Anyone else OCD about alignment and positioning in block diagrams?

[Jordan Kuehn]

Very often I will be working on a VI then get frustrated when the block diagram cleanup button is missing...only to realize that I was indeed on the Front Panel.  The good news is Jack already has an idea so I don't need to take the time to post it.

 

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/How-about-a-Front-Panel-Cleanup/idi-p/963556

 

Kudo'd.  Thanks!

[Val Brown]

I mean, come on NI.  Why wouldn't you do that for the FP as well? 

[MikeC3]

Very often I will be working on a VI then get frustrated when the block diagram cleanup button is missing...only to realize that I was indeed on the Front Panel.  The good news is Jack already has an idea so I don't need to take the time to post it.

 

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/How-about-a-Front-Panel-Cleanup/idi-p/963556

 

Also Kudo'd.  This would be a huge timesave for sub-vi work.

[OlivierL]

The new trend of this topic got me digging into the information from Jack's post and I'm quite happy to have found Mark Balla's "SubVI fixer". I'm still working on some LV2009 projects so the automatic 4x2x2x4 is useful on top of the FP auto-alignment.  Look here if like me you've missed it 4 years ago:  http://lavag.org/files/file/128-fp-subvi-fixer-ver-6-lv-2009/ 

 

I Definitely Kudo'ed Jack's idea.

 

On the original topic, VIs available on the palettes should always be 4x2x2x4.  Those 5x3x3x5 do make BD look ugly until the bends get hidden behind the "unconventional" VIs.  Aligning the icons is just as important as straight wires...

[JackDunaway]

Since there's been a bit of chatter about Front Panel Cleanup -- four years later, I find the desire for a Front Panel Cleanup indicative of a more root desire to just "spend less time creating a functional View for the method interface; I'd rather delegate this task to the IDE and language definition".

 

I've been thinking the correct way to do this is to allow SubVIs to be created without a Front Panel; instead, integrating the interface UI into the BD itself.

 

This requires half a dozen small (perhaps, controversial?) steps redefining things like Terminals and ConPanes and Local Variables (spoiler: locals are properly deprecated, since true dataflow has no analogue to a traditional "local variable"), yet could fundamentally improve the mental model of how we perceive the links between VI components and how they represent the composition of logic.

 

(e.g. -- currently, how would you explain to a beginner how data flows from a diagram to a front panel, and from the ConPane from a FP into a subsequent VI's diagram? the mental model departs quickly from the IDE representation, making LabVIEW a booger to "get")

 

tl;dr: Front Panel Cleanup is a band-aid for the root problem of SubVIs being required to have Front Panels (no offence to the novice who first suggested this on the LV IdEx)

[Mark Balla]

I've been working on this Idea for a few years and have a tool in the CR that helps reduce the time it takes to fix the FP layout to the connector pane pattern.

There are also videos showing how the tool works.

 

FP SubVI Fixer ver 6

 

It doesn't do exactly what Jack is asking for but there is a lot of possible reuse code in the tool to help save you time and effort.

 

Mark

[John Lokanis]

I am not sure I would want to support the idea of eliminating the FP from sub-vis.  While I agree that it's layout does not serve any functional purpose in the code and is just another time consuming step to deal with, i feel it still has value as a unit test interface.  That is one of the best things about LabVIEW that text based languages lack.  So, Jack, if you want to kill off the FP, you need to tell me how to debug my sub-vis just as easily as I can now.

I would support some way to auto arrange the FP in a sensible way.  One thing I would love to see is the controls being limited to the visible space on the FP.  For example, when you copy some code containing control terminals from one VI to another, those new controls should be placed within the visible portion of the destination VI's FP.  Currently, I often have to hunt down where they landed far off screen and move them back into place.

I think we have a pretty solid basic agreement on sub-vi FP layout.  I would be satisfied if we could simply designate a VI as a sub-vi when we create it and then the IDE would auto-place/move controls to meet those guidelines.  The rules I follow are:

 

• All controls must be visible on the FP (within the current boundaries.  No scrolling allowed)
• Controls must be laid out to match the connector pane orientation.
• Error clusters are always in the lower left/right corners.
• When possible, references are passed in/out the upper left/right corners.
• All controls snap to the grid (I use the graph paper grid) with at least one grid block separation.
• There is a minimum margin of one grid block around the perimeter of the FP.
• The FP is positioned so the origin is precisely in the upper left corner.
  

 
Bonus things I do:

• The minimum size of the FP is set so the entire toolbar is visible.  Even if this means a lot of white (grey) space on the FP.
• The VI description is copied to the FP in a comment block at the bottom of the FP.
  

Even if we just had some scripting example to accomplish most of this that would be a step forward.  I know many people have made their own version.  I would prefer an official solution so we could have some continuity between developers.

[JackDunaway]

I am not sure I would want to support the idea of eliminating the FP from sub-vis.... That is one of the best things about LabVIEW that text based languages lack.  So, Jack, if you want to kill off the FP, you need to tell me how to debug my sub-vis just as easily as I can now.

 

Agree wholeheartedly, and I think this can be done. I'll make it a point to start a new thread on this topic in the next several weeks.

[Darin]

First of all, this thread pretty much makes me want to vomit all over my keyboard so I take it in small doses.  Front Panels make a little more sense to worry about since it is higher on the substance-style scale.

 

Once again let me post my pipe dream, how is this for debugging your BD?  We don't need no stinking Front Panels.

 

 

[GregSands]

I've been thinking the correct way to do this is to allow SubVIs to be created without a Front Panel; instead, integrating the interface UI into the BD itself.

 

I suggested pretty much this idea a couple of years ago, but it's suffering from a lack of kudos and discussion.  The core of the idea is that the BD is the only required part of a VI, but it's possible to add one or more FP views which could give different views for UI, debugging, etc, but only when required.  99% of my subVIs have no requirement for a FP, and I often don't even worry about arranging things particularly nicely, as once created, I never look at it.  For example, every Class Accessor VI - why have a FP at all?

 

Darin's pic is not a bad addition either, though it probably only makes sense for small subVIs - and most are, at least in my experience.

[JackDunaway]

I suggested pretty much this idea a couple of years ago

 

Duly Kudoed; likewise, a couple of years ago 

[todd]

First of all, this thread pretty much makes me want to vomit all over my keyboard so I take it in small doses.

I'll take vomit any day over some of the code I've been lucky enough to deal with.

[Darin]

Darin's pic is not a bad addition either, though it probably only makes sense for small subVIs - and most are, at least in my experience.

 

Allow me to toss a hand grenade.  As a baby step toward that end I suggest (I am being serious) that you turn on icon view for terminals and use it.  Keep an open mind and try to make it look good.

 

Wire bends?  Yes there will be more on average, but they are longer which is easier to follow and much less annoying IMO than those 1 and 2 px jumps.

 

They take up more space?  Yes!  This has two benefits.  It drives down the density of your BD, and triggers that urge to create a subVI earlier.  Helps curb mission creep inside a VI.  Second benefit:  lower density leaves more "slack" on the BD for when you really need to add something.  Tight-packing means that adding a single node can literally affect every other node on the diagram.

 

Perhaps that tall stack of terminals can become a type-def cluster.

 

Bonus:  NI insists on resetting this setting with each release of LV, just sit back and enjoy it instead of cursing every time.

 

Now, once you have accepted the joys of less dense, more focused subVIs, it is easy to move from icon view to control view.  

 

The more focused subVIs are easier to test, maintain, and are much likely to be reusable.  Every node you add tends to increase the specialization.

Edited October 8, 2013 by Darin

[John Lokanis]

Are you sure you meant to say "turn on icon view for terminals" and not to "turn off icon view for sub-vis"?

I honestly cannot see any benefit to making the terminal take up more space.  I do agree with your point of spreading things out and leaving room to grow if necessary in the future.

But, I have seen benefit to turning off icon view for a sub-vi on occasion.  Especially for situations where you cannot keep the con pane down to 4224.  But now with LVOOP, that seems to be less of a problem.

 

I do agree that accessors have no good reason to have FPs.  For that matter, they really don't even need BDs. Maybe I am in the minority but I never edit 99.9% of the ones I auto-create and they mainly mess up my VI analyzer tests because the scripting that creates them does not deal well with long class names.  (terminal labels tend to overlap the case structure)

 

Seriously, icon view terminals?  The next thing you will suggest is using Express VIs! 

[Darin]

Are you sure you meant to say "turn on icon view for terminals" and not to "turn off icon view for sub-vis"?

Seriously, icon view terminals?  The next thing you will suggest is using Express VIs! 

 

I am dead serious.  It gets you out of the tetris mentality, it makes you give every node a little personal space which makes wire routing easier, it fits in nicely with objects and type defs.

 

I actually turn icon view off sometimes myself. I'd like to be able to use more of the icon space in the header, and I wish I could mark pairs of terminals (say error in and error out) as one passthrough terminal so I do not have to have separate lines for them.  Usually I leave the chained connections in the top anyway.  I'd also like to be able to color code the yellow background area.

 

I do not know where Express VIs enter, other than they turn off icon view.  I will guess that you use the term derisively, but that says more about the use of the technology rather than the Express VI technology itself.  I like the configuration aspects, but do not like the subsequent hiding of the configuration details.  They are quite close cousins to XNodes, to me bashing one is akin to bashing the other.  But that is way off-topic.

[hooovahh]

Icon View, Auto-Insert Feedback Node, Auto-Tool, Scripting.

 

The default settings I change on each install of LabVIEW.  I'm not saying my views on these features won't change, but I do think that it tells you something about what kind of LabVIEW programmer you are if you only ever use the icon view for terminals.

 

I believe there was a CLAD question once that was something of "What are the main components of a subVI".  Likely wanting you to say Block Diagram, Front Panel, but I agree that a VI doesn't really need a front panel.  And if I choose to remove the block diagram I guess my VI doesn't really need that either.  

 

But at some point I feel like we may lose something.  LabVIEW is visual (duh) and as a result I feel like my brain makes connections between the subVI icon and the functions it performs.  This helps me remember things very quickly and traversing down the rabbit hole of subVIs seems easy because i remember all their functions visually.  

 

Likewise my brain makes connections between the front panel and block diagram and knows how controls on the front panel and indicators are coupled.  I started this post wanted to say I was on board with removing the front panel, but now I'm not so sure, unless there is again some visual way for me to understand code in a way that is hard to explain.  In text based code I find my self remembering what the code does, based on the shape of the text in that line (or surrounding lines).  I feel like I'm a better programmer because of these visual connections, and I hope that if the Front Panel goes away, some new method will be there to replace the visual connection that will be lost.

[todd]

Wouldn't hiding the FP be good enough? Minimize it behind the BD's icon view - without leaving the FP's window in the taskbar list.

[GregSands]

Wouldn't hiding the FP be good enough? Minimize it behind the BD's icon view - without leaving the FP's window in the taskbar list.

 

At the moment you can't link terminals to the con-pane from the BD, so not quite.  But my idea was more about an alternative paradigm which views the BD as the essential core of a VI.  That is opposite to the NI concept of a Virtual Instrument (i.e. LabVIEW is a software analog of a hardware interface) where the FP defines the functionality.  And while such a fundamental change may never happen, the Idea Exchange and LAVA are both places to explore aspects of LV which may not best fit how it is used in practice.  Even better when an NI guru chimes in to show where ideas fit within NI's thinking that we all can't see.

 

So I suggested being able to choose how many FPs you want, from zero upwards.  For example, you could have a debug FP - which could look similar to the Probe Window but be savable with the VI, even several different ones.  You could have a FP which shows only the I/O controls.  You could choose which of several FPs to show depending on the user, logging status, or whether to show an array as an array or a graph.  Or you could have no FP at all, and in many cases, that's exactly what you do want.

Edited October 9, 2013 by GregSands

[OlivierL]

Because the FP can be very helpful when debugging, I wouldn't support getting rid of it altogether.  However, VIs should have a property that hides the FP and only shows the block diagram (and show the connector pane on the BD screen as well).  One major benefit of this would be to have only half the amount of windows opened when troubleshooting a deeply nested VI and getting to your point of interest faster than having to press "Ctrl-E" every time you open a VI.  By allowing to hide FP and let a BD window open by itself, you could even have a feature that opens only the BD of a VI when the "Ctrl" key is down regardless of the VI's properties.

 

Since the FP should stay, I still support Jack's original idea and Mark's tool to have a FP auto clean-up so that FP look clean when you need them while not t wasting time with them when you don't.  Nowadays, unless you spend some time organising the controls on your FP, your programs can "look bad" even if you have the cleanest code on the BD which really is the only thing that matters.

 

Regarding the notion of a VI being a "Virtual Instrument" and therefore requiring an interface, I think it's time to acknowledge that only a minority of VIs are actually visible to the users and to support the idea of the code be the most important part of the program instead the graphical representation of the function's I/Os which serves little purpose 95%+ of the time.

[Jordan Kuehn]

While I find the discussion regarding the usefulness of a FP in many VIs to be lacking, I do think the idea of flat out removing it is a bit much.  First, the unit testing argument is very compelling to me, or even very simple testing by manipulating the FP manually and seeing the results is helpful at times.  Further, In my mind the FP/BD combo is one of the more powerful and unique features in LabVIEW.  It facilitates the construction of a UI unlike anything else I've seen and it's tightly integrated with the code.  There is no process of building a UI, then tying every element to some tag that gets update by underlying code or whatnot.  The strong relationship with BD elements to FP elements is a benefit, rather than something tedious to me.  This is why I'd like to be able to hit clean-up when I don't care about the FP and have it look organized and standardized without any additional effort.

[Val Brown]

Regarding the notion of a VI being a "Virtual Instrument" and therefore requiring an interface, I think it's time to acknowledge that only a minority of VIs are actually visible to the users and to support the idea of the code be the most important part of the program instead the graphical representation of the function's I/Os which serves little purpose 95%+ of the time.

 

I find this perspective curious because any "thing" that accomplishes a task is an instrument, whether that task is measurement, display, file management, byte manipulation, etc.  LV is virtual instrumentation because everything is in code -- not hardware.  Whether something is an instrument is not about having or not having a user interface that is visible; rather, it's like the concept of having a tool that "gets the job done".  Frequently the military serves as an instrument of a political decision and that includes black ops.

[GregSands]

@Jordan: In my mind it's not so much "removing" the FP, rather, only creating it if and when needed.  That could still be completely automated (even customized with the sort of hooks LV currently provides) - certainly not needing to manually build a UI or match tags.  I simply feel that having the BD as the default starting point for a VI provides a better programming perspective than filtering what I want to do through the FP.  I'm not anti-FP just saying the FP serves the BD, and not the other way around.

Edited October 9, 2013 by GregSands

[OlivierL]

Created a separate topic to discuss about the need for FP.  We can go back to discussing about 1px bends in here.

 

http://lavag.org/topic/17326-should-bd-be-allowed-without-fp/

[tnt]

When inserting an 'Unbundle By Name' I always seem to move the wire 1px down to remove the bend.

(... and hiding the 1 px bend )

 

For some reason the input and output are not aligned.

The unbundle is 18px, the center of the 3px error cluster wire on the left
is located 1px below the 1px output wire on the right.
 

Same issue when having multiple sequential Unbundles...

* I know this can be done in 1 single unbundle, but when you reuse clusters inside another big configurationcluster

  the unbundles can get corrupted (linked to the first possible match) when updating the source cluster.
  (Maybe this bug has been solved or not, but I still unbundle first when I know there are identical names inside)

Edited October 22, 2013 by tnt

[hooovahh]

* I know this can be done in 1 single unbundle, but when you reuse clusters inside another big configurationcluster

  the unbundles can get corrupted (linked to the first possible match) when updating the source cluster.

  (Maybe this bug has been solved or not, but I still unbundle first when I know there are identical names inside)

I don't remember ever seeing this, but I tend to try to have unique names in my cluster (and master configurationcluster) so maybe that is why I've never heard of that issue.  I wonder if the In Place structure does the same thing.