‎03-12-2013 11:28 AM
I have an old application that needs to be updated but I need a strategy for reviving it.
It is composed of a single main vi with 6 separate loops running. (currently in Labview 8.6, going to 2011)
Some loops update indicators from analog inputs, some are controlling instruments, and one is the main state machine that processes scripts loaded from files.
My dilemma is mostly what to do with the 100+ FP indicators/controlls spread across 6 tabs.
I want to condense each loop into its own subvi but not sure how to handle this.
It looks like I need to create a reference for all controls/indicators, pass these into each subvi and access the values via property nodes.
Solved! Go to Solution.
‎03-12-2013 03:15 PM
If I understand you correctly, you want to update your controls/indicators on your main vi from your subvi. See link below for a cool tool
‎03-12-2013 03:55 PM
First, consider whether you actually need to modify the code. If it works well enough, it's sometimes better not to touch it even if it's not perfect. You should also be aware that spreading responsibility for one FP to multiple subVIs can make the code considerably more complicated and error prone, which is presumably not what you want.
I would recommend moving the loops into subVIs and displays the subVIs in a subpanel, but that assumes that each loop corresponds to exactly one page of the tab. Not knowing your code makes it difficult to provide more constructive advice. You could also try bringing in an experienced consultant to help plan the refactoring. I'm assuming your local NI office can put you in touch with some relevant people.
‎03-13-2013 02:42 PM
Hello chiraldude,
Updating a VI to a new version of LabVIEW can sometimes be a tricky process. We generally like to say "the bigger the jump, the greater the chance of incompatibility" when our users ask this question. I have included below a couple of links to documents that will give you a better idea of what might go wrong when you bring your 8.6 code into LabVIEW 2011. In particular, the instrument control segments could rely on earlier versions of drivers and subVIs that may be incompatible with the new version of LabVIEW. You should look at the versions of these drivers you are using and see if they are compatible with 2011. In the case that the drivers are incompatible, check and see what subVI functions you are using and ensure that those functions haven't changed (or there is an easily-adaptable alternative) in the earliest compatible version of the drivers. Also check to see if your instrumentation is supported!
How to Upgrade or Revert a VI to a Different Version of LabVIEW
Regarding your question about what to do with your 100+ FP indicators/controls, it is always difficult to answer this question. It really depends on how comfortable you are with LabVIEW and troubleshooting. You could indeed create references to the controls and indicators and pass them into subVIs. This is my personal preference because it creates well-segmented, easy-to-read code. However, passing 100+ references into subVIs would be a daunting task! I would group your indicators and controls into clusters that will ensure you don't have hundreds of icons to move around. You can then take the cluster and bundle/unbundle it to pass it between parts of the VI structure. If you are not familiar with how clusters work, I've included a link below. Clusters are one of my favorite things about LabVIEW!
If you aren't familiar with how to utilize references, this might be useful:
Controlling Front Panel Objects Programmatically from a SubVI
I hope this helps! Please let me know if there is anything else regarding the upgrade or splitting up your VI that I can help with. Good luck!
‎03-13-2013 03:20 PM
Thanks for all the comments.
I am particularly interested in packaging the references into a variant as suggested by jyang72211. This has the most potential to clean up the diagram. Still lots of work but I have become a lot more focused on reusable and readable code.
I was wondering if there was some simpler solution using LVOOP. I am assuming that, since nobody suggested it, there is little benefit in converting an application to LVOOP. If I were starting from scratch with a decent list of specifications, maybe a different story.
‎03-13-2013 03:38 PM
@chiraldude wrote:
I was wondering if there was some simpler solution using LVOOP. I am assuming that, since nobody suggested it, there is little benefit in converting an application to LVOOP.
Well, a proper recommendation can't really be made without knowing a lot more, but converting an existing application can be messy, especially if it's not already structured nicely. If you have experience with OOP, then you shoud be able to judge yourself whether parts of the app can be converted. If not, I wouldn't recommned learning it on something like this.