I have a Realtime C++ program/component with some asynchronous IO.
A dedicated thread is waiting for incoming data via UDP socket and stores it into a GDS outport.
When the datagram is received the code signals a User Event.
This User Event serves as task trigger for some calculations in IEC.
The UDP receiver works as expected and sees every message (sequence number), but the IEC doesn’t, some sequences are missing or duplicated, as if the GDS is lagging behind.
Is there something I must do to ensure that when I trigger the User Event the data in the GDS port is also in sync?
are your GDS ports configured in IEC or in C++. Components are typically not configured as ESM tasks, like programs, which are instantiated and run as ESM tasks. They do only have a default update cycle of 50ms. The alternative would be an I/O driver via Pluggable I/O. But there is currently just a template in the PLCnext Toolchain 2026.0 and no other documentation available. Maybe @Martin_PLCnext_Techn can help.
I believe that the local Phoenix Contact subsidiary has been working with the customer on this aspect of their application, and a resolution to this issue has been found.
That is true, we’ve been in contact with PC NL.
We are seeing better results when using a program port instead of component port.
I need to get in touch with them to confirm whether this is a reliable solution.
The issue was not related to missing or duplicated GDS data, but to the C++ program receiving data faster than the event task could process. The program was running in an event-driven task (so there is no “period” other then the default 50ms), so GDS transfers only occurred at the 50 ms, while events were triggered every 30–40 ms, causing the mismatch. Using cyclic task running at 20ms, update faster and resolved this.