xPC Target    

Restrictions Introduced by the Polling Mode

As explained above, polling mode executes the Simulink-based target application in real time exclusively. While the target application is executing in polling mode, the background tasks, mainly the one for host-target communication and target screen updating, are inactive. This is because all interrupts of the target PC are fully disabled during the execution of the target application. On one hand this assures the highest polling performance; on the other hand, as a consequence the background tasks are not serviced.

Here is a list of all relevant restrictions of polling mode, which are otherwise available in the default interrupt mode.

Host-Target Communication Is Not Available During the Execution of the Target Application

If the target application execution is started in polling mode, say with

host-target communication is disabled throughout the entire run, or in other words until the stop time is reached. Each attempt to issue a command like

leads to a communication-related error message. Even the start(tg) command to start polling mode execution returns such an error message, because the host side does not receive the acknowledgment from the target before timing out. The error message when executing start(tg) is not avoidable. Subsequently, during the entire run, it is best not to issue any target-related commands on the host, in order to avoid displaying the same error message over and over again.

As a consequence, it is not possible to issue a stop(tg) command to stop the target application execution from the host side. The target application has to reach its set stop time in order that polling mode is exited. You can use

before starting the execution, but once started the application executes until the stop time is reached. Nevertheless, there is a way to stop the execution interactively before reaching the target application stop time. See Controlling the Target Application.

If the target application execution finally reaches the stop time and polling mode execution is stopped, host-target communication will begin functioning again. However, the host-target communication link might be in a bad state. If you still get communication error messages after polling mode execution stops, type the command

to reset the host-target communication link.

After the communication link is working again, type

in order to resync the target object on the host side with the most current status of the target application.

Target Screen Does Not Update During the Execution of the Target Application

As with the restriction mentioned above, the target screen updating is disabled during the entire execution of the target application. Using the kernel with the TargetScope option enabled (see xpcsetup-GUI) loses its entire functionality during a run, and it is therefore recommended that you use the kernel with the TargetScope property disabled (text output only). The text mode enabled kernel actually provides more information when running in polling mode.

Session Time Does Not Advance During the Execution of the Target Application

Because all interrupts are disabled during a run, the session time does not advance. The session time right before and after the run is therefore the same. This is a minor restriction and should not pose a problem.

The Only Rapid-Prototyping Feature Available Is Data Logging

Because host-target communication and target screen updating are disabled during the entire run, most of the common rapid-prototyping features of xPC Target are not available in polling mode. These are

The only rapid-prototyping feature available is signal logging, because the acquisition of signal data runs independently from the host, and logged data is retrieved only after the execution is stopped. Nevertheless, being able to log data allows gathering good enough information about the behavior of the target application. Signal logging becomes a very important feature in polling mode.

Multirate Simulink Models Cannot Be Executed in Multitasking Mode on the Target PC

Because of the polling mode execution scheme, executing Simulink-based target applications in multitasking mode is not possible. The modeling of function-call subsystems to handle asynchronous events (interrupts) is not possible either. This can be a hard restriction, especially for multirate systems. Multirate systems can be executed in single-tasking mode, but because of its sequential execution scheme for all subsystems with different rates, the CPU will most likely overload for the given base sample time. As an important consequence, polling mode is only a feasible alternative to the interrupt mode if the model has a single rate or if it can be converted to a single-rate model. A single-rate model implies continuous states only, discrete states only, or mixed continuous and discrete states, if the continuous and discrete subsystems have the same rate. Use the Format -> Sample time color feature of Simulink to check for the single rate requirement. Additionally, set the Mode property in the Simulation parameters / Solver dialog box to SingleTasking to avoid a possible switch to multitasking mode. For more information on single-tasking mode compared to multitasking mode, see the Real-Time Workshop User's Guide.

I/O Drivers Using Kernel Timing Information Cannot Be Used Within a Model

Some xPC Target drivers use timing information exported from the kernel in order to run properly, for example, for the detection of time-outs. Because the standard timing engine of the real-time kernel is not running during the entire target application execution in polling mode, timing information passed back to the drivers is incorrect. Drivers importing the header file time_xpcimport.h can therefore not be used. This is a current restriction only. In a future version of polling mode, all drivers will make use of the Pentium counter for getting timing information instead.


  Setting the Polling Mode Controlling the Target Application