Re: [DISCUSS] How to do discovery?
Just had another idea ... How about giving this driver no real transport at all (think we have the dummy transport ... that works like a charm) and then to provide the means in the subscription addresses? This way I could start discovering serial, passive and active ... and perhaps even multiple instances with just one connection ... Chris Am 30.06.20, 19:09 schrieb "Christofer Dutz" : Hi folks, for the past weeks I have been thinking about how we could approach the “discovery” topic. I think I just had an idea and would like some feedback from you. So I was thinking about how we could model such a discovery API. In general it would look pretty different to the existing APIs … at least I thought. The Idea I just had, was: How about we create a new “discovery” driver? This can use both the serial transport as well as the passive-mode transport or even tcp transport for protocols that allow active discovery mechanisms. So you would simply create a “connection” to something like “discovery:raw//eh1” or “discovery:serial:///dev/ttyS0” … now this driver would be a little special. It would internally query the list of drivers available on the given system, the same way the DriverManager does it. But it would check each driver if it implements an interface “SupportsDiscovery” (or whatever name we give it) … So it would then initialize an instance of all drivers supporting discovery. So in the end the DiscoveryDriver would simply try to feed each packet to each of the drivers and have them check if they can make sense out of that. If they do, they would start emitting events just the same way a resource subscription does. (Of course we should probably apply some filtering mechanism to avoid too much overload) So a client wanting to use discovery, would use the normal PLC4X API to connect and then would simply subscribe to the datastream produced by that. So in the end we wouldn’t be changing anything with the user-facing API and all could be done internally … and the cool thing we would get all the integrations working with this without modifications for free :-) … so you could start simply streaming the discovery data to StreamPipes or Kafka or log it in IoTDB for intrusion detection or other crazy stuff What do you think? I have to admit I am currently absolutely happy with this idea … so please … bombs away … tear it apart ;-) Chris
[DISCUSS] How to do discovery?
Hi folks, for the past weeks I have been thinking about how we could approach the “discovery” topic. I think I just had an idea and would like some feedback from you. So I was thinking about how we could model such a discovery API. In general it would look pretty different to the existing APIs … at least I thought. The Idea I just had, was: How about we create a new “discovery” driver? This can use both the serial transport as well as the passive-mode transport or even tcp transport for protocols that allow active discovery mechanisms. So you would simply create a “connection” to something like “discovery:raw//eh1” or “discovery:serial:///dev/ttyS0” … now this driver would be a little special. It would internally query the list of drivers available on the given system, the same way the DriverManager does it. But it would check each driver if it implements an interface “SupportsDiscovery” (or whatever name we give it) … So it would then initialize an instance of all drivers supporting discovery. So in the end the DiscoveryDriver would simply try to feed each packet to each of the drivers and have them check if they can make sense out of that. If they do, they would start emitting events just the same way a resource subscription does. (Of course we should probably apply some filtering mechanism to avoid too much overload) So a client wanting to use discovery, would use the normal PLC4X API to connect and then would simply subscribe to the datastream produced by that. So in the end we wouldn’t be changing anything with the user-facing API and all could be done internally … and the cool thing we would get all the integrations working with this without modifications for free :-) … so you could start simply streaming the discovery data to StreamPipes or Kafka or log it in IoTDB for intrusion detection or other crazy stuff What do you think? I have to admit I am currently absolutely happy with this idea … so please … bombs away … tear it apart ;-) Chris
Re: [VOTE] Rename our "master" branch to "release"
+1 because why not? Most others are considering “main” or something, avoiding what you are (I think) explicitly going for using release which as such meaning. Can always change it back On June 29, 2020 at 03:09:44, Christofer Dutz (christofer.d...@c-ware.de) wrote: Hi all, we had already discussed that some days ago, but I’d like to formally have you all vote on this … just to make it official. I always thought “master”, “trunk” etc. were sub-ideal names as they don’t explain what they are used for. We currently develop on “develop” and therefore I propose to change the “master” branch to “release”. While at it I would propose to call the release branches “release/x.y” (instead of “rel/x.y”) and to tag the releases themselves with the full three-digit numbers “release/x.y.z”). This way I think we would have all in a very clean and concise naming scheme where nobody has to ask himself, which branch is used for what. Chris
[BUILD-STABLE]: Job 'PLC4X/PLC4X/develop [develop] [935]'
BUILD-STABLE: Job 'PLC4X/PLC4X/develop [develop] [935]': Is back to normal.
[BUILD-FAILURE]: Job 'PLC4X/PLC4X/develop [develop] [934]'
BUILD-FAILURE: Job 'PLC4X/PLC4X/develop [develop] [934]': Check console output at "https://builds.apache.org/job/PLC4X/job/PLC4X/job/develop/934/;>PLC4X/PLC4X/develop [develop] [934]"
[BUILD-FAILURE]: Job 'PLC4X/PLC4X/develop [develop] [933]'
BUILD-FAILURE: Job 'PLC4X/PLC4X/develop [develop] [933]': Check console output at "https://builds.apache.org/job/PLC4X/job/PLC4X/job/develop/933/;>PLC4X/PLC4X/develop [develop] [933]"
Re: Serial port Connection
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" : On Tue, Jun 30, 2020 at 2:31 PM Christofer Dutz 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
Re: [VOTE] Rename our "master" branch to "release"
+1 Sebastian > Am 29.06.2020 um 09:09 schrieb Christofer Dutz : > > Hi all, > > we had already discussed that some days ago, but I’d like to formally have > you all vote on this … just to make it official. > > I always thought “master”, “trunk” etc. were sub-ideal names as they don’t > explain what they are used for. We currently develop on “develop” and > therefore I propose to change the “master” branch to “release”. > > While at it I would propose to call the release branches “release/x.y” > (instead of “rel/x.y”) and to tag the releases themselves with the full > three-digit numbers “release/x.y.z”). > > This way I think we would have all in a very clean and concise naming scheme > where nobody has to ask himself, which branch is used for what. > > Chris > >
Re: Serial port Connection
On Tue, Jun 30, 2020 at 2:31 PM Christofer Dutz 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
Re: Serial port Connection
Hi all, and thank you Niclas for your very detailed post. Indeed I think you made me realize something I didn't realize till now: You can connect multiple devices to a serial Interface. For me, from the first zero-modem-cable I welded to play command and conquer against a friend, serial interfaces were only one-to-one connections. I guess that's why I built things the way I built them. If I had known what you now made me know, I agree at least the handling of the serial port I would have done differently. Also I have to admit, that the serial communication option was not handled as a first-class citizen by me and probably others here as I at least only have one serial-capable PLC but I don't even have a serial to usb-c adapter (Should really get one ...) So it was always a rather theoretical construct. Also I don't recall people reporting to have used it before. So I agree we should address your findings asap. But can we assume that only one protocol is handled over one serial interface? So not multiple Modbus devices sharing with multiple S5 devices ... Because in this case I guess we could refactor things a bit. 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. 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. I know that in a case like PLC4X where we want to map all sorts of communication variants under one API, we will never get it that it's a perfect match for all protocols, especially if it's the projects goal to have one shared API. But again ... thank you for your detailed input ... this is some very important information and it even made a lot of things clearer to me which customers in the past said and I simply didn't understand ;-) Chris Am 30.06.20, 06:12 schrieb "Cesar Garcia" : Hi Niclas, You are right on all points. I have not tested the Modbus serial driver, but I am very interested that it works on Multidrop connections. Version 0.7.0 is based on Mspec, so a proposal could be: 1. Modify the PLCField to include the UID of the device within the frame from the address of the Item. 2. The default UID must be the one inserted in the Connection String. 3. Evaluate the queue of requests, I think the standard allows a single frame depending on the connection (Half / Full Duplex). It should not be very laborious, I can keep an eye on it. Here Chris can guide us if it is the way. Best regards, El lun., 29 jun. 2020 a las 22:59, Niclas Hedhman () escribió: > Ok, let's dissect this... > > 1. There are many devices connected to a serial ModBus port. > > 2. ModBus (and every other serial protocol I have dealt with) are not > "connection" oriented, but packets, most of the time very small. The > "connection" metaphor in PLC4X for non-TCP comms is actually quite poor.[1] > > 3. All serial protocols (that I worked with) have at least the destination > present in the protocol packet itself. When some of these serial protocols > were "wrapped" for modern TCP/IP communications, an ambiguity surfaced. And > in case of ModBus, the device address was simply defaulted to 1 (although I > think some gateways can handle many, and perhaps some TCP devices will map > out more than one ModbUs device, but I have no experience in that) > > > So, as things are right now, and if I didn't misunderstood something > (totally possible), is that one is required to "open->->close" the > PLC4X connection for each device that I want to scan/read, as I think the > device address (1 byte in case of ModBus) is part of the connection string. > The biggest system I have ever been involved with was just under 1000 PLCs > (granted, not modbus) with 30,000 data points readable in total. It feels > "s wrong" to have "open->send->receive->close" operation for all of > those, AND that the timing on that particular system was that for optimal > performance, exactly 1 byte of delay (related to half-duplex
