Change detection using PCI-6514 and Ni-DAQmx

[ETSS]

Hi,

I'm trying to set up change detection for an 8 bits digital input port. When I configure all the port lines (one channel per line) and activate an input of the port, I get the following result:

- The DAQmxReadDigitalLines call wakes and the right line is detected (set to 1);
- The DAQmxReadDigitalLines call wakes a second time and I get an array of zeros;
- The DAQmxReadDigitalLines call wakes twice again and I get the same results than the two first calls;

This happens every time I activate an input but the result does not come necessarily in the same order.
All the lines of the port are configured for raising and falling event.

Any idea of what the problem could be ?

[AlanArmstead]

Hello,
What programming language are you using? LabWindows/CVI? If so, check out the attached example. If you are not using CVI, you might still want to take a look at the C file included in the zip folder. You can check and see if there are any major differences between this program and yours.
Hope this helps.
-Alan A.

[ETSS]

I'm using Visual C++ 6.0.

I tried the change detection sample with a PCI-6527 instead of a PCI-6514 and I got the same results. I then tried the C# sample for .NET and I got ..... the same thing. I think I can deduce that it is not a card type or a programming language problem. Moreover, from the tests I made It seemed that raising and falling samples were provided in a random order.

I then made the same tests but trapping only falling or raising event. I found that raising events are perfect but that there is too much falling events. When I trap only falling events and I raise an input to release it afterward, I get a "falling" sample on the raising and one more on the falling.

In short, I want to be able to monitor perfectly some inputs with Ni-DAQmx and but It seems that it detects more events than it should. I know that in finite sampling mode instead of continuous I get the exact amount of falling and raising but by the time I process an event, there is a risk of losing some others precisely because I do not sample continuously.

I didn't have those problem with traditional Ni-DAQ. Is there a way to monitor change detection without losing events or trapping too much of them (false events) ?

[Allen H]

Hello,

I have a couple of suggestions for you. First, the 6514 has programmable input filters, so you can use that feature to eliminate any glitches that you may be seeing.

What kind of device is sending data to the 6514? Is it possible that the edges are not entirely clean or monotonic? As you mentioned, it does not sound like a problem with the board since you can see the same behavior on a 6527. I suggest that you try the input filters and see if they help.

Try this example: C:\Program Files\National Instruments\NI-DAQ\Examples\DAQmx ANSI C\Digital\Read Values\Read Dig Chan-Change Detection-Dig Filt

[ETSS]

There is no change even when I activate the filter on the inputs.

I read my digital lines in continuous mode and I get extra events (unwanted events)

I tried with different cards and different IO environments and the problem was always there. It makes me suppose that it is probably not a glitch problem.

Any idea or solution ?

[ETSS]

Thanks to all !!!

It was a sensitivity problem. I started to play with the minimum pulse width and the false events stopped.


Thanks again

[pey]

Hello ETSS,

I have exactly the same problem as you:

i have an application in C++ (with NiDAQmx driver) to read event on DAQ 6527, but I obtain extra events.

How have you done please?

How to play with the minimum pulse width? Have you concrete example? Help please!

Best regards,

                  PEY

[Daniel_L]

Hi Pey,

I haven't been working on this thread myself, but it sounds like the property that ETSS was referring to earlier was the "Set Filter Min Pulse Width" property. 

You can find the exact documentation and function calls in the NI-DAQmx C reference help (Start >> Programs >> National Instruments >> NI-DAQmx).  Try searching for "minimum pulse width".  If you are using the digital input lines, you'll want to to use the associated property.  Likewise, if you're using the counter inputs, then you'll want to use the properties associated with that. 

For example, for digital inputs:

Set DI_DigFltr_MinPulseWidth

int32 __CFUNC DAQmxSetDIDigFltrMinPulseWidth(TaskHandle taskHandle, const char channel[], float64 data);

Purpose
DAQmxSetDIDigFltrMinPulseWidth sets the Digital Input >> Digital Filter >> Minimum Pulse Width property.

I hope this helps,

Daniel L.

Applications Engineer

National Instruments

[pey]

Hello Daniel,

thanks for your response.

I have a NIDAQ PCI 6527 card (Digital 24 I/24 O). Indeed I thought to use the function: DAQmxSetDIDigFltrMinPulseWidth.  But do you think I can use this function with DAQmxRegisterSignalEvent? because into my callback (called by DAQmxRegisterSignalEvent), the function DAQmxReadDigitalLines seems to finish in timeout when I've configured DAQmxSetDIDigFltrMinPulseWidth. Thanks.

Best regards Daniel,

  PEY

[Daniel_L]

Hi PEY,

Perhaps you are setting the minimum pulse width too small, and the digital read is timing out? 

As for the DAQmxRegisterSignalEvent, I'm not sure if this is what you want for your application.  By definition, an event is an output signal that does not have a trigger or clock counterpart. Events are emitted to signify a device state change, the arrival of a certain kind of sample, the production of a certain amount of samples, or the passage of time.

The event that you were asking about was probably the Change Detection event, which is a signal a DIO device generates after it detects a change on the data lines.

If the digital read still doesn't work for you, why don't we take a step back and you can explain what you're trying to do in your application. 

Regards,

Daniel L.

Applications Engineer

National Instruments