Using VI server to obtain parent level indicator reference.

[8bitbanger]

Hi Folks,

I'm just starting to make more use of the Application and VI server of late, and so I'm not fully up to speed with how things are supposed to work.

Basically I have a top-level VI with an indicator, and two parallel subVI's. We'll call them GUI and ACQ.

Right now I am able to get TOPLEVEL to pass the reference of the indicator to GUI, and GUI uses a property node to update it's value.

My dilema is then how can I get ACQ to also pass that same static reference to GUI? Is there a way to obtain the reference of a specefic 'parent' indicator without explicitly/staticly passing it (ie vie terminals/wires, or other).

Just FYI the indicator is a string debug message window, and the 'passing' is done via queue's.

Thanks for your time, I know this is likely a very basic question.

Kindly,

Jamie

[TCPlomp]

That is quite easily done:

 

Ton

Message Edited by TonP on 12-11-2008 07:14 PM

[johnsold]

Jamie,

If you are "passing" via queues, why not just pass the status message as a string and update the indicator in TOPLEVEL.vi?  I see no need to pass the reference at all for this situation.  Many of my systems contain two or three parallel subVIs and all control and display information is transferred via queues without ever using a reference to access the value in a control or indicator from the subVIs. This includes status strings, numerical values, enums as commands or status, and small arrays of numeric data.  For large arrays of numeric data I usually use Action Engines.

Initialization of  many controls from a config file is one place where I do use the reference method as Ton showed.

Lynn 

[8bitbanger]

Ton: Thanks for the reply - that was exactly what I was looking for, the sequence/nesting of properties to get the control ref.

Lynn: I am interested in hearing more about your main VI topology. The reason I needed the reference was because the subVI handling all of the display updates is inside the GUI subvi - thus I can not update the toplevel indicators without using global variables. I did this *primarily* to try and keep the application uncluttered (see below screenshot). This is a project re-write with over 100 globals and case statements sometimes 12-15levels deep.

Anyway so in the screenshot you'll see the event structure responds to a boolean event, which presents a dialog. Once the info is entered, the event passes a 'changenotice' to the MAIN queue. The main queue stores the data for later calculations in the shift register. Lastly it reports to the GUI VI that the config has changed. This is not exactly a good example for this layout, but it allows any subvi process to communicate with the GUI.

My problem arose in the ACQ subvi. For example the MAIN state machines queues a channel configuration to the ACQ. Rather than having the MAIN subvi report this in the message log, it would be desirable to just have the ACQ handle this mundane function. So each 'process' handles its own reporting, logging, etc unless it needs to report outside.

You'll notice it somewhat mimicks expressionflow's QSM design.

I welcome any suggestions, this was just my first stab.

[8bitbanger]

PS - you'll note that I'm not passing a reference to the messagelog indicator - I have temporarily changed the GUI subvi to write to a global for the time being. Prior it was bundled with the timestamp and string.

[johnsold]

Jamie,

I usually use the GUI as the main VI, partly to avoid some of the problems you are having.

It has a while loop with an event structure to handle most user inputs.  In the timeout case I check the queues which get data back from the parallel subVIs.  If an indicator has changed (there is a flag for this), then the data is passed to the indicators.  Otherwise it waits for the next event or timeout.

I use a cluster typically called "Indicators and Flags" to pass the data around in the main VI.  Unbundle by Name documents which element is being accessed at any point in the program.  The cluster itself does not appear on the main VI panel.  It just carries values which are connected to the separate indicators.  It also had status booleans (Meter Ready, DAQ Loop Stopped, ..) which may never be displayed, but which are the "flags" used to keep track of the status of the parallel loops. 

I do not have a compact example at the moment.  The one I am working on now is too big (and too broken) to post.

Lynn