From 04:00 PM CDT – 08:00 PM CDT (09:00 PM UTC – 01:00 AM UTC) Tuesday, April 16, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Mute
- Printer Friendly Page
6509 Change Detection Events
JVL
Member
06-26-2006 04:39 PM
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report to a Moderator
I have configured a 6509 Digital I/O card for change detection events on a line and it seems to work ok. Is there a way to unregister change detection events and return the input channel to normal operation? I try to unregister the event by using a NULL callback pointer but the next digital read is met with a timeout problem. In simplest terms, I want to be able to configure change detection events for the duration of a test and then revert to the previous mode of operation when the test is done. This is a TestStand/LabWindows based test fixture. There are a couple of test steps in the tester where I want to detect events. The rest of the time, I want to perform simple digital I/O.
Thanks,
John
Jesse_O
Active Participant
06-27-2006 09:51 AM
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report to a Moderator
Hello jlgeek,
I have found documentation that explains how to unregister a NI-DAQmx Software
Event. You can find it here.
This article explains that you should pass a NULL value for the event callback
function pointer. This seems to be what you have done, however you cannot
unregister (or register) an event while a task is running. You must stop
the task and then unregister your event.
I hope this clarifies things,
Jesse O.
Applications Engineering
National Instruments
Jesse O. | National Instruments R&D
06-27-2006 10:00 AM
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report to a Moderator
Hi Jesse,
Thanks for your input. I am stopping and starting correctly. I think that I've solved my own problem after much digging through the references. It appears that when change detection is configured, the sample timing type is set to DAQmx_Val_ChangeDetection and when normal sampling is to resume, the sample timing must be reset. In my case, the default timing was set to DAQmx_Val_OnDemand (obtained by DAQmxGetSampTimingType). Once I set it back via the DAQmxResetSampTimingType, things seemed to be ok. It is unfortunate that in the manuals, there isn't much information other than a simple statement of purpose and a function prototype. There should be at least a page of information on how the change detection works and what it changes under the hood so that you can change it back when you are done.
Thanks for your input. I am stopping and starting correctly. I think that I've solved my own problem after much digging through the references. It appears that when change detection is configured, the sample timing type is set to DAQmx_Val_ChangeDetection and when normal sampling is to resume, the sample timing must be reset. In my case, the default timing was set to DAQmx_Val_OnDemand (obtained by DAQmxGetSampTimingType). Once I set it back via the DAQmxResetSampTimingType, things seemed to be ok. It is unfortunate that in the manuals, there isn't much information other than a simple statement of purpose and a function prototype. There should be at least a page of information on how the change detection works and what it changes under the hood so that you can change it back when you are done.
John
