LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Low sampling rate and crosstalk

Solved!
Go to solution

Hi everyone

I am using a program to measure the phase and deflection of a spinning shaft using lasers and an encoder, the VI is attached 

The equpment i'm using-

NI 9185 DAQ, 9209 AI, 9361 counter

 

My problem- when trying to sample and write to a file, the samples from the encoder come out ok- while the samples for the laser sensors (AI card) only register at intervals of about 100ms, while i need to sample at around 20Khz. (values persist for around 100ms before seeing a new value)

I have made sure the laser sensor used supports this rate (keyence LK-031)

Before starting to make any equipment changes, i would appreciate if anyone could help me figure out if my VI is wrong in anyway

Any suggestions for improvement are always gratefully welcome as well

 

Thanks in advance

 

rotodyn1s.png

0 Kudos
Message 1 of 8
(2,630 Views)

Why are you stopping and starting your tasks, and setting the sample clocks within your while loop?  Those operations take time.

0 Kudos
Message 2 of 8
(2,598 Views)

I was under the impression the substructure operates once rather than checking in each iteration of the loop if the boolean is true or false, i understand this isn't the case.

I will try to create an independent loop, with the respective commands out of it, leaving just the channel reading inside.

 

That said, i wonder why the counter samples at the desired rate accurately, it also uses the same open/close task blocks

0 Kudos
Message 3 of 8
(2,574 Views)

Going through the blocks again, there are a couple of things i would appreciate if someone could answer, regarding opening/closing the channels and setting the sample clocks in the t/b block, in the loop-

 

If the clock and sample number would be set repeatedly in each iteration, wouldn't it make the program sample indefinitely? Right now it is sampling the correct number at the correct rate (aside from the fact that laser values persist...)

Also, is there a possible reason why the displacement sensors aren't being sampled correctly while the tachometer values are? it's the same loop and operations, this is the part that really confuses me.

 

Thanks for any help or possible answer

0 Kudos
Message 4 of 8
(2,546 Views)

The key concept in LabVIEW is the Principle of Data Flow:

  • (Almost) anything with an Input (Structure, such as a Loop or a Case, sub-VI, function) doesn't start working until all of its Inputs have Data on their input Wires (or accept "default" if the Input has no connection).
  • (Almost) anything with an Output doesn't "present" anything on its Output until all the code "inside" it finishes.
  • Things that are not sequentially connected by wires operate independently and (for all practical purposes) simultaneously.

The following are consequences of this Principle:

  • The time for sequential code (output of element wired to input of next element) is the sum of the times for each element in the sequential chain.
  • The time for a loop to execute is the longest time of any sequence within the loop.

When considering DAQ applications, such as reading from an Analog Device, say 1000 samples at 1 kHz, the DAQmx Read takes 1000/1000 = 1 second to complete.  Any processing that you need to do within the loop will add to the time that the loop takes to complete (since you cannot process data that you don't yet have, so you need to wire the Data Out from the DAQmx Read into whatever functions you need to process the data).

 

Another consideration is acquisition timing.  DAQ devices are typically designed with very accurate clocks, and generally keep better time than the PC itself.  If you are going to do any long-term data acquisition, the best way to acquire the data with the best timing is as follows:

  1. Set up your DAQ parameters to collect, say, 1000 samples at 1 kHz (adjust parameters to your particular task).
  2. Set the sampling for "Continuous", meaning as soon as the first set of samples is complete, it will be presented at the output of the DAQ Read and the next set of samples started.  This gives you an entire "sample period" (here 1 second) to read and process the data.
  3. Do as little else in the loop as you can.  In particular, do not stop and restart the DAQmx Task.

So the basic AI DAQmx Task starts with defining your task (what device, how many channels, range, etc.), timing (sampling rate, number of samples, sampling mode = continuous), and, when you are ready to start acquiring data, starting the Task.  Then, in a While Loop, you do the Read (don't forget to specify the number of samples you used to define the task -- you want the Read to read all of the samples before exiting) and are then ready (with a whole second to do something) for the next loop iteration.  When you finally Exit the Loop (because you pushed the Stop button wired to the Loop Stop Indicator), you can stop the Task.

 

Note I've not put anything else in the Loop.  In particular, I've done nothing with the data.  What do you want to do with the data?  If you can do it in one second (like write it to a Delimited Spreadsheet), go ahead and to that.  If you think it may (occasionally) take a little more time, you need to "export" the data out of the loop and let a parallel loop chew on it -- this is something called the Producer/Consumer Design Pattern (and you can find links to it by doing a Web search).

 

You've got all of your DAQ code in a single loop.  Remember the Principle of Data Flow says that the loop runs at the speed of the slowest sequential component inside the loop.  But parallel loops (particularly those, like a DAQmx Read, that are mostly "waiting for data", taking no CPU time during the Wait) effectively let the loops "Time-Share" and run simultaneously.

 

Here's a recommendation -- start rewriting your code, one DAQ loop at a time.  I would suggest writing a small Test Routine for each DAQ Task to get a good understanding of how this all works.  Start with the AI task, and try to keep the processing "simple".

 

Bob Schor

 

 

0 Kudos
Message 5 of 8
(2,534 Views)
Solution
Accepted by topic author Pika007

I'd like to just add a little to Bob Schor's detailed description, to perhaps aid in understanding with an example.

 

As Bob explained, the DAQmx Read will not finish until all of the samples it is waiting for are available - this means, for the first iteration of a loop with 1kHz sampling rate and 1000 samples, the Read node will take 1 second.

If you then do some processing (let us imagine that this processing takes 0.5 seconds), then this must wait first the full second for the data to leave the DAQmx Read node, and then it must do the processing.

As a result, the time taken by the first iteration would in this example be ~1.5 seconds.

 

However, the DAQmx Read system uses an internal buffer (the size of which is controlled by inputs to the DAQmx Timing node, or various property nodes) which will allow a faster second iteration.

When the 2nd iteration starts, 1.5s will have already passed. The second iteration requires the data from time 1.000 to 1.999 seconds to be able to complete the Read, so only an additional 0.5 seconds need pass before the Read node can complete.

The processing then takes place, requiring another 0.5 seconds. At this point, a total of 2.5 seconds has passed. The third iteration will behave in the same way as the second iteration, and the result will be that your iteration time becomes 1 second.

 

This is hinted at by Bob's description in his 5th and 6th paragraphs, quoted below (red emphasis mine):


@Bob_Schor wrote:

Note I've not put anything else in the Loop.  In particular, I've done nothing with the data.  What do you want to do with the data?  If you can do it in one second (like write it to a Delimited Spreadsheet), go ahead and to that.  If you think it may (occasionally) take a little more time, you need to "export" the data out of the loop and let a parallel loop chew on it -- this is something called the Producer/Consumer Design Pattern (and you can find links to it by doing a Web search).

 

You've got all of your DAQ code in a single loop.  Remember the Principle of Data Flow says that the loop runs at the speed of the slowest sequential component inside the loop.  But parallel loops (particularly those, like a DAQmx Read, that are mostly "waiting for data", taking no CPU time during the Wait) effectively let the loops "Time-Share" and run simultaneously.

 

Bob Schor


Note that the Data Flow principles that Bob has described are crucially important to understanding LabVIEW's execution system, and that this dependence of one thing on another will slow down your loops (as described above for the 1st iteration).

However, the buffer system for DAQmx will reduce the time taken by the subsequent reads (when some of the data is already available before you reach that node on the block diagram) which allows the addition of some extra processing code.

 

Of course, if your processing takes more than 1 second, you'll eventually overflow the buffer. This is unsustainable in any situation, although for sufficiently short execution times of your acquisition might be acceptable - then acquisition will stop at the end but the VI will continue processing. If you find yourself in this situation, the Producer/Consumer architecture that Bob Schor mentioned is a much better system to use, because it will significantly reduce the chance of missing samples and causing errors in your acquisition process.


GCentral
0 Kudos
Message 6 of 8
(2,523 Views)

I thank everyone for the detailed and informative answers- i am steel new to labview and without a doubt, need to learn more about how data structures operate, and efficient usage for flow of information in labview.

The tutorials only supply limited explanation of the principles.

 

I would also like to report that it seems my problem was in the equipment used- i didn't notice the 9209 card is good for up to 500 samples/second

I switched to another voltage AI card, and the program currently works well at the required rates.

Even so, i understand my way of building it is far from optimal- and will try to optimize it using the advice given here to further to reduce errors or incorrect readings.

 

Once again, thank you all for the help.

0 Kudos
Message 7 of 8
(2,511 Views)

"Remember that a node executes only when data is available at all of its input terminals and supplies data to the output terminals only when the node finishes execution."  (A structure counts as a node.)

 

If you can ruthlessly apply the above paragraph to your code, you can predict how your code will operate - and if you find places where you can't, it's probably true.

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
0 Kudos
Message 8 of 8
(2,491 Views)