LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

DAQmax - USB-6211

Hi,

 

I have created this VI in which I start generating on two different AO channels. Then the VI pass to TS the Task so that I can stop it when I need silence. It was already working when the stop and close DAQmx VIs were inside the attached vi. But now when I run it, I obtain this error.

 

Zuc_Lab_0-1719482095161.png

 

 

I don’ understand why is there anyone who can help me? I’m using LabView and TestStand 2021.

 

Do you have any advice on how to use correctly the DAQmx tasks? 

 

Thank you for the help!

 

Best Reagrds,

Zuc

0 Kudos
Message 1 of 14
(841 Views)

Hi, Zuc.  I tried to open the Zip file you attached, but the VI "Audio Generator_MultiChannel_ON" didn't open properly on my system.  It also seems to be equally "openable" with LabVIEW 2019, not generating a "Wrong version of LabVIEW" error (which I'd expect if it really was saved in LabVIEW 2021), but just hanging.

 

The Error Message suggests that you've got a problem with a Task or DAQmx "Channel" (physical or virtual, not sure) input to a DAQmx function.  Can you attach the main VI (or the one that does the bulk of the DAQmx processing) without zipping it?  Very hard to speculate where the bug might be if I can't see the code ...

 

Bob Schor

0 Kudos
Message 2 of 14
(802 Views)

The error text is pointing you in the right direction.   You've defined a task with 2 AO channels.  But in your For Loop, you auto-index on your "Output Array" which only contains parameters for 1 waveform.  Thus the For Loop only executes for 1 iteration, and the auto-indexed output tunnel containing your array of waveforms only contains 1 element.  And thus the error text you read -- 2 channels, data for only 1.  This should already have been visible in your graphs where you'd only see data in the first but not the second.

 

Define parameters for your 2nd AO channel by populating the 2nd element of "Output Array".   (This will work even if you use the same values for both Output Array elements, though if that were the case there would be other simpler ways to make it work too.)

 

 

-Kevin P

ALERT! LabVIEW's subscription-only policy coming to an end (finally!). Permanent license pricing remains WIP. Tread carefully.
0 Kudos
Message 3 of 14
(794 Views)

Hi,

 

yes you are right! in fact my problem was the waveform array, that by default it had only an element but for running it right it needs two elements, or better the same amount of the channels in the task.

By the way, the Task_out from a VI with more than one channel in the task must be a simple variable or an array? I found problems in closing the task like this

 

Zuc_Lab_0-1719563955895.png

 

Thank you for the help!

 

Best Regards,

Zuc

0 Kudos
Message 4 of 14
(781 Views)

Can't really say anything for sure because the call to DAQmx Stop must lie elsewhere in the parts of your code we haven't seen.

 

In general though, a task containing multiple channels is still a single task.   You won't need to give it any special treatment or handling to close it just because it has multiple channels in it.  The task is not an array, and within your LabVIEW program neither is it a variable, at least not in the sense normally meant in common text languages.

 

If forced to guess, I might suspect another For Loop issue since that's where this thread started.  Are you calling DAQmx Close in a For Loop?   If you close your single task on the first iteration, any subsequent iteration will produce an error (and probably the one you posted though I haven't verified that).

    One other common possibility is failing to feed a task wire through all cases of a case structure, which often results in a default output tunnel value that represents a NULL task.

 

In any event, that problem is somewhere other than the code we've seen here.

 

 

-Kevin P

ALERT! LabVIEW's subscription-only policy coming to an end (finally!). Permanent license pricing remains WIP. Tread carefully.
0 Kudos
Message 5 of 14
(763 Views)

Hi Kevin,

 

Thank you for your response! What I do in my TS sequence is calling the Audio Generation_MultiChannel_ON.vi for starting the audio, as you can see from the code the VI has the task as an output. Then, when I need, I call the Task_OFF.vi who receive the Task of the previous vi as an input to close the task. In a simple sequence everything works fine but when I call them in a more complex sequence it seems that the Audio Generation_MultiChannel_ON.vi does not give any value to the Task_out variable but it does not throw any error so I do not get what happening.

 

Thank you for the help!

 

Best Regards,

Zuc

0 Kudos
Message 6 of 14
(749 Views)

Hi Zuc,

 


@Zuc_Lab wrote:

What I do in my TS sequence is calling the Audio Generation_MultiChannel_ON.vi …Then I call the Task_OFF.vi

In a simple sequence everything works fine

but when I call them in a more complex sequence it seems that the Audio Generation_MultiChannel_ON.vi does not give any value to the Task_out variable


So it seems the problem is in your "more complex sequence": are you sure you handle the task reference in there correctly?

 

(Why should TestStand give an error just because a variable doesn't has the expected value? Again: check your sequence…)

Best regards,
GerdW


using LV2016/2019/2021 on Win10/11+cRIO, TestStand2016/2019
0 Kudos
Message 7 of 14
(747 Views)

Hi GerdW,

 

yep i was checking it but since i simply call the VI and pass the task_out from the vi to a FileGlobals variable assigned for that purpose i don't know what i can make wrong! But thank you for the advice i will try to go deeper in the debugging!

 

Best Regards,

 

Zuc

0 Kudos
Message 8 of 14
(738 Views)

Hi,

 

but is it normal that also when i run the vi not in a sequence i don't see any value in the task_out variable on the UI?

 

Best Regards,

Zuc

0 Kudos
Message 9 of 14
(725 Views)

Hi Zuc,

 


@Zuc_Lab wrote:

is it normal that also when i run the vi not in a sequence i don't see any value in the task_out variable on the UI?


This could happen when there is an error upstream…

 

Btw. in the first moment I missed the TaskOut connection because you used a very unusual connected ConnectorPane: TaskOut should be placed in the upper right connector of the 4224-pattern!

Best regards,
GerdW


using LV2016/2019/2021 on Win10/11+cRIO, TestStand2016/2019
0 Kudos
Message 10 of 14
(721 Views)