On Tue, Jun 30, 2020 at 2:31 PM Christofer Dutz <christofer.d...@c-ware.de> wrote:
> But can we assume that only one protocol is handled over one serial > interface? So not multiple Modbus devices sharing with multiple S5 devices > ... > So, I have never seen anyone trying multiple protocols on the same port, so that is a safe assumption. Even if I think there are devices that can auto-sense Modbus and Bacnet, I doubt anyone will ever want to do both. > Because in this case I guess we could refactor things a bit. > And I totally agree that as little changes as possible should be attempted, so I won't suggest a rewrite, don't worry ;-) Perhaps to have an optional device-address on the connection level which > will act as a default and to extend or provide a second set of addresses, > that have the device-address within. So you could either use the > device-address together with the smaller field addresses (Mainly for TCP > connections) and these would inherit the default device-address or you > could use the bigger ones where you provide the device-address for every > field. > Not sure what you mean here. ModBus/RTU has a one byte Address and a Checksum, and those are dropped in Modbus/TCP and that relies on the delivery/checksum of TCP/IP. > I wouldn’t want to change the naming however ... you could consider in an > extended serial modbus scenario (If we changed the serial part the way you > proposed), that the connection is from the software to the port ...Which > would be true. And most of the other drivers in PLC4X actually do more have > a Connection-oriented communication form. I guess this is due to the fact > that we concentrated on the SCADA-Level protocols first and now are > gradually stepping deeper into the fieldbus area. > I think only the EIP protocol is also somewhat connection-less, but S7, > OPC UA, AMS/ADS, ... definitely are. > Interesting. I have very little experience "higher up" and perhaps there are enough reasons to make abstractions different for stateless (or packet) protocol vs those that are stateful. The compromise now is that stateless pretends to be stateful, and a cycle of "open->close" takes place, very much similar to HTTP/1.0 being stateless over the stateful TCP. I am not 100% confident what is the best way forward, so I'll come back to that later. I think in the short term, I can survive because my current need is very small (reading 5-10 values from each of 3-5 devices) and it is hourly-relevant data. In the process, I will try to formulate ideas for changes... I know that serial comms are slowly dying out, but the amount of stuff already out there and lifespans of decades, it will take a while before it is all gone. // Niclas
