Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Latching triggers skip first event
#1
Okay Dean, this one took a while to track down, but I'm pretty sure this is what is happening. (non-serialized event execution probably not causing my mystery problem)

When Bidirectional triggers get started no event is sent for the first threshold crossing.

Here is my test: Field is BedHallWatts Normal value 0.  I create a bidirectional trigger IsGtThan 5 and turn on a lamp.  Value -> 39, but no event is sent!  I shut off lamp.  Value -> 0; event sent.  Thence it works perfectly: event is sent for both on and off transition.

Delete/recreate the trigger or pause resume the driver (or the app shell), and it will again fail to send an event on the first transition.  Ugh.

Note: when I create an unlatched trigger it seems to work fine - i.e. it catches the very first transition from 0 -> 39 and sends an event.  When the lamp power wobbles a bit I get some 38 and 39 events and then it gave me a 10 during shutdown and no event when the lamp hit zero (as you would expect since 0 NOT IsGtThan 5).

Note2: I tested this with Unidirectional triggers and the behavior is identical.  The first transition does not send an event, but subsequent transitions do.

Thanks -- Bob
Reply
#2
The first value set on the field doesn't cause an event, because I have no idea what it was before then. People complained about how it used to always send a trigger just because the field got its initial value, which most everyone considered a bogus trigger, and because it could create a big blast of triggers on system startup, and often the things they are supposed to operate on aren't ready and so forth.

It's a hard thing to make everyone happy in this case.
Dean Roddey
Explorans limites defectum
Reply
#3
Yeah, I can understand suppressing triggers on the first value set on the field (i.e. shortly after the driver starts).  Maybe even whenever the field comes out of error state.  Not sure though: you could miss an important transition.  fldchange events don't have oldval or anything else to help decide if it is a nuisance event or not...

I think there is something else going on here though because this is *not* the first value set on the field.  The driver is up and the field is in steady state with a value of 0.  It may be hours or days before the value changes (in this case to 39), but the first event is *still* being suppressed.  That's not right.

This also happens when you define a new latching trigger on a field that has been up and running for a long time.
Reply
#4
So it's been up for a long time, but this is just the first time the field value has changed? If that's the case, I'm guessing the initial value just isn't setting the latch state, so that it doesn't think it needs to do anything the first time.

For defining a new trigger, I would definitely think so. Setting a trigger doesn't evaluate the current value at that point, the latching stuff only evaluates changes and the current value when it's set isn't a change. That could be done, assuming there's nothing bad going to happen if we did that. I can't think of anything.
Dean Roddey
Explorans limites defectum
Reply
#5
Well, defining a new trigger is a bit of a corner case, but yeah I think it should evaluate the current value so it is ready for the first transition.

So the first value doesn't set the latch state is true (and ok for purposes of eliminating unwanted startup events).  The problem is that it also ignores the *second* value which *does* set the latch state.  This kind-of makes the whole trigger system unreliable.  Ugh.
Reply
#6
Yeh, I can see that getting the first value should at least prep it for the next transition. It's trying to remember if it already has been on this or that side of the limit, and don't change the state until it's transitions. But, the first value should probably set it as though it transitioned to that side, but not actually send a trigger I guess. That'll let it send one if the next value goes the other way.

I'll have to see how practical that is.
Dean Roddey
Explorans limites defectum
Reply
#7
Yeah, that sounds ideal. Events are suppressed on the initial field value set, but the trigger figures out its current state and is ready for the second value to possibly push it to another state and send its event.

Hopefully not too difficult to implement...

I have a ready test case ;-)

--Bob
Reply
#8
OK, it looks like the issue is that, when you set a trigger on the field (or modify the existing one), the latching state gets set back to 'first' state, which is used to ignore the first evaluation of an incoming value and avoid a bogus trigger. But, by then, we've already evaluated that first value most likely. If we haven't then it's still in 'first' mode and we are fine. If we have, then the latching state has been kept up to date even if not being used, so we should be able to keep it as is.

So I think I just need to stop resetting the latching state when an expression is set.

Otherwise, I can't see how it would ever actually miss a transition, unless the field went into error state and that forced us into false state, and then it came back out and was in false state for the next change. Something like that maybe.
Dean Roddey
Explorans limites defectum
Reply
#9
(01-14-2019, 11:35 AM)Dean Roddey Wrote: Yeh, I can see that getting the first value should at least prep it for the next transition. It's trying to remember if it already has been on this or that side of the limit, and don't change the state until it's transitions. But, the first value should probably set it as though it transitioned to that side, but not actually send a trigger I guess. That'll let it send one if the next value goes the other way.

Have you made this change?  I think it will solve my problem, which is something that transitions very infrequently: about once a week.  My CQC system has been bouncing around a lot (Windows Update, CQC Beta Versions, Driver Development), and it is constantly missing the transition which ends up being the second value (the first change) after some type of restart.

I am not changing the trigger in my problem case, but during the test case I was creating triggers and pause/resume the driver.  Do I need to do a full appserver restart to properly test this?

My field is not going into error state either, unless driver restart is considered error state.  Error state feels like "no value available" to me, so I would vote no event send and no change to latch state.  When the field comes out of error state if new value changes latch state, send trigger otherwise pretend nothing happened.

If you can fix the problem for new/modified triggers that would be great as well!

Thanks -- Bob
Reply
#10
It looks like, as best I can tell, that it's always keeping the transition state up to date, at least if there is a trigger defined. It probably doesn't call the evaluation thingie if there's no trigger, since that would be unneeded overhead. So I may need to add an initial call to that upon setting a brand new trigger perhaps.

Anyhoo, I was just sitting down to test this some, to see what I can see.
Dean Roddey
Explorans limites defectum
Reply


Possibly Related Threads...
Thread Author Replies Views Last Post
  Event Monitors Dean Roddey 39 18,527 10-12-2015, 05:19 PM
Last Post: Dean Roddey
  RunTmplAction in OnLoad event of template? SamVimes2 5 2,918 09-08-2010, 05:00 AM
Last Post: froop
  change request for event code dialogs... bjkiller 4 2,428 04-07-2010, 02:10 PM
Last Post: bjkiller
  Bind a checkbox to an event's state? SamVimes2 1 1,661 02-13-2009, 06:39 PM
Last Post: Dean Roddey

Forum Jump:


Users browsing this thread: 1 Guest(s)