Firejo
Member
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.
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.