Inconsistent values from Versaprobe

Thanks for your reply.

I find it almost hard to believe that there's only two of us on the planet that are encountering this issue.

Do I need to change from Versaprobe to Basic Probe? Are they the same? Have same features, etc.... ??

 

I remember we had a similar problem with a toolchange remap a long time ago.

The toolfile would be written to and then read back as part of the process.
The problem was that the OS would cache the save sometimes and the toolchange failed intermittently.
We used os.fsync() when modifying the tool table to fix this.

This sound similar to your investigation.
I don't know linuxcnc's internals enough to know if this is a possibility.
I wonder if just adding commands between G10 and G43 would help?
I'm not sure what commands cause a tool sync.
The fact that this sometimes works makes it a very difficult case to debug and also possible that only a few suffer from it.

I am certainly willing to test it.

I would suggest that we either fix VersaProbe or remove it completely from the project as it's really annoying to not have this working
as expected.
 
I can also move over to Basic Probe but I'd need some of the documents cleaned up as to what is to actually happen for each
button/control. Some controls are documented but, other controls as well as their functionality are not.

I'd be more than happy to work with you and even document the process for the project(Linuxcnc).

Send me some ideas and I can act on them.

Chris,
I'm not sure that the calculation is is correct. I see the tool table file being written to but, the offset is incorrect.

For example, take this line:
T42  P42  D+12.700000 Z+290.403761 ;SpeTool Spiral .5" Shank .5" Dia 2" CL

I first zero'ed the above line, measured spindle with 3d probe. Then the "Z" probe fails multiple times before the gcode starts correctly. The above line was after the multiple probes and the gcode started running.
My "Z" can only travel somewhere around 120mm based on it's current configuration.

Here's another tool table entry:
T28  P28  D+3.175000 Z+12.349993 ;Whiteside 1/8" RD1600
This is what I would expect to see(Z+12.349993).
However I probed multiple times on that one also.

I did look at the code and there is an os.fsync on line 335 of qt_tstat.py which is located in def _save()
There's also comments to this perhaps causing "odd errors".

I'm thinking that maybe the FLUSH before the FSYNC might be causing this?

 

I've also continued testing and haven't made any progress.

and the m6 doesn't work under basic probe. It always tells me that the pin  #<_hal[qtversaprobe.searchvel]> doesn't exist.

I suspect that I may have found out what is going on.

I was reading thru the setup instructions in the qt_auto_probe_tool.ngc file being careful not to
"read-thru" anything that I may have missed. This sentence caught my eye:

The following workflow assumes using both a XYZ probe and a Z Toolsetter:
;    1 - Initial Setup: Before beginning the program, setup the Probe Tool as 
;        having a zero z-offset in the tool table.

My tool table file did not have an entry for the Z-Height of zero. So I added the entry as follows:

T99  P99  D+2.000000 Z+0.0 ;3D Probe

I started the test program that I had and everything worked as intended/expected. However, as it was getting late in
the evening when I tested I tested with a much shorter end mill than my previous tool which was the longest mill in my
inventory. Today, I will retest with the longer tool and report results. I'll have to look in the code and see if I can find where
the tool Z is picked up and see if there's any room for improvement if this is indeed the problem. Hence, if the probe Z has no value,
then assume zero?

 

Basic Probe and Versa Probe are two different programs.

It appears to me that Basic Probe has fewer options than Versa Probe.

The documentation for the two should be separate as to not confuse the reader. I see if I can add some value to the docs.

gardenweazel wrote:

Basic Probe and Versa Probe are two different programs.

 

I know that there are two different ones. I just wanted to check whether the error occurs there too

gardenweazel wrote:

T99  P99  D+2.000000 Z+0.0 ;3D Probe
 
 

my tool table looks like this:

T1 P1 X0 Y0 Z0 A0 B0 C0 U0 V0 W0 D2.00000 I0 J0 Q0 ;touch probe

Z0 is included in all of them. When changing tools to a new tool, strange Z values ​​occur which are then entered into the tool table at Z when the tool is changed.

The new milling cutter then has a value of 155.34 at Z and then wants to travel 214.45, for example.

even though my maximum travel distance is only 145 in Z