Hi Niclas, Now your're borrowing my reasoning to use PLC4X over OPC UA to argument for Serial communication ... I like it ;-) Yeah, I know that industrial hardware tends to be run a tad longer than a typical IPhone ... and I agree ... we need to get serial in shape. I did notice with the Firmata driver that there will be issues as this is actually a serial protocol, which is stateful (You need to configure the connection in order to use it) Here I encountered the limitation of connection-to-port linking for the first time for which I still don't really have an answer.
> 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 think you initially mentioned, that we have the device-address in the connection string, which makes it necessary to connect and disconnect all the time. My proposal was to leave that option in the connection string, but to treat it as a "default-device-address" which is used if the actual address doesn't have it (Typical TCP case) ... then we would add a second set of address types that contain an additional device-address prefix. So you could simply connect to the serial version without providing the device-address and then use the extended address format for resources and pass in the additional device-address. That a little clearer? Chris Am 30.06.20, 09:12 schrieb "Niclas Hedhman" <nic...@hedhman.org>: 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