Re: Serial port Connection
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 modem > direction switching) between receiving the last byte of previous packet > before the first byte of the new packet. Without the "Serial Port" > abstraction, with a queue of requests to send, such timing is not trivial. > > What I think has "gone wrong" here is that the "serial port" is an > interface, pretty much like "eth0" and should be handled "further down" but > since the operating system has no support for it, it should have been in > PLC4X's architecture. I also think that the "connection" metaphor is poor, > and a "packet" metaphor would have been much better throughout PLC4X > regardless whether it is TCP/IP, UDP or serial. The actual TCP connection > when needed should be handled under the hood, rather invisibly to the user. > As I said before, I understand that this is not something that can be > changed, just like that... Only expressing how I think it should have been > done. > > I will try to work with what we have, and dig into the details on the > serial port side, as that's where I have plenty of experience and I get the > impression that it isn't the strength of the community. I am sure you will > hear a lot from me going forward, as I have decided to put PLC4X into my > commercial product, replacing the existing j2mod. > > > Niclas > > [1] It is quite funny that the serial port is natively a stream, and we map > packets onto it. TCP/IP is natively packets, which is then made into a > stream, which we then map packets onto the stream. Ideally, UDP is fit for > purpose for PLC protocols, but for some unknown reason few are. > > > > > On Mon, Jun 29, 2020 at 4:00 PM Christofer Dutz > > wrote: > > > Hi all, > > > > sorry for joining in the party late ... but hopefully not too late. > > > > Regarding making the serial port part of the connection string ... I have > > to admit that right now I couldn't imagine how to not have it in there > and > > not over-complicate things for the users. Yes, if you create a connection > > this will have exclusive handle to the port, but this is actually an > > important thing to have. In contrast to network devices that can handle > > multiple connections in parallel ... a serial port is ... well ... > serial. > > Havin asynchronous access to one serial port from multiple areas in an > > application sound like a bad Idea. > > > > However you could always use the connection pool ... in this case the > pool > > would have one connection open and could share this (serially) with > > multiple parts of an application. Here a part would request the > connection, > > do its work and then give the connection back to the pool where another > > part of the application could use it. This way I think we have the ideal > > tradeoff between sharing a connection and not having to be concerned > about > > breaking the serial operation of the serial-port communication. >
Re: Serial port Connection
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 modem direction switching) between receiving the last byte of previous packet before the first byte of the new packet. Without the "Serial Port" abstraction, with a queue of requests to send, such timing is not trivial. What I think has "gone wrong" here is that the "serial port" is an interface, pretty much like "eth0" and should be handled "further down" but since the operating system has no support for it, it should have been in PLC4X's architecture. I also think that the "connection" metaphor is poor, and a "packet" metaphor would have been much better throughout PLC4X regardless whether it is TCP/IP, UDP or serial. The actual TCP connection when needed should be handled under the hood, rather invisibly to the user. As I said before, I understand that this is not something that can be changed, just like that... Only expressing how I think it should have been done. I will try to work with what we have, and dig into the details on the serial port side, as that's where I have plenty of experience and I get the impression that it isn't the strength of the community. I am sure you will hear a lot from me going forward, as I have decided to put PLC4X into my commercial product, replacing the existing j2mod. Niclas [1] It is quite funny that the serial port is natively a stream, and we map packets onto it. TCP/IP is natively packets, which is then made into a stream, which we then map packets onto the stream. Ideally, UDP is fit for purpose for PLC protocols, but for some unknown reason few are. On Mon, Jun 29, 2020 at 4:00 PM Christofer Dutz wrote: > Hi all, > > sorry for joining in the party late ... but hopefully not too late. > > Regarding making the serial port part of the connection string ... I have > to admit that right now I couldn't imagine how to not have it in there and > not over-complicate things for the users. Yes, if you create a connection > this will have exclusive handle to the port, but this is actually an > important thing to have. In contrast to network devices that can handle > multiple connections in parallel ... a serial port is ... well ... serial. > Havin asynchronous access to one serial port from multiple areas in an > application sound like a bad Idea. > > However you could always use the connection pool ... in this case the pool > would have one connection open and could share this (serially) with > multiple parts of an application. Here a part would request the connection, > do its work and then give the connection back to the pool where another > part of the application could use it. This way I think we have the ideal > tradeoff between sharing a connection and not having to be concerned about > breaking the serial operation of the serial-port communication. > > And yes: We could use some documentation on the connection pool ... and > the scraper ;-/ > > Perhaps I'll whip up a little documentation on the connection-pool as I > just recently had to find out how to use it myself ;-) > > Chris > > > Am 25.06.20, 11:41 schrieb "Julian Feinauer" < > j.feina...@pragmaticminds.de>: > > Hey, > > yes, its in the module scraper or plc-scraper. > Its easily configurable by yaml, json or programmatically. > > Julian > > Am 25.06.20, 10:30 schrieb "Niclas Hedhman" : > > Thanks > > Another question; is there any "loop" system that just > continuously reads > until I tell it to stop? > > On Thu, Jun 25, 2020, 15:16 Julian Feinauer < > j.feina...@pragmaticminds.de> > wrote: > > > Hi Nic, > > > > I have to dig in a bit later
Re: [VOTE] Rename our "master" branch to "release"
1+ El lun., 29 jun. 2020 a las 3:09, Christofer Dutz (< christofer.d...@c-ware.de>) escribió: > 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 > > > -- *CEOS Automatización, C.A.* *GALPON SERVICIO INDUSTRIALES Y NAVALES FA, C.A.,* *PISO 1, OFICINA 2, AV. RAUL LEONI, SECTOR GUAMACHITO,* *FRENTE A LA ASOCIACION DE GANADEROS,BARCELONA,EDO. ANZOATEGUI* *Ing. César García* *Cel: +58 414-760.98.95* *Hotline Técnica SIEMENS: 0800 1005080* *Email: support.aan.automat...@siemens.com *
Re: [VOTE] Rename our "master" branch to "release"
+1 a much better description of that branch
Re: Serial port Connection
Hi all, sorry for joining in the party late ... but hopefully not too late. Regarding making the serial port part of the connection string ... I have to admit that right now I couldn't imagine how to not have it in there and not over-complicate things for the users. Yes, if you create a connection this will have exclusive handle to the port, but this is actually an important thing to have. In contrast to network devices that can handle multiple connections in parallel ... a serial port is ... well ... serial. Havin asynchronous access to one serial port from multiple areas in an application sound like a bad Idea. However you could always use the connection pool ... in this case the pool would have one connection open and could share this (serially) with multiple parts of an application. Here a part would request the connection, do its work and then give the connection back to the pool where another part of the application could use it. This way I think we have the ideal tradeoff between sharing a connection and not having to be concerned about breaking the serial operation of the serial-port communication. And yes: We could use some documentation on the connection pool ... and the scraper ;-/ Perhaps I'll whip up a little documentation on the connection-pool as I just recently had to find out how to use it myself ;-) Chris Am 25.06.20, 11:41 schrieb "Julian Feinauer" : Hey, yes, its in the module scraper or plc-scraper. Its easily configurable by yaml, json or programmatically. Julian Am 25.06.20, 10:30 schrieb "Niclas Hedhman" : Thanks Another question; is there any "loop" system that just continuously reads until I tell it to stop? On Thu, Jun 25, 2020, 15:16 Julian Feinauer wrote: > Hi Nic, > > I have to dig in a bit later to give you good answers but AFAIR the > connection can be left open and configuration should be as you wrote it. > I also did some tests with it but that was some months ago... > > Hope to have some more information later. > > Julian > > Am 25.06.20, 05:58 schrieb "Niclas Hedhman" : > > Hi, > IIUIC, the connection string for Serial Modbus would be something like; > > modbus:serial:/dev/ttyS0?unit-identifier=7 > > assuming I want to communicate with device with address 7. > > That would mean that I have one connection per device I talk to over a > single serial port. Is that correct? (Personally, I would not made the > device part of the connection abstraction, but realize that it is a bit > late for that) > > Are there any issues here, regarding which connection has access to the > port, or do I need to open and close the connection on each set of > messages? > > Couldn't find info about this in the documentation. > > > The serial port page is missing information on the configuration (data, > parity, stop,...). The source code doesn't have the > @ConfigurationParameter > annotations, so will they still work or do I need to add that > programmatically somehow? > > > Cheers > Niclas > >
Re: [VOTE] Rename our "master" branch to "release"
+1 Lukas Am Mo., 29. Juni 2020 um 09:10 Uhr schrieb Christofer Dutz < christofer.d...@c-ware.de>: > +1 (binding) > > Chris > > > Am 29.06.20, 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: [VOTE] Rename our "master" branch to "release"
+1 (binding) Chris Am 29.06.20, 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: [VOTE] Rename our "master" branch to "release"
+1 Julian Am 29.06.20, 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
[VOTE] Rename our "master" branch to "release"
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
Update on the PLC4C initiative
Hi all, As I was able to finally finish the initial code-generation for PLC4C last week, starting this week I’ll be concentrating on the things we considered SPI in the PLC4J module. I guess the first things will be the ReadBuffer and WriteBuffer and then I’ll have to come up with some base-classes that provide the core driver functionality … just try doing this without classes ;-) … I really hope this is not going to be equally challenging as the code-generation. Chris
Personal update ...
Hi folks, the last few weeks showed a little less activity here, especially from me. Now’s the time to give you an update on what and why. Last Friday I officially had my last working day at codecentric. The problem is, that the progress of the project and the adoption of PLC4X in the industry seems to be good. We can see from some of the domain names on this list, that a lot of big companies are experimenting with PLC4X or even already using it. codecentric had been paying my for the past 4 years to work on PLC4X almost full-time. Of course they were hoping on some consulting work. Unfortunately the amount of consulting work we got could not by far cover my costs. So at the end of my research-semester starting October I would have had to decide what to give up … my work on PLC4X or my job at codecentric. I guess you now all know how I decided ;-) So no worries … PLC4X will remain my biggest area of contribution. So I decided that I’ll be going back to self-employment, but as I know that one-man-shows don’t take off, I’ve joined forces with Julian’s PragmaticMinds and we’re trying to lift training and consulting services around IoT open-source projects to the next level. On https://industrial-opensource.com you can have a look at what we have planned. But all the changes behind the scenes consumed about all of the additional cycles I had. Hopefully this work is soon done (My companies logo and website will still be updated … so please don’t judge it by its current state ;-) … that’s actually about 10-12 years old and will hopefully be replaced in about a week ;-) I won’t be going into details on this too much as I don’t think that commercial offerings should be discussed on an open-source-project list … if you want information, just contact us. So-far the update. I just wanted to tell you all what’s happening. Chris
