Figuring out what you do NOT have to do.
In Part I, I gave the rough outline of the task: How to manage over 12000 controls/indicators on one panel.
The first thing to realize is that the beginner’s reaction (“holy crowdation Batman, that’s impossible”) is based in reality. You could not realistically put 12000 controls on a panel and WIRE THEM ALL UP on a single diagram. That’s waaaaaay beyond sanity.
When pondering the possibilities, you realize that there is to be no difference between one block and another, so a solution practically leaps out at you: use a subVI. For code, this has been done since the 1950s: use a single piece of code with the basic procedure, and call it from several pieces of code, with parameters used to vary the behavioral details.
But how do you apply that to front-panel things?
The answer is in two ideas used together:
- Re-entrancy
- SubPanels
Re-entrancy is a concept that has been around for years. A piece of code (in any language) is said to be reentrant if:
- It can safely be interrupted at any point by a call to itself, and have that second (or subsequent) call execute to completion and return (or re-enter) the first invocation where it was interrupted.
- It maintains a SEPARATE data space for each caller. This is necessary to implement #1.
Now, by default, any VI you make is NOT reentrant. If you call it from A and you call it from B at about the same time, one of the calls will have to complete before the other one even starts. This is what you want in a lot of cases: if there’s any local storage involved, then there will be ONE and ONLY ONE copy of that data, regardless of how many calls there are. The call from A might leave something behind (local storage in the VI), then the call from B will operate on that same data.
If the VI is reentrant, however, that local data will NOT be shared, and the two calls can proceed simultaneously, if the process scheduler sees fit. One call will not interfere or have any connection to the other.
By itself, this doesn’t help us yet. We could have a bunch of copies of a reentrant VI running, but we would have a bunch of separate windows on the screen to wade through.
That is where the SubPanels come in. A SubPanel is basically a LabVIEW container that is a “hole” in your front panel. Through that “hole” you see not the panel that’s on top, but the panel of a DIFFERENT VI that you have inserted into the SubPanel. But it’s a two-way hole: you not only see what’s on the panel below, but your clicks (and keystrokes) go thru the hole and onto the panel below. So you can fully interact with this VI, as long as it’s running, and as long as the hole is big enough to let you see all the controls you need to.
So, there’s our basic strategy: If we make a VI to handle a single BLOCK, and make it reentrant, then we can insert several instances of that VI into several SubPanels on our real panel, and VASTLY decrease the work we have to do.
Back to the original numbers: we counted up 179 items in a single block, and having 72 blocks on the panel. By moving those items into a subVI, and then implementing 72 copies of that VI, we have VASTLY reduced the wiring we need.
Plus we’ve reduces our chances of error, and if something needs changing, change it in one place and we’ve multiplied our effort by 72 !
Continue on to Part III.
