[Logix5000] Timeout failure for ethernet/ip connection

Hi guys,

I'm running into an issue with my ethernet/ip connection timing out, and I'm not sure what to do to fix it. Basically I had everything communicating through an unmanaged switch, and that was working just fine. But now I'm trying to go through some ethernet/ip radios, and I'm getting timeout failures.

The first thing I thought to do was to try increasing RPI, but here's the odd thing; I can't seem to adjust it anywhere. I have two projects; one for the remote/slave PLC (CompactLogix) and one for the master PLC (ControlLogix with 1756-ENBT module). When I go into the master PLC project and go to the I/O configuration and bring up the 1756-ENBT properties, the RPI box is greyed out. There is seemingly no RPI box for the ControlLogix PLC itself, and just for kicks if I try to adjust it at the CompactLogix PLC, it's also greyed out. I've tried doing this offline and online, programming mode and running, nothing seems to allow me to adjust the RPI setting...am I missing something?

Thanks!

RPI is on the consumed Tag properties

Radios - there may be some settings that are needed in them
Brand and model will help

What is the slowest update rate can you cope with?
Are you programming for what will happen if the communications fails?

MichaelG said:

RPI is on the consumed Tag properties

Click to expand...

Ah, interesting...so I'm not using produce/consume tags, I'm using MSG instructions so perhaps RPI is not the right thing to try to adjust here.

Radios - there may be some settings that are needed in them
Brand and model will help

Click to expand...

This very well may be the issue, rather than Logix itself. I will have to contact the vendor and see what they say on Monday (they're Xetawave 4x4e, which are somewhat new and I'm working with their tech support to get them working).

What is the slowest update rate can you cope with?

Click to expand...

That's a great question, and I'm not entirely sure of the answer. Because of the slow speed of the radios (we're expecting ~20-30kbps in the field) the customer wants the sites to be discretely polled in a cycle rather than using produce/consume tags. So that gives me a good bit of leeway as far as getting response times turned up.

Are you programming for what will happen if the communications fails?

Click to expand...

Yes; gonna have comms fail alarms if we have a certain number of unsuccessful communications attempts; don't have that quite ironed out yet, but the plan is to alarm after a certain number of failures.

defcon.klaxon said:

Hi guys,

I'm running into an issue with my ethernet/ip connection timing out, and I'm not sure what to do to fix it. Basically I had everything communicating through an unmanaged switch, and that was working just fine. But now I'm trying to go through some ethernet/ip radios, and I'm getting timeout failures.

The first thing I thought to do was to try increasing RPI, but here's the odd thing; I can't seem to adjust it anywhere. I have two projects; one for the remote/slave PLC (CompactLogix) and one for the master PLC (ControlLogix with 1756-ENBT module). When I go into the master PLC project and go to the I/O configuration and bring up the 1756-ENBT properties, the RPI box is greyed out. There is seemingly no RPI box for the ControlLogix PLC itself, and just for kicks if I try to adjust it at the CompactLogix PLC, it's also greyed out. I've tried doing this offline and online, programming mode and running, nothing seems to allow me to adjust the RPI setting...am I missing something?

Thanks!

Click to expand...

Well, you need to find out what is using up all the "time" and not allowing any time for whatever is timing out. I just had this on a site, and, the thing that was timing out was just a symptom of the real problem.
How I figured it out was to take my primary PERODIC task, and make its execution time something really big, like 250mS.
THEN, run Logix5000TaskMonitor tool, and see what the communications is eating up. It will be reported as "microseconds per second". If it is really high, like 750,000, that means that something, somewhere, is eating up the communications internal priority.
The distracting thing in this troubleshooting was that the PLC was actually doing the process control quite well. No observable lag in response to input making outputs.
Ultimately, it was comm load on an Ethernet card, which is difficult/impossible to determine using ladder logic (GSV, etc.).
Good luck.
And, even though this can be a hot topic for some, I'd default to using a managed switch when there's bunches of E/IP comms. Hirschmann RSB20 is a good choice, and it works...among others, of course.

One small thing you should do is check the format of the connection to the remote CPU in each controller to be sure you're not inadvertently sending cyclic messages.

You only require the destination CPU (and/or the destination 1756-ENBT and chassis) in the I/O tree if you intend to use Produced/Consumed Tags.

To send MSG instructions, you do not need the destination CPU in the I/O tree of your controller project. It's convenient, because you can click on the CPU instead of typing in the CIP path manually, but it's not necessary.

One common mistake is to choose the default connection type when you put a remote 1756-ENBT into your I/O tree. The default is a "Rack Optimized" connection at a 10 millisecond RPI. That's great if you want to use discrete I/O modules in that remote chassis, but a waste of bandwidth if you don't.

Instead, you want a connection type of "None", which is what you use when there are Produced/Consumed tags only.

I have not experimented with it to be sure, but it's possible that there's a slow cyclic connection created when you put the remote CPU into the I/O tree, to report connection status.

So go review those connections, both from the CompactLogix side and the ControlLogix side.

One of the best places to examine those connections is the embedded webpage for the 1756-ENBT/EN2T modules. They'll show the cyclic connections on one tab, and the explicit connections on another.

Something being overlooked is the radios themselves. If you’re testing them on the bench I.E. they are right next to each other, unless they have fixed something, you will get very little bandwidth. They have an oversaturation issue (at least they used to) so when they are close together they struggle to pass any data at all. If you have the ability to add attenuation to the antenna connections try that along with turning the power down (way down). The other thing you can try is to separate them as much as possible (within reason).
The good news is that I’ve not only passed data through a set of Xetawave radios (development radios that have the same core radio that the 4x4e’s use) but I have done EtherNet/IP TCP through them (message instructions) and it does work. The radio are transparent at the application level (unless something’s changed) so the issues are going to be speed and latency and if a simple message instruction isn’t working it’s gotta be running pretty slow.
I want to clarify that I’m not saying that the Xetawave radios aren’t any good. The guy who founded the company and designed the radios is one of the smartest RF engineers on the planet and also co-founded FreeWave and designed the core radio they use (which are currently some of the best data radios you can buy). The issue with oversaturation is a side effect of what it takes to achieve some of the things that radio will do (very high speed over a long distance for example).

Something else occurred to me and that’s you might want to setup and test the radios first and once you get a good path then add the PAC’s. I’d start with a simple ping test then use something that will show you throughput. I like Qcheck from NetIQ (http://www.practicallynetworked.com/reviews/qcheck.htm).
It’s freeware and works pretty well. You need to have it installed and running on two PC’s and then put the radios between the PC’s.
This way you’ll know if the issue is something setup in the radios or the PAC’s.

Don't download or install anything related to qcheck, its stuffed full of malware.

jstolaruk said:

Don't download or install anything related to qcheck, its stuffed full of malware.

Click to expand...

Really? Can you be more specific? Malware can be anything from adware to virus.

Something to be aware these days are:

- Fake download link that appears on the same page as legit download. Scammer are using advertising link.

- bundled "adware". I had problem with Imgburn that I can't even download because Norton catch the adware that's bundled with it. However, once downloaded, the user can skip the adware.

No, it took me a little to get rid of them. No viruses, just installed a bunch of stupid advertising software and Malware said 8 different malware packages.
Qcheck apparently was last available in 2001, no other searches yielded anything but the installations that allowed the malware to install.

Yup, I digged into it more. It appears that qcheck was discontinued quite a few years ago. Anything one download now are "repackaged" with questionable contents.

Ken Roach said:

One common mistake is to choose the default connection type when you put a remote 1756-ENBT into your I/O tree. The default is a "Rack Optimized" connection at a 10 millisecond RPI. That's great if you want to use discrete I/O modules in that remote chassis, but a waste of bandwidth if you don't.

Instead, you want a connection type of "None", which is what you use when there are Produced/Consumed tags only.

Click to expand...

I am looking into this, as I definitely don't want that fast of an RPI for remote connections without testing first.

One of the best places to examine those connections is the embedded webpage for the 1756-ENBT/EN2T modules. They'll show the cyclic connections on one tab, and the explicit connections on another.

Click to expand...

Oh man, I didn't even know about this! How would one access it, is it an IP address?

Firejo said:

Something being overlooked is the radios themselves. If you’re testing them on the bench I.E. they are right next to each other, unless they have fixed something, you will get very little bandwidth. They have an oversaturation issue (at least they used to) so when they are close together they struggle to pass any data at all. If you have the ability to add attenuation to the antenna connections try that along with turning the power down (way down). The other thing you can try is to separate them as much as possible (within reason).

Click to expand...

I think this was it; I separated the radios a good 10-15 feet and that seemed to do the trick; I now have good comms and can get MSGs back and forth. Thanks!

Glad to hear it's up and running.
Happy hunting