LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Queues and notifiers - please help?!

Another question - I have heard that one should avoid using local variables but in this situation how can I avoid it? 

Message Edited by Erik_1 on 06-29-2007 08:46 AM

0 Kudos
Message 11 of 16
(989 Views)

Local variables aren't inherently bad, and in some situations you must use them.  You definitely need to use the stop local variable to be sure all the loops stop.  And I see nothing wrong with the way the other variables being used.

It all comes down to "race conditions" and there are a lot of messages on the subject in the forums worth looking at.  It involves problems with timing, are you trying to read a variable before a value of interest gets written to it?  Not usually a problem with static type of data, but  if you have rapidly changing data like from an acquisition, you could wind up reading the same piece of data twice or completely missing a piece of data if a new value gets written before the previous value gets read.  Buffers and queues are the structures that help with these issues.

Also, if you have multiple readers and writers.  Do you have 2 places in the program trying to write different values to a variable at the same time?  For example, a boolean where one spot of the program writes True and another spot writes False and they are both executing and constantly overwriting each other.

If you don't have these 2 kinds of problems, then local variables aren't going to cause problems.  There may be some other situations I'm not thinking of right now that could be a problem, but I'm sure others will chime in if I missed something.

 

0 Kudos
Message 12 of 16
(974 Views)
Well that certainly makes sense - how does their use affect memory useage and speed of the programs execution?
0 Kudos
Message 13 of 16
(970 Views)
A wire is always the best way to transfer data.  Using a local variable makes an extra copy in memory, but this should only cause problems if you are dealing with large arrays, large clusters, or any huge dataset.
 
Reading or writing to a control or indicator directly is the fastest.  By way of a local variable is almost as fast.  By way of a value property node is very slow.
0 Kudos
Message 14 of 16
(964 Views)

A couple additional questions...

 

Why did you remove all the error wires? Should I not worry about notifier errors?

 

I can't seem to get the Auto control sub-loop working properly - any suggestions? What I want to happen is for the user to select auto control, then select a component to test - the VI should then run through that test sequence. It actually seems to do that part properly but when I try to select another component I get some sort of notifier error. I don't want the user to have to select auto control a second time in order to select an additional component - I want it to wait in the auto control sub-loop until the user either changes out of auto control (to manual for example) or selects another component to test. Attached is the code. Even if I select auto control a second time before selecting a component I still get an error....

 

Thanks!

 

-Erik

0 Kudos
Message 15 of 16
(949 Views)
I think you may be getting a notifier error because the new notifier you added for component does not have its notifier reference wire run all the way through the loop in the "select component" case.  It uses the default (an empty reference or Not a Refnum) which would cause an error when that gets fed into a notifier function.  So wire that reference all the way through in that event and the case structure inside the event.
 
The complication with the auto loop is that now you have two wait for notications in it.  So you need the component notifier to run in order to get the inner loops to run which only occurs when the select component button is pressed and that event structure runs.  The auto notifier is also in the loop, so it will wait on that.  It won't delay execution of the inner loops since it isn't driving anything but the indicator.  But when the inner loops complete, the outer loop will be forced to wait on that notifier before the next iteration of the outer auto loop runs again.   Which won't happen until the send command button is pressed again.  (I'm not sure why you would need the cancel notifier function.)
 
Perhaps you should enter some timeouts into one or both of those wait on notifications so that they will run after a period of time and you don't have to wait for both notifications to occur.  But if they both have a timeout, then you would have to handle that situation so that the loops don't run when you didn't intend them to.  You would have to watch the timed out? boolean and only run the loops if one OR the other timed out? is true.
 
You may want to rethink the logic a little bit.  Maybe it would be better not to have two separate loops for manual and auto.  Put them into different cases within a single "Run" notifier loop that is based on what command it gets sent from up top rather than having commands sent into different notifiers.  (I don't think you could have auto and manual phyisically occuring at the same time, but programmatically it could happen.)  I wonder if you need a send control command and a select component command.  Perhaps one "Perform test" button which takes the component and the auto/manual mode settings and sends that data to a single "test" loop.
 
I think you should worry about notifier errors.  I thought the errors would be handled automatically  (there is a setting in VI properites/Execution for it).  The error wires are often used to enforce operation in series, but since in this case, there are several things happening in parallel, it gets complicated to merge errors, or handle them through numerous extra shift registers.  Perhaps someone who is a higher expert in error handling can help and suggest something on this.
 
-Bill
 
0 Kudos
Message 16 of 16
(919 Views)