LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

error 200294 in Daqmxstart task

Solved!
Go to solution

Hi,

   I am trying to write and read data at the same time form a cdaq chassis 9172. I have 5 NI A/D cards and 2 NI D/A cards. I manage to code it in a way I can generate and acquire from the same chassis. Though I read data fine but when I am trying to write I get error 200294 at the daqmxstart task.vi. I always thought that I shouldnt start a task everytime I write data but I realize, the task wouldnt start unless i write data first. That is why my start task.vi is inside the loop which is now causing the errror. I am only assumming. can anyone help me code this in a better way to avoid that error?

First pic is how I initialize the channels and set sample clock

second pic is my producer loop, writting and reading.

The remaining part of the code works fine besides the writing data to daqmx write.

 

Admin Note - Attachments removed per user's request

Message 1 of 41
(7,041 Views)

ritch_by_nature, 

 

 I don't entirely understand your application, but I have a few resources that may be helpful for you as well as some suggestions. 

 

I would not start the DAQmx task inside the while loop. If a DAQmx Start Task.vi is placed inside a While loop without stopping or clearing the task, on every successive iteration of the While loop the task will attempt to start a task that is already running. In order to avoid this, make sure that you stop or clear the task before it is restarted. However, doing this inside a while loop is incredibly inefficient. If you would like some more information on the DAQmx Task State Model, this KB should serve as a good resource: http://digital.ni.com/public.nsf/allkb/E2F211BD94353713862579D00001E705

 

The following example may be helpful to reference as well:

 

Multiple Channel Analog Output with Dynamically Updating Attributes: https://decibel.ni.com/content/docs/DOC-10821

 

In the LabVIEW shipping examples --> Measurement I/O --> DAQmx  --> Analog Output - Voltage Continuous Output may also serve as a good guide for prewriting data to the buffer prior to staring the analog task. 

 

 

Will M.
Applications Engineer
National Instruments
0 Kudos
Message 2 of 41
(6,960 Views)

BIGMACK, 

 

         I apologize for not being clear but I am trying to generate data using NI 9263 and read the same data using NI9239. All the NI cards(9263 and 9239) are placed in the same chassis (cDAQ9172).  My problem was getting an error when the task start. I used an Daqmx configure ooutput buffer after the the channels in the 9263 have been initialized outside the while loop. That stopped it for giving the error from starttask.vi. Now I notice I get this error : " Error -200561 occurred at DAQmx Write " because my data points are higher than the voltage range (-10 to +10) .  but if I set the auto start of daqmxwrite to True I get error Error 200294.

 Somewhat I am still stuck when It comes to writting data.

0 Kudos
Message 3 of 41
(6,938 Views)
Solution
Accepted by topic author ritch_by_nature

My friend, you have a few problems here.

 

First of all. The reason you're getting the error at DAQmx Start is because you start the task with your first loop iteration...then you start it again on your next loop iteration, without stopping it in between.  It's already running, so you can't start it again.  Hence your problem, and why you need to take DAQmx Start out of the loop.  Now, for a Write operation, you need to preload the buffer, so that when you call DAQmx Write, there's something to write.  So!  Outside your loop, where you set up your AO task?  You'll need to generate some data to write, preload the buffer, then call DAQmx Write. After that, call DAQmx Start.  THEN go into your loop.

 

Another thing.  It looks as though you'd like to output new data via DAQmx Write with each loop iteration.  Assuming that's true, you need to configure your task to do that, using a DAQmx Write property node.  Set "Regeneration" to "Do Not Allow Regeneration".  This will allow you to output new data with each loop iteration.

 

That Dequeue function you have is set to time out after 10msec.  Suppose it does indeed time out.  You'll be trying to write an empty array of waveforms to your AO channels.  That would likely be a problem, so you need to handle that possibility.  Do it however you like, the easiest way is to put your previous valid data into a shift register, check your Dequeue function for timeout, and either use the newly dequeued data (if Dequeue did NOT time out) or use the previous valid data (if Dequeue DID time out).  When you get new, valid data from your Dequeue function, write it to the shift register.  That will ensure you're always writing valid data.

 

Your Wait function is redundant.  Your loop timing is already dictated by the Dequeue function and your DAQmx Write function.  Take the Wait function out.  It's only going to goof up your timing.

 

Also, you might not want your Read and Write functions in the same loop, since you're not doing anything to synchronize their timing.  You'll probably run into buffer overflow/underflow problems with the way you have things set up.  Do a forum search for synchronized AI-AO to find out how to synchronize your tasks.

 

Have a look.  Modify as needed, but this is how you should do a non-regenerative DAQmx Write.  Did you by chance research this particular error on the forums previous to posting?  You probably would have found at least one post very similar to this one.

AO regenerative.png

Message 4 of 41
(6,918 Views)

Thanks for responding, you made some good points and I made all the changes. but apparently whether or not I remove the wait.vi I get error : Error -200621 occurred at DAQmx Write (Analog 1D Wfm NChan NSamp).vi:6390005. I am not sure how to fix that. I used an AI-AO synchronizer form that link: https://decibel.ni.com/content/docs/DOC-26326

I am still debating how to fix it.

 

0 Kudos
Message 5 of 41
(6,863 Views)

If you are following that example (with modification to generate new data each iterarion as Diane S Showed (Nice example Diane!) you definately do NOT want a wait inside your loop.  The AI Read Samples to read input and the sample rate determine the average loop time and thats all you need to avoid a "Greedy Loop"  (You avoid buffer onder and overflows as well)

 

The trick for this use case is to ensure the AO Waveform duration is always the same as the AI duration. 


"Should be" isn't "Is" -Jay
0 Kudos
Message 6 of 41
(6,851 Views)

This is how I set up my AI and AO and also the synchrnozation but I still get the error 200261 wwhen it is writting to daqmxwrite.vi

see attached files/

 

Admin Note - Attachments removed per user's request

0 Kudos
Message 7 of 41
(6,849 Views)

Also Here's my update based on what Diane S Suggested. see attached pic.

 

Admin Note - Attachments removed per user's request

0 Kudos
Message 8 of 41
(6,843 Views)
Solution
Accepted by topic author ritch_by_nature

An easy fix, my friend, an easy fix.

 

Specify the number of samples to read when you call DAQmx Read.  If you are writing 1000 samples / channel each time you call DAQmx Write, then you should wire "1000" to the "Samples to Read" input of DAQmx Read.  That's what Jeff was trying to say.  (Thanks Jeff!)

 

Right now, you're just grabbing whatever happens to be in the buffer when you call DAQmx Read (as described in the help for that function).  So you're messing up your DAQmx Write timing.  (By the way, when you get an error, and it shows up on your front panel "error out" indicator, you can right-click the "error out" cluster and choose "Explain Error".  I find that very handy indeed, and I bet you will too.) 

 

But back to your problem.  However many data points your waveform contains, that's how many data points you should tell DAQmx Read to read.  It's a synchronized operation, so you have to read the same number of samples as you write, at the same rate at which you write them.  You've synchronized the sample rates, but not the number of samples.  So take care of that and all should be well.

 

Get that "Wait" out of there.  You don't need it, I promise.

 

You're doing great, and you're almost there.

 

d

Message 9 of 41
(6,828 Views)

Got it thanks. It was definitely the number of samples that wasnt set right. but the sampling of the waveform was coming from my client so that is why when I fire up the server it takes the default setting for the waveform and puke that error. I fix it now.

 

Thanks alot... Kudos for everyone lol

 

0 Kudos
Message 10 of 41
(6,823 Views)