Micrologix 1400 IP message over ethernet

[heatfireash]

Hello, I'm looking for some insight on data usage for Allen bradley IP messages. I have a setup of 4 total Micrologix 1400s. One is the master that polls the rest for data. The master polls once a minute to grab 2 n7 registers from each of the 3 remote PLCs. These are connected together via a vpn setup in a cellular radio from Microhard. The connection works but the data usage is extreme, around 500mb a month. I have never before tried to use Allen bradley IP messages over cell so I am unfamiliar with eh data it uses. I am looking for any help from someone that might have experience using a cell modem vpn and might know if the data usage is correct. Perhaps I should change the setup to use serial instead of ethernet for the communication? Maybe that uses less data? I'm looking for any help on this. Thank you.

 

[Geospark]

Hi & Welcome to the Forum!

If you have access, please read the following Rockwell Automation Knowledgebase technote article...

623444 - MicroLogix 1400 series B Ethernet packet size information
Access Level: TechConnect

...and also here for a little more info...

67050 - Explanation of how the Keep alive packets are used by Ethernet for the MicroLogix 1100/1400 processors
Access Level: TechConnect

Basically you need to prevent "keep alive" packets by breaking the TCP connection after the MSG instructions are "Done". Also, you can disable Duplicate IP Detection (ARP) packets, which are quite regularly sent.

Just in case, what Series hardware and firmware revision is the Master controller?

Regards,
George

 

[TheWaterboy]

You can use Wireshark to see what Geo is talking about. There is a lot of overhead and housekeeping with Ethernet traffic. I send and read a packet of 100 elements and each transmission session was well over 1K of traffic and that doesn't include the cellular transmission which I have no way of seeing. I'm battling the same thing, but my cell network is in its infancy so mine are all unlimited data for the time being. M2M pricing was not attractive at the data rates I am seeing.

It might be necessary to use one of the IOT protocols (MQTT et al) which are far more lightweight but would need a device than can use it, the 1400 is not one of those.

 

[heatfireash]

Thank you for the quick reply. If I set the break connection bit after the message is finished will I have to reset it before the next message or will the message instruction automatically reset it next time the message instruction is enabled?

The PLCs are all microlgix 1400 B 21.2 firmware.

You can use Wireshark to see what Geo is talking about. There is a lot of overhead and housekeeping with Ethernet traffic. I send and read a packet of 100 elements and each transmission session was well over 1K of traffic and that doesn't include the cellular transmission which I have no way of seeing. I'm battling the same thing, but my cell network is in its infancy so mine are all unlimited data for the time being. M2M pricing was not attractive at the data rates I am seeing.

It might be necessary to use one of the IOT protocols (MQTT et al) which are far more lightweight but would need a device than can use it, the 1400 is not one of those.

We are using M2M as we did this at a different location using modbus with scadapack controllers and the data usage was very low around 40mb a month so we assumed Allen Bradley wouldn't be much different in terms of data but it is. This is all new territory for me. Also I am polling the data once a minute but that isn't really necessary. I may make it every few minutes to help with some of this data usage after I setup the Micrologix as stated in the tech connect note.

 

[Geospark]

From the Instruction Set Reference Manual...

Note the reference to configuring the message as Unconnected (UC), especially for cellular networks.

Just set the Break (BK) bit to "1" and leave it. Each time a MSG instruction is executed, it will break the connection after the message is flagged as completed.

P.s. Your controller Series and firmware are compatible for all this.

Regards,
George

 

[heatfireash]

You can use Wireshark to see what Geo is talking about. There is a lot of overhead and housekeeping with Ethernet traffic. I send and read a packet of 100 elements and each transmission session was well over 1K of traffic and that doesn't include the cellular transmission which I have no way of seeing. I'm battling the same thing, but my cell network is in its infancy so mine are all unlimited data for the time being. M2M pricing was not attractive at the data rates I am seeing.

It might be necessary to use one of the IOT protocols (MQTT et al) which are far more lightweight but would need a device than can use it, the 1400 is not one of those.

From the Instruction Set Reference Manual...

Note the reference to configuring the message as Unconnected (UC), especially for cellular networks.

Just set the Break (BK) bit to "1" and leave it. Each time a MSG instruction is executed, it will break the connection after the message is flagged as completed.

P.s. Your controller Series and firmware are compatible for all this.

Regards,
George

Thanks for this, I will give a try very soon.

 

[TheWaterboy]

Did you notice this in the article ?

The latest MicroLogix 1400 firmware sends out one ARP packet every 2.5 minutes. There is currently no way to prevent these packets from being transmitted.

For MicroLogix 1400 FRN 15.2 and above, if you check 'Disable Duplicate IP Address Detection' in the channel 1 configuration screen, you will stop those ARP packets from being transmitted.
​

These two sentences seem to say the opposite thing.

 

[Geospark]

The first paragraph states how it "was" for older firmware.

The second paragraph states how it now "is" for firmware 15.2 or newer.

The word "latest" in the first paragraph was written at a time when the latest firmware of the day still could not disable ARP packets.

G.

 

[TheWaterboy]

We can make that assumption but you gotta admit that should be clarified in the article.

 

[Geospark]

I could go and get a copy of the firmware to quote the change at 15.2 but I'm not going to. More so because I'm trying to eat my nice sandwich here, and not because I don't think I need to.

We see this quite often in technote articles where updated info is appended to the existing body of text without surveying the previous text and editing it to clarify context. They should have done so here, in my opinion, but as you say, that's just my opinion.

However, the Duplicate IP Detection feature, which has been available for some time now, does indeed disable ARP packets, so we can say with certainty, and irrespective of the technote, that such a feature does exist, can we not?

G

 

[TheWaterboy]

I think it's important that the article be complete and accurate. To demonstrate that we find that we cannot say with certainty that the feature exists because it wasn't only a firmware issue, it's specific to a model. They just clarified the article to read:

There is currently no way to prevent these packets from being transmitted for the Micrologix 1100

As you said they have a habit of appending without reviewing and in this case were being incomplete enough to be confusing.

 

[Geospark]

Big Brother is Watching?...

I think it's important that the article be complete and accurate. To demonstrate that we find that we cannot say with certainty that the feature exists because it wasn't only a firmware issue, it's specific to a model. They just clarified the article to read:

There is currently no way to prevent these packets from being transmitted for the Micrologix 1100

As you said they have a habit of appending without reviewing and in this case were being incomplete enough to be confusing.

...and while adding that MicroLogix 1100 distinction, they just removed that entire first paragraph with the confusing words "latest" and "no way" in reference to the MicroLogix1400...

...The latest MicroLogix 1400 firmware sends out one ARP packet every 2.5 minutes. There is currently no way to prevent these packets from being transmitted.

I find that too unlikely a coincidence my friend?
The very day we point out the apparent technote error or confusion it gets edited to reflect what we were saying, within hours?

I reckon someone with the right connections or clout was looking in here today, and that someone took heed, and did the right thing.

Or am I just making assumptions again?

Regards,
George

 

[TheWaterboy]

Yes indeed you are, but we all have this power.

At the bottom of a technote there are 2 buttons asking it it was helpful, yes or no. If you press no you are asked whats wrong, if you tell them the issue it opens a ticket and they deal with it. I've been poking at them for their ambiguous or horribly worded answers for a long time now and they respond pretty fast and fix it.

Here's the actual feedback.

"I contacted the commercial engineering department & have updated the technote, https://rockwellautomation.custhelp.com/app/answers/detail/a_id/67050.
The corrected/clarifying sentence is as follows: "There is currently no way to prevent these packets from being transmitted for the Micrologix 1100."
Regards,
Mark
Tech Support

 

[Geospark]

Well good on you, good Sir!

It did seem quite uncanny that it happened just after we'd discussed it. I have never bothered before to click those options. So thanks for the excellent tip.

Although, they might be sorry now that I know about it?

G.

 

[TheWaterboy]

From the tone of some of their responses, they already aren't happy that button is there. If they remove it, that will be a whole new mission for me.

I'm fairly dumb and getting worse so I spend a lot of time looking through that stuff and sometimes because the author or editor is not well versed in english, the narrative is darn near incomprehensible.