Managing multiple slaves with the RTU API, perhaps concurrently. about modbus

[nqv]

wrt concurrent access, I'm in the process of adding mutex in the client transporter and fix #16 (expected to be done this week :) )
The client api doesn't have SlaveId in the parameter as using slaveId for TPC is rare. My idea originally is the ability to share the transporter layer among clients, which is like:

h := NewRTUClientHandler()
// Default client
c := NewClient(h)
// Create new Client for different SlaveId
h2 := NewRTUClientHandler()
h2.SlaveId = 2
c2 := NewClient2(h2, h)

May be I can add a helper

func NewClientWithSlaveId(c Client, slaveId int) Client {
   // Clone internal packager, set new slaveId and return a new Client with that packager
}

Please let me know if that will resolve your case. (Again, that requires #16 to be fixed)

[jonseymour]

I think from my point of view, NewClientWithSlaveId(c Client, slaveId int) does what I need and has the advantage that if I need to defer the creation of clients for other slaves, that I can do so without carrying the handler around.

[jonseymour]

Prototyping this, I realised that there may be a need to add a Close() method to the Client interface and also a reference counter in the implementation to allow a Close() on the underlying handler to be deferred until there are no more references (otherwise this will have to be tracked separately).

update: actually whether there is a need or not, I guess is to some degree a matter of preference. I guess my preference would for applications not having to worry about the lifecycle of handlers, but I can see the alternative argument that if applications have to allocate handlers they should have to deallocate them too.

[nqv]

I don't think Close is needed (like http client). Will send a PR for #16 this weekend so you can see what I mean.

Cheers

[gonium]

I had the same issue - which I solved by setting the Slave of the RTUClient before sending anything:

https://github.com/gonium/gosdm630/blob/master/src/github.com/gonium/gosdm630/modbus.go#L114

There is no need to Close() anything. I understand (and appreciate!) @nqv's view to provide a unified API independent of the transport, but for practical applications of the RTU transport, one needs to have a way to set the slave id.

HTH,
-Mathias

[Aditya23456]

Hi,

Thanks for the great library. I don't see any development branch and was wondering if there's any support for concurrent Modbus client or any work done for supporting it ?

Thanks once again,
Aditya