chrisdutz
commented
9 months ago As there are multiple drivers affected by similar issues, I was planning on addressing this differently. All serial-transport protocols can only have one connection using them and all RawSocket transports, as that currently get's an exclusive lock on the serial port. PROFINET would currently only allow talking to one device at a time as having multiple raw-socket channels doesn't seem to be possible. Same with BacNET, as this opens a listening UDP-Port of a fixed port number (I think).
So we generally need to come up with a way to distinguish between exclusive transports (TCP, UDP without a fixed local port number) and shared transports (Serial, UDP with fixed local port number, Raw-Sockets).
As soon as that's solved, I think we should stick with the "multiple connections" approach, even for Modbus, as the alternative would be to add a device-id to every address. As I think ModbusTCP is the by far most used Modbus variant, I wouldn't want to add this to every modbus address.
An alternative would be to make it optional in the modbus addresses ... so if there is no deviceId provided, it uses a default.
What happened?
Modbus unit id is part of every frame which is being exchanged through TCP / UDP or serial port. It means that this parameter is not needed for connection negotiation. It does not need to be set prior connection establishment. It might remain as a connection level default, for shortening tag definitions for basic applications.
Given that there are inverters which support multiple unit ids for different modbus register tables current way of managing unit identifier requires starting up multiple TCP (or even worse) - serial connections.
Version
v0.11.0
Programming Languages
Protocols