We are going to be building a package handling solution for one of our customers and are concerned about the high speed transactions that are required to take place.
Our customer requires an OPC update rate with and Allen Bradley L84ES, L82ES processor to be 24ms or less. We also require working with a SICK Scan tunnel that is going to be connected via TCP driver that also requires these high update rates.
This requirement is coming from our customer requiring a package handling speed of 7750 parcels per hour which is approximately 2.15 parcels per second.
I had a meeting with our inductive Sales Rep about this topic and their technical team mentioned that there is no real defined limit on the OPC server and that it more relies on the specific driver that is being used, rather than the OPC Server itself.
From my research, it seems that it is difficult to get under the 100ms when it comes to polling tags.
Has anyone done any high speed implementations with ignition using the logix driver and have you observed any speed limits that have been challenging to overcome?
I have a third-party module designed specifically for applications like this:
Note that java's garbage collection can produce processing stalls in the tens to hundreds of milliseconds, redundancy failover is typically tens of seconds, and gateway restarts are typically tens of seconds to minutes. You will certainly need some buffering in your PLC to cover applicable cases.
You will likely need to use my module's class 1 connection capability to keep latency down in such an application.
So @pturmel, this sounds very promising. Is there any numbers you can put behind these efficiency gains? My goal is to determine if I can meet customer requirements with your module.
Lets say I have 100 tags that need to be updated at <24 ms. Do you think that these speeds are achievable or do you think the efficiency gains are more about supporting a large volume of tags vs speed of a few tags.
I have a client running 25ms samples for a Keyence vision system that requires 100% inspection, recording several values per sample. Running through a ring buffer in a L16 processor so that any hiccups don't lose anything. Every sample is handshaked, and delivered up to ten at a time. This allows the Ignition connection to run at ~100ms while catching up quickly if any packets are dropped.
I consider the above a light load. The module can handle 100 simultaneous I/O buffer connections, each delivering a 496-byte payload per RPI. RPIs down to about 50ms are practical.
One of my past projects that inspired this module's development recorded thousands of unique tags at 100ms intervals.
The server needs to be rather beefy for high packet rates, with low latency optimizations. Given that, the database is likely to be the limiting factor.
I think your application is easily achievable. It is non-trivial to set up.
I would also confirm that they're not talking about I/O update rates to the PLC and the RPIs between I/O and the processor. 2.15 parcels per second and 25ms is a big difference. Even if you're doing 5 parcels per second, I would think double that rate at 100ms to try to guarantee data comes in would be fast enough, but not knowing your application or the reasons for that fast of an update it may not be enough.
I'm not sure why you need these speeds. The PLC would connect directly to the scan tunnel to control diverts or whatever decisions those scans are used for.
If your trying to store snapshots of data for each PLC scan for some reason, you should not expect to do so live. Populating a buffer for your scada to consume will survive minor network interruptions and will generally yield more consistent results.
Databases aren't great at low-latency recording, to be sure--it conflicts with their transactional assurances--, but almost-live is certainly doable. Having assured recording for production is a necessity in applications that require 100% inspection, and a handshake to the PLC to indicate that it has happened for each record is often required. Ignition can do this, even if it is a bit beyond the "Supervisory" part of SCADA.