Advanced Search

Per chance, have you written up in some detail how you accomplished this?

Hey Guys,

i need some opinions about the design, i kind of like it but im not quite sure if it is worth the time.

What would you say?

The edited version (Light) or Standart?

Thx for any help

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.