The VI Ctrl Val.Set Property

[SercoSteveB]

One to finish the theme.....

Assuming initial values for Action Button and Stop Button of FALSE.  The following VI is executed, the user performs a left mouse click and release on the Action Button.  Which of the following most closely describes the result?

a) The value of the Stop Button is set to TRUE and the VI stops

b) The value of the Stop Button is set to TRUE and the VI does not stop

c) An error is generated and the VI does not stop

d) An error is generated and the VI stops

[mini09]

I hope the ans c is close to the all the rest of the options.

[Calvin_Fernandez]

hi everyone....

the answer is A.

[Eddie_Rickey]

I agree with Calvin..B

[LukeT]

I believe it is also A

[CMal]

The answer depends on the mechanical action of "Action Button".  Also, if the VI has not been saved then the answer will be C.

[SercoSteveB]

Nice one CMal and welcome; I can't see how changing the mechnical action modifies the answer, can you explain?

[CMal]

Here's what I'm seeing with different mechanical actions:

"switch until released" or "latch until released": Stops the VI the first time the button is pressed.

All other mechanical actions: Stops the VI the second time the button is pressed.

I guess this doesn't really alter the answer too much, but I would say that for the case where you have to press the button twice the answer would be "e) The value of the Stop Button is unchanged and the VI does not stop."

[BenoitP.]

Indeed, if the VI is not save on the computer ...  the ans is C because the OPEN VI Reference return an error. It can't open an Reference of a VI that doesn't existe ...

To me this kind of question is not realy interesting to understand the way of labview programing :S

If we considerate that the VI is saved on the disk, well the ans a).

[Mantesh]

If we save the VI Ans is b. without saving the VI it will generate the error & it will not stop. & hence the answer is c.

[SercoSteveB]

I think it is safe to assume that if not stated in the question that the VI is saved.  Having said that; I hadn't considered that Open VI Reference would generate an error if the VI is not saved.

I am slowly catching up CMal. If we set the mechnical action to 'switch/latch until release', an operation of the Action Button generates two value changed events, the second of which stops the VI.

[ManjuG]

Ans is A

[Ajay_MV]

Is there any answer sheet for this question instead of comments from reader?

[jfischer]

I’d say the answer is B.

Note that there are (at least) two distinct threads of execution within the WHILE loop: the EVENT STRUCTURE code path is one thread of execution, and the "STOP button + WHILE loop conditional terminal" code path is a second/distinct thread of execution. With this code construction you cannot determine before the VI runs which of the two threads of execution will run first. (n.b. In this particular code example, it doesn't actually matter which thread runs first; the outcome will be the same regardless of which thread is invoked first.)

Consider what happens when the VI is invoked and control enters the body of the WHILE loop. Let’s assume the scheduler invokes the “read the STOP button thread” first. Presuming the STOP button’s initial state is FALSE, the WHILE loop’s conditional terminal receives this FALSE output value as its input value(*). The scheduler now puts this tread to sleep because it must wait for the remainder of the code in the WHILE loop to finish executing before it can process the WHILE loop’s “Stop if True” conditional terminal. Now that the first thread is sleeping, the scheduler invokes the second thread of execution—i.e., the EVENT STRUCTURE thread. The VI registers its “Value Change” notification event handler for the “Action Button” control, and then it too goes to sleep while it waits for this event to occur. When the user eventually left-clicks (with the mouse) and releases the “Action Button” control, the button’s value change (FALSE->TRUE) is latched when the mouse button is released, and, consequently, the scheduler wakes up the sleeping EVENT STRUCTURE thread which then processes the contents of the “Value Change” case/event--i.e., the value TRUE is assigned to the VALUE property of the “Stop Button” control--and now this thread of execution is done executing. The scheduler now wakes up the first thread to process the WHILE loop’s “Stop if True” condition terminal, which receives the previously-obtained FALSE value(*) from the "Stop Button" control. Therefore, the WHILE loop does not stop at the end of the first iteration. This sequence (or the sequence below) occurs one more time, and during the second iteration of the loop the STOP button's TRUE value is fed to the WHILE loop's conditional terminal, and the loop exits at the end of the second iteration. This example corresponds to outcome B.

Now let’s consider the other possible scenario where the scheduler invokes the EVENT STRUCTURE thread first. As before, the VI registers its “Value Change” notification event handler for the “Action Button” control, and then the thread goes to sleep while it waits for this event to occur. The scheduler now invokes the “Stop Button” thread, reading and saving the button’s FALSE state before putting that thread to sleep, too. When the user left-clicks and releases the “Action Button” control, the sequence of events is the same as described above: the scheduler wakes up the EVENT STRUCTURE event handler thread; the event handler thread sets the STOP button's value to true and the thread terminates; the scheduler wakes up the WHILE loop’s conditional terminal thread, passes it the FALSE value that was previously read from the STOP button, and, consequently, the WHILE loop does not stop at the end of this first iteration. This sequence (or the sequence above) occurs one more time, and during the second iteration of the loop the STOP button's TRUE value is fed to the WHILE loop's conditional terminal, and the loop exits at the end of the second iteration. This example corresponds to outcome B.

If outcome A is required, one must implement the code such that the scheduler always invokes the EVENT STRUCTURE code thread before the STOP button's value is read--e.g., using a sequence structure.

[SercoSteveB]

Sorry AjayvigneshMV no answer sheet, just the opinions of readers.

[SercoSteveB]

Hi jfischer, welcome to 'The Daily CLAD'

You now own the record for the longest post....congrats.

Nice post;  I have often wondered about how LabVIEW deals when there is a lack of dataflow between code in a While Loop and the Stop Condition.  I had assumed and accepted that LabVIEW deals.

What you have posted certainly makes sense, is it your own opinion or learnt on a course?  Can you back it up with a link to ni.com?

[Ajay_MV]

Hi jfischer.  The loop runs only once even if i tested it many times in my PC.  i.e., the iteration counts in the loop gave 0 count all the time.  Even in bulb mode, i find that it run only once.

[jfischer]

I'm curious: which version of LabVIEW are you using, and on which OS platform are you running LabVIEW? I'm using LabVIEW 2009 SP1 (32-bit) and LabVIEW 2010 SP1 (32-bit) on some 64-bit Windows 7 Enterprise PCs (some desktop PCs and one tablet PC). On those systems the runtime behavior of the SercoSteveB's example program is exactly as I described above. Here's a YouTube video I made that demonstrates this:

Like my original reply (see above) this video is a little long-winded; sorry about that.

FWIW, I've seen cases before where a given LabVIEW program has different runtime behaviours on different computers--i.e., different versions of LabVIEW, different operating systems, different hardware, etc.--so I'm not doubting your statement.

[Ajay_MV]

jfisher.  I have the same Labview 2010 SP1 32bit, Win 7 Proffessional on 64 bit PC. You can find in the video below that the while loop runs only once.  When tried to debug it using probes and breakpoints as you done in your video, then the loop runs twice.  I think, the logic you suggested is working only in the debug mode.

Thanks,

Ajay.

[jfischer]

Interesting, Ajay. On my systems the execution sequence is as I showed in my video (i.e., two passes through the WHILE loop) for both the original code and my slightly modified "debug" version of the code. On your system, for the non-debug version, the "Stop Button" value apparently is not being read until after the "Action Button" value change event occurs and is handled.

For what it's worth, in my video I now see something strange that I didn't notice before. When the body of the EVENT STRUCTURE executes and the value TRUE is assigned to the "Value" property of the "Stop Button" control, on my VI's front panel window the "Stop Button" control does not visually change states from FALSE (unpressed) to TRUE (pressed); visually, it remains in the FALSE (unpressed) state even though the value TRUE has been assigned to the control. This also occurs when I run the modified version of the program shown below--i.e., when I left-click (i.e., click and release) with the mouse on the Action Button, the WHILE loop runs once and then the program terminates, as expected with this version. However, after the program terminates, on the front panel, the "Stop Button" visually remains in the FALSE (unpressed) state, even though its Value property must actually be set to TRUE as evidenced by the WHILE loop terminating after only one iteration.

[Ajay_MV]

So, jfischer.. Which answers can we stick with.. Is that both A and B are correct answers...

[jfischer]

I think you are correct, Ajay; answers A and B are possible outcomes for this program. When I first thought about this program I obviously didn't consider the possibility of the EVENT HANDLER code path running to completion before the Stop Button code path begins execution, which corresponds to answer A.

[ramesh44]

A

[mohamedtanveej17]

If we wire a vi server reference to open vi reference means what will happen?