Generate Finite Analog Output Waveform on Demand

[dmhuffman2010]

2. I'm having problems grasping exactly what you're laying out here - sounds complicated, but I'll search for the "QMH template" you've referred to.  From the little research I've done, I have seen that the QMH template ships with LV2012 and later.  I am running 2010.  Would it be possible for you to save this as a 2010 compatible version for me?

3. I'm not planning on executing the "Configuration" VI every call, it would call once, at the beginning.  Essentially I was planning on dropping the whole "MainVI" block diagram into my other VI, and let the loop with GenerateAO vi run in parallel with my acquisition loop.

[Kevin_Price]

2. It isn't necessary to delve into all the QMH stuff right now.  Go ahead and take a look before deciding, and if it seems as complicated as you expect, never mind it.  (If you keep doing more LabVIEW, it'll eventually be worth your while to get familiar with patterns like the QMH, but it may be a lot to swallow in one bite.)

3. Ok, good.

Now go on ahead and scrutinize your use of booleans that drive your software versions of a trigger (transition driven) and an enable (state driven).  I suspect you'll find some issues around that area somewhere.

-Kevin P

[dmhuffman2010]

Well in the mean time, I am going to be having to use this very soon for a study and need it to generate the output reliably.  Do you have any suggestions as to how I can get the "GenerateAO" vi to work for the time being? 

[Kevin_Price]

Like I've been saying, I don't think the main problem is the DAQ code you've shown.  I think it must be in the decision-making code that triggers or enables it, which hasn't been shown.

-Kevin P

[dmhuffman2010]

But shouldnt the MainVI code run as expected then? If I was able to trigger a finite AO each time I pushed the switch, I would agree with you, but since it doesn't generate the output correctly when triggered by the boolean switch, I don't see why the way I am doing the decision making in my other VI would produce any different result.

I'm not trying to argue. This may be (and more than likely is) a lack of understanding on my end.

My idea was that the loop in the MainVI would run fairly fast, then once an iteration comes and the switch is on, it would enter the GenerateAO VI, generate an output  (in this case for one second) following which it would stop the task. Since I have the boolean control set to switch until released, the next iteration of the loop would not cause an ao, so we would be back to running freely until the switch is again pressed.  However, the next time I press ithe, it generates a portion of a second, rather than the entire waveform.

I know I've already stated this - just wanted to make sure I'm relaying information clearly.

[dmhuffman2010]

Anyone have any insight here?

[Kevin_Price]

Just aiming for understanding here too, no worries.

The fact that your DAQ code runs correctly 1 time indicates that you're at least pretty close.  Let's break it down for troubleshooting purposes.

Take your MainVI code and run it all by itself, completely separated from any of your other program logic.  Temporarily substitute a True constant in place of the GUI switch named 'Stimulate'.  Run in highlight execution mode and look for any DAQ errors.  What happens on the 1st iteration?  What happens on subsequent iterations?

-Kevin P

[dmhuffman2010]

To clarify, I have been running this 'mainVI' alone so far to isolate issues with my larger control VI.  I did as you suggested, and wired a True to the case structure.  I placed 5 error probes (see screenshots), which all returns no errors.  I have the device set to generate a 500Hz waveform so I can audibly hear it.  The first time the 'GenerateAO' subVI is called, I hear a smooth 1 second tone when the Start Task VI is called.  However, in subsequent loops, it sounds as though it is only writing a small number of samples each write, as the tone sounds like you are flipping a switch on and off very fast, almost jittery if that makes sense.  If I highlight execution, then each time the Start Task VI is called it generates a smooth one-second tone.  

Its almost as if the GenerateAO subVI is not waiting for the complete 1 second task to be completed before it calls again and is 'restarting' the task at a very high rate.

[dmhuffman2010]

Aslo, I realized that I had changed the stop condition in the 'GenerateAO' VI.  Trying a trial-and-error approach, I had wired the boolean 'task done?' output from the 'Daxmx Is Task Done' VI (seen in recent screenshot GenerateAO).  I changed this back to my original stop condition (error status or stop button as in older screenshot) and it no longer produces the jittery tone on iterations 2-n.  However, the 'GenerateAO' VI seems to get stuck in the loop while checking if the task is done, as it never leaves until I hit the stop button in the sub VI. Upon hitting the start button, the 'GenerateAO' VI executes again from the MainVI, and generates a smooth 1-second waveform each time.

Should I just get rid of the 'Is task done' loop in the GenerateAO vi?

[Kevin_Price]

Please post actual runnable code and identify your DAQ device.  It *does* sound like your "Is Task Done" monitoring loop is terminating prematurely.  Are you configured for Finite or Continuous sampling?  Are you still specifying "Do Not Allow Regeneration"?  What are the values used to define the waveform and task timing?

Note: "switch until released" is a pretty unusual mode for a boolean gui button in my experience.  I would typically go with a "switch when..." mode for state-driven behavior or a "latch when..." mode for transition-driven behavior.  I still haven't let go of the possibility that the gui boolean is part of the problem

-Kevin P