Hi, how can I measure the time taken from when I toggle a boolean tag on Vision Client to Ignition to PLC?
On the Vision Client diagnostics how do I interpret tag throughput scans/second and # of tag value changes?
And also Gateway ping time represent the response time from client to ignition?
Measuring time from Ignition to the PLC is quite hard. The clocks are not synchronised, so you can’t work with timestamps.
You can measure the round-trip time (Ignition to PLC and back) by letting the PLC update a different tag and checking when that changes. The other way around works too.
But you can’t just divide it by two to get the send time. Due to the very different nature of the two involved devices, one way is likely to take longer than the other way.
The times also aren’t constant. OPC-UA works on top of TCP/IP, which is non-deterministic. Any router or switch on the way may choose when which packets are send. The aim is to send it as fast as possible, but on a congested network, this isn’t always possible. On top of that, the OPC-UA standard also allows the involved devices to delay updates. So the whole communication stack works on a “best effort” level.
The # of tag value changes is simply, the number of values that changed for the tags you are subscribed to (the tags that are displayed).
I don’t know what the tag throughput is. For me, it’s a very constant value (depends a bit on the project, but even then seems to always be between 3 and 4). So I guess it’s more related to project configuration…
The gatway ping is the time it takes for the client to send a packet to the gateway, and for the gateway to reply (so also a round-trip time). On a good local (wired) network, this shouldn’t go above 5. WiFi and WAN networks will increase that ping time.
Not just OPC/UA, but practically all of your native PLC protocols. Non-deterministic. If you need deterministic communications, you need repeating UDP transmissions (or bare Ethernet frames).
@Yfactor, your line of questioning tends to be where engineers start when they realize SCADA packages tend to have trouble with momentary buttons driving booleans. This topic has been beaten to death numerous times on this forum:
http://forum.inductiveautomation.com/search?q=momentary
This one is probably the most thorough (and contentious):
True, though we're used to working with TwinCAT for communication between PLCs, which is advertised as being deterministic. It uses ethernet, but no TCP/IP. So you can use regular switches, but you can't mix it with an existing network. So you can't connect an Ignition server to it over that network.
Thank you so much @Sanderd17 & @pturmel for the explanation.
I will definitely try the PLC update method to test it out.
yes, momentary button is giving me a bit of nightmare but I will look into the forum more thoroughly in regards to that.
Cheers
