Store 
| Products & Services | Industries | Academia | Support | User Community | Company |
 |
Download Product Updates | | |  |
Get Pricing | | | |
Trial Software |
| Documentation → xPC Target |
| Products & Services | Industries | Academia | Support | User Community | Company |
|
Download Product Updates | | | |
Get Pricing | | | |
Trial Software |
| Documentation → xPC Target |
| Contents | Index |
| Learn more about xPC Target |
If you encounter issues using the xPC Target I/O drivers,
Ensure that you have properly configured the driver.
Ensure that you are using the latest version of the software.
Test the hardware using the available diagnostic software included with the I/O board from the manufacturer.
Try a different target PC to verify the behavior.
Report the issue to The MathWorks Support at http://www.mathworks.com/support/contact_us/index.html.
From the host PC, you can view the target PC monitor with the MATLAB xpctargetspy command. For example
xpctargetspy('TargetPC1')The Real-Time xPC Target Spy window is displayed on the host PC monitor.
A CPU overload is not an error in the software. This condition indicates that the CPU was unable to complete processing a model time step before being asked to restart.
This error might occur if you have
Real CPU overloads — Those caused by model design and/or target PC resources in use. For example, a model is trying to do more than can be done in the allocated time on the target PC. Possible reasons are:
The target PC is too slow or the model sample is too small (see Dealing with Small Model Sample Times)
Model is too complex (algorithmic complexity)
I/O Latency, where each I/O channel used introduces latency into the system. This might cause the execution time to exceed the model time step.
Spurious CPU overloads — Commonly caused by factors outside of the model design. These overloads are most likely caused by one of the following:
BIOS settings (enabled Advanced Power Management, USB ports in the target PC BIOS, or Plug and Play (PnP) (see Target PC BIOS)
System management interrupts (SMIs)
If the model has too small a sample time, a CPU overload can occur. This error indicates that to run the target application, executing one step of the model requires more time than the sample time for the model (Fixed step size property) allows.
When this error occurs, the target object property CPUoverload changes from none to detected. To correct the issue, perform one of the following:
Change the model Fixed step size property to a larger value and rebuild the model. Use the Solver node in the Simulink model Configuration Parameters dialog.
Remember that I/O can add significant latency to your model.
You can use the xPC Target Interactive Guide
(http://www.mathworks.com/support/product/XP/productnews/interactive_guide/xPC_Target_Interactive_Guide.html)
to find latency numbers for boards supported by the block
library. For example, if your application includes the National Instruments® PCI-6713
board, and you want to use four outputs.
Look up the board in the xPC Target Interactive Guide.
From the table, the D/A latency is 1+2.4N.
To get the latency for four outputs, calculate the latency
1+(2.4 x 4) = 10.6 microseconds
Include this value in your sample time calculations.
Run the target application on a target PC with a faster processor.
Undesirable behavior can occur if any of the following BIOS settings are enabled:
Advanced Power Management — Can cause CPU overload.
USB ports — Can cause CPU overload.
Plug-and-Play (PnP) operating system — Prevents PCI devices from working properly.
System Management Interrupts (SMIs) — Can prevent successful operation of real-time software (cause CPU overloads).
Enabling any of these properties causes non-real-time behavior from the target PC. You must disable these BIOS properties for the target PC to run the target application properly in real time. See The xPC Target Software and the Target PC BIOS in the xPC Target Getting Started Guide.
To successfully operate real-time software on any microprocessor system, you must control and manage all interrupt services, including system management interrupts (SMIs). However, the operating system or the application software cannot detect these interrupts.
In addition, your BIOS might not be able to disable SMIs.
For some chipsets, when you cannot disable SMIs from the BIOS, you can programmatically prevent or disable SMIs. For example, see the Disabling SMIs on Intel ICH5 Chipsets document at MATLAB Central for a solution to disable SMIs in the Intel® ICH5 family.
Typically, the xPC Target kernel halts model execution when it encounters a CPU overload. You can direct the xPC Target environment to allow CPU overloads using the following options in the TLC options parameter in the Real-Time Workshop pane of the Simulink Configuration Parameters dialog box:
| Option | Description | Default |
|---|---|---|
| xPCMaxOverloads | Number of acceptable overloads. | 0 |
| xPCMaxOverloadLen | Number of contiguous acceptable overloads. If you do not specify this option, the default value is the same as xPCMaxOverlaods. Specify a value that is the same or less than the value for the xPCMaxOverloads option. You should not a use value greater than the xPCMaxOverloads value. | Same as value of xPCMaxOverloads |
| xPCStartupFlag | Number of executions of the model at startup, where the timer interrupt is temporarily disabled during model execution. After the model finishes the first xPCStartupFlag number of executions, the xPC Target software enables the timer interrupt, which will invoke the next execution for the model. | 1 |
When the xPC Target kernel runs the model, it checks the number of CPU overloads against the values of xPCMaxOverloads and xPCMaxOverloadLen. When the number of CPU overloads reaches the lower of these two values, the xPC Target kernel stops executing the model.
For example, if you enter a line like the following for the TLC options parameter:
-axPCMaxOverloads=30 -axPCOverLoadLen=2 -axPCStartupFlag=5
the xPC Target software ignores CPU overloads for the first five iterations through the model. After this, the xPC Target software allows up to 30 CPU overloads, preventing no more than two consecutive CPU overloads.
With the TLC options, you can use the following blocks in your model to help keep track of the number of CPU overloads.
Use the xPC Target Get Overload Counter and xPC Target Set Overload Counter blocks to set and keep track of CPU overload numbers.
Use the Pentium Time Stamp Counter block to profile your model.
Run xpcbench at the MATLAB command line. For example
xpcbench('this')This program accurately evaluates your system. The results indicate the smallest base sample time that an xPC Target application can achieve on your system. For more information on xpcbench, type help xpcbench at the MATLAB prompt or see
http://www.mathworks.com/support/product/XP/productnews/benchmarks.html
Set up the xPC Target environment with a different target PC. Compare the result with the original target PC.
Perform optimizations such as:
Optimize processing.
Reduce number of I/O channels.
Reduce data acquisition/logging.
Disable graphics.
Increase sample time.
Partition the model and run it on multiple target PCs. This optimization might require multitarget synchronization using CAN, UDP, parallel port, or reflective memory.
Use polling mode (if you do not need background tasks).
Use clear error messages to help you debug.
This topic describes how to obtain information about the PCI devices in your xPC Target system. This information is useful if you want to determine what PCI boards are installed in your xPC Target system, or if you have or want to use multiple boards of a particular type in your system. Before you start, determine what boards are installed in your xPC Target system. Use one of the following:
In the xPC Target Explorer, connect to the target PC in question and expand the PCI Devices node
In the MATLAB Command Window, type
getxpcpci('all')If you have or want to use multiple boards of a particular type in your system, ensure that the I/O drive supports multiple boards. Refer to one of the following:
xPC Target Interactive Hardware Selection Guide (http://www.mathworks.com/support/product/XP/productnews /interactive_guide/xPC_Target_Interactive_Guide.html)
If you confirm that the board type supports multiple boards, and these boards are installed in the xPC Target system, perform the following procedure to obtain the bus and slot information for these boards:
In the PCI devices display, note the contents of the Bus and Slot columns of the PCI devices in which you are interested.
Enter the bus and slot numbers as vectors into the PCI Slot parameter of the PCI device. For example
[1 9]
where 1 is the bus number and 9 is the slot number.
For additional information about PCI bus I/O devices, refer to the PCI Bus I/O Devices section of xPC Target I/O Reference.
The xPC Target kernel is tuned for minimal overhead and maximum performance. On the target PC, the kernel dedicates all of its resources to the target application. For some representative sample time numbers, run xpcbench at the MATLAB command line.
Actual obtainable sample times depend on a number of factors, including:
Processor performance
Model complexity
I/O block types
Number of I/O channels
You might notice that the sample time you request does not equal the actual sample time you measure from your model. This difference depends on your hardware. Your model sample time is as close to your requested time as the hardware allows.
However, hardware does not allow infinite precision in setting the spacing between the timer interrupts. This limitation can cause the divergent sample times.
For all PCs, the only timer that can generate interrupts is based on a 1.193 MHz clock. For the xPC Target system, the timer is set to a fixed number of ticks of this frequency between interrupts. If you request a sample time of 1/10000, or 100, microseconds, you do not get exactly 100 ticks. Instead, the xPC Target software calculates that number as
100 x 10-6 seconds X 1.193 x 106 ticks/seconds = 119.3 ticks
The xPC Target software rounds this number to the nearest whole number, 119 ticks. The actual sample time is then
119 ticks/(1.193 X 106 ticks/second) = 99.75 X 10-6 seconds (99.75 microseconds)
Compared to the requested original sample time of 100 microseconds, this value is 0.25% faster.
As an example of how you can use this value to derive the expected deviation for your hardware, assume the following:
Output board that generates a 50 Hz sine wave (expected signal)
Sample time of 1/10000
Measured signal of 50.145 Hz
The difference between the expected and measured signals is .145, which deviates from the expected signal value by 0.29% (0.145/50). Compared to the previously calculated value of 0.25%, there is a difference of 0.04% from the expected value.
If you want to further refine the measured deviation for your hardware, assume the following:
Output board that generates a 50 Hz sine wave (expected signal)
Sample time of 1/10200
Measured signal of 50.002 Hz
1/10200 seconds X 1.193 x 106 ticks/seconds = 116.96 ticks
Round this number to the nearest whole number of 117 ticks. The resulting frequency is then
(116.96 ticks/117)(50) = 49.983 Hz
The difference between the expected and measured signal is 0.019, which deviates from the expected signal value by 0.038% (0.019/50.002). The deviation when the sample time is 1/10000 is 0.04%.
Some amount of error is common for most PCs, and the margin of error varies from machine to machine.
Note Most high-level operating systems, like Microsoft Windows or Linux®, occasionally insert extra long intervals to compensate for errors in the timer. Be aware that the xPC Target software does not attempt to compensate for timer errors. This is because for this product, close repeatability is more important for most models than exact timing. However, some chips might have inherent designs that produce residual jitters that could affect your system. For example, some Pentium chips might produce residual jitters on the order of 0.5 microsecond from interrupt to interrupt. |
You might get this error if you are acquiring signal data with a scope of type file. This error occurs because the size of the signal data file exceeds the available space on the disk. The signal data will most likely be corrupted and irretrievable. You should delete the signal data file and reboot the xPC Target system. To prevent this occurrence, monitor the size of the signal data file as the scope acquires data.
Refer to The MathWorks Support xPC Target Web site (http://www.mathworks.com/support/product/XP) for additional information.
You might want to write your own driver if you want to include an unsupported device driver in your xPC Target system. See the xPC Target Device Drivers Guide for details.
Before you consider writing custom device drivers for the xPC Target system, you should possess
Good C programming skills
Knowledge of writing S-functions and compiling those functions as C-MEX functions
Knowledge of SimStruct, a MATLAB Simulink C language header file that defines the Simulink data structure and the SimStruct access macros. It encapsulates all the data relating to the model or S-function, including block parameters and outputs.
An excellent understanding of the I/O hardware. Because of the real-time nature of the xPC Target system, you must develop drivers with minimal latency. And since most drivers access the I/O hardware at the lowest possible level (register programming), you must have a good understanding of how to control the board with register information. Indirectly, this means that you must have access to the register-level programming manual for the device.
A good knowledge of port and memory I/O access over various buses. You need this information to access I/O hardware at the register level.
Yes. You can use either the xPC Target API dynamic link library (DLL) or the xPC Target component object model (COM) API library to create custom stand-alone applications to control a real-time application running on the target PC. To deploy these stand-alone applications, you must have the xPC Target Embedded Option license. Without this license, you can create and use the stand-alone application in your environment, but cannot deploy that application on another host PC that does not contain your licensed copy of the xPC Target software.
See the xPC Target API Guide for details.
You cannot directly tag signal outputs from virtual blocks. Instead, do the following:
Add a unity gain block (a Gain block with a gain of 1) to the model.
Connect the signal output of the virtual block to the input of the unity gain block.
If you change the step size of a target application after it has been built, it is possible that the target application will execute for fewer steps than you expect. The number of execution steps is
floor(stop time/step size)
When you compile code for a model, the Real-Time Workshop software calculates a number of steps based on the current step size and stop time. If the stop time is not an integral multiple of the step size, the Real-Time Workshop software also adjusts the stop time for that model based on the original stop time and step size. If you later change a step size for a target application, but do not recompile the code, the xPC Target software uses the new step size and the adjusted stop time. This might lead to fewer steps than you expect.
For example, if a model has a stop time of 2.4 and a step size of 1, the Real-Time Workshop software adjusts the stop time of the model to 2 at compilation. If you change the step size to .6 but do not recompile the code, the expected number of steps is 4, but the actual number of steps is 3. This is because the Real-Time Workshop software still uses the adjusted stop time of 2.
To avoid this problem, ensure that the original stop time (as specified in the model) is an integral multiple of the original step size.
If your target PC does not have a FAT hard disk, the monitor on the target PC displays the following error:
ERROR -4: drive not found No accessible disk found: file system disabled
If you do not want to access the target PC file system, you can ignore this message. If you want to access the target PC file system, add a FAT hard disk to the target PC system and reboot.
Note, ensure that the hard drive is not cable-selected and that the BIOS can detect it.
Yes, the target PC hard drive can contain multiple partitions. However, the xPC Target software supports file systems of type FAT-12, FAT-16, or FAT-32 only.
The getparamid and getsignalid functions accept block_name parameters. For these functions, enter for block_name the mangled name that the Real-Time Workshop software uses for code generation. You can determine the block_name as follows:
If you do not have special characters in your model, use the gcb function.
If the blocks of interest have special characters, retrieve the mangled name with tg.showsignals='on' or tg.showparam = 'on'.
For example, if carriage return '\n' is part of the block path, the mangled name returns with carriage returns replaced by spaces.
Encoder boards have a fixed size counter register of 16 bits, 24 bits, or 32 bits. Regardless of the size, the register always eventually overflows and rolls over. This can happen in either the positive or negative direction.
Some boards provide a hardware mechanism to account for overflows or rollovers. As a best practice, you should design your model to always deal with overflows or rollovers. An initial count can handle the issue for some applications.
To handle register rollovers, you can use standard Simulink blocks to design the following counter algorithm types:
Rollover Counter — Count the number of rollovers
Extended Counter — Provide an extended counter that is not limited by register size
The Incremental Encoder sublibrary of the xPC Target library contains example blocks for these two types of counters. See Rollover Counter and Extended Counter for further details. You can use these blocks in your model as is, or modified for your model. Connect the output of the encoder block to these blocks.
These counters perform the following. To view the algorithms used in these implementations, right-click the subsystem and select the Look Under Mask option.
A rollover counter counts the number of times the output of an encoder block has rolled over. It counts up for positive direction rollovers and down for negative direction rollovers.
An extended counter takes the output of an encoder block and provides a count that is not limited by register size. For an n-bit register, this counter should be able to count values greater than 2^(n-1).
Keep the following requirements in mind when using these sample blocks:
Some driver blocks allow an initial starting value to be loaded into the register. You must pass this value to the rollover blocks to adjust for that offset.
The rollover block needs to know how many counts each rollover represents. Typically, this number is 2^n, where n is the size of the register in bits.
The xPC Target software supports only static links. When you compile your models, ensure that you use only static links. When compiling with xPC Target S-functions, this is not an issue.
 | Installation, Configuration, and Build Troubleshooting | Getting Updated xPC Target Releases and Help |  |
Learn more about Simulink through this collection of videos, articles, technical literature and the Getting Started with Simulink Guide.
| © 1984-2009- The MathWorks, Inc. - Site Help - Patents - Trademarks - Privacy Policy - Preventing Piracy - RSS |
