Communications Performance
High performance simulation and PLC communications are essential for robust and trustable controls testing and virtual commissioning. ProtoTwin Connect achieves significantly lower latencies when compared to other simulation software. The read and write latency for each connected PLC is displayed in the IO Browser.
Low Latency
Control of fast-moving machines and parts requires low latency communication between the the PLC and the (virtual) machine. ProtoTwin Connect has been designed to achieve extremely low latency communications. Read/write latency can be as low as 0.1ms. When combined with our high-performance simulation engine, this allows you to perform controls testing and virtual commissioning on types of machines that are not possible with other simulation/emulation software.
| Protocol | 1 Boolean | 8 Booleans | 16 Booleans | |
|---|---|---|---|---|
| Siemens S7-1511 | S7 | 2ms | 2ms | 2ms |
| Siemens S7-1214 | S7 | 4ms | 4ms | 4ms |
| CompactLogix 5380 | Ethernet/IP | 0.5ms | 2ms | 2.5ms |
| CompactLogix 5380 | OPC UA | 0.8ms | 1ms | 1.1ms |
| Beckhoff CX9020 | ADS | 1.5ms | 1.5ms | 1.5ms |
| TwinCAT 3 (Local) | ADS | 1ms | 1ms | 1ms |
| Omron CP2E-N | FINS | 0.5ms | 0.5ms | 0.5ms |
| Mitsubishi FX5UC | MELSEC | 2ms | 2ms | 2ms |
| CODESYS (Local) | OPC UA | 0.1ms | 0.1ms | 0.1ms |
| CODESYS (Raspberry Pi 4B) | OPC UA | 0.7ms | 0.7ms | 0.7ms |
Low Jitter
Physics simulations are advanced in discrete time-steps, also called frames. Jitter is a measure of the variation in the time it takes to process each frame. Jitter is problematic for controls testing since the PLC’s clock and the simulation’s clock are distinct.
If the simulation is running at 100Hz then the entire frame budget is 10ms. During this 10ms the simulation engine must complete the full simulation pipeline, including:
- Read outputs from the PLC
- Run pre-step scripting logic
- Perform physics collision detection and dynamic response
- Run post-step scripting logic
- Write inputs to the PLC
- Populate the render buffer
The steps detailed above describe a well-optimized simulation pipeline, whereby rendering is performed in a separate thread and the reading/writing of PLC tags is ordered so as to reduce latency. If this pipeline takes more than 10ms to complete then the frame budget has been exceeded and the next frame must be delayed.
If the simulation can’t run at real-time speed then the simulation will lag behind the PLC. This can have serious implications for certain control systems. Some examples are provided below. ProtoTwin achieves extremely low jitter through its highly optimized simulation engine. This simulation engine is written in C++, which doesn’t suffer from Garbage Collection stalling the pipeline.
Garbage Collection is a process whereby memory is automatically reclaimed by the program. This eases the burden on the programmer, but it incurs a heavy performance cost. The Garbage Collector runs periodically, which causes the program to stall for the duration. This stalling can be as high as 100-200ms and occurs unpredictably. ProtoTwin eliminates garbage collection from the core simulation engine entirely, and reduces scripting memory allocations at runtime to the absolute minimum by allocating memory at initialization time.
Examples
- Measuring Dimensions: It is quite common to measure the size of parts by the time between which a sensor is blocked and cleared. If the frame budget is exceeded between when a part blocks and clears the sensor then the size of the part will be overestimated.
- Sequences: If the control logic expects certain events to happen in a particular sequence then exceeding the frame budget can cause multiple events to happen at the same time.
- Fast Movements: If a machine needs to respond quickly to events, such as a part blocking a sensor, then exceeding the frame budget can cause the response to be delayed or the event to be missed completely. One such example is the tomato sorting machine (shown below), where the motors powering the mechanical deflectors must activate within a few miliseconds of the sensors detecting an unripe tomato.
Best Practices
Whilst ProtoTwin Connect has been designed to achieve low latency communications, we can’t mitigate against certain potential performance pitfalls. It is recommended to satisfy as many of the following conditions as possible in order to gain full advantage:
Networking
- Do not connect to the PLC over Wi-Fi.
- Use a high quality ethernet cable.
- Limit the number of switches between the PC and the PLC.
- Use only high quality/performance switches.
- Use a direct connection where possible.
- Reduce network chatter.
- Use a dedicated high-performance NIC (e.g. Intel x550).
- Increase the MTU size or enable Jumbo Packet on the network adapter.
PLC Configuration
- Use PLCs designed for real-time communications.
- Configure the PLC to allow more time to be spent on communications.
- Experiment with using different protocols.
- Create tags of the same data types at contiguous addresses where possible.
- Group tags by access patterns.
Model Configuration
- Run the model in navigate mode to reduce GUI updates to a minimum.
- Use the performance monitor to help identify any performance spikes.
- Reduce the number of entities being created/deleted in a single frame.
- Reduce the use of computationally expensive physics collider types (e.g. non-convex and excessively detailed custom physics meshes).
- Prefer the use of events in custom scripts rather than
update()functions.