I am not well versed on this topic, especially when it comes to radio communication so looking for any help that I can get. One of our clients currently using Freewave FGR-2 radio polling data from DataTaker DT80 at their plant as a Master.
Last year someone from our team installed 3 panels with Freewave 200-PEU radio with DT80 as slaves. This communication protocol was set to Modbus TCP/IP I was told.
The guy who installed this is no longer around and I tried to put together a similar system in the shop. So we ordered the same setup, i.e 200-PEU Intuicom radio and we bought extra so that we can turn set it as a Master. This is when things get interesting.

I couldn’t get the radios to talk to each other so I called Intuicom and they said 200-PEU can’t do Modbus TCP/IP, only RTU. I called our guy that did the install last year and he said everything is TCP/IP, i.e there is no serial connection anywhere.

Freewave that makes these radios said that they don’t work on Modbus TCP/IP, yet the client that uses this said all their protocol is Modbus TCP/IP.
Am I missing something here? Appreciate any help!

 

A web search tells me the following:

• The DT80 supports both Modbus/TCP and Modbus RTU (via RS-232, RS-422 or RS-485)
• The Freewave FGR-2 seems to only support serial ports. However, the FGR2-P and FGR2-PE have both serial ports and Ethernet ports.
• The 200-PEU seems to be a device made by Intuicom that is meant to replace the end-of-life FGR2-PE-U (https://www.intuicom.com/serial-ethernet/200-peu/freewave-transition/)

Now, generally speaking, if these radios are taking Ethernet packets and converting them to radio signals then back again, Modbus need not be supported, only the underlying TCP protocol (since Modbus/TCP runs on top of TCP). The radios simply need to pass the payload data contained in the TCP packets (i.e. the Modbus protocol), they don't need to interpret that data. Therefore, the radios shouldn't need any knowledge of Modbus.

 

Thanks for your time in responding to this. So if I understand this correctly, TCP refers to the connectivity between two devices and Modbus is the language? So if the radios can communicate between each other, the language shouldn't matter?

The model that our client uses is actually FGR-2-PEU, which looks like it has no Serial port, only Ethernet (based on the photo they sent to us). We couldn't get our hands on this model so we used one of the 200-PEU instead as a Master and the other two as Slaves to practice in our shop and we can't get them to talk to each other. That is when Intuicom told us these won't work on TCP, which made me curious why would you put Ethernet port there in the first place?

 

You might be getting confused by the format of the serial ports on the various models. The 200-PEU has two DB9 connectors on the front marked COM1 and COM2. The FGR2 series have what appear to be four ethernet ports on the front, however the format for all 4 ports is RJ45 (what most people think of as ethernet). Two of those are marked "COM" and the other two are marked "ethernet". Page 147 of the FGR2 manual details the serial pinout of those com ports. It even looks like they'd sell you a special serial cable if you can't make your own.

All that said, you aren't using serial. The radios in between shouldn't care what's in the TCP packet. That portion will be handled by the DT80 and whatever is polling it for data. DT80 takes Modbus packet, slips that into a TCP packet and sends it off. Somewhere on the other end will be a Modbus master. That master will be in the same TCP subnet as the DT80.

Think of it like the mail. The master (SCADA perhaps) puts a modbus command in an envelop and addresses it to the slave (DT80). That envelope is TCP. The slave receives the envelope, opens it and throws away the envelope. The slave then responds the the modbus command, puts that response in a new TCP envelope and sends it back. In between the radios don't know what's in the envelope, just that they have an envelope to pass along. Here, the modbus part happens in the application of data, not the transmission of data

 

Thanks @White, I like your envelope analogy. I will use this going forward in explaining how it works, at least it makes me sound like I know what I am doing lol.