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, >> >> If we were to let the server control a minimum rate for change of >> 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); >>>> >>> >>
