LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

error 1 in notifier

Dear experts,

 

I am trying to use two parrelel loops to control my behavior training rig. I use a notifier to send the information from bottom loop to the top one (see attached vi). The top loop is used to control stimulus delivery and needs to read info from the bottom loop constantly. The bottom loop is used to detect licking behavior and write the time stamp of each licking event to file. I always get this Error 1 for the "get notifier status" of the top loop.

 

Error1.jpg

 

Could someone help me solve this problem? I need to run the bottom loop as fast as I can so I can keep an accruate recording of licking events.

 

Thank you so much!

 

-Herbert

 

0 Kudos
Message 1 of 11
(6,553 Views)

It's a little difficult to tell what operations your two loops are doing or how your data is flowing in the top loop.  It sounds like you are going for a producer / consumer architecture and you might consider taking a clean go at this using the producer consumer template. 

That said, you probably don't want to use a notifier for transmitting data between loops, you should use a queue instead since that will guarantee the data will arrive.  I think your error stems from using the notifier status vi instead of a wait on notification.  Your top loop is probably reading the notifier before there's anything in it.  Typically, you would slow down your loop to with a only run when there's data instead of as fast as possible (which tends to lock up your computer).  Of course, you also have 4 wait functions in the flat sequence, and I'm not sure how these don't conflict in making the top loop run quickly.

Other suggestions would be to use the left side of your structures as inputs and the right sides as outputs -- this would help with the readability of your program.  Encapsulating some of the timing & boolean logic functions in subvi's would also help, and allow you to use error clusters to direct flow control instead of flat sequences.

 

Hope that helps, Chris

 



This avatar was scraped from an instance of good public spending: http://apod.nasa.gov
0 Kudos
Message 2 of 11
(6,540 Views)

In addition to the comments already posted it is possible that the upper loop runs for several seconds after the stop button is pressed and the lower loop stops almost immediately. In this situation the notifier will have been released before the upper loop tries to check the status. Checking status on a non-existent notifier I think will produce error 1.

 

With a straightforward state machine implementation of what you appear to be trying to do in the upper loop, its size would be reduced to about the size of the palm of your hand. And be much more readable, robust, and easily modified when the requirements change.

 

The first LV program I wrote (in LV 1.2) was a stimulus/response program. Its diagram fit on a 7 inch Mac Plus monitor without scrolling. Direct descendents of that program are still running today.

 

Lynn

0 Kudos
Message 3 of 11
(6,536 Views)

Hi Chris,

 

Thanks a lot for your message! and I apologize for the code..

 

I guess I could explain the vi a little more. The bottom loop monitors the animal’s action and the top loop is executing a series of events to the animal, while receiving info from the bottom loop at each event. So the bottom loops should run as fast as possible (to get constant update on the animal’s status), and the top loop should run at the speed I specified (therefore much slower). So the top loop only needs to read the current status of the bottom loop, and data can be lost during the transfer between loops. In addition, if I use a queue, the bottom loop will generate much more data than the top loop can handle. 

 

If the bottom loop is running at a faster speed, there should be data in the notifier when the top loop reads it, right? also, for the “get notifier status” function, Labview help says “If no notification is available, the function returns the zero value for the element data type you wired in the obtain notifier function”, which means the it should be reading the default “F F” 2-element array I wired to the obtain notifier function?

 

Thanks again!

 

herbert

0 Kudos
Message 4 of 11
(6,516 Views)

all inputs are valid, except the ones that specifically cause other errors.

 

Your error 1 may not come from Obtain Notifier.

In the case that error in (no error) has already an error it is passed through.



Thank you & Best regards
syrpimp

=======================================================
“You must continue to gain expertise, but avoid thinking like an expert." -Denis Waitley
0 Kudos
Message 5 of 11
(6,512 Views)

Hi Lynn,

 

Thanks for the reply. I’m sorry about the code..

 

You are right that the upper loop indeed runs for a few seconds more after the stop button is pressed. But the error 1 I got here is in the first execution of the top loop (the very first time "get notifier" status runs). So I’m not sure what the problem is then.. Do you have any other ideas?

 

Many thanks,

 

-Herbert

0 Kudos
Message 6 of 11
(6,512 Views)

"...the upper loop runs for several seconds after the stop button is pressed and the lower loop stops almost immediately." Actually, how do you stop the bottom loop until the first loop reaches a full stop? Would love to hear your advice! Thanks!

0 Kudos
Message 7 of 11
(6,506 Views)

Look at the vi library attached, it demonstrate on how to handle an error.

 

created by  By: F._Schubert



Thank you & Best regards
syrpimp

=======================================================
“You must continue to gain expertise, but avoid thinking like an expert." -Denis Waitley
0 Kudos
Message 8 of 11
(6,491 Views)

Well, that's one of the problems with the sequence structures -- they take far longer than the read of the stop control (which happened immediately in your loop), so that your stop command isn't read until the next go around.  Since you have 2 notifier status read vis, the second one will probably produce and error since the notifier has been closed after stop was pushed. 

 

As Johnsold alluded to, a good alternative would be a state machine so that you can remain in a state until the time has elapsed, or you've recieved a value that allows your program to go to the next state. Ideally, each pass at the state would pass quickly (less than 100 ms) so that if you push stop, you can go to a Stop state quickly. 

 

And although it isn't a very good idea, you could read your data with a local variable instead of the notifier since you don't need the full data stream in the top loop. 

 

Also, it is highly recommended to put in a small delay so that your CPU doesn't max out on your wait loops.



This avatar was scraped from an instance of good public spending: http://apod.nasa.gov
0 Kudos
Message 9 of 11
(6,447 Views)

Thanks a lot! I'll give the state machine a try!

0 Kudos
Message 10 of 11
(6,426 Views)