How does DurationSinceLastTVQ resolve the 'last TVQ' in periodic/subscription Event jobs?
Is there any documentation that explains exactly how DurationSinceLastTVQ determines the `last TVQ` when used in periodic or subscription Calculation/Event jobs? I am trying to create a batch event that starts when a counter begins incrementing and ends after the counter has stopped changing for N number of seconds. The tag does not reset to 0 until the scale is tared, so I cannot use value = 0 as the event end condition.
I would expect when using the DurationSinceLastTVQ function, it would return the elapsed millis since the last real stored value/quality change for the tag.
I am seeing the function return results that appear inconsistent, and it seems like the function may be using an `Extended` good value at the calculation/evaluation rather than the actual last `Real` stored TVQ.
When repeatedly clicking the Evaluate button, DurationSinceLastTVQ oscillates between ~10,000–~58,000ms, but occasionally returns what appears to be the correct value (57,948,295ms) before dropping back down. If the function were using the last `Real` stored TVQ, I would expect it to consistently return ~57948295ms counting up every time the Eval button is clicked.
I am using v26.2.0.26099
Questions for the group;
- Does DurationSinceLastTVQ use extended/interpolated values when evaluating a tag at a periodic calculation timestamp?
- If so, is there a way to force it to use only the last real stored TVQ?
- Is there a recommended pattern for ending an event after N seconds of inactivity following the last real value change?
- Is there a way to preserve the actual last real TVQ timestamp as the recorded event end time, rather than the evaluation timestamp?
The goal is for the event to end based on inactivity after the final real counter update, not when the tag eventually resets to 0 for the next batch.
2 replies
-
Hi ,
The DurationSinceLastTVQ function bases its value on the last real update, not a time-extended value. It only makes sense to use this with a periodic evaluation trigger as a subscription trigger would always return 0. With that being said, I'm assuming you need the start trigger to be subscription-based. If that's the case, you'll need to split this across two events because you cannot mix modes. The first event would be subscription-based and the second event would be a child and it would periodic. See my example below:
1. Parent Event (Subscription)
In this event, the start trigger is based on the tag exceeding a certain value. (The DurationSinceLastTVQ is not as intuitive here, but it prevents this event from reoccurring back to back.) This event does not end until its child event completes.
2. Child Event (Periodic)
This event doesn't start until the parent starts. It concludes when when the tag hasn't received an update in the last 5 minutes (or 300000 ms). It checks every 5 seconds.
We don't have a way to use the last value's timestamp as the end timestamp for the event. That has to be when the event actually ends. Hope this helps!
Print this page