Need a consultant for DF1 and GE MCR radio

I have been fighting with a series of GE MDS orbit MCR radios and DF1 Hdx comms (PLC5's) over low bandwidth (220mhz). This battle has been going on for 2 years. Ethernet comms seems to work well enough but DF1 traffic has a 50% success rate at BEST. End of life Esteem radios have been doing this job for a decade with far less trouble and still do at a 450 mhz freq. I would have stuck with them if they had the lower bandwidth I need for terrain conditions and the rules that allow voice to override SCADA data in the 450 band. But they didn't.

I need to hire a consultant to help me diagnose and fix this. I have exhausted everyone nearby... my usual integrator, GE support and the dealer that sold them to me. They all either are out of ideas or run away when they find its DF1.

I have one location that has both Ethernet and a KE module. If I use the ethernet channel it works 100% of the time, if I switch to DF1, its a 80% failure. Not 100%, 80%. So I have my addressing and setting correct.

I can also SSH into these and that is slow, but stable. That tells me the RF conditions are fine, its the protocol, perhaps combined with the low bandwidth, that causes a problem with timing in this radio.

I am willing to talk to anyone who has had good success in this space or someone that has determined it will never work because GE doesn't care if it does.

Serial on ethernet radios is tricky. I had similar challenges with Micrologix 1400s using serial DF1 over some Trio QR450 radios. You have to get the serial port settings just right so that the radio doesn't transmit partial serial packets. That generally means a transmit delay to allow the entire serial packet to be received by the radio, and a long enough timeout delay in the PLC so the remote unit can answer, via its own radio with transmit delay. We nicknamed this "Dribbly Serial", if you didn't get it right then you got serial data dribbled out the radio. It was never an issue with earlier radios, where the serial baud rate matched the RF transmit rate. With higher speed, there's more complication.

The PLC5s won't have "DF1 Radio" like the micrologix do i don't think? That removes an unnecessary ACK or NAK from the MSG transaction. Before my time, I've never had to work with them.


I can't seem to download the GE radio manual without signing up a new GE account. If you want to PM me your email address, I'll drop you an email and if you mail me the user manual for the radio, plus some screenshots of your existing radio config for the serial port, I'm happy to have a look.

If it works over ethernet then it has to be a serial port or timing issue.

I will get the manual to you but I gotta say, on this subject it is lacking. They removed the ENI support that older models (SD and inet) had and that is what is really needed here

The PLC-5s in my case have KE modules so radio-modem protocol is not an option. HDX master slave is the only option I have as its the lowest common denominator.

During testing 1400's and 5380's using radio modem protocol worked quite well, though they have ethernet so that doesn't really help me. The few PLC5's in the system with serial ports AND radio modem protocol also worked well. Most however have no serial port and are DH+ to KE modules. Since those worked (and continue to work) with the ESTEEM radios I didn't think to test them well assuming they would just work.

The consensus agrees with you that timing must be the issue but I can find no way to record both sides to verify it or determine where exactly the timing fails to attempt a correction.

My polling is sequential, nothing proceeds until the previous msg completes (via a .dn or .er bit). I force a .TO after 3 seconds knowing that if it hasn't worked by then it wont ever. I have a meeting in a few minutes but I will hook up with you and post whatever you think will help.

At this point I'm also going to look for a 5380 to PLC5 IO solution. complete replacement with 5380s was to be done eventually but it was not intended to be this soon. I may not have another choice.

This may help you. https://literature.rockwellautomation.com/idc/groups/literature/documents/um/ag-um008_-en-p.pdf. PLC 5 setup is in chapter 2.
Also have you used logging in the radios? Event logging, Syslog-over-TSL, SSH, Console.

I would check the RTS CTS settings in the radios and the PLC configuration.
1990 was the last time i set up a PLC 5 as a Half duplex poling master.

I agree that it may be time to upgrade. You could E Bay a 5-04 and use channel 0 as your half duplex polling master and communicate with the PLC-5 master over DH+ until you do your upgrade.

The logging is available for both the physical and virtual serial interfaces and shows out of sequence acks, very few NAKs and generally scrambled sequences, and then will show several 5 packet conversations that are perfect. No pattern to the success. Since I only poll one remote at a time I can't understand how that is possible. I need to capture and sync 2 of these captures from 2 the master and slave at the same time and its really difficult to do that.

Hardware flow control is turned of and the DB15 connector to the KE has 4-5 and 6-8-11 pins tied together per the manual to disable hardware signaling needs. This is no doubt why the timing is so critical.

My Master polling machine is a L81 driving a Prosoft PLX51-DF1-ENI (using Ethernet) in bridge mode. There are multiple hops in the ethernet link but latency is very low (<1ms)

Interesting thought using the 5/04. I'd have to do this 15 times for the sites that are remaining.

I’m not familiar with the GE MDS Orbit radios but it sounds like they are taking serial communications and putting it on an Ethernet comms layer which (if true) will be problematic unless they specifically design that process to be serial protocol (DF1 in this case) friendly.

One thing you might consider, if feasible, is to put the EtherNet/IP to DF1 bridge on the remote side of the RF link so that the radios are dealing with nothing but Ethernet and the ACK’s and NAK’s are happing between the bridge and the PLC. That also makes it easier to replace a PLC/5 with an Ethernet PLC down the road as you won’t have to change anything with the radio.

I am guessing you only have 12.5khz channel bandwidth on 220Mhz radio. That's going to limit your over-the-air data rate. 19.2k would be pushing it. What are the serial port baud settings? Can you lower it?

Are you able to get online with RS-Logix 5 remote PLC's?
Are you using DF-1 Scheduled communications ( the general tab in the module)
Is the serial port set to radio mode DF-1 Master?
Can you set some of your underperforming slaves to repeat the messages. You need to enable store and forward.

Can you post a diagram of the master and slaves? That would be helpful for me to understand what is going on.

I have used these with great success: https://www.miille.com/266-p00-xye.htm. You do all of the communication configuration in the module.

Firejo - It's unclear on the encapsulation of the DF1, but I tend to believe they are encapsulated because I have changed the baud rate of the AP and a singe remote to 9600 and yet all the comms remained as unstable as they were where you would expect all by the one remote at 9600 to be the only one working at all. Seems that the baud rate at the destination can be independent of the AP (Master Radio). I will test that later today by going to extremes. I see what you mean ab out moving the bridge but then I'd have to add one to every station... I'll think about that.

KirkC using licensed so I can go to 50k bandwidth, but I am running at 25.

TWS
- No chance of getting online over the radio link, its just too slow for that.
- Do you mean scheduled in the Prosoft module? no. It's in bridge mode responding to the L81 PLC at the plant.
- DF1 Master is the Prosoft Module
- Store and forward does not work with these radios and serial DF1. We tried that 2 years ago and GE couldn't make it work either.
- Diagram.. L8 PLC - microwave ethernet link to hilltop, eth into Prosoft module DF1 out - master radio on a hilltop RF to slaves scatterred through out the area

In the document that TWS referenced the reference ladder diagram has a delay between messages. Is that required? Isn't the .DN (or .ERR) bit enough of a signal of completion to begin the next MSG? Should I add a delay between messages?

(I'm going to now as a test but I would like to know if that is really required. )

It has always been my practice to have a timer that I can adjust for a delay between each message when polling other PLCs sequentially especially when radio modems are involved. I have one system that uses Modbus RTU and serial radio modems and if I set my "inter-message delay" to less than 650ms, some nodes (proprietary RTU boards) will not respond. In most cases I set that timer to a much lower value, but none of them are set to zero. I suppose you could zero the preset if you find it is of no use in your situation.

I also run a timer to measure the total time required to poll all nodes and record the peaks so that I can measure the real world impact of changes like adding nodes or adjusting the inter-message delay. There are cases where I have found setting my delay to anything lower than a certain value has no impact on the overall speed of polling, and some cases where a minimum dead time on the port definitely helps.

I just built the inter-message delay and I do have diagnostics built in too. Percentage of success, duration of each MSG, stuff like that. I built an AOI for that a while back just for times like this.
I'm not seeing any difference yet... we will see.

Here a short sample capture. Some successes. some not so much. This is with 500ms of inter message delay

Have you enabled QOS in the radios and do your Ethernet switches support QOS?
I have always included a delay between messages. How many retries on the messages before you set an error? on a serial radio at 220 MHZ i would do 10 seconds between messages with 3 retries before reporting an error and moving on to the next message.
Can you take a SLC 500 or something with a serial port up to the master radio and see if you can poll all of the remote stations without errors? That will eliminate the Prosoft module and microwave link.
Does GE have software that you can test each link? MDS used to ship the software with each radio. I would test all of the links from the master to the remotes.

10 seconds between messages would not work here. 3-5 seconds is absolute max and that is too much. There are just too many sites to get through. The ones that work on a different nearly identical system, complete in under 2 seconds. I've no idea why one works and one doesn't ...they are the same design.

QOS is available on both the radio and the switches, but the vlan is all mine and this is the only thing on it. There is no competition for bandwidth over the ethernet link