# Logix Driver Maximum Speed **URL:** \ **Category:** Ignition\ **Tags:** opcua\ **Created:** [July 12, 2024, 3:52pm UTC](https://forum.inductiveautomation.com/t/logix-driver-maximum-speed/93153 "2024-07-12T15:52:03Z")\ **Posts on this page:** 8\ **Page:** 1
**Author:** ![Julian\_Islic](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/julian_islic/32/57055_2.png) [@Julian\_Islic](https://forum.inductiveautomation.com/u/Julian_Islic)\ **Post date:** [July 12, 2024, 3:52pm UTC](https://forum.inductiveautomation.com/t/logix-driver-maximum-speed/93153/1 "2024-07-12T15:52:03Z")
Hey Ignition Gurus, 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? Any input or experience or insight is welcome. ---
**Author:** ![Kevin.Herron](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kevin.herron/32/7259_2.png) [@Kevin.Herron](https://forum.inductiveautomation.com/u/Kevin.Herron)\ **Post date:** [July 12, 2024, 4:16pm UTC](https://forum.inductiveautomation.com/t/logix-driver-maximum-speed/93153/2 "2024-07-12T16:16:13Z")
How many tags from each Logix device do you need at high speed? How many tags on each overall? 24ms or less is probably better suited to Class 1 communication as supported by @pturmel's driver. The TCP Driver will probably not work - it will miss changes that happen faster than ~25ms apart. ---
**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\ **Post date:** [July 12, 2024, 4:16pm UTC](https://forum.inductiveautomation.com/t/logix-driver-maximum-speed/93153/3 "2024-07-12T16:16:33Z")
Not with IA driver. I have a third-party module designed specifically for applications like this: > [@Automation Professionals' EtherNet/IP Communication Suite V2](https://forum.inductiveautomation.com/t/automation-professionals-ethernet-ip-communication-suite-v2/68190): > > Automation Professionals is pleased to announce its latest EtherNet/IP Communications Suite driver module, a major upgrade to its EtherNet/IP Class1 Communications module, as a Public Beta. As of April 15, 2023, this is now a Production Release. The primary new feature is its new Generic EtherNet/IP Client Driver, a drop-in replacement for IA's Logix V21+ driver and its Omron NJ/NX driver. It does work with older Logix processors, and also works with Rockwell's MicroLogix 8xx family (ethernet… 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. ---
**Author:** ![Julian\_Islic](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/julian_islic/32/57055_2.png) [@Julian\_Islic](https://forum.inductiveautomation.com/u/Julian_Islic)\ **Post date:** [July 12, 2024, 4:46pm UTC](https://forum.inductiveautomation.com/t/logix-driver-maximum-speed/93153/4 "2024-07-12T16:46:34Z")
Hey guys, Thanks for the lightning quick response. 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. Let me know your thoughts. ---
**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\ **Post date:** [July 12, 2024, 7:21pm UTC](https://forum.inductiveautomation.com/t/logix-driver-maximum-speed/93153/5 "2024-07-12T19:21:22Z")
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. ---
**Author:** ![michael.flagler](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/michael.flagler/32/26272_2.png) [@michael.flagler](https://forum.inductiveautomation.com/u/michael.flagler)\ **Post date:** [July 12, 2024, 8:17pm UTC](https://forum.inductiveautomation.com/t/logix-driver-maximum-speed/93153/6 "2024-07-12T20:17:55Z")
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. ---
**Author:** ![humphrey.daniel](https://avatars.discourse-cdn.com/v4/letter/h/8e8cbc/32.png) [@humphrey.daniel](https://forum.inductiveautomation.com/u/humphrey.daniel)\ **Post date:** [July 13, 2024, 2:21am UTC](https://forum.inductiveautomation.com/t/logix-driver-maximum-speed/93153/7 "2024-07-13T02:21:38Z")
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. ---
**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\ **Post date:** [July 15, 2024, 1:49pm UTC](https://forum.inductiveautomation.com/t/logix-driver-maximum-speed/93153/8 "2024-07-15T13:49:01Z")
> [@humphrey.daniel](#): > > you should not expect to do so live 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.