User events vs notifiers

Question

I’m trying to determine which methodology to employ – Queues and Notifiers or Event Structures (and User Events).  I’m hoping that if I describe my situation, someone will offer their wisdom.  Here’s what I intend to do.  Right now, most of this has yet to be written, so it’s really just a pile of clay waiting to be molded.  I do have the TCP/IP VI working (somewhat).
  Current Design:   I have a VI that allows a user to configure a UHF radio.  I used the State Diagram Toolkit for the initial design.  It has a tabbed front panel where the user can go to set frequencies, change power levels, run BIT, etc.  Each of those tabs has a least one button that allows the user to send the configuration (http message) to the radio over TCP/IP – right now it’s http, but it will ultimately have to be https.  I’m trying to use Stunnel to setup the secure link but that’s not quite working yet.  I have a “AcceptUserRequest” state that contains an event structure and handles the different user button presses.  I don’t (currently) use a queue to buffer the key presses, but I feel I should in the final product.  This VI is fairly stand alone right now, but as I’ll describe, it needs to change significantly given what I’d like to do.  I’ll refer to this VI as the RCTx in the next par.
  Future Requirements: Ultimately, we are gong to be running TestStand to control a production acceptance test procedure (ATP).  In that scenario, TS will call a number of VIs, each will perform some test on the radio.  As part of each test, the VI will need to configure test equipment to prepare it for measurements, and it will have to configure the radio.  Here is where I need the help.  I planned on kicking off (from TS) the RCTx in a separate thread.  It would open a TCP/IP connection with the radio, and (ultimately) open a secure https link.  Using the “Connection: Keep-Alive” parameter, I planned to keep the secure link open all the time and not close the connection, as you might normally do with TCP/IP after each tx/rx session.  I didn't want to have to go through all the handshaking every-single-time I wanted to talk to the radio.
  Anyway, using events or notifiers, I’d like each test VI to be able to tell the RCTx to send MsgX to the radio to get it ready for the test.  I would then take some measurement, tell TS pass/fail, move on to the next test.  In this mode, the RCTx front panel is hidden from the user, and simply receives messages from test VIs.  However, engineers would also like to use the RCTx standalone, without TestStand, to experiment with the radio.  In that case (like it is now), I would have to process key presses, etc.
 Given those requirements, what might be the best architecture to implement that will allow processing of keypresses in stand alone mode, and handling of messages in the TestStand mode?

Answer 1

I included the link to the LAVA discussion in my post above. There are a few code examples that were posted there that you could use as a starting point. The network queue conceptually isn't any different than a normal queue. The main difference is that it uses a TCP socket connection to actually pass the data. This is required if you are passing data between two different machines or two different applications on the same machine. In both cases a native LabVIEW queue would not work since the applications are not sharing an instance of the LabVIEW runtime engine. In the thread I posted the creation of the queue is smart enough to check and see if a native LabVIEW queue can be used. If it can it will use that. Otherwise it will use a native LabVIEW queue internally and layer than on top of a TCP connection for actually passing the data.
The fact that this is defined as a class or in terms of OO should not sway you from using it. It is a fairly self contained package and isn't much different from using any other subVI.
Mark Yedinak
"Does anyone know where the love of God goes when the waves turn the minutes to hours?"
Wreck of the Edmund Fitzgerald - Gordon Lightfoot