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

Thanks for sharing your experience — this is exactly the kind of real-world example we were hoping to hear about.
Your description matches very closely the architecture we are targeting: a PLC/HMI as the cell controller (sequencing, recipes, operator workflow, interlocks), and LinuxCNC used strictly as a motion controller. The Python “bridge” approach you described, using Modbus TCP on the PLC side and the LinuxCNC Python interface on the PC side, is a very pragmatic way to implement a clean command/status boundary between the two domains.
What I find especially valuable in your example is that the operator never interacts with LinuxCNC directly: the PLC/HMI owns the workflow, selects the product/recipe, and LinuxCNC is treated as a subordinate motion engine that executes the required paths and reports status back. That is exactly the separation of responsibilities we are aiming for.
It is also very useful to hear that this setup has been running in production for several years, daily, with good reliability. This addresses one of the main concerns in industrial environments: long-term robustness and maintainability, not just theoretical capability.
Your comment about Modbus TCP being “simple and universal” is also a good reminder that, in many industrial contexts, simplicity and familiarity often translate directly into better supportability and uptime.
Thanks again for sharing this — it’s a very strong reference point for PLC + LinuxCNC architectures in real machines.

There is also the option of equipping the LinuxCNC PC with an EtherCAT slave interface.
Data exchange can then take place via this interface.

A few more details:
Because you will have 2 separate controllers (PC with LinuxCNC and a PLC) startup handshaking has to be worked out. In my case, I set up the linux pc to autostart on power just like a PLC does. Then, on the linux PC I set LinuxCNC to Auto Start on boot. After a few seconds of delay, I Auto Start the "Python Bridge" script. The Python bridge requires that LinuxCNC be up and running before it starts because the python linuxCNC module goes out and looks for linuxCNC to be running. This all takes less than a minute.

Once the Python bridge is up and running it does two things, checks the status of LinuxCNC and starts setting and unsetting a bit in the PLC via modbus. The bit sets and then resets every 250 ms. This is my heartbeat that lets the PLC know that everything is up and running. LinuxCNCs status concerning "Power On", "E-Stop active", and "Axis Home Status" are all read by the Python bridge and this information is passed to the PLC through registers and bits. The PLC then directs that power be turned on, after confirmation that the power is on (again through the python bridge) the PLC issues a "Home All Axis" command. After all axis are homes the Python bridge sets a bit in the PLC that lets the PLC know its ready for operation. In this control scenario, the PLC is always the Master controller, it just checks on and commands LinuxCNC through the Python bridge script. 

Safety is handled like any other industrial set up. A separate safety controller (not the PLC or LinuxCNC) disables all motion and potential in the machine including disabling the CNC servos. The PLC and LinuxCNC are both wired into the safety output so they both stop any motion in the event of an emergency stop. When the safety status is cleared, the PLC issues a "Power back on" command to LinuxCNC and then a re-home command. 

It sounds like a lot, but it is really straightforward and pretty simple once you get the workflow sorted out. 

The machine as it is today can produce 28 unique product variations (potential is almost limitless) and the operator only has to select the
product number via the HMI. Everything else is handled in the background automatically. The operator doesn't have to have any knowledge or CNC experience to run the machine. Training takes less than 30 minutes for a new operator.

Thanks for the additional details — this is very helpful.

At the moment I don’t have EtherCAT hardware available, so I’m starting by validating the architecture with what I already have: Modbus (mb2hal / Python bridge). The goal is to first prove the PLC-as-master / LinuxCNC-as-motion-controller workflow, including startup handshaking, heartbeat, status exchange, and command flow, before moving to other transports like EtherCAT.

Your description of the startup sequence, heartbeat bit, status propagation (power, E-stop, homed), and the PLC-driven workflow matches very closely what we are trying to implement. It’s also very encouraging to hear this has been running reliably in production for years with operators completely abstracted from LinuxCNC.

Once this is stable with Modbus, we can evaluate other interfaces, but for now the focus is on validating the control model and the command/status contract between PLC and LinuxCNC.

Thanks again for sharing the detailed workflow — this is exactly the kind of practical guidance we were looking for.