GUI Optimization and Efficiency

[ErikTheRed]

I'm writing a fairly complicatedlabview program that includes data gathering, computation, graphical display, and an easy-to-use (but cool-looking) user interface.

The program is currently modular. i.e. The GUI can run in parallel with the data acquisition/computation.

The GUI is event driven, but longer computations will queue triggered states for processing so that these events will not slow down event processing and gui responsiveness. The GUI will also have to periodically read from a database and do processing on the data that is returned, which in turn, causes updates to the front panel and image.

The data acquisition is based on a periodic serial read/write as well as writes to a database and calculations on data coming back.

-What is the best way to do this?

-Does anyone have any experience with very complicated code architectures and can offer tips?

-I was thinking about placing the GUI into a subpanel within the daq/parser, but it doesn't load (possibly too complicated?)

Thanks, any help is greatly appreciated!

[ned]

-What is the best way to do this?

-Does anyone have any experience with very complicated code architectures and can offer tips?

-I was thinking about placing the GUI into a subpanel within the daq/parser, but it doesn't load (possibly too complicated?)

This sounds fairly standard to me, not quite as complicated as you make it out to be. My usual approach is to make the GUI the top-level VI and call the processing/acquisition VI(s) as subVIs, usually running in independent execution subsystems, with a cluster of queues, notifiers, or user events to handle communication between the GUI and the processing. The GUI may have several loops - one for handling events, another that constantly reads data from a queue and displays it.

I recently inherited a system with a very different architecture; the GUI itself is fairly lightweight, and each hardware device has its own subsystem with a GUI that runs in a subpanel, again with queues and user events to pass data back and forth. The main executes sequences by sending commands to the hardware subsystems in the appropriate order.

Can you be more specific about why your subpanel doesn't load? It should not be an issue of "too complicated." Do you get any error when you try to load it?

[ErikTheRed]

This sounds fairly standard to me, not quite as complicated as you make it out to be. My usual approach is to make the GUI the top-level VI and call the processing/acquisition VI(s) as subVIs, usually running in independent execution subsystems, with a cluster of queues, notifiers, or user events to handle communication between the GUI and the processing. The GUI may have several loops - one for handling events, another that constantly reads data from a queue and displays it.

I recently inherited a system with a very different architecture; the GUI itself is fairly lightweight, and each hardware device has its own subsystem with a GUI that runs in a subpanel, again with queues and user events to pass data back and forth. The main executes sequences by sending commands to the hardware subsystems in the appropriate order.

Can you be more specific about why your subpanel doesn't load? It should not be an issue of "too complicated." Do you get any error when you try to load it?

Thanks for the reply ned. I suppose that it seems complicated due to the sheer number of loops involved (i.e. event driven master/slave (2 loops) plus the data acquisition loop, and a slave parser loop then adding the event driven real time gui (3 loops). I have been working on labview for a while, but am only recently getting the hang of it from a development standpoint (and sometimes wishing I were back in C!), so I don't know how well LV will handle all of these tasks in parallel. I was trying to simplify the code size of the GUI by splitting the two up... but it seems like the best approach might just be to put them together.

The loading of the subpanel gives no real error. Just that none of the controls/colors/indicators or anything else shows up... it's the same blank screen as before it was "loaded." I can, however, load some smaller VIs that have only simple controls (the current gui does a LOT of image work). Also the fact that I'm using system and custom controls may be an issue? I don't exactly understand the utility of subpanels in this instance, it seems like putting it all together might be the best option...

[ned]

The loading of the subpanel gives no real error. Just that none of the controls/colors/indicators or anything else shows up... it's the same blank screen as before it was "loaded." I can, however, load some smaller VIs that have only simple controls (the current gui does a LOT of image work). Also the fact that I'm using system and custom controls may be an issue? I don't exactly understand the utility of subpanels in this instance, it seems like putting it all together might be the best option...

Are you sure the subpanel is loading? When you say "no real error" have you checked the error outputs after getting the VI reference and after inserting it into the subpanel? After loading the subpanel, with the code still running, create a new VI. Drop the subpanel VI into that new VI, then double-click it to open the VI. See if it shows up in the subpanel (it should). You can also control-double-click to open the block diagram, turn on execution highlighting and see if it's running.

That said, I rarely use subpanels (until I got involved in an application that was already written to use them extensively). I can see them being useful in a plug-in architecture, or possibly if you have a subVI that has its own UI that you want to be able to run either independently or embedded in a larger application. If you don't need that flexibility, consider keeping the entire UI together.