Funny/odd event handling

[Dynamik]

Hi All,

      Ran into this really wierd bug - wasn't sure whether anyone might be interested.

An event producer loop (LocalBytesAtPort value-change) is throwing it's event, even though the Error-case is executing.

If the value-change-node is being called, the the bytes-at-port probe should show data, but it doesn't.  The error probe (from inside error case) is getting fresh values.  Yet event-loop is ticking over and handling value change at the same period as the value-change producer. 

I know this is cryptic, but I hit Post too soon    and have to explain it in a short time!

Cheers

P.S. There's supposed to be a 16color bmp, (bmp is only option) but can't post it!

Message Edited by Dynamik on 04-26-2006 11:57 PM

Message Edited by Dynamik on 04-26-2006 11:58 PM

[Dynamik]

... Paint is missing JPG option on this box, but "Imaging" provided it...

anyway, here's the pic.

Cheers!

[tst]

Well, that picture doesn't seem to be enough in helping to debug this issue (although I probably would have said the same if you posted it as 7.1), but the obvious thing to look for would be other places where the signaling event might be fired from. Other options include other events which are processed by the event structure and make that loop iterate.

BTW, BMP blocking is a good thing.

[Dynamik]

Hi tst,

Re: bmp blocking - at 16colors it was only 330K!

Anyway, I did look for other places the LocalBytesAtPort might be changed, but the FP indicator is only updated from one place - the producer loop via Value (signaling).  After messing with it, it started working - but what did I do?  I accidentally left a 11ms wait in the producer-loop!?

Re posting as 7.1, Looked over th VI to assess the damage (from missing VIs) if only top-level was supplied - not too bad...

To reiterate, [before 11ms timeout was added] the Error-case was executing every 1111ms, but Event handler was receiving a Value-change event for LocalBytesAtPort!

Leading-up to the error condition [w/out 11ms TO], there are several thousand Serial-Character VISA Events in rapid succession.  I had a problem firing notifiers with for-loops without a wait, maybe this is related...

Cheers!

[tst]

Well, according to your probe the No Error case wasn't executed, so I don't see any other way (at least in this VI) for the value change event to fire (which it did, according to your other probe). The only way I can see how this should happen (if it's not a bug) is either if it was fired from another VI or if your timing of placing the probes is off. Anyway, without being able to get the VI to work I don't see any way of being able to test this. I'm just glad you managed to get it working.

[Ben]

Could it be that you have many more events being fired than you thought and LV was just buffereing all of them?

If that is the case, the event structure will let you select the time of the event (in ms clock ticks) and that can be used to dispose of old events.

That is the only guess I can offer.

Ben

[Dynamik]

Hi Ben, tst,

Thanks for looking at it.

Thanks too, for tip re: [event] Time - haven't used it yet, but now that I know it's there...

Maybe event's do get queued, but these "faux-events" are triggering the consumer-loop at exactly the same frequency that the Error (time-out) case executes in the producer-loop, and the Value being signalled appears stuck at some specific value!(?)

Prior to the wierdness, we're watching the console output of a Linux OS booting, and the frequency of the serial events depends on that process.  10s of K-bytes scroll by causing (sans MS Wait) VISA Serial-Character events as fast as they can be detected and passed-on to the Event loop.  After the OS boots, the [console] output stops completely, though the events continue[d]!

It's OK for the user to wait an extra 100ms for test results and probably silly not to have restrained the update-cycle.  I'm gonna bump-up the delay, now that I think about it.

Cheers.