LabVIEW
get notifier status give invalid refnum
Solved!
I am using notifier function to stop mutiple parallel loops.but found get notifier status always give false value and displyed invalid refnum on probe window. please find image and attached file for more detail. how can i fix this problem.
Hmmm... I think you should actually just start over and use the queued message handler template instead. You're not so far along that you can't back out now, and it is a much more robust solution. You shouldn't depend on the notifer stopping the loop. Your VI should be calling a state that stops the loop, and the main loop you have should be a state that keeps repeating itself until the event structure intervenes by queueing up the exit state when you press the stop button.
I think your logging loop should be controlled by a second queue. It would then only update when needed and will no longer need the wait.
The error cluster is your friend. Take time know and appreciate it - and wire it up! You have to pass any errors along if you can ever hope to trap an error programmatically.
Thank you so much. actually, error handling can also do same function and shown on image below.
I aslo create a simple VI to test get notifier status function and also work fine. just don't understand why it doesn't work that implemented
The notifier is being destroyed before your data gathering loop is able to read it. Use the Merge Error function to combine the errors from all of the loops and close the Notifier after the merge errors. What this will do is make sure the notifier is not destroyed until all of the loops are done.
If you change to the QMH, you will want to do something similar for all of your queues.
@crossrulz wrote:
The notifier is being destroyed before your data gathering loop is able to read it. Use the Merge Error function to combine the errors from all of the loops and close the Notifier after the merge errors. What this will do is make sure the notifier is not destroyed until all of the loops are done.
If you change to the QMH, you will want to do something similar for all of your queues.
Yeah, and it's a solid fail because the main loop has a wait in it, all but ensuring that the queue will be destroyed before it gets a chance to read it.
But that's why I suggested something like QMH because you don't have re-invent the wheel.
it's working, thank you, but i am curious why stop function in second image above is working fine without merge error. is it in race condition?
@jiannan wrote:
it's working, thank you, but i am curious why stop function in second image above is working fine without merge error. is it in race condition?
You are absolutely correct. It is a race condition. Sometimes it reads the notifer before it gets destroyed. I bet that if you ran the simple example enough times, the notifier will get destroyed before the other loop can read it.
In the complex example, the top loop will always complete before the main loop because the main loop has a wait in it. By the time it's ready to read the notifier, the top loop has completed and so has the release notifier.
[edit]
Querying the instruments also takes time.
[/edit]
@jiannan wrote:
is it in race condition?
A race condition I have personally been burned by many times. I had to learn the hard way to not shut down your communcation lines until everybody is ready for it. Like with a Producer/Consumer, I much prefer the consumer to close the queue since it is the one that is being commanded to shut down. There shouldn't be anybody else trying to use the queue after that point, therefore it is safe to destroy the queue.
