Look also on the video (44 MByte, 11 min) due to the animation:
You should consider to separated parts of this gif animation.
-
Firstly look on the bottom side left and right bar. It should present a value (by color) in the currently time. If the left bar has a new value, the color changes. It is the representation of a average value of a expired sampling time. This value is transferred (the color follows) to the right bar during a time of less than one step time of a controller application. The dead time of the controlling is this time < one step time plus 1/2 of the average time of measurement plus 1/2 of the average time of presentation the output value for the whole following step time. This is usual for a digital controlled loop for process signals. It needs approximately 2 step times as dead time. or a little bit lesser, also without communication. But here it is shown: It is also possible with communication, only 2 step times dead time.
-
1) How is it possible: The first step for that is: The measured value as average is written in the RAM by the controller software a short time after the average time is expired. This is usual for embedded digital control, organized in an fast interrupt. You see the presentation color in the Slave1 in the bottom cells, this is the read RAM for DMA for telegram communication. Look there, a short time after the input value’s color is newly (left bottom bar), the same color appears in the left bottom cell of Slave1.
-
2) The telegram communication is synchronous to the interrupt or step cycle of the controller. It means this value in RAM is transmitted a small time after writing in RAM by the interrupt. presented by the read arrow bottom on Slave1, transported to the transmit output of SPE. Of course this color appears only a very small time on the SPE communication output, physically the output plug connected to the cable.
-
This value (the color) appears a little time later in the input of the slave2, then on its output, then on input on the master. You cannot follow this fast color changes, you see only breeze past the colors.
-
3) But you see that exact this color is written a little bit time later in the receive RAM of the master bottom side, on the left cell. This is the transmission of the measurement value in the SPE communication ring. Because of the data just in time approach the value from the measurement is fast transported after read out by a slave to all other stations, in this case necessary in the master. The value is written in the first two cells. The second cell comes from the slave2, which has also this measurement value (same color) or just another value from the same step time, from another part of the plant in a distance of till 1000 m. Both measurement values are available a less time later in the master controller.
-
Now, because the interrupt in the master controller is also synchronous to the telegram communication, the master controller can process this value a little bit time later after receiving. This requires exact knowledge of machine statements execution time of the application in interrupt. But this is familiar for fast controller programming also for non-communication approaches. Maybe sometimes also a fast time "spinning" (active wait) should be programmed in the controller only for the fact if a previous operation needs a too less time. Such approaches are known and familiar for fast runtime controller applications, not newly for this approach.
You see a short arrow in master from left bottom to right top, from the telegram write RAM, read and process the data, to the telegram read RAM. The same color appears on the 13th postion in the the telegram read data.
-
This calculation is done during running the telegram. The telegram transmission needs time, 10 Mbit/s is 1.6 µs per data word. The controller has a time of ~ 12*1.6 µs = 19.2 µs minus time for jitter (may be ..5 µs). A normal fast controller can process a controller algorithm (PID or such) in a time of ~ 10 µs.
-
The result of the calculation is now transported by the telegram communication in the same cycle, and it is written on the 13th postion of the received telegram’s RAM (top cells) in slave1 and slave2 a small time later. This small time is the telegram delay for shifting and the time on the line, approximately 4..6..8 µs in sum also for ..6..11 stations. The delay rx to tx in one station is only ~0.4 µs. The delay for SPI access, shifting SPI bits and shifting the SPE telegram bits needs 3.8 µs between 2 stations (1.6 µs for each shifting and 0.4 µs transportation delay per station). The delay on the cable is approximately 0.1 µs/25 m, should also be regarded.
-
Now the result of the controller can be outputted from any of the both slaves, here slave1, after it is received. It is before the end of the cycle, during the running telegram for more other data.
In sum, this approach needs a fine tuning of the time:
Meas ----+1----2--------------------------------------------------------------------------------------+--- telg rd Meas-----1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 telg pos wr master------ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 Master ----+-------------3jjjjjjj4444444444..........5--------------------------------------------------+ telg pos rd master 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 --------- telg pos wr Actuator -----1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 --------- Actuator +-------------------------------------------------5--jjjjjj6---------------------------------+
-
+)
-
1) first time of get the value from hardware
-
2) Position in telegram where this value is Rd in Meas to transported, the telegram is synchronized with the sampling time. Regard a possible calculation jitter.
-
3) The time to receive the value depends only on the communication, as described 4..8 µs.
-
4) The time where the value is calculated depends on a jitter for calculation times (
j) and the calculation time for that itself. -
5) Position in telegram where the calculated value is read in Master to transport via SPE and written in Actuator
-
6) Position where the value is read from RAM to output as actuator value, after Jitter
j
In comparison to the execution of a controll algorithm in interrupt in a single controller it is:
Ctrl-------+1-------------jjjjjjj4444444444----------5----------jjjjjj6-----------------------------------+
The additional effort for the distributed communication is:
-
Determine the position in the telegram where the value should be transported.
-
Add two times 4..8 µs, it is 8..16 µs for the communication.
-
regard in fine tuning the time where the calculation runs, depending on the telegram position.
The timing for a controller algorithm in a single controller is relaxed. The timing for a distributed system should additionally regard the time to provide the value for the communication (depends on telegram position) and the time to get first the value from the telegram.
When to use
Of course these finely graduated timing adjustments are only possible for a manual written controller software with a definitively functionality. This is especially true when fast control by split stations is required. The approach presented here also allows a dead time of only two step times, as with the single controller solution.
But, for commonly used sources, perhaps automatically generated or from higher-level tools, the usual standard approach should be applied, which uses the transmitted data only when the entire communication package is complete (data is consistent and available). A double buffering mechanism should also be used to ensure consistency of data.