Manual tool change + tool lengh touch off

I have no idea about internals of linuxcnc, but i had the same error. It appeared that linuxcnc reads the entire gcode file you want to feed it and if somewhere in that listing it calculates that the tool gets above the limits you have set for that axis then it gives this error.

When i calculated it by hand - it was entirely correct that warning.

I have reconfigured the way how the Z-axis runs here. In the limits of the linux CNC i have it run from -58 to +58 yet when the toolsetter initializes then the bed is 0.00 and the toolsetter in this case is 41.5

I touch off just above the workpiece or if one wants to mill the top of the workpiece at the top of the workpiece as z=0.00

So the endstop at the Z-axis here is at the top here and nothing at the bottom.

So in the .hal file i have set a max-home-z and not a min-home-z endstop.

in the .ini file i have
min_limit = -58
max_limit = 52

So if i hit the + continuous Z-axis move then the milling motor goes UP
and if i hit the - of Z-axis then the milling motor goes DOWN.

And the GCODE of the pyvcp that's doing the endstop probe i'm doing as
with the toolset probe located at hard coordinates X=4 and Y=30 currently
and after the probe the tool is 45 mm above the bed.

As the idea was that this routine gets called after homing, i'm moving down the tool at most 40mm. In reality it's like 7 mm drop as the Z-axis at this 'engraving machine' is only 60mm max.

o100 sub
G91 G21
G38.2 Z-40 F100
G10 L20 P0 Z41.5
G90
G0 Z45
G38.2 Z40 F10
G10 L20 P1 X4 Y30 Z41.5
G90
G0 Z45
o100 endsup

Yet it's a mess what sits where in linuxcnc.

Some limits are in the .ini file and others in the .hal file and in my case to initialize it all i use a .stepconf file which i'm no longer using because if i use the stepconf wizard all kind of modifications in the .hal and .ini are gone.

The only advantage of this mess seems to be there for commercial dudes who have made settings for their CNC line and those at home who want to configure linuxcnc themselves for a selfbuilt machine are litterary thrown into the deep ocean.

What i fail to accomplish is give in pyvcp a parameter from what is on the screen to the gcode.

Therefore this gcode script is hard coordinates instead of using the coordinates that's in the GUI of axis.

I finally figured out why OrangeCats tool-change routine sometimes stopped with errors like this:
"Linear move on line 133 would exceed joint 2's positive limit"

The reason is this:
If you probe your reference tool, i.e. first tool change after the M600 command, before you touch off on the work piece, the reference tool length (#<_ToolZRef> in the code) will not be scaled to the new G54 coordinate system. The math in this line then goes wrong:

G53 G1 F[#<_TravelFeed>] Z[#5183 - #<_ToolZLast> + #<_ToolZ>] ( return to where we were in Z, adjusting for tool length change )

#<_ToolZLast> is equal to #<_ToolZRef> on first tool change after the reference tool is measured (i.e. on second tool probing sequence), but this in relative unit in the G54 coordinate system before the work piece was touched off. #<_ToolZ> is the probing result in the new G54. This combined with the additional fact that #5183 never gets set to the correct value after touching off (always zero) doesn't help.

Hence to make the manual tool change work do this:
1) home machine
2) Touch off to work piece
3) M600
4) M0 T6
5) Run program

Hello all,

it seems that the patch #1096 now breaks the probing routine.
github.com/LinuxCNC/linuxcnc/pull/1096
github.com/LinuxCNC/linuxcnc/issues/368

After the latest updated linuxcnc version 2.8.1 i allways get the error "Probe tripped during non-probe move." when the probe sensor get a signal and the subroutine stops.
Is there a workaround possible?

regards
Karlram

It seemsto be a "probing with rotating spindle" issue. I need a rotating spindle to measure the tool legth by a laser sensor. Without the S24000M3 command G38.2 works fine. But with the rotating spindle i get allways the non-probe move error.
I made a test with S0M3 -> G38.2 probing works fine. A running spindle leads always into the non-probe error.
Is there a way to run the spindle and probing?

regards
Karlram

I just tested this patch on my machine and I can have the spindle turning while probing without issue. A G38.2 behaves as expected when preceded by a S6000M3, a S0M3, or a M5.

One thing to be aware of is that prior to this change, the stop on non-probe move pretty much did not work. As soon as a program or macro was run, the probe input was ignored on non probe moves. If you have any noise on your probe input, you will get non-probe move errors popping up. It is possible that when your drive is on, there is some noise on the probe input?

Thank you for your advice. The noise was the problem, exactly the rotating edges of the flute. After an additional debounce of the pin the probing works like expected.
Thank you very much for your support.

Regards
Karlram

same problem here with laser-measurement.
github.com/LinuxCNC/linuxcnc/issues/368#issuecomment-822429577

I could add debouncing, but it seems not to be the correct way. I think the behaviour of "probe-while-moving" should be swiched on and off by user in g-code.

I am trying to run the original sub routines by orangecat for M6 and M600 but the calculations aren't adjusting appropriately for setting G43.1 Z

Is there a way I can see what the global named parameter value has been set to? I can't find a way to see what is being set to double check the math and figure out why it's not working.

Also, does variable #5063 record the value for Z in machine coordinate or the active WCS at a triggered probe?