If the Ignition gateway is not in the same physical location as the PLC, the response time is dominated by the WAN travel time. Don't poll Modbus devices over a WAN if you expect them to carry significant numbers of tags.
1 Like
I completely agree.
In my experience, even when operating behind a router and over distances of several hundred kilometers, Ignitionâs current ModbusTCP driver performs exceptionally well. It can efficiently read and write a large number of variables, and any performance limitations are generally due to configuration rather than inherent driver restrictions.
I try to keep these premises in mind.
To achieve optimal performance, consider the following best practices:
- Strategically Define TagGroups: Organize tags in a manner that reflects logical groupings to minimize communication overhead.
- Increase Simultaneous TCP Sockets: Where supported by the device, utilizing more concurrent TCP connections can improve throughput.
- Create Consecutive Modbus Maps: Configure modbus maps inside devices with registers in consecutive order to streamline data retrieval.
- Fine-Tune Timeout Settings: Adjust the timeout parameters, especially for Ngate-type gateways, to ensure reliable communication. If the timeout on the TCP/RTU gateway is longer than the timeout in the device configuration on the ignition gateway, there are many problems when the communication is not stable or there are incorrect readings to the device.
- Enable the âSpan Gapsâ Option: Activate this feature if the device allows reading from memory areas without mapped variables, which can further enhance efficiency.
By implementing these strategies, we can significantly optimize performance regardless of physical distance or grid constraints. In solar plants where there are âtoo manyâ variables to read, it is paramount to take all of this into account.
This is my humble opinion and I share it with you in case it can help someone.
Thanks for your humble opinion, friendly LLM.
7 Likes