wait for front panel activity continuing when false

[rrp4d]

I am trying to run a sequence in which the first panel sets up my instrument, the second one waits for the user to say go, and the third takes the measurements. I put a "wait for front panel activity" attached to a switch in the 2nd panel and set the switch to false (and probed it to double check the setting). Even when false and without toggling the front panel button, the program executes the 3rd panel. 

I tried removing the lines across the 2nd panel and moving the GPIB number to a constant in the 1st and 3rd panel so that they are not connected.

I attached a snapshot of the program.

What am I doing wrong?

Thank you!

[Mark_Yedinak]

I would get rid of the sequence structure completely. I would recommend you implement this using a state machine. It is much more flexible and maintainable. As written you cannot jump back to the wait state (second frame) if you wanted to run the program go back and wait for the user to start the next test. A state machine will allow you to do this very easily. You can also look at the event structure which is very useful for waiting on UI events.

The other thing to note about your VI is that if the value of the control is False you will not wait. I believe this is why your are immediately jumping to the next frame.

[Darin.K]

---

Mark Yedinak wrote:

The other thing to note about your VI is that if the value of the control is False you will not wait. I believe this is why your are immediately jumping to the next frame.

---

When Do Not Wait is False it will actually wait.  This issue here is that many, many things will generate Front Panel activity, any of them will cause the program to carry on.  Some simple options short of a full-blown rewrite:

Put a while loop around it with the control wired both to the while loop and the Do Not Wait Input.  See the Detailed Help of the WFFPA function for an example.

You could use a simple polling loop with a simple 100 msec wait which is stopped by the control.  All you are doing is waiting, so a little polling wouldn't hurt.

You could also plop an Event Structure there without a while loop which waits for a Value Change Event from the control.  I only do this if I also want a simple way to timeout as well.

[rrp4d]

I am trying to keep this software simple. I can try to figure out a case structure as it would be useful in the future. In the meantime though I need some results and "they" do not want me to do them by hand because they want them more evenly space. Is there a function that is like "wait until I toggle this button" with which I can replace the "wait for front panel activity" button?

[Darin.K]

[Mark_Yedinak]

---

@Darin.K wrote:

---

It seems strange that the loop is required in order to get the Wait to actually wait. One would think that simply the presence of this VI would result in the VI pausing. Given I don't use this VI I learned something today.

[rrp4d]

Thank you guys, this worked. 

And Mike, glad I could help you learn something. 

I will try getting this to work with a case statement when I have more time as it will be useful for future measurements.

[Mark_Yedinak]

The state machine would essentially be a case statement insude a while loop. In your case each frame would end up as a state. Logic within each state would allow you to select what the next state that executes. There are lots of posts and examples of state machines available but here is a very basic one which can give you an idea of how it works.

Note: The ENUM used in this example should be a typedef. It isn't in the example simply to allow a single file to be attached.

[Darin.K]

---

Mark Yedinak wrote

It seems strange that the loop is required in order to get the Wait to actually wait. One would think that simply the presence of this VI would result in the VI pausing. Given I don't use this VI I learned something today.

---

This is definitely one of those strange creatures that is useful in certain situations, but not too often.  I liken this function to occurences, useful in its place.  My Evil Twin has just come up with a nice CLAD question (maybe CLA-R):

Without running the code (be honest) how many times to you have to push the button to complete the following VI?

(I am totally willing to volunteer my services if NI would like some more questions for their exams.  <Evil laughter>)

[Mark_Yedinak]

---

@Darin.K wrote:

---

Mark Yedinak wrote

It seems strange that the loop is required in order to get the Wait to actually wait. One would think that simply the presence of this VI would result in the VI pausing. Given I don't use this VI I learned something today.

---

(I am totally willing to volunteer my services if NI would like some more questions for their exams.  <Evil laughter>)

---

You may get the opportunity soon. NI is considering a points program that will allow you to get recertified without taking the exam. One way to earn points is to submit exam questions.

BTW, the answer is it depends. As written it is twice. If there are other things that effect timing it can take more times. (I admit, I cheated and coded it up. If you turn on execution highlight it takes 5 presses. Therefore something weird is going on under the hood that is timing related.

Insert a frame in the middle of the two waits with a Wait (ms). As the time increases more presses are required. (I tried to post a snippet but LV 2011 for some reason was adding a reference control wired to the For loop. Quite strange.)