We're currently facing a real-time issue during SCADA integration with a robotic assembly line at our facility. The integration involves connecting multiple PLCs to the SCADA system for centralized monitoring and control. However, we're noticing inconsistent response times—sometimes up to 2–3 seconds—between commands issued from the SCADA interface and the actual robotic actions on the floor.
This delay is causing major synchronization problems between robotic stations, especially for time-sensitive operations. We've checked the basic configuration and ensured that the network is operational, but suspect the issue might be related to communication traffic overload or protocol mismatch.
Has anyone faced similar issues during SCADA-PLC-robotic integration? INS3's team would greatly appreciate any insights or recommendations, especially around optimizing SCADA communication settings, buffering strategies, or network architecture tweaks to reduce latency.
Thanks in advance for your input!

 

Welcome to AAC.

Have you sniffed the network traffic with a tool like Wireshark to get some insight into what is actually happening on the wire?

 

There is a HUGE difference between the requirements for monitoring a system and actually controlling multiple independent devices to work in a synchronized manner. The two different activities have totally different requirements. Probably you are trying to get the system to do what it was never intended to do.
So I suggest contacting the robot's manufacturer's control's group.

 

if everything works but comms are slow, you may want to take a look at the network/utilization, switch configuration and topology, normally network loops are a bad sign but in some cases they are done on purpose for redundancy and network switches need to be able to handle that correctly and not creating network storms. when redundancy is needed, configuration need to be done carefully. this is where WireShark and network analyzers come in. it is also a good idea to segregate production and office networks to reduce base load. also check SCADA settings. if every tag is set to update every 50-100ms and there is a lot of tags, you will run out of bandwidth. things that do not need rapid update can be set to refresh at slowever intervals.

 

I've seen it as communication problems - protocols will, in the background, do retries if bad CRC etc. and you don't really know the packet error rate is high until things get ridiculously slow. Look at retry counters.

Ethernet can go mysteriously slow if the cable is (twisted pairs stretched) damaged during cable pull at installation, wrong CAT rating, too long, bad RJ jacks, Ethernet switch is misconfigured low quality etc.
RS-485 is can be misplaced termination resistors, a bad line driver IC or grounding problems.

Some things to think about, I don' t know the comms or the site, size etc. but removing nodes to see if they are jabbering or configured wrong I would look at, running some new cables temporarily on the ground, smaller network hubs etc.
I guess try to figure out if it's H/W or S/W problem.

 

We faced a similar problem during integration of SCADA with our robotic packaging lines last year. In our case, the main bottleneck was the polling frequency and communication protocol settings. Here’s what helped us:

• Switch to event-driven communication wherever possible (e.g. OPC UA subscriptions) instead of constant polling to reduce traffic.
• Check PLC scan cycles and SCADA polling intervals – mismatch here often causes delays.
• Prioritize critical tags and reduce the update rate for non-essential data points.
• Ensure that network switches are managed and QoS is configured to prioritize control traffic over general plant network traffic.
• If using Modbus TCP, optimize frame sizes and consider switching to protocols with lower latency like EtherNet/IP if your devices support it.

Finally, review the buffer settings on SCADA and PLC side – sometimes increasing or decreasing buffer sizes helps stabilize real-time performance.


Hope this helps stabilise your integration. Did my<Mod:deleted Off Topic link>earlier while reviewing our SCADA configs – efficient mornings all around today.

 

As a desperate alternative, some robots have external I/O that can be used right inside the control program. I was able to use that to link a load-pickup fixture with the robot part grab for a press load operation that moved the human many feet away from the press. It worked very well .