plc4x-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andreas Vogler <andreas.vog...@me.com.INVALID>
Subject Re: [DISCUSS] Minimum sampling interval on change of state subscription
Date Mon, 08 Mar 2021 12:37:55 GMT
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 <christofer.dutz@c-ware.de> 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 <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