timestamping for SOE modules
How to Configure external time stamping for AlarmCond or SimpleEventDetector block for SOE modules (DI830).
Asked 4 months ago
Answers
0
When using SOE timestamps, there is an additional parameter (ExternalTimeStamp) which you need to set to the hardware path of the module / channel (e.g. 0.11.101.6 ...). I believe the Control Builder M's online help will outline how this is done...
The amount of SOE events possible per module and time period is limited. As far as I can recall, 10% of the module bus messages is set aside for acyclic data such as SOE event data; e.g. if you scan the module bus at 100ms, it is possible to send one acyclic message every 1000ms. A long burst of SOE events may flood the acyclic data buffer in the IO module and prevent the CPU from gaining access to the high resolution SOE time information. In that case, the alarm & event will be tagged with the coarse 61131 program scan time.
For overall performance reasons, the module bus scan time should be set as slow as possible. A rule of thumb is to run the module bus twice as fast as the fastest module bus dependent task/application running in the controller.
Flooding SOE buffers and incorrect setting of SOE / HW path will generate error messages in the controller log. Therefore, make it a habit to check it periodically after download during application development.
The amount of SOE events possible per module and time period is limited. As far as I can recall, 10% of the module bus messages is set aside for acyclic data such as SOE event data; e.g. if you scan the module bus at 100ms, it is possible to send one acyclic message every 1000ms. A long burst of SOE events may flood the acyclic data buffer in the IO module and prevent the CPU from gaining access to the high resolution SOE time information. In that case, the alarm & event will be tagged with the coarse 61131 program scan time.
For overall performance reasons, the module bus scan time should be set as slow as possible. A rule of thumb is to run the module bus twice as fast as the fastest module bus dependent task/application running in the controller.
Flooding SOE buffers and incorrect setting of SOE / HW path will generate error messages in the controller log. Therefore, make it a habit to check it periodically after download during application development.
0
I have a test in my lab using a DO810 wired to a DI830 with SimpleEventDetectors and SOE
Hardware tree with DI830 module
Sample of variable definition and call to SimpleEventDetector() from Structured Text. Notice the ChId strings pointing out the module bus address + channel of DI830
Controller log warnings when SOE buffer is overflowing (due to too slow module bus scan time vs SOE event generation)
W 2020-12-15 18:50:42.204 Unit= _SWPHMbus C117 4901 Event overflow in module 0.11.102
W 2020-12-15 18:55:42.194 Unit= _SWPHMbus C117 4901 Event overflow in module 0.11.102
W 2020-12-15 19:00:42.184 Unit= _SWPHMbus C117 4901 Event overflow in module 0.11.102
Control Builder M's OnLine Help for AlarmCond detailing the use of ExtTimeStamp
Hardware tree with DI830 module
Sample of variable definition and call to SimpleEventDetector() from Structured Text. Notice the ChId strings pointing out the module bus address + channel of DI830
Controller log warnings when SOE buffer is overflowing (due to too slow module bus scan time vs SOE event generation)
W 2020-12-15 18:50:42.204 Unit= _SWPHMbus C117 4901 Event overflow in module 0.11.102
W 2020-12-15 18:55:42.194 Unit= _SWPHMbus C117 4901 Event overflow in module 0.11.102
W 2020-12-15 19:00:42.184 Unit= _SWPHMbus C117 4901 Event overflow in module 0.11.102
Control Builder M's OnLine Help for AlarmCond detailing the use of ExtTimeStamp
Add new comment