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 "soooo 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 <christofer.d...@c-ware.de> 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" <nic...@hedhman.org>: > > 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 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" <nic...@hedhman.org > >: > > > > 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 > > > > > > >
