This widget could not be displayed.

LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Buffered samples not updating in For Loop

Solved!
Go to solution

Hello.

 

I am having some issues with DAQmx Read.

 

I have 2 USB 6509 boards doing digital output to address some multiplexers and I want to measure differential voltage

using 2 USB 6255 boards. I have a sample clock shared for the 6255 boards through a PFI line. Unfortunately

the 6509 boards do not allow for hardware sync as far as I can tell.

 

So, to sync the the functions I have used a flat sequence to make sure the multiplexers are addressed before acquiring the voltage data

and as you can see from the VI (LabVIEW 8.6) I am using a For Loop to execute 16 iterations and build an array with that data.

 

The problem is that sometimes i get either error 200287 or error 200010. And when I don't get an error, the data from the 16 iterations

is the same and the is incorrect because I am monotoring the data going into the 6255 boards using a multimeter and the data does not match.

 

I seems to me that the Analog Input is only reading data from one iteration and I can't figure out why.

 

Also this VI takes a very long time to run and it freezes for a few seconds on some iterations.

 

Can someone take a look at the VI and shed some light please?

 

I am really stuck on this part.

 

Thanks in advance.

 

Cheers.

 

Rui

Message 1 of 8
(2,867 Views)

Hello Rsilva,

 

First of all, I saw that you create a finite task for 20 samples and in the flat sequence, you take 10 samples per iteration of For loop, so your task will be cleared after the second iteration.

I didn't see wher you have 16 iterations, you probably wanted to say 6...

 

What happens if you make the change?

 

Sincerely

David S.| Certified LabVIEW Associate Developer
National Instruments France


Message 2 of 8
(2,842 Views)

Rui,

 

Instead using the VI DAQmx Read alone use the following configuration:

 

   [1.]               [2.]                          [3.] 

 

1. Start Task

2. Read - the same as you have in your VI but: don't add anything to number of sample (default is -1) and  it will use what you defined in the Sample Clock (20 samples). (10 is timeout)

3. Stop Task.

 

This should do the job.

 

Paul

Message 3 of 8
(2,831 Views)
Solution
Accepted by Rsilva

Rui,

 

Well- that code has plenty of room to improve performance!  Other than the obvious samples to read error that was pointed out I would recommend:

 

  • Use "control task.vi" to commit the tasks prior to starting the loop- as you have it the tasks enter the loop "unverified" and therefore for each iteration the tasks are verified, reserved, committed, started, stopped, uncommitted, unreserved and unverified. Thats a lot of unnecessary work behind the scenes!
  • Do not pass 30000 as a sample rate to the slave AI task- Read the actual sample rate from the master task from a task property node and pass a value GREATER that actual sample rate to the slave task (sample rates can get coerced and cause you a bit of an issue)
  • Bring your constants out of the loop the 8.6 compiler does not have some of the modern optomizations available so reading constants every iteration is frowned on
  • Check your version of DAQmx.  You want it greater than 9.1 to avoid the autostart bug.

 

 

 


"Should be" isn't "Is" -Jay
Message 4 of 8
(2,824 Views)

 


@PaulieQ wrote:

Rui,

 

Instead using the VI DAQmx Read alone use the following configuration:

 

   [1.]               [2.]                          [3.] 

 

1. Start Task

2. Read - the same as you have in your VI but: don't add anything to number of sample (default is -1) and  it will use what you defined in the Sample Clock (20 samples). (10 is timeout)

3. Stop Task.

 

This should do the job.

 

 

 

Paul- With DAQmx 9.1 and later there is no need to use start and stop on a finite sample task if autostart is "true"


"Should be" isn't "Is" -Jay
Message 5 of 8
(2,822 Views)

Thanks Jeff. It's good to know.

0 Kudos
Message 6 of 8
(2,816 Views)

Thanks to everyone for the imput.

 

However I was less than clear about what I wanted, which was a Retriggable Analog Input.

 

I wanted to read data for every multiplexed address, which change with each iteration, and I kept getting the inital buffered data for the first iteration

and those values where passed on to the following iterations, thus making the data for each iteration equal. That was not the purpose.

 

I have already implemented using the examples in the forum and KB.

 

I will, however apply the advices given here to my current vi.

 

I appologize for the all the trouble, but I am very thankfull.

 

This forum is indeed a life saver at times.

 

All the best,

 

Rui

 

P.S. I would like to give kudos and mark a solution but I am not sure who to give kudos and what post to mark as solution.

Message 7 of 8
(2,810 Views)

Just click the half-star icon under the names of the people that contributed to give kudos!

 

And, of course, any post that helped can be marked the solution- we don't get too bent over who helped the most specifically for you. its the OP's option


"Should be" isn't "Is" -Jay
0 Kudos
Message 8 of 8
(2,805 Views)