[Logix5000] ControlLogix PLC slamming wireless etherness radio with data

Hi all,

I'm attempting to get my radio comms working and I'm having a bear of a time getting the radios to work. I think I've narrowed it down to the ControlLogix PLC that takes care of polling the remote sites via ethernet radio (CompactLogix at remote sites, radios are Xetawave 4x4-E). Right now there's just one master site, and one remote site. At the remote side, the CompactLogix (in program mode) is the only thing plugged into its radio. Down here at the Master radio, if my laptop is plugged into one of two ethernet ports on the radio, I can ping the remote PLC all day long. On the radio statistics page, the transmission and reception rates are a few kbps. As soon as I plug the ControlLogix PLC into the radio, I get a wild spike of data; transmission rate jumps to over 20kbps, reception rate takes a nose dive to 0 kbps, and the ethernet/ip link crashes. Radios keep talking, but no data and my pings of the CompactLogix PLC crash. Then after a few minutes transmission rate lowers, it tries to re-connect, might for a few seconds and then transmission rate skyrockets again, connection crashes. If I unplug the ControlLogix, my pings to the CompactLogix restore and are strong again.

At this point I don't know what is causing the transmission spike, but it's definitely related to the ControlLogix PLC. Keep in mind the PLC is in program mode, so it's not even trying to send data...all it's trying to do is see if the remote site is there, via the I/O Configuration.

I'm not sure how to tackle this problem, exactly; I'm by no means a networking expert so I'm not sure how to try to track down what's causing his huge transmission spike. I've talked to the radio mfr and while they were helpful in getting the cause narrowed down, there's not a whole lot more they can do on the network side of things and they're not PLC experts.

Any thoughts on what I can look for, and what I can try?

defcon.klaxon said:

...
Keep in mind the PLC is in program mode, so it's not even trying to send data...all it's trying to do is see if the remote site is there, via the I/O Configuration.

Click to expand...

You don't want to have the remote PLC in the I/O configuration of the master when using radios. The master will try to communicate with all of its I/O at the RPI rate and there is little that you can do to control it.

You do want to programmatically control the traffic using MSG instructions.

You do want to poll at a reasonable rate and make sure you are waiting for a DN or ER from one message before triggering the next.

You do want to have some deadtime between polling loops to allow for other things to happen across the air (like pings from you laptop to the remote, or browser access to the remote).

I have not used that radio, but have had experience with Cal-Amp Viper radios where I have one master and six remotes.

Hope this helps.

OkiePC said:

You don't want to have the remote PLC in the I/O configuration of the master when using radios. The master will try to communicate with all of its I/O at the RPI rate and there is little that you can do to control it.

Click to expand...

AH ok that makes sense. I assumed I had to have the PLCs in the I/O Configuration since the MSG instruction asks for the path; I'll try doing it manually.

You do want to programmatically control the traffic using MSG instructions.

Click to expand...

I am using MSG instructions so that's good to know. Makes sense, as I've read that produced/consumed tags can slam networks.

You do want to poll at a reasonable rate and make sure you are waiting for a DN or ER from one message before triggering the next.

Click to expand...

Right now I break up each remote site into four MSGs, but I let them all go at once. I'll modify to have it do one at a time.

You do want to have some deadtime between polling loops to allow for other things to happen across the air (like pings from you laptop to the remote, or browser access to the remote).

Click to expand...

I have a "slowdown" timer in place to do just that. I'll remove the PLCs from the I/O Configuration, modify code to run one MSG at a time insted of the group, and see if that helps. Thanks a million!

I have not used that radio, but have had experience with Cal-Amp Viper radios where I have one master and six remotes.

Hope this helps.[/quote]

Quick update: I removed the instances of the PLCs from each of the I/O Configurations and that cleared up the problem.

Now, the challenge is trying to figure out why the connection crashes when I go online to the PLC in Logix; apparently when I do that, RSLinx goes out and tries to communicate with all the other PLCs in the network, and that crashes the comms link because of the traffic. Until then, it seems like every time I go online to any PLC in the network, it'll crash the connection. Maybe using the USB port instead of the ethernet connection? But then I'm limited to one PLC at a time, and needing to physically move to each one. I'm going to contact AB and see what they say; if anyone can chime in with help, that would be great too.

Thanks again OkiePC!

update: OK so now going online to the master PLC doesn't crash the connection...maybe the instances in the I/O Configuration and going online were correlative? This is odd; now the connection seems totally solid.

try using different subnets for remotes.. and the master radio should bridge them.

I do not know that radio but most have some type of "network neighborhood". If each remote has a different subnet then that should limit linx.

If every remote has same subnet then the msg will be boadcast over everything even linx.

Are the Xetawave radios close to each other (I.E. bench testing)? If so it is possible to see what you are describing when you load up the data. If you are bench testing put as much distance as you can between the modems and if you have access to them put some attenuators between the modem and the antenna. You can (and should) turn the RF power down but don’t forget to put it back up when the radios go in the field. Having said all of that, Produce/Consume will not work across those radios (or any other radio other than very high speed ones (and that doesn’t always work)). I know you’re not utilizing P/C now but for future reference and others reading this.

Hi robo77,

This is where my networking knowledge quickly becomes overwhelmed; I know a bit about setting up networks and IP addresses and etc, but this project is pretty over my head. We have multiple subnets meant to separate the radios from the PLCs and virtual machines, but it's tough for me to keep track of everything. We have an IT consultant who runs laps around me when it comes to network management so I lean on him. If you have any suggestions for resources on how to learn more about network management I would love to investigate them!

Firejo said:

Are the Xetawave radios close to each other (I.E. bench testing)? If so it is possible to see what you are describing when you load up the data. If you are bench testing put as much distance as you can between the modems and if you have access to them put some attenuators between the modem and the antenna. You can (and should) turn the RF power down but don’t forget to put it back up when the radios go in the field. Having said all of that, Produce/Consume will not work across those radios (or any other radio other than very high speed ones (and that doesn’t always work)). I know you’re not utilizing P/C now but for future reference and others reading this.

Click to expand...

Hi Firejo I think we've talked Xetawave radios before. To answer your questions:

1. No they are not in an office environment anymore, they're deployed in the field and are about 4 km away from each other. Bench testing is definitely a valuable way to go and I am able to do that with reduced power and rubber duck antennas instead of the yagis we're using, if need be.

2. I'm not using produce/consume tags, only MSG instructions. Apparently produce/consume can slam networks with traffic if they're multicast, and I've been told by more experienced programmers that produced/consumed can be a real challenge when it comes to radio comms; thus, I've avoided them and am using MSG instructions only in this project.

3. That all being said, at the end of your post you mention how you already know I'm not using produced/consumed from previous posts so disregard, but I'll leave it for any curious readers. Thanks for chiming in!

As far as current status, I removed the radio-connected PLCs from I/O Configuration from both local and remote PLCs, and that cleared the issue up. MSGs are being managed as a per-MSG rate, instead of sending out in groups like I was doing before and comms have been rock solid for hours now. Thanks again for all the help.