does anyone have experience with Data-Linc RTUs? Can't get ModbusTCP to work.

defcon.klaxon

Lifetime Supporting Member
Join Date
Feb 2015
Location
Far NorCal
Posts
616
Hey guys,

Part of the project I'm working on currently is a remote RTU system that is made by Data-Linc; the remote RTU is a CIX-6430 and the master is a CIX-6435. There's only one single remote RTU, so it's pretty simple. The remote RTU has two analog inputs from level transmitters and simply passes a raw value up to the master via spread spectrum (900 MHz) radio. What I'm trying to do is get my RX3i to communicate with the master via ModbusTCP.

After having issues in the field that we thought might be radio path related, I grabbed the two units and put them on my bench, connected via attenuator so that radio path uncertainty was eliminated. Once I got the radios properly configured, I tried using a program on my laptop to poll the remote site via the master. Wasn't working via ModbusTCP, but when I switch to ModbusRTU and connect to the master via serial cable instead of ethernet, it works exactly as intended. I've tried ModbusTCP with qModMaster and SimplyModbus, both throw errors.

I'm talking with tech support but thought I'd ask and see if anyone here has tangled with these devices before.
 
The first thing I’ll address is the Radio connection. The radios in those units are some of the best radio modems on the planet and the likelihood that they are the problem, especially on the bench, is remote to none and unless you’ve got at least 120dB of attenuation and the xmit power turned down to 1 (or less) you’re possibly doing damage to the receivers so I’d remove the attenuator and put antennas back on. The simplest way to determine if the units are talking to each other is via the LED’s. If the “I” and “O” LED’s on the remote (the CIX6430) are constantly flashing, then the remote is in constant communications with the master (the CIX6435) and is working normally). If those LED’s are pausing, then the master is programmed with more than one remote and needs to be reprogrammed to just the one remote. Having said that because it worked with Modbus RTU it’s safe to say this isn’t a remote addressing (radio addressing) issue.
As to Modbus TCP, a vast majority of DLG’s applications are Allen Bradley so my experience was focused on that so I had little opportunity to work with Modbus TCP so I’m not going to be much help but I can suggest a few things to look at. This first one is a common mistake so if it seems “insulting” I apologize (I used to make this mistake all the time) Modbus TCP server = Modbus Slave, Modbus TCP client = Modbus Master. The CIX6435 is the Modbus TCP Server and your software/ GE RX3i is the Modbus TCP Client. This gets confusing because when you configure the CIX6435 you configure it as a Master but that’s between the two modems (in which case it is the master) but when you are talking about between the modem and the PLC, the modem is the slave to the PLC. You may also want to try playing around with the register addressing. Modbus (you probably also know this one already as well) has “PLC” and “Non-PLC” addressing one starting at “0” and the other starting at “1”. Sometimes you just gotta “play with it”. It is very possible that when the CIX6435 is using Modbus RTU it will use the PLC addressing and when using TCP it will use the other (a bug). I’m not saying it is this way, but I’ve seen stranger things.
I wish I could be more help, but I don’t work there anymore, and I don’t have access to the units or the software, so I can’t do any testing. I you have access to a Modbus RTU port my recommendation would be to use that as I do know that Modbus RTU, with regards to the CIX6435 is more stable (for that matter if you could go DF1 or EtherNet IP/TCP that would be even better) but it should work with Modbus TCP.
 
Hi Firejo,

Thanks for the response. I've spent the day digging to what's really going on here, and have some technical info to share. Nothing like getting down to the bit/byte level of raw data and reading the Modbus/TCP spec to celebrate it being Friday, haha.

So let's talk Modbus in general; it's a comms protocol that strings together bytes and ships them out serially. Thus, we can break up the string and see what each byte does. For example, if I want to read the first analog input register, the Modbus TCP request message would be:

00 01 | 00 00 | 00 06 | 01 | 04 | 00 00 | 00 01

From left to right, I'll describe each "section" of the string, which are delimited by the vertical bars.

Sections 1-3 are called the MBAP, or Modbus Application Header. It's used for Modbus TCP only; Modbus RTU starts with the slave ID and ends (after section 7) with a CRC for error checking. In Modbus TCP, the slave ID and CRC are lopped off, and the remaining data is called the PDU, or Protocol Data Unit (that's sections 4-7).


Sections Explained:
1 – Transaction ID (this keeps track of requests, and increments each time you send a new request)
2 – Protocol ID (always 00 00, this means Modbus TCP)
3 – Message Length (how many bytes will be in the PDU, or Protocol Data Unit…that’s 4-7, or 6 bytes in this case)
4 – Unit ID – address of the Slave (disclaimer - this is a bizarre section and the Modbus/TCP spec makes for confusing reading; they suggest setting it to 0 or 16#FF, but when I am testing it seems to work best when the slave ID is used in my case; YMMV)
5 – Modbus Function Code – 4 for reading input registers
6 – Starting Address of Data – the Modbus Function Code of 4 means input registers, that means an assumed offset of 30001; thus 00 00 means start at 30001
7 – Length of Data – how many registers to read; this case, a singular register which is 30001, or Analog Input 1

What is interesting is that when I test this on the Data-Linc modem, the response I get is just the request I sent; it doesn’t actually send any data, it just echoes what I’ve requested.

Thus if my request is
00 01 | 00 00 | 00 06 | 01 | 04 | 00 00 | 00 01

and I watch the data bus, the response from the Data-Linc modem is

00 01 | 00 00 | 00 06 | 01 | 04 | 00 00 | 00 01

However, if I test this with another PLC (Scadapack) I have in the office, the response is different. When the Modbus request is successful with the Scadapack, the response is:

00 01 | 00 00 | 00 05 | 01 | 04 | 02 | 00 00

Section Descriptions:
1 - Transaction ID (should match the request)
2 - Protocol ID (00 00 for Modbus TCP, just like request)
3 - Message Length (response of PDU is 5 bytes, which is still 4-7 but you see there’s only 5 bytes in the response instead of 6 in the request)
4 - Unit ID – same as request
5 - Modbus Function Code – 4 , or read input registers; this confirms that the response matches the requested FC)
6 - Number of Bytes of data requested – in this case, the data requested is two bytes long, which is a single 16 bit register
7 - Data Requested – this is the data in the register I’ve requested to read, in this case it’s 30001 and the input is 0)


I’ve also set up my GE PLC (a spare that matches what we have installed out in the field for this project) to read from the Data-Linc radio and while I can open and close a connection, when I request the read data I get a “protocol error” but nothing more specific is mentioned. I would be willing to bet it’s that the response message is the echoed request message, which can’t be interpreted as a response.

That all being said, not sure what to make of this and not sure why the modem would just echo the request instead of providing a response. I've provided this info to tech support, hopefully it'll help with troubleshooting. It's certainly been interesting getting "under the hood" of how Modbus TCP works, it's definitely helpful for troubleshooting purposes.
 
Last edited:
I could be wrong but I thought Modbus is just Modbus TCP wrapped up.

I would suggest you use Wireshark to look at the request going out from your Modbus Master simulator and the response, if any, coming back.

Sound you got modbus down quite well, I didn't understand it in any detail until I took a online course at Udemy. $10 well spent.
 
Modbus is just Modbus TCP wrapped up.

Modbus/TCP is not just Modbus RTU "encapsulated" across a TCP connection.

But some Ethernet master devices do give you the option to run "Modbus RTU Ethernet encapsulation" instead of true Modbus/TCP. If you have a end device that is a general-purpose TCP/Serial server, that's one way to do it.

defcon.klaxon's discovery that he's getting an echo instead of a response suggests there's a setting someplace that is inadvertently echoing incoming data instead of processing it.

The Unit ID is often a stumbling point for Modbus/TCP devices. It's included there because a common type of Modbus/TCP device is a protocol bridge that unwraps the command and sends it out over a serial port as Modbus RTU protocol. The Unit ID becomes the Slave ID in that Modbus RTU packet.

Any given device is a coin-flip as to whether it wants you to use 0, 255, or 1 as the Unit ID, or whether it ignores the Unit ID entirely.

If you can grab the Wireshark trace itself, ZIP and post, that might be useful.
 
I could be wrong but I thought Modbus is just Modbus TCP wrapped up.

The information I gathered came from two sources; first is SimplyModbus.ca and the second was the Modbus/TCP spec. Using those two sources I worked out the byte string for both RTU and TCP modes, and then used the SimplyModbus RTU and TCP software to send messages to my various PLCs. The byte strings in the request are shown as they're constructed, and the responses are shown as well so I was able to follow along.

I would suggest you use Wireshark to look at the request going out from your Modbus Master simulator and the response, if any, coming back.

That may be interesting to see; as I said above, I'm able to see the data bus going and coming via the SimplyModbus software tools (and I've tried other software tools as well with identical results).

Sound you got modbus down quite well, I didn't understand it in any detail until I took a online course at Udemy. $10 well spent.

At this point I feel fairly confident in my understanding of it. I really like getting into the bit/byte level of things like this. Really helps with understanding and troubleshooting.
 
Your alternative server/slave, Scadapack, provides a valid Modbus/TCP response and does not throw an error/fault.

Given that the Scadapack reply message format is different from the Data-linc reply, I'd say GE's assessment of "protocol error" is on target and correct.

It looks like a Data-linc firmware problem to me, given the evidence you've put on the table.
 
Another thought: Could the "slave" radio be set up in a Repeater mode, so that it's re-transmitting the packet instead of processing it ?
 
Modbus/TCP is not just Modbus RTU "encapsulated" across a TCP connection.

Indeed, it's not quite that simple. For those interested, here's a handy diagram showing the differences between Modbus RTU and TCP:

adu_pdu.PNG


But some Ethernet master devices do give you the option to run "Modbus RTU Ethernet encapsulation" instead of true Modbus/TCP. If you have a end device that is a general-purpose TCP/Serial server, that's one way to do it.

This is interesting info, I'll put it in my back pocket for future use.

defcon.klaxon's discovery that he's getting an echo instead of a response suggests there's a setting someplace that is inadvertently echoing incoming data instead of processing it.

It definitely is interesting. I checked the software configuration tool that is provided with the Data-Linc hardware and there's nothing in the configuration that seems to be adjustable; it's pretty spartan when it comes the Modbus configuration; basically you choose whether to use Modbus or Ethernet/IP or DF1; if Modbus, you choose which port for TCP and then serial config (baud, parity, etc). I'm hoping my discovery will help the tech support folks hone in on what's going on.

The Unit ID is often a stumbling point for Modbus/TCP devices. It's included there because a common type of Modbus/TCP device is a protocol bridge that unwraps the command and sends it out over a serial port as Modbus RTU protocol. The Unit ID becomes the Slave ID in that Modbus RTU packet.

Thanks for the explanation. In my readings, they didn't mention the protocol bridge aspect, just that the Unit ID was for devices connected via serial bus, which was vague enough to just confuse me.

Any given device is a coin-flip as to whether it wants you to use 0, 255, or 1 as the Unit ID, or whether it ignores the Unit ID entirely.

Yeah I did some experimenting with these values and found exactly as you describe; sometimes it didn't matter at all, and sometimes it would mess things up. In the future I'll be using this to troubleshoot.

If you can grab the Wireshark trace itself, ZIP and post, that might be useful.

I'll see what I can do, thanks for chiming in with your info Ken, you were spot on across the board!
 
Your alternative server/slave, Scadapack, provides a valid Modbus/TCP response and does not throw an error/fault.

Given that the Scadapack reply message format is different from the Data-linc reply, I'd say GE's assessment of "protocol error" is on target and correct.

It looks like a Data-linc firmware problem to me, given the evidence you've put on the table.

I'm thinking more and more that it's a Data-Linc firmware issue too. Given what I've learned about the Modbus protocol and how two other PLCs have functioned flawlessly, I feel pretty confident in pointing my finger at the Data-Linc hardware. In fact I did a little test and with the software configurator, I checked the model and firmware version; strangely the model comes back as a CIX-6535 when the unit is actually a CIX-6435...now who knows what they're up to down in the firmware, maybe firmware wise they are using that as an indicator of newer versions so that doesn't necessarily mean anything, but the firmware is two years old so maybe updating would help.
 
Another thought: Could the "slave" radio be set up in a Repeater mode, so that it's re-transmitting the packet instead of processing it ?

Good question. I don't believe that's the case, as Modbus RTU works just fine and I can grab the register data all day long. Juuuust to be sure, I did bring up the configuration and no repeater functionality is activated, so I think I'm good but thanks for the suggestion Ken!
 

Similar Topics

Hi all, Client called saying that the turbidity readout on the HMI is 0.0000 but on the local readout, it shows an actual value. Sure enough...
Replies
12
Views
5,337
I migrated a SLC500 rack that was RIO to a PLC5 processor. It is now on a 1756-L73. I got confused by the setup of the card and thought it was...
Replies
3
Views
1,310
Hello folks, Is this the right forum for HMI related questions? We are not using a PLC in our HMI, but a data logger. Looking for peoples...
Replies
2
Views
1,700
Replies
2
Views
1,736
Need some help here (again). I tried to download my HMI to the PLC and I get this error message about a missing file. Can anyone help?
Replies
3
Views
668
Back
Top Bottom