Good morning, I have a client asking about the use of the GDS. He understands the use of Ports to “abstract” and to share the I/O Data from the pheriphery between programs or tasks but he asks if the Ports are always the best way to share data between tasks. For instance, he talks about a Modbus application where the PLCNext serves a lot of data to a modbus client. Is it the best way to declare these Modbus registers as Ports or maybe it would be no necessary to work with ports but only with global variables that could be reachable for another tasks? Imagine a big memory map that should be read for another task.. how would be the best way to handle these memory map? Would be with Ports the best way? A declared Global (no Port) Variable in PLCNext is placed in the GDS area? What kind of limitations exist in terms of memory, buffer refreshed time etc has the GDS? I heard about a kind of three buffer technology that GDS uses to better performance of the buffer latch and refresh in the GDS. Could you explain breafly how it works? Sorry for the questions but sometimes the client questions go in the deep. Angel
Hi Angel, Those are difficult questions to answer without a deep-dive, but hopefully this will help: Question: Are Ports always the best way to share data between tasks? Answer: It is possible that there are situations where ports would not be the best way to share data between tasks, but ports should always be the first option considered. Ports are fast, simple to use, and they guarantee data consistency between programs. If your customer does not need these features, and if they are comfortable creating their own alternative inter-process data transfer mechanism, then they are free to do so. The use of the Global Variable table is possible, but it makes the customer’s code less portable (e.g. more difficult to package into a User Library and share with other projects), without adding any significant benefit. For the Modbus example, I recommend considering using Ports as a first option. Port variables can be updated as quickly as Global variables, and I cannot imagine that this will be a bottleneck in a Modbus comms application. I don’t know if there is any documented total size limit on GDS variables, but I imagine that this is no worse than the size limit on Global Variables. The GDS buffer refresh time is also no worse than the update rate of PLC Global variables. The theory behind the quad-buffer mechanism that the GDS uses is described in this paper: https://www.researchgate.net/publication/3350832_Four-slot_fully_asynchronous_communication_mechanism - Martin.
Hello Martin, Can you provide the content of this paper to us? I have tried to create an account on Researchgate, it looks easy, but at the end they refused my request. ? As far as I know, you need to be a member to have access to such a paper. Regards, Sven
Hello Team, a customer is asking me about the way to get access to global variables from a C++ or C# Program without using In/Out Ports. If you could share a little explanation about it, I think would be enough. Thanks Angel
@Sven I’ll need to check if I can share the paper … @Angel: How to access to global variables [in an IEC program] from a C++ or C# Program without using In/Out Ports.
1. OPC UA (no additional IEC programming required. C++ or C# program must include OPC UA Client functionality) 2. REST interface (no additional IEC programming required) - [this example](https://github.com/PLCnext/HTML5_with_REST) on GitHub might help. 3. Modbus/TCP (small amount of additional IEC progamming required. C++ or C# program must include Modbus/TCP Client functionality) 4. TCP Sockets (more challenging IEC programming required) 5. Some other inter-process communications mechanism that you create yourself.- Martin.