05-09-2007 11:46 AM
05-10-2007 02:19 PM - edited 05-10-2007 02:19 PM
Hi epertsov,
Can you please let me know what software and language you are using to program? Where is your signal coming from, and how fast is it? Have you verified your signals are correct by viewing them in a test panel when in Measurement and Automation explorer (MAX)? Does this happen with multiple USB ports? Posting a screenshot would be very helpful, so I could see what lines you are using as inputs.
Can you pinpoint the times when it does and does not work? I ask all of these because I was unable to reproduce the problem with a PCI card, and the 6221 is capable of doing this operation.
Message Edited by David L. on 05-10-2007 02:19 PM
05-10-2007 05:06 PM
The first line corresponds the event when I pressed button. The second line - when I released button. They are correct. The third (and the last) line is extra line that displays wrong value. I understand that this signal could be noisy, so it could be some extra lines, but I hoped that the last displayed value should be correct.
I also tried "Read Dig Chan-Change Detection" project from "..\NI-DAQ\Examples\DAQmx ANSI C\Digital\Read Values" directory and I couldn't get it work either.
Thanks and regards,
Eugene
05-11-2007 02:47 PM
I ran the first example, and believe that you are seeing correct results. The Data posted is correct in that when you press the button, a change occurs, and is recognized on bit 1. When you release the button, another change occurs, and is again recognized. The reason why a change is marked for both the rising and falling edge is because the example configures the DAQmxCfgChangeDetectionTiming() for this. You can change the function inputs if you would like it to act differently.
05-11-2007 03:14 PM
Hi David, the problem is that in my connections when button is depressed, reading is 1, when button is released, reading is 0. I checked it in MAX. In this particular example when I pressed the button, I saw only one first line. when I released, I saw 2 new lines, last one with incorrect reading. It does not happen every time. But if you do this something like 1- 3 minutes with different speed, you alweas have this situation and sometimes you have not 2 readings per reconnection but 3,4,5...
What is related to "Read Dig Chan-Change Detection" it never comes to reading point at all.
Regards,
Eugene
05-11-2007 03:17 PM
Sorry, I was mistaken in my previous replay: when button is depressed, reading should be 0, when button is released, reading should be 1.
Eugene
05-14-2007 06:24 PM
I have personally run this example, along with LabVIEW examples, and cannot reproduce the issue you are seeing. One thing I did notice is that if the voltage is close to TTL Logic, than the value may change often and rapid. Please make sure that your values are 0-.8V for low and 2V-5V for high values. If there is any more detail that you can give me, that would be very helpful.
The “Read Dig Chan-Change Detection” never shows data because it is not coded too. It is coded to read the data forever( while (1) ) and does not have a printf statement in it. If you are not getting any errors, besides seeing no data, than the program is running. I may suggest either printing the data or replacing the while loop with a for loop, continuously building the data array, and then looking at it in the end.
05-15-2007 10:41 AM
Hi David,
Our low level is about 0.9. I will make it below 0.8 and let you know how it works.
What is related to “Read Dig Chan-Change Detection”, I put there printing, but it does not print. Instead it gives me error -200284.
Thanks and regards,
05-15-2007 09:04 PM
David,
now we have good levels, but the same behavior. So the question is: are you working with 6221? and if so, maybe our device is bad and we should replace it?
Eugene
05-16-2007 10:01 AM