LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

puzzles when using FIFOs to control voltage output

from some NI board's instructions,I see that there are FIFOs for AO channels' control.

I checked some demo VIs of DAQ AOs control ,but didnot find further useage of it.

 

Can I use the FIFOs for time_based accurate control by this ? just to ensure the time's precision of AO voltage channels , so as to accomplish parts performance of RTOS.

 

I consider that , I can first set the FIFOs buffer size to 3k, set the channel clock to board CLOCK 1K, and then ,I write the FIFOs buffer with a 1D 2k length's array .

so the CLOCK will "eat" the FIFOs with a rate of 1k/s.

 

and then ,I check the FIFOs' size repeatly , once it is less than 1K, I will enrich it , and add another 1k waveform data to it. so it seems I can use the board's system to continuously output a smooth voltage signal with proper time precision.

 

But ,from the VI demos in NI folder , the demos shows that ,if I want to use the FIFOs to output a voltage signal(for example, SIN signal) , I need

1,first produce the array data of that SIN signal ,

2,and then use labview to put the array into the board's FIFOs,

3,and then the board output the SIN signal.

after all these steps finish,labview will again put the array into FIFOs, the DAQ board again output the voltage signal.

 

it seems there is no chance for me to check the left FIFOs' size, no chance for me to enrich it continuously.

 

So, if I use it on windows system, there may probably be a time error between two FIFOs' voltage signal's connection part on AO channel pin. The output pin's voltage waveform may be easily disgunished and divided into sections,and each section refers to the FIFOs that laview wrote.

 

Am I right? Is there some misunderstanding that I need to correct? I want to output time_accruate signals(such as voltage signal) with simple NI board , as most RTOS can do.

 

0 Kudos
Message 1 of 6
(2,899 Views)

@alii001 wrote:

it seems there is no chance for me to check the left FIFOs' size, no chance for me to enrich it continuously.


That's one of the most important use cases for a FIFO.

 

Post some code. Changes we can recreate and advice on what you have are pretty slim.

0 Kudos
Message 2 of 6
(2,882 Views)

There are typically 2 buffers involved in a DAQmx AO task.  1 is a task buffer that is stored in application memory -- this is what you most directly interact with when you call DAQmx Timing and DAQmx Write.   There's also a hardware FIFO on most DAQ boards.  Generally, DAQmx invisibly manages the process of moving data from the task buffer to the FIFO. 

 

The programmer usually just needs to keep writing chunks of data to the task buffer fast enough to keep up with hardware generation.  If you try to write faster than necessary, the call to DAQmx Write will block and wait until there's enough room in the buffer to avoid overwriting samples that haven't yet been delivered to the board for generation.

 

The shipping example "Voltage (non-regeneration) - Continuous Output" is worth looking at.

 

 

-Kevin P

ALERT! LabVIEW's subscription-only policy came to an end (finally!). Unfortunately, pricing favors the captured and committed over new adopters -- so tread carefully.
0 Kudos
Message 3 of 6
(2,858 Views)

@Kevin_Price  已写:

There are typically 2 buffers involved in a DAQmx AO task.  1 is a task buffer that is stored in application memory -- this is what you most directly interact with when you call DAQmx Timing and DAQmx Write.   There's also a hardware FIFO on most DAQ boards.  Generally, DAQmx invisibly manages the process of moving data from the task buffer to the FIFO. 

 

The programmer usually just needs to keep writing chunks of data to the task buffer fast enough to keep up with hardware generation.  If you try to write faster than necessary, the call to DAQmx Write will block and wait until there's enough room in the buffer to avoid overwriting samples that haven't yet been delivered to the board for generation.

 

The shipping example "Voltage (non-regeneration) - Continuous Output" is worth looking at.

 

 

-Kevin P


from your comment,I know that it is commonly unreachable for users to use FIFOs in DAQ board, while ,the board will automatically check if there is enough space in FIFOs to receive data from application.

 

this seems can ensure the precision that I mentioned in my question.

 

but , if I know the exact unoccupied size of FIFOs, I can decide when to write data more properly ,no need to write too hurry.  what shall I do accomplish this ?

 

thank you !

0 Kudos
Message 4 of 6
(2,846 Views)

@alii001 wrote:

but , if I know the exact unoccupied size of FIFOs, I can decide when to write data more properly ,no need to write too hurry.  what shall I do accomplish this ?


You'd usually make a loop that pushes data based on timing. Preferably HW timing. A read of data does this. Reading 1M samples, at a certain frequency will HW time your loop... If you know the output sample rate, you know how much data there needs to be pushed in a timeframe.

 

I think you should also be able to hook event structures to a DAQmx task to get events related to buffers\data? Not sure how widespread this support is...

0 Kudos
Message 5 of 6
(2,831 Views)

You might want to read about the DAQmx property "Data Transfer Request Condition".  This isn't direct access to or control of the board's internal FIFO, but does give you *some* influence.

 

Here's a knowledgebase article.  It focuses on reducing output latency, but it may be helpful for your needs, which I don't fully understand.

 

 

-Kevin P

ALERT! LabVIEW's subscription-only policy came to an end (finally!). Unfortunately, pricing favors the captured and committed over new adopters -- so tread carefully.
0 Kudos
Message 6 of 6
(2,821 Views)