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

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