PCI-6224 Two-Edge Separation Timing Discrepancy

[OlderJohn]

I am using the Two-Edge Separation task with a PCI-6224 DAQ card to measure the time one signal goes high to another, which should be around 60 to 70 ms.  Sadly, I am not seeing this amount of time reported back by the task.  Instead we are getting values that are 35 to 45 ms higher.

I've attached our PC-based digital storage oscilloscope to the two edges that are monitored and have verified that the two edges coming into the card are the correct distance apart (see attached TimingDiscrep-Scope.jpg and TimingDiscrep-App.jpg).  So I believe that the error is originating somewhere within the card itself, but I do not know where.

We aren't doing anything terribly complicated with the card, so any thoughts on what could cause this 30 to 40 ms delay?  I've ran this setup numerous times to know that the offset is repeated each time.  We are also accessing the card periodically to read 8 analog inputs and read/write ~25 DIO as well.

[John_P1]

Hi OlderJohn,

This is a very significant error between the measurements--I am not immediately sure what the cause could be.  Are you sure you are measuring between rising edges on the proper channels?  It is also possible to measure between rising and falling edges, or between falling edges.  Also, you should make sure that the proper channels are selected for First Edge and Second Edge.

It looks like the first two edge separation measurements you make are ~900ms--are these expected results?  After double-checking that the appropriate channels are connected and configured in software, could you try running a simple shipping example to see if you can recreate the problem.  Specifically, I would try running the Meas Two Edge Separation.vi example, found in:

Help >> Find Examples... >> Hardware Input and Output >> DAQmx >> Counter Measurements >> Two-Signal Edge-Separation

If the example code exhibits the same behavior (make sure to change the configuration to measure between rising edges), could you let me know which pins you have your signals connected to?  If the example code functions but your code does not, could you post the code if possible.  Thanks!

-John 

[OlderJohn]

John, 

I believe that we are measuring at the correct points (the ~900 ms values are what we are expecting from those portions of the sequence).  All of our values could be off by this amount, but 30-40 ms is a significantly smaller portion of them.

I have worked with the example VI that you have directed me to before we have had this issue.  I've had to add the ability to use non-default pins (PFI 15 for the leading edge and PFI 9 for the second edge).  The example code has given us the same results.  We have even created a separate microcontroller circuit that precisely mimics the edges from the field (and turned off the rest of the system) and get the same results.

[John_P1]

Hi OlderJohn,

This issue has us scratching our heads a bit--could you post your code and confirm that you are using the 6224 (and not the 6624).  

I would also like to see more information about the signal.  In particular, would it be possible to attach the following screenshots from your scope?

1. A "zoomed out" graph of the entire digital waveform that generates the measurements shown in your LabVIEW screen shot.  I would like to see where rising and falling edges occur from each chanel to help diagnose exactly what the counter might be measuring.
2. A "zoomed in" graph of one of the falling and rising eges of the signal on channel A1 (the blue one).  It looks like the edges may be ringing quite dramatically for 1ms or so.  A zoomed in graph on channel A2 wouldn't hurt as well.

I suspect that the issue may be that the counter is registering the falling edges as rising edges due to the amount of ringing.  You might want to try enabling the digital debouncing filter that is available on all M series devices (described in the M Series User Manual).  You can enable the filter with the DAQmx Channel Property Node:

-John 

Message Edited by John P on 04-07-2009 03:00 PM

Message Edited by John P on 04-07-2009 03:00 PM

[OlderJohn]

The issue turned out to be a bit of code that was modified while attempting to troubleshoot another problem (which was solved by using the digital filtering) but not changed back afterwards.  The problem was that the task was configured to look at the falling edge of the signal, and the 30-40 ms was the width of that pulse.