Modbus communication


Thread Starter

J-F Portala

Dear listers:
I want to communicate between PLC and PC with Modbus Protocol. I use C++ and ReadFile and WriteFile functions to manage the serial port.
I am not sure NT is capable to manage modbus communication as a slave. The end frame detection needs for the PC to detect a blank of 3,5 characters. There is a structure CommTimeOut which permits to set timeouts when reading or writing. The first tests I have done show me the following
- the timeouts are set with 1 ms accuracy but I have to adjust them to 5 or 10ms instead of 3 or 4 ms (at 9600)
- when I write a frame,I don't know when I have to set the line low(with EscapeComm functions)
I use a sleep of 1ms after WriteFile function.
- the thread I use is in TimeCritical priority, but I can loose frames when if the CPU is utilized by another process.

Is it possible to write a reliable Modbus slave comunication with NT?
Are the readFile and writeFile functions sufficient, or do I need to write a driver with DDK?
Thank you
J-F Portala
SoViLor company

R A Peterson

Personally, I'd be inclined to ignore the 3.5 character spec. Its a PITA when using modems and anything else that tends to break things into packets. Set it to look for a fixed time inetrval between characters instead. That ought to work fine.
You are reading the spec too literally.

No serious master or slave device would use a true 3.5 char time-out, as it would mean 99% of the OTHER Modbus devices in the world could not talk to you reliably. To SEND such tight timing requires the sender (such as a PC) has to place a higher priority on serial transmit interrupts than on network and most other interrupts. No one does this. So most of the "real" Modbus devices in the world will accidently introduce "pauses" in the message of longer than 3.5 charecters. Yes, this VIOLATES the standard, but that's
reality & you are just creating many problems for yourself if you enforce this 3.5 char timeout in a slave or master.

Instead, use a user defined timeout of from 10 to 250msec for this. Then create a simple routine to parse the message as it arrives - after seeing 2,
3 or 6 bytes you can ALWAYS calcuate how big the incoming Modbus message WILL BE based on the function code & related data. Then you don't even need to worry about the time-out.

If you expect the message to be 8 chars and the CRC is zero after you receive 8 bytes, then the message is finished and no time-out is required.

If after 8 bytes the CRC is NOT 0, then I assume the message in non-standard and just wait for the longer timeout to verify the message is REALLY done.

Best Regards

Lynn August Linse, Senior Product Application Engineer
15353 Barranca Parkway, Lantronix Inc, Irvine CA 92618
[email protected]
Tel: (949)450-7272 Fax: (949)453-7132
We have a modbus slave interface for our product. I took a quick look at it and it uses the comm timeout. You just need to calculate this value based on the baudrate and the number of bits per byte.

We have previously developed and deployed a working Modbus slave interface for Windows NT using the standard ReadFile() and WriteFile() API calls. To properly detect the end of frame set up the intercharacter timeout in the CommTimeout structure. The timeout value can be calculated based on the configured baud rate for the link (3.5 character times), as follows:

double dblBitsPerByte = 1 + m_byDataBits + m_byStopBits + ( m_byParity ? 1 :
0 );
timeouts.ReadIntervalTimeout = (DWORD) ceil((3.5f * dblBitsPerByte /
(double)m_nBaud * 1000.0f)) ;
timeouts.ReadTotalTimeoutMultiplier = 0;
timeouts.ReadTotalTimeoutConstant = 0;
timeouts.WriteTotalTimeoutMultiplier = 0;
timeouts.WriteTotalTimeoutConstant = 0;


Gord Ellis, P. Eng.
Northern Dynamic Inc.
J103-155 Frobisher Drive
Waterloo, Ontario
Canada N2V 2E1
Tel/Fax: (519) 725-2071/2072
It usually doesn't matter that you accurately time Modbus RTU protocol. You can write your slave to timeout at 100 msec or even 1 sec if you want. It will still work with every Modbus master
I have encountered. The purpose, I believe, of the 3.5 char message timeout is to allow full duplex communication between the master and slave. The timeout gives the slave a way to re-frame after a bad message. But I have not seen any master program that tries to run Modbus in full duplex mode. They are all written to send one command, wait for a reponse, then send the next command, and so on.

Jay Kirsch
Macro Automatics
2985 E. Hillcrest Drive, Ste 101
Thousand Oaks, CA 91362
[email protected]

Gianni Franchi

I used to work with WindowsNT & serial communication and I think that what are you doing is impossible, or maybe you can try and obtain a worst result. In the past i realized some communication protocol with Siemens and other
device, but a PC (specially Windows NT) is not able to do so, cause the timing of serial communication of modbus must be very accurate.
The best thing (i think the only way) to do is to buy a PC ISA/PCI board for modbus communication.
This is true of Modbus RTU where the response time must be something like 1.5 characters, but Modbus ASCII has no such requirement. There are plenty of Modbus drivers around which work with windows (95/98 at least) and several that can work with Linux.

Have alook at the LinuxPLC links page for references,
This won't help answer whats going on when trying to do the comms directly, but this organization writes comm software libraries for a wide variety of products, and undoubtedly have a comm library to tie C (VB, etc.) and Modbus together.

Hanoi Santos Hung

J-F Portala :
I normaly use WindowsNT to comunicate with all kinds of PLCs and I use to call WriteFile with
the full string. I mean without using sleep().
The real problem is receiving and processing the data in time, then you can use
WaitCommEvent(CommHandle,EV_RXCHAR,NULL) and decode the modbus frame.

Anyway Wintech ( have a implementation of an Modbus OCX slave,I tested
this software under WinNT and works well, but is a little expensive ($549)

Ing Hanoi Santos Hung
Dpto Sistemas Digitales 3
Instituto Central de Investigacion Digital
FAX : (537) 336387
Phone : (537) 218769 ext 43
email : [email protected]

Darold Woodward

As someone who recently helped do extensive testing on a new Modbus slave device, I would beg to differ with the casualness that the 3.5 character delay has been approached. There are some important things to consider. We found
several Modbus masters (not PCs) that were not tollerent of improper handling of the 3.5 character delay and one that even had a setting that allowed it to be used or ignored. For example, if the slave had the data ready at a slow baud rate, it would often answer the master before the 3.5 characters had elapsed. Some masters ignored the response and others could handle it.

There are some important things to consider about the 3.5 char delay:

1. Make sure that you never send a new poll after less than 3.5 characters has elapsed from the end of the last slave device's response. You won't even see 3.5 characters at 9600 bps and beyond, but if you have the ability to run slower
and someone does it, you can get into a situation where the slaves ignore you.

2. For incoming messages, you can probably get by with the expected number of bytes based on the FC, but we intenionally sent corrupted messages around the network also. Unexpected things can happen if you expect the message bytes to always be correct. You need to consider the validity of the CRC in your incoming message strategy as well as the message type.

Good luck and do lots of testing before you start using this thing.

Darold Woodward PE
SEL Inc.
[email protected]

Jeff P. LeBlanc

I have two programs which act as slaves running under NT. The first is written in C the second in VB. I think what you want to do is possible

>You are reading the spec too literally.
>No serious master or slave device would use a true 3.5 char time-out, as it
>would mean 99% of the OTHER Modbus devices in the world could not talk
>to you reliably.

I second that. In all my years of Modbus experience I have only *once* encountered a device which upheld the 3.5 char time-out. And this supplier even claimed to have been officially certified (who does that?).

>To SEND such tight timing requires the sender (such as a PC)
>has to place a higher priority on serial transmit interrupts than on
>network and most other interrupts. No one does this.

There is one simple solution to implement this on a PC, but only when the 2nd (other) COM-port is not used. Program it to the double bitrate of
the Modbus-network, and start the transmission of 7 characters. When a character is received from the Modbus-network, reset the 2nd COM-port, and start it again with 7 characters. In case this serial port finishes, you have your 3.5 character timeout. In case the double bitrate is not
supported, you can use the trick with the same bitrate, but then you can only have a 4-character timeout (or perhaps slightly less if you don't use
a parity-bit and 7-bit characters).

>So most of the "real" Modbus
>devices in the world will accidently introduce "pauses" in the message of
>longer than 3.5 charecters. Yes, this VIOLATES the standard, but that's
>reality & you are just creating many problems for yourself if you enforce
>this 3.5 char timeout in a slave or master.

Right, especially when on a 4-wire network this is already actual behaviour.

Rob Hulsebos
Does the PC really observe the timeout as calculated, or does it round-up the timeout to the nearest *possible* timeout value? In such cases the result may be something else than expected.
Just curious,

Rob Hulsebos
Hi List:

The discussion on the 3.5 character delay at the end of message for Modbus RTU has been interesting to say the least.

Yet, I don't think anyone has pointed out the reason the delay exists in the first place.

****The delay allows the end of packet to be identified in all cases.****

In particular, in a noisy environment where characters are often lost and using a purely binary protocol without transparency, a lost character can cause a receiver to become hopelessly forever lost. With no chance of

If the receiver reads for a specific number of characters and looses one or more in a packet, the first characters from the next will be interpreted as part of the first. At this point, the interpretation of the binary data stream becomes a statistical nightmare as to when, if ever, the receiver will find the right combination of characters to get realigned.

The 3.5 character timeout ensure the packet framing in error conditions. If a character is lost in a packet, the gap at the end of the packet will ensure the receiver detects the damaged packet and is aligned properly on the next packet start.

Our company has thousands of Modbus RTU interfaces installed. We offer the user the option of enforcing the timing in the case that all of the devices are properly constructed -- giving the user a much higher degree of
reliability in noisy conditions.

We also allow the user to relax the timing. A very large part of devices that have been implemented do *NOT* properly behave (just read the opinions of the posts on this topic so far!). In order to communicate with them, the
user must relax the timing -- and give up reliability in a noisy environment.

Interestingly, most high speed smart modems use their own compression/packetization algorithm between the modems, and the modems will buffer up
several characters before transmitting them to the other modem which then sends them at full speed to the receiver (after a long gap while the data was being buffered.) Thus, if high speed modems are the timings *must* be relaxed in order for the Modbus RTU protocol to work at all. (Another reason for making the timings optional for the user and the application at hand.)

By the way, no mention was made of the maximum intercharacter timing requirements of Modbus RTU -- which are required to prevent false end of
packet detection. Often times PCs have trouble reliably sending characters with the proper inter character gap! It seems the PC gets busy doing things other than answering serial interrupts and a (false end of packet) gap occurs. Again, making the timing optional for the user is helpful.

Oh, one last related topic -- Modbus RTU over TCP/IP (often over Ethernet) drops all timing requirements, since no predictions at all are possible about the general case for TCP/IP delivery of the bytes in the message. What is guaranteed by TCP/IP, is that all the characters will be delivered and delivered in order. Thus, if all is working, the will be no missing
characters to cause the receiver to get lost in the first place!

If something does go wrong, the TCP/IP link can be reset or closed and opened again and the communications path restarted and resynchronized,
something that can be done with serial communications only by resetting or power cycling the two ends of the Modbus RTU link.

Of course many devices and links that ignore the timing and work without errors being detected for years -- the quality and sensitivity of the
transmitters/ receivers is remarkably higher today than just a few years ago. Today, many plants will go years without a single character being lost. Back then, many high speed (2400 baud back then!) links suffered lost/corrupted characters every few days, even in a near laboratory environment. Ignoring error detection and recovery was a certain path to unemployment; today's technology is a lot more forgiving.

Finally, I'll stop this marathon post with the admonition to judge all protocols by their behavior in error detection and recovery, in addition to their behavior in *normal* conditions.

Cheers! Steve

<My opinions and not necessarily those of my Employer>
Steven B. Cliff title: VP, Research & Development
Control Technology, Inc. email: [email protected]
5734 Middlebrook Pike web:
PO Box 59003 voice: (423/865) 584-0440
Knoxville, TN 37950 fax: (423/865) 584-5720

Srinivas Iyer

I saw your posting related to PC-PLC communication. I am trying to work out a similar application where i have a DCS querying my PC for data. The PC had two s/w's that run continuously. One of them generates data and puts in into a file. The other s/w checks the file for the latest data and holds that data in an array for passing it to the DCS. The DCS is querying the PC over the serial port using the MODBUS protocol. I have tried using the available OPC servers to simulate the DCS querying my PC, but so far have had no luck in interpreting the query from the DCS. Have you tried the same? I am assuming that in your case you must have had the PLC querying the PC.
Any info would be greatly appreciated
Hi Jeff,
Saw your posting relating to the C programs for MODBUS slaves. Do you have the source code? If you have developed it yourself, is it shareware? Let me know