add FC Extensibility

[a-hennig]

I consider switching from goburrow to this modbus stack, but would need additional FC (manufacturer, file, fifo) and vendor specific ones.

What would you think about adding an extension point for FC calls?
something along the lines of wrapping assembleRTU, parseRTU, expectedResponse{length] into an interface and adding registerFC + send + receive functions to the transport or client.

this would allow me to develop my vendor specific FC locally.
And if I develop a standard FC (like one of my team members did in github.com/debevv/modbus for FC43), I can develop ahead and open a pull request to here ... without waiting on my fork until the merge is done.

[simonvetter]

Hi there,

I would definitely love to add support for file and fifo opcodes. That's been on my todo list for a long, long time, I just haven't been able to do it quite yet (and get my hands on devices supporting them to test).

Regarding manufacturer-specific function codes, would adding a client method along the lines of

func (c *ModbusClient) ExecuteCustomReq(reqFC uint8, reqPayload []byte, expectedResponseLength uint8) (resFC uint8, resPayload []byte, err error)

suit your needs?

The idea is that you'd send your own function code along with its payload and expected response byte length and get a reply FC back with its payload as well, a standard modbus error (if the response FC falls in the standard exception range), or any other I/O error, depending on the outcome. Both request and response payloads would be treated as opaque byte strings and the caller would be responsible for encoding/decoding them.

This should be trivial to implement for MBAP-based transports (i.e. TCP/UDP), but I'd have to find a way to let the RTU transport know about how many response bytes to expect. That may require a rework of the transport interface, but since it's not yet exposed outside of the package, it's probably okay.

Otherwise, I think it would fit nicely with the current client interface.

What do you think? BTW, are your target devices mainly TCP or RTU?

[a-hennig]

Yes, that would work nicely. Thanks! TCP/RTU answer depends on viewpoint 😊 if by project progress, its “95% TCP” by target use case more a “65% TCP”. Pricepoint of RTU serials makes it a die-hard .. I even once visited a data center and asked how they connect their modbus power meters. Answer was “by serial, obviously .. the price for an ethernet port is just too high” … and that in a data center …

[simonvetter]

Heh sure, no judgement here :) I'm on the RTU team for power meters as well, especially when they are all located next to each other.

My question was more whether making custom opcodes work with the TCP transport only as a first step would be ok for you, I should have made that more explicit. If yes, I should be able to add that quickly.

[a-hennig]

Interface stability >> timing 😊 i.e. if you think the RTU support might break the signature of the TCP version, I’d rather wait 2-4 weeks more. If its [likely] going to be non-breaking or two different methods anyway, then TCP first please 😊 From: Simon Vetter ***@***.***> Sent: Friday, June 16, 2023 11:55 AM To: simonvetter/modbus ***@***.***> Cc: Hennig, Andreas (SI BP R&D) ***@***.***>; Author ***@***.***> Subject: Re: [simonvetter/modbus] add FC Extensibility (Issue #31) Heh sure, no judgement here :) I'm on the RTU team for power meters as well, especially if they are all located next to each other. My question was more whether making custom opcodes work with the TCP transport only as a first step would be ok for you, I should have made that more explicit. If yes, I should be able to add that quickly. — Reply to this email directly, view it on GitHub<#31 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AHLN3O44X2LBUH2HIBS5IGLXLQURDANCNFSM6AAAAAAZI4L4KU>. You are receiving this because you authored the thread.Message ID: ***@***.******@***.***>>

[Shiny380]

@simonvetter NubeIO are currently implementing R/W File Record FC's under https://github.com/NubeIO/go-modbus-fork

[a-hennig]

@simonvetter NubeIO are currently implementing R/W File Record FC's under https://github.com/NubeIO/go-modbus-fork

good to know and see :)
is that intended to merge back here?

looks like its not using an extension point, but goes straight into the package (good/ok for really standard FC .. but I have seen some "local interpretation of FCxxx" that I wouldnt see in a general library.

[simonvetter]

Sorry folks, haven't had much time to work on this project recently... things should clear up soon.

#37 seems to have both read and write file record support, awesome!

I'm going to try to get my hands on a PLC supporting those functions to test, make a few adjustments and push a new release once done.