The command parser waits for commands coming from the client, interprets them and routes the incoming command parameters to the appropriate loop. Figure 8 shows the example server command parser loop in greater detail.
Figure 8. Example server application Command Parser loop
The following paragraphs explain the command parser operation. Note that it’s operation is similar to the client Data Receiver loop.
1. Retrieve the RT FIFO references that are relevant to the command parser. To keep the code organized, it is a good idea to wrap RT FIFO initialization and clearing operations in subVIs. Since the application may use numerous RT FIFOs, it is convenient to bundle them as clusters so that each FIFO reference can be extracted as needed. In this particular example, the Command Parser Loop needs to communicate 2 types of information to the Time Critical loop (Stop and Frequency information), hence the need for 2 RT FIFOs.
2. Read incoming commands from the client. The STM Read Msg VI is part of the Simple TCP/IP Messaging API. An important feature of this VI is the timeout parameter. By default it is set to timeout every 25 seconds. This feature allows the loop to sleep until a new command needs processing. This is very efficient since the Command Parser loop will consume very little CPU time if there are no commands to process.
3. Retrieve the name of the incoming command. Refer to the Simple TCP/IP Messaging Protocol document for more details.
4. Convert the incoming data to the appropriate type. It is the developer's responsibility to know the expected data type for each command. The data can be of any type recognized by LabVIEW (integer, floating, complex, boolean, a cluster, an image, etc.).
5. Select the command handler. This is implemented as a case selector with a separate case for each command supported by the server. This design pattern is very scalable, because new commands are implemented by simply adding a new case. The example Command Parser has cases to handle the following commands: Set Frequency, Window and Stop.
6. Route incoming command data to the appropriate loop. When a command is received, the Command Parser must send the data either to the High Priority Task, Medium Priority Task(s) or both, as shown in Figure 8. To ensure determinism, follow the rules of a typical LabVIEW Real-Time application such as using RT FIFOs for sharing data between high and low priority loops. Communication with medium-priority tasks can be implemented via any other means of communication (deterministic and non-deterministic), including Local and Global Variables, Functional Global Variables, Queues, Notifiers, Occurrences, etc. In general, no other actions should be taken inside the Command Parser. Restricting this loop to data distribution makes the server application very responsive to client commands.