Loop Time

The RMC is a deterministic controller. It reads the inputs, computes the control algorithms and updates the outputs at a specific interval. This interval is called the controller loop time, in reference to the way the controller repeatedly "loops" through its code.

The RMC will always run at its loop time setting. When it finishes all the calculations for one loop, it waits until the next loop time before doing its calculations again.

Setting the Loop Time

To set the loop time of the RMC, use the Control Loop Page.

Available Loop Times vs Axes

The loop times available on the RMC controllers are listed below, along with the expected number of axes supported by that loop time with a full load of motion commands, user programs, communications and plots. The user program time allocation is also affected by loop time, as described in Program Capacity and Time Usage.

High Control Loop Utilization

If you wish to use a loop time with more axes than listed below as being supported with a full load of motion commands, user programs, communications and plots, then you must enable High Control Loop Utilization in the Control Loop Page of the controller properties dialog.

The High Control Loop Utilization option does the following:

• Allows selecting faster loop times given the number of control axes defined in the controller.

• Allows downloading user programming with estimated worst-case processing times that exceed the allocated time. See Program Capacity and Time Usage.

If you choose High Control Loop Utilization, then you must ensure that your application will run within the selected control loop time. See the Exceeding the Loop Time and Monitoring the Loop Time sections below.

RMC75 Loop Times

Loop times that support all axes configurations are indicated by a check mark .

RMC150 Loop Times

Loop times that support all axes configurations are indicated by a check mark .

1 4000 µs requires firmware 3.33.0 or newer or 3.36.0 if MDT modules are present. It is not supported by RMC150E/RMC151E CPU revision 1.2B or older or MDT (-M) modules revision 6.0 or older.

2 500 µs is not supported by SSI (-S) modules revision 5.0 or older, or Analog Input (-A, -H, and -G) modules revision 6.0 or older.

3 250 µs is not supported by SSI (-S) modules revision 5.0 or older, or any Analog Input (-A, -H, and -G) modules.

RMC200 Loop Times

In the tables below:

• All refers to the maximum number of axes supported by the controller, as listed in the Axis Types Overview.

• Full Load includes control, user programs, plots and communications.

• Limited Load indicates the range of axes possible in applications using less than a full load. Using axes in this range requires High Control Loop Utilization to be enabled.

• A control axis in this context refers to an axis with at least one PID loop, and includes cascading outer loop axes.

CPU20L

CPU40

When is High Control Loop Utilization Required?

For the RMC200 controller, High Control Loop Utilization is required if the estimated axis processing time exceeds the processing time allowed for the selected loop time. The Axis Definitions dialog automatically provides a graphic indication of the estimated axis processing time and whether High Control Loop Utilization is required. The following tables are used to determine whether or not High Control Loop Utilization is required:

Maximum Total Axis Processing Time Allowed at Full Load

*This means High Control Loop Utilization is always required.

Estimated Processing Time per Axis

Notice that the estimated per-axis processing times shown above are conservative estimates assuming maximum processing, for purposes of determining whether High Control Loop Utilization is required. Actual processing time for axes will often be significantly less than these times indicate. However, the user should always verify that the application does not exceed the loop time excessively, as described below.

Exceeding the Loop Time

How the loop time works

The loop time is the pre-selected interval at which the RMC reads its inputs, processes motion commands and user programs, computes the control algorithms and updates the outputs. When it finishes all the processing for one loop, it waits until the next loop time before doing its calculations again. The amount of calculations can vary significantly from loop to loop, based on many factors including the commands received, user program calculations, and communications load. It is common that most of the actual loop times are low, and there are some loops that require much more time, such as during the loop time in which a motion command is received by an axis, which requires more processing.

Running over the loop time

If the loop processing takes longer than the specified loop time, the RMC will finish the processing and then immediately start on processing the next loop. The start of this next loop is therefore delayed, so the updating of outputs can also be delayed. If the loop time has been exceeded by only a small amount, such as 20%, then this delay is typically negligible, and the RMC will usually catch up with its processing in the next loop time. If the loop time has been exceeded by more, such as 75%, the delay is larger, but still usually negligible relative to the responsiveness of the physical system, especially if the RMC is able to catch up with its processing in the next loop time.

Do not exceed loop time by 100%

It is very important that the loop time is not exceeded by 100% or more. If it is, that loop time will be lost, and the RMC's calculations will not take it into account. This can cause the RMC's internal time calculations to lose one loop time, and the target motion profile calculations will be slowed by one loop time. If many loop times are lost, the target motion profiles may be significantly off, which could cause machine damage.

If consecutive loop times are exceeded such that the cumulative exceeded loop time is 100% or more, the RMC will also lose a loop time. It is important that this does not occur.

Event Log Reporting

Loop time overage of less than 80% is reported in the Event Log as a warning that can be filtered out. Loop time overage of 80%, or cumulative loop time overage of 80% or more is reported in the Event Log as an error.

In summary

• Occasionally exceeding an individual loop time by a small amount should not cause any adverse effects.

• It is important to avoid exceeding a loop time by 100%. The RMC reports an error at 80%.

• It is important to avoid cumulatively exceeding a loop time by 100%. The RMC reports an error at 80%.

Monitoring the Loop Time

Monitor the loop time in the following ways:

• Control Loop Page
  On this setting page, you can view how much of the control loop the RMC used in the last loop, along with the maximum value since the RMC powered up or since the Clear button was clicked. See Control Loop Page.

• Plotting Loop Time Registers
  To clearly visualize the loop time usage of the RMC, you can add the loop time usage registers to a plot. See Plotting the Loop Time for details.

Reducing the Loop Time Used

If the RMC is exceeding the loop time, you can attempt to reduce the loop time used, or select a larger loop time. To reduce the loop time used, you can plot the loop time registers as described in Plotting the Loop Time to determine which part of the loop is taking the most time, then use one or more of the following tips to reduce the loop time:

User Programs

• Reduce the programming loop time used by following the tips in the Program Capacity and Time Usage topic.

Commands:

• Stagger simultaneous commands
  When a command is received, the RMC performs some initial calculations in that loop time, which can be extensive. Sending many commands simultaneously can therefore result in a large loop time load. If it is possible to stagger the commands, the total loop time will not be as large.

• Do not use the Transition commands
  The Transition Rate (56) command causes extra processing, not when it is sent, but when a transition is active, such as during the beginning of sine or curve motions. Removing transitions may possibly reduce the loop time load.

• Do not use Dynamic Retargeting
  Dynamic Retargeting is the continuous sending of a Move Absolute (20) or similar commands, such as every loop time. This causes a heavy processing load.

Plots:

• Reduce the number of captured plot items
  Having a very large number of captured plot items may impact the loop time. By default, each axis has a corresponding plot that triggers when a command is sent to the axis. Reducing the number of plotted items, or changing the settings so that not as many plots are automatically triggered may slightly reduce the loop time load.

Communications:

• Reduce the Cyclic I/O
  A large amount of cyclic EtherNet/IP I/O or PROFINET communications at very short intervals can increase the loop time. Reducing the Requested Packet Interval, the number of connections, or the amount of data may reduce the loop time load.

Using the Loop Time in Expressions

Certain calculations in user programs, especially for calculating time, may require accessing the current set loop time. The _LoopTime tag can be used to access the loop time when using expressions. _LoopTime is a REAL, and is specified in seconds.

See Also

Program Capacity and Time Usage | Plotting the Loop Time |  Control Loop Page

Send comments on this topic.

Copyright © 2024 Delta Computer Systems, Inc. dba Delta Motion