I currently have a testing requirement where my users need me to provide information on the communication latency between VC and various PLC brands (we only need to test one communication protocol at the moment), I have asked testers I know in other areas and they have given me a very cumbersome process to go through, and I’m curious if there is an official VC test standard on this that I can provide?
Thanks in advance to anyone who responds! 
Note that you can’t guarantee any real-time response time or latency with VC anyway as VC is not a real-time application and neither are the connection protocols / stacks that VC uses. Thus any number of factors affect the realized communication latency.
1 Like
Thanks for the quick reply!
So, does this mean that testing any communication delay is kind of impossible? And like Mitsubishi they advertise that the FA interface supposedly achieves a 20MS comms delay, where does that come from?
It is possible to test and get some value for “typical” or average delay, but in practice you will need to deal with things like certain UI actions taking 1-2 seconds during which VC will not respond to anything, and smaller random delays which may take e.g 100 ms when the average is e.g. 10ms.
On Windows and standard Ethernet level there can also be random delays, but usually those are smaller.
Then there is of course the general issue that how the simulation layout is built affects the performance a lot. Typical mistakes like causing component rebuilds cause delays from some milliseconds to even seconds each time. Even rendering is synchronous, so if your viewport works at 1 FPS then your communication can’t be any faster either.
Even on the PLC side the communication such as OPC UA server updates are not usually realtime, the requests are run as some lower priority or even completely async task from the main logic loop execution.
All that being said, there are significant differences in the average communication delays between the VC connection plugins because the some of the communication protocols are just very crude and inefficient for such purpose where “random access” of many independent PLC tags is needed. The performance of OPC UA servers on some PLCs is also quite poor due to limited hardware resources and design for slow access such as HMIs, not for constant IO read and write.
1 Like
The way I’m using it is, in the simulation environment, I’m only using a cube with two python scripts for doing data updates and logging the current computer time, the PLC and the simulation environment are connected through the component properties, and a total of 1000 pairs of DInt types are connected, and I’d like to test the data related to the communication by monitoring the data reads and writes including the packet loss, latency, and so on,… But I asked my friend who is doing other aspects of testing, he thinks there is something wrong with the way I am testing, he thinks I should understand the data of all aspects of VC, including the underlying Python and such scripts how they make update calls, neither he nor I understand these data, he is not even a VC software maker, which makes me think of coming to the forum to ask if there is any good way.
Do you see a problem with the way I’m testing this, and if so, you’re welcome to get back to me at any convenient time! 
Well, my point is that your expectations need to be realistic. It is not possible to do testing which would accurately tell what kind of communication response time you can get from connecting VC to certain brand of PLC as it will always vary on case-by-case basis.
Further, it is not possible in general to get any bounded maximum value for such response time, because VC is not implemented as a realtime software application, and it is not running on a realtime operating system. Thus it may always take up to infinite amount of time to respond to any input.
For many use cases this is fine, but for some it is a deal-breaker and then some other software and hardware solution must be used.
What you might be able to test and measure is “best possible” communication or response time. For some PLCs and communication protocols it could be 500 ms, while others 2 ms. The important variables affecting this are mostly just the type of network connection, protocol, and how many / what variables are read and written. For some protocols it might also matter if the variables are laid out in adjacent memory locations on the PLC or not.
1 Like
Well, maybe I should give it to my colleague in charge of communication 
, it looks like I should drop this test.