From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

DAQmx Change Detection - Unregister for Events Error

Solved!
Go to solution

I am trying to use DAQmx to do change detection on some digital lines. I think I have setup everything according to this article, however I am consistently getting the error "Error 1 occurred at Unregister For Events in Test Change Detection - Unregister Error.vi". When I change the structure to register some other event, not involving DAQmx but using the same structure, I don't get this error.

 

I will need to implement this on a code that runs for a very long time and according to the above article:

 

"Use the Unregister For Events function and the Destroy User Event function to release the associated events and the user event reference. LabVIEW unregisters all events and destroys existing user events automatically when the top-level VI finishes running. However, to conserve memory resources, National Instruments recommends that you unregister and destroy user events explicitly, especially in an application that runs for a long period of time."

 

Here are some screenshots of my BD, as well as the .vi. Note that the actual change detection is working well, it's just after I click "stop" that I get the error generated by the "unregister for events.vi"

DAQmx Change Detection - Register for Events Error - BD1.png

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

DAQmx Change Detection - Register for Events Error - BD2.png

 

Note when Uploading the .vi, I was having the issues described on this thread and had to change the file name...

0 Kudos
Message 1 of 8
(4,125 Views)

You need to unregister for the event before clearing the DAQmx task.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 2 of 8
(4,110 Views)
Solution
Accepted by topic author ColeV

@crossrulz wrote:

You need to unregister for the event before clearing the DAQmx task.


Clearing the task implicitly unregisters the events.  If you clear the task, rather than simply unreserve it, the event is already unregistered and you do not need both nodes.

 

Or simply put, the event is part of the task.  no task, no event and LabVIEW cleans up the registrations for the non-existant event.  Other events that arenot "Owned" by similar I/O Sessions must use the unregister (Like User Events)


"Should be" isn't "Is" -Jay
0 Kudos
Message 3 of 8
(4,100 Views)

Jeff·Þ·Bohrer wrote:

Clearing the task implicitly unregisters the events.  If you clear the task, rather than simply unreserve it, the event is already unregistered and you do not need both nodes.

 

Or simply put, the event is part of the task.  no task, no event and LabVIEW cleans up the registrations for the non-existant event.  Other events that arenot "Owned" by similar I/O Sessions must use the unregister (Like User Events)


That doesn't exactly sit right with me.  Do have any documentation on the unregistration on clearing?  Though, it does kind of make sense based on the error code 1 the OP is seeing.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 4 of 8
(4,089 Views)

@crossrulz wrote:

Jeff·Þ·Bohrer wrote:

Clearing the task implicitly unregisters the events.  If you clear the task, rather than simply unreserve it, the event is already unregistered and you do not need both nodes.

 

Or simply put, the event is part of the task.  no task, no event and LabVIEW cleans up the registrations for the non-existant event.  Other events that arenot "Owned" by similar I/O Sessions must use the unregister (Like User Events)


That doesn't exactly sit right with me.  Do have any documentation on the unregistration on clearing?  Though, it does kind of make sense based on the error code 1 the OP is seeing.


As I was given to understand (I have no document to swear by and I may misspeak terms that the developers of these things abstract away from us mere mortals)

Events are generated by the application that owns them.  DAQmx owns that event and specifically the task that is in that instance of NI DAQmx.  Ditto VISA events  VISA owns them.  When the sessions close (or Tasks clear) there cannot be events generated or really any other thing done to the event since it is Poof- Not there anywhere around! DAQmx or VISA destroyed the event.  (With me so far?)  

 

User and Dynamic events are owned by LabVIEW.  LabVIEW is still around untill the top level VI goes idle those events, once requested to be in existance are in existance and will keep queueing up regardless of how many structures are registered for the event unless the event is destroyed.

 

One of the reasons I dislike using dynamic events- Oh I DO Use them but they can chew up a lot of stuff unless smacked down when you want them to go away.


"Should be" isn't "Is" -Jay
0 Kudos
Message 5 of 8
(4,078 Views)
Solution
Accepted by topic author ColeV

A number of posts have been coming up recently about this in the DAQ forums.  It appears that in a fairly recent version of LabVIEW (LV 2013 according to this post) some changes were made regarding the error reporting for unregistering events.

 

If you want to explicitly unregister your DAQmx Events, you'll need to first stop the task, then unregister the event, then clear the task as shown here.

 

In older versions of LV the unregister did not return these errors (for example, on my system using LV 2011 and DAQmx 9.7.5).  In more recent versions, it appears errors are returned by the unregister in the following cases:

 

Attempting to unregister an event associated with a task that is still running:  The unregister will return an error informing the user that it isn't possible to unregister the task while it is running.  According to comments in the first post I linked, it sounds like in older versions of LabVIEW the unregister would silently fail--the error isn't new, but LabVIEW is now correctly reporting it.

 

Attempting to unregister an event when the task has already been cleared:  The unregister will return an error consistent with trying to unregister an event that is not registered in the first place (i.e. because DAQmx Clear Task has already unregistered it for you).  I'm assuming that the reason that this error is now showing up is due to the fix for the error reporting in the Unregister For Events call, but then again I'm not sure if DAQmx Clear Task has always unregistered the events implicitly or not...

 

 

Best Regards,

John Passiak
Message 6 of 8
(4,066 Views)

Thank you for all of the help, this actually clears up a lot of the misconceptions I had with dynamically registering events. My original code (of which this example is a subset) registered some DAQ change detection events, as well as some other events and I really didn't understand the "ownership" concept.

 

So it appears that if I want to register/unregister different classes of user events (e.g. behaviours of the UI) as well as DAQ change detection events (e.g. DAQ change detection events where the lines that we detect on are changed on the fly) then the optimal way to do this is via different event structures.

 

If anyone has seen other examples of more complicated event structure handling, including registering, unregistering and generating dynamic events I would appreciate being pointed to them. The examples that come with LabVIEW show the bare basics but don't make it clear how to do this in a code architecture that is based on the continuous measurement and logging project template.

0 Kudos
Message 7 of 8
(3,997 Views)

@ColeV wrote:

 

So it appears that if I want to register/unregister different classes of user events (e.g. behaviours of the UI) as well as DAQ change detection events (e.g. DAQ change detection events where the lines that we detect on are changed on the fly) then the optimal way to do this is via different event structures.

 


That is something NI should fix someday-

 

An event reg refnum may contain references to several events and you can register however many you want.  but, you can only unregister them all and not selectivly


"Should be" isn't "Is" -Jay
0 Kudos
Message 8 of 8
(3,983 Views)