Multifunction DAQ

cancel
Showing results for 
Search instead for 
Did you mean: 

Measuring short (faster than the clock) pulse width fails with NI DAQ USB 6363

natasftw...

Of course what You said is true.

I asked WHY it's not supported, what makes it not supported?!?

It seems like a simple trival thing to do, something we did in the past with other NI DAQ cards, and we thought it's supported.

 

And as a counter example, you won't find people with jailbreak asking for support on apple forums and you won't find threads about it there.

 

I will ask again my last question:

 

We can simplify the problem:

Trying to read a single pulse (gate) when there is no clk signal should give a count of 0 and should not fail, but it does...

 

Any other thoughts? 😕

 

That, as far as I know, should be supported...

 

Cheers

Yoav

0 Kudos
Message 11 of 24
(2,902 Views)

 

I just threw together a very simplified example but I could only try it on a *simulated* USB-6363.  No errors were thrown.  That doesn't really mean a *lot* yet, but it could mean *something* since my earlier attempt to illegally write to the Duplicate Count Prevention property on the same simulated device *did* throw an error.

 

I'm not sure if default values come across in snippets, but I set the Gate signal to be one of the internal timebases and the Source/Clk signal to be an unused & unconnected PFI line.  So this would be an extreme case where the pulses are continuous, but there are never any source edges to increment the count used for characterizing pulse width.

 

I *think* this is the kind of simplified case you referred to where you'd expect to retrieve a "measurement" of 0 for pulse width rather than getting a timeout error.  Tweak as needed if I've got something wrong, but then repost whatever you're running if you continue to get the unexpected behavior.  Then others who are trying to help can run the same code on their hardware and it'll help to track down the core issue.

 

-Kevin P

 

measure 0 width pulses.png

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 12 of 24
(2,898 Views)

Hey Kevin,

It appears to me that the simulation was configed correctly and it does work.

But the experiment fails 😕

It appears that the 6363 and the simulation do not operate the same...

 

It might be a problem with our code, but I somehow doubt that, because:

  1. The same code worked with older DAQ cards (NI PCI-6251 for example).
  2. The code itself works, only detecting zero length pulses fails.

We also tried it on 2 different 6363 DAQ cards (one with BNC and one without) and we saw the same behavior...

 

You have any other ideas?

If the simulation and the product behave differently, is it possible that there is a "bug" in the device?

 

Cheers

Yoav

 

0 Kudos
Message 13 of 24
(2,870 Views)

Let me start by making 100% sure we're talking about the same thing.  You said:

 

It appears to me that the simulation was configed correctly and it does work.

But the experiment fails 😕

It appears that the 6363 and the simulation do not operate the same...

 

Can you describe your experiment in more detail?  Did you run the simple example code I posted both times, once with a simulated device and once with your real device?  What did you specify for your gate and source input signals each time? 

 

You say "the experiment fails."  In exactly what way?  What data did you get?  What error message did you get?  Does the error come immediately or only after the timeout period has elapsed?

 

Be sure to use an internal board signal (such as the 100 kHz timebase) for the gate in these experiments to help rule out issues with external signals & wiring.

 

 

-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 14 of 24
(2,851 Views)

Hey Kevin,

 

Sorry for the long delay!

 

The short answer is yes, I've ran this on both the simulated device and on the real device, the results were different.

 

The long answer:

For the simulation, I've ran your code.

For the experiment, I've ran the same code I've sent, which is the matlab version of it.

I've changed the gate to be the internal 100MHz timebase and the pulsewidth term to be an unconnected PFI line.

 

There error I'm getting is

Error -200077:Requested value is not a supported value for this property. The property value may be
invalid because it conflicts with another property.

0 Kudos
Message 15 of 24
(2,797 Views)

Hello Yomach, 

 

How did the code work with your simulation?  Also, have you tried running the provided code in LabVIEW with your physical device? If so, can you provide a description of your results doing this?

 

Best wishes!

Amanda B.
Applications Engineer
National Instruments
0 Kudos
Message 16 of 24
(2,781 Views)

Hey Bellissima,

 

Just to clarify, I'm using Matlab and not Labview.

I haven't tried labview and I have no experince with it, but if needed I can install it and give it a go.

 

Here is what I did:

I ran the following code twice, once on a real USB 6363 DAQ card and once a simulated one (created with this procedure).

On the simulated device, I received no errors.

On the real device, I received Error -200284: Some or all of the samples requested have not yet been acquired.

 

The code:

 

device = 'dev2/Ctr0';
N=2;

[ status, ~, task ] = DAQmxCreateTask([]);
DAQmxErr(status);
status = DAQmxCreateCIPulseWidthChan(task, device, '', 0.000000100, 18.38860750, DAQmx_Val_Seconds, DAQmx_Val_Rising, '')
DAQmxErr(status);
status = DAQmxCfgImplicitTiming(task, DAQmx_Val_FiniteSamps , N);
DAQmxErr(status);

DAQmxSet(task, 'CI.CtrTimebaseSrc', device, '/dev2/PFI5');
DAQmxSet(task, 'CI.PulseWidthTerm', device, '/dev2/100MHzTimebase');

numSampsPerChan = N;
readArray = zeros(1,N);
arraySizeInSamps = N;
sampsPerChanRead = int32(0);

[status, readArray, aux] = DAQmxReadCounterU32(task, numSampsPerChan, 1, readArray, arraySizeInSamps, sampsPerChanRead )
DAQmxErr(status); %This is the failing line.

 

Notes:

PFI 5  is unconnected.

I've set N=2 and not N=1 because for some reason, when N=1, I get Error -200608:Acquisition cannot be started, because the selected buffer size is too small.

I didn't look into it, but it shouldn't change anything.

0 Kudos
Message 17 of 24
(2,764 Views)

A few comments, hope they help move you along some:

 

1. I don't see a call to explicity *start* the task.  I think the read call will cause the task to start implicitly but it'd be a better practice to control the task start explicitly.

 

2. You configured input signals as:


DAQmxSet(task, 'CI.CtrTimebaseSrc', device, '/dev2/PFI5');
DAQmxSet(task, 'CI.PulseWidthTerm', device, '/dev2/100MHzTimebase');

 

It seems like you'd want these reversed.  As it is, you'd be trying to measure the number of edges on PFI5 that occur during the high time of the 100 MHz timebase.  And the task will be trying to buffer measurements at 100 MHz, which will fail *very* quickly.

 

3. That said, I'm surprised by *which* error you got.  The error you got would suggest that the read call timed out before getting the requested # of cycles of the PulseWidthTerm signal.  Combined with your comment that you had no signal at the PFI5 terminal, this error would make perfect sense if your signal config was already reversed from what I quoted in comment #2 above.  With the config you described, I'd expect a different error. 

   I can't recall the error # or exact wording, but it would say something about data arriving too rapidly for the system to keep up.

 

4. I'd suggest that for troubleshooting purposes, you try using different internal timebases for both signals you config.  Those should give you very consistent and predictable results.

 

 

-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 18 of 24
(2,750 Views)

Hey Kevin,

 

  1. You are correct! I have the start (and stop/clear) in the main code but I forgot it in the test case I created...
    Just double checked to make sure, and the results are the same.
  2. I actually think this is the correct way, let me quote you from a few post ago:

    "I'm not sure if default values come across in snippets, but I set the Gate signal to be one of the internal timebases and the Source/Clk signal to be an unused & unconnected PFI line.  So this would be an extreme case where the pulses are continuous, but there are never any source edges to increment the count used for characterizing pulse width.

     

    I *think* this is the kind of simplified case you referred to where you'd expect to retrieve a "measurement" of 0 for pulse width rather than getting a timeout error.  Tweak as needed if I've got something wrong, but then repost whatever you're running if you continue to get the unexpected behavior.  Then others who are trying to help can run the same code on their hardware and it'll help to track down the core issue"

    So as you wrote, this simulates an extreme "zero width" pulse, and better simulates the real condition I am having (I always get all of the pulses, but not always I have a clock fast enough to detect them).
  3. Well, I agree! This is very weird, it seems that the dup count prevnetion is not working...
  4. I actually tried that, played with the 20MHz Timebase as well, and also switched between the gate and the clk and tried several combinations of them (For example, 100MHz gate and 20MHz clk, and vise versa).
    All of the results are consistent with one another, the only "problem" is with detecting these zero width pulses.
0 Kudos
Message 19 of 24
(2,747 Views)

RE: #2

 

Ok, gotcha.  Just to clarify a bit, I posted that snippet primarily as a troubleshooting exercise -- to test a case where there were regular pulse width signals, but never any timebase signals.  The expected result should be measurements of all 0 values, acquired at the rate of the internal timebase.  (I'd suggest the 100 kHz timebase though, so the system has a fighting chance to keep up.)

 

I don't have appropriate hw to test out the code in real life.  Hopefully someone with a USB 63xx will try the snippet and report their findings.  Meanwhile, you could go back to John_P1's suggestion to help with further investigation.

 

 

-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 20 of 24
(2,742 Views)