MATLAB: Simulink Real-Time: Target gets disconnected after some time

My model runs perfectly on the target. I am using UDP port to send data from target to Simulink. After 500-600 seconds, my target gets disconnect from slrt-explorer. I also have a separate port on which I do the same operation using a Python script which is listening in parallel. Even though the connection breaks with Simulink, the connection remains intact with the Python script. There is no error on target. There is this message on Diagonostic Viewer after the connection gets disconnected:

Streaming to SDI is not available: Could not connect to XCP slave: XCP Master internal error: Busy(0) or no timeout(2) for 255

Important: The connection gets re-established after a few minutes i.e. the Target shows connected on SLRT explorer but the receiving of data does not resume.

How can I maintain the connection to the SLRT?

Best Answer

This usually happens when the model primarily consists of Simscape blocks and when it is executing close to the CPU overload limit, which leaves no room for the host-target communication background thread to execute. In such cases, host-target connectivity is temporarily lost but the model should continue running on the target. Try the following things:

Try enabling "Allow tasks to execute concurrently on target" in "Configuration Parameters" -> "Solver". Enabling concurrent execution allows the model to leverage the multiple CPU cores on the target, which in turn alleviates the computational burden.
Remove graphics or any mask-images from the model

Related Solutions

MATLAB: Does the xPC Target simulation crash intermittently in a host-target communication set up on xPC Target 5.0 (R2011a)

The EMFILE means an out of socket ports error. This error occurs if allocation of a port structure fails during a call to socket in host-target communication. If host target communication is significant in a model execution, EMLFILE error is expected.

There are several ways in to make the host communicate less frequently to the target. The following are enumerated below:

1. The best way is to use multicore kernel on a multicore target machine. Using a single core target is vulnerable to running into this state. The reason is that with multicore kernel the communication is not disrupted between host and target during a TCP/IP communication, therefore the host and target don't need to close and open another ports.

2. In the model, if there is a scope an output collected from the target, watching such a scope on the host via external mode generates a lot of host-target traffic. Use an xPC target scope, which displays the same result on the target screen.

3. Make the communication timeout much longer than the model stop time. This is because when a model is run under polling mode, it disables the interrupts to occupy the CPU, and then enables interrupts after the execution. When the interrupts are disabled during the execution, the target is unable to communicate with the host, host gets a communication error "TCP/IP timeout

while receiving data". Say, when we issue commands to modify the model parameters using XPCEXPLR, the host and target have to re-establish communication via different ports. This is why EMFILE error intermittently occurs.

You may accomplish this in the following way:

Say the stop time of the model is 5 seconds, first, set the communication timeOut to be 5, and host shows a timeout error right after the command

tg = xpctarget.xpc
tg.CommunicationTimeOut = 5;
tg.load('MySimpleMuscleModelNaDCET');
+tg;

The following error may occur:

 Error using start (line 22)
 TargetPC1: TCP/IP timeout while receiving data

Further, change the communication timeout to 50, host works fine.

xpctargetping;
tg.CommunicationTimeOut = 50;
+tg;

Output is:

tg.Connected
ans =
Yes

Another important thing to note is that, to issue the command XPCTARGETPING before sending commands to modify parameter. XPCTARGETPING can reconnect the target if the communication is lost.

MATLAB: How to choose a specific Ethernet adapter for host-target communication using xPC Target 4.3 (R2010a) when the target PC has multiple adapters of the same type

If your target PC has multiple Ethernet adapters of the same type, the kernel, upon booting, selects one of these adapters for host-target communication. Without manually testing, it is not possible to determine which physical Ethernet connector (port) is associated with the selected adapter.

Connect the host-target network cable to one of the Ethernet ports and issue the following command in the MATLAB Command Window:

xpctargetping

If the return status is "failed", move the network cable to a different Ethernet port on the target PC and retry. The above command will return "success" when you are connected to the port associated with the adapter in use for host-target communication.

You can manually select a different Ethernet adapter for host-target communication. The xPC Target kernel uses an indexing mechanism called "EthernetIndex" to identify adapters. Indexing starts at 0; hence, if you have two Ethernet adapters of the same type, one will be identified as EthernetIndex 0 and one as EthernetIndex 1. By default, the adapter identified as EthernetIndex 0 will be used for host-target communication. To switch adapters, issue the following command:

setxpcenv('EthernetIndex', '1');

You will need to recreate the kernel image and reboot for this to take effect.

If you want to change this selection for a target PC other than the default target PC (say, 'TargetPC2') , issue the following commands:

allTargets = xpctarget.targets;
myTargetEnv = allTargets.Item('TargetPC2');
set(myTargetEnv, 'EthernetIndex', '1');

If you have more than two Ethernet adapters of the same type, each will have a unique EthernetIndex (0, 1, 2, 3, …).

Note: If you are using the Network Boot method, it is possible that Ethernet adapter (A) used by the BIOS of the target PC to load and boot the xPC Target kernel is different from Ethernet adapter (B) chosen by the xPC Target kernel for host-target communication. For instance, consider this situation:

The xPC Target kernel loads and boots when the host-target network cable is attached to Ethernet adapter 'A'.
While booting, the xPC Target kernel selects Ethernet adapter 'B' for host-target communication.

After booting, you move the network cable from the port for adapter 'A' to the port for adapter 'B', you should now be able to communicate over the host target-link. However, communication will initially fail because the Windows OS on the host PC will have logged an entry in the Address Resolution Protocol (ARP) table associating the physical (MAC) address of adapter 'A' with the TCP/IP address selected for the target PC. To remove this association, confirm the host-target network cable is connected to the port for adapter 'B' and execute the following command in the MATLAB Command Window:

!arp –d

You should now be able to communicate with the target PC. To confirm, verify that "success" is returned when issuing the xpctargetping command. To circumvent this problem, use the method described above to force the xPC Target kernel to use adapter 'A' for host-target communication.

Best Answer

Related Solutions

MATLAB: Does the xPC Target simulation crash intermittently in a host-target communication set up on xPC Target 5.0 (R2011a)

MATLAB: How to choose a specific Ethernet adapter for host-target communication using xPC Target 4.3 (R2010a) when the target PC has multiple adapters of the same type

Related Question