Probing with a 3d probe and toolprobe on the same input

[Klippert]

Hello,

I've previously sucessfully run a toolprobe (tool length sensor) and a 3d probe on the same input.
Now i don't know if anything changed in recent versions of grbl hal, or i'm just getting it wrong, but i just had a part where i'd use the center of a hole to locate it for the 2nd op milling (flipping it over) and I probed with my 3d probe to get the centre of the hole as well as i could. I got a repeatability (by looking at the machine coordinates of 0,01-0,02mm) Good enough for me - but to my great surprise i ended up with an Y offset of about 2mm and a x offset of about 0,1mm.

This is a breakdown of what i did:

1. Mounted the part, so it wouldn't move. (very securely - i'm conviced this is not the source of error.)
2. Inserted the probe and tested that it works by triggering it with my finger.
3. Went to approximately right over the centre of the hole, keeping Z about 50mm above the material.
4. Go to centerfinder under probing, and set a profile for my probe that doesn't have the same 170mm seek-travel as my tool probe has. The hole is almost 80mm diameter, so i set the 77mm size in the config to feed a little longer.
   See config:
   
5. did a probing with preview
6. did a probing about 50mm above my workpiece, which strangely enough ran without errors. It only probed air, but it seems like it was "happily triggering" itself at some distance away - i expect this is some sort of overtravel protection, but i can't say i understand it. If i triggered the probe by hand while it was moving i'd get an alarm (4?) and things would stop. unlike what i expected.
7. After a deep breath i lowered the Z, and to my great surprise it triggered correctly on the edges of the hole.
8. After a few tries, verifying the machine position was the same, i went and took out the probe and ran the job.
9. and I missed the mark :-0

One thing, i had doubts about, is if i should use G52 or G54. But as i set the G54, the probe lands itself in 0,0 (x,y) on the DRO display.
I did experiment with the G52 offset once, but reset it

Any help is most welcome,

Best
Kristoffer

[terjeio]

Can you try the attached version? It seems there is a concurrency issue at play that I have never seen on my development machine that causes a probing sequence to continue even after a probe fails .FYI I am away from home for a while and on a laptop so cannot fully verify the changes I have made so test carefully.

ioSender Edge 2.0.45p9.zip

[Klippert]

Hello Terje,
Thanks for the new build despite your being away - I finally got the time to test it out.
It would seem there is still an issue going on, or I just don't remember how to use it correctly.

Here goes my shot at explainign.

1. I set up my probe in the new version as usual.
   
   Did a centerfinder internal, and moved to what looked center-ish.

This first gave me this run:

first.run-converted.mp4

which seems to end up pretty centered. - though i didn't start visibly worse off center, so it might have been a fluke.

2. I then tried with two runs, which only gave me one run?

2nd.run-converted.mp4

3. i then moved the "hole" that i was probing, to see if the off center thing was for real.. and did a third run:

3rd.run-converted.mp4

So, now my question is, am i doing something wrong or is there an actual bug?

Thanks in advance, and any help is most welcome

Best
Kristoffer

[terjeio]

It is hard to tell what is going on from your videos.
What is displayed in the status line (at the bottom of the sender window) when probing is finished?
Can you enable verbose logging in the console, clear it and post the log after a probe?

[Klippert]

And as luck would have it, i've switched back to io-senderXL, and i now can't reproduce the problem. I could be something between the special build one you gave me, and the ordinary one. Alternatively i'll have to experiment more. But two seperate probings worked sucessfully now. also the number of repeats worked.
I could do more probing with the build you made, to see if it's something there?