Acquiring groups

RT-LAB enables signal acquisition from the real-time target nodes in the cluster. Because TCP/IP is relatively slow compared with most real-time systems, RT-LAB enables you to set different groups of acquisition. Each group can include many signals, including the number of signals per frame to receive, decimation factor, etc. These parameters can be defined separately for each signal.

For example, in a system with a 1-millisecond step, a user might want to acquire the data values of a slowly changing signal once every 100 steps or so. Signals can also be acquired only once specific conditions have been met, by defining the conditions’ parameters in a Trigger block, as described below.

Signals received on the Console (SC_) subsystem are grouped into twenty-four groups. The acquisition group for a signal is specified in the OpComm communication block through which the signal passes.

Acquisition Parameters

Acquisition parameters are shared by all signals included in a given acquisition group. These parameters are specified by you in the Probe Control Panel, on the tabs numbered with the appropriate acquisition group number.

Use Tools > Probe Control or click the Probe Control Icon to open this panel.

Triggering Acquisition

By default, each acquisition group is always triggered, meaning that a new data packet is filled as soon as the previous packet is sent. Sometimes, however, you may want to receive data only when a certain condition occurs.

For this reason, the OpTrigger block can be inserted into the subsystem containing the acquisition group signals. The OpTrigger block is used to acquire data triggered by a specific signal, enabling you to acquire information from a specified part of the simulation only. 

Recording Data with OpWriteFile

To obtain data for any particular signal, use the OpWriteFile block. Data recorded with this block is stored on the target real-time node’s hard drive. The data file is automatically transferred to the command station when the model is reset.

Sometimes, in simulations with fast sampling times, the acquisition data loss on the command station is too significant to clearly understand what is happening in the real-time model. The Simulink library ToFile block cannot be used in real-time simulations because it does not have a buffering system.

Using this block in a real-time context without a buffer would significantly increase the real-time simulation’s effective step size.

A real-time write-to-file block (OpWriteFile) can be inserted into the computation subsystem. This block enables data in MATFILE format to be saved to the real-time node’s hard disk. The generated MATFILE (.mat file) can be transferred to the command station and analyzed using MATLAB. The write to file does not affect the simulation step size in synchronized mode, because all writing is done during the simulation’s spare time. The OpWriteFile block uses a circular buffer architecture that enables continuous data acquisition. If the circular buffer is full, it will be emptied completely before starting again. For simulations with small step size, a large buffer size is recommended to avoid discontinuous data in the write-to file.

The Simulink block has one input: the signals to be saved. You can save multiple signals by using a vector as the block input. Each OpWriteFile block must be associated with an acquisition group number.

Moreover, because the write-to-file block is considered an extra acquisition group, an OpTrigger block is used to write data when certain conditions occurs.

Understanding Data Reception

Communication Between the Console and the Target Nodes

The Console is connected to each computation node by an Ethernet network. Because this type of network is much slower than a real-time PCIe-type network and because a command station is very resource-demanding, the command station may probably not be able to receive and display all of the data, so there is a need to be selective with respect to incoming data.

Often, data is read-only every 2, 3, or even 5 calculation steps: this lightens the load imposed on the Console. To accelerate the transmission process, target nodes send batches of data to the network rather than sending one batch per data item.

The target node contains a buffer where it gathers data from many signals for transmission to the Console. The target node dispatches its data only when this buffer reaches the level specified in the Probe Control panel.

A frame is composed of all of the data that represents a specific signal inside the buffer. For example, if you have three signals and want the data transmitted at every 5000th value, the buffer contains 15,000 samples or three frames of 5000 values each. Because the command station takes a certain amount of time to receive and display the acquired values and because the real-time model is calculated in continuous mode, it is possible that the next data frame received may not immediately follow the currently displayed frame; in other words, there may be holes in the data display.

The following figures illustrate this point:

As the time required to display Frame 1 is longer than the frame itself, the portion of the calculation performed between dispatching the two frames is lost, creating a discontinuity in the display:

It is possible to minimize this effect. For a number of values per given signal, an increase in the decimation factor (from one acquisition per step to one acquisition for every two steps) also increases the effective length of the frame, diminishing the gap in values between the two data transmissions:

Although the display is more representative of the real-time calculation performed, an increase in the decimation factor can cause problems with display resolution, as shown here:

In RT-LAB, even if the command station crashes, a real-time model running on the target nodes continues to run. After rebooting the command station, reconnect to the real-time model and continue data acquisition.

Synchronous Acquisition

Remember, acquisition frames are sent when the system has time; frames sent as TCP/IP packets are sent while the model is waiting for a communication packet or for the synchronization pulse. This results in your real-time system not being disturbed by a TCP/IP transmission.

Therefore, the console display may miss some data if the command station is too slow or if the target node does not have enough time left. This technique helps ensure hard-real-time performance.

Aliasing is another acquisition issue that arises with the use of small frames. As described previously, the next data frame received may not immediately follow the frame currently displayed. Consequently, in the case of small frames (like one value per frame) the possibility of losing some values results in incorrect data display.

To illustrate this concept, let's assume that we have a sine signal as shown here:

If, for example, data is acquired once every n steps because acquisition cannot follow the real-time simulation, the display shows values without updating the time axis, which results in aliasing: the frequency of the resulting signal is increased by a factor of n.

The data reception problem occurs because the Console isn't aware that data from the target node is being missed. To circumvent this problem, it is possible to synchronize the Console time with the simulation time to avoid data loss and data reception errors.
During acquisition, the console subsystem acquires signals from the simulation platform, enabling you to view data (Scope, To Workspace-type blocks, etc.). There are three options to choose from with the OpComm block mask.

OpComm Block Mask Options

Button/Field	Function
Enable synchronization	Enables the synchronization algorithm for a given acquisition group. This algorithm must be used if synchronization is required between acquisition Console time and Simulation time. In case of a synchronization problem, the Console detects missing data from the target node and the algorithm either replaces the lost data with the last signal value received or interpolates the data.
Enable interpolation	In case of missed data from a computation subsystem, the synchronization algorithm interpolates data during a range of data loss.  The following illustrations make this point clear. The display to the left indicates no interpolation during data acquisition while the display to the right indicates interpolation between two frames during data loss.
Threshold	Difference between the simulation Console time and the simulation target time. Whenever this difference is exceeded, the synchronization algorithm stops interpolating and re-synchronizes to the new value.