Manual tool change + tool lengh touch off

diep wrote: I do not know how to merge the gladeVCP example of manual-toolchange-with-tool-length-switch/ into the defines i had made for the machine in linuxcnc/configs/3040ext/ + configs/3040ext.stepconf

The GladeVCP panel exists only to simulate the probe trip, for use with a simulated machine.
A real machine should not need any of that.

What you do need is the remap routine (ngc) and the INI file entries.

I have been testing OrangeCats manual tool change routine and ran into issues I didn't understand - primarily this:

"Linear move on line 128 would exceed joint 2's positive limit"

This error popped up after a new tool was inserted and the height probing complete. But not in a consistent way, and that puzzled me.
I therefore modified the subroutine by inserting some (print, ..) statements. See the attached file.
I then did this:
1) Start LinuxCnc from the terminal, so I can watch the output from the print statements
2) Home the machine (now at (0,0,0))
3) From MDI run: M600 and then M0 T6 (I leave the tool in)
The first probing sequence is executed and the spindle returns to its original position (0,0,0). The print output is:
First tool change
G38.2 Z[-128.000000 - -10.000000] F[400.000000]
Trip point _ToolZRef = -24.113033
4) I load the .ngc file with the cnc project I want to run
5) Manually move the spindle to the workpiece and touch off all axes. The print output is:
First tool change
G38.2 Z[-128.000000 - -10.000000] F[400.000000]
Trip point _ToolZRef = -32.790000
First tool change
G38.2 Z[-128.000000 - -10.000000] F[400.000000]
Trip point _ToolZRef = -32.790000
First tool change
G38.2 Z[-128.000000 - -10.000000] F[400.000000]
Trip point _ToolZRef = -32.790000
First tool change
G38.2 Z[-128.000000 - -10.000000] F[400.000000]
Trip point _ToolZRef = -32.124133
6) Press Run to start the program. Linuxcnc prompts me to change to the first tool. Since the correct tool is in the spindle, I leave it in.
The probing sequence starts. The print output is:
ToolDiamMM = 4.000000
G38.2 Z[-128.000000 - -10.000000] F[400.000000]
Old tool length = ######
New tool length = -23.671500
G53 G1 F[500.000000] Z[0.000000 - -24.113033 + -23.671500]
USRMOT: ERROR: invalid command
Linear move on line 128 would exceed joint 2's positive limit

The problem is clearly that the last G53 command wants to move the spindle above Z0 (valid range is -130 to 0).
Even though it is the same tool in both probing sequences, the small difference (actually rather large??) between two readings may result in the addition of a positive number. This combined with the fact that variable #5183 apparently always is zero (also if I move the z-axis down after homing and before step 3 above).

My two questions:
1) Why is #5183 always zero?
2) Why is the tool-change.ngc subroutine executed when the touch-off button is pressed? (The "First tool change" output is seen multiple times and "_ToolZRef = -32.790000" is printed
at each touch-off button press, even though the z-axis doesn't move. Don't understand where this value comes from?

What am I missing here?

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

Is the probe tripping on a non-probe move?

By which I mean, are you saying that path #1096 was wrong, or that there is a problem with the touch-off code?