I have a customer who tells me his field device communicates via serial comms using Modbus UDP.

The ports available to me to interface to this device support either Modbus RTU or Modbus ASCII.

So 2 Questions :-

1 What is Modbus UDP, if indeed it exists
2 Depending of 1 above is there a method of converting this data to RTU or ASCII

Thanks in advance

 

Keith Chappell wrote:
> The ports available to me to interface to this device support either
> Modbus RTU or Modbus ASCII.
>
> So 2 Questions :-
>
> 1 What is Modbus UDP, if indeed it exists

Never heard of it. Whatever it is, it isn't a published standard (like Modbus ASCII, Modbus RTU, or Modbus TCP) Go ask your customer more
information about that device.

> 2 Depending on 1 above is there a method of converting this data to RTU
> or ASCII

There's always a way -- writing a bridge isn't too hard to do, but whether or not you can pull one off the shelf or not depends on what the device is. My company could do some work and make one given the "Modbus UDP" spec, email me if you're interested.

Alex Pavloff - [email protected]
Eason Technology -- www.eason.com

 

Modbus UDP does exist, but I haven't seen a standard. It is used over IP, typically on Ethernet. UDP has less overhead than TCP but is unreliable. No, it's not that it doesn't get there, but it doesn't have the checks and resending that TCP does, so your application must either tolerate the occasional packet that falls on the floor, or implement it's own means for detacting packet loss. Lynn can probably tell you how much of this is around but my guess would be you would have to know how they are doing it to match it up on your own, and I can't say I've seen a commercial converter. But again, Lynn would know. Any Ethernet text would discuss UDP itself and there are excellent materials on the web.

Regards

cww

 

Well, thanks for the vote of confidence Curt.

I've seen Modbus/UDP on a number of systems - even back 5 years ago. Usually it is just Modbus/TCP form, but using UDP for transport - but could also be Modbus/RTU or Modbus/ASCII packed into UDP. You'll need to ask the customer for clarification. No, it is not covered by any standard, but when's that stopped vendors from using creative license & still calling it
"Modbus" ;^)

It shouldn't surprise anyone - under BSD sockets, using UDP instead of TCP is just changing 1 constant during open. A system which fully and properly supports Modbus/TCP (under TCP) could be justified to offer UDP in situations where data and/or packets cost money or time (for example
satellite or radio links). I've seen a few vendors in the power industry offer this OPTION - TCP or UDP at your choice. I don't fault them, as they offer the "standard" TCP form for those who expect it, and the UDP for those have value using it. We've gotten frequent requests for Modbus in UDP.

Unfortunately, some UDP products exist because the vendor doesn't have TCP yet - only UDP & IP. That is a problem. I personally think this is bad, since TCP is more complex than UDP, but not THAT much more. Putting such a product out seems to be asking for trouble - years of trying to explain to users "the problem". I call that a bit penny-wise and pound-foolish.

Best Regards

Lynn August Linse, [email protected]
IA Firmware Specialist, Digi Int'l (www.digi.com)

 

At SIXNET we have supported Modbus over UDP since 1995. It's just a slight variation of Modbus over TCP. We actually implemented UDP before TCP because for local area control networks it has some advantages. For details please go to:
http://www.sixnetio.com/html_files/presentation/udp_secret.htm
(Please note that all our Ethernet-enabled devices now support both Modbus TCP and UDP.)

As for converting Modbus/UDP (or Modbus/TCP) to Modbus ASCII or Modbus RTU, we have some converters that are specifically designed to do this. We simply take the Modbus message out of the UDP or TCP packet and then send it out the serial port as Modbus ASCII or RTU. The response is then converted back and sent out over Ethernet. Details on these units can be found at:
http://www.sixnetio.com/html_files/products_and_groups/ethernet_modbus.htm

 

No problem Lynn, It's your business to watch such things. I only watch until I get ticked off. But, I am a fan of published protocols on Open protocols. Modbus on UDP without some safeguards could be .....interesting. Especially on a network with some chatty windows boxes.

Regards
cww

 

Actually, from an application sense, Modbus/UDP is just as reliable as Modbus/TCP. Think of the transaction:

A master sends a Modbus/UDP poll: - if the slave gets the poll, it returns a Modbus/UDP response
- if the Master receives the response, the poll/response is complete (!@!@!)
- if the master does NOT receive the response, it's a time-out - just try poll again
- if the slave doesn't get poll, there is no response, it's a time-out - just try poll again
- in all cases, the slave doesn't really care if the master saw the response.
- in all cases, decades of Modbus/RTU have created masters capable of timeout & retry. Modbus/UDP is just like that.

The main difference between Modbus/TCP and Modbus/UDP is that we'll have 1 or 2 extra TCP/IP packets with just the ACK info set. Plus if an IP packet gets lost, the IP layer *MIGHT* recreate it faster than the Modbus Master application layer - depends on the TCP stack & we all know how real-time aware common stacks are. ;^)

I think the "real" difference between TCP and UDP (per chats with some of the early Modbus/TCP creators)

* UDP works perfect ONLY on small local area networks - the "wider" your area network becomes, the less predictable a UDP solution would become as each new hop or subnet leg added would increase the probability the packet is discarded. TCP would force the hop or leg discarding to recover, UDP would not & only a master application layer timeout would notice the problem.

* TCP works acceptly in LAN and WAN, plus anyone planning HTTP/Web access will also need TCP anyway. It has more overhead "here" in a LAN, but likely less perceived overhead in a complex WAN design.

So if one has to pick 1 of the 2 - TCP or UDP, then TCP is the more general-purpose solution. So if you accept that 1 world-wide common selection is better than 2 selectable, then Modbus/TCP is the natural choice. (At least that's the rational that was explained to me).

(By the way, our current generation DigiOne-IA-RP bridge handles Modbus/RTU and Modbus/ASCII packing in UDP or TCP - but not Modbus/TCP using UDP for transport, only TCP. Our next release will solve this slight inconsistancy and allow free bridging of the 3 formats Modbus/TCP, RTU, ASCII in either TCP or UDP transport. Hey, the market rules - when customers with big budgets ask for & need products, 3rd party suppliers are obligated (by our bosses) to respond ;^]

Best Regards

Lynn August Linse, [email protected] IA Firmware Specialist, Digi Int'l (www.digi.com)

 

That's true if the implementation maintains the timeouts and the values are selected intelligently and delays are accounted for. I'm not sure what the advantage would be other than a decrease in overhead. But I can see it if you are really low on processor power. And there are applications where a miss wouldn't make any difference. If you're writing open loop once per second and doing HVAC, this packet or the next wouldn't be a big deal.

Regards

cww

 

Mr. Linse is mostly correct on Modbus/TCP and UDP. Personally, I have never heard of Modbus/UDP, but technically it's feasible. Andy Swayles at Schneider developed Modbus/TCP in less than 3 months. It was a mapping of only the four most used Modbus commands to TCP/IP, and it worked great out of the box. The most current version of this protocol is posted for downloading on http://www.modbus.org.

A little story. I asked Andy why he didn't take advantage of the type of encoding into UDP that was done for Foundation Fieldbus HSE. Schneider was a member of the Foundation and they has access to that specification, which is also Type 5 of IEC 61158 Part 6 Fieldbus standard. Andy said that a proper implementation of UDP like HSE would have taken him much longer. For PC-to-PLC connection, Modbus/TCP is fast and efficient on 100 Mbps Ethernet, and extends well to the Internet, the objectives in Schneider's Transparent Factory initiative. If they were targeting the time-critical link of Remote I/O to PLC, then the determinism of a UDP-based protocol would have been necessary. But you cannot just map Modbus commands to UDP frames. As Mr. Linse points out, UDP does not have the end-to-end guaranteed delivery of TCP, so you need to do something in protocol itself to implement certain message frames where the application needs deterministic delivery -- such as flow integration and high priority trip alarming. Foundation Fieldbus HSE implements this type of encoding in UDP.

Modbus/TCP is a highly secure and efficient protocol for the transfer of data. It's just not deterministic for use in any synchronous or high speed control operation. It's a great SCADA protocol.

Dick Caro
============================================
Richard H. Caro, CEO
CMC Associates
2 Beth Circle, Acton, MA 01720
Tel: +1.978.635.9449 Mobile: +1.978.764.4728
Fax: +1.978.246.1270
E-mail: [email protected]
Web: http://www.CMC.us
============================================

 

Plus it doesn't take a large team to implement and it's published and usable with no license fee or royalties, or "membership bri^h^h^h fee". That is a vast advantage and should be encouraged. If the top 5 protos were as open it'd be a much nicer world for integrators.

As an aside, I start work Monday at the first job where I was actually hired to do automation. I guess that makes me an automation guy :^) I even get a shiny new hard hat. If that don't do it, nothing will.

Regards

cww

 

Hi All,

For those interested, the BACnet standard committee went with UDP on the basis that BACnet has lost packet recovery built in and so does not need TCP. For a more extensive discussion of their reasoning (which included a number of other issues as well) see http://www.bacnet.org/Tutorial/BACnetIP/sld002.html.

BTW, BACnet has just been approved as an ISO standard (ISO 16484-5) so we can expect to see much wider adoption internationally.

Regards

Peter Whalley
Magenta Communications Pty Ltd
Melbourne, VIC, Australia
e-mail: peter*no-spam*@magentacomm.com.au
delete *no-spam* before sending