Inconsistent values from Versaprobe

Ok, here's the latest update.

Text from the log file:
[QTvcp.QTVCP.WIDGETS.GCODE_EDITOR][ERROR]  load_text(): [Errno 2] No such file or directory: '' (gcode_editor.py:338)
[QTvcp.QTVCP.WIDGETS.DIALOGMIXIN][DEBUG]  Setting ToolChangeDialog-geometry dialog geometry from from prefs. (dialogMixin.py:127)
[QTvcp.QTVCP.WIDGETS.DIALOG_WIDGET][ERROR]  No callback or STATUS message specified for: toolDialog_ (dialog_widget.py:317)
qt.qpa.xcb: QXcbConnection: XCB error: 3 (BadWindow), sequence: 12756, resource id: 9629954, major code: 40 (TranslateCoords), minor code: 0
USRMOT: ERROR: invalid command
Linear move on line 277 would exceed Z's positive limit
Linear move on line 277 would exceed joint 3's positive limit
invalid params in linear command


The images I am attaching honestly make little to no sense, rather the values in the images.

 


 
 

I did some more testing and milling and everything seems to work for me know. There are some differences to your setup: this is how I measure the tool 

    #<touch_result> = #5063
    #<setterheight> = #<_hal[qtversaprobe.probeheight]>
    #<blockheight> = #<_hal[qtversaprobe.blockheight]>
    (print, #<touch_result>  #<setterheight>  #<blockheight>)
    ;(DEBUG, %fTouch Result: #<touch_result>)
    ;(DEBUG, %fProbe Height: #<_hal[qtversaprobe.probeheight]>)
    ;(DEBUG, %fBlock Height: #<_hal[qtversaprobe.blockheight]>)
    ;(DEBUG, %fnewtool: [#<touch_result> - #<_hal[qtversaprobe.probeheight]> + #<_hal[qtversaprobe.blockheight]>])

    G10 L1 P#<newtool> Z[#<touch_result> - #<_hal[qtversaprobe.probeheight]> + #<_hal[qtversaprobe.blockheight]>]
    G43

Whole file can be found here . Main remap is base on user Guihue and versaprobe macros for axis  adopted to my needs in qtdragon. 
github.com/zieluch22/sorotec_cl0604/blob...cros/rack_change.ngc  
From ini check section 
[RS274NGC]
#PSNG parapeters
RETAIN_G43 = 0
INI_VARS = 1
HAL_PIN_VARS = 1
SUBROUTINE_PATH = macros 
RS274NGC_STARTUP_CODE = G17 G21 G40 G43H0 G54 G64P0.0127 G80 G90 G94 G97 M5 M9
and I am using python3. 
whole file 
github.com/zieluch22/sorotec_cl0604/blob...d_sorotec_cl0604.ini  

hope you can find something and you can enjoy the software.

Based on this single probe attempt, what is causing the VAR _z to be -364.743 that I have highlighted in RED below?
All I did was turn on the machine and home it.

 --- QtVCP Screen Started on: Sat, Dec 28 2024 11:48:10 AM ---
 --- QtDragon_hd Version 1.5 on Linuxcnc 2.10.0~pre0 ---
 11:48:11 Machine OFF
 11:48:11 Hard limits tripped
 11:48:11 Tool 0: No Tool
 11:48:32 Machine ON
 11:48:57 Hard limits tripped
 11:48:57 Hard limits tripped
 11:49:04 Hard limits tripped
 11:49:04 Hard limits tripped
 11:49:09 Hard limits tripped
 11:49:09 Hard limits tripped
 11:51:28 Loaded tool 99
 11:51:28 Tool 99: 3D Probe
 11:51:37 Cannot switch pages while in AUTO mode
 11:51:43 Versa Probe: Start Cycle: Go to Tool Setter
 11:52:52 Versa Probe: Start Cycle: Probe Tool Setter Z Height
 11:53:21 HISTORY Tool Setter height Z[-132.446]
 11:57:20 Versa Probe: Start Cycle: Probe Z Height of material
 11:57:30 HISTORY Probe Material Top Z[-94.743]
 11:58:07 Loaded program file : /home/andy/uploads/Tool-change-TEST-2.ngc
 11:58:07 Loaded file /home/andy/uploads/Tool-change-TEST-2.ngc
 11:59:59 Saved: /home/andy/uploads/Tool-change-TEST-2.ngc
 11:59:59 Loaded file /home/andy/uploads/Tool-change-TEST-2.ngc
 12:00:34 Started program from line 1
 12:00:38  

---

Program Begin PROBE

---

 12:00:38  Current Coord System: 540.000000
 12:00:39  G43 Tool Offset:  0.000000
 12:00:39  Current Selected Tool: 36.000000
 12:00:39  Current Selected Pocket: 36.000000
 12:00:39  Current Tool Loaded: 99.000000
 12:00:39  Current Tool Index:  99.000000
 12:00:39  Orig Tool Z position local_start_z: 364.743000
 12:01:59 Tool 36: Sharpro SPWS2LXD3.22 Down cut 1/8" Shan
 12:02:33 Run timer stopped at 00:01:59
 12:02:33 Tool 36: Sharpro SPWS2LXD3.22 Down cut 1/8" Shan
 12:02:33  

---

FINAL PROBE BACKOFF

---

 12:02:34  Z value detected 5063: 217.447440
 12:02:34  Setting tool 36.000000 Z to 255.144440
 12:02:34  

---

FINAL PROBE

---

 12:02:34  Current Tool Z Offset 5403: 255.144440
 12:02:34  Probe Height: -132.4400
 12:02:34  Block Height: -94.7430
 12:02:34  Probe Result: 217.4474
 12:02:34  5063        : 217.4474
 12:02:34  Tool          : 36.000000
 12:02:34  5400          : 36.000000
 12:02:35  Return to original tool-tip position using new z-offset: 45.666690 , 95.252380 , 364.743000
 12:02:35 Linear move on line 271 would exceed Z's positive limit
 12:02:35 Linear move on line 271 would exceed joint 3's positive limit
 12:02:35 invalid params in linear command
 12:02:35 Abort Parameter is [3]
 12:06:48 Machine OFF
 

So  I just did a Linux watch on the linuxcnc.var file for each change. 
Immediately after I loaded the NGC file the #5223 changed to the -364.743 value. I had previously set
the value to zero before I started linuxcnc.

This is the NGC file that I loaded is as follows:
%
G90 G94 G17 G91.1
G21
(G53 G0 Z0.)
(FACE1)
T36 M6
S12000 M3
G94 G4 P8.
G17 G90
G54
G64 P0.001 Q0.001
M8
G0 X188.156 Y-1.472
Z15.
G0 Z5.

G17
M5
G53 G0 Z0.
(Move Z all the way to the top)
M30
%

Anyone else having this problem?

I sm having the sams or similar issues.

I am very new to LinuxCNC and the versaprobe routine is very different from what I used to do as a "professional" on Haas, Okuma, Mazak, et.al.

I follow the documentation and touch off to the tool setter, then the top of the workpiece.
Then, set G54X0Y0 with the probe.
Then start the program and it touches off the tool, returns to Z safe height, moves to the first X and Y coordinate, then errors complaining about the next Z move being out of bounds.

From my previous experience, I would think that it would just be easier to use the probe touch off on the tool setter to set a reference plane. Then touch off on the G54 Z0 point. That would set the difference between the tool setter and G54 Z0.

During the program, it would touch off the toolsetter, then add the offset from that to G54 Z0 and calculate the proper tool length. Call length comp to store, then make chips. Basically mimic setting tool length by hand and storing the offset in the table manually.

Altertively, with the known offset to the tool setter, it could just as easily use G92 Z-15.0 (or whatever the offset between the tool setter and G54Z0 is), although that would likely make Z0 dance around based on tool length, so I don't really like that option.

I am not sure if that's what it's actually trying to do or not. As I said, still pretty new.

If there's anybway I can help, let me know.