Send data over TCP/IP to specified remote machine
Instrument Control Toolbox
The TCP/IP Send block sends data from your model to remote machines using the TCP/IP protocol. This data is sent at the end of the simulation or at fixed intervals during a simulation.
You need a license for both the Instrument Control Toolbox™ and Simulink® software to use this block.
In the Instrument Control Toolbox Block Library, the TCP/IP Receive block is now called the TCP/IP Client Receive block, and the TCP/IP Send block is now called the TCP/IP Client Send block. Note that the internal name has not been changed, so there is no compatibility issue if you have scripts or models with these block names. Both of the blocks are for use as TCP/IP clients. They do not work as TCP/IP servers.
The TCP/IP Send block has one input port. The size of the input port is dynamic, and is inherited from the driving block. This block has no output ports.
This block supports the use of Simulink Accelerator™ mode, but not Rapid Accelerator or code generation.
The block supports the use of model referencing, so that your model can include other Simulink models as modular components.
For more information on these features, see the Simulink documentation.
You can enter MATLAB variables in the text edit fields in the TCP/IP Send Block Parameters dialog box, except for this field: Remote address.
Specify the IP address, name, or the Web server address of the machine to which you need to send data. This field is empty by default.
Specify the remote port on the host you need to send the data
to. The default port value is
80. Valid port values
Click this button to:
Check if the specified remote address is correct.
Establish connection with the specified remote address and port.
When using binary or binblock format with more than 8 bits, you can
specify the instrument's byte order for the data. Your options are
Specify if you want to block the simulation while sending data. This option is selected by default. Clear this check box if you do not want the write operation to block the simulation.
The following diagrams show the difference between sending data using blocking mode and nonblocking mode.
In this example, you start the simulation at time (t=0). At time step (T1), data output is initiated and simulation stops until the block of data (B1) is sent to the specified remote address and port. After the data is sent, simulation resumes until time step (T2), where the block initiates another data output and simulation is blocked until the block of data (B2) is sent to the remote address and port, and the simulation resumes.
Nonblocking Mode – Scenario 1
In this scenario, the data output outpaces the simulation speed. Data output is initiated at the first time step (T1) and the corresponding block of data (B1) is sent to the specified remote address asynchronously. The simulation runs continuously in this mode.
Nonblocking Mode – Scenario 2
In this scenario, the simulation speed outpaces the data acquisition.
At time step T1: The block of data (B1) is sent to the specified remote address and port asynchronously.
At time step T2: The simulation is blocked until the block of data (B1) is sent completely. When B1 is completely sent, the new block of data (B2) is sent asynchronously, and the simulation resumes.
Several factors, including network connectivity and model complexity, can affect the simulation speed. This can cause both nonblocking scenarios to occur within the same simulation.
Specify the amount of time that the model will wait when data
is sent during each simulation time step. The default value is
This field is unavailable if you have not enabled blocking mode.
This option sets the
TransferDelay property and is
on by default. Clear the option if you do not want to use the feature.
When set to on, small segments of outstanding data are collected and
sent in a single packet when acknowledgment (ACK) arrives from the
TransferDelay is off, data is sent
immediately to the network.
If a network is slow, you can improve its performance by configuring
TransferDelay to on. However, on a fast network
acknowledgments arrive quickly and there is negligible difference
TransferDelay to on or