Hello everyone, I need to collect data from plastic injection molding machines and I'm facing the following problem.
The scenario: We have a production line with 3 independent machines. They are controlled by Techmation A80 series PLCs and HMIs. My goal is to extract operational data (production count, machine status, alarms, and cycle times) from these three units, process the data in Node-RED, and send it via MQTT to a ThingsBoard control panel.
The challenge: The only available communication port on this HMI is an RS232 serial interface, which is also connected to the only network output of the RS232 controller.
Has anyone implemented this type of RS232 bridge before? I don't know the memory addresses or the protocol used (the manufacturer doesn't provide this information either). I thought about capturing network traffic (sniffing) and decoding the controller's response to the HMI.
I use this for RS485 (Modbus) to various meters and Solar devices around my place (i have 3 of these boxes) and have never had a single issue with them - note i have not tried the RS232 so you would need to investigate that.
I run all my Node Red as Virtual Machines and use this to translate from Modbus/TCP to Modbus/RTU
However, my biggest concern at the moment is whether this type of sniffer on the RS232 network will work without losing communication with the current HMI, and how to translate the data collected from this communication, since it is not an open communication protocol like Modbus. I believe it is ASCII.
But I also used com0com/ hub4com and created virtual com ports
For linux world, I am pretty sure you could achieve something similar using socat or interceptty (should run fine on a PI with 2 cheap USB Serial interfaces)
However that was all a long time ago - today, I believe it would be as simple as Node-RED proxies the data bewtween the 2 serial ports:
[serial in - ttyUSB0 (DEVICE)] → [serial out - ttyUSB1 (HMI)]
↘
[debug / function / mqtt / whatever node]
[serial in - ttyUSB1 (HMI)] → [serial out - ttyUSB0 (DEVICE)]
↘
[debug / function / mqtt / whatever node]
This would of course require you to disconnect serial from the device, connect it to an active hardware (like a Raspberry Pi or computer) then connect to serial port 2 to pass the serial on - so not exactly passive pass through (more of an active pass through)- depends what you are comfortable doing.
This is a very interesting approach! I believe it will work well and is certainly a great low-cost solution.
However, I have two main concerns regarding a production environment:
Latency/Timeout: Since we are introducing an active intermediary, communication will naturally have a slight delay. The controller may be strict about polling times, interpret this delayed response as a communication failure, and trigger a timeout error.
Single point of failure: If my Node-RED instance crashes or the host computer restarts for any reason, the physical connection between the PLC and the HMI will be completely broken, causing the machine to stop immediately.
Will it though? Is this something you know already / experienced already?
Personally note: I consider any HMI failure that actually stops production to be a pretty poor design! (in my automotive days, something I often asked (when we bought or designed systems) was "will it stop the facility if it breaks"). Not saying it doesnt happen or doesnt have merit (in some cases), just that it ideally, it should not! e.g. When a machine is setup and running, the HMI is pretty much just eye candy (get it replaced/fixed while the run continues). I've even seen me input raw bits and bytes into the PLC memory areas for the next run while a suitable HMI replacement was sorted!
Obviously a test will be necessary. I estimate you would add <=10ms into responses. If this is not a protocol that depends on well timed gaps (looking at you Modbus RTU/DeviceNet/PROFIBUS) then I dont think this will be an issue.
Yes, comes with the active vs passive territory. It depends on the application and/or risk aversion. Its a balance between needs/wants/efforts and such.
For example, you could always go passive (build or buy an adaptor) and connect to the middle leg to a serial connection! You may even find an ethernet based one with spy/sniffing however I did not find a suitable device when i was doing this like 10/15y ago.
To clarify the situation with the machine: all interaction is done exclusively through this HMI (Human-Machine Interface). The operator performs several necessary operations during the machine's cycle. If the connection is interrupted, the machine can technically continue executing its current physical process, but it will exhibit a "malfunction" from a production standpoint, as we lose all ability to change parameters, send commands, or monitor alarms. This is why a stable connection is crucial.
Regarding latency, the protocol is entirely proprietary to the manufacturer and is not open. Because of this, only a practical test can determine if the additional latency of an active Node-RED bridge will cause a timeout error in the controller.
There is also another possible obstacle with the active bridge approach (USB 1 -> Node-RED -> USB 2). I checked the controller board and the DB9 port has 7 active traces, which means it likely relies on hardware flow control (RTS/CTS, DTR/DSR). From what I understand, the Node-RED Node Serialport forwards the data perfectly, but it doesn't replicate the states of the electrical control pins between the two ports. If the PLC waits for a "Release to Send" (CTS) electrical signal that Node-RED doesn't generate, communication will simply be interrupted.
I've researched professional RS232 data analyzers/snap-throughs (like the Advantech Data Taps), but they are very expensive (US$400 to US$500) and, unfortunately, difficult to find, as they require international import to Brazil.
Due to these risks, another possibility I'm considering is developing a custom passive analyzer based on a half-duplex spy cable diagram. Using a 1N4148 diode and a 2.2kΩ resistor, I could safely combine the PLC's TX line and the HMI's TX line into a single RX port on my gateway. This would allow me to passively 'listen' to the traffic without interrupting the physical connection or dealing with communication problems between the hardware components.
But I'm still considering performing a test with this approach (USB 1 -> Node-RED -> USB 2).
Has anyone here done any kind of passive analysis like the one I mentioned above?
Yes (as far as the old grey matter remembers anyhow)
But not with Node-RED (this was pre-node-red) I used a serial logger for the breakout. There is always the risk that it could introduce noise through impedance (or bad workmanship) and be unreliable but testing should reveal that. However, listening to the breakout using Node-RED should be no different / have no impact.
About the diode and resistor and breakout cable - they may introduces a small RC effect that softens signal edges. At the usual slow baud rates of older systems (9600, 19200) this is probably a non-issue, but worth confirming on a scope if the machine runs at anything higher. Note, there are far cleverer electronics guys who lurk this forum - they may have better feedback.
You can use DSLogic Series - DreamSourceLab. I used for RS232 (for the printer and the entire label) and RS485 (modbus) for listening. It's less intuitive and records temporarily. If you have an oscilloscope, you can connect it as long as it supports protocols decoding.
Aaqu, the solution seems good, but it's geared towards diagnostics; afterwards, I would still have to buy hardware to run the readings permanently, which I also found a bit complex.
I will continue trying to replicate the Spy's RS232 by buying the components and assembling the cable, and if that doesn't work, I will try the approach suggested by Steve (USB 1 -> Node-RED -> USB 2).
Again, if anyone in the electronics field or anyone who has done this before could share more details, I would be very grateful. Thank you.
