Advanced Search

Coming from a background in mostly mazak programming and alittle haas the way linux cnc handles tool offsets has been confusing me and maybe it's because I'm not setup with somthing like the carousel macros.

I am currently using axis since it's the only thing that supports the weird display size I accidentally went with. So anyways when I set tool height it moves g54s z value to the tooltip like I was touching off the part not the tool. Currently I have been storing all tool heights too p59 as a work around.

This seems like a weird way of being setup rather then storing it too it's own unique tool height reference for a tool setter. 

I'd be curious too see how the tool setter macros work exactly where do they store the height of the tool setter 

Maybe this is somthing super basic I have never had to setup a tool setter at work before and as far as I fan tell and when manually setting tool lengths mazak seems to base them on a unique height offset.

Thanks for any and all responses!

Light looks nice, very nice.

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.