Tell Block Diagram Cleanup What "Clean" VIs Look Like

[Darren]

I've been using block diagram cleanup extensively over the past year in an attempt to speed up my LabVIEW programming.  I am definitely faster as a result of using the feature, but there are still some VIs that I have to arrange myself, because diagram cleanup's arrangement is unacceptable.  So the feature still has a ways to go in making all my diagrams acceptably clean.  It's my understanding that there are many more configuration options in diagram cleanup that could potentially be exposed to the user, but I think an easier way to conform diagram cleanup to my standards would be to point it at a folder of VIs that I have personally deemed "clean", and have diagram cleanup mimic the arrangement in those VIs when cleaning up other VIs.

As an example, I am ok with input tunnels into a case structure overlapping somewhat, if those tunnels are coming straight from subVI output terminals that are close together.  Diagram cleanup insists on adding space between the tunnels so that they don't overlap, which results in unnecessarily crooked wires.  Ideally, I would have VIs in my "clean" folder that have slightly overlapping tunnels, diagram cleanup would discover that I'm ok with this, and subsequent cleanups would allow this arrangement.

[JackDunaway]

You mean, would the end user walk through a "calibration" process? Such as the Clear Type Text Tuner? Or the optometrist face gadget? Or simply, the BD Cleanup tool "learns", and is adaptive to your style?

[Darren]

I'm envisioning that diagram cleanup would inspect your code and "learn" your style.  By "learn", I mean tweak its own internal heuristics (of which there are dozens, I'm told) to most closely match the arrangement in the VIs it learned from.

[Darin.K]

I would have to brush up on my CS notes to see how many VIs would be necessary to implement a satisfactory unsupervised learning algorithm for an artificial neural network.  One thing I would not use as a training set is vi.lib.

A lot of people tend to run down the BD blow-up cleanup tool, but I will say it is indispensable for scripting uses.  It is pretty easy to get perspective on the scope of the problem by trying to recreate it.

An effective method I have implemented assumes that I got it "almost right".  I then snap all functions/subVIs/etc. to the nearest position of a coarse grid.  Finally, I leave the positions of all the nodes alone and Clean Up all of the wires.  This lets me be a bit sloppy while coding, and then clean it up if I want.  Still a bit of work to deal with structures and some corner cases, but I know that nothing will be moving more than about 20 pixels.

What would possibly help is greater tunability of whatever cost function the BDCT uses.  We can tweak how badly we want our error wires horizontal versus crossing wires, etc.  I am sure there are plenty of free parameters to tune.

OR, perhaps it is time to realize that machines have indeed become our masters and that in fact LV does know better.  We should then all adapt our vision of what clean is to match what the BDCT produces.  Who am I to argue with a mathematical formula?

[Daklu]

I use BD cleanup only on simple vis.  On anything with more than 3 or 4 sub vis it invariably creates more work for me than rearranging things myself.  (Especially with the error wire.)  I hold out hope that it will get better.

[PJM_Labview]

I agree with Darren. I also have start using the BD cleanup on most of my SubVI. It does initially speed things up (you can start coding with no care for style), but it get to a point where subsequent use result in more work and hence it is no longer useful.

I would also love to be able to "teach" that tool what makes "good" code.

Note: My biggest annoyance with it is that it yield way too many wire bend.

[Broken_Arrow]

Neat idea. Here is something that currently bugs me about Cleanup, and why it would be nice to "tell" LabVIEW not to move them things.

[jlokanis]

I would just like it to STOP right justifying the labels of indicators.  This just looks bad.  It would make more sense to me to right justify the controls instead, but I would be happy if it would just let me turn this off altogether.

Oh, and while they are at it, teach their interns proper coding style and have them use the block diagram cleanup tool if they can't write legible code.  For that matter, how about hire a bunch of interns to batch process all of the examples and VI.LIB with block diagram cleanup and then review all the code for cleanup artifacts.

[JackDunaway]

---

@jlokanis wrote:

Oh, and while they are at it, teach their interns proper coding style and have them use the block diagram cleanup tool if they can't write legible code.  For that matter, how about hire a bunch of interns to batch process all of the examples and VI.LIB with block diagram cleanup and then review all the code for cleanup artifacts.

---

Read my #1 saucy idea. We share the same sentiments.

Back on topic....

In my first comment, I mentioned two types of ways for the BDCT to become smarter: adaptive heuristic parameters based on a given set of VI's, or a walk-through "Which do you like better, A or B?"

I'm leaning strongly toward the BDCT wizard that walks the user through a tuning process for several reasons:

1. It might be easier/more likely for NI to implement.

2. Unlike the other method, if you feed the BDCT tuner VI's that are pretty much objectively crappy, it doesn't end up tuning itself to produce objectively crappy style (e.g., a block diagram "only a mother could love"). The wizard style shows the users pre-defined block diagrams with pre-defined parameters.

3. I would be willing to allow this tool to optionally report back statistics on what customers consider to be 'beautiful' VI's. I don't know how much market research was done whilst developing the BDCT, but I can say my opinion was not considered! (Was yours?)

4. Darin eloquently states what I agree with... we should adapt our style to "the machine", where "the machine" is the best representation of the best of the community's style.

5. I highly regard style. This is why I would not touch the BDCT with a ten foot pole. On the other hand, I highly regard expediting the sometimes-mundane process of enforcing good style on my code. This is why I think the BDCT has a good chance as being a featured component of my repertoire once it's improved.

6. Maybe, the wizard could store your "top 5 styles", and repeatedly running BDC would toggle the cleanup through each of your top 5 styles, until you found the most attractive VI.

A year ago, I ridiculed the BDCT as being a bogus waste of resources. Although I still don't ever use it, I have developed an awareness that - with some improvement - it could improve my workflow and increase the bottom line, $$$.

[AristosQueue (NI)]

Slight tangent: Diag clean up in LV 2010 is substantially better than LV 2009. Many special cases were handled and the general algorithm got some adjustments toward settings more favored by the community (based on VIs submitted as CARs against the diagram cleanup tool). Squeaky wheel gets the grease, so if you do have VIs that you find in LV 2010 that are not being cleaned up to your liking and can point out specific changes that would make them correct, please take a moment to file that bug report.

[AristosQueue (NI)]

Related Idea posted:Cleanup Options Preview

These are not the same idea, but they seem to complement well. I've posted my thoughts about how they could work together in that other idea.