XMP-SynqNet Controller Performance

Controller Processor Load

The controller is responsible for the real-time trajectory calculations, closed-loop control, handling the dedicated I/O, updating status, event messages, data recording, SynqNet network data processing, plus many other features. The controller's processor load is based on the number of SynqNet nodes, number of enabled objects (Motion Supervisor, Axis, Filter, Motor, etc.) and enabled features. For optimum controller performance, be sure to disable any unused controller features.

Foreground vs. Background Task

The XMP-Series controllers split the operations into two tasks: foreground and background. The foreground task is the main task and is triggered from an internal interrupt that fires when the sample period timer expires. After the foreground task completes, then the background task executes. If the background task does not complete within one sample period, it is interrupted to begin the foreground task in the next sample. Each time the foreground cycle completes, it begins the background task from the point it was interrupted in the last cycle. The sample rate is user configurable (default = 2000).

All sample period critical functions are performed in the foreground: trajectory calculations, closed-loop servo calculations, SynqNet data processing, data recording, linking, camming, position compensation tables, capture, compare, program sequencers, etc. Less critical functions are performed in the background cycle: status update, dedicated I/O processing, motor limits, actions, event messages, etc.

Performance Statistics

The controller maintains internal statistics to keep track of its processing load:

Maximum Foreground Time - The maximum amount of time to execute the foreground task.

Maximum Background Time - The maximum amount of time to execute a full background task. This may require one or more sample periods.

Maximum Delta - The maximum number of times a full background task is interrupted by the foreground task. A value of one means the background task executed to completion without being interrupted by the foreground cycle.

The statistics can be viewed in Motion Console or your application (See the xmpstats1.c sample application). You can also use these statistics to monitor the controller's processor load and/or to select an appropriate sample rate. When collecting controller performance statistics, make sure to run your application or simulate the expected load. Executing features and configurations will cause the controller's code path to be different, resulting in different performance statistics.

Guidelines

For good, balanced performance between the foreground and background tasks, choose a sample rate that keeps the maximum delta low (0 to 2). Larger deltas can degrade controller feature performance. For example, commanding point-to-point motion, waiting for events, motor configuration, motor limits, and user limits will have higher latencies and longer execution times. If the maximum delta becomes large (>= 10), then the controller will waste significant processing time on context switching. Even larger values will cause the background cycle to be starved, resulting in software timeout errors and other strange behavior.

If the controller's sample rate is too high or the foreground processing time is too long, the processor may not be able to update the SynqNet Tx buffer before the data is scheduled to be sent to the nodes. If the controller updates the Tx data too late for two successive samples, the controller will shutdown the network and generate an TX_FAILURE status and event. If TX_FAILURE events occur, you will need to reduce the sample rate and/or reduce the controller's foreground cycle processing load or increase the Tx Time. Be sure to eliminate any unused resources to reduce the foreground cycle load. A good rule of thumb is to keep the foreground execution time less than (sample time) * (Tx Time). For example, if the sample period is 500 microseconds (default) and the Tx Time is 75% (default), then the foreground cycle time should be less than ~375 microseconds (plus some margin).

Servo Update Rate

The servo closed-loop update rate is dependent on the application requirements.