LabVIEW
Wait timer "challenge"
I am asking this "challenge" question because I am having doubts about a long held conception of mine re: how the Wait Timer in LabVIEW (Windows) behaves.
Look at the attached .jpg. The prize winning question is:
Do Output A and Output B turn on and off:
A) At the same time
B) In opposition to one another
C) It depends
My answer would normally be C, but I wonder if that is really true. We know how the Output B loop will behave, but can we tell without running the VI how Output A will behave? And once we compile and run the vi and observe the results, are we still 100% sure it will ALWAYS behave that way, no matter what PC we run it on and even if we build it into an executable file?
P.S. the "prize" is that I buy the winner a beer, redeemable anywhere within the city of Los Angeles.
Message Edited by Garvacious on 10-21-2005 05:52 PM
Message Edited by Garvacious on 10-21-2005 05:55 PM
The answer is probably very close to B.
Since there is no data dependency between the wait statement and other structures in the loop in the upper case, they all will execute roughly at the same time. It does not matter if the wait or the display update starts first, they will all start within "nanoseconds" of each other and the changed LED will be updated to the new value. (The NOT will execute after the display update, so it will not have any influence in the current iteration). The wait statement is not blocking anything that can go on in parallel, it will only prevent the loop from finishing because it will be the slowest node. Dataflow dictates that a frame can only finish once everything in it is done.
In the bottom case, the update of the LED is delayed until the first frame finishes.
Message Edited by altenbach on 10-21-2005 04:08 PM
Well, Christian, if you are still living in Venice I suppose I'll have to honor that prize 
Anyway, I was never quite clear on whether or not that function behaved synchronously within a given loop, i.e. forced all the other code in the loop to wait while it was executing regardless of data dependencies- versus executing in parallel with other code in the loop. I'm not sure why I ever got that impression but it was a misconception I had for a long time.
Ab has a good point- the second frame of the sequence structure probably adds a small amount of execution time, making the loop time something like 1.000001 sec. Thus, if you left it running for hours it might eventually phase out of sync with the other loop.
@Garvacious wrote:
Well, Christian, if you are still living in Venice I suppose I'll have to honor that prize
I'll be at the NI Technical Symposium tomorrow (Oct 25th) in Irvine. If you're going, maybe we can have a toast with some of the fruit punch! 😄
