Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Latching triggers skip first event
#11
OK, so the driver base class only calls the 'send field trigger' method if the field wasn't in error previously. This is part of the thing to suppress bogus initial value triggers. But, that means that the initial value never gets evaluated to set the latching state. So I changed it so that the 'was in error' flag just gets passed to the field storage object. He'll do the evaluation but not send a trigger if this is coming out of error state. But it gets the latching state correctly set on the first value.

There will still be a miss if the driver or field goes into error state, since the first value upon recovery will be 'who knows from where' type value and it'll still just be used to set the state, but not to generate a trigger.

Updating the trigger config shouldn't affect the current latching state (as per above), so that shouldn't cause a miss anymore either.

I haven't tested this yet, I'm rebuilding and need to grab some lunch. I'll test it when I get back and hopefully get a drop up later this evening.
Dean Roddey
Explorans limites defectum
Reply
#12
I have been testing this in 932 and it does not seem to be fixed.

There are two problems I have been examining: "when defining a new latching trigger the first state change doesn't send an event".  Also, the more important (to me): "for all latching triggers: when the driver pause/resumes or appshell/system restarts the first state change doesn't send an event".

It seems like the new trigger problem is fixed, but only after the first event for that field has been skipped (yeah, weird).  In my testing it seemed like it was not fixed at all, but as I deleted and recreated the trigger on my test field, it worked correctly.  Then I switched to a different field, and it broke again until the second try and then it worked.

The restart problem still appears to be broken, but I've expanded my test case a bit and its seems odd.
I attached a trigger to my ElkV2Dev driver for LogZone114 IsEqual Short.  This works perfectly (except for the first transition after creating the trigger).  I can restart the driver and it fires on the next transition (either Short or Open), and there are no extraneous startup events.

However, my original test case still fails on pause/resume!
The trigger is attached to RESMON#BedHall~Watts which is a Card4.  The trigger is IsGtThan 12.  When my lamp is off its value is 0 and when the lamp is on the value is 39-40.  If the lamp is on(39-40) when I restart the driver I get an event when the lamp turns off (and no extraneous events - perfect), but if the lamp is off(0) during restart I don't get an event when the lamp is later turned on (though it works fine after that).

Why?  It is possible it is working when the lamp is on during restart because the on value wiggles a bit (39-40) and that is enough to force the re-evaluation.  Hmmm.  

Perhaps because this is a Card4 field rather than a String field?  I notice that String initial value is blank but Card4 initial value is 0 (based on looking at the admin interface's driver page as the driver is starting up).  Maybe the Elk case is working because LogZone114 changes from "" to "Open"/"Short" on startup.  However, BedHall~Watts' first value is 0 (in the off restart case).  Maybe this is bypassing some code because the value doesn't get changed and the initial latch state is not being calculated?

Hmmm.  Sorry this is so long -- Bob
Reply
#13
It may be the case, yes, that if the initial value is the same as the default value of the field that it doesn't look like a change. It should, since it is transitioning from error state to good state. That should be considered a change no matter what the new value. I'll see what I see on that. It may be though that that's getting short circuited somewhere in the process, at least in as far as this trigger stuff is concerned.
Dean Roddey
Explorans limites defectum
Reply
#14
OK, so the issue was that the field storage objects are not marked initially as being in error. That means that they don't recognize the first value out of error state as a change if it's the same as the default initial value (a transition out of error state is always considered a change.)

I've changed that and it now always correctly gets the first change even if the initial value == the default, but it's a bit scary. That means that any drivers that never wrote values to fields would end up with the initial value. That won't be the case now, and those fields will show as in error. This could be a breaking change.

I may need to come up with some better, non-breaking, way of dealing with this, like a one shot flag on the field storage guy, so that it can know when the very first value is written.
Dean Roddey
Explorans limites defectum
Reply
#15
Ah, very interesting! I knew it had to be a smaller case than "all latching triggers". It just took a while to get down to "all latching triggers whose initial value is zero or blank".

Yeah, it makes sense that all fields are in error state until the driver writes values to them, but it may change things. Possibly put it into the betas for a while and see if anyone has a problem with it. Not sure if a lot of people are using the betas though...

I'll keep an eye out for the next build and give it a shot...
Reply
#16
Oh well, that's not going to work. Just testing some drivers and already seeing quite a few failures because of fields not having been written to initially.

I'm going to have to leave that for a future binge and just implement a 'first value' flag on the field values for this purpose.
Dean Roddey
Explorans limites defectum
Reply
#17
Oh, and of course that's another reason why a first change might not do anything. If the field ends up with a default value, then no value was ever written and so the trigger state won't be updated for that initial default value. What I'm changing won't help that, because it can only respond to values being written.

Just in general the issue of fields not getting their values set needs to be addressed, since it's not good. Crazy how much one little goober can create such a morass.
Dean Roddey
Explorans limites defectum
Reply
#18
I added a log msg to check, after a driver reports connected, if any readable fields never got an initial value. This can be used to start weeding these out, and then I can just move to an initial error state of true maybe in the next release.
Dean Roddey
Explorans limites defectum
Reply
#19
And, for those drivers that need to legitimately come back from connect without all their fields set, because the underlying system just isn't that sturdy to insure that, they can call a new SetAllErrStates to set all the fields to error state after registration. Then any that don't get set will be in an initial error state as they should be, and the next legit value will now cause a transition out of error state.

Anyhoo, this stuff should provide the tools to start getting drivers right.
Dean Roddey
Explorans limites defectum
Reply
#20
I used the simulator drivers to work out the above stuff and it seems to be doing fine. I got them updated to not have any unset fields. They are sort of worst case ones since they don't have any actual device driven fields.
Dean Roddey
Explorans limites defectum
Reply


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

Forum Jump:


Users browsing this thread: 1 Guest(s)