I am trying to get a Unitronics V570 (Master) to connect to another V570 (Slave) and read a single Memory Integer using Modbus RTU protocol. They will be installed a couple of miles apart and I have line of site so trying to get a couple of RF Radios to achieve the communication between the two. We're using a couple of XStream-PKG by Digi RS232/RS485 RF Radios. I'm currently trying RS232 and getting nothing. A direct cable connection using the cables and connectors in the setup results in communication. I can get the RF Radios to link up using software by Digi. When mimic the connection like in the field I get nothing. I've tried both 19200 and 9600 Baud Rate. Any one with experience with these setups? Would it be better to use RS485 for this? I assume on the Master side TX of V570 matches up directly with TX of RF Radio. On the Slave side it crosses over after exiting the RF Radio?
PLC to PLC Communication - RF Radio & Modbus RTU
- Thread starter jweav2223
- Start date
Firejo
Member
A couple of things.
First, a lot of Modbus RTU devices run using an 11 bit word (8 data bits, 1 stop bit and Even or Odd parity) and most radio modem default to a 10 bit word (8 data bits, 1 stop bit and no parity). I think the Xstream radios can be set to use an 11 bit word and for that matter the V570’s might be a 10 bit word or can be configured to use a 10 bit word. The long and short is you’ll need to know what the V570’s are using, how they are configured and how they can be configured. Same thing with the radios, you need to know how they are configured and how they can be configured so everything matches.
Next, not all radios will work with Modbus RTU. I don’t know if the Xstream’s do but that is something you will need to know and must use. Modbus RTU uses a gap in the data as part of the protocol and hopping radios create gaps. You need a radio that uses buffers to prevent the gap from seeing the serial port. A lot of radios do this (Data-Linc and FreeWave modems for example) but you will pay more for them (industrial automation communications is a “you get what you pay for” world).
Last, with RS232 you don’t connect TX to TX, you connect TX to RX and RX to TX. If the equipment you are using follows the RS232 standard (not everybody does) there are two types of devices, DTE (Data Terminal Equipment) and DCE (Data Circuit-terminating equipment also called Data Communications Equipment). DTE devices are “end devices” meaning communications start and end with them (PC, PLC, etc…). DCE devices are devices that transport communications such as modems. As far as the DTE and DCE port pinouts are concerned the biggest difference is that the transmit line (TX) and receiver line (RX) are swapped so that when you connect a DTE device to a DCE device you use a straight cable (2 to 2, 3 to 3, etc…). This gives you the TX to RX that you need. So I’m guessing that the V570’s are going to be DTE devices and I know the Xstream’s are DCE devices. With that you should need a straight cable with pins 2, 3 and 5 (assuming both are DB9’s) going straight through (2 to 2, 3 to 3 and 5 to 5).
To sum it up, you can either do a lot of “playing around” trying to find the matching configuration between the V570’s and the radio modems or you can do some homework and figure out what you’ve got and set them up to play nice with each other. Either way you’ve to some work to do but it should be doable.
First, a lot of Modbus RTU devices run using an 11 bit word (8 data bits, 1 stop bit and Even or Odd parity) and most radio modem default to a 10 bit word (8 data bits, 1 stop bit and no parity). I think the Xstream radios can be set to use an 11 bit word and for that matter the V570’s might be a 10 bit word or can be configured to use a 10 bit word. The long and short is you’ll need to know what the V570’s are using, how they are configured and how they can be configured. Same thing with the radios, you need to know how they are configured and how they can be configured so everything matches.
Next, not all radios will work with Modbus RTU. I don’t know if the Xstream’s do but that is something you will need to know and must use. Modbus RTU uses a gap in the data as part of the protocol and hopping radios create gaps. You need a radio that uses buffers to prevent the gap from seeing the serial port. A lot of radios do this (Data-Linc and FreeWave modems for example) but you will pay more for them (industrial automation communications is a “you get what you pay for” world).
Last, with RS232 you don’t connect TX to TX, you connect TX to RX and RX to TX. If the equipment you are using follows the RS232 standard (not everybody does) there are two types of devices, DTE (Data Terminal Equipment) and DCE (Data Circuit-terminating equipment also called Data Communications Equipment). DTE devices are “end devices” meaning communications start and end with them (PC, PLC, etc…). DCE devices are devices that transport communications such as modems. As far as the DTE and DCE port pinouts are concerned the biggest difference is that the transmit line (TX) and receiver line (RX) are swapped so that when you connect a DTE device to a DCE device you use a straight cable (2 to 2, 3 to 3, etc…). This gives you the TX to RX that you need. So I’m guessing that the V570’s are going to be DTE devices and I know the Xstream’s are DCE devices. With that you should need a straight cable with pins 2, 3 and 5 (assuming both are DB9’s) going straight through (2 to 2, 3 to 3 and 5 to 5).
To sum it up, you can either do a lot of “playing around” trying to find the matching configuration between the V570’s and the radio modems or you can do some homework and figure out what you’ve got and set them up to play nice with each other. Either way you’ve to some work to do but it should be doable.
danw
Lifetime Supporting Member
Firejo gets 5 stars * * * * * for that answer. Excellent.
I would use RS-232 because the pin/out functionality is typically defined in the documentation and tx is always Tx, it's never Rx, whereas in RS-485 A/B, +/- data line functionality can vary depending on vendor, creating another stumbling block.
I would use RS-232 because the pin/out functionality is typically defined in the documentation and tx is always Tx, it's never Rx, whereas in RS-485 A/B, +/- data line functionality can vary depending on vendor, creating another stumbling block.
Both my PLC and RF Radio can be changed to use 11 or 10 Bit Word. I have had them matched up at 8 Data Bit, 1 Stop Bit, No Parity. Also both set to No Flow Control.
Already researched if the XStream-PKG was able to work with Modbus RTU. Straight from their website this line is able to with timing adjustments. Yes Modbus ASCII works easier, but the Unitronics PLC does not use Modbus ASCII. I can customize it for Modbus ASCII using Protocol Function Blocks but would take a couple of days of programming in my estimation. Andy why when Digi says this line is able to do RTU? Researching more on Digi previously I discovered that inter-character delay requirements must be met to make it compatible with the latencies. To satisfy that they recommend the transfer data over the air at twice the serial baud rate. Given I have a 19.2 RF Radio that would be 9600. Which RF Radios and PLCs have been set at.
I think my issues were arising with the serial connections which I am testing this morning. I was under the impression it went like this.
PLC #1 TX --> RF Radio #1 TX <----Over the Air ---> RF Radio #2 TX ---> PLC #2 RX
This would justify the TX -- RX requirement
But it sounds as if you're describing this
PLC #1 TX --> RF Radio #1 RX <----Over the Air ---> RF Radio #2 TX ----> PLC #2 RX
I've made a couple of custom "straight through" cables as well as using some DB9 Connectors with Terminal Blocks so that I can easily keep track of each crossing over that might occur. The PLC used a RJ11 Connector Cable that crossed over. I was trying to use a RJ11-DB9 Connector from Unitronics, DB9 Gender Changing Adapter and then to the RF Radio.
My questions would be do you suggest increasing the RS232 Time Out and Modbus Time Out? Or would these really have no effect on operation?
Already researched if the XStream-PKG was able to work with Modbus RTU. Straight from their website this line is able to with timing adjustments. Yes Modbus ASCII works easier, but the Unitronics PLC does not use Modbus ASCII. I can customize it for Modbus ASCII using Protocol Function Blocks but would take a couple of days of programming in my estimation. Andy why when Digi says this line is able to do RTU? Researching more on Digi previously I discovered that inter-character delay requirements must be met to make it compatible with the latencies. To satisfy that they recommend the transfer data over the air at twice the serial baud rate. Given I have a 19.2 RF Radio that would be 9600. Which RF Radios and PLCs have been set at.
I think my issues were arising with the serial connections which I am testing this morning. I was under the impression it went like this.
PLC #1 TX --> RF Radio #1 TX <----Over the Air ---> RF Radio #2 TX ---> PLC #2 RX
This would justify the TX -- RX requirement
But it sounds as if you're describing this
PLC #1 TX --> RF Radio #1 RX <----Over the Air ---> RF Radio #2 TX ----> PLC #2 RX
I've made a couple of custom "straight through" cables as well as using some DB9 Connectors with Terminal Blocks so that I can easily keep track of each crossing over that might occur. The PLC used a RJ11 Connector Cable that crossed over. I was trying to use a RJ11-DB9 Connector from Unitronics, DB9 Gender Changing Adapter and then to the RF Radio.
My questions would be do you suggest increasing the RS232 Time Out and Modbus Time Out? Or would these really have no effect on operation?
Modbus is configured fine on the PLCs. I confirmed this with a direct cable connection with no issues. I ditched RS232 and trying RS485 now. I have previous experience with this involving PLC-VFD connections.
Something confusing was following the +/+ and -/- connections was fine on the Master & RF Radio #1 side, but resulted in a solid LED for "Data In" on Slave & RF Radio #2 side. I crossed those over and LED went away.
When testing and trying to write a value I did get a brief "Data In" for Radio #1 and "Data Out" for Radio #2. But no data actually written to the Slave PLC
My RS485 setup is PLC #1 RS485 Termination -- RF Radio #1 RS485 ----- RF Radio #2 RS485 --- PLC #2 RS485 Termination
Something confusing was following the +/+ and -/- connections was fine on the Master & RF Radio #1 side, but resulted in a solid LED for "Data In" on Slave & RF Radio #2 side. I crossed those over and LED went away.
When testing and trying to write a value I did get a brief "Data In" for Radio #1 and "Data Out" for Radio #2. But no data actually written to the Slave PLC
My RS485 setup is PLC #1 RS485 Termination -- RF Radio #1 RS485 ----- RF Radio #2 RS485 --- PLC #2 RS485 Termination
danw
Lifetime Supporting Member
That's what I would start with.
Like wise PLC#1 Rx --> RF Radio #1 Tx . . . .
Gnd --> Gnd
I'm not sure what RS232 Time out is. Modbus Time Out is traditionally how long the master waits for a reply until it gives up and makes the next polling transaction in its list.
Default is probably 1 second. That should suffice for efforts to get them talking to each other.
danw
Lifetime Supporting Member
Termination becomes more critical at higher baud rates and at longer cabling distances. I'm guessing the radios are within a short distance of the PLC, so termination is not critical.
Termination should be at both ends of a 485 line:
on one end, PLC 485 terminated, Radio 485 terminated
on the other end, Radio 485 terminated, PLC 485 terminated.
But it's rare that lack of termination kills bench top testing, if ever.
Firejo
Member
The issue with Modbus RTU is that it uses a 3.5 character gap in the data to determine the “end of message”. If the packets are larger than the size the radio is breaking the incoming data into then you’ll get artificial gaps which will tell the receiving device that the packet is finished which it isn’t. While Digi states their radios are compatible with Modbus RTU my recollection, having tested them (some time ago) was that they weren’t very good at it and you had to do a lot of “playing around” to find a good combination. If you know the size of the data packets being sent and can figure out how to set the radios to deal with packets that size (or larger) you might get it to work however keep in mind that what you do in the lab won’t always be the same as what happens in the field I.E. if the radios have to deal with noise the packets handling might change. The way other radios have dealt with Modbus RTU is to create a buffer on the receiving (RF) device that collects the data until a defined amount is collected. That way if the radio has to resend packets several times the serial port still won’t release the data until it’s complete. You add latency but gain reliability (this is what FreeWave and Data-Linc do).
The other thing to note about Xstream radios is they are very much a “you get what you pay for” radio. More than once I’ve consulted with someone and concluded that a Xstream radio (formerly MaxStream) simply couldn’t handle the noise in the area. They are what I call a “works on paper” radio where the design looks good but real world implantation doesn’t allow for the radio to compensate for noise and temperature. So, enough Xstream bashing (although I could go on).
Keep in mind that if this is a Modbus RTU issue there won’t be any difference between RS232 and RS485. One thing you might try doing is a loopback test (using RS232). That way you can at least confirm that the radios are capable of sending data in both directions. Maybe you’ve got a bad radio?
The other thing to note about Xstream radios is they are very much a “you get what you pay for” radio. More than once I’ve consulted with someone and concluded that a Xstream radio (formerly MaxStream) simply couldn’t handle the noise in the area. They are what I call a “works on paper” radio where the design looks good but real world implantation doesn’t allow for the radio to compensate for noise and temperature. So, enough Xstream bashing (although I could go on).
Keep in mind that if this is a Modbus RTU issue there won’t be any difference between RS232 and RS485. One thing you might try doing is a loopback test (using RS232). That way you can at least confirm that the radios are capable of sending data in both directions. Maybe you’ve got a bad radio?
I removed PLC #2 and connected RF Radio #2 to the PC to see the data coming out of it via the X-CTU Software. I was getting what looks to be a Modbus message.
02 10 00 64 00 01 02 00 E6 3B 0E
My original thinking was that while it may be a "you get what you pay for" type of component it would still be fine for this persons application. Rural community less than two miles from each other with line of site. I was unaware of the issues I would have with it not being able to send Modbus RTU okay. Data Sheet mentioned Modbus so assumed it would handle RTU and ASCII with the same ease.
The X-CTU Software has a testing portion using a Loopback Adapter. I was able to successfully get them to connect down to 4800 Baud Rate. Lower than that it was failing. Assuming there is a Time Out setting within its Configuration but declined to dig further.
Unitronics does allow Protocol Function Block so technically I think with more time than I originally planned I can convert to Modbus ASCII. That is my next step.
Any suggestions of literature to read in regards to this conversion?
02 10 00 64 00 01 02 00 E6 3B 0E
My original thinking was that while it may be a "you get what you pay for" type of component it would still be fine for this persons application. Rural community less than two miles from each other with line of site. I was unaware of the issues I would have with it not being able to send Modbus RTU okay. Data Sheet mentioned Modbus so assumed it would handle RTU and ASCII with the same ease.
The X-CTU Software has a testing portion using a Loopback Adapter. I was able to successfully get them to connect down to 4800 Baud Rate. Lower than that it was failing. Assuming there is a Time Out setting within its Configuration but declined to dig further.
Unitronics does allow Protocol Function Block so technically I think with more time than I originally planned I can convert to Modbus ASCII. That is my next step.
Any suggestions of literature to read in regards to this conversion?
danw
Lifetime Supporting Member
The message looks somewhat reasonable, without confirming the CRC value:
- slave 2
- Function Code 10h
- start address 0064
- qty of registers 0001
- byte count 02
- register data values 00E6
- CRC 3B0E
If I understand properly, the msg was PLC 1 > radio 1 > radio 2 > PC, correct?
If so, the radio link works, right?
If the radio link works, what exactly is not working at this point?
Converting to Modbus ASCII has severe stumbling blocks. If the PLCs are designed for RTU mode, then
- their inherent serial timing scheme is RTU based, not ASCII based. So you can recode the message for ASCII, but the sender/receivers will still expect RTU timing performance.
- the error checking is, by design, CRC. In order to get an ASCII coded message (which uses LRC) through the slave receiver, without the slave throwing an exception code, you would have to pack an ASCII message into an RTU packet with RTU CRC and RTU timing in order get the RTU packet through successfully. If you can get an RTU packet through successfully, why bother with anything but RTU?
- Modbus ASCII uses 7 bit words, not 8 bit words, which separates the two at UART level. You can pack a leading 0 to fake 8 bit and if you're coding for it and you know it OK.
Modbus ASCII and RTU are two different protocols. Unless you value your time at zero or are retired and doing charity work, I'd say converting from RTU to ASCII is a loser proposition.
- slave 2
- Function Code 10h
- start address 0064
- qty of registers 0001
- byte count 02
- register data values 00E6
- CRC 3B0E
If I understand properly, the msg was PLC 1 > radio 1 > radio 2 > PC, correct?
If so, the radio link works, right?
If the radio link works, what exactly is not working at this point?
Converting to Modbus ASCII has severe stumbling blocks. If the PLCs are designed for RTU mode, then
- their inherent serial timing scheme is RTU based, not ASCII based. So you can recode the message for ASCII, but the sender/receivers will still expect RTU timing performance.
- the error checking is, by design, CRC. In order to get an ASCII coded message (which uses LRC) through the slave receiver, without the slave throwing an exception code, you would have to pack an ASCII message into an RTU packet with RTU CRC and RTU timing in order get the RTU packet through successfully. If you can get an RTU packet through successfully, why bother with anything but RTU?
- Modbus ASCII uses 7 bit words, not 8 bit words, which separates the two at UART level. You can pack a leading 0 to fake 8 bit and if you're coding for it and you know it OK.
Modbus ASCII and RTU are two different protocols. Unless you value your time at zero or are retired and doing charity work, I'd say converting from RTU to ASCII is a loser proposition.
Works now in that a message is being sent from Radio #1 to Radio #2. PLC#2 is not recognizing the message though as the value is not being written and PLC#1 is not getting that handshake confirmation so Status Message of Modbus is "Error No Response"
My message was to "Preset Holding Register 16" or write a value of a single Memory Integer from Master Address MI100 to Slave Address #100. The value at the time was 230 I believe. Slave Network ID #2
Slave Network ID matches up (#2). Quantity of Registers matches up (#1). Register Data Values matches up (#230). I think Function Code 10 Hex is correct for Preset Holding Registers (?), Not sure what CRC references? Biggest thing I see wrong is Start Address!
When I read the Modbus Command yes it was the following:
PLC#1 --> Radio #1 --> Radio #2 --> PC
In the field or with testing it will be:
PLC#1 --> Radio #1 --> Radio #2 --> PLC #2
I guess technically speaking I miss spoke when I referenced it as converting from RTU to ASCII. Unitronics programming allows for making your own Protocol essentially. So I really meant just making a ASCII message to be sent using these function blocks. But like you said their timing for any of these protocols may just be by default the RTU method.
My message was to "Preset Holding Register 16" or write a value of a single Memory Integer from Master Address MI100 to Slave Address #100. The value at the time was 230 I believe. Slave Network ID #2
Slave Network ID matches up (#2). Quantity of Registers matches up (#1). Register Data Values matches up (#230). I think Function Code 10 Hex is correct for Preset Holding Registers (?), Not sure what CRC references? Biggest thing I see wrong is Start Address!
When I read the Modbus Command yes it was the following:
PLC#1 --> Radio #1 --> Radio #2 --> PC
In the field or with testing it will be:
PLC#1 --> Radio #1 --> Radio #2 --> PLC #2
I guess technically speaking I miss spoke when I referenced it as converting from RTU to ASCII. Unitronics programming allows for making your own Protocol essentially. So I really meant just making a ASCII message to be sent using these function blocks. But like you said their timing for any of these protocols may just be by default the RTU method.
danw
Lifetime Supporting Member
The PC receives the message from the master and displays it for you. The wiring and Modbus master poll through the radio link works.
I agree with your messaging: PLC #1 (the master) writes a single register integer value 230 decimal to Modbus Slave #2's register #100 decimal.
The PLC does is not responding, so it is either not recognizing the serial message from the radio or its logic isn't doing the Modbus thing.
Why doesn't slave PLC #2 get it?
wrong slave ID # ? (you are addressing slave 2, most devices default to slave 1, are you sure that the PLC is at node 2 address?)
serial settings: wrong baud rate/wrong word size, wrong parity ? On both the radio and the PLC.
Is the PLC port 232 or 485? DIP switch or firmware set? (on both radio and PLC)
wrong wiring terminal connections between radio #2 and PLC #2 ? Did you draw out a wiring diagram and have someone else check the wiring?
wrong 'logic' or setup - dealing with the Modbus port as a slave node
It's easy to leave a 232 setting intact when changing to 485. check and re-check.
I don't know what the Unitronics needs to have 'enabled' for it to recognize the serial port as Modbus RTU and to put the data it receives into register 100, wherever that is. Read and re-read the manual on that part. That's what's stalling you at this point.
I agree with your messaging: PLC #1 (the master) writes a single register integer value 230 decimal to Modbus Slave #2's register #100 decimal.
The PLC does is not responding, so it is either not recognizing the serial message from the radio or its logic isn't doing the Modbus thing.
Why doesn't slave PLC #2 get it?
wrong slave ID # ? (you are addressing slave 2, most devices default to slave 1, are you sure that the PLC is at node 2 address?)
serial settings: wrong baud rate/wrong word size, wrong parity ? On both the radio and the PLC.
Is the PLC port 232 or 485? DIP switch or firmware set? (on both radio and PLC)
wrong wiring terminal connections between radio #2 and PLC #2 ? Did you draw out a wiring diagram and have someone else check the wiring?
wrong 'logic' or setup - dealing with the Modbus port as a slave node
It's easy to leave a 232 setting intact when changing to 485. check and re-check.
I don't know what the Unitronics needs to have 'enabled' for it to recognize the serial port as Modbus RTU and to put the data it receives into register 100, wherever that is. Read and re-read the manual on that part. That's what's stalling you at this point.
Firejo
Member
One thing you might also consider trying is Modbus Poll and Slave (you’ll need either two computers or one computer with two available ports). That way you could test the radios and PLC’s separately. The other consideration would be to track down a couple of used SRM6000’s or FreeWave serial modems (they have several models all compatible with each other (as long as their all 900MHz)). They both are readily available on Ebay however that is a little bit of a gamble. For that matter you could buy new SRM6030’s (the current version of Data-Linc’s serial modem) or FreeWave’s FGR2-CE modems but it sounds like that’s not a budget friendly solution.
That being said if it’s possible to create an ASCII protocol then that might be a good fit as well. Just remember you’re dealing with $80 radios and that’s the performance you can expect.
http://www.modbustools.com/modbus_poll.html
That being said if it’s possible to create an ASCII protocol then that might be a good fit as well. Just remember you’re dealing with $80 radios and that’s the performance you can expect.
http://www.modbustools.com/modbus_poll.html
Pretty sure your comm cables should be the same at both sites, PLC TX to Radio TX, PLC RX to Radio RX, the radio "flips" the TX/RX in the transmission -
PLC TX --> TX Radio <--Overair--> RX Radio --> RX PLC
PLC RX --> RX Radio <--Overair--> TX Radio --> TX PLC
PLC TX --> TX Radio <--Overair--> RX Radio --> RX PLC
PLC RX --> RX Radio <--Overair--> TX Radio --> TX PLC
Similar Topics
i have two plc
1. s7-1212dc/dc/dc ip; 192.168.0.1
2. s7-1500 1513-1pn ip; 192.168.3.2
i need to get data from plc1 to plc2. any idea how to do...
I have created a project in TIA Portal v16 Upd6 with S7-1200 (6ES7214-1AG40-0XB0) and WinCC Unified (PC station). The communication between the...
Hello
We have installed several G.E. Fanuc 90 70 PLC
Everything was ok but suddenly we can not communicate anymore with any PLC with the software...
Apologies for not being the best IDEC programmer. I recently was doing some inspections on a site that had 3 FC6A IDEC processors. The issue is...
I'm trying to write a data in Arduino using MODWR function block .I used the code I got from online for both PLC and Arduino. I made the wiring...