Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Latching triggers skip first event
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
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
Software Geek Extraordinaire
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.
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
Software Geek Extraordinaire
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.
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
Software Geek Extraordinaire
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 ;-)


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

Forum Jump:

Users browsing this thread: rbroders, 1 Guest(s)