Control Logix - Produce / Consume RPI?

Hello Ladies and Gents,

I have some PLC to PLC communications using Produce and Consume.

The data is not time sensitive, and I really only need a turn around of 1-2 seconds.

The current program has RPI set to 20ms, this seems overkill to me.

The IT group is saying that there is a lot of traffic (+200K packets in 5 minutes).

My instinct is telling me that 20ms is way to zippy for this, and I would like to set this to 1000 ms.

Am I heading in the right direction?

Also, can this be changed online in run, or do I have to save/upload --> go offline --> change RPI --> download.

Thanks in advance,

I believe this can be done in run but not sure of safety produced/consumed. You'll want to do this at both PLCs.

I set this up in two test Compact Logix. L33ER to L36ERM (FW 32).

You have to go to program mode to change the RPI setting.

These are not safety p/c, just PLC to PLC, nothing time sensitive or critical (process control call for water)

If you only need to have new data every 1 or 2 seconds, requested packet interval of 20 msec is way too low. You should be fine with 500 msec.
With regards to whether this change can be made online, I am not so sure about this. I do more EtherNet/IP adapter development, not so much machine development, so I may be wrong. EtherNet/IP adapters use produce/consume connections for implicit messaging, that is, exchange of process data with scanner (PLC), after a connection is successfully established. Two PLCs basically use (I suppose) similar mechanisms to establish a connection, and in the Logix5000 project this is setup in the IO section of the project. Thus I am not sure if the Logix 5000 tool will let you do this download directly without setting the PLC into remote programming and then back to run mode, as the parameters for the connection settings need to be loaded by the processor on the EtherNet/IP parameters, and not just the control image.
Also, if the network is not using managed switches, I would recommend you setup only unicast connections for the produced data, because if your switch does not have IGMP snooping filtering function the packets being produced will the forwarded to unneeded ports of the switch, which will significantly increase the probability of your IT colleagues getting quite upset.

AlfredoQuintero said:

If you only need to have new data every 1 or 2 seconds, requested packet interval of 20 msec is way too low. You should be fine with 500 msec.

Click to expand...

Thank you for the confirmation, I will try this.

AlfredoQuintero said:

With regards to whether this change can be made online, I am not so sure about this.

Click to expand...

PLC to PLC RPI change can be made online, just not in RUN, needed to be in Remote Program.

AlfredoQuintero said:

Two PLCs basically use (I suppose) similar mechanisms to establish a connection, and in the Logix5000 project this is setup in the IO section of the project. Thus I am not sure if the Logix 5000 tool will let you do this download directly without setting the PLC into remote programming and then back to run mode, as the parameters for the connection settings need to be loaded by the processor on the EtherNet/IP parameters, and not just the control image.

Click to expand...

To add the Producer to the Consume tag, the Producer needs to be in the IO Tree. This has to be done Offline.

AlfredoQuintero said:

Also, if the network is not using managed switches, I would recommend you setup only unicast connections for the produced data, because if your switch does not have IGMP snooping filtering function the packets being produced will the forwarded to unneeded ports of the switch, which will significantly increase the probability of your IT colleagues getting quite upset.

Click to expand...

The network is fully managed by IT, and the switches they are using are unknown and I am on a need to know basis, they will not release any information about server or network specifications, it is guarded information. Based on what I have seen, the switches in the IDFs are high end, and home runs to every device in the panels.

Thank you for the reply, I really appreciate the input you have provided!!

celichi said:

The network is fully managed by IT, and the switches they are using are unknown and I am on a need to know basis, they will not release any information about server or network specifications, it is guarded information.

Click to expand...

If the PLCs run the core, profit-making process of the business, that clueless and stupid approach by IT will be a problem someday.

Leave. Now.

drbitboy said:

If the PLCs run the core, profit-making process of the business, that clueless and stupid approach by IT will be a problem someday.

Leave. Now.

Click to expand...

I think I am with you. It seems like ALL business decisions are being driven by IT, Lawyers, and Accountants.

WHAT? We don't make any Chips or Vaccines in North America? HOW COULD THIS BE!!!!! --> Ask the bean counters.

Now all steel production is being sent to countries that don't give a #$%* about the environment...steel will be the next commodity that is extinct in North America.

celichi said:

The current program has RPI set to 20ms, this seems overkill to me.

The IT group is saying that there is a lot of traffic (+200K packets in 5 minutes).

My instinct is telling me that 20ms is way to zippy for this, and I would like to set this to 1000 ms.

Click to expand...

If there is one consumer for this data every 20ms then we are talking about 50 packets per second (pps). If there are two consumers, then 100 pps. That is not heavy traffic whatsoever. 200K packets in 5 minutes is 660+ pps. This is light traffic, not heavy. It worries me that they consider that to be "a lot of traffic". My rule of thumb is to set the RPI 2-4 times faster than you need the data. If I need it once per second, I will set the RPI somewhere between 250-500ms.

I would think they would be more concerned with what type of traffic they are seeing. Such as broadcast or multicast traffic.

The default message type for EtherNet/IP is multicast. This is efficient when you need to send the same data to more than one recipient. However, if the Ethernet switches do not have IGMP Snooping capability, they can treat multicast messages like broadcast messages. That would greatly concern your IT people. Broadcast type messages are evil to the IT world. These broadcast type messages reach the routers and can impact network performance. When IGMP Snooping is enabled, these messages do not reach the routers.

This is why the "right" switch with the proper capabilities is so critical on an EtherNet/IP network. If you only need to exchange data with one other device, then you can configure your message to use Unicast instead. This would eliminate the broadcast effect. It would not reduce traffic, but IT won't care about unicast traffic.

If you connect to your EtherNet/IP module (like an ENBT or EN2T) using a web browser, you can see information on packets per second and you can get an idea how much traffic that device is seeing.

OG

celichi said:

Thank you for the reply, I really appreciate the input you have provided!!

Click to expand...

No problem. Glad to know it was useful. By the way your avatar is hilarious.

AlfredoQuintero said:

No problem. Glad to know it was useful. By the way your avatar is hilarious.

Click to expand...

Haha, thanks. One of my points that I try to make to new programmers/engineers. Document your code, and document what the bit means when it is on.

I recently had a new one, it was a tri-state digital input...

Operaghost said:

If there is one consumer for this data every 20ms then we are talking about 50 packets per second (pps). If there are two consumers, then 100 pps. That is not heavy traffic whatsoever. 200K packets in 5 minutes is 660+ pps. This is light traffic, not heavy. It worries me that they consider that to be "a lot of traffic". My rule of thumb is to set the RPI 2-4 times faster than you need the data. If I need it once per second, I will set the RPI somewhere between 250-500ms.

Click to expand...

Yes, I wasn't sure what was considered heavy or not. Thanks for this. I like your rule, 2-4x faster than you need the data. That is a good suggestion.

The other issue, is that I was sort of forced to go P/C, I really just wanted to have msg READ instruction triggered every second. What I usually do, is in my data block increment a DINT by one, this is sent with the data. The PLC that is reading the message is always looking for this value to change (message number). When the message number reaches 200 million, it can be reset back to 0. It is easy to detect comm loss or PLC in Program mode with a message number.

The reason I like READs is because they are searchable.

Anyway, I was talked into P/C and they wanted the comm loss based on IO fault, which does not account for stale data (program mode is not detected in IO fault).

When I suggested using an UDT to include first member as CONNECTION_STATUS, was told that is not needed.

Now we are having network comm loss issues, and it my issue and this is a little bit political, hurt feelings etc.

These are all 1 producer and 1 consumer, so checking for unicast is on my list. Thanks for that information Operaghost!

celichi said:

When I suggested using an AOI to include first member as CONNECTION_STATUS, was told that is not needed.

Click to expand...

I'm curious, what was your thoughts or advantage on including this in a AOI?

jstolaruk said:

I'm curious, what was your thoughts or advantage on including this in a AOI?

Click to expand...

On the consumer side, you get built in Connection Status as well as Run / Program status automatically, no code required.

Consumer Controller Tags
My_Consumed_Tag.Connection_Status.RunMode

This is a 1 when the Producer is in Run mode.
This is a 0 when the Producer is in Program mode.

My_Consumed_Tag.Connection_Status.ConnectionFaulted

This is a 0 when the Producer connection is good, regardless of its mode.
This is a 1 when the Producer Connection is broken.

celichi said:

On the consumer side, you get built in Connection Status as well as Run / Program status automatically, no code required.

Consumer Controller Tags
My_Consumed_Tag.Connection_Status.RunMode

This is a 1 when the Producer is in Run mode.
This is a 0 when the Producer is in Program mode.

My_Consumed_Tag.Connection_Status.ConnectionFaulted

This is a 0 when the Producer connection is good, regardless of its mode.
This is a 1 when the Producer Connection is broken.

Click to expand...

Sure, that is true for P/C tags and I use it but you said AOIs. AOIs?

jstolaruk said:

Sure, that is true for P/C tags and I use it but you said AOIs. AOIs?

Click to expand...

Sorry, need more coffee....UDT, not AOI

Thanks for correcting me.