ML1400 read PLC5 through Serial Radio - not so much...

Glad to hear you’re making progress but for further testing I really wouldn’t use Modbus RTU (Modbus ASCII is OK). Just because Modbus RTU is not as forgiving as DF1 doesn’t mean that if it works for RTU then DF1 will work. Normally just the opposite. To be fair, I’m not familiar with the MDS radios but there is a fundamental difference in the way RTU and DF1 operate and that difference means that radios need to handle the packets differently.
DF1 is a straight forward 10 bit word protocol and uses a typical “start of message” character and “end of message” character structure thus the receiving device knows when the packet begins and ends. RTU uses 3.5-character gaps in the data. When the receiving device sees a gap of 1.5 characters it clears its buffer and prepares of the incoming packet.
Here’s the rub with radios. All Frequency Hopping Spread Spectrum radios produce gaps in the data stream. Most are very good at keeping things in order but there are gaps and if that gap lands in the middle of a packet the receiving device will see it and think the packet is done, see that it has failed the CRC check and toss it as garbage. It then does the same thing with the remainder of the packet because it is also only half of the original. The way to deal with this is to either read the incoming packet then reconstruct it at the other end (rather than just passing the data through) or to deploy a buffer at the receiving end so that the transmitting end has time to get all of the data through and the gaps are eliminated. The first method works but it requires a lot of processor power on both ends and adds a lot of overhead to the actual RF transmission slowing things down at the application layer. The second method is what most radios do (invented by FreeWave by the way) and also works but also slows things down. My experience (with the FreeWave radio) is that because of the added delay, DF1 becomes unhappy and while it will work, it also is more likely to produce errors. To be fair I never did figure out why but without fail whenever I’d set the radio up to work with Modbus RTU I’d start getting “Bad Characters Received” when looking at the diagnostics in RSLinx. I could get the PLC’s to talk but not as fast or error free as when I turned RTU mode off. It’s very possible that the MDS radios are using the first method and since they aren’t detecting a Modbus packet they aren’t adding the delay and if that is the case then your off and running but I would find that out or at very least run RSLinx to a PLC through the radio link and see what the diagnostics say. If RSLinx is happy then the PLC’s should talk to each other just fine.
 
P.S. You may very well know a lot of what I just posted (no intent to insult your intelligence) but I figure a lot of other people don't know what's different about MB RTU so I went off the rails (a little).
 
All good, no such thing as too much info here.
The reason for using Modbus was just that, timing. If it passed timing then the link is as solid as possible. The radio itself might not be happy about it in some cases, but such was not the case here. This was a licensed simplex band, not hopping.
These are Ethernet radios that encapsulate the serial stream such that the entire serial "packet" gets assembled when its is completely received, only then is it sent to the locally attached device. This process should deal with the gaps as the local radio has the entire string (or it doesn't and drops it) before it attempts to send it to the device.

I also am not involving RSLinx, the PLC's talk directly to each other. Never even occurred to me to try RSLinx over serial radio.

I had to increase RSLinx delay times to get it to even work over my cellular links because of the 300-500 ms latency. Can't imagine how bad it would be over a slow connection.
 
All good, no such thing as too much info here.
The reason for using Modbus was just that, timing. If it passed timing then the link is as solid as possible. The radio itself might not be happy about it in some cases, but such was not the case here. This was a licensed simplex band, not hopping.
These are Ethernet radios that encapsulate the serial stream such that the entire serial "packet" gets assembled when its is completely received, only then is it sent to the locally attached device. This process should deal with the gaps as the local radio has the entire string (or it doesn't and drops it) before it attempts to send it to the device.

I also am not involving RSLinx, the PLC's talk directly to each other. Never even occurred to me to try RSLinx over serial radio.

I had to increase RSLinx delay times to get it to even work over my cellular links because of the 300-500 ms latency. Can't imagine how bad it would be over a slow connection.

I didn't realize GE/MDS had a licensed version of that radio. That's a whole different animal all together. Licensed radios are much friendlier to Modbus RTU because they typically don't break the Modbus packets apart (even without the Ethernet encapsulation).
As to RSLinx, I've not used it with that much of a delay to often but when I have I've not seen to much of a problem other than it taking forever to do anything. However it was long enough ago that it is very possible that I also had to change the delay settings to get it to work.
Having said that, the reason I've used RSLinx is that it's the same driver used by the PLC's except that you get access to a lot of detailed diagnostics data. I've used it in the past to fine tune the PLC's settings by looking at the diagnostics data to see what's happening to the data moving across the wireless link.
What this really proves is there is more than one way to skin a cat. Like I said before, good to hear you've got a handle on it and it's always good to express ideas and share experiences with others.
Thanks for posting and following up.
 
Radios are MDS Orbit. Was more tricky to config than necessary because we have a couple locations where Store and Forward is needed. This was further complicated by having both the docs and the videos portray configurations that just didn't function the same in this radio. They worked in the SD and XS(?) models, but not this one. GE support was equally surprised but verified it on their end. I expect unannounced firmware updates will follow.

I'm gonna try RSLinx just for the experience. Thanks for chatting.
 
Radios are MDS Orbit. Was more tricky to config than necessary because we have a couple locations where Store and Forward is needed. This was further complicated by having both the docs and the videos portray configurations that just didn't function the same in this radio. They worked in the SD and XS(?) models, but not this one. GE support was equally surprised but verified it on their end. I expect unannounced firmware updates will follow.

I'm gonna try RSLinx just for the experience. Thanks for chatting.

;)
 

Similar Topics

I need to read one analog tag located in a PLC5/40C 1.5 that has an ethernet card installed. I need to do this over ethernet to a Micrologix 1400...
Replies
4
Views
2,079
Hi All. I can write an N7 value to a modbus register in an Automation Direct Servo but I can't read a holding register to an N7 address. I've...
Replies
3
Views
1,892
Stuck at home and need to adjust the CVH on a PID loop. I can build an AdvancedHMI HMI to read write the valeus, but I cannot VPN in. Is there...
Replies
5
Views
1,654
Hiii. i am trying to read the PLC-5/40c data to the ML1400 PLC throgh channel 0(25 pin to 9 pin pin configuration). When i downloaded the program...
Replies
17
Views
4,851
Hi , in my application i was supposed to read the recipe name in a string & have to display it all other screens of scada & to perform operation...
Replies
0
Views
2,891
Back
Top Bottom