I have a requirement that I thought would be SIMPLE, but can't get it to work.  I have a 9205 card in a little 9174 cDAQ USB chassis.
My *intended* behavior is to wait (block) at the DAQmx Trigger/Start Analog Edge on, say channel ai1, until I get a falling edge thru, say, -0.050V.  So I have a little vi (that contains 2 parallel loops) that I want to sit & wait for the trigger to be satisifed.  I'm doing "routine" voltage measurements in another AI loop on a different channel.  I want this vi to run separately from my "routine" voltage measurements because I want the app to respond "instantly" to input voltage exceeding a limit to prevent expensive damage to load cells.  I was afraid that if I used either Finite or Continuous sampling to "catch" an excessive voltage, I might miss it while I'm doing something else.  Yes, yes, a cRIO real-time setup would be better for this, but this is a very cost-sensitive task... I just want to "Arm & Forget" this process until it gets triggered, whereupon it fires an event at me.  SO... I'm also reading the same voltage on channel ai0 for regular-ole voltage measurements, and just jumpering them together.  I did this because I read somewhere that you can't use the same channel for multiple DAQ tasks - I *thought* I would need to set up the tasks differently.  {but now that think about it, the setups can be the same...}.
I've set up the DAQmx task the same as shipping examples and lots of posts I've seen.  I'm supplying a nice clean DC voltage to a 9205 card using a high quality HP variable power supply.  Using NI-MAX, I've verified that my 9174 chassis & 9205 are working properly.
THE PROBLEM - When I run it, the vi just sails right through to the end, with no error, and an empty data array out.  No matter WHAT crazy voltage I give the "DAQmx Trigger.vi" (set up for Start Analog Edge), it never waits for the trigger to be satisfied, just breezes on through as if it weren't there.  If I set the Sample Clock for "Finite Samples", the DAQmx Read fails with timeout - makes sense, since the trigger wasn't satisfied.  What could I possibly be doing wrong with such a simple task???????
So my fundamental misunderstanding still vexes me - does the DAQmx Trigger vi not block and wait for the trigger condition to be satisfied, like the instructions state - "Configures the task to start acquiring or generating samples when an analog signal crosses the level you specify"?
I stripped my requirement down to the bare essentials - see the 1st snippet, the 2nd is my actual vi.  Any ideas, anybody?

Hello all,
My question is: what is your preferred non-volatile way of storing daqmx task configurations? 
Backstory: For a long time I've used ini files to maintain task configurations between executions of a program. This has worked for primarily static DAQmx configurations but I'm looking at creating a test executive with some degree of flexibility, which means daqmx task configurations start to get more complicated.
If you use MAX for storing your tasks:  Do you run into problems accessing and maintaining these tasks even though you don't have direct access to the file?  Or is there an unlisted storage location for these files?
If you use ini/text based files:  How do you keep things orderly?  I'm running into all kinds of limitations with the format.
If you use XML: Where did you find your schema?  Did you write it?  I know NI saves tasks as XML files, and so therefore the schema exists, but I haven't been able to figure out how to use it.  I've created a task in my project and then dug through the XML of the project to find the attached image.  I believe this would be the ideal solution, but a little bit of digging in around NI.com (I know...) and google (actually useful) has resulted in no answers.
 
I know there is an elegant answer to this question, I've just not found it yet.  Thanks in advance for your comments. 
 
Cheers,
Tim M

So for a while, I have wanted a good way of identifying my builds and one way is to add build date to the front panel. Typically I had done this manually, I have searched for a good solution for automating this but, but typically the answer is very obfuscated. Then one day I had a thought, I could use VI scripting to generate a VI holding a constant and in a way use it as a pre-processor to make things happen. I'll provide a rough outline and a project of how I made things work. And who knows maybe someone has an even better solution.
I suppose it was kinda obvious that this could be done, now that I think of it. I think lv scripting was introduced in 2012 and is needed for this example. 
First Create A VI that generates a constant via LV script.
Use it in your Top Level VI or wherever you would like the compile time constant to be visible.
Generate a A Pre-build Action.vi that calls your VI generator.
Now you can have compile time constants that are up to date!
I included an example project let me know if the same thing works for you.
 





BuildDateOnPanel Ver12.zip

Hello again LAVAG,
I'm currently feeling the pain of propagating changes to multiple, slightly different configuration files, and am searching for a way to make things a bit more palatable.
To give some background, my application is configuration driven in that it exists to control a machine which has many subsystems, each of which can be configured in different ways to produce different results.  Some of these subsystems include: DAQ, Actuator Control, Safety Limit Monitoring, CAN communication, and Calculation/Calibration.  The current configuration scheme is that I have one main configuration file, and several sub-system configuration files.  The main file is essentially an array of classes flattened to binary, while the sub-system files are human readable (INI) files that can be loaded/saved from the main file editor UI.  It is important to note that this scheme is not dynamic; or to put it another way, the main file does not update automatically from the sub-files, so any changes to sub-files must be manually reloaded in the main file editor UI.
The problem in this comes from the fact that we periodically update calibration values in one sub-config file, and we maintain safety limits for each DUT (device under test) in another sub-file.  This means that we have many configurations, all of which must me updated when a calibration changes.
I am currently brainstorming ways to ease this burden, while making sure that the latest calibration values get propagated to each configuration, and was hoping that someone on LAVAG had experience with this type of calibration management.  My current idea has several steps:
Rework the main configuration file to be human readable. Store file paths to sub-files in the main file instead of storing the sub-file data.  Load the sub-file data when the main file is loaded. Develop a set of default sub-files which contain basic configurations and calibration data.   Set up the main file loading routine to pull from the default sub-files unless a unique sub-file is not specified. Store only the parameters that differ from the default values in the unique subfile. Load the default values first, then overwrite only the unique values.  This would work similarly to the way that LabVIEW.ini works.  If you do not specify a key, LabVIEW uses its internal default.  This has two advantages: Allows calibration and other base configuration changes to easily propagate through to other configs. Allows the user to quickly identify configuration differences. Steps 4 and 5 are really the crux of making life easier, since they allow global changes to all configurations.  One thing to note here is that these configurations are stored in an SVN repository to allow versioning and recovery if something breaks.
So my questions to LAVAG are:
Has anyone ever encountered a need to propagate configuration changes like this?   How did you handle it?   Does the proposal above seem feasible?   What gotchas have I missed that will make my life miserable in the future? Thanks in advance everyone!
Drew

Hello to all.
I would like to know hoe can open my VI with the same configuration. I mean with every indicators, controls, graphs... are equal than when Labview was closed the las time.
 
Is it that possible?
I am asking this because I am developing a vision application with vision and motion toolkit. And a ROI is changed every time when I run again Labview in the same position of display.
 
Thanks a lot.