Read Dig Chan-Change Detection Event example does not work with USB 6221

[David L.]

Eugene,

I tried my best to reproduce this issue, using both the USB-6221 and PCI-6251. I have not been able to see what you posted and are describing. I have also used not only the example program you posted, but the same counter part in LabVIEW. Have you tried different devices, and does this still happen? Does scoping the signal show you any evidence of a bouncing signal? Please let me know if there is any more information that you can tell me which may help reproduce this issue.

[epertsov]

Hi David,

I use USB-6221. I am not interested in PCI-6251. My scheme is: pin 96 connected with pin 66 via 10K resistor. Also pin 66 is connected to pin 82 via button. When button is released I have 4v on pin 66. when button is depressed, I have 0. When I read these values with the “C:\Program Files\National Instruments\NI-DAQ\Examples\DAQmx ANSI C\Digital\Read Values\Read Dig Chan” example, everything is OK. Now I ran “C:\Program Files\National Instruments\NI-DAQ\Examples\DAQmx ANSI C\Events\Signal\Change Detection\Read Dig Chan-Change Detection Event” example. I am not interested in labview. Often after I press and/or release button, I see on display that the last value is wrong. Obviously either hardware or software does not work properly.

Regards,

Eugene

[epertsov]

And by the way "C:\Program Files\National Instruments\NI-DAQ\Examples\DAQmx ANSI C\Digital\Read Values\Read Dig Chan-Change Detection" example also does not work with USB-6221. Namely: if I put breakpoint on the reading statement, I see that I never come there, alternatively if I put there printing, it never prints. So I wonder if it is possible to have some C or C++ example code that works with this card, not some other card and not in labview.

Regards,

Eugene

[David L.]

Eugene,

I only mentioned the PCI-6251 to let the community know that I tried different cards and could not reproduce the issue. Trying different cards let me know if this issue is isolated or not. For the example program, I was able to see the first 2 lines you posted, but did not get a third line.

00000000             --------

01000000             -X------

Although the first line detects a change, but does not mark an ‘X’- this is not a driver bug, as much as a slight programming oversight. The driver still detects a change, but does not put an X because an array (cachedData[]) is initialized to 0, and the algorithm in the code sees there is no difference between this array and the comparing array(data[]). You can correct this by manually altering the code if you know the original value. (Replace the line cachedData[64] = {0}; with cachedData[8] = {0,1,0,0,0,0,0,0}. This way, when the value changes to 0, the algorithm will see that bit 2 has changed and will mark an X.

One note: I did notice that if the button had a slow transition or loose connections, than I get false readings or multiple readings. When I do quick and clean connections, than there is not a problem.

[epertsov]

Hi David,

As I tried to stress all the time my concern is not that I get extra readings, my concern is that "Read Dig Chan-Change Detection Event"  example gives me often wrong readings at the end and  "Read Dig Chan-Change Detection" does not read anything at all. It is reproduced every time on my USB-6221. I will try to get another one to test the same issues.

Eugene