Inconsistent values from Versaprobe

Yes, this is what I noticed as well. I believe that the linuxcnc.var file is incorrect and the later gets written to
with an acceptable value within range.

I followed the code during this time to confirm. I'm just not sure where the initial value is being set?

Thanks for chiming in, hopefully this can get remediated sooner rather than later.

Posting some additional debug details in anticipation of getting some resolution.
This is from a single job that I ran yesterday. Exact same job run 3 times, as you can see there were 2 failures
and finally on the third try I was successful.

The second FAIL and the PASS are nearly identical.

Please chime in if you have any clues. I am using the subroutine from qt_auto_probe_tool.ngc

  

Not sure If I bring anything but :
once you start machine and load tool z offset is present ?
I have problem with G43 on the first time after starting machine. Even my macro for tool change issue G43 after program is executed z offset disappears. Once I manually issue G43 everything is working than fine.

I have no idea how I can track what is causing this problem
my workflow :

Start machine
home all XYZ
load Probe (M6 T99) , during subprog execution z offset is visible for split of the second and than disappears)
G43 manually from MDI - offset now visible 
Probing part and zero G54
M6 T1 -all offsets are correct, if I don't issue manually G43 all the offsets with all the tools are messed up later on.


 

Hi,
Thanks for your feedback! Based on what I am seeing this appears as if its an issue with the G43 and G49 entries in the gcode.
Which is why I included a copy of my gcode in one of the posts in this thread. There are both G43 and G49 code changes in the qt_auto_probe_tool.ngc script.
I suspect that there may be some quirks that might be disabling/enabling these two codes.

Strange enough is the value of #5070 probe fail/succeed passes each time with a one(1) succeed.

I have not even tried(recently) to do a tool change in mid code(other than the initial beginning tool change) for fear of crashing, etc...

Its also worth noting that the post processor for Fusion 360, EMC2 in my case doesn't inhibit the call to G43 despite having the following two lines in my PP script:
outputToolLengthCompensation: false,
outputToolLengthOffset: false

To further complicate things, I've also noted that using tool number zero as my probe doesn't seem to work very well. I've moved my probe to tool number 99 as of now.

It would be nice to hear from some of the seniors as to their take on this issue.

Agreed on the "probe succeeding".

I added this in order to see what is taking place:
'Return to original tool-tip position using new z-offset: ...'

I've noted from the script that:
#<touch_result> = #5063
which equates to 277.16xx in this case. Fairly consistent thru the 3 attempts.

I'm attaching the script as I have it now including the extra debug messages.

It's worth noting that immediately after the second touch-off the program aborts. There is no movement for any axis.


 

Understood, Here's the lines where I suspect may be problematic, these are all after the touch-off:
#<touch_result> = #5063
#<calculated_offset> = [#<touch_result> - #<_hal[qtversaprobe.probeheight]> + #<_hal[qtversaprobe.blockheight]>]
G10 L1 P#<tool> Z[#<calculated_offset>]
G43
(DEBUG, Return to original tool-tip position using new z-offset: #<local_start_x> , #<local_start_y> , #<local_start_z>)
G53 G0 Z[#<_ini[VERSA_TOOLSETTER]Z_MAX_CLEAR>]
G0 X[#<local_start_x>] Y[#<local_start_y>]
G0 Z[#<local_start_z>]       <

---

LINE 244

The last line above is line 244.

The G53 call I have as -5 in my ini file. Which is an absolute call as I understand. The local variables are just that and
do not change when the sub runs.
The calculated_offset is consistent throughout the sub so that can be ruled out, I believe?
That leaves these two lines:
G10 L1 P#<tool> Z[#<calculated_offset>]
G43



 

I noticed that the following code appears well into the SUB:

o300 if [#<_hal[qtversaprobe.enable]> EQ 0]
   (MSG, Auto Tool probe disabled )
    G43 ;turn back on tool offset mode before returning
o300 return [3] ; indicate no tool measurement
o300 endif

Actually, after the first M6 in the code. If I'm reading this correctly, the IF statement gets evaluated when TRUE.
If this is the case then why would it not be at the very top of the SUB? The reason I ask is because the line above this block is a 
call to G49 which cancels tool length compensation. Meaning why bother to even begin the sub if it's not enabled?

That said, this return code of 3 shows up as the abort parameter in both of the failures.

Any feedback or thoughts what-so-ever are encouraged.