03-11-2011 12:53 PM
Not really sure how to ask this so it makes sense, but here goes... Is there a way to use, I'm guessing here, a variable to connect an output to an input that's a long way across the block diagram from each other? I have an output from a DAQ Assistant VI that's on the other side of the diagram from where I want it... I looked at dumping it into a local variable, but I'm not sure what to put next to the input to have them connect. I know I can string a wire, but it's getting rather messy and I'm trying to simplify my screen. A point in the right direction would be much appreciated!
THX
C
03-11-2011 01:00 PM
If your block diagram is that large, then it's quite likely that you have a poor programming structure, such as trying to do everything at one level, rather than using subVIs. While you could use a local variable, doing so exposes you to the risk of creating race conditions, and examples of poor/improper use of local variables can be found in the Local Variables thread.
If you post your code we can suggest improvements.
03-11-2011 01:22 PM
Hi,
Never heard of the terms :
- Sequences
- state engines
- subVI's
They should make your code more readable and cleaner.
03-11-2011 01:39 PM
@ABCPrograms wrote:
Hi,
Never heard of the terms :
-
Sequences- state engines
- subVI's
They should make your code more readable and cleaner.
As suggested earlier given your description it sounds like you need to modularize your code. You would also benefit from using some standard architectures like a state machine. I would avoid using sequences though. LabVIEW is a data flow program and you should strive to write your code that way. In virtually every instance you can avoid using sequence frames by using data flow to control the flow and order of execution of your program. There are a few cases were sequences are justified but use of them should be the exception, not the rule.
03-11-2011 01:42 PM
Hi,
True Mark, you can indeed better avoid using sequences, I was just making a statement on which possible structures to use 😉
03-11-2011 01:45 PM
I understand. I just take the approach of conveniently ignoring those constructs (sequence frames, flat frames, global variables) that lead to bad programming habits. If a new person is unaware of them they won't get in the habit of using and abusing them.
03-11-2011 04:36 PM
Here's my code as it sits today... a catasrophe I know, but it is better now than how it started. I had it somewhat working with the DAQ Assistant wired and then I blew my power supply so I'm repairing that at the moment. But I am open to any suggestions that those with more experience may have to give!
Thank you!
Chad
03-11-2011 10:00 PM
First, run a block diagram cleanup. That will go a long ways towards compacting the space.
Second, give all your control/indicator terminals meaningful names and show their labels on the block diagram. What way you know what the purpose of each terminal is. Many of your boolean indicators are missing the labels on the block diagram. And when I went to show them, they were meaningless or default labels.
Third, try to avoid deeply nested structures like loop in a case, in a loop in a case.
Fourth, your code has several major bugs in it. You have numerous while loops that will either run once or run forever. The stop terminal of the while loop is fed by a boolean coming from outside the loop. When that loop runs it will always have whatever value that was at the tunnel of the loop when it started. If it is a True, the loop will only run once, then stop. If it is a False, it will run forever and never stop. Though for every problem that I found in your code, it looks like the while loop will only run once because the stop terminal is fed from a boolean that also controls the case structure. Thus the loop will only run if it is true, and then it will only run once. So most of those while loops are pointless and can just be removed.
03-12-2011 08:37 AM
Not much to add, modularize and convert to a event structure and it'll be managable, now it's a mess.
/Y
03-13-2011 03:05 AM
Hi,
I should devide your VI in different subsections for readability. You can use a state engine for that. If you don't know how a state-engine works, here is a VERY SIMPLE example of it 😉