Work with probe
- lerman
- Offline
- Junior Member
Less
More
- Posts: 25
- Thank you received: 5
17 Jun 2015 21:55 #59913
by lerman
Replied by lerman on topic Work with probe - suggestions and some problems
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
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
The following user(s) said Thank You: verser
Please Log in or Create an account to join the conversation.
- lerman
- Offline
- Junior Member
Less
More
- Posts: 25
- Thank you received: 5
19 Jun 2015 04:12 #59966
by lerman
Replied by lerman on topic Work with probe -- How should probing be done?
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
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
Please Log in or Create an account to join the conversation.
- cradek
- Offline
- Administrator
Less
More
- Posts: 29
- Thank you received: 9
19 Jun 2015 05:31 #59971
by cradek
It did this for a while. We took it out because a lot of probes give false probe hits when they're jiggled even a little bit (imagine a probe banging around in a tool carousel). We still have this protection during homing, jogging, and MDI moves, which I think are the most likely way to screw up. I would absolutely support making this an option; it's trivial - see around control.c:400
It's polled in the servo thread.
Replied by cradek on topic Work with probe -- How should probing be done?
In fact, it it were up to me, motion would stop if the probe is activated even for non-probing motion.
It did this for a while. We took it out because a lot of probes give false probe hits when they're jiggled even a little bit (imagine a probe banging around in a tool carousel). We still have this protection during homing, jogging, and MDI moves, which I think are the most likely way to screw up. I would absolutely support making this an option; it's trivial - see around control.c:400
One question I have is how fast (or slow) should the motion be when probing. How often the state of the probe is tested?
It's polled in the servo thread.
The following user(s) said Thank You: lerman
Please Log in or Create an account to join the conversation.
- johns00056
- Offline
- Premium Member
Less
More
- Posts: 108
- Thank you received: 2
20 Jun 2015 00:39 #59997
by johns00056
Replied by johns00056 on topic Work with probe -- How should probing be done?
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.
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.
Please Log in or Create an account to join the conversation.
- verser
- Topic Author
- Offline
- Senior Member
Less
More
- Posts: 79
- Thank you received: 69
21 Jun 2015 11:32 #60028
by verser
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
Replied by verser on topic Work with probe - suggestions and some problems
Thanks, Ken, for the description of the problem....When doing the clearing motions, it would be useful if they ran with the probe activated....
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
The following user(s) said Thank You: lerman
Please Log in or Create an account to join the conversation.
- verser
- Topic Author
- Offline
- Senior Member
Less
More
- Posts: 79
- Thank you received: 69
25 Jun 2015 11:43 - 25 Jun 2015 13:14 #60124
by verser
А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)
Replied by verser on topic Work with probe - suggestions and some problems
Сorrections doneI correct it as soon as possible.
А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)
Last edit: 25 Jun 2015 13:14 by verser.
Please Log in or Create an account to join the conversation.
- mariusl
- Offline
- Platinum Member
28 Jun 2015 17:18 #60216
by mariusl
Regards
Marius
www.bluearccnc.com
Replied by mariusl on topic Work with probe
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.
Regards
Marius
www.bluearccnc.com
Please Log in or Create an account to join the conversation.
- BigJohnT
- Offline
- Administrator
Less
More
- Posts: 7330
- Thank you received: 1176
28 Jun 2015 18:27 #60220
by BigJohnT
Replied by BigJohnT on topic Work with probe
Please Log in or Create an account to join the conversation.
- spangledboy
- Offline
- Senior Member
Less
More
- Posts: 76
- Thank you received: 10
28 Jun 2015 21:42 #60228
by spangledboy
Replied by spangledboy on topic Work with probe
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
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
The following user(s) said Thank You: verser
Please Log in or Create an account to join the conversation.
- lerman
- Offline
- Junior Member
Less
More
- Posts: 25
- Thank you received: 5
29 Jun 2015 02:50 - 29 Jun 2015 06:06 #60232
by lerman
Replied by lerman on topic Work with probe
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
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
Last edit: 29 Jun 2015 06:06 by lerman. Reason: Fix typo.
Please Log in or Create an account to join the conversation.
Time to create page: 0.235 seconds