10-22-2012 09:44 AM
I have used successfully Notifiers on LabVIEW 2008 and Windows XP. I cannot say the same about LabVIEW 2010 and Windows 7 professional. I have two programs that use notifiers and both of them use the same Vi’s for sending and receiving the notification. Only one program runs at a time. The first program works and the second does not. By debugging the second program you can see that one notifier VI sends the notification but the notifier VI waiting to receive the notification keeps waiting as if the notification was never sent. There is no other function waiting for the same notification. I had to change the notifiers by functional global variables to get the program two to work. I tried using “Wait on notification” and “Wait on notification with notifier history”.
Thanks in advance for any help
10-22-2012 09:49 AM
you haven't set ignore previous True have you?
10-22-2012 12:53 PM
I'm with Jeff. It sounds like you have the Ignore Previous set to TRUE. Try changing that to FALSE and see what happens.
Can you share any of the code to help us debug?
10-22-2012 01:39 PM
I left the “ignore previous” input unwired which means it takes the default value of false. I have attached the screen shoots of the two Vis attached as a pdf document. The VI's run in parallel. Sorry that I did not attached the original VI’s, because of all the sub VI’s involved.
I used case structures to disable the notify functions for now until I find the solution.
Many thanks
10-22-2012 02:11 PM
@rotzeri wrote:
I left the “ignore previous” input unwired which means it takes the default value of false. I have attached the screen shoots of the two Vis attached as a pdf document. The VI's run in parallel. Sorry that I did not attached the original VI’s, because of all the sub VI’s involved.
I used case structures to disable the notify functions for now until I find the solution.
Many thanks
Unfortunately we cannot see all the hidden code, but I can guarantee that the true nested inside the false will never run due to the false constant attached to it.
10-22-2012 04:29 PM
With such a limited view it is difficult to follow your overall logic and how things interact. However, some comments about the code in general. The frame structure is completely unnecessary in your first page of code. Dataflow will control things quite nicely for you. The only thing you need to add is a single frame around your Wait code with an output from there wired to later code. Passing an error cluster through this single frame will often provide the data dependency you need. All of your othe rcode already has data dependencies which will control the execution order.
10-22-2012 05:36 PM
@Mark_Yedinak wrote:
With such a limited view it is difficult to follow your overall logic and how things interact. However, some comments about the code in general. The frame structure is completely unnecessary in your first page of code. Dataflow will control things quite nicely for you. The only thing you need to add is a single frame around your Wait code with an output from there wired to later code. Passing an error cluster through this single frame will often provide the data dependency you need. All of your othe rcode already has data dependencies which will control the execution order.
Mark:
I am wondering if vi2 is an attempt at rewriting vi1...?
10-23-2012 01:59 AM
The cases not shown have the functional global variables that at the moment substitute the notifiers. I shown on purpose the case that never executes, because it contains the notifier code that I used before the functional globals implementation. When I used the notifiers I ran the program in debug mode and what happens is that the wait on notification function starts waiting before the notification is sent. Once the notification is sent the wait on notifier function keeps waiting as if no notification has been sent. Both parallel notifiers use the same name, and nobody else in the program acquires the notifier with this name.
Before the wait on notifier function executes two sets of other VI’s execute, but only one at a time. When the first set of VI’s execute the wait on notification works. When the second set of Vis execute the wait on notification does not work. Once the wait on notifier starts waiting for the notification to be sent, the program does not execute any other VI expect for the one that will sent the notification. There is only one place in the program that waits on notification. They are up to eight sent notification VI’s, each independen and all of them run in parallel with the main program. Each one of the eight sent notification VI’s use different notifier names. The wait on notification function receives the name of the notifier it wants to wait for. During the debugging session it was checked that the wait on notifier function receives the correct notifier name.
Some strange combination of events make the notifiers communication channel irresponsive. The two sets of VI’s that execute before both work and do the job. These set of VI’s are quite big and that is by there are not attached to this message. These set of VI’s use error management, which means that if an error occur previous to the wait on notification function, the program execution will stop and an error message is displayed. Since these mentioned VI’s control the movement of a machine, the user would notice that something went wrong, which is not the case at the moment.
During the execution of the program the wait on notifier function is called more than once for the same natifier name. The first time it is called for the notifier with the problem it works, but not the second time.
I tested the notifiers VI’s alone simulating the same functionality as in the main program and they work ok. As I said my hypothesis is that there must be some strange combination that corrupts the notifier communication channel.
Again many thank for your support.
10-23-2012 10:16 AM
You have checked that the plate name isn't somehow changing/becomes invalid?