plc4x-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christofer Dutz <christofer.d...@c-ware.de>
Subject AW: [DISCUSS] Minimum sampling interval on change of state subscription
Date Mon, 08 Mar 2021 12:08:24 GMT
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 <ott.lukas.14@gmail.com> 
Gesendet: Montag, 8. März 2021 12:58
An: dev@plc4x.apache.org
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 <
ben.hutche@gmail.com>:

> 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 
> <christofer.dutz@c-ware.de>
> 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 <luke@code-house.org>
> > Gesendet: Montag, 8. März 2021 11:08
> > An: dev@plc4x.apache.org
> > 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);
> > >
> >
>
Mime
View raw message