LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Hidden objects and wires

Solved!
Go to solution

The alternative that I (and many other LabVIEW developers) use is to make use of the Error Line to link functions and sub-VIs that operate sequentially by passing the Error Line from Error Out of one function/sub-VI to the Error In of the next function/sub-VI.  If you look at the examples that ship with LabVIEW, such as the many DAQmx examples, you will see that "almost everything sits on the Error Line".

 

I've created a sub-VI "Template" that I always use when programming.  Instead of going to the File menu and clicking "New VI", I click the second entry, "New ..." which I use to navigate (the first time I use it on a new PC) to where I've saved my "New VI Template" file, which I originally created by making a new VI using the default 4-2-2-4 connector pane, and putting Error In and Error Out on the Front Panel, wired to the lower left and lower right corners.  I also rename them to "Error In" and "Error Out", which reminds me they are "my" sub-VIs.  I then save this "template" VI somewhere I can conveniently find it and save it as a .vit (VI Template) file, naming it something "memorable" such as "TEMPLATE Basic VI.vit".

 

Now, when I want to create a new VI, I click "New ...", and once I've "found" where I stored TEMPLATE Basic VI.vit, it will appear as the "last used" entry and when I select it, I'll have a new VI with Error In and Error Out on the Front Panel and Block Diagram, ready to be wired and used.

 

But what (you might ask) if I only need 1 input, and 2 outputs?  Can't I use another pattern?  Sure, but consistency means the inputs and outputs stay aligned, and your wires "automatically" run straighter.  "But what if I need 6 inputs?"  Do you really need 6 "unrelated" inputs?  Can you bundle them into one "main" input a 5 "parameters" that can be bundled into a Cluster and appear as a single "Cluster" input (or output)?

 

This will definitely "debulk" your block diagram, making all (or "most") of the items 32x32 pixel squares of functions and sub-VI, with the occasional While, For, and Case structures surrounding them.

 

Another decluttering method is to group code that does (more-or-less) a single function into its own sub-VI, particularly if "What" it does is much more important than "How" it does it.  Hide the messy details inside a 32x32 pixel sub-VI.  However, if you do use this "trick" (which basically all advanced LabVIEW developers use), you'll need to find a way to label your sub-VIs.  The best developers have mastered the art of creating sub-VI Icons that identify what is contained in that Icon.  Those of us (like myself) who haven't quite mastered VI Iconography use the Icon Editor (right-click the Icon in the upper-right corner of the Front Panel or Block Diagram) and chose "Edit Icon" to replace the default Icon that LabVIEW creates.

 

Once you are there, you need to turn on seeing the "Layers" Tab, which you do by clicking "Layers" on the top menu and choosing "Show Layers page".  There you can get rid of the default LabVIEW new VI icon and replace it with a Template, such as an empty Black Square (choose the Rectangle Tool that looks like a Black rectangle outline, click in the Drawing Area and drag down and right).  Now go to the Icon Text tab, set Small Fonts, Center alignment (my choice), 10 point, Center Text Vertically, and turn off Capitalize.  Now you can write up to 4 (short) lines of text to identify this VI when placed on the Block Diagram.

 

Making your own sub-VIs is the "secret" to taming huge Block Diagrams.  My most complex code (with multiple parallel routines, several hundred VIs, bells and whistles all over) fits on a single 15" laptop screen (of course you don't "see everything", but you do see the "Big Picture", and when you want a Detail, you click on the 32x32 Icon labelled "Messy Detail #1" and (as they say,) "Bob's Your Uncle".

 

As for using Local Variables, the Big Downside is you cannot see the flow of data (remember, "Data flows through wires").  

 

Bob Schor

Message 11 of 21
(464 Views)

Wow.  I've just downloaded and taken a look at your VI.  Observations and suggestions abound.

  • Open the Block Diagram.  Click "View" on the Menu Bar, and choose Navigation Window.  This opens a tool that lets you "navigate" around your Block Diagram by sliding a white rectangle showing the area of the Screen view to "see what's there".
  • Your Block Diagram is 23 "screens" wide and 9 "screens" tall.  Much of it is "blank space".  Your goal is for it to be 1 x 1, not 23 x 9.
  • The "left" edge seems to be initializing Controls (often using Local Variables, a "bad" practice.  There's a better way to do this:
    • Set all the Controls to the value you want them to have initially.  Note that if they are sent to the "normal default" (0 for numerics, F for Booleans, blank for strings), you should leave them "as is" -- many of your Controls fall into this category, but some ("Tab Weight Threshold") have non-zero values.
    • Click "Edit" on the Menu bar, and choose "Make Current Values default".
    • To make your program start with all the values set to the saved Default, tell LabVIEW when it starts your program to "Reinitialize All Values to Default".  This you do using a Property Node of this Top Level VI using features found on the Application Control palette.  Here's a picture (I hope):Reinit All.png

      Like (almost  all) LabVIEW Functions, this has Error In and Error Out terminals, so if your code uses the Error Line properly you can place this at the beginning of the Error Line (which should be before your code starts to run) and it will reset all your Controls to their (saved) Default Values (which is why you saved them, above). 

  • Once you've done this, you can safely remove the outer-most Sequence.  Now start using the Error Line properly (and make Clusters when necessary), create sub-VIs, and gradually "slim down" the code and banish the Sequences that you have rendered superfluous.
  • Stop when it all fits on a single screen.  I'm confident it can be done (and will vastly improve your ability to manage the code, particularly when "something doesn't work").

Bob Schor

Message 12 of 21
(456 Views)

@Bob_Schor wrote:
  • The "left" edge seems to be initializing Controls (often using Local Variables, a "bad" practice.  There's a better way to do this:
    • Set all the Controls to the value you want them to have initially.  Note that if they are sent to the "normal default" (0 for numerics, F for Booleans, blank for strings), you should leave them "as is" -- many of your Controls fall into this category, but some ("Tab Weight Threshold") have non-zero values.
    • Click "Edit" on the Menu bar, and choose "Make Current Values default".

This is useful during development where controls can be changed in edit mode to unusual values before the next run, but once this is a built application (in the end, it always is!), it is no longer needed unless we implement a "reset" state while keeping the program running.

 

It is also important to only set default values for controls. Often, indicators such as graphs contain massive amounts of data that would only bloat the VI on disk if made the default. (For some background, read this idea). For good measure, I also always set the execution option to "clear indicators when called".

 

Of course with an overabundance of local variables, the distinction between control and indicator gets blurry, so things get more complicated. But that can of worms has already been opened here... 😄

0 Kudos
Message 13 of 21
(449 Views)

@Faisal786 wrote:

Its very easy to suggest someone to throw their 3 years of work and abusing their way of work but it is not welcome at all. 

 

1)  i have not left these blank spaces on purpose, i am also pissed of why they are their as clean up tool is not helping.

2) i have plenty of local variables because i read somewhere on forum that creating local variable is better than entering or leaving millions of wires from structures.

 

Open to have any constructive feedback and suggestion.


My advice is sincere. You may not want to hear it, but I believe that those three steps I mentioned really are the best course of action.

Message 14 of 21
(438 Views)

@Bob_Schor wrote:

 

...

 

The best developers have mastered the art of creating sub-VI Icons that identify what is contained in that Icon.

 

...

 

Bob Schor


Gee, that's disappointing to hear.  It should be 'most developers', not "The best developers".

0 Kudos
Message 15 of 21
(432 Views)

@altenbach wrote:

@Faisal786 wrote:

i have plenty of local variables because i read somewhere on forum that creating local variable is better than entering or leaving millions of wires from structures..


A bold and completely false statement require a link. Can you tell us where you read that? All I can think of is that this was a newbie statement that quickly got challenged by more experienced users.

 


One of my former cow-orkers would use "Value" property nodes all over because he heard that local variables "cause race conditions".

0 Kudos
Message 16 of 21
(405 Views)

@paul_a_cardinale wrote:

@Faisal786 wrote:

Its very easy to suggest someone to throw their 3 years of work and abusing their way of work but it is not welcome at all. 

 

1)  i have not left these blank spaces on purpose, i am also pissed of why they are their as clean up tool is not helping.

2) i have plenty of local variables because i read somewhere on forum that creating local variable is better than entering or leaving millions of wires from structures.

 

Open to have any constructive feedback and suggestion.


My advice is sincere. You may not want to hear it, but I believe that those three steps I mentioned really are the best course of action.


Paul is right. Instead of spending three years of creating this, you could have learned to program and made it in much less time and have fewer issues in the future. But, as they say, the best time to plant a tree is 3 years ago, but the second best is now. Continuing to program like this will only get you into more trouble and headache, but now you have the opportunity to learn and improve.

Certified LabVIEW Architect
0 Kudos
Message 17 of 21
(370 Views)

Hi Bob,

 

Thanks a million for spending time on my case and giving me a very detailed feedback. I am already working on your and other member's feedback. 

0 Kudos
Message 18 of 21
(333 Views)

The Automatic clean up is unfortunately not very good. It works ok on small sub-vi's. In this case you'll have to fix it yourself.

Most things are mentioned, but i'd like to add a State Machine-architecture. Check out Help -> Find example -> State machine fundamentals, it'd help you structure and organize your code.

You can do a lot of cleanup by similar things like this and it'll save you space. (ctrl+alt+l mouse to contract diagram)

Yamaeda_0-1747051186733.png

 

Yamaeda_1-1747051367362.pngYamaeda_2-1747051506192.png

Yamaeda_3-1747051955132.png

 

 

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

Qestit Systems
Certified-LabVIEW-Developer
Message 19 of 21
(306 Views)

Hi,

 

The whole sum+comparison only makes sense for integer values of those "powder concentrations" (rule: "never compare floats for equality", almost).

So the array should be blue and there should be only one comparison "<2" (or ">=2")…

Best regards,
GerdW


using LV2016/2019/2021 on Win10/11+cRIO, TestStand2016/2019
Message 20 of 21
(300 Views)