LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Pick and Sample & Hold DAQ output

Solved!
Go to solution
Highlighted

Hello,

 

The VI I'm working on must do the following:

  1. Generate low-frequency (~ 1Hz) sawtooth value (DAQ AO0)
  2. Read input (DAQ AI0), that depends on generated value (for simplicity I've just connected AO0 with AI0)
  3. When ceratin condition occur, immediately stop generating sawtooth and maintain the last value on AO0

For simplicity, "certain condition" is realized as 20th transition of the sawtooth on threshold value.

 

The interaction between "Generation" and "Acquisition" loops is realised with help of the local variable "Stop Generation Loop".

This setup works perfectly except the following:

  1. When "Generation Loop" stops, the DAQ output value isn't equal to the threshold value (as it's supposed to be)
  2. The DAQ output value doesn't depend on threshold value ... either threshold value is set, the output is about 2.2V (controlled on oscilloscope)

Any suggestions welcome

 

Regards

 

Pavel

0 Kudos
Message 1 of 7
(1,362 Views)

Well, you are telling the DAQ to output full waveforms.  So the entirity of the waveform will be output.  And then you have the race condition of when the local variable gets read vs when it is written.

 

If you really need this to be exact, you should use an FPGA board.  Then you can do all of the calculations/comparisons in hardware on a point-by-point basis and get the results you want.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
0 Kudos
Message 2 of 7
(1,339 Views)

Yes I need DAQ output value to be "frozen" once a particular event on input occurs.

So, there is no any means to get this setup working without FPGA? I mean employing only USB-6343.

Probably not using local variables, but some other technique ?

 

0 Kudos
Message 3 of 7
(1,331 Views)

If you are using software synchronization, maximum what you can achieve is around 1 ms: you register condition, process it, generate action. PC can decide it has other important things to do, so 1 ms is the best and it jitters. 

If your voltage changes slowly, and several ms is acceptable, move in this direction.

Then go realtime systems. they are more stable: if it takes 1 ms to make an action, it will not take 10 ms to make the same action as it can happen on Windows. 

 

Then hardware synchronization.

It relies on hardware cycle speed and can respond within microseconds - up to 10 ns of 100 MHz counter clock.

Pause trigger might have been an option, but your board does not support analog triggering. If your stop condition is simply a voltage level, you can make analog comparator that will switch digital level when input voltage crosses specified level and use digital trigger to stop AO task. You can choose level to trigger with a separate analog ouput. But it requires some board development and soldering.

 

FPGA is a combination of these: it can process and decide (software flexibility), but actual comparison is done on hardware level with its speed. Needs expensive hardware and specific programming skills. More straightforward with NI, than tradition languages, but still needs (some 😃 time to get into it.

Message 4 of 7
(1,320 Views)

Hello Alexander,

 

Thanks for suggestion.

I've changed the approach - instead of waveform I generates staircase with DC values, incrementing in loop.

Such solution is even better for final application.

 

The objective remains the same - when reading value reach the threshold, output must be "frozen".

This setup works perfectly except small detail - the final value on output is 1.51V instead of 1.50V (as it supposed to be due to "MORE OR EQUAL" comparator).

 

What could be the reason of such imprecision ?

 

Regards

 

Pavel.

 

Staircase with For Loop - Diagramme.JPG

 

Staircase with For Loop - Panel.JPG

0 Kudos
Message 5 of 7
(1,285 Views)
Solution
Accepted by topic author Pavel_47

@Pavel_47 wrote:

What could be the reason of such imprecision ?


You have a race condition with the local variable where the variable is read before the output gets its new value.  Therefore the loop iterates again.  So you should use a Flat Sequence Structure to force the reading of the local variable to be after you output the value.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
Message 6 of 7
(1,276 Views)

Perfect !!!

Thanks

0 Kudos
Message 7 of 7
(1,265 Views)