I am interested in the Modbus UDP, and we did a program in a small controller for Modbus/TCP. Only just found out the IO Scanning by Schneider uses UDP.

Anyone document on this Modbus/UDP or know where to find? Our working program for Modbus/TCP lose connection when we send a reply to the IO Scanning.

Modbus/UDP need to be in connected state like the TCP? Same port number 502?

Hope you can help?

 

UDP is the basic Network Layer protocol of the internet. TCP is a Transport Layer protocol that is layered over UDP. In other words, all TCP/IP messages use UDP encoded data frames. Modbus TCP is a simple protocol that uses TCP/IP to communicate messages framed in Modbus content. TCP features end-to-end checking for message delivery. It also has some pacing features needed by the Internet, but not by local area networks. The typical TCP/IP driver for LANs, disables lots of the Internet features for efficiency and speed. The messages are sent from point to point using UDP, but the basic message still uses TCP error checking.

Dick Caro

===========================================
Richard H. Caro, Certified Automation Professional, CEO, CMC Associates,
2 Beth Circle, Acton, MA 01720 USA
E-mail: RCaro [at] CMC.us
Subscribe to the CMC Wireless Report
Web: http://www.CMC.us
Buy my books:
http://www.isa.org/books
Automation Network Selection
Wireless Networks for Industrial Automation
http://www.spitzerandboyes.com/Product/fbus.htm
The Consumer's Guide to Fieldbus Network Equipment for Process Control
Buy this book and save 50% or more on your next control system!!!
===========================================

 

You might also want to look at this thread: http://www.control.com/thread/1265022867.

That was a Modbus/UDP question that posted within hours of your own. It includes discussion of a code example.

Unlike Modbus/TCP, Modbus/UDP is not covered by a standard. That means there is no standards document which covers how it works and you will need to verify the vendor's implementation. However, here is something which explains it:

http://jamod.sourceforge.net/kbase/modbus_udp.html

I can't of course guaranty that this is how your I/O works.

 

Do you or anyone has any idea if the IO scanning by the schneider Quantum NOE using MOdbus/TCP or some proprietary in this IO SCANNING ?

We have written, a simple TCP server using microcontoller with libraries from MOXA, simplified socket which seems to work well when tested using the MODSCAN test program, however, the connection drops out when we use the NOE to poll.

We setup up a simple function 3 read 1 registers, and confirm that the incoming and outgoing data from MODSCAN and NOE are the same, but the NOE sees to drop the connection after reply! MODSCAN works fine.

Maybe MOSCAN keeps the port open all the time and while NOE close the port after every poll and reconnect again ? Also does not sees correct as the read value does not gets in the PLC memory !

In fact, if we try write from NOE data comes in correctly, but the PLC reports IO scanning is not success.

Any clue on how to resolve this ? Someone commented that maybe there is something proprietary for Schneider IO Scanning.

 

I must admit that I am more than a little confused here. The topic started off as UDP. However, I was under the impression that NOE I/O scanning used Modbus/TCP. I was also under the impression that Modscan supported Modbus/TCP, but not any form of UDP.

If you are working on TCP now, then I would suggest checking the NOE configuration to make sure everything is correct there. Also, don't assume that just because Modscan isn't complaining that the message format is correct. There could be an error, but Modscan might be ignoring it.

 

Dear Dick/Derek,

I would say both TCP and UDP are at the transport layer, above the
underlying IP network layer.

TCP is connection-oriented
UDP is connectionless

Many protocols like FF-HSE make use of UDP for real-time data because it makes more sense to wait for the next update than to retransmit data which is already old. I'm not surprised they are using it for I/O on other protocols too.

Cheers,
Jonas

 

The I/O Scanning function of the Modicon Programmable Controllers will first use Function 23 to attempt to do a Read and Write in the same message. If the device accepts this command and returns a valid response, the request will be completed. If the target device does not understand the function code 23 request and does not respond with a valid error response, the communication will fail. If it does respond with a valid error response then, it will use Function 3 and 14 to process the Read and Write request on the next cycle.

Function Code 03 -- Read Holding Registers
Function Code 16 -- Write Holding Registers
Function Code 23 -- Read / Write Holding Registers

 

Unless things have changed DRASTICALLY at Modicon, I can promise that the NOE does NOT use UDP/IP - this was a long-running religious debate within the company. Last I knew, NOE used a slightly 'trimmed' form of TCP/IP which reduced connection overhead yet caused some issues with other less-full TCP/IP. The religion concluded that such a semi-custom TCP was the bext of both worlds.

I suspect if someone told you that NOE used UDP, what they really meant was that NOE used a fast form of TCP which partially approximates the function of UDP, rapidly open/closing TCP sockets to work like UDP.

(The ideal that TCP uses UDP is completely false - both use IP, but UDP and TCP are separate layers on top of IP).