PLC + LinuxCNC for industrial machine with simple HMI (non-G-code operators)

Marcos DC wrote:

@NWE
Following up on the interface question above:Given that LinuxCNC does not currently provide a standardized, PLC-facing external API, I’m trying to understand what has proven to be the least fragile approach in real production systems.In your experience, when LinuxCNC is treated as a subordinate motion controller, what has held up better long-term:
• discrete I/O with explicit handshaking, or
• a register-based interface (e.g. Modbus TCP/RTU or similar)?I’m mainly interested in maintainability and field robustness rather than theoretical capability.

I consider discrete I/O or ethercat similarly less fragile, and modbus has been quite fragile from my experience.

Marcos DC wrote:

@NWE
Following up on the interface question above:Given that LinuxCNC does not currently provide a standardized, PLC-facing external API, 

Sorry, I was misunderstanding you in this respect. I was on a different page, thinking low level I/O.

Marcos DC wrote:

@NWE
In your experience, when LinuxCNC is treated as a subordinate motion controller,
 
 

I can see potentially doing it this way, and I agree, for your use case, this must be necessary, however, I have not used LinuxCNC as subordinate to a PLC in any project. I have used LinuxCNC controlling 6 PLCs via mqtt messaging on a larger project. Above all that in the chain of command I have the safety system, and due to the nature of the system, we have one single discrete signal wired from an output in the safety system to an input on one of the PLC's, through which LinuxCNC reads whether the safety system has disabled the entire plant. During most abnormalities, the program running in LinuxCNC initiates a controlled shutdown of the plant. If the safety system has tripped, it is a foregone conclusion, the plant is already shut down.

Most of the machines on that project are interdependent in various ways, so we have not included the capability to disable part of the system while other parts are in operation, except for the fact that each machine has individual lockout switches. However, It is not possible to complete the automatic startup sequence programmed in LinuxCNC when the locked-out machine fails to start. It does have a service mode where the repair tech has start/stop control of each individual machine during down time.

I can see doing it the other way, where the PLC commands LinuxCNC, but I have not done it that way yet.

@NWE
Thanks for the clarification — that helps a lot, and I appreciate you explicitly calling out the difference in perspective.Your comments are very helpful in terms of transport robustness (discrete I/O vs EtherCAT vs Modbus), and that’s valuable input for narrowing down implementation options.Just to make sure the discussion is clear for readers: when we talk about a PLC supervising LinuxCNC, we’re referring to logical authority over machine state, sequencing, and operator workflow, rather than mastership of the physical communication layer.As you noted, with EtherCAT today LinuxCNC often ends up as the technical bus master, even in architectures where the PLC is the higher-level controller issuing commands and consuming status. These two roles tend to get conflated, but they’re separate concerns in industrial systems.Your insight on which transports have proven more or less fragile in practice is very useful, even though the PLC→LinuxCNC authority model itself is something we’ll have to implement largely on our side.

I did an industrial project 5 years ago with the same control model as you are describing. I am by trade an industrial controls/mechanical engineer and I was contacted by a medical company seeking to automate the production of one of their products. After evaluation of the system requirements it was clear that one aspect of the system would need a CNC controller to run a 4 axis ultrasonic cutter while the bulk of the machine would require standard PLC controller elements. In addition to the CNC cutter section, the machine has 4 servo driven custom conveyors, a heat press laminator, various air cylinders, and a PID temp controlled 10KW heater platen.  It also uses an overhead projector that loads recipe driven images to direct the machine operator where to locate the raw materials on a circulating pallet.

The single most important requirement of the customer was that they wanted a machine that would be simple to operate so that the training to run the machine would be minimal.

I  reached out to this forum to help me understand what would be the best method to "blend" traditional industrial controls (PLCs, VFDs, HMIs, sensors, etc.) with LinuxCNC. Eventually, I landed on using Python as a "bridge" between LinuxCNC and the PLC/HMI. Python has an excellent and stable module called pymodbusTCP. With that module, python can reliably talk to virtually any industrial PLC or device that speaks modbus. The second module that makes it all work is the python linuxCNC module. It talks to a running instance of LinuxCNC and can get status information and it can command LinuxCNC . Using this custom python script that I wrote the system works without the machine operator having any knowledge of how to run a CNC machine or any G code whatsoever. When the system starts up, the python software bridge homes the CNC system and checks it for ready status. The operator simply selects which product code to run via the HMI. From there, the PLC tag with the product code is read by python through ModbusTCP. Then, the correct G-Code file for that cut pattern is automatically loaded into LinuxCNC. When the product leaves the laminator and arrives at the CNC cutter the PLC sets a bit that python reads. Python then tells LinuxCNC to run the G-Code file and it cuts the parts out. When LinuxCNC completes the cut cycle python gets the complete status bit and then it sets a bit in the PLC that lets the PLC know it's time to move the pallet to the next station.  The operator has zero direct interaction with LinuxCNC. This system has been running now for over 4 years and it runs every day producing thousands and thousands of parts. The customer is totally satisfied with the machine and they are now starting to talk to me about the need for a second one. Based on my experience, blending LinuxCNC with standard industrial controls methods and devices is an excellent way to achieve advanced machine control systems. I would highly recommend using Mesa Ethernet cards to offload the pulse generation from your LinuxCNC installation. The Mesa card I installed on this system has been flawless.

Edit: Modbus (TCP) may not be the most "modern" approach that is available but I would say that it is the most universal, well understood, and common Industrial protocol. When it comes to system support it would be hard to argue against Modbus just because so many industrial control techs know it and use it. Simple system architecture typically translates to reliability. In an industrial application, reliability is king.

hhscott wrote:

Edit: Modbus (TCP) may not be the most "modern" approach that is available but I would say that it is the most universal, well understood, and common Industrial protocol. When it comes to system support it would be hard to argue against Modbus just because so many industrial control techs know it and use it. Simple system architecture typically translates to reliability. In an industrial application, reliability is king.

good point

I have been suspicious my bad experiences with modbus was mostly related to some inexpensive hardware I used.