Advanced Search

Slower than I would like to. The workshop is really uncomfortably cold right now. But the control panel is almost done, and the “packaging,” or what goes where, is almost done as well. I will make a few photos when I am in the shop the next time and post here again.

I removed
setp     wj200-vfd.00.update-hz               0.1
from .hal
Linuxcnc starts without any error, but still no Temperature from VDF (my indicator that it should work).
But if click the Spindle CW Button , my Vdf switched immediately into some E 12.1 Error Code (image):
If I click the ccw button, Linux CNC will close suddenly and create some error log about weird Modbus data. (modbus_error.png).

Itś hard to debug, my Workshop is 75m long walk, it is currently -5°C inside, so i bought a 75m ethernet cable to extend my Wifi for RemoteDesktop.
But i have to reset my Vdf by Hand every  E12.1 Error ( good excercise )
 

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.

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.

Hi David,
ich bin zwar auch nicht der Pro aber wenn Du die Materialien schon alle hast,
würde ich persönlich alles daran setzen diese auch zu nutzen.
Wird sicherlich Zeit in Anspruch nehmen, hier und da Schweiß laufen und evtl.
Frust geben aber wenn es dann läuft, kannst stolz sein und hast eine wunderbare Maschine,
was sie ja eh schon ist! Das nur so als Motivation!
Die Indus, kannst Du im "Worst Case" dann immer noch verbauen!

Viel Erfolg und Durchhalten!

Gruß Fritz

@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 tried loading this in master and came up with an error message.

[QTvcp.QTVCP.QT_MAKEGUI][ERROR] Easystep: Trouble looking for handlers in 'lathe_easystep_handler': (qt_makegui.py:469)
Traceback (most recent call last):
File "/home/chris/emc/lib/python/qtvcp/qt_makegui.py", line 446, in _load_handlers
objlist = h(halcomp, widgets, self.PATHS) # this sets the handler class signature
File "/home/chris/emc/configs/sim/qtdragon_lathe/easy_lathe/qtvcp/panels/lathe_easystep/lathe_easystep_handler.py", line 7101, in get_handlers
return [HandlerClass(halcomp, widgets, paths)]
File "/home/chris/emc/configs/sim/qtdragon_lathe/easy_lathe/qtvcp/panels/lathe_easystep/lathe_easystep_handler.py", line 3038, in __init__
self._connect_signals()
File "/home/chris/emc/configs/sim/qtdragon_lathe/easy_lathe/qtvcp/panels/lathe_easystep/lathe_easystep_handler.py", line 4468, in _connect_signals
self.list_ops.currentRowChanged.connect(self._handle_selection_change)
AttributeError: 'QWidget' object has no attribute 'currentRowChanged'

I didn't look into why.

I did switch to 2.9 and it seems to work, but I haven't figured out how to use it yet

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

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.

looks great. I'll have a play.
Does my homecomp you link to work for you without any changes?
github.com/rodw-au/cia402_homecomp
I never had hardware in the end to test it properly.

Hi, I'm very new to CNC, and I have a Maxnc15CL from around the year 2000 and am using a Raspberry Pi 5 to communicate with it using LinuxCNC. The Pi 5 has a parallel port hat from Byte 2 Bot, and I'm able to control the spindle, detect the limit switches, enable the motor encoder feedback loop, and make the motors make noise when I tell the axis to move. I suspect that the motor timing is off, but im not too sure if when I change the values, if it's getting closer or further away from actually moving. If anyone has any ideas on how to make this work, I would greatly appreciate it, and im leaving my hal file and .ini file below. Thank you 

I would like to share my repositories at github, this repository consist of Programs created to automate the creation of EtherCAT configuration files, solutions for all the problems described at this topic as well configs for XYZ, and XYYZ.
topic:
github.com/szolkaa/Automatic-linuxcnc-co...rators-for-ethercat/

Hi all,
I am completely new to this as you can probably tell. I recently bought an old Gerber Dimension 200 for cheap. It’s a beefy chassis that will allow for a great machine by doing some upgrades. I’m doing a complete overhaul of electronics, spindle, steppers, limit switches etc. All of which will be run off a 7i96 board with the SpinX1. I am a bit confused on how to choose a spindle. I’d like it to integrate with the Mesa board well obviously. The wiring just doesn’t make sense to me on what goes where. If anyone has a solid recommendation for a spindle kit or the like please let me know. Will only be doing wood and aluminum, with the occasional steel sheet. Thank you guys for your time and knowledge.

Hallo liebes Forum!

Das ist mein erster Post hier. Bin ganz schön am Anfang meiner LinuxCNC-Reise. Habe zwar schon einige Male an Fräsen gearbeitet, die mit LinuxCNC liefen, aber noch nie ein System selbst aufgesetzt. 

Ich bin auf der Suche nach Tipps zu folgendem Thema: 
Ich baue gerade eine Mitutoyo QV404 um zur CNC-Portalfräse. 
An der Maschine sind noch die Original Glasmaßstäbe und Lichtschranken (als End- und Referenzschalter) dran: 

So kam die Maschine bei mir an: (Vorbesitzer hat schon angefangen Umbauten vorzunehmen)
 

Beim Auseinendernehmen der Z-Achse, musste ich die Auslese-Einheit der Glasmaßstäbe abnehmen, dabei habe ich ein paar Bilder davon gemacht:
 

 

 

 

Da sieht man an der Seite auch schon gut die Platine mit den Referenz- und Endschranken. 
Das ganze läuft dann hinten an der Maschine auf dieses Board: 

 

 


Denkt ihr, es ist realistisch, diese Teile zu verwenden? 
Ich bin leider im Bereich Elektro/Programmieren nicht so die hellste Leuchte und halte mich dann eher mit ChatGPT über Wasser  , kann mich aber tendenziell ganz gut in neue Felder einarbeiten. 
Falls ja, gibt es vllt gut dokumentierte Beispiele von anderen Forumsmitgliedern, die euch einfallen, wo ich mir ein bisschen was abgucken kann? 
Wie würdet ihr da ran gehen? 

Ich bin eigentlich kurz davor, die Lichtschranken einfach durch induktive Endschalter zu erstetzen und, da die Glasmaßstäbe unverkleidet und somit störanfällig für den Fräsbetrieb sind, auch hier kurz davor diese rauszuwerfen. Aber gleichzeitig auch noch auf der Suche nach guten Gründen sie drin lassen zu können, da Original-Mitutoyo und schön. 

Würde mich über Einschätzungen freuen  
Grüße
David 


 

How is the Schaublin progressing?