1. How fast I/O modules on the I²C bus are polled? Does this vary as more modules are added?
2. Can you say roughly what the scan time of each point would be if the maximum modules (20) were added? Or if just one module (eg 16 point DI) were added?
There is a quantity of factors affecting the I/O scanning speed and periodicity. They can be segregated to
a) user software factors; and
b) hardware/firmware factors.
All the factors interact in their influence in some complicated manner. User software execution periodicity also depends on all of them.
It is very complicated to measure the influence of (b) factors separately. Even though this is possible, the practical value of figures obtained would be about zero, especially for customers. What is really interesting to know is the length of scan time of controllers with different configurations of software and hardware.
Scan time (aka "work cycle") of a SCADAPack controller is a period of controller operation, in which 1) one main cycle of user software is executed, and 2) all the inputs/outputs of the controller are scanned by the firmware once. There is always one occurrence of the first procedure corresponding to one occurrence of the second procedure, and vice versa.
This article gives general explanation of dependence between the length of scan time (or simply "the scan time") and controller configuration (hardware and user software).
To a first approximation we can assume that
1. User software and I/O scan run for the most part in parallel. They limit each other in periodicity: whichever is longer, substantially defines the scan time.
2. Different I/O modules have different impact on the scan time. Furthermore, this impact largely depends on controller model and in some cases on firmware version.
3. Obviously speed of user software execution also depends on controller model and firmware version. This dependence does not have a direct relation with the dependences mentioned in the previous rule.
4. Assuming that the "software cycle" boundary is overtaken, each additional expansion module of the same kind adds the same portion to the scan time.
5. Ladder logic and C code are executed sequentially. Their "cycle" times are summed.
6. Assuming that the "firmware cycle" boundary is overtaken, there is a linear dependence between software complicity and the scan time as well. Though, it is complicated to estimate the software complicity based on particular ladder logic or C program; general rules apply.
7. Even though some configurations of hardware can make the scan time significantly big, user software can overwhelm the hardware impact when not optimized, or when it uses the controller for complicated software operations which it is not designed for.
8. The Register Assignment has a priority impact on the firmware cycle. If registers are not assigned, corresponding hardware is not being scanned and has no impact on the scan time.
9. If registers are assigned but the corresponding hardware is not connected, it can either increase or decrease the scan time compared to the situation when the hardware is connected.
Watching more precisely we can see that (as examples)
10. Rule 1 is not absolute. For example after reaching the "software cycle" boundary, adding more I/O modules still increases the scan time, though for a much smaller value.
11. Rule 4 in application to some combinations of hardware is quite inaccurate.
On the above figure you can see an illustration for rules 1, 4, 10 and 11. Particularly were used controllers 5232 with relatively slow expansion modules 5506. The left graph has a bend at the point (1; 2.18). This bend means that the "software cycle" boundary was already overtaken with the addition of the first expansion module. The bend is very slight though. It is because the user software was very simple and fast.
The above table illustrates scan times for some other combinations of hardware. For all the combinations we used the same very small program.
The last column, where applicable, shows the difference between current and previous scan time.
Notice that connecting 5305 AO module does not affect the scan time. It can be explained for example by the fact that there is no possibility to remove the corresponding register assignment from controller configuration. However it is possible to remove build-in counters' inputs (DI) from the register assignment and prevent the firmware from scanning them. The last but one row shows the scan time in such situation.
We have designed a small TelePACE ladder logic program for SCADAPack, which experimentally measures the scan time of a given hardware/software configuration. This program is available in the Programming Samples download section of CMI website.