The restriction of 440 bytes for the redundancy system per-task-cycle-exchange (the AREA_SYNCRO) is ridiculous, IMHO!
Even a single ethernet frame can contain at maximum 1.518 bytes, right? (1.440 bytes would be nice)
What will it take for CODESYS to increase this area size or to give an asyncronous alternative, at least?
As of now one will have to resort to custom data exchanges for whatever that does not fit in the AREA_SYNCRO.
Doing a full SYNCRONIZE repeatedly is hardly the correct manner, either, IMHO.
I belive engineers find it hard to trust the fact that two logical systems being exposed to identical inputs shall produce the same output. For small IO only based systems, maybe, but what about commands and parameters from top level SCADA, local HMI panels for both 'Active' and 'Passive' PLC, stepping through sequences, ramping, state machines,....
Simply mirroring all state defining variables for all objects seems a more sane approach. But when the object count is 400+ alone, then the 440 bytes limit is quickly exhausted.
(Tender docs specify that 'Redundancy' shall be a manufacturer provided feature, not something cooked up by the integrator.)
Any thoughts on this are welcome.
Last edit: Ulvis 2021-11-16
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Ah, this is the CODESYS standard redundancy concept for a controller pair handling the active/standby, high availability, many names.... feature from CODESYS GmbH. You may not find it in the standard Codesys release, it is a OEM module provided by CODESYS to be integrated by the device hardware manufacturer.
But I expect the properties of the the different data areas utilized to be of the same nature for all these implementations, as they are set by CODESYS GmbH. Thus, sizes of AREA_SYNCRO, AREA_PASSIVE, etc.
I am using the PCD QronoX controller from SBC (formerly Saia-Burgess Controls, now a Honeywell subsidiary.)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Dear Ulvis,
you are right, the limit for this area is quite small. We did set the default size relatively small to make sure it is working on all platforms.
We experienced problems with bigger packets on some systems. You cannot guarantee larger packets on every possible system, IMHO.
The minimum MTU size that an host can set is 576 and IP header max size can be 60 bytes (508 = 576 MTU - 60 IP - 8 UDP), so this is the range we are in.
Device Manufacturers like Saia-Burgess Controls can use bigger values by adapting the Redundancy Toolkit if they are confident this will work stable with their controllers.
Furthermore, future versions of CODESYS redundancy will support bigger areas.
But maybe the use of AREA_SYNCRO is not the best choice in your use-case anyway.
You want to synchronize all variables, not only variables in this one area type.
In this case, you may want to use the function RedundancySynchronizeData().
This is not a full synchronize.
Regarding two systems generating the same outputs:
Commands coming from CODESYS online write and force values, visualization, OPC UA server are synchronized with the passive controller.
Of course this has its limits. On the other side, when it comes to stepping through sequences, controller stopped at a breakpoint for a long time, are you sure this really has to be synchronized? Our solution is to switch to standalone mode and re-synchronize when the system is running again.
Best Regards
Edwin
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Update: RedundancySyncronizeData() does give you full programatic control of when you syncronize the objects included in the Redundacy Configuration´s "Registered Areas" table.
Like every 1 sec, 500 msec or whatever, but not at every program cycle. For fast "in-cycle-tune" data you may want to use the AREA_SYNCRO for speedier but less volumious data sets. (There is also a AREA_PASSIVE for the reverse direction)
The maximum size of data included via "Registered Areas" is not known to me.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The restriction of 440 bytes for the redundancy system per-task-cycle-exchange (the AREA_SYNCRO) is ridiculous, IMHO!
Even a single ethernet frame can contain at maximum 1.518 bytes, right? (1.440 bytes would be nice)
What will it take for CODESYS to increase this area size or to give an asyncronous alternative, at least?
As of now one will have to resort to custom data exchanges for whatever that does not fit in the AREA_SYNCRO.
Doing a full SYNCRONIZE repeatedly is hardly the correct manner, either, IMHO.
I belive engineers find it hard to trust the fact that two logical systems being exposed to identical inputs shall produce the same output. For small IO only based systems, maybe, but what about commands and parameters from top level SCADA, local HMI panels for both 'Active' and 'Passive' PLC, stepping through sequences, ramping, state machines,....
Simply mirroring all state defining variables for all objects seems a more sane approach. But when the object count is 400+ alone, then the 440 bytes limit is quickly exhausted.
(Tender docs specify that 'Redundancy' shall be a manufacturer provided feature, not something cooked up by the integrator.)
Any thoughts on this are welcome.
Last edit: Ulvis 2021-11-16
A little context on The restriction of 440 bytes for the redundancy system per-task-cycle-exchange (the AREA_SYNCRO) is ridiculous, IMHO! might help?
It has obviously something to do with "HA" or High Availability a.k.a Redundancy. But what software/settings are you referring to?
Ah, this is the CODESYS standard redundancy concept for a controller pair handling the active/standby, high availability, many names.... feature from CODESYS GmbH. You may not find it in the standard Codesys release, it is a OEM module provided by CODESYS to be integrated by the device hardware manufacturer.
But I expect the properties of the the different data areas utilized to be of the same nature for all these implementations, as they are set by CODESYS GmbH. Thus, sizes of AREA_SYNCRO, AREA_PASSIVE, etc.
I am using the PCD QronoX controller from SBC (formerly Saia-Burgess Controls, now a Honeywell subsidiary.)
Dear Ulvis,
you are right, the limit for this area is quite small. We did set the default size relatively small to make sure it is working on all platforms.
We experienced problems with bigger packets on some systems. You cannot guarantee larger packets on every possible system, IMHO.
The minimum MTU size that an host can set is 576 and IP header max size can be 60 bytes (508 = 576 MTU - 60 IP - 8 UDP), so this is the range we are in.
Device Manufacturers like Saia-Burgess Controls can use bigger values by adapting the Redundancy Toolkit if they are confident this will work stable with their controllers.
Furthermore, future versions of CODESYS redundancy will support bigger areas.
But maybe the use of AREA_SYNCRO is not the best choice in your use-case anyway.
You want to synchronize all variables, not only variables in this one area type.
In this case, you may want to use the function RedundancySynchronizeData().
This is not a full synchronize.
Regarding two systems generating the same outputs:
Commands coming from CODESYS online write and force values, visualization, OPC UA server are synchronized with the passive controller.
Of course this has its limits. On the other side, when it comes to stepping through sequences, controller stopped at a breakpoint for a long time, are you sure this really has to be synchronized? Our solution is to switch to standalone mode and re-synchronize when the system is running again.
Best Regards
Edwin
I will most definetly give the RedundancySynchronizeData() a try.
Thanks, Edwim.
Update: RedundancySyncronizeData() does give you full programatic control of when you syncronize the objects included in the Redundacy Configuration´s "Registered Areas" table.
Like every 1 sec, 500 msec or whatever, but not at every program cycle. For fast "in-cycle-tune" data you may want to use the AREA_SYNCRO for speedier but less volumious data sets. (There is also a AREA_PASSIVE for the reverse direction)
The maximum size of data included via "Registered Areas" is not known to me.