Master/Slave with Events

[crossrulz]

---

@jfalesi wrote:

Another question - is there an advantage to using an Event structure instead of a Case structure inside the consumer loop?

---

Only if you are using User Events to send your data to the consumer.  If you are using a queue, then case structure.

[jfalesi]

I guess that's what I'm wondering - should I use a queue and case structure or events and event structure?  Are there situatuions in which one would be more appropriate than the other?

[crossrulz]

Unless you have a need to send the same message to multiple loops, events are a little more difficult.  I would just stick with the queue.

[jfalesi]

Cool, thanks.

[jfalesi]

I have a follow-up question.  I have decided on three loops:

1) Producer loop to handle user events

2) Consumer loop to kick off a parallel "Read Buffer" loop, which needs to execute continuously until stopped by user

3) A display-update loop that is actually a slave to the "Read Buffer" loop, and is executed when "Read Buffer" detects that a value has changed from the device buffer

I decided to use notifications since all the communication is 1-to-1 except "Quit", which is 1-to-N.

I created a template vi with just the control structure so I could confirm it behaves as I expect.  Of course, it doesn't.

The first thing I realized is that every time I want to send an "execute something" notification I also have to send a "don't quit" notification.  This makes me wonder if I'm using notifications properly.

The next thing I realized is that I can't seem to quit gracefully.  First I tried putting a "Wait on Quit Notification" inside the continuous "Read Buffer" loop, (loop #2) but that doesn't work unless I'm continuously sending notifications to not quit, which defeats the purpose of spawning a parallel loop.  Putting a "Wait on Quit Notification" outside the continuous "Read Buffer" loop and wiring it into the stop sign in the loop doesn't work.  Can't figure out how to get into the loop to stop it...  This also makes me think I'm using the wrong communication paradigm.  I'd use a queue, but the consumer loop is only going to ever need to respond to two events - "start" and "stop".  Seems hardly worth creating a queue.  I don't think I can get inside the Read Buffer loop with an event... what am I missing here?

I've attached the template vi and the Display Data class I'm using to hold the data for updating the GUI (not sure if this is a good way to do it, but seemed like a good idea at the time)

Thanks,

-Jamie 

[VItan]

Could you resave it for LV 2013 and reattach?  I cannot take a look at your VI since it was saved using 2014.

[crossrulz]

1. I would use a User Event to send the GUI updates to the Master Loop.  That eliminates a loop and keeps all of the GUI in a single loop.

2. I do not think you want to use Notifiers here.  Remember that Notifiers only keep the last message.  So you can miss commands if your loop gets slowed down for whatever reason.  You likely want to use a Queue instead.

3. Two Notifiers is annoying to deal with, as you have already noticed.  Instead, use a queue with the data type of a string.  Then in your consumer loop (read buffer loop), you use a case structure with the command string going to the case selector.  This will eliminate the need for two message references since you can send the Stop and the Read commands using the same queue.

4. You should not have a while loop inside of another loop.  I'm looking at your read buffer loop here.  Intead, put the reading inside of the Default case of the command case structure I mentioned in 3.  You can set the timeout of the queue to be 0 to instantly timeout and read the buffer.  Set the queue's timeout to -1 when not reading in order to sit there and wait for a command.  You need to do this so that you can monitor the message queue.  I typically keep the timeout in a shift register, making it easy for any of the commands to set it.

[jfalesi]

Thanks Crossrulz, I'll mock up a template as you describe.

Vltan, here's a 2k13 version for you.

Thanks,

-Jamie