Thanks for reply. I didn't know that as soon as I downloaded latest 2.10 and compiled and installed. The qtdragonhd also got updated. I didn't know how to check it's latest or not. Then I checked files in downloaded repo and system files. Both were same.

I have adjusted the code accordingly.
With a bit of luck, this fixes the reported issue.In addition, I have extended the README with a basic usage guide to better explain the workflow and operation.There is now an integrated grooving cycle, which is written into the program automatically when required.Feedback on whether this resolves the issue would be appreciated.

Hello;

I'm finalizing my retrofit and i struggle on the very last detail: the MPG.
My drivers are run by analog command and its works fine, I manage to get decent repeatability and precision.
However the MPG is a huge mess.
2 issues, the first one is the worst to me 
1. When i send only one pulse, the motor is not moving. When i send the second pulse, the motor moves and eventually catch back the 1 first pulse, no always. The issue is the same if joint.0.jog-vel-mode is 1 or 0.
My mpg-counts signal is straight forward and is working well. the axis and joint jog counts are equal to mpg counts 

2. When jogging, the velocity of my axis is not linear, it goes from 0 to 300 very quickly but by step (maybe 3 step by half a second) and does like this all the way

I attach my config as I'm a little bit lost on what should I do

Thank you

Maybe the result depends on the starting position, or some other unknown factor(?)

As such, this is okay for me. I was thinking that maybe a have some strange more or similar enabled. But it appears the preview may require a linear move before arcs.

So maybe a bug in the preview code...

They are talking about user-request-enable pin behaviour.
But I noticed that even after all conditions met for estop_latch.ok-out, this output never becomes true.

i have the same problem:

github.com/LinuxCNC/linuxcnc/issues/3724...uecomment-3778191505

Thank you tjtr33 for the good explanation of the spark process. In the last weeks (or months) i had done some experiments with a mosfet and a 60 V power supply, max 8 A. The mosfet was switched with a variable pwm signal from a esp32. A simple z axis was build from an old 3d printer. I used a hall sensor to measure the current in the gap and control the stepper motor based on a max current threshold. If a shot circuit occurs the electrode will lift up. The dielelectric fluid was distilled water. But because of the low voltage these weren't edm sparks and instead were short circuit sparks. Much more violent, loud and high wear on the electrode. See the test piece for the surface finish, it's bad. Next step would be to get a 100 V - 120 V DC power supply and close the loop with monitoring the spark gap, just as tjtr33 described it. The pwm doesn't care if a spark is good or not. But right now i don't have the time to continue this project (so another dead edm thread on the internet).

Part of the circuit i got from Peter Hofbauer, who has an excellent build log (in german) on his website:
www.hcp-hofbauer.de/indexerodierv2s4.htm

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.