LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Avoiding really long wires?

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

0 Kudos
Message 1 of 18
(3,995 Views)

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.

Message 2 of 18
(3,990 Views)

Hi,

 

Never heard of the terms :

- Sequences

- state engines

- subVI's

 

They should make your code more readable and cleaner.

 

Kind regards,

- Bjorn -

Have fun using LabVIEW... and if you like my answer, please pay me back in Kudo's 😉
LabVIEW 5.1 - LabVIEW 2012
0 Kudos
Message 3 of 18
(3,982 Views)

 


@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.

 



Mark Yedinak
Certified LabVIEW Architect
LabVIEW Champion

"Does anyone know where the love of God goes when the waves turn the minutes to hours?"
Wreck of the Edmund Fitzgerald - Gordon Lightfoot
Message 4 of 18
(3,972 Views)

Hi,

 

True Mark, you can indeed better avoid using sequences, I was just making a statement on which possible structures to use 😉

Kind regards,

- Bjorn -

Have fun using LabVIEW... and if you like my answer, please pay me back in Kudo's 😉
LabVIEW 5.1 - LabVIEW 2012
0 Kudos
Message 5 of 18
(3,968 Views)

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.



Mark Yedinak
Certified LabVIEW Architect
LabVIEW Champion

"Does anyone know where the love of God goes when the waves turn the minutes to hours?"
Wreck of the Edmund Fitzgerald - Gordon Lightfoot
Message 6 of 18
(3,964 Views)

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

0 Kudos
Message 7 of 18
(3,910 Views)

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.

0 Kudos
Message 8 of 18
(3,894 Views)

Not much to add, modularize and convert to a event structure and it'll be managable, now it's a mess.

 

/Y

G# - Award winning reference based OOP for LV, for free! - Qestit VIPM GitHub

Qestit Systems
Certified-LabVIEW-Developer
0 Kudos
Message 9 of 18
(3,869 Views)

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 😉

 

SimpleStateEngine

Kind regards,

- Bjorn -

Have fun using LabVIEW... and if you like my answer, please pay me back in Kudo's 😉
LabVIEW 5.1 - LabVIEW 2012
0 Kudos
Message 10 of 18
(3,843 Views)