Which is the best default bit rate?

  • Thread starter Sebastian Seidel
  • Start date
S

Thread Starter

Sebastian Seidel

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
 
You know how it goes, it seems rare that the user looks up the default settings. They just seem to start trying settings, hoping they hit pay dirt.

I have to admit, that if the default settings were not apparent and I couldn't find them, that 115K baud rate would be far down on the list I'd try. I see 19.2K 8-N-1 as the most common serial default settings with 9600 baud coming in 2nd.
 
S

Sebastian Seidel

thanks Dave, that helps a lot.

It still pains me a little, because 19200 baud is really quite antiquated (an 1.8 MHz crystal can do 115200 and with an 7.3 MHz crystal one can go up to 460800) and I fear that users might stick with it and end up with an suboptimal slow bus. But nevertheless, we will propably do as you advise and stick with 19200 8 N 1.

Or maybe we could program a scanner software that will find all devices on the bus.

About the delay issue when writing to EEPROM (device might respond up to one second delayed to master-requests which can lead to bus conflicts). Anybody else had this problem and how did they deal with it?

Best regards, Sebastian
 
S

Sebastian Seidel

David,

I just looked up the baud rate spec in the "Modbus over serial line" document, page 34. It's 19200 8 Even 1. Where is that on your list? Is even/odd parity not much used at all, at any baud rates?

Do you agree that it's better to go with frequency of usage (no parity), and not standard recommendation (even parity)? We only verify CRC16 and do not check for parity, so this bit would be wasted anyway.

Thank you very much for your recommendation.

Best regards, Sebastian
 
L

Lynn August Linse

Partly this depends on the normal use-case.

If your devices are usually installed within a single room with good cable, then 115kbps default is fine.

However, if many users run their cables 300m or more outdoors on possibly questionable cable, then you'll find a lot of users won't find 115kbps 'satisfactory' and may even reject trials of your device because it does not seem to work. They may not be smart enough to understand that if 115kbps doesn't work, 9600 or slower may.

No magic here - for example I once showed up at remote loading jetty (after a day of travel) to discover waiting for me ... 800 meters of armored 18AWG 4-20mA loop cable pretending to be RS-485 cable. The contractor had agreed to use real RS-485 cable, but there we all stood with payments waiting for field acceptance tests. Finally, dropping the baud rate to 4800 baud got the flow meters talking with few errors. I left it with the user - either run at that rate or find a way to force the contractor to import good RS-485 cable from overseas. Would take 3-4 months to get the new cable and no one wanted to delay the project (or payments) for that long.

- LynnL, digi.com
 
Sebastian,

I prefer even parity because it avoids issues with the "10 or 11 character word size" issue when those few Modbus spec compliant masters actually expect no parity to have 2 stop bits. But I don't think I'm typical. Yes, even parity is needed. When there's a problem, the first thing I change to is even parity because an amazing number of slaves cannot do 2 stop bits with no parity, like the Modbus serial standard calls for.

I ran into this recently. The master defaulted to 8-E-1. There was no setting (in the master) for number of word bits or stop bits, the only setting was for parity. 8-N-x was apparently 8-N-2 because the slave at its default 8-N-1 could not connect with the master. When I set master parity to even and slave to 8-E-1, they were both happy and chatted away with each other.

Yes, my Modbus standard reads the same as yours, default to even parity. I know that a wireless base station from a couple weeks ago defaulted to even parity but I'm struggling to recall the one before that that did.

When contemplating the frequency of potential service calls, (I can't get it to connect, nothing happens . . . whine whine whine) going with the market flow (8-N-1) makes more sense to me than rigidly adhering to a spec in the standard that most vendors ignore.

I've seen a couple devices that search out the network at varying combinations of settings, and it's cute, but will the lazy be any more inclined to run that (because it takes some time to execute) than they are to look it up?

I'm old school and expect the manual to tell me what the default settings are or a sticker on the inside of the cover that shows what the DIP or rotary switch settings are, or to display the defaults in the dialogue box of the setup software. We're supposed to be big boys, aren't we, figure it out ourselves? I suspect this qualifies me for old-fogey-dom?

You can't stop the lazy people from not doing anything for themselves, but if your documentation is as good as your post above, then there'll be sufficient information for the competent to make it work. Just tell them what you've told us.

One thing I did not mention is that my work is SCADA over some distance, where high speed is considered 38k. Yeah, I like to run stuff on the bench at 115k, but field wiring and the vagaries of bias, termination and lack of a signal ground in many vendors RS-485 makes lower speeds the norm to compensate for marginal 485 implementations. I'm a big user of isolators.

David
 
S
Reminds me of a case that happened to a friend of mine. They were doing some kind of installation and he, the owner, and the electrical contractor were going over plans, and the contractor mentions he'll need a pull box in the middle of a 400' run of trenched conduit for a 4-20ma cable to one isolated sensor. When asked why, he said he could only get Romex up to 250' in a roll!
 
S

Sebastian Seidel

Dear David, dear Lynn,

thank you for your detailed answers and advice. Our sensors are mostly used with big machinery and infrastructural projects, so we will follow your recommendation and ship with 19200 8 N 1 preset.

Many customers ask about maximum cable-length. Given proper implementation, are 1000 meters with 115200 baud achievable? What is the farthest distance for transmission over RS485 cable without repeaters?

About SCADA: are contractors concerned about security? For example, one single broadcast write to the register which sets the bus-address of our devices would make all our devices inaccessible at once. Do you think it would be advantageous, if users could lock the comm-settings of the device (with, for example, an individual key)?

And last not least there is the dreaded endianess with multi-register-values ambiguity:

For now, we save type information along each value and use this to return everything in BE format. 32 bit values which are saved in our LE microcontroller as hex 01234567 will be returned as hex 76543210. The exception is ASCII which is not swapped at all, so a 64 bit string saved as "Examples" will still read "Examples" if the corresponding registers are read.

However, I like the idea of mapping different byte orderings of the same register value to different register ranges (I read about this suggestion in another forum post), like this:

- 0000-1FFF would contain our pure BE interface like described above. The 32 bit value would read 76543210.

- 2000-3FFF would contain a LE interface because it is so simple. The 32 bit value would read 01234567.

- 4000-5FFF would contain a Modicon 'byte-swap, word-keep' interface.

The value would read 23016745. Should ASCII bytes be swapped, too? If yes, a string like "Examples" would read "xEmalpse".

Do we cover most Modbus byte-orderings with that approach? Which is the most commonly used byte-ordering? How about the ASCII-bytes: is it correct to not swap them with the BE and LE interface, but to swap them with the Modicon PLC interface?

Do you agree, that a little-endian interface is still useful (because it saves much overhead for the master), even if it is not standard? Do others use LE, too?

We also need some 64 bit values (for example time information, which is too big for 32-bit unsigned integers and would lose resolution if converted to 32-bit floats). Do the same rules (no action in LE, complete reversion of all bytes in BE, byte-swap word-keep in Modicon PLC) apply here, too?

Thank you very much for sharing your knowledge and experience.

Best regards, Sebastian
 
>are 1000 meters with 115200 baud achievable?<

The distance depends on the entire network, and most RS-485 networks aren't engineered, they're ad hoc'd. Combinations of devices, device firmware, device 485 implementation, wiring and termination.

Like Steve Myers mentioned, some of the 'contractors' are going to pull Romex for comm cable.

Lammberties says 100k baud at 1200m, then again they've got RS-232 at 20k at 10m, unrealistically
low.
http://www.lammertbies.nl/comm/info/RS-485.html

I pulled this off a Topworx Profibus overview sheet, a table of baud rate vs distance for Profibus DP which runs on RS-485:

93.75Kbps and less - 1200 meters
500Kbps - 400 meters
1.5Mbps - 200 meters
12Mbps - 100 meters

The gotcha is that Profibus DP is an engineered system with engineered components - wire/cable,
terminal blocks, termination resistors, all with little Profibus logos on the gear.

What can your customers buy with an RS-485 logo on it? Nothing. It doesn't exist.

It isn't clear how much of the RS-485 network you're providing, other than a couple screw terminals at your end of the 485 port and the firmware.

I personally think 115k at 1000m is unrealistically optimistic unless you're mandating the contents of the entire network.

>About SCADA: are contractors concerned about security? <

Not in the least. Contractors are concerned about getting in, getting done, getting paid and getting out. They could care less about security. They're the low bidders. Why should they be concerned about the owners' security?

>For example, one single broadcast write to the register which sets the bus-address of our devices would make all our devices inaccessible at once. <

Why would you make the device address be addressable on the network in a write register? Isn't there a physical address setup; rotary switch or DIP switch, keypad setup; or device setup software, or a Windows utility?

>Do you think it would be advantageous, if users could lock the comm-settings of the device (with, for example, an individual key)? <

Sounds costly and if the key is needed for the initial setting, it'll get lost before commissioning is complete (Somebody's Law).

The probability of devices being readdressed in their working lifespan approaches zero, does it not?

I have re-configured devices that others had somehow screwed up, but that was to get the network up and running. Once a network is working, devices stay at the same address until they die. Like Grandma Sikes. She lived her entire adult life and finally died in the house she and her husband bought. Is your stuff different somehow?
 
S

Sebastian Seidel

David,
I think I get the idea. We will ship with a reasonably low bitrate (19200). The user can speed it up. If he wants. With our software. This software needs what? A writing register. So? We see no reason to hide this interface. Impossible anyway. And there might be customers who have the technical background. Unrealistically optimistic you will say.

How is a key costly? It's not more than a couple of bytes to type into our software. I think we can afford that. If they get lost? We read them outta a list? How about that?

And yes, we don't sell grandma sikes, but our sensors (SEIKA) might outlast them for what that's worth.

Sincerely yours, Sebastian

PS: I hope that doesn't come accross wrongly. I appreciate your honest answer and i'm relieved that some of the problems I imagined are not that relevant.

PPS: Should I open another thread on the endianess question?
 
S

Sebastian Seidel

David,

I read your post more carefully.

Maybe the Modbus devices are more like trailer homes than Grandma sikes (even if I'd prefer to think of them as finely tuned sportscars). They get around a little, before they decide on a location and settle down. They need a little flexibility in the beginning (like in the example Lynn mentioned, where he had to down-tune the baudrate to 4800 to make it work) but when they are installed they are expected to stay that way.

Now, how to switch from flexibility in the beginning to a locked setup when everything is in place?

I'd like to have a physical address setting mechanism, but we try to avoid any unccessary moving parts because for one, they tend to fail and secondly we fill our devices with potting to make them more shock-resistant. So that is no option. All settings must be performed over the serial interace.

We will propably work something out. Some day. For now, the user will get what he asks for, be it maximum flexibilty or some special locked settings.

This totally settles the baudrate question. Only about the endianess, I'm still a little unclear, particular about what is used most commonly (new thread on this?).

Best regards,
Sebastian
 
> Big-Little Endian

I mostly work with 32 bit floating point (FP) and I've found the FP world splits about evenly into big/little endian. About half the time I have to go into that setting in Kepware that swaps the format and then the data looks OK.

Off the top of my head, I don't know what the bit/byte read order is for a 32 bit integer, or a 64 bit integer for that matter. Every time I've needed to read a long 32 bit integer, it read right, as is, by the master, with no order swap needed, so I haven't researched it.

Modbus does not define formats, formats are conventions, which sometimes get inverted like little/big endian. I don't know how it could hurt, but I'm not sure how much confusion there is about 32 or 64 bit integers.

The value of a slave providing multiple formats that I've seen is when the same data is available as an integer or as floating point. Conversion from one format to another can be a challenge.

You might consider providing floats even though it's less resolved than a long integer, unless you know your target customers can handle the long formats.

Should ASCII be swapped? I'd use whichever endian format any terminal program uses for ASCII and leave it at that.

I think you should start another thread on endianess; I'd be interested in what others chime in with on your multi-format proposal.

Functions 20 and 21 (14h/15h)
To my knowledge, I've run into these functions only once. A major brand of single loop PID controllers uses functions 20 and 21 for file up and downloads from the controller to their proprietary configuration Windows app. For reasons beyond my ken, the controller's operating manual lists registers for function 20 and 21, not for function codes 3/4 and 10h/17h.

It drove me nuts when I attempted to poll register xxxx with function 03 to find that the contents bore no resemblance to the data expected. It took about 5 transfers through tech support people before someone realized that the manual references were for functions 20/21. A separate Modbus manual has the correct register/address tables, but how and why the 20/21 registers got into the regular operating manual is a mystery.

If anyone has developed a file system for function codes 20 and 21 I'm unaware of it. You might start another thread with that as the subject because the topic is somewhat buried in the rest of this discussion.
 
S

Sebastian Seidel

Thank you, David. That gives us a good direction.

I'll take another look at the register map. Maybe I can include a float in redundancy to the 64 bit long integer.

For now, we support 3/4 and 10 hex and in a future release we'll look into 17 hex, too.

We have not yet implemented function 06 hex (write single register). When we started out, it seemed that this would be a bad idea because users might write multi-register values one register after the other which would ultimately fail on values which are checked for plausibility (the write is ignored if they fail this check). Now, it turns out that all write-registers are 16-bit, so we might as well support it.

At the moment there is no need for functions 20 and 21 hex and we are glad that nobody else uses them much either. One might possibly be able to do interesting things with them (filesystem, serving huge data sets, supporting multiple different register maps in one slave device) but this would require some convention between implementers.

During the next days, I'll read up a little on endianess and open a new thread to get some clarity about which course of supporting different endianesses would be preferable.

Many thanks to you and the others who have replied to my question. Hope to hear from you again in the other thread.

Best regards, Sebastian
 
Top