Hi Stephen, Regarding the name ... we could Name it Cache (which is technically more correct) but we add in the JavaDoc that it's sort of a special ConnectionPool and perhaps add a page to the website which also mentions that, so someone coding with google, can find it. I'm happy with that.
well admittedly we spaced out the "programming" part in PLC4X till now (unless you can do that via normal write operations (Which I sincerely hope no device allows). My first reason to not allow this, was that I knew how unsecured these boxes are and I didn't want to have script kiddies write stuff for ruining hardware. The other is that this is where I have seen things go down proprietary road everywhere. So, we would probably need to support programming for all different automation systems, which I wasn't planning on implementing. So, consider PLC4X a pure data reading/writing tool. Who knows? Mabe one day the industry wakes up and funds projects like this and we'll add a "Programming API" which would be cool for some "Continuous-Delivery"-like features. Or someone wants to implement this ... but I guess till then, I'll not touch that ;-) But geeee ... hopping from USB to serial to network sounds pretty complicated, but I understand why this might be supported. I think for stuff like this we'll really have to play with the transports and extend the driver contexts to support that. But I think we generally need to do this more. The S7 driver currently tries to identify the remote device, based on its serial number. It also currently stores this in the context. So in general the driver could access this information and react differently. For example the S7 driver could return in the MetaData that it supports subscriptions, if the device is a S7 400 or one of the devices Cesar is working with, but say that it doesn't if it's one of my little 1200 or even a LOGO. Same with the "long" types like "LINT", "LUINT" and "LREAL", which not all types support, we could then switch to byte-based access in this case. But that's fine-tuning we would need to add over time, I think. But the same could be done for different transport variants. Chris -----Original Message----- From: Stephen Snow <[email protected]> Sent: Freitag, 21. Januar 2022 13:55 To: [email protected] Subject: Re: [DISCUSS] What should the "Connection Pool" be named? Hello, On Fri, 2022-01-21 at 11:35 +0000, Christofer Dutz wrote: > Hi all, > > in the past we had a "ConnectionPool" ... but in reality, we don't > have a pool of multiple connection to one target, like in databases, > but usually we have only one connection to each source in the "pool". > But we can have multiple connections to multiple targets. > > I guess that's why Julian named the new version of the Pool > "Connection Cache". This sort of comes closer to what it technically > is. > I don't mind use of either name, personally, but if you have a good reason for naming it a cache, that should be documented and explained why (we) feel it is more suitable. This should cover some implementation details too I would think. > So now the question is: How should we generally name this thing? > > I would opt to stick with ConnectionPool despite it being more a > ConnectionCache. The reason for this is that people looking for > something with the functionality, will probably start looking for a > ConnectionPool and not a ConnetionCache. I think the inside nature of > the component is more a context-detail and we should rather provide > people with what they intuitively would look for. > > But I would like to hear your thoughts on this. > > Chris To put another wrinkle in this conversation. PLC's and HMI products that hang on Industrial networks such as all of these wonderful ones we are talking about, but let's take EIP. I am going to cite an example of my work day. Customer calls, says "Hey Stephen, can you come over and look at my FilberFlanger, it's not meshing my grapple grommets?" I say "Sure, be right over." Pack up my PC and interface goodies to go see what's the matter. I want to connect to the PLC and watch the process while connected, live debugging. But the main panel housing the PLC actually is inside of the Machine guarding and unreachable without special safety interlock defeating. However, there is a connected HMI on a serial network I can connect to with USB on it's programming port. So my programming software for the PLC is now connected through a network bridge in the device (HMI panel) from my USB eventually to the EIP network the PLC is on. This is termed "jumping" by Rockwell, and most PLC's and HMI products they sell will accomodate it. They (Rockwell, and others I noticed) will usually only offer this through the use of a more advanced driver, normally referred to as "enterprise" or some such. Which finally brings me to my point on drivers, there may need to be different types considered, as in their expected capabilities. So a direct connect driver should be the simplest IMO, usable in most IIOT use cases where you are making a device to "hang off" a PLC EIP or other open network, like a "smart IO sensor", etc... even for a lot of the PC based uses. For multiple connections and larger networked application building it would likely be more appropriate to look at a server role for the driver. The Rockwell micro plc I am playing with now can handle up to 16 simultanious connections on TCP/UDP with either Modbus and EIP for example, and it is just a small guy. But it will only allow one port ownership (which ownership is meant for the programming role). Regards, Stephen P.S. if you need some testing for pooled connections to a PLC on a Modbus or EIP network I can help.
