Get Boolean through Property node in Subvi

[jyang72211]

Hi all,

I have a main vi and a sub vi.  In my subvi, it gets a boolean value from the main vi through property node (see attached).  The subvi will poll the boolean reference until it gets a true.  Apparently, when the subvi is running, it is not detecting changes in the main vi boolean.  Why is that?  

[johnsold]

Cannot tell fro sure from your image of a small portion of the program (which does not show the subVI).

Most likely is dataflow: The Main VI does not read the button while the subVI is running.  Turn on Highlight Execution (the lightbulb on the block diagram toolbar) and watch your program run while youpush the button.

Lynn

[Mark_Yedinak]

What is updating the Boolean? If you are reading something in the main VI and updating the value of the Boolean your subVI will not see the data change unless it is running in parallel to whatever is setting the Boolean's value. That is, if the call to the subVI and the setting of the Boolean are in the same structure (case structure, loop, event structure) once you enter your subVI the main VI will not be able to update the Boolean until the subVI completes. THe subVI won't complete because it is waiting for the main to update. You have created a deadlock situation. The only way this will work is if the subVI and the setting of the Boolean are done in parallel.

Now, the way you are doing this is not a very good way to architect your system. You can see from the deadlock you created why. You are much better off making the decision in the main as to when to actually call the subVI rather than have the subVI reach out of itself (by using the property node) to items in other parts of the code. The subVI shouldn't need to check that condition (at least not in a polling loop). If you do want to test the state of the Boolean inside the subVI don't do the polling there. Read the value of the Boolean and simply pass that to the subVI. The subVI can then run or not based on that value and return immediately if it doesn't need to run. Even better would be to use events instead of polling. That way the code is idle when waiting for something to do.

[jyang72211]

The boolean is an abort button from the main vi.  When the user click on the abort button in the main vi and the problem is running the subvi, I want the subvi to be able to run this true from the abort button and stop running.  

If I understand you correctly, the subvi will only get the updated value through the property node only if the boolean control is read in the main vi.  I guess that make sense.  What is the best way to do what I want?  A global?

[Mark_Yedinak]

---

@jyang72211 wrote:

The boolean is an abort button from the main vi.  When the user click on the abort button in the main vi and the problem is running the subvi, I want the subvi to be able to run this true from the abort button and stop running.  

If I understand you correctly, the subvi will only get the updated value through the property node only if the boolean control is read in the main vi.  I guess that make sense.  What is the best way to do what I want?  A global?

---

Not quite. I am saying that if your main VI looks something like this:

where you are reading the value of "stop" in the subVI you will not do what you want to do. A loop, or any structure for that matter, must wait for ALL code inside it to complete before it moves on. If your code is similar to the very simple example above you are entering the subVI and trying to read a value that is not going to be updated because the control itself will only update its value once every loop iteration. You cannot use a polling loop in the subVI reading a control that is updated in the same structure where the main VI is updating/reading the control. They need to either be in parallel loops or remove the loop from the subVI.

[Darren · Accepted solution]

If it's a latch boolean, you'll get error 1193 whenever you try to read its Value property.  I noticed you're not checking the error output from the Value property read, which is why I'm guessing this is the problem.  Reading/writing the Value property of a latch boolean isn't supported.  You'll need to switch the boolean to use switch mechanical action...or you'll need to figure out some other way to pass the information between your VIs.

For more information on the mechanical action of booleans, check out this help document.

[jyang72211]

My problem is simliar to your example.  The subvi will want to read the abort button and abort mid way.  If I can't do it that way, what would you suggest?

[Mark_Yedinak]

I would recommend that you look at something like the producer/consumer architecture. Alternatively you could modify your subVI to only run a single iteration of whatever it is that you are doing. If your code looks like what I posted you will not be able to do what you want. I would run your subVI in parallel to your main VI's loop (this is basically a producer/consumer architecture) and use a queue or notifer to pass messages to the loop in your subVI. The messages would basically be start and stop messages given what your are currently trying to do. Then the subVI can do what it needs, check to see is it got a stop message, if not repeat. If it did then stop.

[johnsold]

Mark has given you some good advice.

To see why this works the way it does, turn on Execution Highlighting (the lightbulb on the Block Diagram toolbar).  Then run your program and watch what happens when you push the button.  Actually, pay close attention to when the button is read, because it will probably be read before you push it.

Lynn

[jyang72211]

Hi Mark,

From what you said, if I tried to access a control's value through a property node and the control is not being read continuously in parellel, the property node will not give me the most up-to-date value.  I tried out the concept with the attached example, and it got me confused.  In the example, the boolean is only read once before the loop, but the property node inside the loop seems to pick up the boolean changes if I were to change the value.  Why is that?