Programatically generated boolean in loops

[LandBelenky]

There are a few things I'd like to clean up so that we can figure out what's going on.

(1) I noticed that you have an un-initiated shift register on your loop.

Those can be tricky because you sometimes don't know what value is in it originally so it can throw around values that you aren't expecting.

I never, ever, ever use un-initiated shift registers.  (Some other people do, but not me.)  I would like to know in advance what value should be in the at shift register and make sure it is initialized properly.

(2) Do you really want to use the "greater than" function on your boolean values?  Maybe a "greater than or equal to?"

(3) You have your loop set to stop if i>1.  Does that mean you want it to execute exactly once, or exactly twice?

If you know how many times you want it to execute, replace the While loop with a For loop.

[RobotLabviewTest]

The loop doesnt seem the problem, i tried about 15 different loops provided by NI forum members all of which work with a boolean switch and not my boolean output. Something is wrong with my hardware to software boolean output. I appreciate its difficult without having the hardware or dll to test the code but this info all seems too common on the NI forum in regards to boolean latching

Quote:

Note  You cannot use any latch action for objects with a local variable. The first local variable to read a Boolean control with latch action resets its value to the default. If you configure your Boolean value with a latching mechanical action, the Value Property and the Value (Signaling) Property always return an error. Due to race conditions that can occur when you have a Boolean value with latching mechanical action, you cannot programmatically read Boolean values that are set with a latching mechanical action.

This appears to be the issue, i tried converting the boolean output and tried using the number before the array (before the cluster) to create a variable or number to use math in a loop but i am stuck.

Thanks for keep suggesting

[RobotLabviewTest]

diffePerhaps there is a way to convert/change the action of my boolean output from cluster to be used in while or for loops? Or a different way other than a local variable to import (true/false) data into a loop to run code from my VI that actually works? If you need more info ask. Perhaps what i want is not possible using the code i have?

[LandBelenky]

An important thing to understand is that the boolean doesn't do any latching.

Latching is a function of the front panel object (switch, button, light, etc), that controls the boolean, but it's not in the boolean itself.

As a general rule of thumb, you should avoid local variables.

I really think the latching problem you are seeing is the combination of an un-initiated shift register and the 'greater than.'

That will only return a true if your input value is true and your register value is false.  Any other combination will return a false.

This might make you think that your value is stuck in the off position.

Sorry  I can't be more helpful.

[LandBelenky]

Perhaps there is a way to convert/change the action of my boolean output from cluster to be used in while or for loops? Or a different way other than a local variable to import (true/false) data into a loop to run code from my VI that actually works? If you need more info ask. Perhaps what i want is not possible using the code i have?

Ohh... I think I might be starting to understand.  You definitely don't want to use a local variable to import data into your loop.

A local variable will grab whatever data is in your control at the moment it gets called.  This is a big problem because it often means that your local variable gets called before any data has been put into it.  Sometimes, you don't know exactly when it is getting called and its value might be changing.  You don't know if the data you are pulling out of it is from before it was updated or after.  This is called a "race condition."

The proper way to move data into a loop is to wire it directly.  That way, the loop cannot start until after the previous operations have finished.

Is this what you have done?

Also, I'd really like to know what value is coming out of your shift register on the first iteration.  Can you attach an indicator to it (between the shift register and the 'greater than') and run it a few times? 

[LandBelenky]

Perhaps there is a way to convert/change the action of my boolean output from cluster to be used in while or for loops? Or a different way other than a local variable to import (true/false) data into a loop to run code from my VI that actually works? If you need more info ask. Perhaps what i want is not possible using the code i have?

Ohh... I think I might be starting to understand.  You definitely don't want to use a local variable to import data into your loop.

A local variable will grab whatever data is in your control at the moment it gets called.  This is a big problem because it often means that your local variable gets called before any data has been put into it.  Sometimes, you don't know exactly when it is getting called and its value might be changing.  You don't know if the data you are pulling out of it is from before it was updated or after.  This is called a "race condition."

The proper way to move data into a loop is to wire it directly.  That way, the loop cannot start until after the previous operations have finished.

Is this what you have done?

Also, I'd really like to know what value is coming out of your shift register on the first iteration.  Can you attach an indicator to it (between the shift register and the 'greater than') and run it a few times? 

[Mark_Yedinak]

I still have no idea what you are trying to actually do. As mentioned, you do not need to do a greater than (or other type of comparison). A simple equality test is all that is needed. I would strongly recommend that you do not use stacked sequence frames. Learn how to use data flow. Simply placing your calls to the dll in a series connecting the error out of one into the error out of the next will run things in order and be easier to read. A state machine would be even better since you could handle errors that might occur in the middle of your processing.

As for your value from the dll call I suspect you simply are not getting the correct value from that call. You may not be interpreting that value correctly. I suspect that is the root of your problem. There is no magic that happens when you wire the value of one control over the other into a tunnel on the loop. It will get the value that is present on the wire.

When you say you want to use the value of the boolean inside the what do you mean. Do you want the value after the loops terminates? If so, simply wire it to the right side of the loop and then wire that to wherever you need it. If you need the value while the loop is still running then I recommend you use a queue or notifier to pass it to the other code that needs it.

[RobotLabviewTest]

LandBelenky You are exactly right with the local variable. Thats very helpful information and i will change the way i get data into loops.

I wont focus too much on the loop as the loops i have been using to test my boolean output from cluster were just a handfull grabbed from example's presented on these forums, it was only to Illustrate my problem of a switch being able to start a loop but a simple boolean output from my cluster not being able to start it. It happens with many many loops.

Mark_Yedinak Today i will try and split down my stacked sequence frames and try using a more simple method to call the DLL as for I/O. I still find it very weird that the indicator on Boolean outputs on the right hand side function perfectly with all inputs. When i press a test button (on the hardware) it lights up immediatly however i stuggle to get this into other code. But i think you are right data flow is much more what i need and i find it alot easier to understand.

What i am doing for this small bit of code is controlling the movement of a pan and tilt head with an encoder shaft so i can find its position and then move it around and gather data from a sensor head. Ultrasonic range finder, laser scanning head, 1080p camera and a stack of other sensors. So really i havent progressed anywhere. I am understimating how difficult it is to run basic flow's. I do beleive a lot of the problems are with these initial stacked sequence frame's. No loops outside of this appear to run correctly. Everything is fine for simple indicators but moving data from this for any kind of processing seems to halt the whole VI and get jammed in the loop or totally prevent the original indicators from working (on any channels). I will start changing the way i call the DLL and work back from there.

Thank you both for your advice, i really appreaciate it.

[LandBelenky]

I'd really like to see what your code looks like when you wire the boolean from the output of your unbundle cluster to the input of your loop.  I suspect you might be making a very simple mistake that we can correct quite easily.

The other thing I'd like to know is what it looks like when you run it in "Highlight Execution" mode.  I'd like to know if the loop starts looping before the output from your .dlls is finished.

We're going to get this thing!

[billko]

---

@LandBelenky wrote:

I'd really like to see what your code looks like when you wire the boolean from the output of your unbundle cluster to the input of your loop.  I suspect you might be making a very simple mistake that we can correct quite easily.

The other thing I'd like to know is what it looks like when you run it in "Highlight Execution" mode.  I'd like to know if the loop starts looping before the output from your .dlls is finished.

We're going to get this thing!

---

A caveat:

"Highlight Execution" mode will probably make things execute in a different order than it would normally.  For that reason, it might not be as helpful as hoped for.

[nathand]

Jumping into this discussion a bit late, but... right now your code only reads the boolean input ONCE when you run it.  Is that what you intended?  Are you using the "Run Continuously" button to run this VI?  You really should not be doing that... if you need to check the input continuously, read from the DLL in a loop.