qtdragon - probing issues
If the entered probe data is meant to always be in machine units. then the probe routines should check that linuxcnc is in the proper units before starting probing. ie metric machine should probe in g21.
I don't think qtvcp's routines checks that.
What really should be done is (I think):
record the current machine units before probing
switch if (required) to machine units for probing
switch back (if required) to recorded units.
Error catching makes this more difficult as linuxcnc is not good at allowing a routine to 'reset' things at error. It's one of the reasons we use complicated python routines in qtvcp.
There is m70/m72 that can do the recording/restoring, not sure how it works with errors.
It would be super useful if modes could be set directly from python code...
Does this seem right/reasonable to you?
Lets try adding detail.
rodw post=271209 userid=20660Sorry,
When I look at what I said above, the diagram related to inside corners.
OK, I see your point with the start move.
But it does not excuse the probe going the wrong way after the second touch off and causing a probe error while not probing.
It does this when its found the first edge.
Lets discus inside probing using the top right button in basic probe (back_right_inside).
The most important settings to change:
XY Clearance -distance away from edge before rough probing
Z Clearance -distance from probe to top of material
Extra Depth -distance to lower probe from top of material
Edge Width -distance along edge (away from corner) to start probing.
manual set probe at the intersection of the edges (ie corner) of material as described by the green bullseye on the button. Set it Z CLEARANCE above the top of material. These can be done by eye.
set EXTRA CLEARANCE to a value that you want the probe to go below the _top_ of material.
(So the probe will move from it's start position down Z Clearance + Extra Clearance distance)
set XY CLEARANCE to a value that definitely gives clearance from the wall so when the probe goes down it doesn't hit anything.
set EDGE WIDTH to a value that describes the distance measured from the corner, along the wall to where you wish to probe. this edge distance will be used along the X wall and then the Y wall.
sequence after pressing the button:
-rapid edge width distance away from corner at the same time moving XY clearance away from edge. So this is a slightly diagonal move.
- move probe down by Z Clearance + extra Depth
- probe wall twice (rough and fine)
- move diagonally to the other wall as set by edge width and XY clearance
- probe wall twice
- raise probe up by Z Clearance + extra Depth
- rapid back to starting corner, now calculated using the probed walls.
- if auto zero button is set set X and Y of the current user system to zero.
Can you confirm this sequence?
I just pushed code that uses m70/72 to record/reset the motion modes before/after probing.
I don't think it does - which does seem a bad idea.
Which behaviour do you think is a bad idea? It isn't entirely clear from the way you wrote this.
Seems to work fine - though I haven't tested it much.
well, updated. testing
a couple of small things.
for the 'Outside Boss' (center pick on the Outside page) the X Neg and X Pos results are backwards, as are the Y Neg and Ypos.
I think the assignments in probe_routine.py (line 658, etc) are backwards. see the image attached.
also the move from the -x probe completion over to the +x probe is too big.
# move X+ 2 * (edge_length + xy_clearance)
aa = 2 * (self.data_side_edge_length + self.data_xy_clearance)
s = """G91
G1 F%s X%f
aa = 2*(1.5 +.3) ==3.6
it should be the -x radius just determined (xpres) + edge_length + xy_clearance
aa= 1.2174 + 1.5 +.3 == 3.0174
remember going out it moved (edge_length + xy clearance) = 1.5 +.3 = 1.8
so essentially ya just go back to the center and then out the same as the first out.
and the same goes for the Y probing.
Just my opinion.
The inside-pocket works fine.....
Sounds like the similar problem with hole probing.
maybe this (have to account for latch return distance that is already moved:
(2 *self.data_side_edge_length) + latch_return + self.data_xy_clearance)
I'll look at those result calculations.