Jump to content

The force is with LabVIEW 8.6


Donald

Recommended Posts

Hello All,

This post just to share my 2 weeks of LabVIEW 8.6 wiring experience!

I'm so happy with the LabVIEW 8.6 diagram cleanup feature! For me it is the best new feauture and best developers time saver since the introduction of Undo. Maybe the best rapid developers feature ever!

I tortured the diagram cleanup with the worst horor diagram I've seen in 13 years :wacko: of LabVIEW usage and ... yes the NI LabVIEW developers did the impossible :worship: --- the 2400x1900 multi nested sequence diagram of doom was clean(er) after 1 minute of calculations on a dual core(!) and LabVIEW did not crash!!! After 2 weeks of development (2 projects with +1500 VIs) LabVIEW 8.6 did not crash at all during development!

Rapid development gets a new breeze with this function... just drop Vis wire - test - debug - and cleanup in some second! Maybe my PC mouse will last longer than one year with this feature :-) Even my test and prototype VIs are neat now

Also the multi control-indicator properties dialog is a serious improvement. And on a PC were it takes at leat 20 seconds to get the properties dialog also an enormous time saver for GUI development.

One little cloud :o : I can not build a project I can build with 8.5, something I still have to check with NI support. (saving to 8.5 solves my problem so it is not blocking the use of 8.6).

Happy clean wiring,

Donald

Link to comment

QUOTE (Donald @ Sep 9 2008, 04:34 AM)

I'm so happy with the LabVIEW 8.6 diagram cleanup feature! For me it is the best new feauture and best developers time saver since the introduction of Undo. Maybe the best rapid developers feature ever!

I shudder to think what could become of LabVIEW style guidelines if people start to rely to heavily on the diagram cleanup tool. I will admit that I have seen some VIs that were so poorly written that the cleanup feature actually helped, but I have yet to see a VI that I would consider "clean" after running this tool. I think it can provide a better starting point for cleaning up messy code, but my experience so far has been that quite a bit of work is still required to make the code presentable.

Link to comment

QUOTE (TobyD @ Sep 9 2008, 11:58 AM)

I shudder to think what could become of LabVIEW style guidelines if people start to rely to heavily on the diagram cleanup tool. I will admit that I have seen some VIs that were so poorly written that the cleanup feature actually helped, but I have yet to see a VI that I would consider "clean" after running this tool. I think it can provide a better starting point for cleaning up messy code, but my experience so far has been that quite a bit of work is still required to make the code presentable.

I agree with Tony on this. I like my code 'clean' in a specific way, which is not quite what the cleanup tool creates. However, I do find it extremely useful as a first step after using Edit -> Create SubVI.

Link to comment

QUOTE (TobyD @ Sep 9 2008, 08:58 AM)

I shudder to think what could become of LabVIEW style guidelines if people start to rely to heavily on the diagram cleanup tool. I will admit that I have seen some VIs that were so poorly written that the cleanup feature actually helped, but I have yet to see a VI that I would consider "clean" after running this tool. I think it can provide a better starting point for cleaning up messy code, but my experience so far has been that quite a bit of work is still required to make the code presentable.

I will have to agree with Toby on that.

Also, it has become so much of a second nature for me to use good style when coding (even when I am trying to be messy to use the diagram cleanup tool) that I hardly ever need it (I will try harder to not automatically do cleanup while I code). The few times I tried it, the end result required some more cleanup.

About the multiple properties dialog, I could not agree more. This is indeed a time saver.

PJM

Link to comment

QUOTE (TobyD @ Sep 9 2008, 11:58 AM)

I shudder to think what could become of LabVIEW style guidelines if people start to rely to heavily on the diagram cleanup tool.

I'm not worried. I think that it has the potential to be relied upon by LabVIEW users (those who do a little programming, but programming isn't their main job function), but I don't see a lot of LabVIEW developers using it on thier own code (those who program in LabVIEW as their main job function). That said, I can see LabVIEW developers use it on code given to them by LabVIEW users :)

Link to comment

Your predictions do not align with what I've been seeing just in the first month of this tool being available. Worrying about wire alignment, keeping nodes straight, etc, is a real time sink. Yes, it becomes second nature if you work on LV long enough and get tired of messy diagrams, but it is a time consuming activity. Did you see Darren's demo in the NI Week keynote? He dropped a bunch of nodes fast using Quick Drop, didn't care about where he dropped them, wired them up (with some wires running backwards) and then hit the clean up button. I've seen a number of programmers do this. I don't know how widespread it is. I've tried using that strategy myself recently, and the results aren't too bad. It's below my standards for a clean diagram, but not by much. We shall see how this goes in the future, but it would not surprise me to see, over time, LV style end up matching what the code clean up tool creates. As layout quality improves, I think that many programmers will decide to let the tool handle the layout rather than nudging nodes pixel by pixel.

Link to comment

QUOTE (Aristos Queue @ Sep 10 2008, 12:59 AM)

[...]

It's below my standards for a clean diagram, but not by much.

[..]

The same for me , I am quite demanding with myself about having clean diagrams, one things IMO that could improve the auto diagram clean-up is having wire labels ( :rolleyes: ). When I try to clean up a diagram my free texts (code documentation) are often moved in a way that bugs me ; if I could bind my doc texts to wires, I think it would help.

Link to comment

Manual wiring could produce nicer code yes I agree but often I do not have the time for it, certainly during refactoring/modifing code some small changes could result sometimes in huge wiring efforts and even the danger of introducing a bug during connecting/disconnecting. Cleanup does it error free and fast(er) than I can, the style is more than acceptable for my customers who pay me per hour (and they do not care where the error cluster is connected to). Please give it a try.

I also use often code that is 'in the field' since LV3.1.1 and had many revisions so not always the cleanest code (also automatic 'bad' style during upgrades 3.11-> 4.1 -> 6.1 -> 7.1 -> 8.2.1 -> 8.6 :-) ther LV compiler introduces sometimes conversion nodes- wires get hidden etc) Now I can clean it up in a split second.

BTW: An extra feature could also be that only the selected code/diagram is part of the cleanup and not the complete diagram.

Good comment however regarding annotations and comments that are misplaced. I did not think about this.. Yes there was no (at least not many) comments in the code I cleaned up. I need to check this.

I remember a funny comment in a diagram once (I guess it was Philips R&D)

IF THE CODE WAS HARD TO PROGRAM IT SHOULD BE HARD TO READ! :headbang:

Link to comment

QUOTE (Aristos Queue @ Sep 9 2008, 02:59 PM)

Did you see Darren's demo in the NI Week keynote? He dropped a bunch of nodes fast using Quick Drop, didn't care about where he dropped them, wired them up (with some wires running backwards) and then hit the clean up button. I've seen a number of programmers do this. I don't know how widespread it is. I've tried using that strategy myself recently, and the results aren't too bad.

But Darren was also coding an exceedingly simple VI. I've tried to use The One True Tool on other VIs that are really still pretty simple (inputs: a couple of LVOOP objects, maybe a DBL and an error cluster; outputs: an LVOOP object & error cluster) but that include a couple nested cases or loops with shift registers, and it makes some really eyebrow-raising decisions due to its obsession with the error wire. Generally I'm a big fan of straight error wires, but except in the simplest VIs, it really makes odd decisions.

Also, I tend to arrange my block diagram terminals so they roughly match the connector pane of the VI (not by distance, just by top-to-bottom order on the left & right sides of the diagram). The block diagram cleanup tool does not share this preference, which puts it strongly at odds with a key personal aesthetic. So are the diagrams cleaner? Sometimes. Are they more useful and easier to understand as I drill down through a chain of subVIs? Usually not :unsure:.

Now, that having been said, I think it's a great tool for people who don't already have a decade of personal style worn into the faux-woodgrain of their desks. It gives them a chance to see what their code would look like, if it were reasonably clean, and that's a big step forward. The cleanup performs so well on simple VIs, in fact, that I can see Quick Drop as being something that encourages users to write not cleaner diagrams, but simpler diagrams. And that's good for everybody :thumbup: .

QUOTE

It's below my standards for a clean diagram, but not by much. We shall see how this goes in the future, but it would not surprise me to see, over time,
LV
style end up matching what the code clean up tool creates. As layout quality improves, I think that many programmers will decide to let the tool handle the layout rather than nudging nodes pixel by pixel.

I think that this could be true, but it will require NI to put real effort into refining and continuing to develop the block diagram cleanup. It's pretty surprisingly good for just having come out of the gate, but I'm afraid it could be seen by NI as "good enough" and just allowed to languish. Or worse, NI could devote more resources to it in lieu of fixing other, worse problems in LabVIEW, and leave us all with shiny, clean, lickable block diagrams that still don't do what we want ;).

Link to comment

QUOTE (Justin Goeres @ Sep 10 2008, 05:19 AM)

I used to do that, but I came to a point where I figured that there's a reason the FP and BD are deliniated, so while terminals are the portal between the two, I figure that preserving layout between the two is not really relevant. That said, I still do try to match the FP layout with the connector pane for lower-level non-UI VIs, but I no longer preserve that layout to the BD as well.

QUOTE (Justin Goeres @ Sep 10 2008, 05:19 AM)

Now, that having been said, I think it's a
great
tool for people who don't already have a decade of personal style worn into the faux-woodgrain of their desks. It gives them a chance to see what their code
would
look like, if it were
reasonably
clean, and that's a big step forward... Or worse, NI could devote
more
resources to it in lieu of fixing
other, worse problems
in LabVIEW, and leave us all with shiny, clean, lickable block diagrams that still don't do what we want
;)
.

I completely agree - thanks NI for the tool, as I'm sure it'll help LabVIE users (LabVIEW programmers - not so much), but don't spend too much more time on it. Please keep working on more professional tools for the LabVIEW programmer like the LabVIEW Software Engineering Tools :ninja:

Link to comment

QUOTE (Antoine Châlons @ Sep 10 2008, 01:59 AM)

...having wire labels...

I third this! Votes++

An intrinsic tool that encourages (coaxes?) users/devs to document code is long overdue. Plus, it would solve the current auto-cleanup shortcoming regarding documentation placement.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.