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

Reply via email to