07-25-2007 01:23 PM
On a more serious note, I agree with the subvi reasoning, for the EE this is like making a schematic but not using the microchips as black box but showing all the transisters that make up the chips (subvis). The reason behind software engineering is for project management mostly not functionality. Testing reuse encapsulation readability and managability are all important too. One aditional note in addition to subvis to encapsulate code you can bundle wires with similar origins and locations, this is much like an EE bus, since the wires are all following the same path, you might as well save yourself some tome and use a bundle ("cable") instead of individule wires. Using typdefs to define these bundles will also promote type checking and code reuse. Imagine every time you wanted to get serial data you grabed 9 wires instead of a rs-232 cable. Would really slow you down wouldnt it?
Paul
07-25-2007 02:14 PM - edited 07-25-2007 02:14 PM
Message Edited by Gabi1 on 07-25-2007 09:15 PM
Message Edited by Gabi1 on 07-25-2007 09:15 PM
12-01-2008 05:00 PM
What everyone has already said is good, but for those who are new to Labview and want to reduce complexity there is a way to convert some of the vi to a sub-vi. When I first started out, I chose labview because it wasn't as structured and I thought I could quickly throw together some code to get a quick program. However with all the options of Labview and functionality your code grows and you get a lot of wires. In the long run it is better if you do some planning initially and start out with subroutines (sub vi's). If you do not do this you can easily convert some of the code to a sub vi. Actually the sub vi will not always reduce the number of wires but it will break up the code into smaller chunks.
To convert a portion of the vi to a sub vi:
Select the items you want to be in the sub vi. On the "Edit" menu there is an option to convert to Sub VI.
09-25-2009 08:08 AM
To convert a portion of the vi to a sub vi:
Select the items you want to be in the sub vi. On the "Edit" menu there is an option to convert to Sub VI.
Not a substitute for well thought-out modularity. Also, if you're a noob, and you do this, heed the warnings about locals or fpterms in loops which will change the behaviour of your program.
09-25-2009 12:16 PM
Broken Arrow wrote:To convert a portion of the vi to a sub vi:
Select the items you want to be in the sub vi. On the "Edit" menu there is an option to convert to Sub VI.
Not a substitute for well thought-out modularity. Also, if you're a noob, and you do this, heed the warnings about locals or fpterms in loops which will change the behaviour of your program.
Broken Arrow:
I mostly agree with that, but sometimes it *is* useful if you decide that the very specific code you just used could be generalized and used elsewhere. I wouldn't make it a habit, but sometimes you just get a brainstorm (or survived a brain fart) and there ya go... 😉
On the running topic here about sub-VIs in general though, just think:
Sub-VI ~ Sub-routine (or procedure). Writing a VI without sub-VIs is like writing a program in C with no ther procedure than the main one! Okay for simple programs... In addition to functioning like sub-routines, since you save them as separate VIs, you can use your code in future projects. Imagine writing an algorithm destined to become the foundation of your company's widgets... then realizing it wasn't portable... uh-oh...
I don't know about the "hacker" excuse, either. I started out hacking code on my old Atari 800 (it was new back then - yeeesh), but the moment I decided to go beyond "hello" world, I researched doing things the right way... Same with LabVIEW.
Bill
09-26-2009 02:15 PM
Broken Arrow wrote:To convert a portion of the vi to a sub vi:
Select the items you want to be in the sub vi. On the "Edit" menu there is an option to convert to Sub VI.
Not a substitute for well thought-out modularity. Also, if you're a noob, and you do this, heed the warnings about locals or fpterms in loops which will change the behaviour of your program.
I actually use the create subVI from selection menu often. Not because I haven't thought about making a subVI out of some code before, but because it is a little bit faster to just draw the code and make a subVI out of it than going to a new VI, arrange everything on it, write the code, wire up all terminals, create a connector pattern and then connect it accordingly.
Of course those subVIs do get heavily edited afterwards anyhow, such as reorganizing the connector pane into a clean left in -> right out scheme, error clusters on the bottom corners, refnums on the top, etc. etc.
I agree that using this option as an afterthough is not a good idea and leaving the subVI as it is created by LabVIEW a complete NO-NO!
Rolf Kalbermatter
09-27-2009 11:50 AM
rolfk wrote:
Broken Arrow wrote:To convert a portion of the vi to a sub vi:
Select the items you want to be in the sub vi. On the "Edit" menu there is an option to convert to Sub VI.
Not a substitute for well thought-out modularity. Also, if you're a noob, and you do this, heed the warnings about locals or fpterms in loops which will change the behaviour of your program.
I actually use the create subVI from selection menu often. Not because I haven't thought about making a subVI out of some code before, but because it is a little bit faster to just draw the code and make a subVI out of it than going to a new VI, arrange everything on it, write the code, wire up all terminals, create a connector pattern and then connect it accordingly.
Of course those subVIs do get heavily edited afterwards anyhow, such as reorganizing the connector pane into a clean left in -> right out scheme, error clusters on the bottom corners, refnums on the top, etc. etc.
I agree that using this option as an afterthough is not a good idea and leaving the subVI as it is created by LabVIEW a complete NO-NO!
Rolf Kalbermatter
Precisely!
11-24-2012 08:08 PM
The best way to get rid of the wires is to use Visual Studio or something. But I once customized a class wire to be white on white. That might work for you.