02-02-2009 01:53 PM
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.
02-03-2009 04:04 PM
02-03-2009 05:35 PM
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?
02-04-2009 09:56 AM
... 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?
02-04-2009 10:52 AM
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?
02-04-2009 11:32 AM
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.
02-12-2009 12:10 PM
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.