S
Dear Sirs,
Our Modbus RTU (over half duplex RS485) slave device (inclination sensor) supports most bit rates from 300 up to 230400 bits/s. The user can set any bit rate, parity, stopbits and times by changing the corresponding registers.
We have implemented only functions 3 (read multiple holding registers), 4 (read multiple input registers) and 16 (write multiple holding registers). Functions 3 and 4 do the same because we do not discriminate between input and holding registers. Would that be acceptable?
Max 123 registers can be written in one go (with one Modbus command) and max 125 registers can be read in on go. Are these limitations still obligatory? Sometimes, it would be useful, if more registers could be read together but then again longer messages might also result in a higher chance of communication failures.
Before shipping the device we have to decide about the default (preset) communication settings. How about the following:
- 115200 baud since that is the fastest bitrate which did work with a variety of PC systems. (Interestingly, by using an USB to RS232 adapter we got up to 230400 bits/s, by using the original RS232 port only up to 115200 bits/s). Other candidates would be 9600 (quite slow) and 19200 (Modbus standard?).
- Even parity
- 1 stopbit
- t_3.5 = minimum silence that precedes (marks the begin of) any master request = 20 ms. Too long? The Modbus specification mentions 1750 microseconds (with 115200 bits/s) but then again, the master would have to send out its request very fluid without gaps longer than that or the request will be cut off.
- t_response = minimum delay from when our device has received the last byte of the masters request until it sends the reply so the master (PC) has enough time to switch from send to receive mode = 30 ms. Too short?
Unfortunately, writing EEPROM registers takes much longer than any other operation (7 ms per one register, nearly one second per 123 registers) and the device will only answer after the write has been performed completely. Thus, it might answer with a delay of one second!
I have a bad feeling about this, but it seems hard to do right (replying with a code 06 "slave device busy error" to requests), because it would require implementing a kind of multitasking system on an 8-bit microcontroller (ATmega1284p). Did anybody experience a similar problem? Did it lead to further problems?
Your opinions would be much appreciated.
And just out of curiosity: Did anybody yet implement a filesystem or a unified way to specify register contents for Modbus? I noticed there are file-records (functions 20 and 21), but these seem more like a two-dimensional register matrix than a file system (no named entities).
Best regards,
Sebastian Seidel
Our Modbus RTU (over half duplex RS485) slave device (inclination sensor) supports most bit rates from 300 up to 230400 bits/s. The user can set any bit rate, parity, stopbits and times by changing the corresponding registers.
We have implemented only functions 3 (read multiple holding registers), 4 (read multiple input registers) and 16 (write multiple holding registers). Functions 3 and 4 do the same because we do not discriminate between input and holding registers. Would that be acceptable?
Max 123 registers can be written in one go (with one Modbus command) and max 125 registers can be read in on go. Are these limitations still obligatory? Sometimes, it would be useful, if more registers could be read together but then again longer messages might also result in a higher chance of communication failures.
Before shipping the device we have to decide about the default (preset) communication settings. How about the following:
- 115200 baud since that is the fastest bitrate which did work with a variety of PC systems. (Interestingly, by using an USB to RS232 adapter we got up to 230400 bits/s, by using the original RS232 port only up to 115200 bits/s). Other candidates would be 9600 (quite slow) and 19200 (Modbus standard?).
- Even parity
- 1 stopbit
- t_3.5 = minimum silence that precedes (marks the begin of) any master request = 20 ms. Too long? The Modbus specification mentions 1750 microseconds (with 115200 bits/s) but then again, the master would have to send out its request very fluid without gaps longer than that or the request will be cut off.
- t_response = minimum delay from when our device has received the last byte of the masters request until it sends the reply so the master (PC) has enough time to switch from send to receive mode = 30 ms. Too short?
Unfortunately, writing EEPROM registers takes much longer than any other operation (7 ms per one register, nearly one second per 123 registers) and the device will only answer after the write has been performed completely. Thus, it might answer with a delay of one second!
I have a bad feeling about this, but it seems hard to do right (replying with a code 06 "slave device busy error" to requests), because it would require implementing a kind of multitasking system on an 8-bit microcontroller (ATmega1284p). Did anybody experience a similar problem? Did it lead to further problems?
Your opinions would be much appreciated.
And just out of curiosity: Did anybody yet implement a filesystem or a unified way to specify register contents for Modbus? I noticed there are file-records (functions 20 and 21), but these seem more like a two-dimensional register matrix than a file system (no named entities).
Best regards,
Sebastian Seidel