If I understand correctly, Encoder 1 is the encoder that correspnds to the X-axis encoder and OEM button code 133 can be used to zero that encoder count.  I'll give that a shot. Thanks for the help.

YEP you can use two of the encoders to do a compare function  and it does not matter which 2 (;-)

IF encoder(1) = Encoder(2) (+/-) then ok
If encoder(1) <> Encoder(2) (+/-) then STOP and (most important)

write MESSAGE to screen ( WHOA BOY, ENCODERS ARE OUT OF SYNC) (;-)

ON ESTOP and  rehome axis  then  Function 133 & 134 ( reset encoder dro to zero to resync test function)

AND double check your Encoder(0)   YES ART normally started his naming sequence with (0) being the X axis   x=0 y=1 z=2 ,etc

YEP that should about do it(;-), TP

I apologize for not communicating clearly. My ultimate goal is to detect racking of the gantry and stop the machine before damage can be done. The gantry is moved by a lead screw on each side. My plan is to have a rotary encoder at the end of each screw. When I detect that one screw is not keeping up with the other, then issue a stop command. My problem is establishing the inital conditions for each encoder. I am sure there are many ways to solve this problem. My first thought was to detect when the machine is in an e-stop state and then zero each encoder count via a brain. When the machine is taken out of the e-stop state, then have the brain compare the two counts and stop he machine if they differ by more than a few counts.

If there is no way to zero the counts, then my next thought was to read the counts into a variable when the machin is in an e-stop condition. Call these the initial count variables (a variable for each encoder). Once the machine is out of the e-stop condition, subtract the initial count variables from the encoder readings. Again, if these readings differ by more than a few counts, stop the machine.

I am open to a completely different approach. Perhaps I need to assign the encoder to an MPG or axis DRO. Perhaps my newness to Mach is making this a much more difficult problem than it should be.

You could zero the encoders using an initialization macro, and use that same macro to re-zero after a fault, as it simply executes as an M-code.  You could also use the macropump to do the detection, rather than a brain, if you wanted to.  I think the only downside would be the slower update rate - about 10 times per second, IIRC,

Regards,
Ray L.