Multifunction DAQ

cancel
Showing results for 
Search instead for 
Did you mean: 

Time out even though a measurement is made for pulse width

Hello,

 

I have a system with Windows 10 and PXI-6229. I am trying to make a pulse measurement. A very simple one. My signal goes up to 5 V for 300-600 ms and drops to 0. I was getting a time out in my code so I set up a task in data neighborhood. When I run my task it returns a value, I can see it in the upper section of the screen but still times out and pops up a message box with an error. My acquisition sample is set up to "1 sample".

Thanks 

J.

0 Kudos
Message 1 of 24
(3,808 Views)

Hi Cimteker, 

 

Whats the error you are receiving?

 

Check the M series Manual for more information about counter funtions. 

 

http://www.ni.com/pdf/manuals/371022l.pdf

0 Kudos
Message 2 of 24
(3,767 Views)

I can't see enough about the MAX config to say much with confidence.  I do notice a mismatch between your Max/Min values and units -- there's no such thing as fractional "Ticks" for counting.  The count value you get is almost 1 million, so it *does* appear to be measuring in Ticks units.  But those million ticks would still (likely) represent only about 12 msec, not 300-600.  (Odds are the board uses its max timebase of 80 MHz for the measurement.  A million cycles takes 1/80th sec.)

 

Try a shipping example for pulse width measurement and see if you get better results.  Or post your original code (if necessary, "save for previous version" to LV 2016 or earlier please) and I can try to make sense of the timeout problem.

 

 

-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 3 of 24
(3,764 Views)

This is the error I am receiving:

 

Error -200474 occurred at DAQ Assistant

Possible Reason(s):

Specified operation did not complete, because the specified timeout expired.

0 Kudos
Message 4 of 24
(3,761 Views)

I must have played with units. Originally it was set to seconds.

Another screen attached. This time it reads what it looks like 400 ms and still generates an error.

 

0 Kudos
Message 5 of 24
(3,760 Views)

This is my code. It's in Python.

 

try:
taskHandle = OnStart.hNiDaq.CreateTask("myTask")

channel = "PXI_6229/ctr0"

minVal = 0.01
maxVal = 2.0
startEdge = OnStart.hNiDaq.CONST.DAQmx_Val_Rising

OnStart.hNiDaq.CreateCIPulseWidthChan(taskHandle, channel, "",
minVal, maxVal, OnStart.hNiDaq.CONST.DAQmx_Val_Seconds, startEdge, "")
OnStart.hNiDaq.SetCIPulseWidthTerm(taskHandle, channel, "PFI0")

OnStart.hNiDaq.StartTask(taskHandle)

time.sleep( 0.25 )
IO.setOutput("Nest1/LIInput")

pwidth = OnStart.hNiDaq.ReadCounterScalarF64(taskHandle,5.0)
my.testResult.value = pwidth

except Exception, e:
RDX.printError( e.message)
finally:
if(taskHandle != None):
OnStart.hNiDaq.StopTask(taskHandle)
OnStart.hNiDaq.ClearTask(taskHandle)

 

0 Kudos
Message 6 of 24
(3,758 Views)

I can't help much without more details. 

 

You've set up a task for pulse width measurement.  You've either defined a timeout value or else are using a default.  The task is reporting that it's unable to complete the measurement within the allowed time, though in some cases it appears to make at least 1 reasonable measurement.

 

So now it's mystery-solving time.  What are all your config settings?  What things have you already done to try to understand and troubleshoot the timeout error?  Where is the signal physically connected?  Are you sure there's a pulse signal present when you run?  Etc...

 

Meanwhile, you should also try a shipping example.  It's regular DAQmx code and it's known to work.  That'll help narrow down your suspects.

 

 

-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 7 of 24
(3,753 Views)

Thanks Kevin,

 

I am just questioning the logic implemented in NI-MAX Data Neighborhood. If it takes a measurement why does it time out? The acquisition mode is set to 1 sample unless I am not understanding this setting

 

CT

0 Kudos
Message 8 of 24
(3,738 Views)

I had a scope hooked up to the pin that produces the pulse, I saw it on the scope. Then I rang out that pin to a high density connector going into PXI-6229. That's pretty clear to me that it's there. Not sure what else I can check.

 

Thank you

CT

0 Kudos
Message 9 of 24
(3,736 Views)

I think I started my last reply before seeing the python code you posted.  I don't know the python API, but I can mostly follow what you've got there I think.  I agree that it seems odd to get both a reasonable measurement and a timeout error in MAX.  I have no explanation because I never really use global tasks in MAX -- too many details are hidden.  

 

Is the following line meant to set a digital line high?  Is it the line corresponding to PFI0 on your board (or is it physically wired to PFI0)?

IO.setOutput("Nest1/LIInput")

 

If so, then you need to toggle the line back low again to allow the pulse width measurement to finish.  Your pulse width measurement will start tracking time when it sees a PFI0 rising edge and won't complete the measurement until it sees a falling edge.

 

I would suggest you use MAX to generate a continuous pulse train on ctr1.  Figure out what PFI pin the pulse train is on and change your python code to measure the pulse width on that PFI pin.  Basically, make sure there's always a source of pulses on the pin you're measuring and *then* see if you still get a timeout error.

 

 

-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 10 of 24
(3,731 Views)