I work with GML commander a lot and have run into a quirk that can result in the execution of the fault routine only to find no faults exist. This may not be the problem in your application. You should be able to follow the program flow if there are print blocks at each branch. I recommend adding a print block at each decision branch in the program. Be careful not to put print blocks within loops or you'll overload the serial buffers. Most fault routines disable all axes at the beginning of the fault routine, so your program is probably detecting a fault and executing the fault routine. The only faults that aren't retentive (that I am aware of) are the hardware overtravel faults.
It could, depending on your program, produce the symptoms you describe. If an axis in the system has harware overtravel limit switches in use, and one of these switches momentarily changes states, the high speed inputs on the controller will detect this and cause program flow to jump to the fault routine. Within the fault routine, if the limit switch has returned to its "ok" state, there will be no evidence of what caused the fault. The axis status and global status codes will return to normal automatically. In my application, I copy these status words to user variables at the very beginning of the fault routine, but I've had two different situations on two different machines in which this still was not fast enough to trap the overtravel fault. On one machine, a drive belt was whipping down and tapping the limit switch arm so quickly that you could barely see it with the naked eye. I bent the limit switch arm down out of the way to fix it. The other machine had a poor solder connection that was opening for only a few microseconds at a time.
I have complained to Rockwell Software about the fact that this particular fault is not retentive and their recommendations matched what I'm already doing. They have no intention of changing anything to make this better for us programmers.
Hope this helps.
Paul C.
