06-08-2012 10:31 AM
@AndyN wrote:
The closest worry free solution I found was a radio button but that thing does not have an option of "Switch until released". Why? It allows for no selection...
Probably because a radio button is not a boolean but a numeric control, which does not have a mechanical action associated with it.
@AndyN wrote:
What is weird this option has to be set in the cluster before put in the array-> array wont let to you change the mechanical action. With two cases of "Select" I will get the functionality.
No, the Mechanical action has to be set before you put it into the array, irregardless of whether it's in a cluster or not. Just clarifying.
It's nice to hear you are close to a solution. Can you post what you have?
06-09-2012 08:05 PM
This is what I finally decided to do. I pulled it out of my project and made it a self contained VI to test.
The only thing really necessary except the array is the for loop with logic to go from Booleans to floats. Excuse the type inconsistency red dots.
Well, radio buttons have a mechanical action associated just not the kind I need.
I think it would be nice to have a full functionality three state button with numeric output. Or just a radio button with an extra mechanical action.
Thanks to all!
06-09-2012 08:16 PM
I have not searched but I think I recall some threads on making three state "booleans." They may have used a slider. Try searching the Forum for "three state boolean" or "tristate boolean". The ideas in those threads may not be exactly what you want but may give some other ideas.
Lynn
06-09-2012 10:14 PM
Two small improvements:
1) When there is an auto-indexing array, LabVIEW ignores the value wired to the N terminal of the for loop and iterates through every element of the array, so need for the constant 6.
2) You can simplify the logic to eliminate the XOR, just cascade the two Select nodes. The DN output goes to the first select with a true value of -1 and a false value of 0. The UP output goes to the second select with a true value of 1, and a false value of the output from the first select.
06-09-2012 10:28 PM
1. Good to know. That's why I had troubles with allocating it. I don't like the concept at all...
2. How is the Select working if it is already knows the decision is true but the false result hasn't arrived yet?
It would make perfect sense to ignore that path ( I guess it does not). Are small portions of the parallel code like that executed in parallel?
06-10-2012 09:22 AM
@jAndyN wrote:
1. Good to know. That's why I had troubles with allocating it. I don't like the concept at all...
2. How is the Select working if it is already knows the decision is true but the false result hasn't arrived yet?
It would make perfect sense to ignore that path ( I guess it does not). Are small portions of the parallel code like that executed in parallel?
1. Autoindexing is a very handy feature which saves the otherwise common (loop until length of (array))
2. Dataflow: An operation waits until all needed data is available, if possible it will parallellize as much as possible, which is why you need to enforce dataflow/dependancy through wires. That's why Local variables are tricky, they are always available and have a good chance of being read too early, using early or old values and causing race conditions.
/Y
06-11-2012 07:52 AM
Force data flow by using the error cluster (no need for the sequence structure).
What's the point of the property node? I assume you are setting the cluster of arrays to False, but why wire it to the While loop? As I said, use the error clusters to force data flow.
The biggest problem I see is your use of an infinite loop. Here's a simplified version.
Ignore the reference to the Invode node. It auto-placed when attached to the thread.
Your using the N terminal plus auto-indexing.
06-11-2012 11:10 PM
Mo,
The whole point was to share how to get the functionality, which is the big for loop. I added the rest dirty quick to let other see how it works and I do not need nor have it in my code. Everybody is more then welcome to change it make it better ect. Please do not make me explain myself for the fact that snippet png made a reference on its own or that I wanted to just make it "ready to work" for the forum with minimum effort.
BTW. It is a bad idea not to allocate the array.
06-12-2012 07:30 AM
@AndyN wrote:
Mo,
The whole point was to share how to get the functionality, which is the big for loop. I added the rest dirty quick to let other see how it works and I do not need nor have it in my code. Everybody is more then welcome to change it make it better ect. Please do not make me explain myself for the fact that snippet png made a reference on its own or that I wanted to just make it "ready to work" for the forum with minimum effort.
BTW. It is a bad idea not to allocate the array.
Well...you have an infinite loop and I'm not supposed to make mention of it? Dirty quick is one thing, just plain nasty is something else. I made no mention of your reference. I understand how the snippet thing works and likes to include things, but the property node is yours, which is what I referred to, not the reference.
I don't know your skill level or your intention. Perhaps you should make mention of this when you post so others don't needlessly give you unwanted advice. I just saw a better way to do things and pointed it out, that's all.
06-12-2012 07:35 AM - edited 06-12-2012 07:36 AM
@AndyN wrote:
BTW. It is a bad idea not to allocate the array.
Which array are you referring? The output array grows to whatever the input array is. You may see the need to allocate the array, and that's fine, but I saw no need in this case. Unless your dealing with an infinite loop, which is what you had. Then I could see the benefit.