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

Hi Mark, thanks — that’s an interesting idea.

Technically, running two separate LinuxCNC instances on two physical PCs (one dedicated to motion control, the other acting as PLC/HMI) could meet the functional requirements.

However, for our target environment — multiple non-G-code operators, industrial maintenance, and potential future machine sales — we prefer a clearer separation of roles:
LinuxCNC dedicated strictly to deterministic motion control, and a real industrial PLC + HMI handling sequencing, recipes, interlocks, and operator interface.

On the motion side, we are currently planning to use Mesa Electronics hardware (for example 7i96S with 7i84U remote I/O and THCAD-2), but the exact hardware is not finalized yet. LinuxCNC would remain focused purely on motion and kinematics.

Using two PCs increases overall system complexity (two OS installs, updates, storage, diagnostics, etc.), and it still doesn’t fully meet the typical industrial expectation of having a dedicated PLC for troubleshooting, maintenance, and customer acceptance — compared to using a conventional PLC platform (e.g. Mitsubishi, Omron, Beckhoff, etc.).

Safety will be handled by dedicated safety hardware (E-stop, STO, safety relays or a safety PLC), independent of whether LinuxCNC or PLC is used for logic.

So at the moment we are leaning toward a PLC + HMI + LinuxCNC motion architecture rather than using a second LinuxCNC instance as a PLC replacement.

Cheers!

Most PLC's and touchscreen HMIs do pretty much everything in their software. For workcell controllers intended for operator safety, you need a combination of hardwired safety controllers and power disconnects that can be locked. LinuxCNC has many available interfaces for communicating with PLCs. Ethercat, discrete I/O, analog, RS232, RS485, CAN, Modbus TCP, Modbus RTU. Probably more. Safety controlling is outside the domain of LinuxCNC.

On systems where the PLC/computer automatically start/stop 250HP machines or even 1/4HP machines, every machine on the premises has a dedicated power disconnect switch that can be locked. If that disconnect switch is on, the machine must be assumed to be running, whether or not it is making noise. Everything is prominently labeled with danger signs, reminding personel that the process equipment starts/stops automatically.

Plus we have the hard wired safety circuit that disables everything and only communicates to LinuxCNC that it has been disabled. LinuxCNC cannot activate this safety circuit. Not even an industrial PLC is qualified to run this safety circuit, only dedicated fail-safe safety controllers do that.

Marcos DC wrote:

@NWE
Thanks for the explanation. In our case, the PLC cannot be a “drive-by-wire” remote control for LinuxCNC. The PLC must be the authority of machine state, sequencing, and safety, independent of the PC. LinuxCNC is treated as a subordinate motion controller, similar to how a PLC supervises an industrial robot controller.

That is the key architectural requirement we are trying to address.

I meant the other way around. PLC driving linuxcnc

@NWE

Thanks — that clears it up. I now understand that you meant the PLC driving LinuxCNC, not LinuxCNC driving the PLC.
That is exactly the architecture we are aiming for: PLC as the authority for machine state, sequencing, and operator workflow, with LinuxCNC acting as a subordinate motion controller responsible for trajectory planning, interpolation, and coordinated motion.

Where we are still looking for practical guidance is the shape of the interface between the PLC and LinuxCNC — in other words, what has proven to be a clean, maintainable, industrial-friendly command/status boundary without turning into a large custom integration project.

From your experience, do you see this working best as:

Discrete I/O + handshaking
(cycle start, feed hold, abort/reset, mode select, jog enable, plus status bits like ready/running/done/fault), with parameters passed via registers; or

A fieldbus/protocol approach
(e.g. EtherCAT, Modbus TCP/RTU, etc.) with a defined command/status register map.

For safety, we fully agree with your description: E-stop, STO, door interlocks, and power isolation are all handled by dedicated hardwired safety hardware, independent of both PLC and LinuxCNC. Software only receives “safety OK / safety tripped” status and never has authority to energize the safety chain.

If you have examples of a minimal but robust command/status block that has worked well for you (which bits/words you expose, how you handle “busy/done/fault”, parameter latching, etc.), that would be extremely helpful.

@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.

For keeping it simple, I think I would look at discrete signals using Mesa cards or maybe ethercat. Ethercat is somewhat more complicated to get started, but you get to replace all that discrete wiring with one robust ethernet connection, which you can not route through an ethernet switch, but I saw Beckhoff has ethercat hubs for this purpose.

I used to like modbus but the more I use it, the more I despise it. Compared to the other options, modbus seems slower and less reliable. Probably depends on the application. I am moving away from modbus entirely.

If you want RS232 or RS485, ask someone else, my opinion is it can be done (I use them if I have to interface with something that gives me no other choice) but... its a pain. Except... Mesa has what I think runs on RS422 called SSerial (SmartSerial) which I think is a joy to use. It is stable and it is plug-and-play. To use that, you start with a Mesa board that has SSerial host, then you can connect additional I/O SSerial daughter cards to it via SSerial.

If going with ethercat, LinuxCNC does only master that I'm aware or. You would want to use a PLC that exposes an ethercat slave to LinuxCNC for transferring data/commands between PLC and ethercat. What I mean, is the ethercat link would be LinuxCNC = master, PLC = slave, however, linuxcnc would be listening on this connection for commands from its real master, the PLC. I admit I'm a bit of a newby with ethercat, been using it barely a year. Been tinkering with linuxcnc 10+ years and just recently majorly included it in my toolset.

Whether discrete or ethercat, this would amount to hal pins that you would connect to control signals in the hal configuration text file(s). How clean the implementation would be would probably depend a lot on how well you organize the hal files.

When I'm programming my LinuxCNC "plc" controllers, I'm doing most of it in a linux program that looks and works a lot like notepad with some additional bells and whistles.