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 
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?


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>

    > 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 
    > 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

Reply via email to