8.6 Block Diagram Cleanup Comparisons

[Justin Goeres]

For fun (and inspired by our other discussion), I decided to apply the Block Diagram Cleanup Tool to several examples from the 99 Bottles of Beer thread from a while back. I picked 3 VIs from that thread to run the tool on. I didn't pick these for any particular reason, other than that they're all reasonably different from each other. I opened them in LV86, took a "before" screenshot, then ran the Cleanup Tool and took a "after" screenshot. I didn't do any cleanup of the "after" code, other than that I removed some free text labels (which had been scattered to the wilderness areas of the diagram, because we already know those aren't handled well).

On balance, I think the Cleanup Tool generally made these VIs worse in terms of readability, particularly near the Format Into String primitives. At the very least, I don't think it improved them much, if at all. And while these are non-trivial VIs, they're not terribly complicated. So what's the deal? Were these VIs just pretty "clean" to begin with? What do y'all think?

Aristos Queue

BEFORE

AFTER

Orko

BEFORE

AFTER

Justin Goeres

BEFORE

AFTER

[crossrulz]

I did something similar when I first downloaded LV8.6. Quite frankly, I agree that the cleanup tool actually made my VIs look worse. Then again, I try to make my code look really clean in the first place. I think the real problem is that you can't really set concrete rules when it comes to LV code. Sometimes you have to give on one rule for the sake of readability and/or performance. So I simply just ignore that feature. Though, I have some real BAD speghetti code that I inherited. I should try it sometime.

As a side note, the only new feature I like in 8.6 is being able to alter the properties of multiple objects at once. That will save me hours of work in the near future.

[Aristos Queue]

Justin: Did you play with any of the Tools>>Options settings that control this tool? The default setting is to compact the diagram as tight as possible. In general, all of the user written diagrams have a "looser" feel to them. Try increasing the spacing setting and see whether that improves results.

[Justin Goeres]

QUOTE (Aristos Queue @ Sep 10 2008, 05:23 AM)

Justin: Did you play with any of the Tools>>Options settings that control this tool? The default setting is to compact the diagram as tight as possible. In general, all of the user written diagrams have a "looser" feel to them. Try increasing the spacing setting and see whether that improves results.

Good point. I didn't change any of the default settings. This is fresh-from-the-shrinkwrap behavior.

[Norm Kirchner]

Now wait a damn minute!!!

What are you all thinking ragging on the inability to have this make clean code cleaner??!!

I mean get off it already.

Yes, we all have our styles and ways that things should look w/ regards to specific functions ie format into string.

And although LV can now respond to our voice commands, (more on this later), it still can't read our freaking minds!!

Take some damn perspective on this tool, it analyzes what things are and moves them around in a logical manner.

This is one of the most creative ideas that I have in LV in a long time.

.... I can't even get what I'm saying across right at the moment because I'm so beside myself that you are all so critical of this awesome feature.

The tool doesn't probably care how special you are and how neat the code is already. More likely it says what the F did y'all plop down and what makes sense as far as layout and starts from scratch.

That's pretty damn smart if you ask me.

So take the tool for what it's worth and don't be unrealistic with your expectations.

and for those of you who are wondering, I have used it on a few occasions for cleaning up other peoples rats nests and for taking my quick prototype code and helping me when it's time to turn it into a well laid out diagram.

I still move things around after the fact, but it saves me time..... and that makes all the difference!

Hillshire Farm

Go Meat!

[TobyD]

QUOTE (Norm Kirchner @ Sep 10 2008, 12:24 PM)

Now wait a damn minute!!!

BREATH NORM, BREATH!!!

I think most of us can agree that having this feature is better than not having it. My only point is that I really hope the overuse of this tool does not influence the slackening (is that a word?) of style guidelines.

I see it as similar to PCB design software. Because I have limited experience with PCB layout, the auto-layout feature helps me out, but if I showed some of my layouts to people who layout boards for a living they would cringe.

-Toby

[Aristos Queue]

QUOTE (Norm Kirchner @ Sep 10 2008, 02:24 PM)

And although LV can now respond to our voice commands, (more on this later), it still can't read our freaking minds!!

Actually, it can read minds: http://www.viroadshow.com/2007/02/wheelcha...ly-by-your.html

High praise and glory will be given to the user who makes Quick Drop work with the mind-reader collar. That will solve the problem of everyone talking out loud at their cubes.

--------------------------------------------

The #1 Tools>>Options setting that I've heard requested is "Keep FPTerminals in conpane-relative positions".

I've also heard a general request for "if a wire forks, try to run one branch completely straight and fork the other branch up or down. If you cannot run straight, then try for equidistant up and down on both branches. Only if neither of these constraints can be fulfilled should the branches be imbalanced. Only in the most extreme cases should a wire both fork and bend". See image.

http://lavag.org/old_files/monthly_09_2008/post-5877-1221078512.png' target="_blank">

[Justin Goeres]

QUOTE (Norm Kirchner @ Sep 10 2008, 12:24 PM)

Take some damn perspective on this tool, it analyzes what things are and moves them around in a logical manner.

This is one of the most creative ideas that I have in LV in a long time.

.... I can't even get what I'm saying across right at the moment because I'm so beside myself that you are all so critical of this awesome feature.

The tool doesn't probably care how special you are and how neat the code is already. More likely it says what the F did y'all plop down and what makes sense as far as layout and starts from scratch.

I don't think anyone's really being all that critical of it. It takes what seems to be a pretty hard problem and comes up with generally fairly reasonable layouts. I think it's interesting to consider, though, that the tool will always be the product of a few developers' ideas of "good style," boiled down to a set of heuristics. NI has done a really good job on it, but that doesn't mean it's not interesting to look at the cases where it comes up short anyway.

And FWIW, I'm actually kind of impressed by how little it modified the examples above . You can kind of see by the changes it makes how it weights different nodes and different wiring patterns.

For the sake of argument, though, the handling of free labels is really inconvenient. For the large number of us who use free labels to label our wires, we either have to change our workflow to do the labels after a cleanup (which means they're not labeled during initial development ), or resign ourselves to replacing them all the time , or just never use the Magic Fingers . For such a banner feature that it got airtime at an NIWeek keynote, that's a bit disappointing, and that's not its only shortcoming.

I still think it's pretty clever, and reasonably well executed, and a godsend for a large number of LabVIEW developers. But the problem it's trying to solve is fundamentally pretty hard.

[crelf]

QUOTE (Aristos Queue @ Sep 10 2008, 03:28 PM)

I've also heard a general request for "if a wire forks, try to run one branch completely straight and fork the other branch up or down. If you cannot run straight, then try for equidistant up and down on both branches. Only if neither of these constraints can be fulfilled should the branches be imbalanced. Only in the most extreme cases should a wire both fork and bend".

That's going to be one hell of an options page...

[Jim Kring]

QUOTE (crelf @ Sep 10 2008, 09:10 PM)

That's going to be one hell of an options page...

How about having the ability to "teach" the block diagram cleanup tool what a good block diagram looks like? It could gather various metrics on your code to determine the optimal settings just for you.

[Aristos Queue]

QUOTE (crelf @ Sep 10 2008, 11:10 PM)

That's going to be one hell of an options page...

That one isn't meant to be an option, just a general modification to the algorithm that is always in play.

[crelf]

QUOTE (Aristos Queue @ Sep 10 2008, 11:54 PM)

That one isn't meant to be an option, just a general modification to the algorithm that is always in play.

I was kidding

[LAVA 1.0 Content]

QUOTE (Aristos Queue @ Sep 11 2008, 12:54 AM)

That one isn't meant to be an option, just a general modification to the algorithm that is always in play.

Just judging by the images posted one idea would involve the Diagram Clean-up checking with the VIA to see how it did. One of those cleaned-up daigrams had a wire running under a string constant and would have failed that VIA test.

Ben

[Aristos Queue]

QUOTE (neB @ Sep 11 2008, 10:06 AM)

One of those cleaned-up daigrams had a wire running under a string constant and would have failed that VIA test.

This has been reported as CAR 125827.

[Michael Aivaliotis]

This first version of the cleanup tool is just that. It's going to be improved. What we need to do is let NI know what needs to be improved for the next release. So far, every time I use it I have to undo it. I have yet to find a case where it does what I want. Playing with the settings doesn't help.

One suggestion is that NI look at clean code that Pro developers like us create and find the key elements that characterize our layouts. Then, they could incorporate those elements into the cleanup tool as predefined styles that can be chosen in the options. You could even have several predefined layout styles. For example Style A, Style B, Style LAVA, and so on.

I think that if NI doesn't receive and listen to feedback from us on what is considered a clean diagram then it will never be as useful as it could.

[Norm Kirchner]

QUOTE (Michael_Aivaliotis @ Sep 11 2008, 07:42 PM)

This first version of the cleanup tool is just that. It's going to be improved. What we need to do is let NI know what needs to be improved for the next release. So far, every time I use it I have to undo it. I have yet to find a case where it does what I want. Playing with the settings doesn't help.

One suggestion is that NI look at clean code that Pro developers like us create and find the key elements that characterize our layouts. Then, they could incorporate those elements into the cleanup tool as predefined styles that can be chosen in the options. You could even have several predefined layout styles. For example Style A, Style B, Style LAVA, and so on.

I think that if NI doesn't receive and listen to feedback from us on what is considered a clean diagram then it will never be as useful as it could.

Understood, and am now sufficiently calmer.

And I do agree. My perspective of what I was hearing prior to my rant was far from what has been the remainder of this thread.

And I shall chime in, as an admitted active user of the tool, what I see as potential improvements too.

[crelf]

QUOTE (Michael_Aivaliotis @ Sep 11 2008, 07:42 PM)

You could even have several predefined layout styles. For example Style A, Style B, Style LAVA, and so on.

...and a custom style where we could define what we wanted, and then save it off as a style file so we could take it with us, and share it amongst our colleagues. Just like VI Analyzer profiles.

[LAVA 1.0 Content]

QUOTE (crelf @ Sep 12 2008, 10:49 AM)

...and a custom style where we could define what we wanted, and then save it off as a style file so we could take it with us, and share it amongst our colleagues. Just like VI Analyzer profiles.

How do you define and document your custom style? i.e. what thought process do you use to decide how to place and organize your LV diagram? And how do you tell a computer to do the same thing?

[Aristos Queue]

QUOTE (Aristos Queue @ Sep 11 2008, 10:42 AM)

This has been reported as CAR 125827.

Regarding the CAR that the wire routed under the string constant... I got an update from one of the developers who works on Diag. Clean Up:

This is the expected behavior, with the default settings for auto Horizontal-Compactness. If the user moves the setting for Horizontal compactness to lowest, then the Diagram Clean Up will ensure that the wires will not go under the blocks.

Quoting from the Tools>>Options dialog documentation:

"Horizontal compactness—Determines how compact to make the block diagram. Higher compactness causes LabVIEW to take longer to clean up the block diagram and can cause LabVIEW to reroute wires under objects. This control is grayed out unless you select Manual tuning. LabVIEW considers labels as part of a block diagram object. "

Even though this is a known issue, I am keeping this bug open because I could see that wire-routing in general is pretty bad in the given VI. The excessive bends in wires appear to be related to another known issue caused by shift registers, which we are currently working on.

[Scott Carlson]

Norm --

I found the above post, completely appropriate. I have no idea, why you are "flipping out". "Get off it"? Did you write the clean-up routine? Are you personally offended?

I agree, the clean-up routine isn't a replacement for writing clean code.

-Scott

QUOTE (Norm Kirchner @ Sep 10 2008, 03:24 PM)

Now wait a damn minute!!!

What are you all thinking ragging on the inability to have this make clean code cleaner??!!

I mean get off it already.

Yes, we all have our styles and ways that things should look w/ regards to specific functions ie format into string.

And although LV can now respond to our voice commands, (more on this later), it still can't read our freaking minds!!

Take some damn perspective on this tool, it analyzes what things are and moves them around in a logical manner.

This is one of the most creative ideas that I have in LV in a long time.

.... I can't even get what I'm saying across right at the moment because I'm so beside myself that you are all so critical of this awesome feature.

The tool doesn't probably care how special you are and how neat the code is already. More likely it says what the F did y'all plop down and what makes sense as far as layout and starts from scratch.

That's pretty damn smart if you ask me.

So take the tool for what it's worth and don't be unrealistic with your expectations.

and for those of you who are wondering, I have used it on a few occasions for cleaning up other peoples rats nests and for taking my quick prototype code and helping me when it's time to turn it into a well laid out diagram.

I still move things around after the fact, but it saves me time..... and that makes all the difference!

Hillshire Farm

Go Meat!

[Norm Kirchner]

QUOTE (Scott Carlson @ Sep 12 2008, 11:55 AM)

Norm --

I found the above post, completely appropriate. I have no idea, why you are "flipping out". "Get off it"? Did you write the clean-up routine? Are you personally offended?

I agree, the clean-up routine isn't a replacement for writing clean code.

Statements like

QUOTE

but I have yet to see a VI that I would consider "clean" after running this tool.

QUOTE

The few times I tried it, the end result required some more cleanup.

QUOTE

The block diagram cleanup tool

does not

share this preference, which puts it strongly at odds with a key personal aesthetic.

QUOTE

thanks NI for the tool, as I'm sure it'll help LabVIE users (LabVIEW programmers - not so much)

were the type that catalyzed my fervor.

And no, I did not develop it, but I like to see arguments from the other side and although well intended, the comments seemed over critical at the time and I felt that someone needed to stand up a bit for the tool and the fact that they made it work in the first place.

As I soak in the recommendations coming out as opposed to just seeing the... "well this just isn't good enough for me" comments, I center my chi once again.

[crelf]

QUOTE (Norm Kirchner @ Sep 12 2008, 01:05 PM)

Statements like

QUOTE

thanks NI for the tool, as I'm sure it'll help LabVIEW users (LabVIEW programmers - not so much)

were the type that catalyzed my fervor. ...well intended, the comments seemed over critical at the time and I felt that someone needed to stand up a bit for the tool and the fact that they made it work in the first place.

That's exactly what I was saying! Read it word for word: "thanks NI for the tool, as I'm sure it'll help LabVIEW users". I consider my comment balanced and realistic.

[gb119]

QUOTE (Michael_Aivaliotis @ Sep 12 2008, 01:42 AM)

This first version of the cleanup tool is just that. It's going to be improved. What we need to do is let NI know what needs to be improved for the next release. So far, every time I use it I have to undo it. I have yet to find a case where it does what I want. Playing with the settings doesn't help.

One suggestion is that NI look at clean code that Pro developers like us create and find the key elements that characterize our layouts. Then, they could incorporate those elements into the cleanup tool as predefined styles that can be chosen in the options. You could even have several predefined layout styles. For example Style A, Style B, Style LAVA, and so on.

The cleanup tool is kind of fun - but I'd really like it if it could be persuaded to work on sub-diagrams. I can't think of the number of times that I've written a state-machine and while the basic structure is clean and tidy, there's one case that is a total mess. As things stand with the current clean-up tool it will cleanup my mess and then (to my eyes at least) de-optimize my state machine. For example, if I'm passing data through the state machine with shift registers, then I've normally set the y position of those shift registers with some reason - I think (without extensive testing) that the cleanup wizard is rather fond of moving and re-ordering them. Short of having the ability to selectively 'lock' BD objects I'm not sure how one would encompass that sort of style decision in a style schema.

I do really like the idea of a code-cleanup tool that could 'learn' what a user thought was good style - I've seen text programming code pretifiers that inferred correct style from samples - it would be really neat if the code cleanrup tool came with several 'style definition' vis that you could edit into your idea of good style...

[gb119]

QUOTE (Gavin Burnell @ Sep 13 2008, 07:36 PM)

The cleanup tool is kind of fun - but I'd really like it if it could be persuaded to work on sub-diagrams.

As a footnote to myself - after a bit of poking and script magic, I discovered that there is a 'Relayout' method defined for Diagram references. For a couple of hours I was very excited, thinking I'd discovered a way to do the selective layout - but unfortunately the method only seems implemented for TopLevelDiagram references. Oh well, that's what you get for trying to use features NI haven't actually released... - still perhaps a future version of LabVIEW will do the selective cleanup...

[Michael Aivaliotis]

I'd like to continue this thread as I think the diagram cleanup tool has a lot of potential and I'm hoping NI will improve it in the future. It's already saving me a lot of development time. One thing I haven't been able to figure out is how to compress horizontal spacing and remove a lot of white space. In the example below, I don't think it's necessary to expand the above structures.

Should be like this:

It seems like the tool tries to balance things out. If I delete the code below the structures then they become small when cleaned up again. It seems to expand the case structures to the width of the code below them.