Control strategies can span multiple control modules. Select scan rates that meet the timing requirements of any interacting modules but still make efficient use of the CPU.
For example, you use module templates from the library to create several motor modules with interlocks. The interlock conditions in each of these modules are configured using expressions in Condition function blocks. If the interlock conditions rely on values of parameters in other modules, the scan rate of those other modules should be at least as fast as the motor module. The configuration engineer does not set the execution order of control modules. Only the execution order of blocks within modules is set. So, the user does not control the order of execution of modules with the same scan rate. Modules that interact with other modules having the same scan rate could effectively be delayed 1 scan in terms of acting on information from another module. This might lead the configuration engineer to scan all interacting modules at twice the required scan rate.
If there is a requirement that all discrete devices (for example, motors) interlock to the passive state within 1 second, then setting the scan rate of all modules involved in interlock conditions or discrete control to 1 second does not guarantee that the requirement will be met. However, setting the scan rate to 500 milliseconds satisfies the requirement with the possibility that it might be costly from a CPU loading perspective. A possible alternative when CPU load is an issue would be to base interlock conditions on values at input channels (via I/O type parameter paths) where possible, rather than on parameters in other control modules (via module type parameter paths) instead of overscanning all of the interacting modules. This keeps the interlock information current to within about 25 msecs.