qtdragon - probing issues

Could you please show what that looks like with versa probe ????
and that is the HD version, right?

Yes to HD version.
I haven't done anything with versaprobe. Chris has done a lot of work on it and it will be up to him to decide what new features it will have. The good news is that the majority of the code supports both versions. The only real difference is the UI and code that handles the UI. The subprogram and probe routines are the exact same python files for both.
Jim

I wouldn't find the popup useful.
I heard an argument why G38.4 would be more accurate and it made sense but I have never tested it to see if there was a detectable difference. Having the option for either would be nice.
This version looks good too. I like the Jog buttons.

Thanks Jim
John

persei8 wrote:

BTW, the start point is indicated by the purple dots and the green targets are where the probe tip will be after probing.
- is there a big advantage in using G38.4 as opposed to setting the retract distance small, like 1 mm? Should it be optional?
Jim
​​​​​​
 

Thanks Jim.
You've confirmed what I've maintained al along that Chris is wrong in his thinking that the start position is the green dot. This I think is a source of a lot of confusion and possibly wrong code. It also shows what I also maintained the purple dot is in the wrong position for inside corners (I have not looked for a while).

We don't want popups, just clarity in the docs and the images.

Re G38.4 it eliminates the gcode to to back away from the surface and reprobing so the code is cleaner and there are less configuration variables, not to mention faster. It's what we do with plasma probing. Even a probe will have hysteresis and overtravel before it triggers and stops motion. If you think about it, using G38.4 will not trigger (on lost contact) until the probe is in a neutral upright position. So yes it has to be more accurate.

I suspect some of the code has it's origins in Mach3 where G38.4 does not exist. But Linuxcnc is smarter than that, don't neuter it through ignorance!

So are you saying that with G38.4 there's no need to retract after the first contact and then reprobe at a slower speed? If so, I can see how that would speed things up although the savings in code would be insignificant. I assume then that linuxcnc knows that when it's doing a G38.4 MDI command, it should trigger on the falling edge of motion.probe-input?

persei8 wrote:

So are you saying that with G38.4 there's no need to retract after the first contact and then reprobe at a slower speed? If so, I can see how that would speed things up although the savings in code would be insignificant. I assume then that linuxcnc knows that when it's doing a G38.4 MDI command, it should trigger on the falling edge of motion.probe-input?

Yes, on initial probe contact you immediately probe away with G38.4. You can do this super slow as its ony moving a 0.2mm or so.But the other advantage I see is that there is no chance the probe going the wrong way which I often experienced with the current algorithm (whether that was due to a user error or a bug). And yes if you read the docs G38.4 triggers on a falling edge. Forget the time savings and think about the accuracy. Also, there is no need to define how far to back off so there are fewer user fields. You can do some tests with the MDI. The results will be different but I thnk the 2 step probing has to be more accurate.

Remember that a lot of users me included know nothing about probing so the simpler it is the better.

If I calibrate against a metric 123 block, the results are undersize. It would be interesting to redo with 2 stage probing and see how close it gets. Thats really how to test for accuracy between methods.

Actually looking at the docs G38.5 would be better becasue we know it will break contact as its just made contact
REF: linuxcnc.org/docs/2.9/html/gcode/g-code.html#gcode:g38

In my head it looks like this

 

"If I calibrate against a metric 123 block, the results are undersize. "
That's probably because the current probe routines don't implement the calibration routines. (well, the probing runs but no calibration offset is calculated) I have added it to my version and I get results within about the same accuracy that I can measure with a digital caliper. 
I will implement G38.4 or 5 and report results, probably next week.
Jim

Thanks. Whilst the probe routines may not use the calibration results. You can see or calculate the size of an object on the calibration screen. This is where I was looking.

In the past what I had been doing to calibrate my probing was to change the probe tip diameter to represent its' effective size. I would probe a 123 block and tweak the diameter until it match the block size. One side might be under or over by .0001 because I only had one number to tweak for X & Y but that was closed enough for hobby work.