Allen-Bradley bandwidth upload same as download

We have several remote sites (controllogix v28) and data usage is a huge problem. We’ve managed to set our scan classes appropriately so that our overall bandwidth usage is generally pretty low, but something that’s very confusing is that according to wireshark and our bandwidth report from the modem, our upload amount and download amount to the plc is always generally the same. Even when we were pulling down all of the information from the plc every few seconds, the up and down usage would be the same. example: 512 MB download , 511 MB upload for one day.

Shouldnt the usage be primarily upload from the PLC? Nothing else except Ignition is talking to it over the modem.

With Logix PLC’s, and actually, almost all PLC’s, you have to actively poll them to extract the data; they don’t just pump it out on a schedule.
So, you have “Hey, PLC, What is the value of SomeTagInThePLC” written, then “My Value for SomeTagInThePLC is 12345”.

You can make logix communications more efficient if you are polling for large arrays, so you ask once and receive 1000 items back

From your question, you are thinking in terms of “Upload” meaning writing a value to the PLC, but as far as your modem is concerned, just asking for a value is an upload, and receiving it is a download.

ah, I was just thinking that the request for information would be smaller than the response.

It’s a common practice in some parts of the Allen-Bradley world to make heavy use of alias tags, especially when working on a Logix program that started as an automated conversion from PLC-5 or SLC-500. They are like crack for old-school programmers, and just as deleterious as crack if one targets them when polling. If you want requests to be consistently smaller than responses, use Logix structures and arrays, nested as needed, to pack all scada-relevant data into a few top-level tags, aiming for 400 bytes or more per named tag. Keep tag names and especially structure element names short.

Another possibility would be to drop the polling approach entirely, and use producer/consumer tags or I/O packets. This approach sends packed data at intervals with implied structure. If you have a 400- byte structured tag to send once per second, you’ll get that plus 20 bytes of Ethernet/IP headers and 42 bytes of UDP/IP headers. Return heartbeats can be as little as two bytes of payload. There’s a module just for this purpose. (-:

This is true for request/reply protocols, but not true for I/O protocols. And in the Allen-Bradley case, not true for producer/consumer tags.

I’ll check it out, thanks

Still would be nice if Ignition could handle things like this out of the box…

And which box are you referring to? Ignition has package deals with selected modules, but there’s no “box” that has everything IA offers, much less what’s available from third parties. Your suggestion is like saying “Apple should include all the apps I want in the price of the phone.”

Referring to the fact that FTView and WinCC don’t require messing with scan classes and changing memory allocation just to get it working at a reasonable response time. It is entirely different than suggested Apple should include all the apps. What I’m saying is analogous to saying it should be able to make a simple phone call when it is purchased

The OP would have exactly the same problem with FTView and WinCC. It’s a protocol issue, not a product issue. The problem wasn’t response time, it was data usage. Switching protocols is one solution.

1 Like

I’m going to have to agree with Phil. Having fine control over the scan times is great for us. I was just needing to know some specifics on how the messages are being handled. I’m not sure what you mean by memory allocation. As far as handling things out of the box though, the AB driver suite has always been great imo.