Introduce support for callback functions

[mhei]

I've a device which implements custom modbus functions. Receiving the response for this functions is only possible when libmodbus knows about the response length. As various device could implement the same function codes its up to the program using the modbus library to calculate/provide the response length correctly. So this two patches are a RFC to deal with such situations.

[stephane]

Hi Michael,

I intend to add a callback support to libmodbus for years! I'll try to give feedback on your RFC in following weeks

[daschuer]

Hi Michael,

Thank you for your branch.
What was the reason to introduce a common callback function type using ...
For me this looks like a source for runtime errors if the user messes with the function types.

Kind regards,

Daniel

[mhei]

Hi Daniel,

your are right, me too, I'm wondering whether this is the correct approach for a library. When I coded this PR, my main intension was to indicate the/my need for my particular requirement and to get a discussion started - as we do here :-)
As indicated, take this as an RFC.
What do you think or which approach do you prefer? For each callback a single function type?

Best regards,
Michael

[daschuer]

Hi Michael,

Yes, I would prefer a fixed function type for each callback. I have also
seen one common callback with an additional parameter telling why it is
called.

I am currently working at the QModBus tool. There is a need for two
additional callbacks to implement a bus Monitor.

Kind regards,

Daniel

2013/11/5 Michael Heimpold notifications@github.com

Hi Daniel,

your are right, me too, I'm wondering whether this is the correct approach
for a library. When I coded this PR, my main intension was to indicate
the/my need for my particular requirement and to get a discussion started -
as we do here :-)
As indicated, take this as an RFC.
What do you think or which approach do you prefer? For each callback a
single function type?

Best regards,
Michael

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/140#issuecomment-27769379
.

[karlp]

This would ~solve the core issues in #231 and #344

The following issues could then become "trivially" implemented in user code, instead of requiring library mods to function at all.
#407
#330
#449
#431
#474

[dangowrt]

Beautiful. Would allow me to use libmodbus in https://github.com/dangowrt/tracertools/ ... Just that EP also uses a function code reserved for error handling (supposedly they miscalculated decimal 100 as 0xA0...)

[ekigwana]

How unfortunate that I now have to roll my own because this is exactly what I needed.Considering this idea with a contributed patch has not made it since September 2013, there is no point to trying to convince anyone here or even contributing patches!

Another example of hardware where this library does not work SeaLevel SeaI/O 462

The irritating part is that I almost got all the way there using the other inefficient methods. That is until I got ERROR Illegal data address at address 88 when using modbus_read_input_bits. I'll never get my 2 days back.