Advanced Search

I finally managed to implement this and it seems to work very well.

What it does:
- Detects the first G5x coordinate system (G54–G59.3) used in a G-code file
- Prints a debug log to the terminal: [DEBUG] G57 on line 4
- Sends the detected G5x via MDI so that the GUI updates to reflect the active work coordinate system

How I implemented it:
I added the following method to the StatCanon class in:
/usr/lib/python3/dist-packages/qt5_graphics.py



Notes:
- Make sure this method is placed inside the StatCanon class with consistent 4-space indentation.
- The initial G54 on line 0 and final G54 at the end (due to GUI reset) are ignored using: self.lineno > 0
- Only the first explicitly used G5x is applied via MDI.
- Verified to work reliably in QtDragon simulator config.

This improves usability by ensuring the GUI’s coordinate system matches what the G-code will actually use.

Tested with:
- LinuxCNC 2.9.4
- QtDragon (QtVCP)
- sim.qtdragon.qtdragon_tool_probe configuration

Let me know if this is helpful or if there’s a cleaner way to hook into the coordinate system logic.

Great info thanks. I will most likely go with the 48v supply I bought , although I will then have to add another step down supply as the board max is 24v so I will need a 48v to 24v and then 24v to 5v I already have. Worthwhile though going by the graph. I don't expect to drive at high speeds either.

Ich habe den Fehler gefunden: es war der doppelte Eintrag "net machine is on.." in der Handrad.hal. und in der Maschinen.hal. Wenn dieser Eintrag in der Maschinen.hal auskommentiert wird, dann funktioniert das Handrad korrekt.

I had trouble installing Verser's v2.9 probing screen for the Axis GUI.  Eventually I decided to try EasyProbe.  Easy enough, except that the pocket probing function has a constant that only works for metric.  But if you change ff_distance from 5 mm to 0.2, it appears that everything works.

EasyProbe allows you to calibrate the probe tip, which avoids the complication of using an indicator to get the probe tip colinear with the axis of the spindle.  The drawback is you must measure with the probe oriented as it was during calibration.  Here's my calibration setup

 

The ring gage is 1.0060 inches
 

After calibration, the I probed the pocket a few times.  The measured diameters varied from the standard by

1. 0.000,014 inches
2. 0.000,006 
3. 0.000,114
4. 0.000,097

I would only believe this to a tenth (+/- 0.000,1 in).  But it's not bad for a probe tip that is off axis by almost 2 thou.

While working with EasyProbe, I encountered manual tool changing for the first time, with rapids set to 200 IPM.  I had also set TOOL_CHANGE_QUILL_UP, which almost smashed the probe into the table.  I had set up the axes using the right hand rule, with +Y moving away from the operator.  This requires that +Z is up.  I turned off the quill-up setting but had several close calls because M6 rapids the spindle to the tool change location, not caring about the Z position.  So I've got to reverse the Y axis so I can take advantage of the quill-up setting.  

Hi, I am just on the way to start my ethercat adventure.
I received my ethercat servos and some beckhoff ethercat interfaces as well.
Now i recognize that I still need something to control my Optidrive E3 VFD over modbus.
Can I use the El6001 Serial Interface or wich Interface do I need?

I would really appreciate any help or hint

best Kai

Hi,

i think you need to update local git clone first. It needs latest updates.

Then build_cmake.

It is capable to switch between the two modes but it is not a 'normal' setup.

Because there are different setups there isn't a 'one size fits all' solution to do this.
In your case I would wire the DC drive as the spindle and the servo as a rotary axis (eg 'C').
Solutions will largely depend on what kind of encoder signal(s) you have and whether those track spindle position at all times or only in either turning or milling modes.
If you have encoder and index feedback from the same source and the encoder position isn't lost when operating the the spindle at max speed then you can home the rotary on startup and don't need to rehome when switching from turning to milling. There is 'caxis.comp' to prevent the spindle unwinding the accumulated rotations for this case. The original version of this can be found in the zip folder in this thread:
forum.linuxcnc.org/10-advanced-configura...ling?start=50#288345

If you do need to rehome the rotary due to lost encoder position then make sure to take note of the bug described in this thread and the workaround presented:
forum.linuxcnc.org/38-general-linuxcnc-q...blem?start=20#324276