LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Invalid notifier references

This ranks in my top two for oddest behaviour encountered in LV. The other one's also relevant, more on which later.

 

I have a medium/large application which relies heavily on queues and notifiers for inter-process communications. I also rely heavily on notifiers for internal loop control: Obtain a notifier with a Boolean data type, then in one branch carry out an action, sending a notifier when it's complete; parallel to this, collect data in a while loop and stop when the notifier status is true.

 

For instance, here's some dummy code:

inv-notifier.png

 

For simplicity's sake, I've left out any other code, but suffice to say that the collect data subVI contains Wait On Notifier (with a reasonable timeout) returning data from another process.

 

Seems like a legit approach. But imagine my surprise when, after several hours of tracing odd results in my code, I found that the notifier primitves weren't executing properly, and that the reference returned from Obtain Notifier was an invalid refnum! Restarting LabVIEW had no effect; restarting the PC had no effect. I even tried generating unique notifier name strings from a random number, on the off chance it was an unclosed reference to a named notifier. No error is generated by the Obtain Notifier VI telling you that it's returned an invalid refnum, subsequent nodes don't error, and the notifier VIs don't register with Desktop Execution Trace Toolkit when this happens.

 

This happened in several states which contain a similar architecture. Bizarrely, the only thing that seemed to solve it was replacing the notifier structure with a fresh set of queue and/or notifier VIs.

 

This odd behaviour struck me as similar to something I've seen with Timed Loops, as I am pretty sure that I will have created a block of code with these notifiers in one state, then copied and pasted into another state when required. If you have a VI containing a timed loop, and you copy and paste that timed loop within the same VI, occasionally you'll find that one or more of the Timed Loops don't run at all, even if they have different names. I can never remember whether I used to see an error or not - memory suggests I didn't, the KB suggests I should have - but it was definitely linked to the copy/paste process.

 

There's an old CAR on force destroyed notifiers causing similar problems, but as these are all independent notifiers which are most definitely not called anywhere else, I don't think it's relevant.

 

So, does this ring a bell with anyone else?

---
CLA
0 Kudos
Message 1 of 3
(2,652 Views)

This doesn't sound familiar, but assuming your description is accurate (e.g. that you actually check the errors, which your example code doesn't show), I would suspect compiled code separation. I know of some problems that happened with it where the compiled code sometimes fails to sync with the BD, and since you say replacing the nodes solves this, it sounds like a likely suspect.

 

If you still have code which demonstrates this, you can check this theory by clearing the cache or by changing the setting on the VI. It might also be advisable to send the code to NI.


___________________
Try to take over the world!
0 Kudos
Message 2 of 3
(2,621 Views)

I'll have a play over the next few days to see if I can replicate and repair. As you can imagine, a quick refactor was the preferred route at the time thanks to deadlines.

 

The thing that I struggle with is that DETT showed zero activity on any of those notifiers in question. The higher level notifiers and queues, no problem, but those little local ones...nada.

 

That was just dummy code btw - errors are dealt with downstream in a local/central error handler combo. It's a little tedious posting actual code snippets when you have to airbrush out almost everything of interest from it first! 🙂

---
CLA
0 Kudos
Message 3 of 3
(2,607 Views)