We built a modbus client on a Win98 PC. In a test routine, we polled our device as fast as possible.

So we learned, the response of one of our device e.g. modbus server is delayed about 10...20ms. (10Mbaud)(We started a clock at request and stopped the clock at receive).

If we install more than one requesting object (n times) in the PCs application to request n different devices, how can we calculated and test, if the cycle time is n times 20ms or how "parellel" are the n request works ?

If we guess, the request is a small ethernet frame with the smallest amount of data, it is about 46+26 bytes.

So at 10Mbaud, it needs min. 60µs to send this frame.

So the PC should be able so send a lot of parallel requests in a very short time.

So all answers of the requested servers can reach the client in 20ms+n*60µs, if we have a separated network without other communication.

So, in summary, are these ideas the right way or is there any mistake ?

C needs only

 

Hello,

PLC answer to network requests at the end of the PLC scan. For me the 20ms you spoke about are in fact the time to execute PLC application.

Time to send a request by a PC is negligible in front of PLC scan time.

To enhance communication (Point to Point) on modbus with more than 1 request you have to open more than 1 IP connection with a remote device.

Hope it helps and answer to your question

Best regards
Jérôme

 

Jérôme:
> PLC answer to network requests at the end of the PLC scan. For me the
> 20ms you spoke about are in fact the time to execute PLC application.

> Time to send a request by a PC is negligible in front of PLC scan
> time.

If that's so, then it should be completely parallelisable: send a request to each of the n devices, and 10-20ms later you'll have the
responses from all of them.

previous poster:
> > So we learned, the response of one of our device e.g. modbus server
> > is delayed about 10...20ms. (10Mbaud)(We started a clock at request
> > and stopped the clock at receive).

> > If we install more than one requesting object (n times) in the PCs
> > application to request n different devices, how can we calculated
> > and test, if the cycle time is n times 20ms or how "parellel" are
> > the n request works ?


Jiri
--
Jiri Baum <[email protected]> http://www.csse.monash.edu.au/~jirib
MAT LinuxPLC project --- http://mat.sf.net --- Machine Automation Tools

 

> > We built a modbus client on a Win98 PC. In a test routine, we polled
> > our device as fast as possible.
> >
> > ....
> >
> > So the PC should be able so send a lot of parallel requests in a very
> > short time.
> >
> > So all answers of the requested servers can reach the client in
> > 20ms+n*60=B5s, if we have a separated network without other
> > communication.

A couple of thoughts:

1) Keep in mind that some remote MB/TCP servers will support only a limited number of sockets (or IP connections) in parallel. This may be as low as 4 or even 1, although 8-12 seems to be the most common limit for small devices. So make sure you allow some way to limit how many parallel
requests you send at once per IP if you want to support a wide number of remote servers.

2) Unless you have modern FULL-DUPLEX Ethernet switches through-out, you may be in for some rude shocks when your responses start colliding with
your requests on half-duplex UTP links and occasionally you'll get into TCP's retry back off of 250/500/1000 ms etc.

3) For people doing Modbus/TCP, take a look at the less commonly used 0x17 Read/Write Multiple registers which allows reading and writing in one poll cycle. For small devices with both input and output using this (if supported) could have a big impact in performance.

Best Regards

Lynn August Linse, alist (at) linse (dot) org
IA Firmware Specialist, Digi Int'l (www.digi.com)
26741 Portola Pkwy, Suite 1E #242
Foothill Ranch CA 92610-1743 USA
Ph/Fx: 949-916-1524 (voice message usually)

 

A) There is one other issue with Modbus/TCP. TCP/IP delays sending of small amounts of data for performance reasons. This is done using the
Nagle algorithm. In typical network applications where packets are sized 1K and higher it improves network performance.

However with MODBUS/TCP which sends small amounts of data typically from 10 to 200 bytes, it will add additional delay .

"... However, for some applications this algorithm can impede performance, and TCP_NODELAY can be used to turn it off. These are
applications where many small messages are sent, and the time delays between the messages are maintained. Application writers should not set TCP_NODELAY unless the impact of doing so is well-understood and desired because setting TCP_NODELAY can have a significant negative
impact on network and application performance. ..."

The MODBUS/TCP stack you are using should switch off the Nagle algorithm when opening the TCP socket.

B) You are using Windows 98 which is certainly not a high performance machine in regards to networking and scheduling network traffic. Use
a network benchmark tool to measure the network performance of your configuration. It might help using a different operating system (NT, W2K)
Have a look at "http://www.pcausa.com/Utilities/pcattcp.htm":http://www.pcausa.com/Utilities/pcattcp.htm

C) You are at the moment assuming that the Server is the bottle-neck. This has to be proven first. Parallelling requests makes only sense if you are currently underutilising the practical network bandwith of your Client and your Server is able to perform multiple requests at the same time and handle multiple TCP connections.

Most MODBUS/TCP Servers are designed single threaded and allow only serving one request at any time.

D) You need full-duplex Ethernet ports on Server and Client side and a high performance switch if you want to guarantee transmission times on Ethernet and avoid collisions.

As you can see the issue is complex and depends very much on your overall configuration. The only practical way to find out is by doing tests.

With kind regards,

Henrik W Maier
FOCUS Software Engineering
Brisbane, Australia
http://www.focus-sw.com

 

yeah.. it is very important for us to know, how fast the devices that we use to respond the request that we send via Modbus TCP protocol.
Especially for data that are important such as the alarm data from a coil registers, then the speed of the respond should be a very important consideration for us to determine the amount of the value of the polling interval will we set.

So.. you can try my software tool '<b>Modbus Speed Test</b>', this is easily and accurately to know about how fast this device in respond the request that we send via Modbus TCP protocol. We can test the speed of respond when we requested the data Coil, the data of holding registers 16-bit and data from holding registers 32-bit.

Actually, many factors affect the speed of respond of the equipment, one of which is as many applications Modbus Master who make requests to the device, the speed of the processor of the devices we use are less responsive, or maybe a network cable and hub are used poorly.

So, to know about the speed of respond from your modbus device, you can download my program for free, here -> https://dl.dropboxusercontent.com/u/3351822/MbSpeedTest.rar

Thanks..