DAQ Assistant in subvi not updating output to DAQ board with each call...

[jkeane3]

Hi All,

I am calling a simple subvi that creates a user-defined number of pulses with "Square Waveform.vi."  This square wave (with the given total number of pulses) is then used as an input to a DAQ Assistant controlling an analog output signal on a NI USB-6259 DAQ board.  I am using Labview 8.5 right now.

However, each time I call this subvi from my main program, the output I measure from the DAQ board is identical to whatever I set in the first call (i.e., if i created two pulses in the first call, I get two pulses on every call, regardless of the input I feed to the subvi).  The multiple calls to this subvi are made in sequential frames in a stacked sequence.  I believe stacked sequences are frowned upon by good labview people, right?  But putting that aside for the moment...

The "#-of-pulses" input I give to the subvi is updated in a subvi front panel number indicator and a graph of this waveform.  Just not in the real output I measure from the board.  Why is the hardware output being asserted (with the original input value) before this new number can reach the DAQ Assistant?

The sloppy fix to this is just to put that square wave creation code in my main program each time I need it.  This does work and fixes my problem.  However, I would like to use subvis to keep things clean.

I am not a good Labview programmer, but have used this software for a number of projects and am stumped by this.  Any ideas?

Thanks,

John

[Dennis_Knutson]

Can you attach your main and subVI for someone to look at?

[jkeane3]

Yes, sorry...I know I should have done that right away.  But I don't have access to that code at the moment. 

Will do tomorrow.

I was wondering if this was some obvious kind of problem where the original input parameter I passed to the subvi (and in turn the waveform it created for the DAQ Assistant) is caught in memory.  It's just weird because I see the new inputs reflected in the front panel of the subvi...just not in the real outputs from the DAQ board.

[jkeane3]

Here is some example code.  "TopExample.vi" calls the subvi "CreatePulsesExample.vi".

TopExample is hard-coded to create one 5V pulse through CreatePulsesExample right when it is started.  Then in the next stacked sequence frame, it waits for the user to hit a continue button.  After the user hits that button, TopExample should create five 5V pulses through the subvi.

These new 5 pulses do show up in the control box and graph on the front panel of the subvi, but they do not show up at the actual output of analog channel a0 on my NI USB-6259 board.  Instead, only a single pulse shows up on the oscilloscope.

No matter how many pulses I request from the first call of CreatePulsesExample, that number shows up at the hardware output on the subsequent call.  So for example, if I tried to create five pulses with that first call, five would be created in the next call regardless of how many I request.

Does anyone know what I am doing wrong?

[jkeane3]

bump.

one more try.  am i just making a dumb mistake?

thanks.

[Dennis_Knutson]

I don't see anything offhand. When you just run the subVI, do you see the expected number of pulses? What are you using to detect the pulses?

[jkeane3]

I do see the expected number of pulses on the front panel indicators.

However, I do not see those pulses when I probe the DAQ board output with an ocilloscope.  In that case, I always see the original number of pulses repeated any time I call the subvi.  

I have tried this a number of ways, but can't get past the error.  However, I'll try some more now...

[John_P1]

Hi John,

I am running your code over here and seeing the same results.  I believe the problem is that the DAQ Assistant is being called inside a loop (really a sequence structure, but nonetheless more than once).  Sometimes it is difficult to troubleshoot the DAQ Assistant in cases like this--it is trying to be "smart" and seems to be avoiding re-configuring its parameters inside the loop.  This is intended to improve loop speed for when customers are performing continuous operations.  In this case, it is performing a finite generation, and the number of samples generated appears to carry over from one loop iteration to the other.

It sounds like you have discovered one workaround for this already: putting a DAQ Assistant in each frame of the main VI.  Two other options that come to mind are:

1. Use the lower-level DAQmx functions inside the sub VI.  Here you will have explicit control over when the task is created and cleared, and when parameters are set.  You can find examples of how to use the DAQmx API in the Example Finder at:
   Help >> Find Examples... >> Hardware Input and Output >> DAQmx
2. Write a consistent amount of samples to the DAQ assistant by "zero-padding" your signal.  For example, instead of writing [10, 1010], try writing [1000, 1010].  In this case, it wouldn't need to reconfigure the number of samples to generate.

One lesson to take away here is that the DAQ Assistant is good for basic functionality, but for more advanced control over the execution and configuration of your task you should learn to use the lower-level DAQmx functions.  In this case it sounds like the problem is actually a bug.  I'll file a bug report, since the DAQ Assistant is not checking for waveform timing changes even though your timing is set to Use Waveform Timing.

Thank you for pointing out this odd behavior--out of curiosity which version of DAQmx are you using? 

-John