Last release looks broken. about arduinomodbusslave

[falahati]

Hey @raf59, thanks for the issue.
Please allow me to test it myself. I will report back.

[raf59]

I just tried the library at 9600 bauds.
When I just write slave.poll() in the loop, I only get CRC errors.

As soon as I write on the Serial line in the poll event (slave.poll()!=0 { Serial.println(); }), everything starts working.

I get the same behaviour up to 28800 bauds.
With higher baudrates, everything seems to be working fine, even without printing to the Serial line.

[falahati]

@yaacov; yes it does Yaacov.

[yaacov]

Thanks for the issue 👍 @falahati can you take a look ?

[falahati]

I just submitted a PR for this problem to the main repo. However, it would be great if you could try this before @yaacov merges it. The branch with this fix included is available here:

https://github.com/falahati/ArduinoModbusSlave/tree/fix2

[yaacov]

merged ❤️

[raf59]

Hello @falahati
Thanks for the PR. 😃
I can't try it right now. My bus is busy, I'm performing another test wich takes a long time.
I'll give it a try tonight

[falahati]

Thanks for the detailed reports.
This seems like a transmission control problem. Probably Serial clears the transmission buffer before starting to send a byte.

It would be great if you check out this branch before I submit a PR:
https://github.com/falahati/ArduinoModbusSlave/tree/fix3

I also strongly suggest using another Serial port for RS485 communications instead of the board's main serial port (aka; the USB port). AltSoftSerial is the best alternative I found out based on the communication technics it uses if your board only provides you with one serial output. That being said, I am happy that you used the main serial port and therefore provided us with much-needed feedbacks.

PS:
Let me clarify what changed between the two releases.
In the older releases; ArduinoModbusSlave used to write the response in one go and then waited for it to get completely transmitted (if this functionality was available in the underlying Serial implementation); this is known as blocking communication. I changed this behaviour to nonblocking; meaning that in the new release; ArduinoModbusSlave now writes the response to the underlying Serial library's buffer in one or more steps and then periodically checks if the buffer is empty therefore transmission is considered as completed.

There are clear advantages to this; one is the fact that it is interrupt friendly and also allows for larger transmissions as well as faster transmission due to the fact that majority of the Serial libraries block the write request if the requested data is larger than the transmission buffer of the Serial library at the time until the transmission buffer is completely empty. It is also watchdog friendly as it does not keep the program in a while loop as well as making your real code more responsive.

Now comes the cons; or more specifically; the con. Almost every Serial library has a bad nonblocking implementation. AltSoftSerial didn't even report the free space available in the transmission buffer up until the last week (still waiting for a release; the workaround is already a part of the code); Serial seems to empty the buffer before even completely sending the data (hence your current issue) and almost every one of them uses a different size for the buffer (workaround is, again, already a part of the code).

Still, I think it worth the time and resources to use the nonblocking technics if only for the big list of pros it offers. In network programming, we use this technic all the time when the number of threads is limited. Blocking is only considered when there is no limit (or a very high limit) for the number of threads. In newer implementations when the language offers more asynchronous tools, like in the C#'s async case, these two technics are merged in a way that from the programmer point of view it is as easy as writing a blocking code and in reality, it is in a semi-nonblocking mode. Unfortunately, we don't have something like that in C++ especially with a single thread.

[yaacov]

@falahati can you reproduce ? if yes :-) does this fix work on your side ?

[yaacov]

@yaacov; yes it does Yaacov.

That is good enough for me 😎 if you want to make a PR 🍰