Production monitoring system

We are discussing a small pilot project to remotely monitor the production rate of 10 high speed presses. These are located within a radius of 100m and the general idea is this :

Requirement : Each press will run a variety of jobs and each job has a ID . The quantity of each job per shift is also fixed. So once the system is installed it will help to do the following :

  1. Each press will have one Sensor node with a Xbee radio module + ATmega328 MCU. Once a digital input changes state, it increments a variable and sends it to a Gateway via XBee, tagging it alongwith the job ID and time stamp. ( the digital state change happens when one component is punched)

  2. The Gateway collects the data from all the 10 Sensor nodes and beams it up via a ESP8266 WiFi link to a local WLAN.

  3. My scope is only upto this ...once the data is sent via WiFi it is then stored in a cloud and the user has an App running on cell phone to query the server / download the data / collate and display it and as well generate alarms based on low production etc.

My question is whether the hardware setup as described in 1 and 2 is the right way to go about this or any other better method can be thought off ? ( Being an Industrial application, the Sensor nodes can be powered by 24V dc from the machine panel and hence power drain is not a major concern as in a battery operated equipment. )

How will you know the jobID?

if you have wifi at all ports, you can use a ESP8266 in each case and not need the xbee.

wildbill:
How will you know the jobID?

To start with we are planning to have small menu driven LCD interface on the Sensor node using which the operator can choose from a pre-programmed enumerated list. Later we can take this info from a Barcode reader or machine setup menu.

Sorry did not elaborate on this earlier.

dave-in-nj:
if you have wifi at all ports, you can use a ESP8266 in each case and not need the xbee.

Yes ... its a viable and simpler option. The ESP8266 having a full fledged MCU in it, can do the digital sensing and beam up the data to the central gateway.

But I am concerned on two things :

  1. The reliability of the ESP8266 - most times you get a good module but on some rare occasions you get not so good ones. And I don't know when that will happen... In the case of Xbee its a reliable and mature offering. So restricting the ESP8266 to only the gateway, I reduce my anxiety.

  2. With the Xbee there is lot more control on each node - its role , sleep etc. Have not worked with ESP8266 extensively to know about these. Maybe possible ??

X-bee is a lot more expensive, but in a commercial setting, I doubt the difference is really material. The nice thing about it is that if your environment is electrically noisy (which I expect it is), you can add repeater nodes to the mesh to make the transmission more robust so I'd be inclined to go that route.

I haven't heard issues with reliability of the ESP8266 yet. They're widely used in all kinds of products. A 100 nF filtering cap and a 100µF decoupling cap go a long way to make it stable.

If you would use NodeMCU or WeMOS development boards stuck into headers on a piece of protoboard (considering the small number I guess that's how you do it), you could easily swap out boards if any one wouldn't work well. It does reduce overall complexity, and OTA updates make code updates for all 10 of them quite easy to do.

Do make sure you filter your power supply well - you have a lot connected to that 24VDC so it will be noisy, and you really want clean power to your MCU. I've had serious problems with my systems powered on a 12V supply that also powers a few small water pumps - had to improve filtering - so far so good but it's been only a day or two.

@wildbill

You said it ... using the Xbee provides so much options to reconfigure in case of unexpected road blocks and it has an excellent support ecosystem to fall back when trouble shooting.

@wvmarle

Oh how did I over look the NodeMCU !! Yes you are very right ... I have had no issues with that hardware. And of course the possibility of OTA updates is another feather to add.

Folks its been a good interaction. SO let me get back to the design and work out the HW for both and list out the possibilities. Being at a concept proving stage I am not focussing too much on cost as of now - which will ultimately become the number one game changer for final deployment.

I am happy based on your feedbacks that what I propose is not a stupid option or one that is possible in a lot much easy way. That's the input I wanted right now. Will come back once I realize the system .

If processing power and number of inputs are a (potential) issue, you may want to have a look at the ESP32 processor as yet another option. At least the NodeMCU has a version that uses this chip, I guess WeMOS also has one by now, and maybe others.

Good luck with the design! I bet it's a fun project to sink your teeth into.

I think that your basic idea is sound.
and that the market has multiple offerings to get you to your goal.

one of the great things going for you is that you can program on a UNO, with an XBee and get it working.

if you are satisfied, great.

then just port your stuff over to the ESP8266 and see how that works.

I have to add that the ESP, either the 32 or 8266 are much faster and that would show on any displays you have.

dave-in-nj:
I think that your basic idea is sound.
and that the market has multiple offerings to get you to your goal.

one of the great things going for you is that you can program on a UNO, with an XBee and get it working.

if you are satisfied, great.

then just port your stuff over to the ESP8266 and see how that works.

I have to add that the ESP, either the 32 or 8266 are much faster and that would show on any displays you have.

Thanks …sounds pretty reassuring . Yes start with reliable and well documented modules and then once the process is established migrate to cost effective solutions. One variable to contend with at one time !!

wvmarle:
If processing power and number of inputs are a (potential) issue, you may want to have a look at the ESP32 processor as yet another option. At least the NodeMCU has a version that uses this chip, I guess WeMOS also has one by now, and maybe others.

Good luck with the design! I bet it's a fun project to sink your teeth into.

Thanks .. will keep that point in mind when the processing power is a limitation.

OK the basic demo set up with the X-Bee + UNO in sensing node and X-Bee+ESP8266 in the Gateway node is getting ready. Should be ok to start with..

Incidentally I was also thinking about the ESP8266 alone on all Sensor Nodes and Gateway . The data flow will be like this :

  1. Sensor Node_X ( where X can vary from 1 to 32 right now ) . Use only a ESP8266 driving a LCD. This is connected to the machine and senses a Digital Input .Use the Menu driven LCD to choose the job ID. So when the Digital Input changes from Low-High-Low, it counts one and sends that info as preformatted string with Machine ID + Job ID + Job count to the Gateway.

  2. The Gateway receives it and first acknowledges the Sensor Node and then beams it up to the server in the cloud. But for this the ESP8266 in the gateway should act as a central access point to which the Sensor Nodes will connect up ( Star topography ). Then it also has to act as a WLAN station connecting to the router. Is this possible to be done on the fly without a power cycling ?

Also what library choice is there for such networking ?