Hello,

Im trying to implement some probing features but when probing X or Y,  the probing head also moves in Z direction when I use G31X (no idea what triggers this behaviour)

example Code:

If IsOutputActive(Output15) Then

SetOEMDRO(47, 0)
SetOEMDRO(48, 0)
SetOEMDRO(49, 0)

PosX=GetOEMDRO(83)
PosY=GetOEMDRO(84)

'X+ Probing routine

Position = GetOEMDRO(83)
Code "G31 X" & (Position + 20) & "F850"
While IsMoving()
Wend

Position = GetVar(2000) 'real x probing point
Code "G01 G53 X" & (Position - 0.75) & "F500"
While IsMoving()
Wend

Position = GetOEMDRO(83)
Code "G31X" & (Position + 1) & "F40"
While IsMoving()
Wend
Position = GetVar(2000) 'real x probing point
Result= Position-(GetOEMDRO(1325)/(2)) + GetOEMDRO(1310)
It would crash into the table because it moves both axis.

Anybody here who had this problem before :/?

Thanks,
Max

Try shutting down the PC stone cold dead then power it back up and retry the sequence.

Also try a G31 from the MDI and see if the problem is there also.

(;-) TP

I tried it again after some restarts and also from the MDI line.
It seems to work now for the time being. But I really don't want to slow down my mill to 10% everytime so I can e-stop it before it crashes with the probe.
As long as this error isnt repeatable its pretty useless :/
Im using the Ethernet Smoothstepper.. maybe thats part of the problem.

PS: I didn't know about the 2000-2005 variables since last week so I always used this fast and slow approach routine.
When using probe tripping variables, is it necessary to approach with a slow feedrate? I guess it jsut depends on the update-rate of the digital inputs? I couldn't really find any relationship between feedrate and repeatability of the results.

The G31 reacts FASTER than any motion you can produce in Mach3.

BUT the Faster you go the more overshot you will see as Mach3 Has to do a controlled stop abiding to the Config of the Axis for VEL Accel.

NOW does the G31 ever hicup(;-) In Straight Gcode applications NOPE.

IN Macros mixed with CB and Gcode YEP

(;-) TP

But is the overshoot really a problem?
The 2000 variables are saved directly on the trigger point I hope?

Or do you mean because overshoot may be unhealthy for the probes?

It will depend on what your acell settings are and how FAST you are moving. IF it overshoots too far it could damage the probe if it is against a hard stop.

The trip point values are stored in the 2000 variables as you noted so that is not a problem.

(;-) TP

Hm ok i really can't find any consistency here.
I have no Idea what triggers this error.. It could also be the weather or star constellation.
I tried to calibrate my probe again after a new pc start and did nothing in mach3 but mill a simple reference surface.
Is this a known problem? Maybe for smooth-stepper users? I guess I can't be the only one with this problem

Are you running a smoothstepper or LPT port??

(;-) TP

Ethernet Smoothstepper 

OK with the SS Mach3 does NOT do the motion for probing it is controlled from the SS. Check with Greg over at Warp9.

(;-) TP