Performance Characteristics

It is important to understand that user limits:

The foreground cycle processes crucial information that needs to be updated every servo cycle. The background cycle processes all other information. The background cycle runs continuously on the XMP as often as it can. A foreground cycle starts when a timer interrupt on the XMP puts the background cycle on hold. After the foreground cycle is done, the background cycle continues running. The foreground cycle will be started at regular intervals at the rate of once per servo cycle. The background cycle runs as quickly as possible with whatever spare time the foreground cycle does not use.

Usually the background cycle will complete many cycles in the time it takes to complete a servo cycle. However, the time it takes to complete a single background cycle can end up spanning many servo cycles if the sample rate is raised or if the foreground cycle takes more time to process. If an application requires a high number of XMP objects and features or requires a fast sample rate, it is possible that background cycles could take multiple servo cycles to process, even dozens if the XMP is pushed to its limits.

Since user limits are evaluated in the background cycle, events might not be generated or output might not be written in the same servo cycle as when the conditions for the user limit would otherwise first be evaluated as TRUE. In the example below, a user limit is set up to evaluate TRUE when the axis position is greater than 1000. We would expect the conditions of the user limit to evaluate TRUE for sample 240. The XMP's background cycle, however, does not evaluate the user limit until sample 242. Therefore, an event is triggered two samples later than one would hope. The delay of two samples shown here is not indicative of typical XMP setups. Background cycles are commonly evaluated more quickly than foreground cycles, but as explained above, it is possible for the foreground cycle to process more frequently.

The following example shows how it is possible to even miss a user limit when the conditions that would cause the user limit to evaluate as TRUE and change too quickly back to FALSE. In this example, a user limit has been set up to evaluate TRUE when the axis position is greater than 200. The axis is performing sinusoidal motion of amplitude 220 encoder counts with an approximate period of eight samples. If the background cycle delays evaluating the user limit by even one servo cycle, it will miss triggering an event.

We now return to our first example to show the corollary to the previous example. It is equally possible to miss resetting the state of the user limit to FALSE after the position drops below 1000, so that it will not trigger an event when the conditions for the user limit to evaluate TRUE occur again.