I had implemented modbus protocol in static energy meters. The protocol is working fine. The tests have been carried out using modbus drivers from wonderware software and RSVIEW from Rockwell Automation. The processor used in energy meter is 89C51 controller.

The problem we are facing with RSVIEW software as follows:

There are white BOX seen on the monitor and the logger logs the error as MODBUS time out once after 5 to 10 minutes. The baud rate used is 9600.Also at the start and end of frame is checked using 3.5 Character times (approx 3.5 msec for 9600 baud rate).

I have found that the meter is sending data to the master but the master is unable to read it correctly. Is there any corruption on RS485 bus or noise problem etc. Please let me know possible solution to solve the above problem.

 

My first guess is that your meter may be responding too fast for some computer drivers. Many Modbus/RTU drivers follow this paradigm to send a request:

1) Check if RTS/CTS support required
2) Send the Request
3) Wait for request to finish shifting out physically
4) Check if RTS/CTS support required
5) Flush receive buffer (in case noise or echo of request was received)
6) Wait for response.

The problem with small devices like yours is that it likely can start responding within 4msec of the end of the request, and the Modbus driver may NOT have been able to complete steps 3, 4, & 5 in that short of time. Since RTS/CTS control is NOT used like this in main-stream IT/Office applications, I think step #3 can happen a few msec AFTER the fact. So if you respond too fast, a few bytes of your response get flushed in step #6 and the driver discards your response with a bad form and CRC.

Another problem with responding too fast as it means the first byte of your response is mixed with reflections from the request. You won't see this on short "lab" RS-485 - it's something one sees in real 1000m+ field systems on less than perfect cable. The fast response during refection noise means the start-bit may be missed & the async char off a few bits. I've especially seen this with devices designed for 4-wire when used as 2-wire. They reply too fast assuming a clean, idle 2nd wire pair and instead hit the dying noise on the single pair used. Delaying a few msec offers a cleaner start-bit condition in the response.

Try adding a user settable delay to response and DEFAULT it to 10 msec. The few users who don't need or want the 10 msec delay can remove it, but better to pick safe defaults that keeps 99% of the customers from complaining about lost messages.

Best Regards
- LynnL, www.digi.com

 

For Modbus RTU and 9600 baud rate, try tuning the maximum time between characters received to 35ms.

If this value is set too small, the complete message may not be received and data from the serial device will be lost. If this value is set too high, the performance will be negatively affected.

The timeout is influenced by the selected baud rate (the slower the baud rate, the larger the timeout). For Modbus ASCII, a value of 1000 ms should be sufficient.

Are your RS-485 lines terminated at the ends? 9600 is slow, but may see disruptions on long cable lengths if unterminated. Also make sure serial parameters are the same on all your devices.

Hope this helps.
-Matt (www.sanpeople.com)

 

Please make sure the reply of the meter does not contain gaps between characters longer than 3.5 characters time (assuming it is MODBUS RTU you are using).

Meir Saggie

 

Dear Sir,

here i am sending response after min 15msec after
receipt of valid query.

I would like to have your comment regarding my
following observation:

I have implemented MODBUS RTU protocol.
baud rate 9600
parity none
stop bit 1
word length 8 bits
CPU used in energy meters is 8051.

Data type is IEEE floating point format.

Suppose i send a request to slave for say
5 floating point parameters then the query sent by master
should be as follows:

0x01 ,0x03,0x00,0x00,0x0A,XX,XX (XX = CRC)

stn No Func code Start Add Length of data CRC

The above query is as per Modicon Modbus
document.
My meter is responding well for above query.

But if i request same number of parameters
through RSVIEW then the query sent by Master
is different i.e only 5 registers.

data length (no of registers requested )

i would like to have your comment on length
of holding registers and size of holding reg
(i.e. whether the holding register will be 16
bit or 8 bit)

regards
yogesh

 

A register in MODBUS is 16 bits by definition. MODBUS does not handle IEEE 32 bit floating point - but if you use it to read 2 consecutive registers (or multiples of), the reading application is (should be) capable to combine each of the 16 bit pairs (registers) into one 32 bit entity and treat it as an IEEE 32 bit number. RSVIEW probably understand registers in the native MODBUS way (as defined, 16 bits). Meir ,

 

You've hit upon one of the most 'gray' areas in Modbus. You can ask for 5 registers, but cannot state the expected size of data type. The Modbus spec has always IMPLIED data is always 16-bit - the function 0x03 is called "Read Holding Registers" and they have always been 16-bit. However the existance of the byte-count in the response lead some suppliers to conclude the master/client can detect after the response what size was actually returned. Reading 5 registers and seeing 20 bytes returned could be used to understand they are 32-bit regs.

Your first master is doing things the traditional way - assuming 5 floating points are stored in 2 concequtive 16-bit holding registers. That is why it polls for 10 registers.

The way your RSView is set up, it is assuming 32-bits will be returned so only asking for only 5. Check the documentation or ask an RSView expert (I've never used it). I am certain there is some way to tell RSView "I'm expecting 5 32-bit floats, you you need to poll them as 10 x 16-bit". I'm sure this is possible as this the way MOST slave devices will expect to answer. An OPC/HMI that cannot handle Modbus floats in 2 x 16-bit registers is pretty stupid & useless.

I'd like to end by saying you did your meter the RIGHT way. Returning 32-bit floats as 2 consequtive 16-bits SHOULD be assumed the default base behavior and will cause you the least customer problems.

Supporting the return of 32-bits regs instead of 16-bit is a vendor extension you may want to add ... but it is still an extension and SHOULD NOT be the default behavior. Users SHOULD (if you do this) be able to enable this mode if so desired as a non-default, non-out-of-box option. This also means instead of having your 5 registers published as 40001, 40003, 40005, 40007, and 40009, they may become 40001-40005. This becomes confusing. But even this is more 'gray' area as some vendors with this extension do it WITHOUT renumbering the registers - reading 2 regs at 40001 returns 40001-40004 as 2x32-bits, reading 2 regs at 40005 returns 40005-40008 as 2x32-bits, etc.

Best regards - LynnL, www.digi.com - plus I'm one of the Modbus.Org board of directors.

P.S. We're still suffering logistic/resource pains to get RFC area open at www.modbus.org, but this issue of 32-bit regs will be one of the things I'll work on getting debated & published. Because of the diverse existing solutions, no 1 answer will satisfy every vendor, but we should be able to select 1 logical solution to recommend for all future/new work. Modbus.org doesn't need to rubber-stamp existing Modbus "rule-bending", but we should help reduce the confusion in such areas. The genie is out of the bottle and use of 32-bit registers will NOT go away no matter how hard some old Modbus folks wish it will ;^)