From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Instability using ANC daqmx

Yes, I use LAN cable..How can resolve these delays?

0 Kudos
Message 11 of 25
(457 Views)

Hi Maxim,

 


@Maxim898 wrote:

Yes, I use LAN cable..How can resolve these delays?


You can't (with your current setup)...

Best regards,
GerdW


using LV2016/2019/2021 on Win10/11+cRIO, TestStand2016/2019
0 Kudos
Message 12 of 25
(443 Views)

I'm assuming you have an embedded real-time controller in a PXI chassis and the LAN cable is just to connect to the host PC to provide a simple-to-implement user interface from the LabVIEW dev environment.

 

You'll need the AO task to be unbuffered for sure.  I'd make the AI task unbuffered too, at least initially.  All you need to do is *not* include a call to DAQmx Timing and that'll leave your tasks in software-timed "on-demand" mode.  In this mode you'll read and write just 1 sample at a time so the main control loop will need to iterate at a high rate. 

 

I haven't been around RT in a long time, but IIRC, the real-time DAQmx driver has a lot less overhead for these on-demand reads and writes.  So you'll not only be able to have reliable timing under RT, but you should be able to get a pretty fast loop rate.  

    And you're going to *need* it.  Dunno what frequencies you need to "cancel", but your loop rate probably needs to be faster than those frequencies.  I'm guessing you'll want a loop rate of at least 5 kHz. 

    It may be important for you *not* to update any indicators inside the main control loop.  I'm not sure how VI Server handles this stuff when managing the LAN traffic with your host-side GUI, but those updates might slow the loop down.  You can put the indicator updates in a parallel "consumer" loop and have your main loop push data to it with an RTFIFO, a lossy Queue, or similar mechanism.

 

As to the actual science of noise cancellation, I have no idea.  I can only help give hints about making a faster control loop with low latency.  I don't know what that control algorithm needs to look like.

 

 

-Kevin P

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
0 Kudos
Message 13 of 25
(435 Views)

Kevin thank ypu for your cooperation.

 

By loop rate you mean sample clock rate that initialize in DAQmx sampleClock?

 

I would like to riduce tone pure in the range between 100 and 500 Hz.

 

To reduce delay, Can I use in the picture 

Maxim898_0-1649230834296.png

used in Multi-Function-Synch AI-AO.vi?

0 Kudos
Message 14 of 25
(425 Views)

By loop rate you mean sample clock rate that initialize in DAQmx sampleClock?

Nope.  I've been suggesting NO sample clock (and thus no buffer).  Loop rate means the iteration rate of the control loop.   Under RT, it'd be useful to make that a Timed Loop instead of a While Loop.

 


To reduce delay, Can I use in the picture used in Multi-Function-Synch AI-AO.vi?

Again, nope, not much point.  That pic shows one method for sync'ing the start time of 2 tasks that use a sample clock and buffer.  Sync is often pretty important in those cases.  But for *your* control loop case with on-demand sampling, it isn't going to matter.  

 

FWIW, cancelling a pure tone in the 100-500 Hz range sounds pretty feasible under RT.  Dunno anything about your adaptive filters or noise cancellation algorithms in general, but you have a nice regular (and predictable!) signal to cancel at a modest frequency.  Both work in your favor.

 

 

-Kevin P

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
0 Kudos
Message 15 of 25
(418 Views)

Ok thank you very much.

 

In Period and Source Name in time loop Can I use, for a tone pure to 100 Hz, Period = 100 and Source name= 1KHz?

 

In Daqmx read and write I use Analog 1D DBL NChan 1Samp and Analog DBL 1Chan 1 sam. Is it correct?

 

Tahnks a lotMax

0 Kudos
Message 16 of 25
(423 Views)

In Period and Source Name in time loop Can I use, for a tone pure to 100 Hz, Period = 100 and Source name= 1KHz?

Again no.  That would loop every 100 cycles of a 1kHz clock, i.e., 10 Hz.  Not nearly enough.  Use the 1MHz Source and start with something like 500 for period, i.e. 2 kHz.

 


In Daqmx read and write I use Analog 1D DBL NChan 1Samp and Analog DBL 1Chan 1 sam. Is it correct?

Yes, for on-demand sampling, 1 sample (per channel) at a time is correct.

 

 

-Kevin P

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
0 Kudos
Message 17 of 25
(417 Views)

In the source name and source type I writed 1 MHz. 

0 Kudos
Message 18 of 25
(415 Views)

In attached my VI, It stil doesn't work.

 

Can you help me? My "Error Mic" gets unstable, instead x+y during the time tend to zero.

0 Kudos
Message 19 of 25
(406 Views)

In the last VI, x+y doesn't work, it doesn't tend to zero.

 

Thanks a loto

 

Max

0 Kudos
Message 20 of 25
(405 Views)