Generate Finite Analog Output Waveform on Demand

[dmhuffman2010]

I am configured to Finite Samples, 10k samples @ 10kHz, "Do Not Allow Regeneration."  Im not sure what you mean by "the values for waveform and task timing," unless you simply meant number of samples and sampling rate.  I'm currently running through a NI USB 6211, and sending through channel AO0 timed with the Onboard clock.  

The mechanism behind the boolean switch isn't a major concern for me, as it will be replaced by a boolean local variable later. It was just a way for me to check if the AO was being generated as I expect.

[Kevin_Price]

Yeah, I meant things like # samples, sampling rate.  Comments from running on my end:

1. I do not have a USB device here so I had to bypass the code that sets up USB bulk transfer in the config.

2. I used a compound Boolean OR node in the "Generate..." subvi to terminate on Error OR Stop Button OR Is Task Done output.

3. After that it ran fine.  It would iterate over the "Is Task Done" query dozens of times until the output turned True after a second.  Error and Stop button were always False.  The main outer loop would immediately start a new finite generation which would again run for a second, terminate, and repeat again ad nauseum.

4. I also tried hooking up the "Stimulate" GUI button in place of the True constant.  It continued to work fine, running 1 time for 1 second for each press of the button.

Attached is the modified "Generate" subvi.  My DAQ hardware is a PCIe-6341.

-Kevin P

[dmhuffman2010]

Im stuck in the stoneage with LabVIEW 2010.. could you save a compatible version so I can see what you did? 😕

[Kevin_Price]

No prob, here you go.  You'll see it's a trivial change, just reverting back to more like where you started from.

-Kevin P

[dmhuffman2010]

Its telling me its a 2012 version, maybe a snap shot would be easier.  I added the compound or statement in the Is Task Done loop in GenerateAO vi, but I'm still getting the same 'jittery' behavior after the first write.  Here are snapshots of my current VIs. Look the same as yours?

With a T wired to the case structure, I would expect the loop count in the MainVI to update approximately once per second, but after being 0 for the first second it goes on to update VERY fast, resetting the Waveform written each time and making the 'jittery' output.  

[Kevin_Price]

Sorry about the version mixup, mistake on my end.  Your pic is exactly the same as what I did though.

Which of the 3 inputs is going instantly True to cause your "Generate" loop to terminate?  If it's the "Is Task Done" output, I can only say that it doesn't behave that way here.  Differences are that I'm using a PCIe plugin card in my desktop, and because of that I bypassed the Config code that specified USB Bulk Transfer.  Can you try bypassing that in your config too?

Also, if any runs produce an DAQmx error, post the error #.

-Kevin P

[dmhuffman2010]

Thanks Kevin,

Yes, it is the Task Done? boolean that is going right to True.  The first time the GenerateAO is called, the Task Done is False for a sec then changes to True, but going forward it flips VERY fast between T and F.  Looks like the first iteration of the Task Done loop its false then the second time it is true, instead of staying F for seveal iterations as it does the first time it is called.

I tried bypassing the USB Bulk config with a disable structure and that didn't change things.  As I mentioned before. If I highlight execution within the GenerateAO vi, everything runs as expected (I assume because the task has time to complete before it is re-executed.  You didn't add any Wait commands or anything in there anywhere did you?

I can't figure out why the Is Task Done VI is working correctly on it's first call, but after that it acts like the task in immediately done.  Could it be an issue with Task Names? Does LabVIEW reassign Task Names every time it starts an "unnamed Task"? (i.e. name it UnnamedTask2A the first time but UnnamedTask2B the second time). Because if so, that would make sense because the same Task Name is going into the Generation loop in the Main VI each iteration.

Sorry if that's ignorant. I'm not savvy with the background workings of daqmx.

[Kevin_Price]

I'm attaching the code as I ran it.  You'll only need to fill in the device & channel for the AO signal, I left that blank by default since we have different hardware.  No extra waits or anything like that.

I don't see the issue you keep seeing.  The DAQmx Task refnum created by the initial Config has no problem being reused through several start/stop cycles on my end, using a PCIe-6341 and running DAQmx 16.0   Each start/stop cycle takes a second (as expected), "Is Task Done" returns False repeatedly until the end of that second, then the next cycle begins immediately (as far as one can observe with gui indicators and software probes) and takes its own full second, etc.

Now I wonder if the issue is something about either your particular USB device or its compatibility with your DAQmx version.  I've heard of some other occasional limitations of the USB version of DAQ devices.  Are you sure there are no DAQ errors also being thrown on iterations 2+ when "Is Task Done" == True immediately?

-Kevin P

[dmhuffman2010]

I think you're right.  When I simulate a NI USB 6211 in MAX, the VI runs once per second as expected.  However, when I run it with either an actual USB6211 or USB 6218BNC I get the "jittery" behavior after the first iteration.  Unfortunately, updating daqmx isnt an option, because software we use that incorportates daq boards runs unreliably if we use a new version.  Do you think that updating the device drivers or firmware could resolve the issue?

[dmhuffman2010 · Accepted solution]

Called NI today about this, and they helped me to get it working.

Turns out all we needed to was to unreserve the task after stopping it. After that, it seems to be running as intended!

I attached a snapshot of the GenerateAO vi for reference