-
-
Notifications
You must be signed in to change notification settings - Fork 1.9k
Add modbus_reply_callback() #396
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
Conversation
|
It seems very interesting on first quick review 👍 |
0d21b1b to
bc769b3
Compare
doc/modbus_reply_callback.txt
Outdated
| application_context *ctx = user_ctx; | ||
|
|
||
| /* ... */ | ||
|
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think you want a better example here, ie, what is length meant to be? related, Where is "len" coming from if not the bytes? Your comment above about this being "values" not bytes makes it very hard to do generic code, without having to handle all the modbus function code internals.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agreed, the doc needs some more work. Have you looked at the implementation I put into modbus.c for the mapping-reply?
Modbus internals yes, but not many. A user needs to know how to get/put bits and registers out of/into the buffer given to the read and write callback. I chose to propose it like this because it avoids allocating memory and additional copies inside libmodbus.
doc/modbus_reply_callback.txt
Outdated
| { | ||
| application_context *ctx = user_ctx; | ||
|
|
||
| /* ... */ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
likewize, I feel some trivial, but real example would be better here than just "/.../"
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's in the works.
bc769b3 to
524fabe
Compare
|
Please do not merge the pull-request for the moment, I'm currently working actively on it and it is not yet ready. However, the basic idea probably won't change, feel free to comment. |
e76dd39 to
7e56e8f
Compare
|
I made more changes to reduce LOC and thus more DRY, maybe the code has become more complex. Basically the verification-part and read/write-part has been separated in two switch-cases and thus exception-replies are done once for all MODBUS_FC_* as well as value-count extraction of buffers. When reviewing, looking at the diff for modbus.c is maybe not the best idea (anymore). Doc is still missing. |
94cd17f to
8535b71
Compare
8535b71 to
3f8465e
Compare
Based on @frodete's proposal (stephane#319) this implementation adds a a callback-based reply-functionality. The old mapping-implementation is now based on this version. As a nice side-effect some DRY code optimizations could have been done. Also adds a MODBUS_SLAVE_ACCEPT_ALL "address", which can be used with modbus_set_slave(). This makes the modbus_receive()-function accept all requests, independently of the slave-address found in the decoded-request. Useful for multi-slave-implementation using libmodbus.
3f8465e to
d113379
Compare
Based on @frodete's proposal (#319) a more minimalist implementation of a callback-based reply-function.
The old mapping-implementation is now based on this version. As a nice side-effect some DRY code optimizations could have been done.
Unit tests are OK. And my RTU-multi-slave server starts to work.
EDIT:
My motivation for needing a callback-based reply is that I need to implement a modbus-tcp-server and a modbus-rtu-slave. Both will handle the data within a cache. The rtu-slave implementation has to be able to handle multiple slaves. One RS485-port multiple slave-id will be handled.
More details to what I have done: I took the
modbus_reply-function and changed its name tomodbus_reply_callback. Then, each time where something was checked against thestart_bits/start_registers-adresses andtab_*-counts I replaced it with a call to the callbackverify. And each time the payload-part of the request or response-buffer was accesses I replaced it with a call to the callbackreadorwriterespectively.Then I implemented the previous
modbus_reply-function in a way that it uses themodbus_reply_callbackfunction by providing callbacks forverify,readandwrite. In these callback-functions I put the code which previously was in charge to fill in the buffer or to verify the boundaries. By doing so, some code-duplicates have been removed, especially accesses to the buffers in the mapping and its verification.