Work with probe

First, the suggestions.

I've finally gotten my probe working, but had to disable the LED on it. It would be useful if the probe screen had a "light" that indicated the probe was activated.

When doing the clearing motions, it would be useful if they ran with the probe activated. Because one of the parameters hadn't actually taken effect (see the problems below), the probe moved down into the table and the stylus got bent before I got a following error. Since there should never be a case where the probe is activated while moving to (or from) its probing position, it should be reasonable to stop when the probe is hit.

When moving from a probe activated condition, it should be possible to first move a short distance (say, half the ball diameter). If the probe doesn't clear, that's an indication of a problem

My probe (the whole thing) was only $79, but if you are using an expensive one, little mistakes could be costly. It would be nice if this software protected us from our mistakes.

Another suggestion:
It is not obvious (at least to me) from the screens which motions will take place for each of the buttons. Some time ago, I saw that you had a screen that showed all of the details. It would be nice if that screen were to be incorporated into the runtime.
Alternatives:
1 -- put that info at the bottom of the existing tab and enable scrolling
2 -- add another tab (called probing help)
3 -- Add a rollover for each of the buttons showing a graphic of what happens when that button is used
4 -- ... (I'm sure there must be other possibilities)

The problems (possible bugs):
1 -- I've changed all of the parameters (they are apparently in mm and I'm using inches), but some haven't seemed to take effect. For example, when probing +X, the probe move to the left one inch (it should have moved 1/4 inch), then moved down about the same amount, and so on.
2 -- On restart, some (but not all) of the parameters seem to have changed.

Thanks again for all your hard work.

Regards,

Ken

In looking at the code, I have a question about how probe code should be written.

Alternative A:
Advance the probe in the proper direction at high speed until it is actuated.
Then back off in the opposite direction until the probe is no longer in contact.
The point where contact was lost is the result.

Alternative B:
Like Alternative A except after losing contact, go forward again to make contact.

Alternative C:
Advance the probe at high speed until it is actuated.
Back off some fixed distance at some speed.
Now go forward again at low speed.
The point where contact is made is the result.

========
I've mentioned this previously (in a different context), but I think all probing code should use ONLY probe moves (G38.x). That's to protect the probe from the user when he does something dumb. In fact, it it were up to me, motion would stop if the probe is activated even for non-probing motion. Of course there is the issue of what to do then. It's much the same issue of what to do when you hit a limit. The Axis interface lets you check a box to allow jogging when on a switch. In the case of probing, the software could keep track of the last move and only permit motion in the opposite direction.

One question I have is how fast (or slow) should the motion be when probing. How often the state of the probe is tested? Or if it is interrupt driven, what is the latency.

At a rate of one inch per second, if the latency is a millisecond, there is a built in .001 error. If I knew the latency, I would probably choose a measurement speed equivalent to a few tenths.

Ken

Renishaw has a "protected move" probing feature that one can use to stop motion if the probe trips when it should not.

I have never used it but I understand that it can be selected, if desired, during risky portions of the probe travel.

I agree that a probe trip should not always stop motion. My probe trips a lot when I load it into the spindle.

lerman wrote:

...When doing the clearing motions, it would be useful if they ran with the probe activated....

Thanks, Ken, for the description of the problem.
The Probe Screen is designed to stop all further measurements in the case "..probe tripped.." and similar errors.
Now I'm trying to understand why the error channel is silent. It is bug. I correct it as soon as possible.
My apologies for the broken probe

verser wrote:

I correct it as soon as possible.

Сorrections done
Аdditionally, you must copy the file .axisrc from the archive to the home directory ~/
If you are already using .axisrc, then only add to your file contents of this .axisrc
(for gmoccapy, installing unchanged)

I am trying to probe an inside circle but the initial travel is not enough. Which of the parameters must be set to enable me to probe a larger hole? I think it is the length of the edge but I am not sure.

Thanks for creating this screen - it finally gave me the motivation to connect up my probe and get this useful feature working.

I do however have a few suggestions which might be useful for those of us that use touch screens:

1) The spin buttons are really small for use on a tough screen - if they were larger they'd be much less frustrating to use and there seems to be plenty of room on the screen for the change.

2) If you can find a way to make the on screen keyboard available on this tab it would probably be even more useful than larger spin buttons.

3) It would be great if probing settings could be saved and retrieved - typically the different types of probing require quite different values for probe distance etc and if you have to change between two different types of probing often then it would be useful to bring up some frequently used presets.

Many thanks for your hard work on this!

Ben

After crashing my probe because the routines do some moves that are not guarded against contact, I started to write my own routines.


Here are some of what I want in such routines:
1 -- Must be safe in the sense that every move terminates when the probe makes contact.
2 -- My mode of operation is interactive. I don't need the probe routine to go down to the center of a hole before determining its diameter. I will position the probe in the desired location (I just bought an MPG) and then run the find center routine.
3 -- When it makes sense, (such as finding the center of something) the routine should leave the probe at the center. It doesn't make sense (at least to me) to position the probe at an edge because we need to know how far to raise the probe before positioning. In cases like that, find the edge, but remember the found value and return the probe to the starting point. Then manually move the probe to a safe location and give another command to move to remembered place.
4 -- When positioning to the center of a block, I want to use the same procedure as if I had just a DRO and edge finder.
A -- Jog to the side of an edge. Find the edge.
B -- Zero the DRO (selecting which coordinate system should be zeroed - P0, P1, ...)
C -- Jog to the side of the opposite edge. Find the edge.
D -- Store half the difference between the value in the coordinate system and the current value to that coordinate system.
E -- Go to that location. -- Or, since it has been saved in a coordinate system, do something else and go there later.
5 -- I'd also like the ability to find the top center of a horizontal cylinder. I've written a gcode routine to find the center and diameter of a circle given three points on it. It still needs some cleanup to make it more general, but it seems to work.
6 -- I'd like it to integrate with the buttons on my MPG. The axis selection knob together with the zero and half buttons should be useful for doing the procedure in #4.
7 -- It should (my current draft does) have an init routine that sets the relevant parameters (they are global named parameters) -- probe diameter, search distance, ... There is no reason why specific init routines couldn't be written for each important case.
8 -- Rather than diddle little screws on the bottom of my probe to get it centered perfectly, I've chosen to just calibrate the probe by measuring its offset. One way of doing that is to put a pin in a collet and use that to zero a ring. Then measure the center of the ring and record the offset. Save the offset and add (or subtract it) from every reading.

Comments, suggestions, etc are solicited. Should this be moved to a separate thread?

Thanks,

Ken