LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

DAQmx timing issue

Solved!
Go to solution

cm_opi,

 

In your first post you listed 5 steps that your overall program was completing.  In the VI you gave us you are doing one of these steps.  There has to be some bigger program that calls the other steps correct?  If this bigger program is repeatedly calling this step (the VI you linked) then it will be rerunning all of the setup/cleanup that this VI contains, thus dramatically slowing down your program.  Maybe the best way would be for us to confirm this if you posted the rest of your code.

Sincerely,
Jason Daming
Applications Engineer
National Instruments
http://www.ni.com/support
0 Kudos
Message 11 of 12
(630 Views)
Solution
Accepted by topic author cm_opi

I met with our local NI engineers and I think we found a solution to this particular problem.  The -200279 error was being thrown because we were filling up the buffer faster than we read out of it, so to fix that we added in a DAQmx read property node after the sample clock and set the RelativeTo property to Most Recent Sample and the Offset property to -1.  This allowed us to read from the end of the buffer (which is all we cared about anyway) and the error vanished. 

 

The loop timing delays did not go away, unfortunately, and we determined it was due to screen updating.  Whenver the program had to update a lot of front panel indicators, the loop took longer to run.  As such, I'm going to have to go update drivers/upgrade video cards, as well as look into closing of background windows processes.

 

Thought I'd post what I found out in case anyone else is having buffer issues.

0 Kudos
Message 12 of 12
(607 Views)