qtdragon - probing issues

Actually, that's exactly how the basic_probe calibration works, but it's done automagically. First it probes the calibration object as usual and then does it a second time but starting from the calculated center point. Then it compares what it measured to what it's supposed to be and adds an offset to the probe tip diameter so that the probed result matches the expected result. The error can be averaged for X, Y or XY dimensions. Normal probing routines will then use the probe tip diameter plus the calibration offset value. Of course, the accuracy of the results depends on several other factors not related to probing. That part is up to the machine operator.
Jim

Jim, John, Rod, and Chris,
thanks for continuing the work on the probing.   it's very important for accurate work, and not destroying probes.

on the double probing, I figure it's like homing to an encoder index mark, not just a switch by itself.   so finding an approximate point on the first probe, and then a more accurate point on a slower approach is fine.  with lower speed other factors are probably reduced, like following error, accel/decel lag, and even system computation time...... and don't forget probe mechanical factors.....(flex, sticktion, etc.)

As for G38.2 or .4 or .5,  I don't at present have a definite educated opinion.   It could be very system dependent.

Now, calibration.  super important.  I've lost track of the hours I've spent trying to center my probes.  what a PITA.  Even now I try to put the probe back in the spindle facing the same way as is was when I centered it....   A good calibration routine would be invaluable, and should be used by the probing routines.  of course, this could be optional.
I too use a 1-2-3 block to test on, and also a new, good size, quality bearing (for inside dimensions).  And I have adjusted the probe diameter to 'calibrate' the system.

Versa_Probe vs. Basic_Probe,   not sure if it really matters.   I ran the original Versa Probe v2 for a lot of years and got very used to it, and trusted it.  So it may be more time and effort efficient to concentrate on one of these rather than both.  pick one....it's ok.

And finally, the documentation.  Critical.  Probably best done when everything else is worked out, just to minimize duplication of efforts.

Not being a programmer, I'm not much use in the actual programming, but I can definitely help with testing, and maybe even some documentation....

Thanks again.
Noel
 

I have a Hallmark ITTP Probe (Impact Tolerant Touch Probe). So far I haven't wrecked the tip.  If I am really unsure I will probe a piece of styrofoam first.
hallmarkdesign.co.nz/probe

John

I was playing around with making changes to /usr/lib/python3/dist-packages/qtvcp/widgets/probe_routines.py. I started getting errors so I put it back the way I found it.  But, its still broken.  When I try to probe Z (that's all I have been trying) It does nothing.  When I check the status page it says Cannot switch pages when in AUTO mode.  If I start from the command line I am also seeing the following.  Not sure that is even related.
libsub: error [udev_hotplug_event] ignoring udev action change.

What would be the easiest way to just start over with the latest QTDragon_HD and basic_probe?
John

Probably reinstall linuxcnc from debs.
This explains how to do it for Bookworm
 linuxcnc.org/docs/2.9/html/getting-start...etting-linuxcnc.html
If you are on Bullseye change bookworm to bullseye on this linesudo echo "deb buildbot2.highlab.com/debian/ bookworm 2.9-uspace" | sudo tee -a

I'm using Bookworm and 2.9. I'll give that a try.

Thanks Rod.

I loaded the latest version per Rods instructions. Probing is now somewhat working.

What I am seeing now is when probing Z, the initial probe is VERY slow. After it makes initial contact the probe backs off at (PROBE RAPID) and then probes at (PROBE SPEED).

I have also notice that the touch screen randomly stops working but the mouse clicks still works. Some times I will push a button and LCNC just exits.

I was able to get this from a report during a failure:
[QTvcp.QTVCP.WIDGETS.BASIC_PROBE][[36mINFO[0m] Basic Probing routine completed without errors (basic_probe.py:231)
[QTvcp.QTVCP.WIDGETS.BASIC_PROBE][[36mINFO[0m] Probe Process finished - exitCode 0 exitStatus 0 (basic_probe.py:212)
libusb: error [udev_hotplug_event] ignoring udev action change
libusb: error [udev_hotplug_event] ignoring udev action change
libusb: error [udev_hotplug_event] ignoring udev action change
libusb: error [udev_hotplug_event] ignoring udev action change
libusb: error [udev_hotplug_event] ignoring udev action change
libusb: error [udev_hotplug_event] ignoring udev action change
libusb: error [udev_hotplug_event] ignoring udev action change
libusb: error [udev_hotplug_event] ignoring udev action change
libusb: error [udev_hotplug_event] ignoring udev action change
libusb: error [udev_hotplug_event] ignoring udev action change
/usr/bin/linuxcnc: line 977: 9020 Segmentation fault $EMCDISPLAY -ini "$INIFILE" $EMCDISPLAYARGS $EXTRA_ARGS
libusb: error [udev_hotplug_event] ignoring udev action change
libusb: error [udev_hotplug_event] ignoring udev action change
8970
9016
Stopping realtime threads
Unloading hal components
RTAPI_PCI: Unmapped 65536 bytes at 0x7f0394bdd000
Note: Using POSIX realtime

I think the Segmentation fault is the most concerning here.

I also got a QTVCP error in /usr/lib/python3.11/json/decoder.py line 340, in decode. Extra data in Line 2 column 1 (char 199)

I'll keep playing and gathering data.

John

I'm using a BAT1-J1800 with a USB pendant and an ASUS USB touch screen. I never had this problem with 2.8.4. I think I am running Ubuntu Mint 19.3 on that SSD. I 'm just swapping SSDs to go between my working machine and the new setup I am testing.

I could test without the pendant since the screen jogging works. I am also not sure that when I say the touch screen doesn't work that it is an across the board thing. I check for that the next time I am testing. I also noticed that sometimes I just have to push the button a little longer. Usually a quick tap is all it takes.

Your PC is clearly not happy with its USB side of things.
lsusb is nothing to do with Linuxcnc
Seems like a USB device is being disconnected randomly (hotplug)
If there is a hardware fault, the slow performance could be explained by spurious interrupts.

If your J1800 has a Baytrail chipset, there is a long standing linux bug with spurious overtemperature errors.
I would have thought it should be fixed in  kernel 6.1