UCCNC Probing

[ger21]

It shouldn't, but it might?

[CT63]

I found using Mach 3 (v0.062) that sometimes after the second slow speed tap Mach 3 would try to drive the tool bit into the work for no reason. I traced the problem to the line of code in the probing macros that retracts the tool to point of contact "in case of overshoot". I disabled this line of code in the macro and disabled the second (slow) tap line of code and lowered the initial probe rate to 5 ipm. Never happened again and never noticed a difference with cutting accuracy. In UCCNC I only use one probe tap. I'm cutting wood so being off a couple of thousands isn't a problem.

[cncdrive]

Programmatically it does not matter, the probing generates an interrupt in the microcontroller and the probed coordinates are then saved in realtime (happens in less than 50 nanoseconds which is 0.00000005 seconds) and then the axis stops and the coordinates sent to the PC, so the user can read them out.

So, if you probe e.g. with 20000mm/min (not likely anone would probe that fast.) then still the travel on the worst case about 50nsec is 0.0000166666 millimeters which is 0.000000656 inches only.

[A_Camera]

Programmatically it does not matter, the probing generates an interrupt in the microcontroller and the probed coordinates are then saved in realtime (happens in less than 50 nanoseconds which is 0.00000005 seconds) and then the axis stops and the coordinates sent to the PC, so the user can read them out.

So, if you probe e.g. with 20000mm/min (not likely anone would probe that fast.) then still the travel on the worst case about 50nsec is 0.0000166666 millimeters which is 0.000000656 inches only.

Hi Balázs,
Have you measured this? I mean, yes in theory that is the case, but is this really the case in reality? Also, I think in another post you said that you sample the inputs five times even for probing, so if that is the case than the movement is a whole lot more, namely 0.000083333 mm.

On the other hand... when I probe using the jog probing feature then at 10% speed, which in my case is 1000mm/min, I can feel my touch plate moving before the movement stops. Are you saving the actual touch value when the plate is touched or when the movement is stopped? I am sure there is a measurable difference, and the movement is definitely more than 0.000083333 mm, though I have not measured it, just felt with my finger and see actually that the DRO shows zero only if I probe with a LOT slower speed. The way I do it is that I am probing at a fairly high speed (50mm/min) and then after the stop I back off 0.2 mm and run a new probing at 3mm/min. Are you sure that probing speed does not matter for UCCNC? It definitely matters in Mach3, I measured that when I wrote my macro for probing.

[cncdrive]

I can't say anything about if it matters in Mach3 or not, I did not use it for a too long time now and I can't remember how this is handled in Mach3.

In the UCCNC as I wrote the probing input is not polled, but a software interrupt is generated on the 2 probe pins on the edge which is set to the active one.
The sofware interrupt means that the code exacution inside the microcontroller jumps to the interrupt service routine as soon as the microcontroller detects the set edge on the probe pin.
This is a hardware microcontroller feature and happens immediately without any delays, the only delay, the max. 50nsec is because the return address to return back after the interrupt has to be saved to the stack prior to doing anything else and then the coordinates are read, these takes upto 50nanoseconds with the 200MHz CPU frequency microcontroller in the UC300ETH, because one micro CPU cycle is 5nanosec and it can take upto 10 CPU cycles to do the mentioned things.
After these are saved the saved coordinates are sent back to the computer via the ethernet, so the user can access them.

It is another thing when and how the probe stops, that can be a problem if the probing is too fast, it does not influance the programmatic measurement accuracy though,
however ofcourse too fast probing could cause the switch to jump/prell and could cause the machine to shake and also the axis stops a bit further since it has to stop,
but again the probe coordinates are already saved when the axis stops, so these things are no more UC300ETH, but machine and sensor dependents.

[A_Camera]

I can't say anything about if it matters in Mach3 or not, I did not use it for a too long time now and I can't remember how this is handled in Mach3.

In the UCCNC as I wrote the probing input is not polled, but a software interrupt is generated on the 2 probe pins on the edge which is set to the active one.
The sofware interrupt means that the code exacution inside the microcontroller jumps to the interrupt service routine as soon as the microcontroller detects the set edge on the probe pin.
This is a hardware microcontroller feature and happens immediately without any delays, the only delay, the max. 50nsec is because the return address to return back after the interrupt has to be saved to the stack prior to doing anything else and then the coordinates are read, these takes upto 50nanoseconds with the 200MHz CPU frequency microcontroller in the UC300ETH, because one micro CPU cycle is 5nanosec and it can take upto 10 CPU cycles to do the mentioned things.
After these are saved the saved coordinates are sent back to the computer via the ethernet, so the user can access them.

It is another thing when and how the probe stops, that can be a problem if the probing is too fast, it does not influance the programmatic measurement accuracy though,
however ofcourse too fast probing could cause the switch to jump/prell and could cause the machine to shake and also the axis stops a bit further since it has to stop,
but again the probe coordinates are already saved when the axis stops, so these things are no more UC300ETH, but machine and sensor dependents.

OK, thanks.

BTW, I know what interrupt is...

...built my own computer in 1980... firmware, OS and everything was my own design based on Rockwell 6502, and many 8 and 16 bit CPU and micro controller based things after that. Today I only use Microchip PICs or different model, depending on the target.

[ger21]

You do have to make sure that you get the coordinates from the vars, and not from the DRO's.

[beefy]

I just looked at the manual and read the description for G31 move.

The thing I was interested in was exactly WHEN the co-ordinates are recorded.

If the probe trips the coordinates at the trigger point are written into the variables #5061 to # 5066 (axes coordinates X to C in order) and the axis stops with deceleration.

That seems to say that no matter what the probing feedrate, it should not make any (noticeable) difference because the co-ordinates are recorded at the moment the probe trips.

AFTER that the probe axis will slow down to a stop.

So if I did a probe move at 10,000 mm/min I'm pretty sure the STOP position would be somewhat past the probe trip point due to the deceleration/slowdown, but as for the worst theoretical error for the recorded probe trip point:

10,000 mm/min = 167 mm/sec

167mm x 0.00000005 (50ns) = 0.00000835mm or 8.35 millionths of a mm

I have overrun mechanisms on my plasma table home switches. This allows me to get maximum accuracy from the switches but any overrun causes by deceleration does not break the switches, the spring loaded plunge mechanism just pushes in.

Keith.

[CT63]

Are you sure that probing speed does not matter for UCCNC? It definitely matters in Mach3, I measured that when I wrote my macro for probing.

I'm not even sure it matters in Mach 3 or could be something in the version of Mach 3 you are using. Mach 3 (ArtSoft) is notoriously known for fixing one problem and creating 3 more in the process. I know running Mach 3 Ver 0.62 it didn't make a difference in probing accuracy when I stopped using the second tap. I know a second tap doesn't make any difference in probing accuracy from the first tap in UCCNC.

[A_Camera]

I just looked at the manual and read the description for G31 move.

The thing I was interested in was exactly WHEN the co-ordinates are recorded.

If the probe trips the coordinates at the trigger point are written into the variables #5061 to # 5066 (axes coordinates X to C in order) and the axis stops with deceleration.

That seems to say that no matter what the probing feedrate, it should not make any (noticeable) difference because the co-ordinates are recorded at the moment the probe trips.

AFTER that the probe axis will slow down to a stop.

So if I did a probe move at 10,000 mm/min I'm pretty sure the STOP position would be somewhat past the probe trip point due to the deceleration/slowdown, but as for the worst theoretical error for the recorded probe trip point:

10,000 mm/min = 167 mm/sec

167mm x 0.00000005 (50ns) = 0.00000835mm or 8.35 millionths of a mm

I have overrun mechanisms on my plasma table home switches. This allows me to get maximum accuracy from the switches but any overrun causes by deceleration does not break the switches, the spring loaded plunge mechanism just pushes in.

Keith.

Yes, that's the way it should work. I have not checked yet if this is really the case, just noticed that I can feel the extra movement. Of course it doesn't matter if the trip point is recorded, just back to the trip point, set it to zero and that's it.