Siemens and Allen-Bradely PLC driver speed

Hi all,

I am investigating various solutions for data capture from PLC's and I have stumbled upon Ignition since it has a Driver for Siemens. The main factor that I am interested in, is the amount of tags I can read per second from the PLC.

After reading some other topics it seems that this would be an "it depends" question, so to flip it around, what are the factors affecting the amount of tags I can read per second with the ignition and Siemens driver? So far I have observed that changing the CIP value in OPC UA device settings does change the amount of tags per second increase but I am not certain this wouldn't cause any issues in the future.
The PLC in mind is Siemens S7-1500s.

Thanks all

I don't have any hard answers for you.

I can only offer less tangible advice, like making sure the network connection is local/good, that whatever the PLC program is actually doing may influence how much time is left over for comms, and that whether or not other systems are also making and using S7 connections will also matter.

This won't be relevant for a connection to a Siemens device.

1 Like

The S7-1500 also supports OPC UA, so if the overall number of tags you need to monitor (Monitored Items in OPC UA terminology) is less than the number of Monitored Items supported by the hardware model you'll be using, you don't have to worry about "tags per second" because OPC UA subscriptions are report-by-exception.

Hi Kevin,

Thanks for you fast reply and advice.

I have also been testing Allen-Bradley PLC and with default settings and I got 500 tag readings per second.
Now what I am trying to achieve is 10.000 tag reads per second or even more and I know that OPC UA is not meant for this. Do you know if it is even feasible to do that with Ignition and what would be the hardware requirements for this?

I have found this article that mentioned Large Historian configuration with 8 Cores (4 GHz+), 16GB memory, SSD able to do 5,000 - 10,000 tags per second?

Ignition Server Sizing and Architecture Guide | Inductive Automation

@Edy_Moc,

We are currently busy with a Siemens project and opc UA communication with onboard opc server and it's really not mean for high speed monitoring. I think you will be better with the siemens driver with the drawback of non optimized db so bee sure to structure your db in a logical way to avoid lost of memory (Bools with bools, int with int,...).

I've tested the way of an external opc UA with this server OPC-Server for common PLCs
But not with a read of 10000 tags /sec. But it was way faster that onboard opc UA.

For hardware we are using this model from siemens 6AG4141-5BC00-0GA0
But you can find better value in other brand like onlogic helix 500.

Regards

1 Like

That is untypically terrible performance for modern Logix controllers. You should be able to optimize to read ten thousand values per second without difficulty.

Rockwell is just better at this than Siemens. A lot better.

10,000 tags/s with the Logix driver is generally attainable.

Subscribing to 10,000 tags @ 1s doesn't mean storing 10,000 values/s unless these tags are always changing every second...

Thanks all for the answers, this sheds hope that I should be able to achieve my goals.

Given that Rockwell is way better than Siemens, I still get back to my initial question:
What are the factors affecting the amount of tags I can read per second (given that the tags change every second), for Rockwell PLC in this case?

Currently I tried to change the CIP value to 50 in OPC UA Device settings which allowed me to read 1500 tags per second.

The setup I am working on is:

  1. Allen-Bradley PLC 1756-L84ES with a program incrementing each tag value by one, total of 5000 tags.
  2. Ignition server with 4GB of RAM

Is there any impact depending on where the Ignition designer is running or is there any specific settings in Ignition Designer to have an effect on it?

Also, I can see that communication load of the PLC is around 80%, would the bottleneck in this case be the communication driver and would external Ethernet port help?

Lastly, I'm new to Ignition so sorry for such specific and pushy questions - your help here means a lot.

If you're talking about the Concurrent Requests setting, this is too high. Please be specific about what setting you are changing.

No, but it matters where the Ignition Gateway is running.

No, external ethernet port won't help. The L8x series already has its own processor core for comms.

What kind of tags are you trying to read? Are any of them AOIs?

How are you measuring tags read per second?

Also, are these individual elementary tags or such aliases? Or arrays or UDT instances? The fundamental unit of access/optimization is the top level tag, so 5000 individual DINTs will be way slower than an array of 5000 DINTs.

Considering that this topic is about Siemens, the Logix discussion should probably be a new topic. But read this and the links within first:

Dear @Kevin.Herron and @pturmel, thanks for your answers and following questions. I have read your suggested forums and tried to find all the answers to your questions. I have also changed the name of this Discussion so it mentions both Siemens and Rockwell.

The "CIP connection Size" value that I mentioned before is found under Config>OPC-UA>Devices>Edit>"Show advanced properties". Currently I have it set to 50.

The Tags are all individual INT type tags, none of them are AOI(If you refer to Add on instruction) and no UDT's are also in the program. The program basically just increments each tag value by one until it reaches 100000 and then is reset to 0. I have 5000 tags in the program.

After some testing, this is my current output shown below. I am relying on Device> Status > overview in Ignition Getaway and I assume that "Throughput(mean)" shows the amount of tags which are updated per 1 second, please correct me if I'm wrong.

With lower CIP connection Size values I have noticed the Communication load increase to 90% and Overload on the Status overview increase to 400%.

At this point I am still unsure if Allen-Bradley driver in Ignition can achieve 10.000 Individual tag update per 1 second and what would be the factors affecting this. Also, could you direct me to some sources that explain what does to overload chart indicates and what is the calculation based on?

Throughput is Requests per second, and generally a request should be for multiple tags, but you've seriously knee-capped yourself by setting the CIP Connection Size to 50. It's 500 by default, and usually setting it higher yields better performance, along with the Concurrency setting.

1 Like

Thanks for the explanation. Previously you have mentioned that "10,000 tags/s with the Logix driver is generally attainable" and given that the Throughput was not showing what I assumed it shows - could you share how did you do it and what would be the correct way to measure how often each tag change is recorded per second?

The Monitored Item count on that page (5000 in your case) shows how many items are being sampled (tags). This is the closest measure you’ll get. Configure 10,000 tags @ 1000ms and then check that the load is indicating they are being sampled in under 1000ms.

And actually have the PLC changes them (randomly, perhaps) to cause subscription updates for everything on every interval.

Comming back with some results that I got from my testing. Hopefully will be helpful for others that are new with Ignition.

After doing so as you said, I can conclude that with my setup and the default settings(CIP Connection size set to default 500) it is not possible to update 10.000 tags @ 1000ms since the "Actual sampling time" is 1,468ms.

I can also see that CPU and Communication load is very high.

Nevertheless, with CIP Connection Size set to 4000, the actual sampling interval of 1000ms is achieved.

The main questions that I have now: is there any other configurations of Ignition/hardware setup I should consider to achieve more tags monitored @ 1000ms or to have 10.000 tags monitored at faster sampling intervals?

Thanks

Increasing the Concurrent Requests setting can sometimes help, but in this case with your comms load already near max I don't expect much difference.

The other thing you can do is change the tag layout/structure in your PLC program. It looks like you have 10,000 individual tags right now. You'll probably observe some differences if you organized this into e.g. 10 arrays of 1,000 or 100 arrays of 100. Structures packed full of tags would likely be more efficient too, but not as efficient as arrays.

1 Like

I would expect a huge improvement. If the tags are REAL, an array of 10000 would be only ~80 requests, instead of 910 (at 500 byte buffers), with likely similar response times.