Leaderboard

Has anyone ever given any thought to the LAVA community creating one single patch for the LabVIEW development environment? In other words, LabVIEW ships from National Instruments and then after installing LabVIEW, a user would then install the Community Patch. What would/could the patch do? 1. Install any number of useful tools in one go: right click framework, quick drop short cuts 2. Add useful OpenG tools 3. Update the configuration file to set settings different from the defaults that LV offers 4. Change the default custom probes 5. Fix bugs that the community has prioritized There are fewer developers here at National Instruments than exist in the wider LV community, and so it is not surprising that there are many great tools developed by members of the community that significantly improve the LabVIEW user experience. Identifying all the tools that I'd like to pull down and install -- or that I would recommend another user pull down and install -- is hard. Some of them are available as packages, but many others are just one-off VIs posted to a forum, like an improved custom probe. I might read the post one day, think, "Great! Let me grab that." So I copy it into my current version of LV. But I don't remember to copy it into LV on my other computers, and when it comes time to upgrade, I may not remember to copy that VI into the upgrade. Ideally such things would be flowing back to National Instruments and we in LV R&D would be over time adding them to LabVIEW's own installer. But there are often licensing problems with us picking up VIs from forums, and even when there aren't, the other priorities required to get a release ready often trump pulling such tidbits in. That got me thinking... Imagine if one of the significant LV users who has a high trust/recognition among the community were to say, "I have created one VI package that installs everything free that I consider valuable to upgrade my LabVIEW experience." That makes it easy for a user to just install one thing and get a set of reviewed improvements all at once. I suspect a lot of tools that otherwise languish in the hands of a few expert users would suddenly have a much wider adoption, and a lot of forgotten niceties would enjoy a renewal. Plus it would give LV R&D one package to review each release, instead of relying on someone happening to have tripped over an interesting post in the forums, which might help get these tools into LabVIEW's own installer. I have no idea if this has been thought about before, no idea how workable this would be, but it doesn't necessarily have to be all that organized. A lone developer deciding to maintain such a package and add to it whenever he/she saw something interesting on the forums would be valuable. An ad hoc group might form around him/her to advise on "posts that should go into <Your Name Here>'s LV Patch". Thoughts?

To get the effect you show in the picture, simply remove both FSS and replace with one big one. I doubt you want that, you probably want to merge the two. In this case I would simply align the two individual structures side-by-side, functionally the same with a lot less pain. Stacked sequences would be a bad idea. If it ain't broke, don't fix it. If it is broke, start over. You seem to be headed down the path of most work for least return.

Why do you want to use a stacked sequence structure? I suspect that the majority suggestion on LAVA would be to convert the flat seqs to sub-vis. If they are old and work, don't mess with them; especially if you aren't touching the code inside them. People usually use flat seq structures to enforce order of operation and a seemingly simple change can break things badly. They did this because they don't understand dataflow which means they don't know LabVIEW and that means there may be other monsters waiting to bite you. If the flat seqs are large (complex) and need to be modified, it might be better to create a sub-vi. Within the sub-vi, they can be converted from a flat to a stacked seq structure and then finally to a case structure that can be wrapped with a while loop and some shift registers to be turned into state machine. You can even use a diagram disable structure to leave a copy of the flat seq in place as you refactor. If something doesn't work, you can just use the old code until you have time to 'do it right'. If the flat seqs contain locals or property nodes that modify data not related to the code within the structures, you've got a whole big, ugly, nasty bag of butt hurt that can't be fixed with sub-vis or get better by adding a stacked sequence structure. The block diagram of your top level VI may look nice, but the next person looking at the code won't be any happier than you. When I open a piece of code that contains nested sequence structures, I become instantly upset to my stomach. My choices in order of preference: 1. State Machine 2. Flat seq structure 3. Anything else ( ) 4. stacked sequence structure P.S. Remembered this from the NI Idea Exchange: http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Splitting-and-exiting-flat-sequences/idi-p/1535798