LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

How to configure test conditions from a file?

Right, in that case you would have to make the code more versatile, such as checking for number of channels desired. If you do choose the VI route, and have any questions, I can try and answer them.

 

 

National Instruments
0 Kudos
Message 11 of 17
(840 Views)
After looking into it some more, I see an expression parser in the examples dir, so I could hack that to handle boolean expressions.  But I'm really not crazy about the extra effort.  It does, however, allow me to parse the string and build up an efficient expression tree structure that can run on the RT target without all the string parsing.  But am I being overly concerned about making the VI method efficient?  I could establish the common interface for all aborts to include an array of names and values.  Then all abort VIs will have to look up the channels they're intested in.  Am I being overly paranoid about searching an array of strings at 100 Hz?  I suppose I could do some tests to measure the time, but what experience do others have?
0 Kudos
Message 12 of 17
(815 Views)

Here's another issue with the VI approach: How can I handle persistence (like "if the pressure is above 50 PSI for more than 3 seconds")?  The test condition VI will be called at 100 Hz (when the card is read) with an array of waveforms and array of strings passed in.  How can it retain state between calls to know how long a condition has been true?

 

0 Kudos
Message 13 of 17
(808 Views)

... And another thing ...  Assuming I can solve the persistence issue (I'm guessing with a USR), how do I get the VI to the RT target?  My app starts on the host PC and deploys to the target.  How do I get it to also deploy the VI that was in the config file?

 

0 Kudos
Message 14 of 17
(788 Views)

Hello,

 

As I was reading through this thread, I realize I forgot to ask for a particular clarification. Do we really want:

 

A)  A VI to write these test conditions to a configuration file (if yes what kind of file format are we talking about) and then this file will be read by your existing test setup (which is a LabVIEW VI?)

 

B) OR we want a VI to hold the configuration data and pass it to your test setup application (again, is this VI?) In this case, do we want the user to be able to specify these test conditions?

 

In both cases, we can keep the data organized using an array of clusters. Each cluster can have a String control for the channel name, a Numeric control for the voltage and another Numeric for the time spec. This way the user can enter values for all of these and we can unbundled this cluster to grab each element inside it and pass it to whatever we need.

 

Are you using a DAQ card? Will you be using the DAQmx VI's to setup your channels?

 

National Instruments
0 Kudos
Message 15 of 17
(778 Views)

Here's how our config file works currently: It's an XML file format and is basically a big cluster of all the things we need, such as an array of channel configuration clusters (name, physical channel, calibration, etc.), an array of filter settings, sample rates, log file names, etc.  The target VI starts and waits for a configuration.  The main VI starts and prompts the user for the test configuration file.  It's loaded in and sent to the target, which initializes all the devices and channels and starts running.

 

So what I was looking for was a way to add the specific test criteria to this configuration file, which may vary from test to test.  The two approaches are string-based or VI-based.  The string-based method is to specify a string in the config file that represents arbitrary combinations of boolean expressions.  I would then need to parse this string, build an expression tree representation, and send that to the target.  The VI-based method is to use a VI itself to represent the specific test conditions.  The config file in this case has the file name for the test condition VI.  The end user would develop the test condition VI to suit the particular test needs.  Then SOMEHOW, the VI would get to the RT PXI target and execute.  I know how to reference the VI on the host and have developed a simple prototype of the concept, but I don't know how to get the VI (loaded at run-time) to the RT target programmatically.

 

0 Kudos
Message 16 of 17
(770 Views)

Hello,

 

I have thought about this and tried and tested this method, you might find it helpful. You can create another VI under your RT target that can ask the user for the boolean expressions, in a popup a dialog or it's front panel or however you would like to grab them. This VI can be called from your main VI programmatically and ask for these values. You would just have to Deploy All before you run the main VI. Here is a screen shot of how to call your 'Test Conditions vi from your main VI. You may then capture these boolean values from the front panel controls of Test Conditions.vi and apply them anywhere.

 

 

National Instruments
0 Kudos
Message 17 of 17
(708 Views)