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

Hello,I work for a company that provides on-site and in-factory service and maintenance for heavy-duty industrial and construction machinery.We are currently developing a large custom machine for laser cleaning and automated painting of heavy equipment and structures. The system will use LinuxCNC as the motion controller, but the machine will be operated by multiple technicians who do not have a G-code programming background.For this reason, we are evaluating the use of a PLC + LinuxCNC architecture, where:

• LinuxCNC handles motion control
• A PLC and HMI handle operator interface, recipes, and simple machine operation (start/stop, part selection, dimensions, safety, etc.)

I would like to hear from others who are using LinuxCNC in an industrial environment with PLC + HMI, especially for machines operated by non-CNC specialists.In particular, I am interested in:

• How you split responsibilities between PLC and LinuxCNC
• How you manage recipes and part parameters
• How you design a simple HMI for operators
• Any recommended PLC platforms or architectures that integrate well with LinuxCNC

Any real-world examples or lessons learned would be greatly appreciated.Thank you.

Some notes on what has been working for me:

Currently my go-to PLC+HMI setup is LinuxCNC+Node Red dashboard. Sometimes also Glade user interfaces.

I use a combination of Mesa Electronics boards and/or Beckhoff ethercat remote I/O at locations on the machine where you'd normally expect to find a PLC. My logic runs on hal + custom hal components coded in basically C.

Non real-time logic, recipe selections etc. can be configured in node-red pretty much without writing a single line of code unless you want customized functions.

LinuxCNC also has a ladder logic PLC built-in but I cannot inform you of its capabilities, having never used it. I don't care for ladder logic in any form. I have spent way too much time trying to automate complicated machine sequences in expensive proprietary PLC ladder programming software that did not always function the way I expected or wanted.

With node-red for the HMI, all the software lives in the LinuxCNC 'server'. The physical HMIs consist of panel mount touchscreen IPCs booting pretty much any os, autostarting a web browser fullscreen, pointed at the LinuxCNC sever's Node Red web page. The hmi is simply a web page(s) in the server. Placing a duplicate HMI at an additional operator station consists of whatever device you wish, running a web browser displaying the server's web page(s)

I think node-red supports multiple user logins, but I have not tried that feature. In the projects I did so far, I am the only programmer, and the operators don't know how to access the programming back end. Everyone is logged in as me.

On a recent project I set up a router blasting WIFI over the premises. The operator driving the payloader can log into the WIFI with his phone and access the HMI to monitor the processes and switch the machines on/off that he is tending. From the payloader cab.

The entire network is air-gapped from public internet except the server has access to ntp time.

E-stop, safety lockouts, etc are all hardwired with physical safety hardware.

With this system an operator station needs the following wiring:
1. A power cord for the pc.
2. A network cable.
3. A 2 to 6 conductor cable for the E-stop circuit.

When I get more time I'd like to provide some documentation on all this, and some example configs. Currently I'm in the middle of several half finished projects like this, plus a customer running a proprietary PLC I programmed in ladder logic is starting to have random crashes of the PLC, so he is due for an upgrade to LinuxCNC with Glade user interface. This is one more basic machine, so I will skip the node-red. The glade user interface is an app that runs on a monitor plugged directly into the LinuxCNC pc. Then there is a sizable project I'm currently drafting a quote for.

node red getting started:
nodered.org/docs/getting-started/local

I use this for installing node-red:
nodered.org/docs/getting-started/raspberrypi
Although it says raspberry pi, it can be used on an x86/64 pc. During the installation it asks whether I want to install Pi specific nodes, I opt out of that because my x86/64 pc is not a Raspberry pi.

I have been using mqtt messaging to communicate between the LinuxCNC program(s) and node-red. That entails setting up an mqtt server, I have been using mosquitto:
sudo apt install mosquitto

then I run a python-hal component to communicate with node-red via mqtt

Doing all the above configuration pretty much requires a a person to first know his way around linux configuration in the /etc directory extensively.
Default installation of mosquitto and node-red I think listen only on localhost for connection.

Wow, I was going to attach a copy of my python-hal-mqtt connector, but my backup of it seems to be missing. I will have to retrieve a copy from customer's machine as soon as I can.

Thanks for the detailed explanation — that is a very interesting architecture and I appreciate you taking the time to describe it.Thanks for the clarification regarding Beckhoff I/O. Just to be clear, in your setup you are using Beckhoff EtherCAT I/O as remote I/O, but without a Beckhoff PLC runtime (e.g. TwinCAT PLC), correct? In our case, we are specifically looking for architectures where a real PLC runtime (IEC 61131, ladder/ST, etc.) is responsible for machine sequencing and state, and LinuxCNC is used primarily for motion and interpolation.
In our case, one of the main drivers for using a PLC is to keep machine sequencing, state management, and operator workflow independent of the LinuxCNC PC. The goal is that the PLC maintains the machine state and basic operation even if the LinuxCNC PC or software needs to be restarted or serviced.

We are also targeting a more traditional industrial maintenance environment, where ladder/IEC PLC logic and a dedicated industrial HMI are preferred for long-term support by technicians who are not Linux or software specialists.

For that reason, we are specifically interested in experiences using a real PLC (e.g. Mitsubishi, Omron, Siemens, Keyence, Beckhoff, etc.) alongside LinuxCNC, and how people typically split responsibilities between PLC and LinuxCNC in that type of architecture.

Still, your approach with Node-RED, distributed I/O, and web-based HMI is useful as a reference for alternative architectures — thanks again for sharing your experience

To add some more technical context to our use case:

This is a large-format gantry-style machine for laser cleaning and automated spray painting of heavy equipment and large structures. The focus is on robustness, safety, and simple, repeatable operator workflows rather than traditional CNC part programming.

Our current concept is roughly:

• PLC: machine sequencing, state machine, safety logic, interlocks, recipe management, part dimensions, operator interface (HMI), and maintaining machine state independently of the PC
• LinuxCNC: motion control, path execution, coordinated axes, and low-level servo/stepper control

The PLC would command LinuxCNC at a higher level (start cycle, select program, pass parameters, etc.), while LinuxCNC would not be responsible for overall machine state or safety sequencing.

We are particularly interested in hearing from anyone who has implemented a similar architecture with a real industrial PLC + HMI, and how you structured communication, parameter passing, and responsibility boundaries between the PLC and LinuxCNC in production machines.

Any concrete examples or lessons learned from industrial environments would be very valuable.

I'm not trying to dissuade you from using LCNC with an external PLC, but if you must have a physical PLC handling IO and similar...have you considered a PLC-only solution?

Some PLC's these days are available with high-speed outputs and built-in motion control (trajectory planner) functions.

I have built two automation machines recently using an Automation Direct ClickPlus PLC that drives three axes of coordinated motion via step/dir servos.  Programming was dirt-simple and the resulting motion met our expectations.

The main PLC has the HS outputs - no need for expensive daughter boards just to get the motion control features.

In my case the motion profiles are very simple; I've not explored the full capabilities of these PLCs... but if your needs are also fairly simple something like this might suffice.  Admittedly, the Click PLCs are fairly 'low-end', so higher-end PLC's likely have more sophisticated onboard motion control features.

Thanks for the replies — I think it may help to clarify one architectural point.

We are not evaluating a PLC + LinuxCNC setup because LinuxCNC lacks sequencing, ladder logic, or HMI capabilities.
The decision is driven by industrial architecture requirements.

In our case, the PLC is not intended to replace motion control.
The process is trajectory/raster-based (laser cleaning and spray overlap), where motion quality, lookahead, and path execution are critical — this is why LinuxCNC remains responsible for motion.

The PLC acts as the machine controller:
• machine state and sequencing
• safety and interlocks
• operator workflow and recipes
• maintaining a safe and known state independently of the PC

This is similar to how many industrial robotic cells are structured, where a dedicated motion controller handles paths, and a PLC controls the cell logic and operator interaction.

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

Any practical examples along those lines would be appreciated.

Marcos wrote:

Just to be clear, in your setup you are using Beckhoff EtherCAT I/O as remote I/O, but without a Beckhoff PLC runtime (e.g. TwinCAT PLC), correct?

 

Yes, I'm using Beckhoff I/O strictly as remote I/O, all my logic exists in the pc running LinuxCNC

spumco wrote:

Admittedly, the Click PLCs are fairly 'low-end', so higher-end PLC's likely have more sophisticated onboard motion control features.

I've always had good results with AutomationDirect's Click PLC's. But I've been disappointed with the reliability of their Productivity 2000 and also their BRX models. Maybe it was just bad luck. I've finally retrofitted most of my higher end AutomationDirect PLC's but those Clicks sure don't seem to make much trouble. Still I don't care for ladder logic.

The very first project I sold containing a Productivity 2000 quit about a week after it was out the door. I tried reprogramming it, also tried updating its firmware, no go. I was able to read out some error logs. Automation tech support told me it is bricked, and that they have been having that trouble with that one firmware version. I have to return it for warranty. They gave me a choice of sending back the bricked plc then after they have it back, they send me a replacement. Or I can buy a new plc and they refund me when they get the broken one back. So I bought the new one and got the refund later because the customer was in a hurry. This was a $1200 USD PLC about 7yr. ago. (CPU + base + PSU + motion I/O) Even the base was bricked, that contained a CPLD on its motherboard.

Marcos wrote:

This is similar to how many industrial robotic cells are structured, where a dedicated motion controller handles paths, and a PLC controls the cell logic and operator interaction.

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

Any practical examples along those lines would be appreciated.

I think of this: LinuxCNC has capability to be operated by the user, entirely using keyboard+mouse+monitor, at opposite extreme it can have external I/O wired to physical buttons, switches and dials for operator control without any keyboard+mouse+monitor if you wish.

I'm thinking wire connections from your PLC I/O to LinuxCNC I/O to "drive by wire"? Cycle start, Feed hold, etc. maybe also jogging, whatever you need can be brought out on a wire and connected to your PLC.

The Fanuc 6-axis robot bag palletizer I've been reprogramming lately is connected to an Allen Bradley PLC via ethernet/IP. I have never heard the words "LinuxCNC" and "ethernet/IP" in the same sentence, but I've been meaning to explore the possibilities. I have about $1500 usd worth of new Beckhoff ethernet/IP remote I/O hardware on the shelf for nearly a year now, that I plan to connect with LinuxCNC. My big hurdle has been my nil experience with ethernet/IP. Now on this Fanuc I got an idea what ethernet/IP configuration looks like...