Multifunction DAQ

cancel
Showing results for 
Search instead for 
Did you mean: 

Measure rise time with USB-6363

You tested with a 100 mVpp square, but your signal is a 0 to -8 V step, which is pretty significantly different.  The slew in your signal is over an order of magnitude greater, which, again, requires a larger bandwidth than what you tested.  My guess is that the 27 us signal you're picking up is the slower rising edge that occurs around 550 us into your trace.  (You could verify this by reading off of the analog input task you posted to see where the capture begins.  I'm betting it's on that rising edge.  Incidentally, how did you capture the trace you provided?  There's no graph indicator on the block diagram or front panel you shared.) 

 

I also got confused before, and my suggestion to "Start at something like a 10 us pulse, confirm that you get 10 us out of the counter, and then keep shrinking the pulse width until the counter fails" was not a great one.  Really, what you need to do is send in *edges with a 10 us rise* (or fall, in your case), from 0 to -8 V.  Continue shrinking the rise/fall time until you see the edge not get captured accurately.  Again, a more direct way is probably just to route out the analog comparison event so you can scope it directly.  My guess, is that your transition is so fast that the signal at the analog front end of the comparator is not slewing fast enough to cross the threshold and actually trigger a pulse on the comparator output.

0 Kudos
Message 11 of 16
(470 Views)

I'll test it out with a larger signal and vary the rise/fall time like you suggested and get back to you. That signal was from a previous capture I did, but I added the capture to my code and have attached a screenshot of the front panel. My DAQ is built into a system, so I'm trying to find out whether or not the PFI lines are wired out to a test point that I can monitor so I can scope the analog comparison event. 

0 Kudos
Message 12 of 16
(466 Views)

I believe the Analog Comparison Event is a live and valid signal only while the AI task is running.  During my little bit of playing around yesterday, I noticed some "edge effects" as the AI task was started and stopped.  

 

I simply don't have any experience with the details and nuances of the behavior of the A.C.E., so I'd recommend you do some simple controlled experiments.  Feed your AI channel and APFI0 pin from something like a variable voltage power supply.  Export the A.C.E. to a PFI pin if you can (I didn't really explore this very hard, but didn't quickly find a way to do it).  But if you can't export it, run 2 counters in edge-counting mode.  Let each count on a different edge of the A.C.E.  Start the 2 counter tasks up first, then carefully observe whatever counting they do upon:

 

- AI task start.  Try pre-setting the voltage below, above, and inside the window before AI start to observe any differences.  Starting the AI task with a voltage already inside the window may create a rising edge.  It's possible this could help explain your 27 microsec measurement.

 

- While AI task runs: vary the voltage up and down through the window.  Try things like going in from above and back out above instead of passing all the way through.

 

- AI task sampling done.  Observe what happens to the A.C.E. at the moment finite sampling finishes.  Again, try with voltages both outside and inside the window.

 

- AI task Stop and AI task Clear.  Same kind of stuff.

 

In the pics you posted, the voltage is inside the window at 0.0 V when the capture starts.  I honestly don't know what to expect from the A.C.E. in this circumstance.  But given the other results, I'll bet that whatever it's *meant* to do is exactly what it *is* doing.  If you aren't measuring the interval you intend to, you'll need to account for how it *does* behave when you set up your sequence of tasks and signal sources.

 

 

-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 16
(459 Views)

I did some testing with an injected sine wave and increasing frequencies to get smaller and smaller fall times. For reference again, the attached "Desired signal" is a zoomed in capture of the actual signal I am trying to measure the fall time of. From about 1-6 kHz, my VI looks like it is able to capture the fall time from -1 to -7 V pretty well. After that, it seems like the first trigger point gets later and later, and at 41 kHz it doesn't pick up the single bursts at all anymore. It does pick up a 41 kHz continuous sine wave though.

0 Kudos
Message 14 of 16
(452 Views)

While the screenshots you posted look puzzling, I'm sure that I don't know enough to draw strong conclusions.  That's part of why I suggested the simple controlled experiments.  

 

I noticed that the analog window trigger is considered a kind of Reference trigger.  Usually, I've used Reference triggering when I need to collect pre-trigger samples.  I note that in your earlier code you didn't wire a value to define the # pretrigger samples when you configured triggering.  The default value appears to be 500.  Then your most recent set of screencaps show a *total* # of samples less than that.  I'm not sure how DAQmx handles that situation, but it may explain some of the puzzles.

   I can't do any tests on hardware now, but I wonder whether DAQmx might not even "arm" the ACE until after it has collected its 500 pretrigger samples.  If it works something like this, then the first part of the signal on the graph wouldn't correspond to the time when the counter is measuring the ACE pulse width.

 

Another thing I noticed but don't have insight about is that you're measuring ai2 in differential mode.  That would imply to me that you have the (-) side of the signal wired to ai10.  One thing I wonder is whether the analog triggering circuitry requires you to wire the (-) side of the signal to AI_GND.  

 

Do some more controlled experiments.  Carefully observe the effects of adjusting your pretrigger and total # samples.  Try using an analog window *Start* trigger to avoid any possible issues with pretrigger samples.  Try measuring (and wiring for) RSE instead of differential.  Use controlled voltage signals that aren't repetitive and periodic.  There's a lot of things to be tried and observed.  I expect the answer is in one of those areas where you haven't been looking much yet.

 

 

-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 16
(432 Views)
 

Why not use the scope and control and read it via LabVIEW?

 

To croohcifer: You are rigth .. just when you want to qualify your test system, you need to know your bandwidth ... and a common way to do it is to use a pulse generator 🙂

Greetings from Germany
Henrik

LV since v3.1

“ground” is a convenient fantasy

'˙˙˙˙uıɐƃɐ lɐıp puɐ °06 ǝuoɥd ɹnoʎ uɹnʇ ǝsɐǝld 'ʎɹɐuıƃɐɯı sı pǝlɐıp ǝʌɐɥ noʎ ɹǝqɯnu ǝɥʇ'


0 Kudos
Message 16 of 16
(431 Views)