LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

DAQmx counter input semi period unstable

Solved!
Go to solution

Hello all,

 

I am using for the first time the counter input and DAQmx (and NI hardware in general), so I might be doing something wrong.

I mostly think the issue is hardware wise (noise), so I will describe everything and hopefully get some best practise advises from a fellow NI knight! 🙂

 

I am generating (using a signal generator) a 1kHz signal (0-5V) at 77% duty cycle and I measure this signal with PFI0 and ctr0 of USB-6210 device (semi-period counter input).

 

With post processing the output of the "CI Semi Period", I am getting the duty cycle and frequency.

The measurement looks quite stable at first:

Lchar_0-1694004656054.png

Basically every half second I am doing a measurement of 1000 samples (2 samples = 1 period with CI Semi Period), and I am doing the average which is displayed and stored as min/max if it's a new min/max value.

 

However, once in a while, I would get a weird value, which (I guess) is kind of noise. My issue is that the signal looked good on the oscilloscope. I use the past "looked", because now if I connect my oscilloscope, it's killing my CI measurement (I would only get bad values), not sure what has changed compared to before (= this morning) on my setup.

 

Now the weirdest part for me:

I try to move all the wires from my setup, even jump on the ground several times, and my signal stays stable. 

But If i stand up from my chair, 50% of the time I would get this weird value for one loop... I tried to move my phone/watch near the USB-6210 but it didn't seem to bring some noises.

I am doing a simple test on my desk so I don't have shielded cable, and not the best crimping as well (such as using phoenix connectors as terminal to connect wires together). Could it be the issue? Are NI cards known to be very sensitive to noise? Or at least for counter input? Even though it's only 1kHz signal...

 

On the oscilloscope I can see that the signal has (at every period) a lowershoot /uppershoot (50ns) reaching -2.5V/6.5V. Could it be the issue considering CI are meant to be used at 0-5V? (But then I would expect to have this issue more often).

 

I have tried to use a digital filter but I would get following error that I could not figure out until now:

Terminal has already been configured with a different Minimum Pulse Width by another property in this task.

Device: Dev2
Terminal: PFI0
Requested Value: No Filter
Configured Value: 6.425e-006
Channel Name: Dev2/ctr0

 

If someone is interested, I have attached my VI but it's quite messy. A lot of things (such as the "Remove Outliners") are only there for debug purpose. I am using LabVIEW 2020 SP1.

 

BR,
Ludovic

0 Kudos
Message 1 of 3
(989 Views)
Solution
Accepted by topic author Lchar

Had a few minutes while waiting for a reboot.

 

1. The best solution for noise is to fight it at its source.  Search ni.com for "field wiring and noise" for some best practices.

 

2. Considering that you're new to counters and NI hardware, you've done a really good job with your code so far.  Sure it's a little messy, but not *nearly* as much as I was expecting and pretty easy to follow.

 

3. The digital filtering error you get is a subtle one.  I set up a simulated M-series device and replicated the error.  The first few things I tried didn't solve it.

 

4. Here's what *did* solve it: entirely removing the trigger property node call to setup the "arm start trigger".  That was something I was going to suggest anyway since I tend to use triggering only when it's really *necessary*, and here it actually isn't.

 

5. A better approach than choosing an edge to trigger on is to expand the channel property node to select the property "Starting Edge".  Your duty cycle calc shows that you expect your array of semiperiod times to be sequenced Hi,Lo,Hi,Lo...   So you should set the Starting Edge to be Rising.

 

6. My explanation for the error is that the semi-period usage of PFI9 wanted to set up a digital filter but the arm start usage of PFI9 wanted to leave digital filtering in the default mode of OFF.  This conflict led to your error.

 

 

-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.
Message 2 of 3
(965 Views)

Thanks a lot for your answer!

I have followed your advise to use the property "Starting Edge" instead of the trigger. Afterwards I could activate the digital filter, and activating the filter seem to have clear this noise issue.

I have stand up 20 times, and the error hadn't appear.

Now, I can even connect my oscilloscope to the signal and the counter input stays stable.

I am still quite confused that the counter input was somehow affected by a noise which I couldn't see on the oscilloscope...

 

Anyway it works now (at least I hope murphy won't show himself again soon), thanks again!

0 Kudos
Message 3 of 3
(950 Views)