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: Source Time of PLC Value?
Date Mon, 08 Mar 2021 10:13:49 GMT
Hi all,

sorry for being late to the party ... KNX is currently consuming all my cycles.
Just wanted to add my thoughts to the discussion.

Initially I thought about adding this sort of information to the API, but then I thought that
we have so little protocols supporting this sort of concept that blowing up every PLCValue
with this time information just would waste CPU time and Memory.

When it comes to simulating subscriptions by polling in the background, I thought it would
be a valid solution to provide a default age a value can have in the cache and to make it
possible to override this in the connection string options. If a value is too old, a return
code of: STALE_DATA could be returned.

Also, we do have an option of adding an additional set of PlcValue types. If a driver supports
this quality-of-service type of data, we could return special versions of PlcValues, that
have these properties? 

This way we don't have to waste the CPU time and Memory for protocols that don't support this
concept (We could even implement the methods on the default PlvValues to simply return some
constants to the PlcValues all have the same API.

Chris
 

-----Ursprüngliche Nachricht-----
Von: Łukasz Dywicki <luke@code-house.org> 
Gesendet: Montag, 8. März 2021 10:43
An: dev@plc4x.apache.org
Betreff: Re: Source Time of PLC Value?

Looking at issue we could utilize marker interfaces.
At least in Java we could define Qualified and Timestamped types.

Yet looking at present state of API we are unlikely to make each and every PlcValue in each
and every variant (qualified and timestamped, timestamped, qualified). It would force quite
a lot of wrapping.
Safest option I see is to extend subscription/response API with additional method to retrieve
all markers. For most of drivers it would return just an empty set. It leaves us also an open
door for future drivers (or devices) to ship additional piece of metadata which does not fit
into present API.

Best,
Łukasz


On 08.03.2021 04:30, Otto Fowler wrote:
> So, maybe the extension is timestamp *and* timestamp source.
> 
> uint64_t timestamp;
> typedef enum {
> 	/* timestamp was generated by the source device */
> 	SOURCE,
> 	/* timestamp was generated by plc4x on receiving */
> 	GENERATED,
> } TimestampQuality;
> 
> 
> 
>> On Mar 5, 2021, at 18:04, Ben Hutcheson <ben.hutche@gmail.com> wrote:
>>
>> We do have some error codes, but it would just need to be extended a 
>> bit. I don't think we have one for BAD (we still receive data but the 
>> source has marked it bad).
>>
>> Timestamps I think are definitely a good idea, especially if we 
>> eventually DNP3.
>>
>> On Fri, Mar 5, 2021 at 5:39 PM Łukasz Dywicki <luke@code-house.org> wrote:
>>
>>> You have response code for each individual field which allows you to 
>>> determine state (OK, REMOTE_ERROR etc.). Same information should be 
>>> available also for subscriptions.
>>>
>>> Best,
>>> Łukasz
>>>
>>> On 05.03.2021 21:04, Andreas Vogler wrote:
>>>> Ah, forgot: and is there a status available? Valid/invalid/good/bad
>>> indicator of a plc value?
>>>>
>>>>> On 05.03.2021, at 21:02, Andreas Vogler 
>>>>> <andreas.vogler@me.com.INVALID>
>>> wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> How can I get the source time of a PlcValue?
>>>>>
>>>>> a) from a subscription PlcSubscriptionEvent
>>>>> b) from a read request  PlcReadResponse
>>>>>
>>>>> Best regards,
>>>>> Andreas
>>>>
>>>
> 
Mime
View raw message