LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

notifier sent but never received

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

0 Kudos
Message 1 of 9
(3,296 Views)

you haven't set ignore previous True have you?


"Should be" isn't "Is" -Jay
0 Kudos
Message 2 of 9
(3,291 Views)

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?


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 3 of 9
(3,266 Views)

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

0 Kudos
Message 4 of 9
(3,254 Views)

@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.

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
0 Kudos
Message 5 of 9
(3,232 Views)

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 Yedinak
Certified LabVIEW Architect
LabVIEW Champion

"Does anyone know where the love of God goes when the waves turn the minutes to hours?"
Wreck of the Edmund Fitzgerald - Gordon Lightfoot
0 Kudos
Message 6 of 9
(3,212 Views)

@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...?

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
0 Kudos
Message 7 of 9
(3,198 Views)

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.

0 Kudos
Message 8 of 9
(3,178 Views)

You have checked that the plate name isn't somehow changing/becomes invalid?

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
0 Kudos
Message 9 of 9
(3,153 Views)