Can I say my device is MODBUS-RTU compaible when.....

D

Thread Starter

Detlev Neumann

Could I say that with the following facts my device is MODUS-RTU compatible?

MODBUS-RTU
2-wire RS485
Baud 9600, 19200
8-E-1 (I can change the Parity)
Implemented functions code
FC_READ_HOLDING_REGISTERS 0x03
FC_READ_INPUT_REGISTERS 0x04
FC_PRESET_SINGLE_REGISTER 0x06
FC_PRESET_MULTIPLE_REGISTERS 0x10
Visual Diagnosis No
 
L

Lynn August Linse

Looks good to me, and the 'no parity' option *IS* important as some Modbus devices don't support 'even' parity (the modbus.org standard came decades too late for some products :-] )

I'd also suggest a read of first holding register work (so 4x00001), as some SCADA devices will fail-over do a 0x03 func read of first holding register as a kind of 'ping'. Yah, that's not in the standard, but I've of products which 'start' at say 100 having problems with such SCADA usage.

(OPC vendors will also complain is you have gaps in your register maps, so if registers 1-8 exist, but 9-12 don't exist and then 13-20 exist. So reading 1 to 20 'fails'. Again, something not really locked down in the standard, but critical to customer happiness.)
 
S
Agreed. Other than noting that you should be as flexible as possible on serial parameters (and definitely support N-8-1), you seem to be supporting about as much as many slave devices do. The most critical FC's (depending on what your device does, of course) are 3 and 16 (0x10).
 
J

JulieInAustin

> (OPC vendors will also complain is you have gaps in your register maps, so if registers 1-8 exist, but 9-12 don't
> exist and then 13-20 exist. So reading 1 to 20 'fails'. Again, something not
> really locked down in the standard, but critical to customer happiness.)

There are a lot of devices with rather large gaps in the register map. Any application that ignores the map, and just blindly reads, is broken.

For example, the revenue grade meters I work with often have very large gaps between floating point values and integer values. It makes the map much cleaner. For example, address 1000 through 1100 might be UINT32 values, then 2000 through 2100 might be 32-bit IEEE floats. One very nice thing about that as a design is that if more values are needed (say, 3-phase versus split single phase -- "2 phase" to some people), the 3rd set of values can be added on at the end of each block, rather than having to slide everything down.
 
S
Different situation. Registers that far apart would never be (in fact COULD never be) read in a single transaction.
 
P

Peter Nachtwey

You forgot the timing. I find that many so called Modbus-RTU devices do not adhere to the timing specifications. I am referring to the time between characters that determine when a packet is ended.

Most PC devices are not capable of measuring the time between characters when the bit rate is high. Serial chips that buffer only 16 characters need to have the buffer refilled quickly to keep the flow of characters constant. Windows often fails to do this when someone is moving a mouse or window around.
 
L

Lynn August Linse

>You forgot the timing ...

Although probably yet another context, most radio modems today do packet forwarding & retry, so reading a 255 byte response might return with 30 to 100msec gaps within the packet. So a device should have some ability to expect longer gaps. Many people try to default their product to the Modbus spec (the 3.5 char time), but you should try to allow setting longer gaps for use with wireless and wide-area-network. Certainly, "demanding" exactly and only the Modbus serial spec of 3.5 char times will cause problems in the market.

We had one customer using satellite. Reads worked fine as the remote RTU saw a single small 8-byte request, and the PC tool could handle the 2 to 5-minute 'gap', but they could never write full blocks to the RTU since it could not handle the unnaturally long gaps (of several minutes).
 
But t1.5 is much more critical. If I'm not mistaken, you have to ignore the inter-character timeout completly?! (receive mode)
 
Top