I will just add some of my experience with both older and newer PLC's. First when I am referring to 'older' it generally means PLC's made prior to the advent of object oriented control architecture that is being employed by such OEM's as the current Siemens, Rockwell, Modicon controllers which can have complex data structures that combine most if not all primitive datat structures as well as user defined ones. These are the 'newer PLC's and they have better communication handling capablities as they were designed for this purpose. Irrespective of the age though, in most cases communication is divided into different priorities by the PLC itself, an example would be when a programming terminal is connected to it, that terminal effectivley owns the PLC at that time and it's communication will bump less important comms if required to satisfy scan time limits. What this implies is that if you are 'testing' a connection to the PLC for your data collection purposes while having a programming terminal connected, be aware that the results are affected by the terminal connection. Also, commonly on the control network, there will be operator terminals (HMI's) for the operation of the equipment locally, these gain access to memory location in the PLC and usually are setup to only look for change of state to make writes/reads. This ability has been present across all OEMs and HMI OEM's for a couple of decades at least (and longer with some). SCADA has been around for a very long time, and again, the proprietary drivers that used to be the path to connecting your PLC to your data aquisition system were the ones to choose, because they worked, just not always as flexibly as you liked. Products like WonderWare, WinCC, RSView, etc all do this without substantial overhead increases on the network or for the PLC, although at a premium based on tag databsae size usually. From my Rockwell Automation Systems Special days I know that their drivers they employ sit pretty low on the OSI layer model and they use an ABI as they term it to provide connectivity for user applications, at least this is how it was done in the mid 2000's. So OEM driver ---> OEM ABI(API) ----> User created app. This is all harware dependant to some degree, but there are processor status bits you can monitor to determine if there is a change of state on IO, in some PLC's this is correlated directly to specific IO areas, but I cannot say this for all of them since my experience only covers Siemens, Rockwell, Omron, Reliance, Allen-Bradley, Mitsubishi, Modicon, ABB, and some now extinct types.
So with systems I have encountered and those I was involved in the design on, I can say that polling was used for non control critical data manipulation, so production data, logging data, basically nothing that actually has any direct control fucntion. Anything that needed to be reactive or active in the control strategy needed to be update on change of state. Again, modern PLC's have come a long way and now you can access memory location directly, even in modbus RTU networks. The big OEM's such as Siemens Modicon and Rockwell use this IO has changed state capability in their processors for thid purpose. Also, my understanding of accessing the IO memory locations directly is if you write a one into an output for instance, the PLC program will still overwrite the value based on the program state regardless. So to time stamps, which have been used ad nausium since we have been connecting to PLC's to get data from the plant floor up to the ERP. Usually, if the data collection system is the communication master, then they applied a time stamp to the log activity for that data point. This was necessary since very few PLC's had an RTC at first, and those that did were very rarely connected to an NTP server like the data collection system was. I would suggest, without fully looking at your PLC4X code, that you make a timestamp function/method that applies the time stamp outside of the driver, if the PLC has a RTC like most do nowadays, try to link it to the network NTP server if possible (usually security implications here) but I would be reluctant to rely on ther PLC's idea of the time, per se. Just some thoughts your conversation is provoking in me. Good luck! Stephen On Mon, 2021-03-08 at 13:37 +0100, Andreas Vogler wrote: > Hi, > I have not really read all details of your mails …. just my personal > opinion: for a subscription I would expect that I get every single > change of value (what the source is able to deliver to me) ...if this > will potentially flood my client then I have to take care about it… > and start to think about back pressure strategies … or set a > subscription interval to bigger than 0 (if possible, like it is with > OPC UA )and be aware of possible lost value changes… But it is just > my personal opinion. I mostly work on top of SCADA & event driven… > and sure, here we are on the edge between polling/plc and event > driven architectures (pub/sub)... > Andy > > > On 08.03.2021, at 13:08, Christofer Dutz > > <[email protected]> wrote: > > > > Hi all, > > > > But I would probably assume a sensible default but make ich > > changeable on a per-connection basis. Not on a per-request or even > > per-field. That would simply be a bit too much, I think. > > > > Chris > > > > -----Ursprüngliche Nachricht----- > > Von: Lukas Ott <[email protected]> > > Gesendet: Montag, 8. März 2021 12:58 > > An: [email protected] > > Betreff: Re: [DISCUSS] Minimum sampling interval on change of state > > subscription > > > > Hi, > > > > concerning limiting the data rate is a really valid point as the > > newer PLCs are doing exactly that (e.g. they have a Data collector > > and Data Processor included - and we did exactly that as well with > > some IIoT sensors that we collected and processed the data directly > > on the microcontroller) - as the older ones are not build for > > sending data - it would be quite helpful to configure a timer but > > one second may be too long as default value > > > > Best, > > Lukas > > > > Am Mo., 8. März 2021 um 12:49 Uhr schrieb Ben Hutcheson < > > [email protected]>: > > > > > Hi, > > > > > > state subscriptions then we could overload the client. > > > > > > I think allowing a value of 0 would be a good idea in case you > > > really > > > do want to capture every change even if it is incredibly fast, > > > but > > > still defaulting to 1s. > > > > > > Ben > > > > > > On Mon, Mar 8, 2021 at 5:20 AM Christofer Dutz > > > <[email protected]> > > > wrote: > > > > > > > Hi all, > > > > > > > > yeah ... I wanted to say something to that too: > > > > > > > > Change of State shouldn't have a sampling interval (Perhaps a > > > > min > > > interval > > > > to prevent flooding an application with too many updates) The > > > > use > > > > case seems a bit like a polling use case and we have a separate > > > > set > > > > of subscription properties for that. For polling, there should > > > > be a > > > > sampling interval and that's even included in the API. > > > > > > > > If we are "simulating" a change of state functionality on a > > > > protocol, > > > that > > > > doesn't support this (like S7, Modbus, ...) we should have a > > > > generic > > > > property to control this sampling interval throughout all PLC4X > > > > drivers. > > > As > > > > I recall we currently don't have this subscription simulation > > > > layer ... > > > not > > > > yet ... > > > > > > > > Chris > > > > > > > > > > > > -----Ursprüngliche Nachricht----- > > > > Von: Łukasz Dywicki <[email protected]> > > > > Gesendet: Montag, 8. März 2021 11:08 > > > > An: [email protected] > > > > Betreff: Re: [DISCUSS] Minimum sampling interval on change of > > > > state > > > > subscription > > > > > > > > Hey Ben, > > > > I began writing this answer shortly after you sent your mail > > > > but > > > > eventually left it for a day or two to thing it through. > > > > Looking at API I believe we have three major cases: > > > > - polling/push interval > > > > - change of value > > > > - every value > > > > > > > > Looking at above change of value should not require any > > > > interval > > > > cause it should be determined by device we subscribe to. It > > > > knows > > > > for sure that value changed and should push an update to us. > > > > Same > > > > applies to event > > > field. > > > > For cases where we can specify update interval the first > > > > (cyclic) > > > > option is intended. I know very little of OPC UA so above might > > > > be > > > > not entirely valid in context of it. The real question is shall > > > > we > > > > fit OPC into our > > > API > > > > or our API into OPC. > > > > > > > > Looking closer at cyclic subscriptions we don't have a clear > > > > indication > > > of > > > > who does the time handling. Is it device (or server) who post > > > > updates > > > back > > > > to us at given frequency? Or we poll it given interval? How our > > > > API > > > caller > > > > will know who controls time? > > > > > > > > To sum all this - I would say that case you have seems to fit > > > > more > > > > into cyclic subscription than change of state. > > > > > > > > Best, > > > > Łukasz > > > > > > > > > > > > On 06.03.2021 13:06, Ben Hutcheson wrote: > > > > > Looking at the change of state subscription interface there's > > > > > no > > > > > explanation or way to modify the Duration parameter which > > > > > defaults > > > > > to one second. This is used in OPC UA as a minimum reporting > > > > > time > > > > > so will never report back faster than 1 second. > > > > > > > > > > What's everyone's thoughts on adding this as an optional > > > > > parameter? > > > > > > > > > > I thought about changing the default but I think 1 second is > > > > > a > > > > > good value for it. > > > > > I also think an absolute minimum value should be allowed of 5 > > > > > or 10ms. > > > > > > > > > > * Adds a new field to the to be constructed request which > > > > > should > > > > > be updated as soon as > > > > > * a value changes in the PLC. > > > > > * > > > > > * @param name alias of the field. > > > > > * @param fieldQuery field query string for accessing the > > > > > field. > > > > > * @return builder. > > > > > */ > > > > > PlcSubscriptionRequest.Builder addChangeOfStateField(String > > > > > name, > > > > > String fieldQuery); > > > > > > > > > > > > >
