Two Stop bits/ No Parity??? Modbus RTU/ASCII

J

Thread Starter

Jason Riegert

What does the Modbus Specification define as the correct number of STOP bits when NO parity is selected?

If there is an excerpt of specification document that supports the correct answer that would be of additional help.
 
The specification states that when using "no parity" that you use 2 stop bits. This is essentially the same as using 1 stop bit with "mark parity". One possible reason for keeping 11 bits per byte is to maintain constant timing parameters throughout the specification. I offer the user the ability to select None, Odd, Even, Mark/1, Space/0 parity with either 1 or 2 stop bits. I inform the user that the strict modbus specification is really mark-parity.
 
2 stop bits if no parity

Taken from page 6-7 in Modicon Modbus Protocol Reference Guide PI-MBUS-300 Rev. J
 
>From PI-MBUS-300 REV J:

"The format for each byte in RTU mode is:
Coding System: 8–bit binary, hexadecimal 0–9, A–F
Two hexadecimal characters contained in
8–bit field of the message
Bits per Byte: 1 start bit
8 data bits, least significant bit sent first
1 bit for even/odd parity; no bit for no parity
1 stop bit if parity is used; 2 bits if no parity
Error Check Field: Cyclical Redundancy Check (CRC)"

"The format for each byte in ASCII mode is:
Coding System: Hexadecimal, ASCII characters 0–9, A–F
One hexadecimal character contained in each
ASCII character of the message
Bits per Byte: 1 start bit
7 data bits, least significant bit sent first
1 bit for even/odd parity; no bit for no parity
1 stop bit if parity is used; 2 bits if no parity
Error Check Field: Longitudinal Redundancy Check (LRC)"
 
D

Dave Goldsmith

>2 stop bits if no parity
>
>Taken from page 6-7 in Modicon Modbus Protocol Reference
>Guide PI-MBUS-300 Rev. J

I know this is an old thread, but hopefully no-one minds me asking here as it seems very related. I have been greatly struggling to use a Raspberry Pi to communicate with some modbus energy meters.

Does anyone know if the start bit should be high or low, and also if the stop bit should be high or low?

The manual for my energy meter says that by default the meter does not use the parity bit, and only one stop bit (so 10 bit characters). It also defaults with Address 001 and baud rate 2400.

I'm using Python - WiringPi to Tx and the python time package for baud rate control. I setup a loop to alternate high low on my Tx pin and used a Fluke to check the frequency, and then adjust the sleep time until I got within 1Hz of 2400.

Occasionally the first bit I get back from the meter is 0, but the rest are all ones, and I usually get back all 1s.

I doubt the energy meter is effected by the enable pin on the MAX485, other than possibly seeing it as a bit change, but I've also been trying different timings on switching my MAX485 driver enable / receive enable, with no luck.

Any ideas would be really appreciated. Thanks.
 
8 bits/word, no parity and 1 stop bit is the default config for serial comms. 2400 baud is really quite slow and it suggests they are planning to run it over a great cable length.

In standard RS232/422/485 serial comms (also called NRZ encoding) you have a start bit which is a 1, then you have the data bits INVERTED and sent out LSB first, then the stop bit is a 0.

The above is what actually comes out on RS232, so the start bit is a positive voltage, say +10V, and the stop bit is say -10V.

On RS422/485 you have two wires (plus the ground of course) and the 1 or 0 is according to which way round you have connected them :)

If you are using a microcontroller with a UART then this is all taken care of for you. You just place the bytes into the UART's transmit queue and it will shift out the start bit, the data bits and the stop bit.

Then if you want RS232 you connect the UART's TX output to say a MAX232A or a DS14C88 and these interface chips perform an inversion so the RS232 data comes out as I describe above (start bit is +10V or so).

If you want RS422/485 then you use e.g. a MAX489 and you are done.
 
>8 bits/word, no parity and 1 stop bit is the default config for serial comms.

I suspect that the site Moderators would post any Modbus specification updates or changes, so I just checked and the "MODBUS over Serial Line Specification and Implementation Guide V1.02", dated 2006, still has the requirement for 2 stop bits for no parity on page 12.
http://modbus.org/docs/Modbus_over_serial_line_V1_02.pdf

It continues the requirement from the Modicon Modbus Protocol Reference Guide PI-MBUS-300, Rev J, dated 1996; so it's not a new requirement. Note that the thread on this started in 2006.

I agree that in the serial world 9600 8-N-1 is very popular as a default serial setting. That same Modbus spec states that both 9600 and 19.2K Kbps are required baud rates, with 19.2K being the default baud rate (page 20).

Yet one encounters Modbus masters that simply can not handle 2 stop bits; they have no setting for 2 stop bits and they just can't do it.

No parity/2 stop bits is one of those facets of the standard that should probably be revised, given the trend to 8-N-1 over the past decades. But it would probably take a Modbus Organization corporate member to initiate some action through the technical committee. And, is it worth the effort? I don't think it's worth fussing over when those masters that would not do 2 stop bits easily handled Even or No parity with 1 stop bit.
 
If you send 2 stop bits to a UART configured for 1 stop bit, it will work fine.

If you send 1 stop bit to a UART configured for 2 stop bits, the result depends on the UART. In years past I have seen some which don't actually implement checking for any stop bits after the first, and this makes sense.

Similarly 9600 baud is by far most widely used on Modbus.

The one aspect of Modbus which is relatively important is the intermessage gap of 3.5 character periods. This is needed to easily detect the end of a packet. Obviously such a gap must not appear accidentally within a packet :), and that is why we have the Modbus over TCP stuff which aims to send each Modbus packet without a break.

The 2400 baud mentioned is fairly common for very low power remotely located instrumentation. A lot of this stuff has bit-banged UARTs implemented with low power micros.
 
Top