GML trapping intermittent hard OT faults

This is not really a PLC question, but I'm sure that some of you have dealt with this before. The problem is with A/B 1394 and S-Class motion controllers' overtravel inputs and trapping faults. When an overtravel fault occurs, the global fault code changes to a 3 and the axis status changes to 9. The motion controller will immediately jump to the fault routine, but as soon as the limit switch is Okay, the fault codes go back to normal. I've had two different situations in which an intermittent OT limit caused troubleshooting confusion. The fault handler was unable to identify the cause because it cleared up before any of the fault reporting logic could occur. On one machine it was a loose connection. On the other, it was a drive belt that was whipping the limit switch lever very rapidly (barely visible to the trained eye). The only way I was able to diagnose the first problem was to put a print block in the beginning of the fault routine and watch the terminal window and that only worked part of the time. I've tried copying the status words to user variables at the beginning of the fault routine, and this works occasionally, but most of the time (with the second problem especially) it's just not happening fast enough. The motion controller always detects the fault and jumps to the fault routine, but usually reports no fault. The maintenance techs scratch their heads for a while and then call me. Is there a way to programatically trap hard overtravel faults that is more reliable?
Thanks
Paul C.

I've used quit a bit of these and not had that problem. The first step in my fault handler is to check if the general fault is 3. If so I go instantly to a "Check Axis Fault" and check for a hardware overtravel. If there is a hardware OT, then I will turn on a bit that gets sent to the plc. The fault handler will be put into a loop until the PLC sends back an acknowledge.

Maybe I have been lucky and just haven't had an intermittent OT.

If you want, you could post your GML code and maybe someone could scan through it to see if there is anything that sticks out.

The first four blocks in my fault routine copy the axes statuses to PLC inputs...

In the two cases I've had issues with, the OT limit switch input is only tripped for a couple of milliseconds. I haven't found anything in the servo controller that is "latched" or maintained when the hard OT fault occurs. The method I am using now is better at trapping the faults than the original code, but it's not good enough for me. Maybe I can complain to Rockwell and get them to change the firmware! (That's what we need is more firmware from Rockwell, Huh?)
Thanks
PC

They haven't made any changes to GML for about 5 years and most likely don't have any planned. Likely that you won't be able to solve it in software.
Suggestion:
Wire the OT limit to a relay with seal-in cct and use a relay contact as the OT input on the S-class.

I copied my post in an e-mail to Rockwell Software. I got a call this morning and had a lengthy discussion about changing some firmware to solve my issue. The technician from RS said that I had already done (in GML) what he would recommend and that there is no retentive evidence of hard OT conditions anywhere else in the controller. Also, this is the only fault condition that is not retentive.
I suggested to him that the controller firmware be changed to either retain the axis status or the global status to allow us programmers to make more bullet proof fault routines and annunciation. He said he'd pass that along to the marketing/development teams, but could not guarantee that anything would be done.
We have a huge investment in 1394/S-Class controllers (probably a hundred of them) in this plant, and have had Rockwell's involvement in several other major issues. They know we are generally unhappy with the 1394 system module reliability, so maybe they'll do something to help. Anyway, I complained and I feel better.
PC