Jump to content

Notifiers not working, when use consecutive create notifier vis without delay


Recommended Posts

Hello,

 

I am trying to use notifier for synchronization within my code. My project requires sender program to send a command to multiple receiver programs. The sender program has to wait for response from all the receiver programs to proceed. I am using user event to send the command from sender program to the receiver programs. And receiver program has to set the notifier after it receives the command. Sender program will wait on notifier. 

 

If I don't have any delay between subseqent notifier create vis, my wait on notifier always results in timeout for some of the receiver programs. But when I include a small delay between subsequent create notifier vis, then wait on notifier receives all the notification without timeout.

 

For me it looks like a LabVIEW issue, but I wanted to hear from others, that is there anything wrong in the implementation?.

 

I have attached a small sample program for reference. Open up the sender program, configure no of receivers and run the program. Click the send and receive button to send user events and wait on notifiers.

 

Thanks in advance,

Nanda

Notifier Prototypes.zip

Link to post

Oh it took me a bit but I figured it out.  So in your Sender.vi, in your second for loop you are waiting on the notifier.  You are waiting on them one at a time.  And you know that the first one will not reply until one second, because the receiver has a wait 1000ms after getting the event, before setting the next one.  

 

So you wait for one second before ever looking at the second notifier.  But the second user event (and all of them) have already been generated at this point.  What this means, is you maybe waiting on the first notifier before moving on, but all the other notifiers are already being set.  It is a sorta race condition, where the race is because you set notifiers 1s after getting the user event, but you only wait on notifiers one at a time.  Maybe a dead lock would be a better name for this.

 

A easy solution would be to turn on for loop parallelism in the second for loop, and wire the size of the notifier array to the P terminal.  This way all notifiers will be waiting at the same time.

Link to post

Ignore previous boolean is set to false in the wait on notification vi. It is supposed to receive notification, even if the it is set in the past. How do we explain adding a wait in the first loop (while creating notifier) solves the issue?. Adding a delay of just 1 ms solves the problem. How do we explain that?


I tried enabling iteration parallelism. And wired the notifier array size to the P terminal. It didn't helped.

Link to post

Hi all,

 

Looks like using wait on notifications from multiple vi is the answer. I have been using wait on notification vi manually indexing the notification reference in the for loop. But wait on notifications from multiple vi is the correct vi to be used. Found another thread discussing the same issue.

 

http://lavag.org/topic/4028-notifier-signals-missed/

 

Thanks,

Nanda

Link to post

I looked through that thread and I wonder if there's a better implementation of the notifier behavior like using subscribers or something

drjdpowell: Here's how this affects messages. I defeated the reentrancy by wrapping your "wait for notification" in a nonreentrant subVI. If "data 1" executes first, all messages are delivered nicely. If data 2 fires first (as shown in the image below), you get a timeout (or a  deadlock if the timeout is -1)

OUfzM2H.png

5uIYL4q.png

 

You can make it so both messages are delivered by using the "Wait on notification with history" primitive in your "wait on notification" VI instead of the normal "wait on notification" primitive.

  • Like 1
Link to post

You can make it so both messages are delivered by using the "Wait on notification with history" primitive in your "wait on notification" VI instead of the normal "wait on notification" primitive.

 

Oh yeah, DUH, this is why the “Advanced Notifier Waiting†subpallet exists, isn’t it?  I’ve never used notifiers in such complex ways and so I forgot about it.  If one doesn’t need the many-readers ability of notifiers, one is better off sticking to queues.   The “Future Token†class, which is what I use to solve “wait for something to reply†problems like the OP’s, is a Write-Once, Destroy-on-Reading, single-element queue.

 

I shall add a "Wait on notification with history†method to my NotifierMessenger class in case people find uses for this.  Thanks.

Link to post

In my opinion the advanced behavior is the more intuitive way. It's not intuitive (as you saw with the original post) that the order of the senders should matter. We normally don't think about the receivers having an internal memory (we expect the primitives to be stateless except for the ones that enable statefullness). The other primitive (no history) maybe should be on the advanced pallet because it's for the power users that go faster.

Link to post

In my opinion the advanced behavior is the more intuitive way. It's not intuitive (as you saw with the original post) that the order of the senders should matter. We normally don't think about the receivers having an internal memory (we expect the primitives to be stateless except for the ones that enable statefullness). The other primitive (no history) maybe should be on the advanced pallet because it's for the power users that go faster.

 

It is more intuitive, quite true, but it also has the potential ability to consume memory until an app crashes, which is a possible argument for keeping it advanced.

 

Personally, I would advise against using Notifiers in complex ways like this regardless.

Link to post

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Similar Content

    • By Mads
      Attached is a sketch of a publish-subscribe solution inspired by the design of the native queue functions. Open the project and launch the Simple Demo.vi to get an idea of the concept (or create a few instances of the example templates and run those).   As you know there are *lots* of messaging solutions out there that also support many to many communication, many of which are much more advanced. They are often based on user events, and LVOOP. I have still been missing a solution that is as easy and intuitive to use as queues though.    I also wanted to overcome a few other issues with user events:
        - I do not like to always have to have an event case for each subscriber. - I want each subscriber to be able to preview or flush its incoming data stream...(not fully implemented yet, but logically simple to do) - and I want to be able to keep a channel open for as long as anyone is interested in using it,  not die when the process thathappened to create it goes idle(which is what happens with queues and user events...).   I am publishing this to get some feedback on the concept (as it is now it has lots of missing logic and the design is not thought that much through).    Do you find it useful or just silly?  Are there other solutions out there that are just as simple?    PS - The original attachment was LV2014, I have now added a 2012 version as well. MultiQ - a sketch of a many to many (pub-sub) messaging solution.zip
      MultiQ LV2012.zip
    • By JMak
      Hi All,
      I have been trying to come up with a way to make my program more efficient. I am trying to use less nested case structures, and to avoid calling sub VIs multiple times. I looked at some of the design patterns, and there was not a sole design pattern available that did what I wanted, so I have tried to combine 3 patterns into one.
      My application has a user interface controlling a camera, and each function is context sensitive. For example, if the camera is already acquiring images, the "change video mode" function needs to unconfigure acquisition before adjusting the settings. If the camera is not doing anything, the unconfigure step isn't necessary.
      My previous attempt used nested case structures to test the condition of all these criteria, and take the required action, so there were cases for every combination of states. I wanted the code to be more minimalist, and call functions (sub VIs) in a state machine in a different order, skipping certain cases, depending on the context. I wanted to combine the low CPU usage of the event structure with the queued message handler example, to take an array of states and process them one at a time.
      My first attempt is attached. I used notifiers because I don't want steps to be queued if the user presses multiple commands before completion. I want to only process the first command received after the current notifier changes are made. I couldn't think of a way to change between using the array from the notifier and using the modified array (minus the deleted element) in a shift register, so I used the send notification inside the slave loop to send the modified array of states. I want to know if there is a better, more efficient way of doing this, and whether there are any problems here.
      Thanks,
      James
      MasterSlave Events.vi
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.