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

I don't think many people use a PLC in conjunction with Linuxcnc. There is an Ethercat master we have a driver for so getting IO and the like is pretty easy. Stick to Beckhoff for best support but making a custom XML driver for other IO and drives is pretty simple. Whilst people have mentioned Ladder Logic which is available, the secret magic nobody seems to mention is you can write hal components which when built and installed with a 1 line command : sudo halcompile --install mycomp.comp. Once these are built, they are treated exactly as if they are part of the core program and run in real time.

I do know a guy who has retrofitted a lot of big machines and recently on one big 5 axis machine with 100 tools and multiple pallet changers, the ladder wasn't doing it for him so he learnt a smattering of C and knocked out his working high speed tool changer component over a weekend.  

Check out Beremiz (beremiz.org).
I equipped it with a HAL interface. Works well with LinuxCNC.
runs under Linux and is open source.

I’d like to clarify a few points for readers, as I think some replies are unintentionally mixing different problem domains.

First, regarding PLCs and “ladder-only” assumptions:
Modern industrial PLCs are not limited to ladder logic. Under IEC 61131-3, ladder is only one option. In real industrial machines, Structured Text (ST) is very commonly used for state machines, sequencing, recipe handling, diagnostics, and supervisory motion logic.
In addition, several PLC platforms support compiled C/C++ modules or libraries (for example Beckhoff, B&R, Codesys-based systems, etc.). So PLCs are not inherently low-level or limited to ladder logic.

Second, regarding Beremiz:
Beremiz is an interesting IEC 61131 runtime, but it still runs on the same PC and operating system. In our use case, that does not meet the requirement. One of our core goals is that the machine controller remains independent of the LinuxCNC PC, maintaining machine state and safety even if the PC or LinuxCNC software needs to be restarted or serviced. A soft-PLC running on the same machine does not provide that separation.

Third, regarding remote operation via Wi-Fi or mobile devices:
While this may be acceptable in experimental or supervised environments, it is generally not acceptable in industrial machinery. In an industrial context, machine start/stop authority, mode selection, and operator interaction must be mediated by a certified PLC and physical HMI, with clear local/remote modes, access control, and hardwired safety circuits.
Allowing machines to be started or stopped directly from phones or ad-hoc web interfaces raises significant safety, liability, and maintenance concerns in real production environments.

To clarify our intent: this discussion is not about whether LinuxCNC can do everything. LinuxCNC is excellent at motion planning, interpolation, and trajectory execution, which is exactly why we want it handling motion. The PLC is used as the machine controller, responsible for sequencing, safety, operator workflow, and maintaining a known, safe state independently of the PC.

This is a very common architecture in industrial CNC machines and robotic cells, where a PLC handles cell logic and operator interaction, and a dedicated motion controller executes paths.

We are specifically interested in practical examples of this kind of PLC-driven cell logic combined with LinuxCNC (or otherwise)) as a motion controller, rather than PC-centric or soft-PLC-only architectures.

@rodw
Thanks for the clarification. I think we may be talking about slightly different problem spaces, so I’d like to address your point more directly.

I fully agree that LinuxCNC + HAL + custom C components is extremely powerful, and technically capable of replacing much of what a PLC would do. That is not in dispute.

In our case, however, the decision to use a real PLC is not driven by capability, but by industrial lifecycle and responsibility separation. The PLC is used as a dedicated machine/cell controller that:

• maintains machine state and sequencing independently of the PC
• handles safety interlocks and operator workflow
• is maintainable by technicians familiar with IEC 61131 environments
• remains in a known, deterministic state even if the LinuxCNC PC is rebooted or serviced

While writing HAL components in C is a perfectly valid solution, it assumes long-term availability of developers comfortable with Linux internals, HAL, and custom code. In many industrial environments, that is not a realistic maintenance model.

LinuxCNC remains responsible for what it does best: motion planning, interpolation, and trajectory execution. The PLC acts as the machine controller. This separation is very common in industrial CNC machines and robotic cells.

So the question is not whether LinuxCNC can do everything, but how others have implemented clean responsibility boundaries between a real PLC and LinuxCNC in production machines.

If you’re aware of real-world deployments following this model, those examples would be particularly valuable to the discussion.

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

The original EMC (pre LinuxCNC) design allowed separation of the HMI from the machine itself and communicated via the network and NML.
NML docs: linuxcnc.org/docs/html/code/nml-messages...sec:nml-msg:operator
In one of the config files, there are seperate IP addresses for these two pieces. I can't remember the file to look at and have no idea how much of that is still functional.

I've suggested a few times recently that The missing piece is a modern API for Linuxcnc using restful type calls or even MQTT. It would be a massive body of work that requires a lot of planning. (even picking the API method) I don't think any of our developers are familiar with the API space to even think about it.

Possibly MQTT might map pretty well to NML messaging.

Thanks for the detailed context — that is actually very helpful.

The original EMC separation via NML is interesting and reinforces that LinuxCNC was architecturally designed with separation between the core and the user interface in mind.

From an industrial controls perspective, this also highlights the exact challenge we are running into today: while LinuxCNC has powerful internal mechanisms (HAL, NML), there is currently no stable, supported, PLC-friendly external API that allows LinuxCNC to act cleanly as a subordinate motion controller under a PLC that owns machine state, sequencing, and safety.

Concepts like REST or MQTT could theoretically bridge that gap, but as you noted, defining a robust, long-term API would be a significant effort requiring careful planning, standardization, and maintenance commitment.

Until such an interface exists, PLC + LinuxCNC architectures will likely continue to rely on discrete I/O or tightly-coupled custom integrations, which explains why this model is relatively rare in production despite being conceptually attractive.

This discussion has been very useful in clarifying the current state of LinuxCNC in this regard and helps set realistic expectations for industrial deployments.

Thanks again for the insight.

Just curious, would two separate LinuxCNC instances, running on two physical PC's, one for the motion control, and the other acting as the PLC meet such requirements?
Cheers,
Mark

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.