Basic Communications :: QUARC Communications

navigation bar

Table of Contents > QUARC > User's Guide > Communications

Basic Communications

Basic communications can be accomplished using the Basic communications blockset provided by QUARC. This blockset can be found under the QUARC Targets/Communications/Basic library in the Simulink Library Browser. It consists of two blocks; Stream Client and Stream Server. The Stream Client block acts as the client in the communication process. It connects to a local or remote host and sends and/or receives data from that host. The Stream Server block acts as the server in the communication process. It listens for and accepts a connection from a local or remote host and sends and/or receives data from that host. These two blocks are high-level blocks and do not require a sophisticated knowledge of communications to be used. This section does not deal with the details of these blocks but provides an overview of how to use them to communicate between two different models. Therefore, it is highly recommended that the user refer to the Stream Client and Stream Server blocks' reference pages before continuing.

Two example models are used in this section to demonstrate how to use the aforementioned blocks for basic communications. Please refer to the QUARC Basic Communications Demo reference page in the MATLAB Demo section to open these models.

The first model is called "quarc_basic_client". It is the client model and is depicted in the figure below.

The Stream Client block, as mentioned earlier, can connect to a local or remote host and send to and/or receive data from that host. In our example, we have used the TCP/IP protocol with tcpip://localhost:18000 as the URI of the host to which to connect. This URI will later be used by the server model to listen for and accept connections. The data being sent to the server side is a sine wave. A constant value of 1 is being fed into the "en" input port to enable the sending of data to the server side. The block's output ports are all connected to Scope blocks for monitoring purposes. The important output port to monitor is rcv, which is the data received from the server side. For details about the other output ports', please refer to the Stream Client block's reference page.

The second model is called "quarc_basic_server". It is the server model and is depicted in the figure below.

The Stream Server block, as mentioned earlier, can listen for and accept a connection from a local or remote host and send to and/or receive data from that host. In our example, we listen for and accept connections using the same URI used by the Stream Client block in the "quarc_basic_client" model, tcpip://localhost:18000. The data being sent to the client side is a sawtooth wave generated by the Signal Generator block. A constant value of 1 is being fed into the en input port to enable data to be sent to the client. The block's output ports are connected to Scope blocks for monitoring purposes. The important output port to monitor is rcv, which is the data received from the client. For details about the other output ports, please refer to the Stream Server block's reference page.

Now if you build and run the models, you will be able to view a sine wave on the "Received Data" scope of the server model and a sawtooth wave on the "Received Data" scope of the client model. These two scopes are illustrated below respectively.

The fact that the scopes trace the desired signals verifies that the connection was indeed established and the two models are communicating with each other. There are important facts to mention here. First, these two blocks establish a "persistent" connection. If the connection is lost then these blocks attempt to re-establish the connection. For example, if you stop the client model while the server model is still running, you will notice that the "Received Data" scope of the server model becomes flat, meaning there is no new data being received. If you restart the client model, then the scope starts tracing the received data once again. Reconnecting to the client is possible because the server detected that the connection was lost and returned to waiting to accept a connection. This situation is depicted below.

The flat line section on the scope corresponds to the time span for which the client was shut down. Likewise, if the server model is stopped, then the client model automatically reconnects when the server is restarted; the connection is persistent.

The Basic communications blocks are always non-blocking. They do not wait for data to be sent or to be received. However, the signals sent or received are always treated as atomic units - the blocks will never receive part of the data or send part of the data. Even though these blocks are non-blocking, they may be configured to use non-blocking I/O for the underlying stream or to use blocking I/O in separate threads internally. In either case, the blocks themselves never wait for data to be sent or received (since they are non-blocking) and thus do not interfere with the sampling rate of the model when used in the main diagram.

While the Basic communications blocks are very simple to use, they do not have the flexibility of the other communications blocks. For example, you can only send and receive one signal (although it may be a vector) using these blocks. If you need to send or receive a set of data that cannot be packaged in a single vector, or if the amount of data sent or received varies, it is better to use the Intermediate communications blocks. This lack of flexibility is one of the disadvantages of using the Basic communications blocks. However, if you are just trying to establish a connection between two models and are willing to sacrifice flexibility for simplicity, these blocks are more than adequate for reliable communications.

navigation bar