Emulate array of graphs using multiple subpanels

[Basjong53]

It still doesn't work, see below. But let's not focus on this issue because regardless, the front panel isn't updating AT ALL. If you check the block diagram of the "Graph Plugin.vi" from my previous post, you see a random number connected to an indicator outside the while loop, so even if I remove everything else from the code, at least this should update, which it doesn't. And I think this has something to do with the problem.

[drjdpowell]

Two suggestions:

1) you should not be using the 0x40 option (clone pool) in the code you show. You are creating multiple clone pools, and inserting the "master copy" (rather than the running clone) in your subpanel.  0x40 is widely misunderstood.

2) alternately, have you considered a simpler system.  Putting subVI clones in subpanels does not require Async Calling or communication Queues.  I do what you are trying all the time, and my graph subVIs look like this:

That is a Graph control as input, and a reference to the Graph as output.

Calling code mocks up like this:

Here I statically create 4 clones, call them to get references to teh four Graphs, and put them in four subpanels.

Now, having some kind of messaging system to subVIs placed in subpanels is common, and I do that too.   But that is rather complicated, and better done using a well-tested framework or template.  Trying to set this kind of async stuff from scratch is (as you've found) not that easy.

[cbutcher]

I think this will do what you want (VIs attached, images for reference only, saved 2019).

Caller - this knows how many Subpanels you have

Graph - this returns a reference via Notifier so that you can manipulate properties as desired

Here the Caller.vi also generates some random data and sends it to different graphs in turn. I used waveform charts rather than graphs for simplicity, but I'd be a bit surprised if the change was the cause of problems.

I index the middle graph and make the plot red to demonstrate setting properties for specific graphs - you could bundle anything you want in the setup loop (like a name, a data source queue, etc). You might also consider a Map here if you do name the graphs/queues.

Edit: example front panel, and a warning - I failed to set a different default color, so the middle graph appears blank if you don't change the color box constant before running - oops!

[drjdpowell]

@cbutcher, 

If you're using the 0x40 pool-of-clones option, pull the Open VI Reference outside the For Loop.  You only need one pool; you are creating three different multi-clone pools but only using one clone from each.  Will work but with high overhead.

[cbutcher]

---

@drjdpowell wrote:

@cbutcher, 

If you're using the 0x40 pool-of-clones option, pull the Open VI Reference outside the For Loop.  You only need one pool; you are creating three different multi-clone pools but only using one clone from each.  Will work but with high overhead.

---

Oops. Guess that's one of those common mistakes/things people often miss...

Here's an updated version correcting that mistake, with a more moderate size for the front panel and color box default set to red as well.

[drjdpowell]

---

@cbutcher wrote:

---

@drjdpowell wrote:

@cbutcher, 

If you're using the 0x40 pool-of-clones option, pull the Open VI Reference outside the For Loop.  You only need one pool; you are creating three different multi-clone pools but only using one clone from each.  Will work but with high overhead.

---

Oops. Guess that's one of those common mistakes/things people often miss...

---

It's very common.  The documentation on the 0x40 option is confusingly written, and people think that it is needed to do reentrant VIs (as the OP did), rather than a special way to do reentrant VIs.

[drjdpowell]

Just to emphasise, but the other OP assumption was that a subVI in a sub panel automatically implies async call by reference and subVIs with a loop and lots of communication plumbing.  This is overkill unless one has some other reason for such complexity.

[cbutcher]

For the sake of ease of viewing, here's the block diagram for the updated caller (in my previous post).

The rest is largely unchanged, so I'll try avoid wasting too much vertical space by reposting them...

[tst]

As suggested in the discussion, 0x40 is probably not a good option for you. Just use 0x80 for each VI and make sure it's reentrant.

Also, as others suggested, rolling your own framework is probably not desired. While this can work, getting it right is tricky.

As a side point, you can actually pass values to the VI if you use the Run VI method, but using an ACBR is preferable. I probably didn't use it in the example you linked to because it didn't exist in the version I had open at the time. The example was also focused entirely on the array of subpanels concept.

[Basjong53 · Accepted solution]

Sorry if bumping and old topic is not allowed, but I've finally gotten around to investigated this problem again. As suggested, I've abandoned the idea of creating my own framework and starting learning about the NI Actor Framework. I've created the attached example that does exactly what I need. Even though the Actor Framework may be a little overkill for this particular case, I'm happy that it's modular and in the future it'll be easy to add additional features.

Feel free to make suggestions or correction to this basic code, I've just started learning about the Actor Framework 😉