user events vs notifiers

[mrbean]

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?

[Mark_Yedinak]

I would build the RCTx application as a producer consumer architecture. The producer would have use an event structure which would meet your needs for the interactive method of running the application. All of your button presses would be caught by the event structure and it would in trun send the appropriate message to the consumer which would be a queued state machine. When running in the non-interactive mode the your TS sequences would use the queue to send messages to the RCTx application. It would use the same queue as your producer consumer. For ultimate flexibility I would use a network queue. See this discussion on LAVA for more details.

[mrbean]

I'm using one computer to run all the tests.  The target (UUT) is the radio.  With that being the case, I'm thinking I don't need network queues.  However, I'm thinking I need a couple different queues.  I plan to enqueue a string for button presses.  However, the messages that come from the test VIs will have to be some type of message cluster.  Wouldn't that mean two+queues?  How would that affect the producer/consumer loops that currently handle on queue and one data type?

[Mark_Yedinak]

You may still need the network queue even if you are running on the same machine. Depending on how you start things the TestStand and LabVIEW applications may use a different instance of the runtime engine. In that case you cannot share a native queue. This is the same as when you build two executables and run them at the same time on the same machine. They cannot share queues.

With respect to your data you can easily define your queue data as a typedefed cluster. The most flexible would message definition would contain a message ID (string or numeric) and a variant data field. Then depending on the type of message the variant data can be cast to a more specific data type. Using this approach individual messages could have different message data however the messaging scheme is generic. If you need to send data in both directions then you will need two queues. Each side would have their own queue they receive messages on.

[mrbean]

I found a thread that points to a LAVA discussion about Network Queue, but it uses lvoop.   I found a network queue class (in the 7.x Functions -> User Libraries -> Network Queue Class).  Is there a non-object-oriented implementation, or is the Class approach the only one.  I'm trying to understand what the differences are between the network and non-network queues, but it's still not clear.

[Mark_Yedinak]

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.

[mrbean]

I started with a small example just to experiment with events.  The RCTxSim.vi worked by itself, but it did not receive events from TS_Test_VI_Sim.vi.  I wasn't really confident that it would, but I thought I would try.  This (in general) is what I want to accomplish.  I guess this is where I now have to use network queues, eh?