Dynamic UI for set of HWs: Array of subpanels

[FrasseKatt]

I have a case where a user is supposed to control and run test on a number of connected products (gas analysing probes).

Each product is connected with an RS232 port and also to its own water pump. Before running the tests, the user should assign an RS232 port and a pump ID to each product. When that is done, data like serial number, FW version and status (OK, clogged...) is shown.

A UI good solution would be an array of clusters containing some controls (COM port, pump ID) and indicators (serial number, FW version, status), but this can't be implemented in LabVIEW.

However, each product can preferrably be controlled and monitored with a sub-VI and as all products are identical (except serial numbers and so on), instances of the same VI file can be used (with re-entrant and so on). The front panel of the sub-VI would look something like this:

Now you could show all these front panels as subpanels in the main VI, but the only way to do this in today's LabVIEW seems to be placing as many subpanels you would need on the front panel.

However, this design is really poor as it wouldn't be scalable. The ideal solution would be having an array of subpanels:

Then you could add and remove subpanels/products as you like, and also easily step through them by using a for loop in the code. The thing is that this can't be implemented in today's LabVIEW.

I really encourage NI to implement this feature as it would give a lot of benefits for both the user and the programmer.

I also encourage all the readers to kodus my suggestion.

[wiebe@CARYA]

>The thing is that this can't be implemented in today's LabVIEW.

It's easy to fake though. Simply add enough subpanels and arrange them to look like an array.

I don't think it will be feasible (technically) or they would have implemented this. I'm sure it's been suggested before, right from the subpanels introduction. I can't find an idea exchange post about it. That doesn't mean anything as the idea exchange search function is 'pretty poor'.

I'll kudo this anyway.

[AristosQueue (NI)]

This idea cannot be implemented. To be well defined, the drawing of elements within an array control must be based exclusively on the static values of the array (i.e. the refnum, not the thing referenced by the refnum). Array elements are statically drawn on demand in order to be efficient. Any sort of registration/deregistration as you moved through the array creates weird race conditions. The IMAQ refnum attempted something like this years ago... it never really worked, and we understand better now why that doesn't work... and won't ever work. LabVIEW NXG has discussed mechanisms for dynamic subpanels totally divorced from array data display... you may see a solution to your underlying issue (displaying a list of subVIs) in that platform a few years from now.

[AristosQueue (NI)]

PS: To further clarify the issue: Writing to an FP terminal doesn't allow for an error to be returned. The subpanel control doesn't have its own FP term because setting the refnum might error out for any number of reasons. Even having an array control of VI refnum type would necessitate moving away from the array terminal. It essentially must become a different type of control than an array.

[Darren]

Declined for reasons listed in AristosQueue's replies.

[Darren]

Here's one trick you can use. This is an array of cluster controls. I have colored the numerics and strings to look like indicators, and I have disabled them (right-click > Advanced > Enabled State > Disabled). This gives you a UI element where the user can operate the COM port IO control and the Pump channel menu ring control, but they can't click on anything else.

[FrasseKatt]

AristosQueue, thanks for sharing your knowledge around this topic.

DNatt, this is acutally the workaround I'm using, but it feels like a bad solution and I'll keep looking for better ones.

[wiebe@CARYA]

It's still weird that it's fairly easy to make ourselves (a scrollbar, a few subpanels ordered correctly, a bit of glue code)...

@AQ: It essentially must become a different type of control than an array.

OK, so can we have something that looks exactly like an array of SubPanels, but isn't an array of SubPanels?

I don't really care if it's formally an array. I just want the behavior...

[AristosQueue (NI)]

> OK, so can we have something that looks exactly like an

> array of SubPanels, but isn't an array of SubPanels?

As I said, NXG has discussed plans for something like this, but exactly what it would look like is unknown, and it is far down their priority list at this time.

[wiebe@CARYA]

@AQ:

My last NGX try out (at NI Week) actually was pretty good. And they have a pretty high feature\issue burndown. NXG is starting to get useful. I'll wait for it...

[tst]

---

@FrasseKatt wrote:

The ideal solution would be having an array of subpanels:

Then you could add and remove subpanels/products as you like, and also easily step through them by using a for loop in the code. The thing is that this can't be implemented in today's LabVIEW.

---

It's certainly possible to create an "array" of subpanels using the techniques already mentioned here of having enough subpanels to contain all of the VIs, or even of having enough subpanels to contain the visible VIs and cycle through VIs as the array is scrolled through. It's helpful if you hide all of this complexity in a lower level.

I posted some basic examples of how this can work before and I believe I saw others who posted examples too, although I can't recall who and where offhand. You can start here for my example -

https://forums.ni.com/t5/LabVIEW/User-interface-problem-list-of-clusters/m-p/2311770#M726599

https://forums.ni.com/t5/LabVIEW/Independent-cursors-on-array-of-cluster-of-graphs-or-work-around/m-...

I do have an XControl using the same basic concept as the example, which acts as an array of subpanels and hides the complexity and allows you to simply add VIs to the array. I can't share that, but it does show that this can be done.

As also mentioned, this won't have a value you can interact with ("step through them", as you say). As shown in the example, it will be your responsibility to open and run the VIs, communicate with them and manage the data they represent and what they do, but that comes built-in with subpanels, so it shouldn't be a surprise.