PXIe-6535 missing digital change events

[CurtisHx]

I have a signal pulse line feeing into Port1/Line1 on a PXIe-6535.  This lines goes from 0v to 3.3v for 5ms, every second.  It's a heart beat signal from the device under test.  It goes high for 5ms, then low for 995ms, and repeats as long as the device under test is powered.

My software needs to sync up on this heart beat.  It does not have to be precice.  A few milliseconds of slop is fine.  Here's the code:

        ManualResetEventSlim waitForTrigger = new ManualResetEventSlim();
        using (NationalInstruments.DAQmx.Task task = new NationalInstruments.DAQmx.Task())
        {
          var chan = task.DIChannels.CreateChannel("PXI1Slot2/Port1/Line1", "", ChannelLineGrouping.OneChannelForAllLines);
          chan.LogicFamily = DILogicFamily.ThreePointThreeVolts;

          task.Timing.ConfigureSampleClock("", 10000000, SampleClockActiveEdge.Rising, SampleQuantityMode.ContinuousSamples);
          task.Timing.ConfigureChangeDetection("PXI1Slot2/Port1/Line1", "", SampleQuantityMode.ContinuousSamples);

          task.DigitalChangeDetection += (e, o) =>
          {
            Tracing.TraceEvent(TraceEventType.Information, 0, "Edge detected on PXI1Slot2/Port1/Line1");
            waitForTrigger.Set();
          };

          task.Start();

          if (!waitForTrigger.Wait(1200)) //times out after 1200ms
          {
            String errorMessage = String.Format("Failed to detect edge on PXI1Slot2/Port1/Line1 in 122ms");
            Tracing.TraceEvent(TraceEventType.Information, 0, errorMessage);
            throw new TimeoutException(errorMessage);
          }

This code will wait for 1200ms for a rising edge on Port1/Line1.  I can see the heart beat on my scope, so I know the signal is getting into the the PXIe-6535.  

However, this will miss rising edges on Port1/Line1.  A rising edge will go, but the DigitalChangeDetection event will not fire.  Why?

[Kevin_Price]

Caveat: I only program LabVIEW and don't know any details of the text language syntax.

I believe I see the following:

1.  A conflict in how you're defining the sampling method.  First there's a call that looks like it's requesting

constant rate sampling at 10MHz.  The next call appears to request sampling based on change detection.

These are at cross purposes.  I'm not sure whether you should expect an error or whether the 2nd call

should merely override the 1st.  (In LabVIEW, it'd just override as long as the task hadn't been started).

   In change detection mode, it's the digital change itself that causes sampling.  The time is unknown and

treated as irrelevant.  So I'd keep the 2nd call and get rid of the 1st.  There might be more details to handle,

such as defining which polarity of digital edge to be sensitive to, but that'd be a start.

2. Don't know your particular board, but many of the boards I'm more familiar with only support change

detection or clocked sampling on port 0.  

-Kevin P

[CurtisHx]

Thanks for those suggestions.  It gives me a few more things to try.

To answer point 2: Page 11 of the datasheet for the PXIe-6535 indicates change detection is available on all ports/lines, which a change detection resolution of the sample clock period.  With the sample clock configured at 10mhz, the PXIe-6565 should collect 50,000 samples while the heart beat line is high.

I tried getting rid of the task.Timing.ConfiguresSampleClock line, with the same result.  It still misses some edges.

[Kevin_Price]

I see what you mean from the datasheet, though I still wonder if i t might have been worded unclearly.  The general symmetry found in DAQmx makes me kinda suspicious of configuring a task for both a sample clock *and* change detection.  A wide range of multifunction boards that support change detection requires a choice of one or the other, not both.

When I've used change detection on MIO boards, I've acquired samples only and exactly when one of the watched edges makes a transition.  I would *not* expect to "collect 50,000 samples while the heart beat line is high."  I'd expect two samples from such a pulse -- one when the heart beat line transitions high and one when it transitions back low.

I'm not sure I'm fully clear on what you really need to do vs. things you're doing in an effort to troubleshoot.  The main thing I got from the original post was to get your software to "sync up" to this heartbeat pulse.  Digital change detection ought to be one method, but there may be other simpler ones.  Let me outline what I'd do in LabVIEW, maybe it'll help partially, like a map in a foreign language.

1. Configure sample timing to be based on Change Detection.  I wouldn't expect to do any "sample clock" configuration.  I'd probably configure to be sensitive only to one of the two edges of the heartbeat pulse.  I'd expect this to produce 1 sample per second.

2. The software that needs to sync up would first read all available samples (if any) and ignore them.  It would then immediately enter a repetitive loop where it would first request 1 more sample.  This function call wouldn't return with data until the next heartbeat pulse.  Then the rest of your software can do what it needs, and you can loop around and iterate again on another heartbeat.

Often a digital pulse signal can simply be used as an external sample clock for an analog or digital task.  That might be simpler than dealing with possible quirks of change detection and change event handlers.  I'm not sure either way whether your 3.3V signal will work for that -- you may need something closer to 5V.

-Kevin P

[CurtisHx]

---

Kevin_Price wrote:

I see what you mean from the datasheet, though I still wonder if i t might have been worded unclearly.  The general symmetry found in DAQmx makes me kinda suspicious of configuring a task for both a sample clock *and* change detection.  A wide range of multifunction boards that support change detection requires a choice of one or the other, not both.

I tried pulling out the Task.Timing.ConfigureSampleClock with the same results.

---

Kevin_Price wrote:

When I've used change detection on MIO boards, I've acquired samples only and exactly when one of the watched edges makes a transition.  I would *not* expect to "collect 50,000 samples while the heart beat line is high."  I'd expect two samples from such a pulse -- one when the heart beat line transitions high and one when it transitions back low.

Right. I was thinking of the start trigger, not digital change detection.  The first two arguments / parameters to the Task.Timing.ConfigureChangeDetection are the rising and falling lines, respectively.  Theoretically, if an empty string is passed to the falling line parameter, then a falling edge won't fire change detection.  The problem is a rising edge doesn't always fire the change detection event when configured for rising edge.

---

Kevin_Price wrote:

I'm not sure I'm fully clear on what you really need to do vs. things you're doing in an effort to troubleshoot.  The main thing I got from the original post was to get your software to "sync up" to this heartbeat pulse. 

Exactly correct.

---

Kevin_Price wrote:

2. The software that needs to sync up would first read all available samples (if any) and ignore them.  It would then immediately enter a repetitive loop where it would first request 1 more sample.  This function call wouldn't return with data until the next heartbeat pulse.  Then the rest of your software can do what it needs, and you can loop around and iterate again on another heartbeat.

This is probably going to wind up being the way it gets done.  I tried using a start trigger on a PFI line (connecting the heartbeat signal to PFI4), and I found another bug, where the start trigger will fire on the rising or falling edge, regarless of configuration.

[danniwithNI]

Hi Kevin,

It seems like the remaining issue at this point is that  a rising edge doesn't always fire the change detection event when configured for rising edge. Are you still experiencing this behavior? Does it occur on all lines? Are you able to reproduce it using a change detection example? Attaching the simplest reproducing piece of your code would be the most helpful next step to finding the source of this behavior.

If you think you've located a bug, I would recommend calling NI to report it and sending in the simplest reproducing case of your code. Additionally, I'd recommend keeping this forum thread to specifically the change dtection issue to keep the thread searchable for future customers, so if you think you've identified another bug I would recommend creating a separate post for further discussion on that topic.