[Logix5000] Bandwidth for Ethernet/IP produce/consume tags

[defcon.klaxon]

Hi all,

Hopefully this is a somewhat quick question:

A few of the loops in my system have physical I/O at two different PLCs. My water filter valves, for example, are in one CompactLogix PLC and some pumps in the same loop are in a ControlLogix PLC. I've set up UDTs for all the hardware.

So let's say the CompactLogix PLC's sequence (valve control) waits for a pump running status before it opens a valve, and the control is interrupted by a pump failure alarm at the ControlLogix PLC. Would it be reasonable to create the pump tag at both PLCs, and then produce at the ControlLogix and consume at the CompactLogix? I would ignore all the other data produced by the CompactLogix, save for the Pump Running bit, Fail to Start Alarm bit and Fail to Stop alarm bit. My worry is that moving that much data when I only new a few bits might eat up bandwidth in the Ethernet/IP connection, but I don't know if that's me worrying way too much. I just don't know at what point my RPi would be adversely affected and maybe that's a standard way to do things and I'm worrying too much. The other way I could do things is to move/copy the data from the needed bits into standalone tags, and then produce/consume those specifically. That would be a good amount of add'l work though, and I'd rather not do it if I can help it.

My guess is that my system (a water treatment plant for a somewhat rural community) isn't going to push the limits of Ethernet/IP but I don't really have a good idea for how much data I should be passing back and forth, and if sending everything is going to be bad practice. I'd love to hear what more experienced people would say, thanks a bunch.

EDIT: the UDT for the Pump is 292 bytes, which happens to be the largest UDT I have; some are as small as 4 bytes.

 

[thumperbs]

Yes, you are worrying too much is the simple answer. The main issue I have run into with produce and consume tags is the total connections limitation. With that said my standard comms UDT consists of DINT[50], REAL [50] and CONNECTION_STATUS. This is my go to for all inter-pant networking and even with an average of 2-3 connections per processor I have had no issues sparing one integrator who ran a clone processor on my network, causing a ghost consumer. Love, love, love produce/consume tags. If you have the ability to bring your process down to make the changes and do a download, go for it!

 

[defcon.klaxon]

Update:

I found this link that describes the bandwidth of Ethernet/IP and AB PLCs:

http://www.deltamotion.com/support/...ls/EtherNetIP/EtherNet_IP_I_O_Performance.htm

but the article refers to the bandwidth in the measurement of packets per second, which threw me for a curve ball since I've been focused on bytes per UDT. But that being said, I'm using a ControlLogix with the 1756-ENBT module, which provides a bandwidth of 90% of 5000 packets/sec. So at least that's some metric to go off of.

This presentation (look to page 13) defines what a packet is; it's the CIP payload along with TCP/IP info for addressing.

https://scadahacker.com/library/Doc...well - Fundamentals of Enet-IP Networking.pdf

So referencing the first link and working through the bandwidth vs number of connections vs RPI, it sound seem that in my admittedly small(ish) system of three ControlLogix PLCs talking locally, even if I'm sending the entire UDT for everything, I should have plenty of bandwidth so long as my RPI doesn't need to be screaming fast (which it doesn't).

I feel kiiiiiiind of ok moving forward with this but I would still really appreciate someone more experience chiming in with their suggestions for best practices and what they've dealt with in the field.

Thanks all.

 

[defcon.klaxon]

Yes, you are worrying too much is the simple answer. The main issue I have run into with produce and consume tags is the total connections limitation. With that said my standard comms UDT consists of DINT[50], REAL [50] and CONNECTION_STATUS. This is my go to for all inter-pant networking and even with an average of 2-3 connections per processor I have had no issues sparing one integrator who ran a clone processor on my network, causing a ghost consumer.

Awesome, thanks so much man. That really gives me a boost of confidence!

If you have the ability to bring your process down to make the changes and do a download, go for it!

Yeah I'm actually writing the code for a major overhaul (replacing Siemens S7 system from the early 90s) so I have the simultaneously liberating and yet terrifying ability to pretty much do whatever, haha. Luckily during the rainy season the plant will be down so I'll have several months to iron everything out.