Managing Large number of controls and indicators

[spastichawk]

Working on a test bench for doing some device characterization. There are 16 devices that are being tested at the same time with 15 front panel items for each. The front panel items are a 50/50 mix of controls for configuring VISA resource, and indicators with runtime data and test stats; all this totalling 240 items that need to be dealt with on the block diagram. I want to stay away from arrays for the front ppanel items as it creates UI organizational issues. Can someone suggest some methiods of handling this large number of items cleanly in the VI block diagram?

[PalanivelThiruvenkadam]

You can create a cluster of controls :
If visa resource are the one which create a mess in front panel you can create a configuration tool which will be saved in file and retrive from file internally and use inside the code where it satisfies both configuration method as well as reduces front panel objects

[crossrulz]

I would use subpanels and load up VIs into those panels that run in parallel.  Then you have a VI dedicated to each device.  If they are all the same, you could actually have 1 VI that is reentrant and just load up the different clones into the respective subpanels.  This will greatly reduce the number of items you have to maintain on a single VI.

[mikeporter]

I really like the structure that Tim suggested. I have used the idea of switching subVIs in and out of a subpanel for years and it works really well. You can even include logic to automatically bring a screen to the front if it needs attention.

I also like that you realized that the number of controls and indicators could become a problem. I have seen way too many "wall o' numbers" interfaces over the years that are not only inconvenient, but in some cases were dangerous because they hid information that the operator might need to respond to an emergency situation.

Mike...

[spastichawk]

Im liking the idea of multiple concurrent VI's as well. It definately simplifies many things in the program flow! I will have to do some reading up on how to make this all work.

one concern that i have is does this create resource contention problems over the GPIB interface its talking to since its different channels on the same device that will be accessed?

[mikeporter]

It can, but one way to handle that would be to create a GPIB manager process that mediates all the interactions with that shared resource. The basic idea is that the manager talks to the GPIB and the individual processes talk to the manager.

Depending on your exact needs, the manager could just serve to serialize GPIB accesses, or it could be continually polling devices to obtain data that the individual processes could prescribe to and fetch as needed.

Mike...

PS: You might want to check out my blog (link in my signature). I have written about this structure a lot.

[crossrulz]

If you have subVIs to do the actual communications, then those will act as a blocking mechanism to keep each routine from stomping over the other.  Another option would be to have another loop that just reads the data and then use User Events or Queues to send the data to each/all of the individual unit VIs.