LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

labview 8 program design - multiple VIs, passing data, algorithmic help needed =)

    Hello, I'm new to the labview environment and I have some questions that I am hoping some of you may be able to answer.  I think that this simplest thing would be for me to describe what i want to do so that everyone is clear on what's happening.

    I need a program that controls and older GPIB piece of equipment as well as a brand new high speed digitizer scope (pxi-5114).  Here is what I would like to do...  Among other things, I would like the main VI to have two buttons on it that can be used to open and change settings on the two subVIs that correspond with the GPIB device and the scope.  However, I need to be able to interact with both of these subVIs at the same time (meaning, I need both of them open) in order to find the right combination for data acquisition.  this means that i need to be able to pass data back and forth between the subVIs and mainVI (and possibly between the subVIs, but I'm not sure about that part yet).
    (1) For the GPIB device, I essentially set scan parameters which generate a 1D array of values that will be passed back to the main VI.  So that the main VI can then execute a series of tasks for each index in the array.  Up until now, I have been able to accomplish this task using globals, but after having read through ~ 15 different threads posted in this forum, I've decided I'll probably switch over to using queues because using globals can get pretty messy and they really disrupt the program flow.  That being said, I want to be able to click the "GPIB device" button on mainVI and have another VI popup (i'm confused about how exactly to implement this still -- i feel like I could use a subVI, or use dynamically loaded VIs and i'm not sure about the pros/cons of each).  I'd like to input some values, ... hit 'load values' on the GPIB device VI and have the array be passed back to the mainVI for further use.
    (2) for the scopeVI, I feel like things are much more complicated, but perhaps I'm just not thinking about it clearly yet.  For each member of the 1D array generated in (1), a 'scan' will be run that generates another 1D array as a function of time.  Basically, in the experiment, I have a signal coming in that is time dependent.  I have a master external trigger that is 10Hz and will dictate the collection rate.  I will have parameters in the scopeVI (or whatever) that I will need to adjust (# of sweeps to collect/average per scan, horizontal,vertical, sample rate, record length, etc.)  These parameters are set at the beginning of the experiment, but do not change over the coarse of the experiment (which leads to a question i will address later).
    (3) mainVI.  This is the most loosely defined section as of yet.  I may incorporate some data analysis/signal processing, etc into this section, but I can add those features later.  For now, I want to be able display the result of each 'scan' as it is collected (i.e. - pass the data from scopeVI to mainVI).  Since this is a 10Hz laser, If I take 30 sweeps per scan, my mainVI display will update ~ 1 time every 3 seconds or so.  At the end of the experiment, there will be a 2D array of data.  somewhere in mainVI, I need to include write/save capabilities, but I think I can handle that part on my own as well.

    My primary concerns are:
i. do people have suggestions for the way I should design this program? -- i.e. - using queues, notifiers, reference controls, VI server, etc. and the benefits/pitfalls of your choice?? as I said before, I have read enough to lead me away from using global vars...
ii. There were a lot of example VIs that came with the scope hardware.  There's no need for me to rewrite a bunch of code, so I will just modify one of those VIs to use as scopeVI.  However, the questions that arise with this VI are
    a. I want it's values to exist for the duration of the lifetime of mainVI.  I don't want to dynamically load it (and it's default values) every time I reopen it by pressing the 'scope' button on mainVI.
    b. I want to pass the data that is collected by scopeVI back to mainVI for further processing... I essentially want to keep all of the processing of the signal in mainVI and keep scopeVI strictly as a way to define experimental parameters


    I think that's about it.  I'm more than willing to discuss things further if that would help in your analysis.  Thanks for any information that you're willing to share with a new guy to this language!

-Z   (wazgrp@yahoo.com)
0 Kudos
Message 1 of 7
(3,254 Views)

I think that you would be best off using queues in a producer consumer design pattern.  Your main VI would create the queues and pass a queue reference to your subvi's.  While the subvi's enqueue data you could have a consumer loop in your main vi that dequeues the data and processes it.  In this instance your main VI would have 2 loops.  One would be for responding to the user interface (and launching subvi's) and the other would be the consumer loop that processes the data.

If you want to retain the data in a subvi for the life of the main VI I would store the subvi's data in an ini or xml file.  This way, every time the VI runs it could look at this file and restore any values that it had previously.

Justin D
Applications Engineer
National Instruments

0 Kudos
Message 2 of 7
(3,218 Views)
Hi Justin,

    Thanks for your response.  I have been reading about the producer/consumer approach all day, and I think it may be exactly what I need.  I do however want to ask some questions about the 2nd point you raised.  If I'm going to use an ini or xml file, why wouldn't i just use global vars that pass values into the subVIs which overide the defaults - these globals can then be updated prior to when the subVI is closed??  I feel like there should be a better way to do this, but it's not at all obvious to me, and I'm not sure how the ini or xml approach is any better than globals?

-Z


I am still interested in any input that anyone else has on this topic...... :mansurprised::manhappy:
0 Kudos
Message 3 of 7
(3,202 Views)
Hi Z,

A global has the disadvantage that it doesn't remember it's values between several runs of the application. An ini file has this options.

Ton
Free Code Capture Tool! Version 2.1.3 with comments, web-upload, back-save and snippets!
Nederlandse LabVIEW user groep www.lvug.nl
My LabVIEW Ideas

LabVIEW, programming like it should be!
0 Kudos
Message 4 of 7
(3,192 Views)
thanks TonP.  I understand the point your making.  Perhaps my original question wasn't very clear - I'm not worried about the same values showing up when I close the whole application and then open the whole application.  I was more interested in maintaining the values when I close one subVI and then reopen it.
    Last night, I spent quite a bit of time reading about control references, and then I found that I could avoid using global vars if I just put used control reference controls in the subVIs and hid the actual controls on the mainVI front panel.  That way every time the subVI is opened, the parameters are passed in from the hidden reference controls on the front panel, and every time the subVI is closed, the mainVI values are updated using the control reference controls.
    It's clear to me what I'm saying, but as I reread that last paragraph, it's not easy to read.  Do you understand what I'm saying?

-Z
0 Kudos
Message 5 of 7
(3,175 Views)
Hi zskills,

you should use a while loop and unintialized shift registers, if you take a look at he NI ptbypt VI's you will get the idea. To gather more knowledge about this structure search for
'LV2 globals' or 'functional globals'

Ton
Free Code Capture Tool! Version 2.1.3 with comments, web-upload, back-save and snippets!
Nederlandse LabVIEW user groep www.lvug.nl
My LabVIEW Ideas

LabVIEW, programming like it should be!
0 Kudos
Message 6 of 7
(3,168 Views)
to TonP
    As an excercise, I've now done this with globals, shift registers, queues, and control references.  All have worked, but I think i like the shift registers the best with respect to solving the first problem (1) that I listed in my first post.


to others
    However, I am still interested in additional algorithmic approaches to parts (2), (3).



keep it coming!
-z
0 Kudos
Message 7 of 7
(3,154 Views)