2017 Screenset - Probing Issue

[spumco]

Gerry,

I finally got my spindle touch probe and am trying to use the 2017 probing features in the jog panel.

The problem is that randomly - about every 4th or 5th probing attempt - the machine will do the probing routine and then go past the zero and keep flying along, having crashed past the opposite pocket (or boss) wall. If I had a ceramic stylus I'd have wiped out about 10 of them by now. The impact tolerant touch probe I got from Cliff on CNCZone has paid for itself about 2x over after 2 weeks of ownership...

Lets say I'm doing the inside of a cylindrical pocket:

1. I use the auto-zero to set the height of the pocket top to Z0. All good so far.
2. I manually center (more or less) inside the pocket and jog down about .2"
3. I click the 'inside pocket' probe button and the probing routine starts.
4. Probe moves X+ at the 'initial speed' and touches the X+ side, retracts the programmed amount and does the second touch at reduced speed. Good to go.
5. Probe moves in X- to the other side of the pocket, then hits the opposite wall at initial speed and keeps going until I hit the escape key or E-stop.

The probe LED on the screen lights up when it hits the wall and goes out after the stylus snaps back down in to the contacts. This isn't a case of having a cheapo probe that isn't registering the touch.

This has also happened doing outside bosses. Sometimes it touches all four sides and then on the rapid back to center it keeps going in the last direction it was traveling until it hits a limit switch or I stop it with the reset or feed hold (or estop).

I don't think it's happened on any of the corner routines or single axis routines, but my memory is a little fuzzy sometimes.

Assuming I zeroed everything on a previous probing cycle, once I've stopped the motion after the crash and the probe is way out of the intended final position, the work DRO's still read 0.0000 on both X and Y. i.e. the crash happens before the DRO's are updated.

The machine DRO's are keeping track of the motion - even the unintended motion. I can turn off the 'home auto-zero' and re-home all the axis after a crash and the machine DRO's are within a half a 'thou. I'm guessing this means that UCCNC isn't flipping out, my machine isn't losing steps, and that the probing routine is still going on when I hit the escape key.

I've tried re-starting UCCNC and restarting the computer; neither has helped. Neither has changing axis speeds, probing speeds, kernel frequency, or just about every other setting I could fiddle with. I'll get a few probing cycles done and then it takes off again, regardless of the tweaking I've done. I've got it down to 40IPM rapids, 30 acceleration, 10IPM initial speed, and 2IPM second touch - speed doesn't seem to make a difference. It's almost funny watching it crash in super slo-mo...

Honestly, I don't know if this is a 2017 screenset issue, a UCCNC issue, a VistaMPG issue, or a hardware issue on my end. Just thought I'd start with you since the old(ish) probing manual for the 2010 Mach3 screenset is the only thing I could find with definitions of your probe panel settings. Has anything changed since the 2011 version of your manual?

PS - using UCCNC 1.2045, and I've disconnected the touch-plates I made a while back. Now that I have the TTS toolholders all I use is the auto-zero and the spindle probe.

Thanks for any suggestions you might have.

-Ralph

[cncdrive]

On the Diagniostics screen in the Status monitor section is the probe LED on when the final problematic movement happens?
I'm asking about the Probe LED in the status monitor section and not the Probe LED in the I/O functions section!

The Probe LED I'm asking about tells you if the current movement is a G31 probing movement. If that LED is on then it is a G31 probing movement going on, otherwise, if it is off then the movement is not a probing movement and then it is understandable why it is not stopping for the probe input.

So, if that Probe LED is on and the movement still does not stop when the probe input triggers then it is a UCCNC problem, because it must stop the probing movement when the probe input triggers,
otherwise if the movement is not a probing move then it is a problem with the screenset code which commands the movements, because then the problematic movement is not a G31 which means that the screenset macro sent a non G31 movement to the wrong coordinate if it crashes into the table or workpiece.

[spumco]

I had to slow the axis rapids way down to 30IPM to catch it in the middle of a crash, but I got it.

The probe LEDs on both the run screen and the I/O diagnostics page are lit during the crash.

The red probe LED in the status window is NOT lit during the crash.

Just crashed twice in a row doing an inside pocket. First time it crashed during the X- move after a successful touch in X+. Second time was after successful X+, X-, Y+, and Y- moves - it crashed during the Y+ return to center.

[cncdrive]

If the Probe LED in the Status monitor section is not lit when the crash movement is ongoing then that actual movement is not a probing move, but a normal linear or circular movement.
So, then the issue has to be with the macro code.

And just to make sure there is no missunderstanding I'm attaching a picture with the LED marked with red color which I'm talking about.
That LED shows when a probing movement is in progress.

[cncdrive]

And it would be interesting to also check what the DTG (distance to go) of the axis shows when the problematic movement is ongoing?
It can be interesting to see it's value, because it shows how far the axis is commanded, so knowing the distance might help to figure out the issue in the code.

[spumco]

The 2017 screenset has the status monitors moved to the RUN page, but the red probe LED is NOT lit during the crashes.

Note the LED's at the bottom right of the screen.

Looking at the macro for the pocket probe routine, the move back to center is a G0 command. However, some of the crashes appear to have happened during what should be a G31 command.

[cncdrive]

The probing movement indicator LED is the LED#24.
You can verify it using the screen editor, selecting the LED and checking the lednumber parameter of the LED.
If it is 24 then it is the same LED which I was talking about.

If that LED is not lit when the wrong movement happens which causes the crash then as said it is not a probing movement, so then the movement will not stop even if the probe input triggers.
So then the macro code has to be checked, because then it is commanding the axis to move to the wrong location or it sends a G0 or G1 where a G31 should be.

[spumco]

We're talking about the same LED - #24.

I watched a few more crashes and none of them happen during an actual G31 move. They're all during G0 moves.

Under 'normal' probe routine, the G31 move is to one edge, then the second touch, then a G0 move to start position. There's a slight pause, then the next G31 move to the opposite wall.

During the crashes there is no pause and it just keeps going past center to the opposite pocket wall at G0 speed. It's like the system lost track of where the start position was and continued on.

What's confusing me is that if the macro were at fault, it should do the same thing every time. It's not - it crashes at different sections of the probing cycle. And it doesn't do it every time I try to probe.

[ger21]

Yes, it's LED 24.
Looking at the code, it should be doing a rapid move back to the original X position before doing the X- probe.
Can you set your probe speeds very low, and test in air, to see where the rapid move is going to?

[spumco]

Here's a section of the macro. I'm not going to post the whole thing unless Gerry gives me permission.

This is the X+ probing. The crashes are happening at the end of this section during the last G0 back to start.

// Probe X+ axis

XStart = AS3.Getfielddouble(226); // Current X axis Work Coordinate
ProbeL = XStart + Dmax; // Probe Length

//exec.Code("F" + Frate1); // Set First Probe Feedrate

exec.AddStatusmessage(" ");
exec.AddStatusmessage("Probing for X+ Position...");

exec.Code("G31 X" + ProbeL + " F" + Frate1); // Do First Probe move
while(exec.IsMoving()){}

Xhit = exec.Getvar(5061); // Read the touch point
X1 = Xhit + ProbeD/2 + PlateOff; // Tool Center Position at X=0

if (Frate2 != 0)
{
exec.Code("G0 X" + (Xhit - Retract)); // Back away from edge
while(exec.IsMoving()){}

exec.AddStatusmessage("Slow Probing for X+ Position...");

//exec.Code("F" + Frate2); // Set Slow Probe Feedrate

exec.Code("G31 X" + ProbeL + " F" + Frate2); // Do Slow Probe move
while(exec.IsMoving()){}

Xhit = exec.Getvar(5061); // Read the touch point
X1 = Xhit + ProbeD/2 + PlateOff; // Tool Center Position at X=0

} // End Slow Probing

exec.Code("G0 X" + (Xhit - Retract)); // Back away from edge
while(exec.IsMoving()){}

exec.Code("G0 X" + XStart); // Rapid back to Start Position
while(exec.IsMoving()){}