Need a consultant for DF1 and GE MCR radio

Was the system working properly before the radio upgrade?
On your DF1 data capture, I do not see any reads or writes.
Was the system working with the Prosoft module and the L-81 processor before the radio upgrade?
I am suspicious of the Prosoft module configuration.

I wish I knew something about the subject matter of using radio comm, but have you tried using OPC connections?

You can try putting a local LTE based NUC-type device in your control panel, and have kepware running on it.
Then centrally have a Kepware installation on a main server to go online. Also, if you need to troubleshoot PLCs, you can install the software needed on these NUCs and RDP into them to go online?

Not sure if LTE works for your application considering you have rough terrain, but sometimes the sustenance of old tech after the original tech creators at companies like GE have left, it becomes hard to get fully functioning technology.

Found a Kepware page with some actual info too:https://www.kepware.com/en-us/products/kepserverex/drivers/allen-bradley-df1/

Also, if LTE is just not an option, maybe something like a WAN connection through tools like Ubiquity's offerings? You can try setting up modern radio tech to get a LAN connection?: https://www.ui.com/products/#default

Regards,
-PreLC

The other thing worth mentioning is if you haven’t already, make sure that the master radio is connected to a good managed switch. With the limited bandwidth you want to limit the traffic that can get to the master radio. It should only be traffic that is meant for the remote PLCs. This needs to include broadcast packets especially if the network is also used for internet traffic. You might have a scenario where the radios are spending all of their resources dealing with traffic not meant for the remote PLCs leaving little to no resources to deal with the actual data exchange that needs to take place.

Firejo
Yea, that was part of the VLAN design but I am going to shark the port to make sure that's what's really happening

TWS
New radios have had this problem since install. DF1 is "supported" but not like the older SD and iNET with the built in ENI support. This is going to be timing based serial DF1 comms with the 5 conversation handshake.

PreLC
I need to work with the serial DF1. I have Ethernet Radio at each location that works fine but the existing equipment I need to talk to is too old.

PreLC
I need to work with the serial DF1. I have Ethernet Radio at each location that works fine but the existing equipment I need to talk to is too old.

Click to expand...

Well, that makes sense, but might be a good solution to get from DF1->OPC-UA->OPC-UA->DF1, and the same for the communication on the other side.

They already have DF1->OPC-UA connectors. Might be a viable backup, considering PCs and accessories are cheaper.

Quote: "I have one location that has both Ethernet and a KE module. If I use the ethernet channel it works 100% of the time"
You could try some of these: https://www.rtautomation.com/product/460ecdfm/.

Firejo said:

The other thing worth mentioning is if you haven’t already, make sure that the master radio is connected to a good managed switch. With the limited bandwidth you want to limit the traffic that can get to the master radio. It should only be traffic that is meant for the remote PLCs. This needs to include broadcast packets especially if the network is also used for internet traffic. You might have a scenario where the radios are spending all of their resources dealing with traffic not meant for the remote PLCs leaving little to no resources to deal with the actual data exchange that needs to take place.

Click to expand...

This is precisely why I always recommend people use Layer 3 routing mode on their radios if they support them rather than layer 2 is easier without planning your network first so a lot of people fall into the trap of using it. Most modern ethernet radios do support L3, so plan out the network (/27 subnet size is plenty for most systems). It makes it a lot easier to manage traffic. On some systems I I've use firewall features to block anything other then the required protocols as well, as a backup.

I am using L3 routing for the radios and the traffic to the Ethernet remotes work fine. At 200mhz there is not much room for a GUI but SSH works fine as well as the PLC polling.

The radios themselves stay connected, its only when the DF1 Hdx M/S protocol in involved does my day get worse. Those well timed 5 handshakes that this protocol requires combined with the low bandwidth frequency are just not well tolerated. At least that's how it looks.

and yes I could add a variety of gateway devices at each location to move this communication to the ethernet channel but that gets far too expensive for this application.

In my final act at the end of the week I put serial and ethernet protocol analyzers running on the input and output of the Prosoft DF1 interface to the radio's com port and I saw that the Prosoft would not always respond to the ethernet commands.... That's unexpected. Gives me a little hope that maybe the Prosoft module is the real issue or at least contributing. I need to look at this in more detail next week.

Just to end this thread - the problem was originating from the Prosoft PLX51 module handling the traffic badly. Many thanks to Ken for his help on this. The evidence presented to Prosoft was irrefutable and they FINALLY made a Firmware correction and all DF1 traffic is now working as expected. I can even use the full 19,200 speed with no errors.

Prosoft - you fought me on this all the way only to be proved wrong and I wont forget that.

I have to ask how it was handling the traffic badly? Also thank you for holding prosoft in a headlock long enough for them to admit wrong!

The short version is that they didn't keep track of the TNS number when an error occurred. This particular "error" was an EOT from one site (still I don't know why it generates it since I am not polling by exception, but anyway..)

Without paying attention to TNS (TNS is a sequence number assigned to a particular "conversation") it would sometimes process a packet from a previous conversation, which would introduce an unexpected command in the sequence and the modules only response to this was to issue a TCP reset. That reset prevented it from processing anything else for several seconds which would make all subsequent polling attempts fail instantly. I could never tell when it would happen or find any pattern to it.

And I didn't do it to hold them accountable - this module is the only one I can find that will handle one-to-many conversations over DF1 hdx. Many will do one-to-one, but one-to-many, like that in a radio polling master are impossible to find.

So this was purely selfish.

.

Whoever else has to do this with what you used will be thankful you did it. Even if they don't know there ever was a problem.

If anyone is still using PLC-5s with only DF1 radios out in the field and want to use an ethernet polling master PLC, This module allows you to do that . . . well now it does anyway.