![SteemTrain.jpg](https://cdn.steemitimages.com/DQmPJj1b4AdR2QMHRJ2uqFfmbTkEfYHCcf1ZdnDLaUkFTAY/SteemTrain.jpg)

# In the grand scheme of motion control, you need to know what is going on throughout a system at all times. Part of this entitles knowing what did not happen that should have. On our machinery, our axes are generally set up to have programmable speed via a touch screen. This can throw a wrench in fault control.

## Example:

## The time differential for the axis to complete the commanded move can vary extremely depending on axis speed and distance of travel. Say the axis has to make a 10"(254mm) move, at a speed of 1"(25.4mm)/sec, the move will take in a perfect world 10 seconds to complete. However, as we know, this isn't a perfect world with the addition of friction and wear, heat and stress additional time must be added to accommodate for these resistive forces.

## So let us say a 10" move may take 11 to 12 seconds to complete wide open, now we must factor in the ramping of the axis by the motion controller, as we all know we first have to get to speed. So our 10" move will probably take us more like 13 to 15 seconds to complete.

## Now on the other hand, say the speed was 5"(127mm)/sec, the move could be more like 4 or 5 seconds to complete. This is the wrench. You would not want to set a fault for the motion of the axis based on a timer, as the time could be unpredictable. You might think, just set a timer for the longest time the move could possibly take to complete in the worst case scenario. This could give you an unsafe condition though, suppose the speed is set to 5"/sec. If the axis motion faulted at the beginning of the move, it could sit there working/crashing for a unnecessary amount of time. The extra force or possibly un-synced force could destroy tooling, machine, or worse injure someone.

## To prevent this in machinery I program, I add an 'Axis Motion Detect' fault handler. Heres how it looks:

![Axis_Motion_Detect_1.PNG](https://cdn.steemitimages.com/DQmSrDqV6S2qWQ3FupVrdyQBDe1pwxiLszt87WiJNpwKUUH/Axis_Motion_Detect_1.PNG) ![Axis_Motion_Detect_2.PNG](https://cdn.steemitimages.com/DQmRTkUETCCCrbXsgNuQhkmis1BEhXtLoYWvRaR2cwjsL9A/Axis_Motion_Detect_2.PNG)

Rung 0000 As you can see here, I trigger a timer which resets itself upon the DN bit being set. This is the rung which I use to continually update the position window of the axis as it falls outside the limits used in the LIM instruction. This rung goes true upon the command to move the axis. Rung 0001 This rung updates the axis position window anytime that motion is detected and the trigger timer is done. Rung 0002 If the axis is commanded to move, and is not in position, if axis motion is not detected for 5 seconds this rung will trigger the fault condition. Rung 0003 By putting the low limit window value in the high parameter of the LIM instruction, and using the high limit window value in the low parameter, RSLogix looks for the test value to be outside the high/low range. This tells me that the axis has moved out of the last snapshot calculated motion window. Now speed has no effect on an axis motion fault. If at anytime it takes longer than 5 seconds to see the axis feedback move outside the snapshot window, the fault will be triggered. Hope this helps you out in your ventures! Relay