I assume the calculation of silent interval in 9600 bps is as below.
1 / 9600(bps) * 11(bits) * 3.5(ct) = 4.01 [ms]
A certain manufacturer's slave device calculates as below because Modbus-RTU is binary.
1 / 9600(bps) * 4(bits) * 3.5(ct) = 1.46 [ms]
The both seem to be reasonable, but I would like to know which is correct calculation.
Your first calculation is correct, 4.01 msec.
But beware that there are some implementations that may not do their timing so precisely! If you are implementing a new Modbus driver, then you should consider making this time "adjustable".
In the end, if your device strictly adheres to 4.01 msec and my device does as well, then there will certainly be synchronization problems because your clock and mine are not synchronized exactly. My recommendation is to have default timing values calculated as you have shown them but also be able to override them.
Jerry speaks from experience :)
What you'll find is suppose your customer uses a cheap 'packet radio' to bridge your 9600 baud signal across a 25 mile gap, then you could find gaps of from 50 to 500msec between every 32 or 50 bytes, and if satellite is used these gaps can be 5 minutes or more!
Sure it violates the Modbus/RTU spec, but if you cannot handle these gaps, then your product cannot be used by the customer; you don't make the sale. Not sure about you, but my wife certainly likes me get paid every 2 weeks.
Remember that by watching the bytes arrive you can estimate the expected size of the message. For example, a Modbus/RTU function code 3 request will always be 8 bytes. The response will allows be 5 bytes plus the byte count in third byte.
You really only need this idle-gap for unknown function codes.
I made an excel sheet where one can calculate line time on a Modbus network, so if anyone is interested drop me an email and IŽll send it to you.
>... and if satellite is used these gaps can be 5 minutes or more!
Whoops. I just read this and since we are about to release our device soonishly we might still have the chance to change our register layout.
The problem is this: We have this time adjustable in a 16-bit register, in milliseconds. So at max setting (65535) this is roughly one minute, 5 minutes would not be possible at all!
We also tried to make all communication settings adjustable in single-registers (as opposed to 32 bit unsigned integers) because it might avoid some of the endianess ambiguities and it could be helpful for masters which only implement function 06 hex (not 10/17 hex) for writing registers.
What would you advice? Using two registers for that time value?
Best regards, Sebastian
> The problem is this: We have this time adjustable in a 16-bit register, in
> milliseconds. So at max setting (65535) this is roughly one minute, 5 minutes
> would not be possible at all!
Satellite taking 5 minutes is very rare! And very expensive! If the customer only needs to read 4 or 10 words 'on average', then this doesn't even affect them.
I think 1 minute is 99.9% of what you need.
Or just change it to be in 2 or 5-msec slices, so 65K is 2 minutes or 5 instead. But I'd not bother to change from a 1 minute limit ... 5 seconds would be too short (& I've seen products limited to 5 seconds or less), but 65 seconds is reasonable.
thank you for the advice and please excuse that I'm a week late with my reply.
>I think 1 minute is 99.9% of what you need.
This is very reassuring. Also, it will be easier to scan for the devices if this time has a max setting of one second, because each scan would have to be preceded by at least that amount of silence.
> Or just change it to be in 2 or 5-msec slices, so 65K is 2
> minutes or 5 instead.
What would you recommend as resolution of the silent period? Currently, we have our general purpose timer running at 10 kHz just to get a resolution of 100 microseconds for the Modbus control times. The timer interrupt is a great drain of clock cycles, so if such a high resolution would not be required, we could speed up the main program by running a 1 kHz Modbus-timer instead.
Best regards, Sebastian
> ... Also, it will be easier to scan for the devices if this time has a max setting of one second, ...
Sorry, typo. That would be one minute, of course.
In concur with both of you, in SeqZap (http://seqzap.com/) we never take the pauses into account since we are on a PC anyway, and you just don't get that kind of timing there :)
Actually we have been successful in reading all sorts of customer modbus implementations, because if we can't read a particular byte, we just skip ahead to the next byte and try parsing from there. This means that non-understood packets are just skipped.
> Actually we have been successful in reading all sorts of customer modbus
> implementations, because if we can't read a particular byte, we just skip
> ahead to the next byte and try parsing from there. This means that
> non-understood packets are just skipped.
Do you parse like this in the master or in the slave?
On slave side it should be possible to obsolete the need for a silent period by parsing from each byte, like you mention. Most of those parallel parsing paths would soon come to an end because of wrong address, function byte, data byte count or CRC16. Only the messages which - for each byte - passes all plausibility checks would be answered. Is that what you do?
Arbitrary data might eventually by chance pass all plausibility checks and mimic a valid master request. How do you protect your parser against that chance? Or is what you do different from what I imagined?
Best regards, Sebastian
I recently had a case where our thermocouple input module, M-7018Z http://www.icpdas-usa.com/products.php?PID=3246 and another vendor's product were sitting on the same bus. When our module reached a certain temperature the master would get errors. It looked like our bug, because the error depended on analog input! But it turned out that if the other module had a different address, the temperature would need to be different to trigger the error. The answer was that the other module wasn't checking CRC at all, and responded to our module's temperature data with an 'invalid command' response. The point is, it really matters to check all the parameters of the command when writing a slave device driver.
Nice example. Discarding the CRC16 must be hardcore ignorant.
> The point is, it really matters to check all the parameters of the command when writing a slave device driver.
... including the silent period to ensure that the message is parsed from the start, right? So, it seems that the silent period must be set longer than the largest possible gab in the messages of both, master and slaves. Which means, that in RTU mode, the polling frequency of the master decreases as the gaps in the message increase. So, maybe, ASCII-mode would be preferable over such comm channels? Is it used much anymore? Or do most people prefer to down tune their polling frequency (increase their silent period) in RTU?