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); > > > > > >
