How do I store and forward data in MicroLogix 1400 PLC over radio telemetry

I had apparently lost track of this thread. I have been busy on other projects lately that have taken priority. I have begun to look into this more again recently and the DNP3 protocol that Saffa mentioned seems doable. I am not familiar with DNP3 though.

I am very new to all of these different networking protocols, so I do not know what the best choice is. Please excuse my ignorance.

I have also had someone suggest I use encapsulated UDP. I am not sure if that is a viable option as well or not.

The only way I could see to use UDP instead of TCP just from a quick glance is to set up a Virtual LAN in the viper radio. If I am understanding what I read properly, with a Virtual LAN I could set local connections to TCP and remote connects as UDP, thus having only UDP connections over the air. I have never messed with a Virtual LAN before though and I'm not even sure if a setting up a Virtual LAN like that is even the same as encapsulated UDP.

Regardless of what path we end up going, it's sounding like we definitely need to go away from TCP since it has so much more header information in the data it sends and it has to talk back and forth too much. If I could send the messages in a different protocol than TCP, I could also eliminate the 120 second TCP connection timeout issue.

As far as line of sight, there are tons of hills and tall trees in this area. Line of sight is not a luxury we have. If you look at the topographical map on Google Earth, you would wonder how some of our connections get a signal at all. Not to mention, some of our RTUs are miles away from the MTU (those of which are usually using a repeater or two to get back to the MTU).

We have definitely been considering splitting up our network as well. Possibly having 2 extra MTUs that are remote and connect back to the main MTU through cell or cable internet.

It is unfortunate that I did not work here back when this system was installed (it was installed about 4 years before I started). Apparently, this system never worked very well in the first place. Considering that we have over 65 RTUs online now and growing, it's unlikely the higher ups will approve another major telemetry upgrade. We are stuck with the MicroLogix 1400 RTUs and the Viper SC 200+ radios for now. I could change out the MTU PLC if necessary, that would be a small cost in comparison to replacing all of our MicroLogix PLCs. However, we had an integrator test our system using a ControlLogix PLC and we were getting the same TCP connection timeout issue. I also talked to Rockwell Tech support for over an hour last week and apparently SLC Typed Read messages are unconnected, so they do not use a CIP connection.

You can't have multiple radio modems barking over the same frequencies at the same time unless they are unable to interfere with each other physically.

You might be able to set up some sort of "sub-master" stations for nodes that are distant enough from each other to be able to violate that basic rule without stomping on each other. This could potentially give you the ability to reduce the total number of nodes that the master is required to poll and decrease total cycle time.

What we have done on systems with a large number of RTUs is divide them into logical groups where possible and use FHSS radios with unique "network ID" numbers which results in unique hop patterns, The smaller groups are on their own independent poll sequences and the main master uses UHF radio modems to poll the "sub-masters".

We use Phoenix Contact TWE radio modems for the 900MHz FHSS groups which allow onboard I/O modules to be added to the radios and that eliminates the need for a PLC at many sites that are simple well pump stations. The repeater capabilities built into the set up of the TWE radios work very nicely to get around obstacles and terrain difficulties.

I am off on a bit of a tangent now, but the main point I wanted to make is that changing the protocol, baud rate, and reducing packet sizes will probably only have a very small benefit to a system where one master has to poll 60 plus RTUs.

If you could post a picture of your kmz file (Google Earth) and maybe annotate it with some text to describe the RTUs that might have the potential to be set up on separate smaller groups it would help us to determine what might be possible to make your system perform better.

Another side-note: I recently did some mechanical work on a system with around 20 RTUs all on cell modems. The main RTU polling sequence was one timer. Every 30 seconds, enable all 40 messages (read and write to each RTU). The messages all completed in under two seconds. 100 words to some, 10 words to others, all happen in about the same time. I was actually able to do online editing from their SCADA PC with RSLOgix 500 to modify the logic in the RTUs and it was almost as zippy as having a copper cat5 cable plugged it. The downside is the monthly fee they pay for each RTU.