How Fast is AdvancedHMI CLX driver?

[Archie]

Every so often the AdvancedHMI code is optimized for speed and efficiency. The most recent is some optimizing of the ControlLogix driver for the upcoming version 3.99a.

To gauge how well the optimizing is working, I created a very simple test. An array of 1000 DINT tags are created in the PLC. To get a timing, Wireshark is started. Then a read is done of 1000 elements using:

EthernetIPforCLXCom1.Read("DINTArray",1000)

Then using the time stamps of Wireshark based on the first read (service code 0x4c) until the success response of the final partial read, the total time is calculated. The latest tests has shown a total time of 44ms to read all 1000 DINTs.

So how does this compare to other drivers? The same test was done with RSLinx and was taking several hundred millseconds, so no further testing was done. The next test was done with the Kepware OPC driver and resulted in 54ms. And finally the Automated Solutions driver was tested with a result of 55ms.

This simple test shows an almost 20% faster rate than its nearest tested competitor. If anyone has other software they can perform the same test, I would be very interested in hearing the results.

The hardware I tested with is a CompactLogix L35 and a laptop with a core i7 at 2.2Ghz.

Another quick test I did was to put 5 BasicLabels on a form and point them to 5 different tags of different types, then set the PollRateOveride to 0. Based on Wireshark captures, the update rate averages a little over 4ms. Watching CPU usage, it held around 1%. So what does this really mean? A very fast update rate with very little CPU means an HMI can be very responsive even on low end hardware. For example, I ran the same program on a low cost touch panel with a 1.8Ghz Atom processor. At that extremely fast update rate, it still only used 10% of the CPU.

[bachphi]

I wish I could test this for you. I have an L24ER and I7-2760QM, but my Ingear license just expired!

[Archie]

I tried the trial version of InGear with the sample application. Performed a 1000 DINT read with all the same hardware and repeated 5 times. The average result was 71ms to read 1000 DINTs from an array.

Here is a result summary so far:

AdvancedHMI            44ms   (version 3.99a) , 14.7ms (V3.99y Beta 32)
Kepware                   54ms
Automated Solutions  55ms   (version ? ? ? ?)  , 15.6ms (version 3.9.8 )
Ingear                      71ms
RSLinx                     about 200ms  (had to subscribe to another tag, otherwise it took 18seconds)

[bachphi]

Very cool! Super!! Let's call it AAHMI from now on.

[Archie]

Version 3.99a is now available that includes the new faster CLX driver.

[Richard Waterson]

How did you get the CLX driver to read 1000 dints in 1 shot.  I can only get 240 dints per each read or write? I'm using the driver in C#.

[Archie]

How did you get the CLX driver to read 1000 dints in 1 shot.  I can only get 240 dints per each read or write? I'm using the driver in C#.

Dim values() as string=EthernetIPforCLXCom1.Read("DINTArray[0]",1000)

[Richard Waterson]

Thanks for the reply.  I set up the read just like you showed and it reads the 1000 dint array nice and fast.  I tried to set up a write the same way but I still cant get it to write over 240 dints  or ints per write.  Is there a way to do it?

[Archie]

I set up the read just like you showed and it reads the 1000 dint array nice and fast.  I tried to set up a write the same way but I still cant get it to write over 240 dints  or ints per write.  Is there a way to do it?

The driver only supports partial packet reads, but not partial packet writes. So what you are seeing is correct. The amount of data you can write is limited to a single packet which is a 508 byte default. Once you make space for headers it leaves enough room for about 480 bytes.

[MakinStuffWork]

Hello,

I'm writing a HMI for some presses my company uses. I was curious about the read/write speed of the CLX driver so I set up a small experiment of my own using the EthernetIPforCLX driver and some vb.net code.

I have some tags in the Allen Bradley CompactLogix L45 designated for handshaking bits and some data to gather over every press cycle.

Since these tags aren't necessarily related and won't always be accessed at the same time, I tried timing out individual tag reads instead of a large array read. The tag in question had a string 23 characters long in it.

Code: [Select]


       initialTicks = My.Computer.Clock.TickCount

        For i = 0 To 999
            junk = newPLC.ReadPLC("Info_Part_Description")
        Next
        endTicks = My.Computer.Clock.TickCount
        deltaTicks = endTicks - initialTicks

        TextBox5.Text = deltaTicks
Setup:
CompactLogix L45

i5 4300u 1.9 - 2.5 Ghz / 4GB Ram

I consistently got 5.2 - 5.4 seconds for 1000 independent reads.

I hope this doesn't confuse anybody since it is in fact a very different test than what you had done.

~5ms for a discreet tag read is plenty good for me. Have you ever timed out individual reads/writes yourself? I assume there is a good bit of overhead involved in calling a read/write that you only experience once in your test and I experience 1000 times in mine.

If I knew how to time stuff out with wireshark, or even how to declare and allocate a Dint array of size 1000 (not a PLC person myself) I'd try and duplicate your test.

 
 

[Archie]

I consistently got 5.2 - 5.4 seconds for 1000 independent reads.

I think if you WireSharked this you would discover it takes a fraction of a ms for the driver to turn around from response to next request and you would find the request to response would be about 5ms. The greatest bottleneck is the response of the PLC.

Of course this type of reading would be the least efficient method of reading 1000 tags if they were all different tags. The driver has a function named BeginReadMultiple that can group unrelated tags into a single read. So now instead of reading 5 tags in 25ms, you could read 5 tags in about 6ms. The packet size is limited to 508 (minus header leaves about 480), so it is up to the user to ensure the packet size for a multiple read does not exceed the packet size.

If you use subscriptions, the driver will optimize reading of subscriptions by first trying to group elements in the same array, then using multiple read request.

[Archie]

I was inspired to implement the Large Forward Open which allows packets larger than 511 bytes on processors that support it. This makes a fairly significant improvement in performance. So I wanted to update the benchmark values for AdvancedHMI:

AdvancedHMI            14.7ms   (version 3.99y Beta 32 with CIPConnectionSize=4000)

[bachphi]

Very impressed! 3 times faster than your old record!