qtdragon - probing issues

I understand. June 10 is Bookworm's release date. I'd love to see 2.9 in it...
I'm not sure I was thinking of just small holes but I got no experience with this stuff.
2 sounds better. I can't even probe a hole 5 x the diameter of my 2mm probe.
I think on XY clearance = 0 because you need to be able to set some reference to set the back off distance under present algorithm. The diameter would let you do that. (say 0.25 x diameter?) 
 

guys, probing is definitely complicated, and scary with expensive probes.....
using the old Probe Screen v2, I was able to probe holes as small as .50 inches with a 3mm probe end. it took some doing to adjust the parameters, but it did work. Serguei used both python and gcode. but the gcode was fairly simple. there are only 5 gcode macros.
I've looked through and looked at the current VersaProbe and BasicProbe routines in qtvcp, and it's way complicated, including multiple levels of Py code.... This may not be bad, but it makes it all difficult to follow and debug.
I'm a firm believer of KISS (the good old keep it stupid simple).....

I'm help when and however I can. I was unable to do RIP on my little mill.
It's on bullseye, and Seb's master deb with a 4.19 rt.
I have a few extra ssds, so I can create a totally separate test install.
Which debian version, and linuxcnc version should I use?

chris, you commented on a line in the probe routine as '<<seems wrong' and you are absolutely correct there. that moves the probe way too far from the next edge.

not sure if you recall, but Chris Radek created a good hole probe routine, p_hole.ngc, which has been used as a base for several routines since then, including for ncggui. probe_hole6.ngc. forum.linuxcnc.org/40-subroutines-and-ng...e-for-center-of-hole

So let's keep working this to get it right and safe.....


maybe I'll start here.....   forum.linuxcnc.org/9-installing-linuxcnc...g-installation-notes

well, believe it or not, I made a new install on another ssd, and actually got an RIP to compile.
Rod, I used your direction above on the git clone and branch.
But, how do I know what actually compiled?   the first clone or the branch???
and how can I tell if the branch with the error fixes is actually running....???
 

Great work, its simpler than it looks!
I think this should confirm the branch
My machine runs Bullseye too so there is no reason to change.
Chris has been working on the 2.9 branch so when he merges this branch remember to(The default branch on an initial clone is master branch eg 2.10)
Re version, just trust git, it tells you the branch you are on when you git checkout <branch>

My instructions show how to build a Deb. That takes a long time.
A RIP build is covered in the Linuxcnc developer docs. basically once the dependencies are installed
Now we need to set the environment so linuxcnc looks in your linuxcnc-dev folder
(the leading fullstop and space is critical)
Now if you run linuxcnc normally IN THE SAME CONSOLE WINDOW, you get the RIP
Closing the window, destroys the RIP until you run rip-environment again.

If you have installed a Deb you built you may not be able to run rip-environment.
If that's the case uninstall the deb, something like
[/code]
sudo dpkg -r linuxcnc-uspace
[/code]
And reinstall one of sebs debs
Then the RIP will be happy.

I think it's a good thing to bake the probing in once it's debugged with tears and broken probes.
I agree there is only 5 probe types My observations are:
There is redundant code on the corner probes. They should call the primitive 5!
Using G38.4 would substantially simplify the probing, eliminate a lot of code and speed up the process.

It seems like the the original probing came stuff running from Mach3 or some other less sophisticated gcode environment. Linuxcnc is smarter so we should use those smarts! (eg G38.4)

Forgot to say I hate redundant code!
Once 2.9 is released, the 2,9 branch will be locked from further development (except bug fixes)
Development will move to master branch (where it should always be)
Custom branches might still be used and you will be able to return by 
[/code]
git checkout master
[/code]
It's just Chris is working hard to get all of our changes into 2.9 In case the release happens tomorrow.... or the next day ... or....

thanks.
I installed the new on bookworm. but that should be ok.
Now I will bring the ssd out and get it running on the mill. network stuff is the toughest, but I think I can get it as the current one works and i'll just copy a lot of stuff. Same with the configs and all. Hopefully I'll get the _fix to work.

probably have to do a pull, and check out branch again. then make all over.....no worries.

Seb's debs stay up to date pretty quickly with pushes to master and 2.9, like a day or 2. Cheers to Seb.
And ya can always look for the changes in the listed in the .changes file in the debs directories.

 

rodw wrote:

Ok, Back on topic!

Chris,
I've been through all of the basic probe routines except inside corners and edge angle.
there is  a regression on the height probe as its adding the extre depth in again

 

So I repulled and started testing again. It does look like I forgot to run the rip-environment script yesterday...
So the regression was mine!

ok hole probing will calculate if it should skip rapid positioning.
It also does some basic error calculation to make sure (if it skips rapid positioning) that the max probe length is long enough.
Oh and if diameter hint is smaller the probe diameter a error message appears.
and if probe finishes, the history output shows in the statusbar.

and changed the calculation for long side probe to:
(2x radius) - latch_return- xy_clearance
instead of:
2x (radius - xy_clearance)

Ok, definitely on the right branch now but before any of the changes you just mentioned.

Used a piece of 50mm square section which lets me do inside, outside, ridges and valleys


Tested Basic Probe only 

Outside corners all OK
Inside probe in general.
The probe lowers into pocket, commences movement in the oposite direction to the first probe before starting to probe. Makes no sense. Should just lower and stat moving the right way

Inside corners, inside pockets, ridges and valleys.
When contact is made the second and final time, the probe goes the wrong way (eg toward what it just probed and hits the side again in a non-probe (is this related to the commencement bug above?

Have a look at those and I will retest it all tomorrow.

Can you post a pic of the settings on the probe page?
I don't see a back off before first probe move in my tests but maybe it's setting defendant.

I'm concentrating on the probe inside hole code ATM.