-
Notifications
You must be signed in to change notification settings - Fork 76
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Question] Is the frame delay accounted for in this library #76
Comments
Actually there is not minimum delay between frames enforced by FluentModbus since I was not aware of such a requirement. I will add it according to the spec. So thanks for mentioning it! I guess no problems occurred so far because FluentModbus (which uses the Do I understand you right that you do not want any fixed delay (as it is the case right now)? So when I implement it, you need a way to switch it off? |
Thanks for your answer. Right, for my application I require the maximum throughput which, according to the specification, would not be possible. So yes one should be able to switch it off. The interframe delay is not very efficient as it will decrease up to to a certain baud rate (obviously 3.5 chars between each frame have different length for different baud rates) only to be a fixed value above a certain baud rate (115200?). See p. 14 Modbus Spec |
Okay, then I will implement it and make it possible to switch it off. I am on holidays right now so I`ll do it when I am back. |
Thank you @Apollo3zehn, enjoy your vacations! |
I will implement it later, no time right now and I am not sure how to properly implement it. The following link is only for myself for later reference: https://stackoverflow.com/questions/20740012/calculating-modbus-rtu-3-5-character-time#21223624 |
Hello,
I'm currently using this library to read data from a client. Works well so far. Thank you!
Just one thing: Is the implementation according to the specification with a 3.5 char delay or/and a minimum interframe time? I'm asking because I require the highest possible performance and a fixed interframe time would be too much of a delay in my use case.
Thank you,
Andy
The text was updated successfully, but these errors were encountered: