CANalyzer User Guide V3 - 1 PDF
CANalyzer User Guide V3 - 1 PDF
CANalyzer User Guide V3 - 1 PDF
Distributors:
France Germany
Italy Korea
Netherlands Sweden
Micro-key Kvaser AB
Industrieweg 28 P.O. Box 4076
NL-9804 Noordhorn 51104 Kinnahult
Tel.: +31 594 50-3020 Tel.: +46 32 0-15287
Fax: +31 594 50-5825 Fax: +46 32 0-15284
http://www.microkey.nl http://www.kvaser.se
Copy Protection
The software is not copy protected. The licensee is entitled to make a (single)
backup copy. The licensee is obligated to note the copyright of Vector Informatik
GmbH on this copy. It is expressly prohibited to make additional copies and/or trans-
fer the software to third parties. The conditions of the Vector licensing agreement
must be observed.
The supplied software is provided with a serial number and a text entry identifying
the licensee. Both entries are displayed briefly when the program is started. They
can also be called up by the menu command Help-Info. The licensee must take ap-
propriate precautions to ensure that no unlicensed copies can be made from his ver-
sion. If it becomes known to the licensee that a copy of his version is being used by a
third party, he is obligated to immediately stop this use or inform Vector of such use.
Otherwise, the licensee is liable to Vector for consequential damages.
Typographic Conventions
Text formatting Meaning Example
Italics Menu, command and dialog File|Associate database
box names
Bold Examples of CAPL syntax on message 0x100 {...}
In angle brackets Key names <TAB>
Upper-case File names CAN.INI
Fixed-width font CAPL syntax description "DLC" "=" <integer>
Overview
Chapter 1, Introduction introduces CANalyzer and takes beginners on a short tour
that provides an overview of the most important functions.
Chapter 2, Working with CANalyzer explains the concept of the measurement
setup and explains basic CANalyzer functions for transmitting and analyzing data.
Chapter 3, CAPL Programming discusses the CAPL programming language, with
which you can supplement and expand basic CANalyzer functions in a nearly un-
limited manner. The application possibilities of this programming language are
clarified by means of numerous examples.
Chapter 4, Special Topics gives you more in-depth information for a better under-
standing of CANalyzer functionality and offers you additional tips and tricks for us-
ing CANalyzer in special situations.
Chapter 5, Appendix you will find instructions on how to troubleshoot errors.
Legend:
✔ Available
— Not available
1,2 One / two of these available
n Several of these available
Contents
1 Introduction........................................................................................................ 1-1
3.4 Browser for Creating and Compiling CAPL Programs ...................................... 3-19
3.4.1 Opening Browser............................................................................................. 3-20
3.4.2 Browser Window ............................................................................................. 3-21
3.4.3 Compiling CAPL Programs.............................................................................. 3-21
3.4.4 Searching for Run-Time Errors........................................................................ 3-21
3.4.5 Access to the Database .................................................................................. 3-22
3.4.6 Importing and Exporting ASCII Files................................................................ 3-22
3.4.7 Browser Options.............................................................................................. 3-23
1 Introduction
1.1 Overview
CANalyzer is a universal development tool for CAN bus systems, which can assist in
observing, analyzing and supplementing data traffic on the bus line. Based on its
powerful functions and user-programmability, all needs are covered - from initial trial
runs with CAN to selective error localization in complex problems.
You can choose to work with CANalyzer on the byte level with bus-like raw data for-
mat, or on the application level with logical/physical data representation. A CAN da-
tabase is used to convert raw data. This database has become a de facto standard
in the motor vehicle industry. The user-friendly database management program
CANdb++ is included with CANalyzer.
Even the basic built-in functions - which can be used without any programming
knowledge - provide for an abundance of possible applications. These include listing
bus data traffic (Tracing), displaying data segments of specific messages, transmit-
ting predefined messages and replaying recorded messages, statistically evaluating
messages, and acquiring statistics on bus loading and bus disturbances, as well as
recording messages for replay or offline evaluation.
Furthermore, the user can expand CANalyzer's functionality as desired by means of
user-programming. Program blocks can be inserted at any point in the data flow dia-
gram. The application-oriented, C-like language CAPL (CAN Access Programming
Language) serves as the programming language. A special event procedure concept
and CAN-adapted language tools enable the user to develop quick solutions to spe-
cific problems. CANalyzer contains an interactive development environment that
makes it easy to create, modify and compile CAPL programs.
Programmability results in numerous potential applications:
CANalyzer is controlled and configured from the data flow diagram in the measure-
ment setup window. For further information on this please refer to section 2.1.4.
© Vector Informatik GmbH CANalyzer User Guide Version: 3.1
1-3
1.2.1 Preparations
To start CANalyzer, call CANW32.EXE by double clicking the appropriate icon in the
CANalyzer program group.
CANalyzer has various evaluation windows (Trace, Data, Graphics, Statistics and
Bus Statistics windows) as well as a measurement setup window that shows you the
data flow in CANalyzer and simultaneously allows you to configure CANalyzer.
You can access all program windows from the View menu on the main menu bar.
The data flow diagram of the CANalyzer measurement setup contains the data
source on the left - symbolized by the symbol of a PC-card - and various evaluation
blocks on the right serving as data sinks.That is, the data flow is from right to left.
Connection lines and branches are drawn between the individual elements to clarify
the data flow.
The information arriving at each evaluation block are displayed in the block's evalua-
tion window. For example, the Trace window displays all information arriving at the
trace block, while the Graphics window shows you information arriving at the graph-
ics block.
The only exception is the logging block, which is not assigned a window but rather a
file in which the data arriving at the block are logged.
On the left side of the measurement setup, CANalyzer's transmit branch branches off
after the card icon. Data can be sent onto the bus from here. The data flow in the
transmit branch always runs from top to bottom.
In the data flow diagram you will also recognize small black rectangles: . At these
insertion points (Hotspots) you can insert additional function blocks for manipulating
the data flow (Filter, replay and generator blocks, or CAPL program blocks with user-
definable functions).
Make sure that you begin this tour with a new configuration by selecting the menu
item File|New configuration.
CAN bus
cable PC-Board
Consequently, the CAN bus that you use during this tour will consist of a short 2-
conductor or 3-conductor cable that connects the two CAN controllers of the CAN
card to one another. This is necessary as a minimal configuration, since the CAN
protocol requires - in addition to a sender - at least one receiver that confirms the
correct receipt of messages with an acknowledge.
Up to this point we have not considered definitions of bus parameters (Transmission
speed, sampling point, etc.) which must be set for each of the two participating con-
trollers. To do this, from the View menu bring the measurement setup to the fore-
ground and click the right mouse button on the PC-card icon at the left of this win-
dow.
In the popup menu you initially select bus parameters for the first controller CAN 1
and first set the baud rate in the configuration dialog. The Baud rate selection button
takes you to the baud rate direct selection dialog, where you enter the value 100
kBaud.
This makes sense for both high-speed and low-speed buses. The CANalyzer rec-
ommends default values for the controller registers. When you do this - besides the
transmission speed of 100 kBaud - you also implicitly define other controller parame-
ters (Sampling point, BTL cycles, and synchronization jump width). For the overall
system to function properly, the same exact values must be assumed for the second
controller CAN2. Accep the parameters with OK.
Afterwards, this appears as a rectangular block with the label G. You can then con-
figure this block from its popup menu, which you access by pressing the right mouse
button.
Afterwards, this appears as a rectangular block that is connected to the simulated
bus (red line). You can then configure this block from its popup menu, which you ac-
cess by pressing the right mouse button.
First, fill out the transmit list. You enter 64 as the identifier. (Check to see whether
the numbering format is set to Hex using the Options button .) Then enter the value 4
in the DLC box as the data length entry. Finally, set the values of the data bytes in
the four data boxes that follow by entering the values D8, D6, 37 and 0 there.
Exit the transmit list with OK to accept the values in the configuration. In the genera-
tor block's popup menu, you must now still configure triggering for the transmit ac-
tion. On the second line check the box With Period and then enter the value 100 in
the input box to the right of this.
Start the measurement by pressing the start button on the toolbar. CANalyzer
immediately begins to cyclically transmit the message you have configured in the
generator block. You can recognize this in the Trace window, which automatically
jumps to the foreground after the start of measurement and can now be seen at the
lower right of the main program window: In the first line you see the message that is
sent by the generator block, whereby the first column shows the transmit time rela-
tive to the measurement start.
The next column shows you which of the two CAN controllers was used to transmit.
This value (CAN 1) agrees with the default value assigned in the generator block's
transmit list of messages to be transmitted.
Afterwards, this message is also received by the second CAN controller over the
bus. The question arises: Why is this not also displayed in the Trace window? You
will find the answer in the configuration dialog for the acceptance filter for the second
controller. In turn, you can open this dialog from the PC-card icon's popup menu un-
der the entry CAN Bus parameters/CAN2/Acceptance.
The acceptance filter options support hardware-side filtering of messages. The de-
fault options block most message receiving. You can open the filter by entering the
value X in the upper line. After a new measurement start you can now also see that
the message transmitted via channel 1 (Transmit attribute Tx [= Transmit] in the
Trace window) was received by the second controller (Receive attribute Rx [= Re-
ceive] in the Trace window).
We will now expand the task and additionally transmit a message with modified data:
Exercise 2: Expand the configuration of the last task such that, additionally, a mes-
sage with identifier 3FC (hex) is transmitted every 200 milliseconds. The value of the
first data byte of this message should cyclically assume values from 1 to 5.
You can solve this task by inserting another generator block in the transmit branch.
For this task it does not matter whether you insert this generator block before or after
the first one. Select 200 ms as the value for cyclic triggering. The transmit list should
appear as shown below:
Do not forget to stop the measurement before you reconfigure the measurement
setup. During a running measurement it is not possible to make changes to the con-
figuration of the data flow. The menu items of the relevant popup menus appear in
gray shading.
Besides the generator block, CANalyzer also offers two additional block types as
data sources. With a replay block you can play back data on the bus that were
logged with CANalyzer's logging function. A program block allows you to integrate
your own transmit functionalities - which may be quite complex - into CANalyzer with
the CAPL programming language (cf. chapter 3).
With you can toggle between absolute and relative time representation. In rela-
tive time representation, the time difference between two successive messages
("transmit interval") is shown in the first column. Of course, in this display format it is
also easy to find the transmit interval that you entered previously in the generator
block: 100 milliseconds.
The Statistics window also offers you bus-related information. Here you can observe
the transmit frequencies for messages, coded by identifiers. If you have configured
the transmit branch as in the two last tasks, then you should see two vertical lines in
the Statistics window after the measurement start, which show the transmit frequen-
cies of the two generated messages 64 (hex) and 3FC (hex).
10 messages per second were recorded for identifier 64, and half as many were re-
corded for identifier 3FC. This result corresponds to the cyclic periods of 100 and
200 milliseconds set in the generator blocks.
If the Graphics window display is too imprecise, the statistics block offers you a sta-
tistical report that gives you more precise information on the transmit interval for
each mesage. Stop the measurement and activate the statistical report in the popup
menu of the Statistics block (Statistic report... Activate).
Double click the Messages object type in the area on the left side of the Overall View
window. The subordinate structural level is then shown in this area. In the area on
the right the available messages are shown with their system parameters (e.g. sym-
bolic name, identifier, etc.). First, toggle the numbering format from decimal to hexa-
decimal in the Options|Settings menu item. We can deduce from the symbolic
names of the messages that the system under consideration involves a description
of communications in a rudimentary engine area system.
Click the message EngineData in the left area of the overall view window. The sys-
tem parameters of signals transmitted in this message are shown in the area on the
right side of the Overall View window.
The temperature EngTemp for example is a 7 bit signal. To obtain the physical value
in degrees Celsius, the bit value must be multiplied by the factor 2, and the offset 50
must be subtracted from the result. The idle switch signal Idle Running in the last bit
of the third data byte is a binary signal (one bit), which can assume the value 0 or 1.
With the help of this symbolic information the data contents of messages can now be
interpreted in CANalyzer. Please note that this only makes sense if the database
information describes the system that you are currently observing. Of course, you
can also associate a different database to CANalyzer. The observed CAN data traffic
is then interpreted according to the information in that database, even if it does not
make any sense. You yourself are responsible for ensuring that the database asso-
ciated to the configuration matches the real CAN network.
Messages that you generate in the two generator blocks can be interpreted with the
database MOTBUS.DBC. Please note that the message you generated in the first task
has the identifier 64 (hex). This agrees with the identifier of the message EngineData
that we just examined in the database editor. If you now start the measurement, you
can toggle the program to symbolic mode by activating the button.
In the Trace window you will now see the symbolic message name in addition to the
identifier.
Afterwards, select and accept all signals of this message from the dialog list on the
right.
When you close the Data window's configuration dialog you will see that the signal
names are now entered in the window. After the measurement start the generator
block begins to cyclically send the message EngineData with data bytes D8, D6, 37
and 0 onto the bus. According to the message description in the database, the data
block in the measurement setup now interprets these byte values as engine speed,
temperature and idle switch and displays the appropriate signal values in the Data
window in physical units.
With the help of the conversion formula in the database, engine speed is shown in
RPM, while temperature is shown in degrees Celsius. The values of all three signals
remain constant over time, since the message is constantly transmitted with the
same data bytes D8, D6, 37 and 0.
This corresponds to the five values that you entered in the generator block as part of
task 2. The values remain in the Graphics window after the end of the measurement.
The measurement functions that the window provides for post-analysis are described
in section 2.5.3.5.
now enter the signal values directly. It will also be apparent to you, once again, that
the byte values D8, D6, 37 and 0 from the first line correspond to the signal values
EngSpeed = 5500 rpm, EngTemp = 60 degrees Celsius and IdleRunnning = 0.
If you now set - for example - the value of EngSpeed to 1000 rpm, the generator
block automatically uses the database information to compute the corresponding
data bytes (10, 27, 37 and 0).
cle speed and engine speed vary between two values. The ratio of the two signal
values is determined by the selected gear.
You will find an introduction to CAPL programming and a detailed presentation of the
programming language in chapter 3.
Logs in binary format take up less space on your hard drive, but they cannot be read
by normal text editors. The program's Offline mode offers you the same evaluation
options for logs in both formats.
Besides the file icon, you can also specify trigger conditions for file logging in the log-
ging block. This is often advisable, since frequently it is not the data traffic on the can
bus over the entire measurement period that is of interest, but rather only certain
time intervals, e.g. when there are implausible signal values or when error frames
occur.
A description of how to define trigger conditions and time windows around these con-
ditions is presented in section 2.7. To log the entire measurement it is sufficient to
change the mode from Single Trigger to Entire Measurement in the trigger configura-
tion dialog.
Exit the dialog with OK and then start the measurement, which you stop again after
20 seconds. Now with a double click on the log file icon you can open the logged
ASCII file. Besides the logged messages you can see that statistical information was
also logged. These lines correspond exactly to the information that is displayed in the
Bus Statistics window during a measurement.
Comment box
Comment box This tells the user what is to be input. The boxes behave passively
when clicking on them with the mouse. They cannot be accessed
by keyboard either.
Text input box Alphanumeric boxfield, e.g. for entering file names. Numeric box-
(type-bound) field, e.g. for entering integer or floating point numbers.
Drop-down list After clicking on the arrow along the right border of the box, a list
drops down, from which you can select a value from a prescribed
set of values.
Options but- These buttons represent mutually exclusive options. You can only
ton/Radio button select one option at a time. If you select another option, the previ-
ous selection becomes inactive. The currently selected option but-
ton is identified by a black dot.
Control A check box next to an option indicates that this option can be ac-
box/Check box tivated or deactivated. In this case you can activate as many check
boxes as desired. Activated check boxes are identified by an "x" or
„ “.
Button Buttons serve to execute certain actions, e.g. to exit the dialog box
or to open a subordinate dialog box.
All dialogs have action buttons labeled OK, Cancel and Help. If you press OK, the
settings you have made in the dialog are accepted into the configuration of the par-
ticular block. If you press Cancel, all settings made since the dialog box was last
opened will be lost. With the Help button you can obtain a help text about the dialog
box you are currently working with. After the Help window has been closed you can
continue with the dialog. All settings are preserved.
Most CANalyzer dialogs also have an Options button. When this button is activated
another dialog appears with which you can modify the CANalyzer global options
(decimal/hexadecimal number representation, symbolic/numeric mode).
Note: Modification of the global options from a configuration dialog affects data rep-
resentation in all system windows and dialogs.
Where there are multiple input and action boxes in a dialog box, first the desired box
must be selected. Using the mouse this is done by clicking on the appropriate box.
For input boxes this causes the text cursor to be placed at the mouse pointer position
in the box. Check boxes change their state, and for action boxes the action is exe-
cuted. With keyboard operation the particular box is selected with <Tab> or <Shift-
Tab>. Check boxes can be then be toggled using the spacebar. The <Enter> key
closes the dialog box and executes any actions selected in action boxes.
Mouse Operation
All blocks and some images in the active measurement setup window are mouse
sensitive. When selected by clicking the left mouse button, the element prese-
lected in this manner is identified by a frame as the Active Element. When the
right mouse button is then clicked, a popup menu appears in which the object is
configured by the methods described above. As an alternative, the configuration
dialog for the active block can be called directly by double clicking with the left
mouse button.
Keyboard Operation
When the measurement setup window is active, if <Tab>, <Shift-Tab> or one of
the cursor keys is activated, the preselect frame around the currently active ele-
ment is indexed forward. <Tab> results in forward indexing (<Shift-Tab>: Re-
verse indexing) of the internal processing sequence. The cursor keys index for-
ward to the next closest element geometrically in the direction of the arrow.
When <F10> is activated the popup menu of the active element appears. As an
alternative, the Enter key can be used to call the configuration dialog of the ac-
tive block directly.
The spacebar can be used to deactivate the preselected function block in the
measurement setup; it can be reactivated by pressing the spacebar again.
With <Ctrl-F6> and <Ctrl-Shift-F6> you can bring any opened CANalyzer window to
the foreground and activate it.
At the program start CANalyzer first reads information on hardware settings, start
paths, editors used, etc. from the project file CAN.INI. in the system directory. Af-
terwards, a configuration file *.CFG is read in. This file, which contains all informa-
tion on the currently active configuration of CANalyzer, is updated automatically after
a prompt at each program stop.
You can specify a working directory in the program icon. To have this file loaded
automatically at the start you can also enter the name of a configuration file in the
command line for program names. This method can be used to configure CANalyzer
differently at the start by using multiple icons. If no entries were made in the com-
mand line, the last opened configuration is automatically loaded.
Statistics window
Toolbar for
active Graphics window
Measurement setup
Data window
Graphics window 2
Busstatics window
After selecting an entry the relevant window is activated and is displayed in the fore-
ground.
Menu line Used to select basic functions
Toolbar Used for quick selection of important commands and also
contains status indicators for the number system being used
(decimal or hexadecimal) and to display of keyboard entries
made during the ongoing measurement.
Measurement setup The measurement setup displays the program’s data flow. All
options are set in this window for parameterizing a meas-
urement or evaluation.
Trace window Bus activities are recorded here. The user can scroll in this
window after a measurement has been completed.
Statistics window The mean transmit frequencies of messages are displayed
as line spectra above the identifier axis in this window. As an
option, the user can toggle over to mean transmit spacing.
The window can be zoomed for detailed evaluations.
Data window Preselected data segments of messages can be displayed
here.
Graphics window Graphic representation of signal time responses, which are
displayed in a X-Y diagram above the time axis. After the end
of measurement a measurement cursor and a difference
cursor are provided, with which you can examine the coordi-
nates of all measurement points or differences between two
measurement points precisely.
In Online mode the PC-card serves as the data source. It registers CAN messages
on the bus and passes them on to CANalyzer.
Moreover, some of the supported PC-cards also provide additional information such
as the detection of Error and Overload flags, the values of error counters, the bus
load and external trigger signals.
To insert new evaluation blocks in the measurement setup, click the branch with the
right mouse button and select the new window from the popup menu. This places the
new block after the last block of the same type. It gets the standard name with a se-
rial number. The first Trace window is called Trace, the second gets the name Trace
2, etc.
As an alternative, you can insert evaluation blocks by opening the popup menu for
one of the evaluation blocks and selecting a new block there.
You can also delete the block from the measurement setup via its popup menu, pro-
vided that there is more than one evaluation block of that basic type in the meas-
urement setup. When the block is deleted, the entire branch is always deleted, in-
cluding all of the insertable evaluation blocks there.
To open the window assigned to the evaluation block, double click the block with the
left mouse button or choose Show Window in the block's popup menu. Multiple win-
dows of the same type are shown cascaded in the standard layout.
c:\...\myproject
myproj1.cfg, myproj2.cfg
.\capl
ecu1.can, ecu2.can, test.can, sqr.gen
.\dbc
myproj.dbc, addon.dbc
.\log
test.asc, test.log
References to other project files (e.g. to database files *.DBC or to CAPL programs
*.CAN) are also saved in the configuration files. CANalyzer works internally with
relative paths. That is, referenced files are searched and read-in relative to the con-
figuration file during loading. Consequently, if you move your project directory with all
associated files to another location in the directory tree or to another drive, the data-
bases and CAPL programs referenced by the configuration file are found and cor-
rectly read-in at the next loading.
Note: To document or archive configurations, from the menu item File|Files used you
can have a list generated of all files belonging to the active configuraiton (databases,
CAPL programs, etc.) or have a ZIP archive generated.
The last configurations you worked with are saved in the [LastCANalyzerCon-
figurations] section of the CAN.INI file. The list of last opened configurations
in the File menu allows you to access these configurations. If you do not specify a
start configuration on the command line, the last edited configuration of this list is
used at the program start.
These options affect the representation formats throughout the entire program.
Note: Please note that the numbering system in CAPL programs remains unaffected
by these options. Identifiers with the prefix 0x are interpreted as hexadecimal values,
analogous to the C programming language. Otherwise the CAPL compiler always
assumes that they are decimal numbers.
1
The Offline mode for the analysis of log files is described in section 2.7.4.
After the sub-icons drop down in response to double clicking on the channel icon or
clicking once on the [+] symbol, the chip icon appears beneath the channel symbol
with the label Setup and two items with the labels Acceptance filter and Options.
When you click the Setup chip icon the sub-dialog for bus parameterization appears
on the right side, with which you can configure the chip's baudrate and bus registers
(cf. section 2.2.2). When you click the Acceptance Filter item, on the right side you
see the sub-dialog for configuring the chip's message acceptance filtering (cf. section
2.2.3). Finally, with the Options item you obtain a sub-dialog for configuring driver
and card options (cf. section 2.2.4).
You can confirm all entries with the OK button or reject them with Cancel. If you only
wish to undo the entries of one of the sub-dialogs mentioned above, press the Undo
Page button in the particular sub-dialog. If a channel icon is selected Undo will can-
cel all changes (Setup / Mask / Options) made to this channel.
Above the list you see the input boxes for clock frequency and number of samples.
Shown after the list is the prescaler resulting from the register values.
The CAN controllers are provided with 16 MHz clocks when delivered, and as a rule
16000 (kHz) should be entered in this box. However, it may be necessary to change
out the clocks for special applications. Then the appropriate frequency must be en-
tered here.
In the Samples input box you set the number of bus samples per bit time. Possible
values are:
• 1 Sample. This setting is recommended for High Speed Buses (SAE Class C).
• 3 Samples. This setting is recommended for Low/Medium Speed Buses (Classes
A and B) to filter out level peaks on the bus.
The two Bus Timing Registers define how an individual bit of the serial bit stream is
assembled on the bus. Please refer to the data sheet for the CAN controller (SJA
1000/82C200/82527/72005) for the values that should be entered here. Input the
values as hexadecimal numbers. On the right side of the dialog box you can deter-
mine whether the entered values are plausible (e.g. whether the desired baudrate
has been achieved).
There are multiple Bit Timing Register pairs for a given baudrate which determine the
timing of the CAN controller with regard to the sampling time point, number of BTL
cycles and synchronization jump width (SJW). You can view a selection of allowable
register pairs in the list of sampling options.
Displayed in this list are all Bus Timing Register values for the configured baudrate
and sample count. Shown next to the register values are associated values such as
the sampling time point (Sample) in percent of bit time after the beginning of the bit,
number of BTL cycles (BTL cycles) and the synchronization jumpwidth (SJW).
Once you have changed the baudrate or sample count, click on the list box to update
the list. Afterwards you can select the desired sampling option.
tivated on the SJA 1000 controller. However, please note that when the acknowledge
is deactivated communication can only occur over the bus if at least one other bus
node sends an acknowledge.
Note: On the CAN-AC2 card (with 82C200 or i82527 controller) the acknowledge
can only be deactivated by moving the appropriate jumper.
Instead of entering the mask and code directly, you may program acceptance filter-
ing in CANalyzer using a logical mask (Acceptance filter for standard indentifiers or
Acceptance filter for extended identifiers). You can enter one of the values 0, 1 or X
for each bit in this mask. A message occuring on the bus is only be received if all
mask bits given as 0 or 1 agree with the corresponding message bits. Bits shown as
X are not utilized in the comparison ("don't care"). The values of the acceptance
mask and acceptance code are automatically calculated and displayed after inputting
the logical mask.
You will find a detailed explanation of acceptance filtering for all supported CAN con-
trollers, with examples, in online Help.
Depending on the CAN PC card used, various options may be configured in this dia-
log. These include:
• Reporting the time point of a transmit request (TxRq) to measure delay times
(cf. section 2.3.1).
• Choosing whether bus statistics should be displayed, as well as their
• Display refresh rate (cf. section 2.5.4.3).
The context-sensitive Help function offers more detailed descriptions for your particu-
lar hardware platform.
Note: The actual display of statistical data can be deactivated separately by discon-
necting the Bus Statistics window from the data flow. This will enhance performance.
In contrast to a complete disabling of bus statistics support, data can still be logged
and evaluated later in Offline mode.
For typical applications, a program block, generator block or replay block is inserted
at the hotspot before the transmit block. You can use this to specify what should be
transmitted.
Note: When transmitting from CAPL programs, generator blocks and replay blocks,
you can explicitly specify which of the two CAN controllers (bus connections) should
be used to transmit the message. This is observed accordingly by the card driver.
Filters or user-defined analysis programs can be inserted in the data flow diagram
before the evaluation blocks. As a result, the data flow can be configured in many
ways to suit the particular task.
Each evaluation block has a measurement window in which the data arriving in the
block are displayed. The functions of all measurement windows are described in de-
tail in the sections below. Only the logging block is not assigned its own window. In-
stead, a log file is assigned to it for the purpose of logging bus data traffic and then
studying it "offline" (cf. section 2.7.1).
Located between the function blocks are insertion points (hotspots), at which blocks
can be inserted for to manipulate the data flow (Filter, replay, generator block, CAPL
program block with user-definable functions). Before and after the block inserted in
this manner, new hotspots appear, so that additional blocks can be inserted. The
data flow can also be broken at the hotspots. You will find a description of all insert-
able function blocks in section 2.6.
Figure 27 shows a possible CANalyzer configuration in Online mode2, whereby a
generator block is provided in the transmit branch (e.g. for cyclic transmission of one
or more messages). A filter is inserted in the trace branch, so that only certain mes-
sages will be displayed in the Trace window. The signal branch with data and graph-
ics windows, the statistics branch and the bus statistics branch each receive all data,
while the logging branch is broken.
Note: The data flow in the measurement setup is always directional. It runs from the
left, starting with the card icon, to the evaluation windows on the right, and in the
transmit branch from top to bottom to the transmit block, and from there to the card.
Messages generated in the transmit branch (e.g. by an inserted generator block) ar-
rive first at the CAN controller on the PC-card; from there - once transmission has
been completed successfully - they are fed back in on the left side of the measure-
ment setup at the card icon.
2
Data flow and functions in Online and Offline modes only differ in the data source and in the transmit
block. Refer to section 2.7.4 for a description of Offline mode.
time stamp
,
trace window
RX buffer of
the controller 3.2000 1 3FC Rx d 3 29 10 98
3.2000 sec
CAN-Bus
The messages to be transmitted are passed from the transmit block via the card
driver to the CAN PC-card. If your hardware supports the card and driver option
Activate TxRq in the Options item of the PC-card icon's popup menu, and you have
activated this, the driver returns the time of the transmit request assigned to the CAN
microcontroller to you. In the Trace window, for example, you would see the mes-
sage to be transmitted with the attribute TxRq.
After successful transmission the message is returned with the actual time of trans-
mission and the attribute Tx, so that the transmit messages can be displayed and/or
logged in the Trace window. If these messages reach the transmit block directly
again, they are not retransmitted. This prevents unintentionally forming infinite loops
which might severely load the bus under certain conditions. If an infinite loop is to be
programmed intentionally (e.g. as a base load) this can be done by recopying the
message in a program block.
CANalyzer transmit
branch
time stamp
,
trace window
Tx buffer of
the controller 2.7000 1 3FC TxRq d 3 29 10 98
.
2.7000 sec
trace window
2.7400 1 3FC Tx d 3 29 10 98
The TxRq display permits measurements of the difference between the time of
transmit request and time of transmission. The time between the message with Tx
attribute and TxRq attribute is essentially the transmission time of a message, i.e. the
time that the CAN controller needs to place a message completely on the bus. It is a
function of baud rate and message length. The transmission time also grows as a
result of lost arbitration events, which can be observed more for low-priority mes-
sages at high bus loads.
Since the (very small) latency time of the card driver interrupt must be added to the
transmission time, the following general formula applies:
tTx - tTxRq = Transmission time + Latency time
Note: Under high load conditions the display of messages might be delayed in the
evaluation windows under some circumstances. However, the time stamps for the
messages remain unaffected by this, since they are already assigned to the mes-
sages when they are received on the card.
Moreover, so-called signals are defined in the database. A signal is a symbolic de-
scription of a data segment within a message. Besides identifying the data segment,
the signal definition also incorporates characteristics such as machine format (Mo-
torola/Intel), sign handling, a conversion formula and physical unit of measurement.
This permits direct display of physical dimensions in the data window, such as:
"Speed = 810.4 rpm".
Please refer to CANdb++ Editor documentation or CANdb++ Editor online Help for
further details on creating and modifying a database. Important aspects of working
with databases are explained in section 4.3.
If the database has been filled out completely, you can search in this Explorer for
e.g. a node, a message or even a list of all signals in the database.
Please refer to online Help for further instructions on using the Message Explorer
and Signal Explorer.
Time Point in time when the information arrived at the CAN card (Receive, trans-
mit or transmit request). If the message was generated by a CAPL program,
the time set in the program is displayed. Output is in seconds from the start
of measurement.
Chn Number of the CAN controller chip which provided the message. Generally
the number 1 or 2 is output in this column. If the message was generated by
a CAPL program block, whereby the CAN number was not declared explic-
ity, the character * is output.
Name If a symbolic database is used the message names appear. The columns
"ID" and "Name" can also be shown as a combined column.
DLC The DLC (Data length code) specifies the length of the CAN-data field in
bytes.
Besides these main columns there may also be other configurable columns, depend-
ing on the specific CANalyzer option.
A number of other events are output in the Trace window:
Error frames:
When error frames occur a message will appear in the Trace window.
At any time you can switch back and forth between the two representations, even
during a measurement. Thus, the user can switch over to chronological output mode
after the measurement to page forward and backward through the received mes-
sages in the Trace window.
Note: The Trace window can be stopped by the toolbar icon during a measure-
ment run, so that you can analyze its contents in a user-friendly manner without ter-
minating the measurement.
Furthermore, the Trace window offers you two different time formats. You can select
whether the time stamp for messages should be displayed as absolute, i.e. in sec-
onds since the start of measurement, or relative to the message preceding it. In the
latter case, in fixed mode the time differences always refer to the same line. As a
result, in this mode you can read off the transmission intervals between messages
with the same identifiers. In Chronological mode the time differences are always
shown referenced to the last message displayed in the window.
If you are working with multiple windows, the actions always act only on the active
Trace window. If another measurement window is active, when one of these buttons
is activated the window of the first Trace block is activated, and the function is exe-
cuted in this window. If you are only working with one Trace block, the action is exe-
cuted there directly without the window being activated.
rect time stamp that is already assigned to it by the PC-card. At high base load the
message buffer might overflow and messages could be lost. A warning is output in
the Write window. To prevent a buffer overflow when "Tracing along", it is recom-
mended that all unnecessary branches (Logging, Statistics window, etc.) be discon-
nected. At high bus load, switch the Trace window to the fixed mode to economize
on computing time (see also 4.2 regarding this).
In offline mode computer power plays a subordinate role. Here the trace branch can
always be active. An animate function is also available, with which the entire meas-
urement can be repeated in slow motion, and the entries can be tracked in the Trace
window.
Always displayed are the signal name - which can be set in the configuration dialog -
and its associated value. You can also decide whether the value should be displayed
as a raw datum (hexadecimal or decimal), as a physical value with accompanying
unit of measurement, or as a bar chart.
The signal names and values displayed in the window are context-sensitive. When
the mouse pointer is moved over them, the element below the pointer is identified by
a frame. This element can be dragged to any window location with the mouse, allow-
ing you to group signals and values according to your needs.
All signals of the signal list are shown in the list box at the upper left of the dialog.
Here you can accept new signals from the associated database. When copying, the
abbreviated signal name is modified such that no ambiguities result. The abbreviated
name appears during the measurement as the signal identifier in addition to the ac-
tual signal value.
With the Define and Edit buttons you can enter a new signal description - independ-
ent of the database - in the Data window or modify an existing signal description.
Physical
The raw data are extracted from the CAN message, scaled by the (linear) con-
version formula, and displayed as decimal fixed point numbers.
Example: Signal T consists of 5 bits, is unsigned, has a factor of 10 and an off-
set of 0. Then the possible raw value range is 0-31, and the physical value range
is 0-310. Therefore, the necessary output width is 3 characters.
Please note that invalid format strings can lead to unpredictable results as seri-
ous as system crashes. As a user you are fully responsible for the validity of the
format string!
Signal-time responses are displayed graphically in the Graphics window. They are
displayed in a X-Y diagram above the time axis. The measurement data remain in
the Graphics window after a measurement stop and can be examined using special
measurement cursors.
The Graphics window has a legend in which the selected signals are shown with
their value ranges and colors. It also has a toolbar from which you can easily call the
most important measurement functions. Both the legend and toolbar can be config-
ured in the window's popup menu and can be enabled or disabled from there.
In the Graphics window there is exactly one active signal identified by inverted font in
the legend. You can make a signal the active signal using the Tab key, by Page
Up/Down or by clicking the signal name with the mouse. If Single-signal mode is en-
abled, all commands - such as Measure, Zoom and Scroll - refer to the active signal.
In Multisignal mode the commands refer to all signals of the Graphics window.
All Graphics window signals are displayed in the list box at the upper left of the dia-
log. With the New Signal ... button you first open a list for selecting CAN messages.
In a second list you can then import the signals from the message you initially se-
lected into the Graphics window.
Pressing the Delete button removes the highlighted signals from the list. With
Define... you can define a signal, if you wish to display it without using the database.
The Edit... button allows you to modify an existing signal description.
In the text input box Short name you enter a short, descriptive name for the signal,
which is then output as the signal name in the Graphics window legend.
The display modes physical and decimal are available to you. In the physical display
mode the raw data are extracted from the CAN message, scaled with the (linear)
conversion formula, and displayed as physical values in the Graphics window. The
necessary signal data are obtained from the database. In the decimal display mode,
on the other hand, the raw data are only extracted from the CAN message and dis-
played as decimal numbers. There is no scaling by a conversion formula.
Moreover, you can also change the sequence of signal entries in the legend of the
Graphics window. This is useful if you have configured a rather large number of sig-
nals, but the window is too small to show them all in the legend. Additionally, you can
move the deactivated signals to the lower border so that you can still see as many of
the active signals in the legend as possible, even with relatively small window dimen-
sions.
To move a signal entry you would select it with the mouse and choose the desired
direction from the popup menu or by the key combination <Alt+Arrow up> or
<Alt+Arrow down>.
For all signals you have entered in the Graphics window's signal configuration dialog,
values are automatically assigned for Y-scaling, signal color and time axis, as well as
the lines type. The values for Y-scaling and lines type are assumed from the data-
base. In the Graphics window's Options dialog you can configure all of the options to
satisfy your work requirements. The dialog consists of two parts, the axes options
and the measurement options. You can toggle between the two parts with the action
buttons Measurement > and < Axes.
Listed in the dialog's signal list are all those signals which were entered in the signal
selection dialog.
Line Types
The line type in the last column identifies the display type for the display of a signal
curve.
With Line the measurement points are connected by a line. This representation re-
sults in a continuous curve. It is the default option for displaying physical signals that
are at least one byte in length.
With the Steps option, after a measurement point a horizontal line is output to the
time of the next measurement point and from there a vertical line to the measure-
ment point. This display type is especially suitable for digital signals. Steps is the de-
fault option for signals that are less than 8 bits in length.
With the Horizontal option, after a measurement point a horizontal line is output up to
the time of the next measurement point. With Dots only the measurement points are
marked.
Display Modes
Beneath the signal list you will find four input boxes for configuring the time axis.
With Output you can define the display mode.
If multiple measurement points fall together within the time range of a single screen
pixel, then in Pixel mode only measurement points at the borders of this range are
displayed. This leads to faster output if there are many measurement points in a
small space. Under some circumstances, however, individual peaks might not be
shown in the signal response, if the measurement point with the extreme value lies
within this range. In Full mode, all measurement points are output even if they lie
within the time range of the same screen pixel at the active scaling. When there are
many measurement points in a small space, this will lead to a lower output speed,
but all extreme values of the signal response will be displayed.
The output mode setting has no influence whatsoever on measurement value acqui-
sition.
If you select the option Do not change axis options under Actions at measurement
start, then the last configured Graphics window setup is assumed at the start of the
measurement. Set with time axis sets the Graphics window - at the measurement
start - to a time range selected by you. Also, with Set time axis and home
configuration at the measurement start you can set the Y-axis range you had previ-
ously defined in the popup menu with Save home configuration.
If you check the option Fit time axis under Actions at end of measurement, the signal
responses over the entire measurement duration are displayed at the end of the
measurement. Otherwise, the displayed time interval remains on the screen at the
end of the measurement.
Note: It is always the case that either single-signal mode or multisignal mode is ac-
tive. The operations that change time axis scaling are always executed for all signals
- regardless of the setting single-signal / multisignal mode - since there is only one
time axis for all signals in the Graphics window.
the difference) of this measurement point are shown in the upper legend. In the leg-
end with signal names, the differences in signal values for all signals are shown for
the time points that have been set. The two time points and the time difference are
also displayed. The measurement cursor considers the option Single-Signal or Mul-
tisignal mode. In Single-Signal mode the small box only jumps to measurement
points of the active signal; in Multisignal mode the box jumps to the next closest
measurement point of all signals.
Fit all
Independent of the preset mode, the signals are scaled such that they are com-
pletely visible. To do this, the program determines the actual minimum and
maximum values for each signal and the time range of all signals, and scaling is
adjusted accordingly.
Zoom-in/Zoom-out
This command magnifies or reduces, by a factor of 2, either the active signal (in
Single-Signal mode) or all signals (in Multisignal mode). The size is changed ac-
cording to the preselected axis mode, either for only one axis (in X-mode or Y-
mode) or for both axes simultaneously (in X/Y-mode).
Operations that change the scaling of the time axis are always executed for all
signals (independent of the option Single-Signal/Multisignal mode), since there is
only one time axis for all signals in the Graphics window. Axes can also be
scaled individually for each signal in the Graphics window's options dialog.
Fit
The signals are scaled such that they are completely visible. This involves de-
termining the actual minimum and maximum values of each signal as well as the
time range for all signals, and the scaling is set accordingly. The active modes
(X-mode, Y-mode or X/Y-mode, and Single-Signal or Multisignal mode) are
taken into consideration. This fits the entire graphic optimally in the window.
Round
Scaling of the displayed value range for all signals is rounded-off. This involves
rounding-off the active Division value to a valid whole number (Division = n * 10x
, n = [1 to 9], x = whole number). The lower and upper range limits are rounded-
off to the precision of the Division value.
Rounding always affects all signals of the Graphics window. The active mode (X-
mode, Y-mode or XY-mode) is considered. Scaling of the signals is rounded-off
to a whole number value.
Marker
This command activates or deactivates measurement point marking. The color
of the measurement points matches the preset signal color.
Grid
This command enables/disables grid lines in the Graphics window. The grid lines
match the subdivisions of the Y-axis. You can set the color of the grid lines in the
Color Options dialog.
Y-Axis
This command enables/disables labeling of the Y-axis in the active Graphics
window.
When labeling is disabled, a Y-axis with 10 subdivisions is displayed for all sig-
nals. In the legend the following are shown for each signal: Lower and upper val-
ues of the viewing area, and the value amount between any two subdivision tick
marks.
If labeling is enabled, the subdivision of the Y-axis is calculated automatically for
the active signal and is displayed in the color of the signal.
The tick marks are set to whole number values. If a signal is shown as decimal
(i.e. raw signal values without conversion), then only whole numbers are dis-
played. In this case, if an area between two adjacent numbers is shown magni-
fied, no subdivision tick marks will be seen any longer along the Y-axis. For the
physical display type subdivisions less than 1 are also shown.
When labeling is enabled the legend also shows the following for each signal:
Lower and upper values of the viewing area (i.e. not necessarily the values of
the lowermost and uppermost Y-axis tick marks) and the value amount between
any two tick marks.
The grid lines in the graphics display always match the tick marks on the Y-axis.
Grid lines are enabled or disabled by the Grid command in the window's popup
menu.
Colors
Here you select the background color for the window (white or black). Further-
more, you can open the Options dialog for configuring signal colors.
Signal Legend
With this function you choose whether the legend for signals should be dis-
played on the left side of the Graphics window or not.
Buffer size
Here you set the time interval that is to be saved (in seconds) for the signal re-
sponses of all signals configured in the Graphics window. For example, if you
enter the value 10 here, the last 10 seconds of your measurement in the Graph-
ics window are always saved and will be available to you after the end of
measurement for further evaluation. Consequently, high values for this
parameter will - particularly when displaying many signals - result in a large
memory requirement, but will allow you to track and evaluate the signal response
over a correspondingly large time period after the end of measurement.
After the measurement stop, with large signal buffers some functions may be-
come lethargic, such as moving or fitting signals, since in this case large quanti-
ties of data must be redrawn. Therefore, you should select a value for the buffer
size that is as small as possible.
Buffer limit
In addition to buffer size, you can also specify a buffer limit in kB. This defines
the maximum memory usage by the Graphics window during the measurement.
Above all, this is advisable if you have specified a relatively large time span as
the buffer size. Without this maximum limit, more and more memory is de-
manded by the operating system over the course of the measurement. This can
lead to severe loading of the overall system due to swapping out of storage.
Please refer to online Help for further details.
User-defined refresh
Here you define how often the Graphics window display should be updated.
Small values result in continuous display of the signal response, but on the other
hand they place a high demand on computing resources and may lead to per-
formance problems with slower computers. High refresh values lessen the de-
mand on computing resources, particular when many signals are being dis-
played, but they lead to more erratic display of signal responses. You should
only input a refresh value if your measurement setup places special demands
(high bus load, simultaneous display of many signals, etc.) on the Graphics win-
dow. If the Refresh check box is not checked, the Graphics window automatically
determines a favorable default value. As long as no load problems are occurring
during the measurement (See section 4.2) you should not modify these options.
Scrolling
If the signal curves run into the right border of the Graphics window after the
start of measurement, this command will result in automatic tracking of the
curves. This involves shifting the time axis to the left, to make room for the
measurement signal on the right side. You can configure this behavior, referred
to as scrolling, in the Graphics window. Continuous scrolling is activated as a de-
fault, whereby the time axis is only shifted minimally to the left to give the im-
pression of continuously flowing signal curves.
To shift the time axis in jumps, thus maintaining the graphic diagram at a fixed
location between these jumps, you would deactivate the autoscroll mode in the
Graphics Window Settings dialog. In the line below this you can set the percent-
age of the displayed time interval by which the time axis should be shifted. The
smaller the value, the more evenly the view is scrolled, but it is shifted more fre-
quently. If the time interval displayed in the Graphics window is smaller than the
value you specified, the entire Graphics window is reconstructed, i.e. the image
is shifted by 100%. This prevents the Graphics window from demanding too
much computing power due to frequent scrolling for very short time intervals.
The scrolling procedure always demands more computer resources for smaller
time invervals, since scrolling must be done more quickly. Therefore, there is a
minimum refresh rate for updating the window contents. If the displayed time in-
terval is of the same order of magnitude as this rate, the signal curves are dis-
played again in an increasingly jumpy manner, since the window contents are
not always updated. You can set the minimum refresh rate in the project file
CAN.INI. This involves setting the following value in the [System] section:
GraphicWindowMinAutoRefreshrate= <Cycle time in ms>
However, please note that the smaller the value you select, the more system
loading will increase. Before modifying the automatic refresh rate, it is therefore
essential that you determine an optimal refresh rate with the help of the User-
Defined Refresh function.
Note: Some driver-specific problems in displaying the measurement cursors and dot-
ted lines, such as those used to draw extrapolated signals and window grid lines, can
be resolved by special options in the file CAN.INI. Refer to documentation in section
[Debug] of the project file regarding this.
2.5.4 Statistics
The Statistics block fulfills three different functions. One of these is to display the
average time between the sending of messages (secs/msg) during a measurement.
It can also display the messages per second. These are done by constructing a con-
tinuously updated line histogram above a message identifier’s axis. A sliding scale
averaging method with an adjustable averaging time is used. The other function
keeps statistics on all bus activities in the background; these results can be reported
either as a statistical report in the Write window or stored via a histogram function
and then processed further.
The Statistics window displays (see Figure 48) the mean message rates existing at
the end of the measurement. The Write window contains the statistics report (see
Figure 50).
In the statistics configuration dialog you can define whether the window diagram
should show the mean transmit interval (sec/msg) or its inverse, the mean message
rate (msg/sec). Also configurable is the averaging time which defines the time inter-
val at which the display is refreshed. Averaging is most precise with a low value, but
this demands a lot of computing time. With high values the statistics display lags be-
hind. An averaging time of approx. 1000 ms gives satisfactory results for standard
applications.
You can scale the Statistics window from the popup menu. The functions available
for this, such as Zoom, Fit, Basic Image and Manual Scaling are described in detail
in online Help.
Note: If the CAN card used supports extended identifiers, the function Basic Image
is split. The user can choose whether scaling will be over the range of standard iden-
tifiers or over the entire range.
Afterwards, the Write window shows - for each occurring ID coded by attributes - the
total number of messages, the mean transmit interval, its standard deviation, mini-
mum and maximum.
Note: The function Display statistics report can only be selected if the Statistic
report... Activate option was selected during the measurement.
The appropriate data selected can be stored as a CSV file (values separated by
commas) or transferred to Excel with the script toExcel.js. The data can also be ma-
nipulated with the user’s own Java or Visual Basic script.
The collected data can be reseted in the configuration dialog box of the statistics
block.
Note: Changing the configuration deletes all recorded ranges of coverage.
Under Options in the card icon's popup menu in the measurement setup window, the
user can configure the time interval at which the card passes bus statis-
ticsinformation to CANalyzer. This interval defines the frequency of the bus load
measurement and thereby also the averaging time. The default value is one second.
For measurements with extreme data throughput bus statistics may be deactivated
to increase performance. Above all, this affects the FIFO buffer between CANalyzer
and the CAN card. The error message "Rx buffer overrun" could possibly be pre-
vented by doing this.
Bus statistics information is also recorded in logging (cf. section 2.7). To include this
information in logging activate the Log internal events check box in the configuration
dialog for the log file. When the file is played back in Offline mode this information is
then displayed again in the Bus Statistics window. The Bus Statistics window re-
mains empty in Offline mode if the data source does not contain any bus statistics
information.
this function only acts on the window layout. All other configuration settings are pre-
served.
Select the function Set user-defined layout to define a window arrangement (Layout)
according to your working requirements. this window layout is saved in the file
CAN.INI. With the menu item User-defined layout you can finally arrange the win-
dows of each opened configuration according to the settings made with this function.
In the lower menu area all recently opened windows of CANalyzers are shown. Addi-
tionally, the active window is marked with a .
For Trace windows and the Write window, the window's font can be set from the win-
dow's popup menu with the function Font|Select. The fonts of function blocks and
function block comments e can be configured in the measurement setup.
The predefined font can be set for a window with the function Font|Reset.
If one of the first five menu commands is clicked on, a block is inserted in the data
flow plan which satisfies the particular function. New hotspots appear before and af-
ter this block, so that additional blocks can be inserted. The last menu item is a spe-
cial case. If it is activated a broken hotspot appears, which is intended to show that
the flow of information is blocked at this point.
Function blocks can be recognized by their appearance or by their labels in the data
flow chart. A “P” stands for a CAPL node (Program block), “PF” and “SF” designate
the Pass and Stop Filters, “PE“ and “SE“ are the corresponding filters for environ-
ment variables, a “G” refers to a Generator block, an “IG“ to the Interactive Generator
block and “R“stands for a Replay block. The channel filter is represented with a spe-
cial icon.
All blocks have popup menus which the user can open by either clicking with the
right mouse button or by selecting the block in the data flow plan and then pressing
<F10> . The first menu item opens a configuration dialog for the particular block,
which only serves to parameterize the block (there are two configuration dialogs for
the generator block, which can be opened by the first two menu items). By selecting
the last item in the popup menu "Delete this node", you can remove the block from
the data flow plan. All configuration information is lost in the process. However, the
CAPL source files of the CAPL node and the log file of the replay block are not de-
leted.
From the popup menu you can assign a comment to each function block and analy-
sis block. The comment is displayed by default. With the function Show comment in
the popup menu you can enable and disable the display separately for each block.
Please note that the size of the displayed comment depends on the actual position of
the function block and the space available for the display. Independent of this, it is
always the case that only the first two lines of the comments are displayed. It is ad-
visable to use only short key words in the first two lines and to enter more elaborate
information further below in the text.
If you have not entered any comment, but the display is nevertheless activated, the
predefined comment is displayed.
An important use of program blocks is e.g. to preset transmit messages in the trans-
mit branch. However, even very simple program blocks can be written for data reduc-
tion (Example: Only pass every tenth message) or for monitoring.
Note: A CAPL node blocks all messages in a data flow branch which are not explic-
itly output with output(). A program that is transparanet for all messages must
therefore contain the following message procedure:
on message * {
output(this); /* Pass all messages */
}
Consequently, filters can also be programmed in the evaluation branch with CAPL
programs by the intentional use of output(this). The functionality of these pro-
grams can be much more complex than that of normal pass or blocking filters.
Program blocks appear in the data flow plan as small blocks with the label P.
In the configuration dialog, first assign a CAPL file name (Extension *.CAN) to the
program block.
Press Edit to open the CAPL Browser. Browser is an easy-to-use tool for creating,
modifying and compiling CAPL programs and is described in detail in section 3.4.
Before you start the measurement you must compile the CAPL file. To do this, press
the Compile button or choose Configuration|Compile all nodes in the main menu to
compile all CAPL programs at once.
Note: It is permissible to reference the same CAPL programs in different program
blocks. For example, this may be of interest if the identical data manipulations are to
be performed in two different data flow branches (e.g. data reduction operations).
You can deactivate the node by pressing the spacebar or by selecting the line Node
active in the CAPL node's popup menu. The node can be reactivated by repeating
the same action. The menu command Delete this node removes the CAPL node
from the measurement setup.
Note: When a CAPL node is removed from the measurement setup, the CAPL
source file is not deleted.
The filter configuration is lost when a filter block is removed from the measurement
setup (by choosing the command “Delete this node” in the popup menu or “Del”).
Note: In keeping with its function, a pass filter which is not configured (empty) does
not pass any messages and so blocks all message traffic. If older configurations are
opened with Version 3.1, their old pass and stop filters will reappear.
Double clicking on the filter symbol opens a configuration dialog in which the avail-
able channels are seen and can be set.
The filter configuration is lost when a channel filter is removed from the measure-
ment setup (by choosing the command “Delete this node” in the popup menu “Del”)
Note: A channel filter which has not been configured can be used in the data flow
plan to simply show the number of channels being used.
In all three cases the time spacing between messages within the file is preserved. If
it is less than one millisecond, transmission is delayed accordingly.
The configuration is lost when a replay block is removed from the measurement
setup (by selecting the command "Delete configuration" in the popup menu). This
only affects the options set in the dialog box. The replay file itself is not deleted.
Note: To make a replay block capable of sending data onto the bus, you must insert
it in CANalyzer's transmit branch. If you insert it in the evaluation branch, the data
are indeed sent to the evaluation blocks to the right of the replay block and are dis-
played in the associated windows. However, the data do not reach the bus, due to
the left-to-right directional flow of data.
Note: To have a generator block send data onto the bus, you must insert it in CANa-
lyzer's transmit branch. If you insert it in the evaluation branch the data will indeed be
sent to the evaluation blocks to the right and be displayed in the appropriate win-
dows. However, they will not reach the bus due to the left-to-right directional data
flow.
When one of the trigger conditions occurs, the next element of this list is transmitted.
When the end of the list is reached the program resumes with the first element if the
run mode has been set to cyclic. The list may also consist of only one element.
Nine lines are displayed in the dialog box. The active line - to which the dialog but-
tons refer - is identified by the " " symbol at the beginning of the line. The active line
is shifted automatically by activating the <TAB> key or by clicking the dialog entry
boxes with the mouse.
Each line of the list consists of 11 columns. In the first column you enter the desired
identifier. The DLC field defines the number of data bytes in the message. After that
come the fields for data bytes. Only the number of bytes specified by the DLC are
accepted. The rest are ignored. The last column is a combination box for selecting
the controller by which the message is to be transmitted.
value table to the signal in the database, you can use the relevant symbolic descrip-
tor instead of a numeric value. You can select this from the signal value table in the
middle column.
Physical dimensions are stored in discrete form in the CAN messages. However, it
may not always be possible to represent the numeric value entered in the Value box
as a discrete value. In such cases, when exiting the line or activating the OK button,
the two next possible physical values are displayed in a dialog. Then the entered
value is rounded to the next possible closest value.
Example:
The signal EngineData.RPM is defined as a 16 bit unsigned with an offset of 0 and a
factor of 10. If the value to be compared is entered as 1015, the raw value would
have to be 1015/10 = 101.5. Since only discrete values may occur, either 101 or 102
must be used, which correspond to the physical values 1010 or 1020. It is these two
numbers which appear in the dialog.
In spite of discrete memory storage, quantities which have digits after the decimal
point can be valid. In the example above, if a factor of 10.5 is used for calculation
1008 and 1018.5 are recommended as possible values.
The configuration dialog allows you to parameterize a trapezoidal function. When the
dialog is exited with OK the corresponding lines are automatically generated in the
generator block transmit list. The following signal responses can be generated with
certain parameters:
Signal re- Parameter
sponse
Square ta = tf = 0
Triangular th = tv = 0
Saw-tooth th = tf = tv = 0 or
ta = th = tv = 0
Constant n1 = n2
Displayed in the upper part of the dialog box are the message and the signal. Shown
below this, in the preview box, are a trapezoid and the meanings of its parameters.
By setting individual parameters to zero, the following responses can be generated:
The levels n1 and n2 must be entered physically. The relevant limitations apply here (see
for example generator block signal values).
The entry for transmit interval identifies the interval between any two messages, and
this corresponds to the entry in the generator block dialog Trigger initiation period.
Since CAN is message-based and not signal-based, all signals of a message get the
same transmit interval!
Since this signal characteristic generator is only a tool for the generator block and is
not a block itself, the following must be observed when using different period lengths
for several signals within one message:
The generator creates a list of messages with:
No. of messages = Period / Transmit spacing
This is exactly one period. If the transmit list contains more they are rejected. Using
the combination box Remainder of the user can define how remaining signals are to
be handled for supplementally generated messages:
All bytes to 0:
All signals are set to the raw value 0.
Continue cyclically:
During generation the previous messages are copied as often as necessary until
the new period length is reached.
Example:
The original list contains 3 messages, and the new period length requires 9 mes-
sages. The new signal (byte 1) is a saw tooth.
Interactive generator blocks appear in the data flow plan of the measurement setup
as small blocks with the label IG. Just like traditional generator blocks they are per-
meable to all data in the data flow diagram. That is, they do not filter the data flow
like filter blocks or CAPL blocks do, rather they act in a purely additive manner.
Appearing at the top of the configuration dialog is a list of messages to be sent - the
transmit list - with the message name, message parameters, trigger conditions and
data field of the particular message. Below this, a list of signals appears for the ac-
tive message (marked on the left side of the transmit list with ">"). In this signal list it
is easy for you to configure the values of individual message signals.
All input boxes are explained in the status bar at the lower border of the dialog. The
explanation is always shown for the currently selected box entry. There are also key-
board shortcuts for use without the mouse; these are described in section 2.6.6.7.
When the mode is changed in the mode signal, its associated signals are shown. All
signals not defined in the currently set mode are filtered out.
While the configuration dialog is open and selected by the insertion point, all key-
board entries except <F9> and <Esc> are used for editing within the dialog. A trans-
mit triggering of the generator blocks or activation of CAPL program nodes cannot be
performed by keyboard press until the insertion point is moved to one of the main
windows of CANalyzer or the test mode is explicitly enabled in the configuration dia-
log.
2.6.7 Break
If certain branches of the data flow in the measurement setup should not be run
through, then a hotspot can be converted to a breakpoint. This is advisable, e.g. in
online mode, if all functions (above all in the Trace window) cannot be serviced any
longer without loss of data due to a high data rate.
When a break is created the configuration after the break is fully preserved, so that
the old state can be reinstated after the break is deleted. Therefore, the break pro-
vides a very quick means for temporarily disconnecting certain data paths and
thereby saving computer time.
At the start of a measurement the currently valid data flow plan is converted to an
internal tree structure. In this conversion process breaks which are encountered in a
path are propagated forward to the next branching point. Therefore, it is irrelevant to
processor loading whether a break is placed at the front or back of a path. The same
path is always masked out.
time axis
log file
time axis
log file
Figure 62: Time Window for the Trigger in Single Trigger Mode (top) and in Toggle
Trigger Mode (Bottom)
In Single Trigger mode the user-definable time window between the pre-trigger and
post-trigger times is set around each trigger. Pre-trigger and post-trigger times then
relate to the same trigger. All data falling within this time window are recorded in the
log file.
In Toggle trigger mode the time window is described by two successive triggers
(start-of-block and end-of-block triggers). The first trigger activated during measure-
ment is the start-of-block trigger, and the second is the end-of-block trigger. After-
wards, another start-of-block trigger follows, etc. The pre-trigger time in toggle trigger
mode is referenced to the start-of-block trigger, and the post-trigger time is refer-
enced to the end-of-block trigger.
Figure 63: Log file with 2 trigger blocks. Pre-trigger: 50ms, post-trigger: 100ms,
Trigger types: Message GearBoxInfo and Error Frames
Note: If you wish to write all data to file for a long-duration measurement you should
select the option Write full buffer to file. This option causes a full buffer to be written
to file during the measurement. The buffer size is of decisive importance with this
option. To prevent excessive system loading during saves to the buffer, and to pre-
vent data losses, the buffer should not be configured to be very large. Buffers of
approx. 1000 messages have proven effective in practice. This button is only acces-
sible in Entire Measurement mode or in Single Trigger mode with the trgger type
Start.
To prevent data losses, especially at high system loading, you should observe the
following points:
• Close all applications that run in background and demand system time;
• Switch all blocks in the meausrement setup over to Cyclic Update or disable them
entirely.
• Utilize filters for data reduction.
• Do not execute any unnecessary user actions during the measurement, such as
moving windows.
If a data loss occurs in spite of this, you can make this apparent to the user with the
option Data Lost Message Box in the Logging dialog. This option results in a dialog
box being displayed after the end of measurement if data loss occurs. If no message
appears you will know that all data were logged.
With the help of this option the corrupt locations in the log file are marked with a ‘*’
as a special symbol. The symbol for data loss only disappears when the overload
condition has ended.
The format of the log file is defined by the File format combination box. The user can
choose between binary and ASCII format. The binary format is recommended for
online measurements, since this format is faster in offline evaluation and also gener-
ates smaller log files. When ASCII format is chosen, the data are saved as readable
text. The setting of the global switch determines whether decimal or hexadecimal
representation is used. Among other things, ASCII format can be used for data ex-
change with external programs or for incorporating trace data into documents.
The Offline mode data source can be configured to be either binary or ASCII files.
The automatically preset extension of the file name is .LOG for a binary log file or
.ASC for an ASCII file. The recommended default name is CANWIN.LOG or
CANWIN.ASC.
To view or edit an ASCII file, double click the file icon or press the Edit file button in
the configuration dialog for the log file. You can use your own text editor for this. To
do this, enter the following line in section [Environment] of the file CAN.INI:
LogEditor=MYEDITOR.EXE
whereby you must enter the name of your own editor for MYEDITOR.EXE.
You can configure logging, such that the selected log file name is automatically in-
cremented after the end of measurement or at the end of a trigger block. This pre-
vents overwriting files that already exist:
Example:
Log file before the measurement: C:\CANWIN\MESS_01.ASC
Log file after the measurement: C:\CANWIN\MESS_02.ASC
In the configuration dialog you can indicate whether data losses in overload situa-
tions should be reported to you (cf. section 4.2). In the log file, the faulty lines are
marked with a ‘*’ as a special symbol.
Note: Analogous to output in the Write window with the CAPL function write(),
you can output text lines from CAPL programs to ASCII log files using the functions
writeToLog() and writeToLogEx().
The data source in Offline mode is a file, e.g. generated by logging in Online mode.
Analogous to Online mode, all measurement and evaluation windows are also avail-
able to you in Offline mode. The only option omitted is the possibility of sending data
over the bus. Furthermore, Offline mode provides a powerful search and break func-
tion, with which you can intentionally stop the replay of the log file. This is described
in section 2.7. In the logging block, which is also available in Offline mode, data can
be resaved to a new file, whereby targeted data reduction can be achieved by means
of insertable data manipulation blocks.
You can enter the name for this file under the Configuration... item in the data icon's
popup menu on the left side of the offline measurement setup. CANalyzer supports
both binary and ASCII logging formats for this.
The menu item below this, Break conditions... , opens a dialog in which you can set
an interruption point – a breakpoint. When the condition you have specified occurs,
the offline replay is interrupted until you resume replay of the file with the function
Run (F9), Animate (F8) or Step (F7).
You can configure the break condition with the Conditions... button, which is de-
scribed in more detail in section 2.7.5. If the tools provided in the configuration dialog
are inadequate, the CAPL language – with the function stop() – allows you to pro-
gram a breakpoint yourself.
Start
The individual messages of the data source are read-out and are sent as quickly
as possible through the components of the measurement setup. In Offline mode
the measurement can be resumed after a break. Reset must be called for a new
start.
Reset
After a measurement has been run through either partially or completely in Off-
line mode, it can be reset to the beginning again with Reset and can thereby be
studied from the beginning again.
Animate
Instead of reading data from the source file as quickly as possible, in Animate
mode only about 3 entries per second are read from the source file. This results
in a slow-motion representation of the processes. All of the display windows may
be active during this process, e.g. so that the user can easily observe the se-
quence of messages in the Trace window. The Animate run can be interrupted
by the <Esc> key or the menu command Start|Break. The speed of the Animate
mode can be set with the following line in section [Offline] of the file
CAN.INI:
AnimationDelay=nnn
where nnn describes the time between the replay of two successive events in
milliseconds. (The default value is 300 [ms])
Break
In Offline mode this menu item interrupts the replay of data from the source file
(Animate run). The same can be achieved by the <Esc> key. A restart resumes
the replay at the point where it was interrupted by Break.
Step
This menu item (or the <F7> key) causes a single step of the measurement to
be run. Each time this is activated only one additional message is read from the
log file and processed in the data flow plan.
Within a measurement the user can switch back and forth whenever desired be-
tween Start, Animate and Step.
Online
Toggles to Online mode. In Online mode a data flow plan is shown in the meas-
urement setup window, whereby the CAN PC-card serves as the data source.
Moreover, there is also a transmit block. The time basis in Online mode is real
time, and clocks in CANalyzer and on the CAN board are synchronized at the
start. All time data are referenced to the start of measurement. Data acquisition
cannot be resumed after a break in Online mode, rather it may only be restarted.
The Animate mode is not possible.
Online (Copy)
Toggles from Offline mode to Online mode, whereby the data flow plan of Offline
mode is assumed with all of its function blocks. The corresponding portion of the
last Online configuration is lost in the process. Since the Offline mode does not
have any transmit branch, that section remains unchanged.
Offline
Toggles to Offline mode. In Offline mode a data flow plan is shown in the meas-
urement setup window, in which a data icon serves as the data source. Evalua-
tion of this file is begun by Start, and the evaluation can be resumed after a
break with <ESC>. Animate mode and Single-Step mode are also possible. The
time basis in Offline mode is based on the times recorded for the data in the file.
Offline (Copy)
Toggles from Online mode to Offline mode, whereby the portion of the data flow
plan of Online mode located after the branch to the transmit block is assumed.
This affects all window configurations and function blocks. The last Offline con-
figuration is lost in the process.
The mode switchover functions with copy represent a user-friendly method for as-
suming elaborate options such as trigger conditions, data display configurations or
CAPL programs, and it allows the user to begin immediately with analysis or a new
recording.
Symbol Meaning
<= less than or equal to
> greater than
>= greater than or equal to
After this is a mask to be executed, and the user must choose the numbering format
to be used:
X Masked out
1 Bit is set
0 Bit is not set
To find all messages whose first data byte is odd, the following must be entered:
D0 == XXXXXXX1
Note: It is possible to use >, < etc. in binary mode, but this is difficult to interpret
in mask conditions, and is only of interest to users who have a knowledge of pre-
cise machine-internal data representation.
The SYM buttons Message name and Signal name after the text input boxes are
used to call the symbolic selection dialog, in which you can select the message - and
if applicable also the signal from the database - to which triggering should occur.
If you only enter a message name in the symbolic selection dialog, logging is trig-
gered whenever the message occurs on the bus.
If you select a signal name in the input box below this, a decision is made based on
the signal value regarding when logging should be triggered. The comparison of sig-
nal values is made based on their physical interpretations. This involves choosing a
comparison operator and entering a numeric value.
Physical dimensions are stored in discrete form in the CAN messages. Conse-
quently, the specified numeric value may not always be capable of being mapped to
a discrete value. In such cases, after pressing the Enter key or the OK button the two
next possible physical values are displayed in two boxes below your entry.
Example:
The signal Enginedata.rpm is defined as a 16-bit unsigned value with an offset of 0
and a factor of 10. If 1015 is input as the comparison value, the raw value would
have to be 1015/10 = 101.5. Since only discrete values may occur, either 101 or 102
is used, which corresponds to physical values of 1010 or 1020, respectively. It is
these two values that appear in the two information boxes.
In spite of discrete saving, valid values may still have digits after the decimal point. If
a factor of 10.5 were used in the above example, then 1008 and 1018.5 would be
recommended as possible values.
You can also enter a time range for each primitive, within which it should be active.
Outside of this time range the condition would never be satisfied.
2.7.6.1 Export
The user can limit the export to specific signals. This involves selecting the desired
signals in the Signals selection list.
In the Expanded options dialog that is opened by pressing the Expanded button in
the Logging Export Configuration dialog, the user can define in the Actions box those
programs that can be started after an export.
2.7.6.2 Conversion
Conversion of log files is supported in both directions, i.e. ASCII->Binary and Bi-
nary->ASCII.
3 CAPL Programming
3.1 Overview
The universal applicability of CANalyzer results in large measure from its user pro-
grammability.
The CAN Access Programming Language CAPL is a C-like programming language,
which allows you to program CANalyzer for individual applications. In the develop-
ment of network nodes, for example, the problem arises that the remaining bus
nodes are not yet available for tests. To emulate the system environment, the data
traffic of all remaining stations can be simulated with the help of CAPL.
You can also write programs for problem-specific analysis of data traffic with CAPL,
or you can program a gateway - a connecting element between two buses - to ex-
change data between different CAN buses.
CAPL nodes are inserted in the data flow plan as function blocks. Event procedures
serve as inputs in CAPL. These procedures can react to external events (e.g. the
occurrence of specific messages). You send messages by calling the function
output(). These language tools and symbolic access to the various variables in
the database make it possible to create simple prototypical models of nodes. The
event procedures can be edited in the user-friendly Browser.
We start with a discussion of potential applications of CAPL programs in section
3.1.1. If you are working with CAPL for the first time, section 3.2 that follows offers
you an introduction to the programming language. You will find a small but complete
example of creating a CAPL program in section 3.3. Section 3.3 then gives an over-
view of CAPL Browser, the tool for creating and modifying CAPL programs that is
included with the standard product.
Finally, section 3.5 serves as a reference, providing a language description. All refer-
ences in this manual to environment variables or CAPL functions for environment
variables do not apply to CANalyzer. Environment variables are supported exclu-
sively by CANoe.
Therefore, you can utilize a CAPL program to develop monitoring and testing for your
special problem task. The CAPL program reacts to messages that CANalyzer regis-
ters on the CAN bus, and afterwards you can call your own analysis and test func-
tions.
You can also use a CAPL program to emulate the system environment for a control-
ler. The CAPL program reacts to both messages on the CAN bus and to your key-
board inputs, responding with certain CAN messages according to the event regis-
tered. It is entirely up to you to determine which actions are performed in response to
which events.
Another possible application of CAPL is to program a gateway - that is a connecting
element between two buses - to exchange data between different CAN buses and
moreover to correct erroneous data occurring in this exchange.
Last but not least, the logging block can also be triggered by a CAPL program. Con-
ditions of any desired complexity can be formulated for triggering. Triggering is initi-
ated by a call of the intrinsic function trigger().
located to the right of CANalyzer's transmit branch can indeed generate messages,
but it cannot send them on the bus. Since the data flow is directed from left to right,
these messages are only passed to the function blocks to the right of the CAPL pro-
gram. Only messages generated by CAPL programs located in CANalyzer's transmit
branch4 can be sent out on the bus. This completely logical behavior - which may at
first seem surprising - applies equally to the generator block, which - when it is lo-
cated on the right side of the measurement setup - similarly generates messages
without affecting the bus.
Therefore, in general those CAPL program blocks that exclusively serve analysis
purposes should be inserted on the right side of the measurement setup, while pro-
gram blocks for transmitting CAN messages should be inserted in CANalyzer's
transmit branch.
4
CAPL programs which are inserted at hotspots to the left of CANalyzer's transmit branch can also
send messages on the bus. The part of the data flow between the card icon and the branch to the
transmit block must, in strict terms, therefore also be included as part of the transmit branch.
(on key), track the occurrence of messages on the bus (on message), or execute
certain actions cyclically (on timer).
ID 100
on message 100 {
Bus event: write("Message 100");
}
on key 'a' {
Keyboard event: write("'a' pressed");
}
on timer Uhr_1 {
Time event: write("Clock elapsed");
}
variables {
int msgCount; // Is set to 0 at measurement start
message 34 sendMsg = { // Declare message with Id 34
dlc = 1, // Set Data Length Code = 1
byte(0) = 1 // Set 1st data byte = 1
};
}
Integer and floating point numbers are used as in other programming languages.
They are compatible with one another, and arithmetic is performed with 32-bit resolu-
tion for integers and 80-bit for floating point numbers.
5
Besides keyboard events, in CANoe you can - with event procedures of the type on envvar also
react to actions that you perform yourself on user-defined control panels.
In the Browser, global variables are defined in the global variables pane on the upper
right of the screen. The data types dword, long, word, int, byte and char can
be used analogous to their use in the C programming language. The data types
float and double are synonyms and refer to 64-bit floating point numbers con-
forming to the IEEE standard.
Variables can be initialized when they are declared, whereby you can use either sim-
ple notation or brackets {}. With the exception of timers, the compiler initializes all
variables with default values (unless otherwise defined: 0).
Local variables are - in contrast to C - always created as static. This means that an
initialization is only performed at the program start. The next time they enter the pro-
cedure, variables have the value they had when they last exited the procedure.
CAPL permits the declaration of arrays (arrays, vectors, matrices), analogous to their
declaration in the C programming language.
variables {
int vector[5] = {1,2,3,4,5};
int matrix[2][2] = {{11,12},{21,22}};
char progname[10] = „CANalyzer“;
}
variables {
timer delayTimer; // Declaration of a second timer ...
msTimer cycTimer; // ... and a millisecond timer
}
...
setTimer(delayTimer,3); // Set timer to 3 sec
setTimer(cycTimer,100); // Set timer to 100 msec
...
In contrast to C, CAPL does not permit the use of pointers. This language feature
was avoided intentionally to make CAPL programs more robust. For example, mem-
ory protection violations can be brought under significantly better control this way:
Instead of a crash in the program's high-priority real-time library, the measurement is
terminated in a controlled manner when programming errors occur, and a message
is output to the Write window.
Since the emphasis in modeling with CAPL lies in the description of the bus behavior
of nodes, the scope of the CAPL language is normally sufficient. Nevertheless, ex-
panded functions in C, C++ or PASCAL can also be implemented in a custom Win-
dows DLL and integrated in CAPL. See section 3.6 for detailed instructions on this.
Note: CAPL programs you wish to use to send messages on the CAN bus must al-
ways be inserted in CANalyzer's transmit branch in the measurement setup. Mes-
sages sent by CAPL programs further to the right in the measurement setup will not
be output on the bus.
The components of objects can be accessed by means of component selectors. If
you wish to define an object for a specific chip (for CAN cards with more than one
CAN chip), you would enter the appropriate selector (CAN1 or CAN2) followed by a
dot (.) in front of the message name.
You can access control information for the CAN message objects using the following
component selectors:
ID Message identifier
CAN Chip number
DLC Data Length Code
DIR Direction of transmission, possible values: RX, TX, TXREQUEST.
RTR Remote Transmission Request; possible values: 0 (No RTR), 1 (RTR)
TYPE Combination of DIR and RTR for efficient evaluation.
(TYPE = (RTR << 8) | DIR )
TIME Time point, units: 10 microseconds
For examples of the use of component selectors for messages, please refer to the
CAPL Browser's online Help.
When the specified event occurs, the relevant procedure body is executed. This can
contain the declaration of local variables, C-like arithmetic instructions and control
instructions, and calls of intrinsic default procedures.
React to Messages
The event procedure type on message is provided to react to the receipt of CAN
messages in the CAPL nodes.
on message 123 React to message 123 (dec),
Receiving chip is not considered
on message 0x123 React to message 123 (hex);
receive chip is not considered
on message EngineData React to message EngineData
on message CAN1.123 React to message 123,
if it is received by chip CAN1
on message * React to all messages
on message CAN2.* React to all messages
that are received by chip CAN2
on message 100-200 React to all messages
with identifiers between 100 and 200
Within an on message procedure the key word this is available to you for access-
ing the data of the message just received.
In the following example, a simple gateway is programmed with CAPL. The gateway
should transmit all messages between Bus 1 and Bus 2 in both directions, but it
should modify the message with ID 34 by setting byte 4 to 0.
on message CAN1.34 {
message CAN2.34 sendMsg; // Local message variable with
// name sendMsg, identifier 34,
// target controller CAN 2
sendMsg = this; // Copy all data and attributes
// of received message (this)
// to message to be transmitted
sendMsg.byte(4) = 0; // Change byte 4,
// always enter 0
output(sendMsg); // Transmit message
}
Please note that at this point it would be insufficient to change the fourth byte on the
received message this directly. As described in section 3.2.5, all changes to this
are local and therefore are not considered in the output() function. Consequently,
this is copied to a local message variable.
A bridge function is implemented for all other messages: All messages from Bus 1
are transmitted to Bus 2 and vice versa.
on message CAN2.* {
message CAN1.* sendMsg;
sendMsg = this;
output(sendMsg);
}
CAPL programs are, by default, impermeable to bus events. This means that with a
CAPL node in the evaluation branch of the measurement setup, in effect you block
the data flow to the right side of the node. You must explicitly program the passing of
messages for CAPL nodes in the evaluation branch. You would write the following to
make the CAPL node permeable to messages:
on message * {
output(this);
};
In CAPL a maximum of one procedure is called for each received message. If multi-
ple procedures exist in a CAPL program which match the message, that procedure is
tasked which has the most specific name. The following rules apply here:
• Entry of a controller number has precedence over no entry
• Entry of a message number has precedence over the entry of a wildcard.
An example of the priority sequence (the search for the first applicable procedure is
made from top to bottom):
The sequence in the example corresponds to the representation of the event proce-
dures in the Browser. Two event procedures with the same name are not allowed in
CAPL.
The code for a key press can either be input as a character, number or a predefined
name for a function key.
In the following example, all messages with the (hexadecimal) identifier 1A1 are
counted, and this count is output to the Write window when the ‘a’ key is pressed.
Please note that this program is written for the evaluation branch of the measure-
ment setup and was made permeable to all messages there by the call of
output(this). Without output(this) the messages would not be passed to the
function blocks further to the right, and of course they also would not be displayed in
the corresponding windows.
variables {
int counter = 0;
}
on key 'a' {
write("A total of %d messages 0x1A1 counted",counter);
}
on message 0x1A1 {
counter++;
output(this); // Only in the evaluation branch
}
on message * {
output(this); // Only in the evaluation branch !!!
}
In on key procedures, the key word this is used to determine the active key code.
For example, you could write the following code to consolidate all keyboard handling
in a single event procedure.
on key * {
switch(this) {
case 'a' : ... break;
case F10: ... break;
...
}
}
on errorPassive {
...
write("CAN Controller ist in errorPassive")
write(" errorCountTX = %d", this.errorCountTX);
write(" errorCountRX = %d", this.errorCountRX);
};
Note: At this time, access to the values of the error counter is only supported by sys-
tems with CANcardX.
on message 100 {
byte byte_0;
byte_0 = this.byte(0);
...
}
Analogously, in CANoe you can read out the new value of the just changed integer
environment variable Switch with the following:
on envVar Switch {
int val;
val = getValue(this);
...
}
You should not change the value of this within an event procedure. Nevertheless,
so that you can use this as a parameter, value changes to this are not prohibited
by the CAPL compiler. However, please note that such write accesses to this only
have local validity (i.e. within the event procedure). You will receive an appropriate
warning when compiling. As a result, if - after a change to this - you call the func-
tion output(this) in an on message event procedure, the unchanged original of
this is output and not its changed value.
message EngineData m;
char errSymbol[32];
...
m.rpm=100; // Assignment of a raw value
m.rpm.phys=123.5; // Use of conversion formula
In the first line, the raw value 100 is assigned to the data bits which you have allo-
cated to the signal RPM in the database. In the second line, the conversion formula
assigned in the database is used to calculate the bit value.
When working with signals please note that signal values are always saved in dis-
crete form. If a physical value is assigned, the next closest discrete raw value is en-
tered after scaling. When the signal is read-out afterwards, the result may not neces-
sarily be the original value.
For example, let us assume that the signal RPM of the message EngineData is de-
fined as a 16-bit unsigned with an offset of 0 and a factor of 10. If the physical value
1015 is assigned, the raw value would have to be 1015/10 = 101.5. However, since
only discrete values may occur, 101 is saved. When this value is read out again it is
scaled to 101*10 = 1010.
float rpm;
int time, n;
char buff[100];
...
time = EngineData.CycleTime;
n = ABS.NodeNumber;
rpm = EngineData.Speed.Max_rpm;
strncpy(buff,motordat.db_name,elcount(buff)-1);
This portion of a CAPL program reads out the values of the message attribute
CycleTime (Object: message EngineData, type: INT), the signal attribute
Max_rpm (Object: Signal Speed of the message EngineData, type: FLOAT), the
network node attribute NodeNumber (Object: Network node ABS, type: INT) and the
database attribute db_name (Object: Database motordat, type: STRING).
Attribute values of the ENUM type are handled like strings in CAPL. Therefore, the
last line of the example above is used to copy the value of the ENUM message at-
tribute to the buffer buff. Please note that all attributes share the same name area.
Therefore, it is not possible for example to use a database attribute and a message
attribute which have the same name.
Note: If you read out the attribute value of an object in CAPL without having explicitly
set this value for the object in the database, you get the default value that you en-
tered for each attribute when you defined it in the database editor.
You would write the following code in CAPL to output a message LightData with the
symbolic value Red (=1) of the signal LightStatus on the bus.
If you would like to read the symbolic name of a signal value, use the sys operator:
on message LightData
{
char buf[64];
strncpy(buf,this.AmpelStatus.sym,elCount(buf)-1);
write("this.AmpelStatus = %s",buf);
}
Analogously, you can also work with symbolic values for environment variables of the
Integer type, provided that you defined these in the database.
If you change the controller assignment of the database to CAN1, the message is
transmitted via Chip 1 when the same CAPL code is run again after recompiling.
When using more than one database, you can resolve ambiguous symbols by quali-
fying them. This involves simply entering the database name followed by two colons
(::) before the symbolic name. For example, let us assume that the message 0x10F
is named DiagData in the database Infodat. In the database Motordat, on the other
hand, the name DiagData is used as a name for the message 0x4E1. With
Infodat::DiagData for the message 0x10F and with Motordat::DiagData for
the message 0x4E1 you get unique designations for the two messages.
Please refer to online Help for further instructions on resolving ambiguities when
working with more than one database.
Please note that there is already an intrinsic CAPL function write() with which you
can output formatted text to the Write window. The function defined in the example
overloads the instrinsic function and instead of always calling it, a two-dimensional
array is passed instead.
You will find a complete library of intrinsic CAPL functions in CAPL Browser's online
Help. The following table offers a brief overview of the most important functions.
Transmission of frames output(), output(errorFrame)
Output to Write window write()
Output to log file writeToLog(), writeToLogEx()
Measurement control trigger(), stop()
Time management setTimer(), cancelTimer(), timeNow()
Array size determination elCount()
Environment variable ac- getValue(), putValue()
cess
PC access outport(), inport()
Calculations sin(), cos(), abs()
configuration dialog's Edit... button or directly by double clicking the program block in
the measurement setup.
If you choose a new file the CAPL Browser, which is described in detail in section
3.4, starts with its sub-windows ("Panes"). It allows you to create and edit CAPL pro-
grams quickly and easily.
For your program you will first need an integer variable which counts the messages.
For example, you could name it counter. Go to the upper right Browser pane and
enter this name in the variables block. The following should now appear in this pane:
variables {
int counter;
}
Like all global variables, this variable is automatically initialized to zero at the meas-
urement start.
In the next step, this variable should be incremented whenever an EngineData mes-
sage is registered. Therefore, you must expand the CAPL program to include an
event procedure of the type on message ("React to message event"). To do this,
click the event type Messages in the Browser tree using the right mouse button and
insert a new event procedure of this type using the New command in the popup
menu
Now a procedure template appears in the Procedures Text Editor. First replace the
text <newMessage> by the symbolic name EngineData, which you could also as-
sume directly from the database via the popup menu item CANdb Message. During
compilation the CAPL compiler replaces the symbolic name by the corresponding
identifier 0x64.
Now you only need to define which actions should be performed when the event oc-
curs. Since the program is to count messages, the variable counter must be must
be incremented whenever a message is registered. The complete procedure ap-
pears as follows:
on message 0x100
{
counter++;
}
As a last step, the output to the Write window must still be implemented. Finally, the
program should not just count messages, but also keep track of how many mes-
sages have been counted.
The output to the Write window should occur when the ‘a’ key is pressed. Therefore,
you must define another event procedure for the event "Press key 'a'". In the
Browser tree you select the type Keyboard. This causes the previously defined on
message procedure to disappear, since it belongs to a different event type. Of
course it still remains a component of the CAPL program and will appear again as
soon as you select the Messages event type again.
Now insert a Keyboard event in the CAPL program from the popup menu. A new
procedure template will appear in the Procedures Text Editor, which you fill out as
follows:
on key 'a'
{
write("%d 0x100 messages counted",counter);
}
The format entry %d refers to the integer variable counter, which is entered after
the comma. For the most part, this format string conforms to the C function
printf().
That completes the program. Save it and then start the compiler either with the F9
key, or the main menu command Compiler|Compile or by the lightning icon button on
the toolbar. If you have made an error in creating the program, a message window
will open showing you the error. Double click this error message to go to the location
where the error occurred. After you have corrected it and saved the program file
again, recompile the program. Once the program has compiled without errors, the
message Compiled appears in the status bar at the bottom of Browser's main win-
dow.
Now start the measurement. The generator block in the transmit branch begins to
cyclically transmit messages of the type EngineData, which are now counted by your
program. Whenever you press the 'a' key the text "n EngineData messages
counted" can be seen in the Write window, whereby n represents the number of
messages counted.
A special Browser is integrated in CANalyzer for the user-friendly creation and modi-
fication of CAPL programs. This Browser shows you the variables, event procedures
and functions of a CAPL program in structured form.
Multiple Browser windows with different CAPL programs can be opened simultane-
ously.
The CAPL compiler is started from Browser's main menu or toolbar. Compilation
time is very short, even for larger programs. When an error is detected, the faulty
program section is shown, and the cursor is positioned at the location of the error.
This makes it very easy to make corrections.
• Division by zero
• Exceeding upper or lower array limits
• Exceeding upper or lower offsets in the data fields of messages
• Stack overflow in the call of CAPL subroutines
If such a run-time error is discovered, the measurement is terminated in a controlled
manner. You get a message in the Write window containing the name of the CAPL
program, the error type and an error index. With the help of this error index you can
easily find the location in the CAPL source text that caused the error: Enter the index
under the menu item Compiler|Find run-time errors.
On the other hand, as a user you have the option of generating run-time errors your-
self with the CAPL function runError(), thereby making specific critical program
sections fault-tolerant. In doing so, you can also give the function an error index
which is then output to the Write window upon completion of the measurement.
ing programs make sure that the programs can be compiled error-free, since other-
wise it might not be possible to recognize function names or procedure names un-
ambiguously.
With File|Export you can save CAPL programs in ASCII format. The generated file
does not contain any structural information of the CAPL Browser and can only be
displayed in a Browser window by importing it later.
• The C++ comment symbol // can also be used. The rest of the line then serves as
a comment:
// Comment line
"}"
In Browser global variables are declared in the upper right browser window.
varDeclList ::= varDecl [ varDeclList ] |
constDeclaration [ varDeclList ] |
The data types dword, long, word, int, byte and char can be used analogous to
their use in the C programming language.
The data types float and double are synonymous and designate 64 bit floating
point numbers conforming to the IEEE standard. Internal floating point arithmetic is
performed with 80 bits.
Example:
int counter;
double speed, temperature;
With timer a clock is created which does not run until it is set in an event proce-
dure. When time "0" is reached the associated event procedure is called. A variable
of the timer type can only be accessed by predefined functions. For timer the time
is decremented in one-second cycles, and for msTimer in one-millisecond cycles.
For reasons of speed, a 16-bit value (32 bits internally to count the ticks) is used for
memory storage. The maximum time for timer is 1799 s (limited by internal proces-
sor accuracy), and for msTimer 65.535 s (limited by 16 bits).
Example:
timer timer1s;
msTimer timer100ms;
CAN objects (messages, J1939 parameter groups) to be output from the CAPL pro-
gram are declared with message or pg. Object components are accessed by se-
lectors (see below).
msgDenotation :=
[ chipSelector "." ]<integer> | // Standard Id
[ chipSelector "." ]<integer>"x" | // Extended Id
[ chipSelector "." ]"*" | // Wildcard
[ chipSelector "." ]<msgSymbol> // Symbolic name
[ chipSelector "." ]<dbName>":"<msgSymbol>
// Symbolic name with database qualification
chipSelector ::= "CAN1" | "CAN2"
The name you enter for a CAN object is the message identifier or parameter group
number (<integer>) in decimal or hexadecimal representation. For extended identifi-
ers a x is appended. Entry of * means that this variable initially does not contain any
message identifier. It must then be defined in another way before the object is sent
out. Such objects may serve, for example, in filtering tasks to save all objects to be
passed unchanged. (The received message is then copied, including the message
identifier.)
When a symbolic database is used, the name from the particular database is used
instead of the number.
Example:
If the object is defined for a specific chip (for CAN cards with more than one CAN
chip), this can be entered as CAN1 or CAN2.
idList ::= <varId> [ "," idList ]
intIdList ::= intIdDecl [ "," intIdList ]
intIdDecl ::= declarator[ "=" declInit ]
declarator ::= <varId> | declarator "[" <integer> "]"
declInit ::= "{" declInitList "}" | simpleType | <string>
declInitList ::= declInit [ "," declInitList ]
simpleType ::= signedInteger | signedFloat
signedInteger ::= <integer> | "+" signedInteger | "-" signedInteger
signedFloat ::= <float> | "+" signedFloat | "-" signedFloat
Variables can be initialized when they are declared. Either the simplified writing style
or bracketing with "{ }" is possible here. Variables which are not explicitly initialized
are set to 0 in CAPL. It is possible to declare arrays (arrays, vectors, matrices). They
are used and initialized analogous to the C language. In particular, arrays of the type
CHAR are initialized by assigning a string.
Message variables can be initialized when declared. The data range can be ac-
cessed by entering the type and byte offset. Symbolic identifiers are provided for ini-
tializing the control ranges.
Example:
<integer>
Integer constants which can be written as decimal numbers, hexadecimal num-
bers (with 0x, etc.) or as character constants ('A'). An X is appended to the num-
ber when assigning a message identifier that is an extended ID (29 bits).
<float>
Floating point constant as in C.
<varId>
Identifier for a variable. Must begin with an alpha character or '_' and can contain
"any quantity" of alphanumeric characters or '_' . Upper/lower case formatting is
relevant. Umlauts and 'ß' are not accepted as alpha characters.
<constant expression>
Constant expression as in C.
constDeclaration ::=
"CONST" [ intTypeSpecifier | "DOUBLE" ] <varId> "=" <constant expression>
This is how constants are declared. The method corresponds to the #define direc-
tives of C with supplemental type information and type checking. If no type is given
'long' is assumed. Constants can be used any place where the use of <integer> or
<float> is allowed.
on message 100,200,250-300
on message EngineData
on message *
on message Motbus::EngineData
The code for a key press ("keyDenotation") can either be entered as a number or
with the help of predefined names for function keys. The option on key * serves as a
wild card. All key presses are passed to this function.
Note: Numbers may also be entered as character constants, e.g. 'A'. This permits
problem-based input for the "normal" keys.
Example:
on key 65
on key ‘a’
on key pageDown
on key *
The defined timer variable must be entered as a selection criterium for the reaction
to a timer.
Example:
on timer Timer1sec
on timer Timer100ms
Local variables are always created as static in CAPL (in contrast to C). This means
that initialization is only performed at the program start. When the variables enter the
procedure they have the same value they had when they last left the procedure.
It is not advisable to declare local variables of the Timer type. The purpose of these
event procedures is to trigger, but they can only react to global Timers.
The types of statements provided have been adopted from C and have the same
syntax and semantics. To simplify CAPL, goto and the option of declaring variables
after { were not implemented. As in C the programmer must be careful not to pro-
gram infinite loops.
exprStatement ::= [ expr ] ";"
A type conversion can be made explicitly (as in C) using the cast statement. A cast
specifying msgDenotation may be used to assign messages with different identifiers.
The use of symbolic notation is explained below.
When evaluating expressions that contain long, long, dword, int, word, char or
byte, an implicit type conversion is performed. The following rules apply:
8-bit values are first converted to 32-bit values (charÞlong, byteÞdword)
16-bit values are first converted to 32-bit values (intÞlong, wordÞdword)
If an expression contains mixed signed and unsigned values, the operation is exe-
cuted as unsigned after the expansion.
monadicOperator ::=
"+" | "-" | /* plus, minus */
"~" | "!" | /* bit not, logic not */
"++" | "--" /* Increment, Decrement */
postFixExpr ::=
primaryExpr |
postfixExpr "[" expr "]" |
postfixExpr "++" |
postfixExpr "--" |
postfixExpr "." selection
primaryExpr ::=
<varId> |
"THIS" |
<integer> |
<float> |
specialConst |
"(" expr ")" |
functionCall
selection ::=
intTypeSpecifier "(" <integer> ")"|
"CAN" |
"ID" |
"PGN" | (only J1939)
"DLC" |
"TYPE" |
"DIR" |
"RTR" |
"TIME" |
"SIMULATED" |
"PF" | (only J1939)
"SA" | (only J1939)
"DA" | (only J1939)
"PRIO" | (only J1939)
"R1" | (only J1939)
"DP" | (only J1939)
"CHARACTERISTIC" | (only J1939)
"ERRORCOUNTTX" |
"ERRORCOUNTRX" |
<signalSymbol> [ "." "PHYS" ] |
<attributeSymbol> |
<valueDescription> |
specialConstant ::=
"RX" | "TX" | "TXREQUEST" | "RXREMOTE" | TXREMOTE |
"TXREQUESTREMOTE" | "RXDATA" | "TXDATA" | "TXREQUESTDATA" |
"NOW" | "LPT1" | "LPT2" | "LPT3" | "ERRORFRAME" | "PI"
The data structure of an object is designated by the key word this within an event
procedure for receiving the CAN object.
Note: this should not be modified (read only)! But the use of this as a parameter
for CAPL procedures (see below) is generally not prohibited any longer. For write
accesses to this, a warning appears that this change will only be made locally. If,
for example, output(this) is called after a change, it will pass the unchanged
original of this.
The data range of a message can be accessed by inputting the data type as the se-
lector and the byte value offset (which starts with "0"). The following can be used as
selectors long, dword, int, word, char and byte.
When a project database is being used, an individual signal can be accessed by in-
putting the name of the signal. The compiler assumes the task of determining the bit
offset and bit length as well as the task of converting the machine format (Intel ⇔
Motorola). The values are interpreted in raw format. If physical interpretation is to be
used, the .phys operator must be appended. The compiler then scales the value
according to the conversion formula (factor, offset) specified in the database.
Example:
message EngineData m;
double x;
long i;
Note: It must be noted that signal values are always saved in memory as discrete
values! If a physical value is assigned, then the next closest discrete raw value is
entered after scaling. If the signal is read out afterwards, the result will not necessar-
ily be equal to the original value.
Example:
The signal EngineData.rpm is defined as 16-bit unsigned with an offset of 0 and a
factor of 10. If 1015 is assigned as the physical value, the raw value would have to
be 1015/10 = 101.5. But since only discrete values may occur, the value 101 is
saved. When the value is read out it is scaled to 101*10 = 1010.
This problem is of a general nature. Memory storage of floating point numbers is also
executed in discrete format (in this case conforming to IEEE specification). This can
result in inaccuracies:
double x, y;
x = 1.4;
y = 0.7;
if( x != y*2) write("Error x = %g, y*2 = %g",x,y*2);
In this example an error message could result. The correct comparison would be:
if (abs(x-2*y) < 0.001) write ...
The following symbolic constants are available to remain independent of the actual
coding of DIR and RTR:
For DIR:
RX Message was received DIR == RX
TX Message was sent DIR == TX
TXREQUEST Transmit request was set (DIR == TXREQUEST)
for message
For TYPE:
RXREMOTE Remote message was re- (DIR == RX) && RTR
ceived
In the project database the CAN objects (messages, signals, etc.) can be assigned
attributes and symbolic value descriptions. The attribute values of objects can be
accessed with the attribute name as object selector.
Example:
on message EngineSpeed {
// ‘msCycleTime’ defined as message attribute
if (this.msCycleTime == 100) { ... }
In on key event procedures, this serves to determine the current key code.
Example:
on key * {
switch(this) {
case ‘a’: .... break;
case F10: ... break;
...
}
}
this is not meaningful for event procedures which react to timers, start or error
frames.
Functions can be defined with overloading (as for intrinsics). This means that several
functions can be declared with the same name but different parameters: The type of
the result must always be the same.
void print(int i)
void print(int j[])
void print(int j[][]);
This method may be used, for example, to define a uniform output function for all
data bytes, which is always called under the same name. The compiler then always
calls the function that is appropriate for the particular data type. Existing intrinsic
functions can be expanded in this manner (e.g. write(int),
write(float),...,output(float),...).
Use of arrays as parameters:
Arrays are passed formally, as in C. But the program has been expanded to permit
passing of multidimensional arrays. The number of elements of a parameter can be
queried using the elCount() function. The compiler executes a range check. If an in-
dex is less than zero or greater than the number of elements used, a runtime error is
generated by runError().
Example:
Note: When you integrate custom DLLs in CAPL programs all paths for accessing
system resources are open to you (memory management, hardware, etc.). However,
due to the many problems associated with this method only experienced program-
mers should make use of this capability. Please understand that Vector Informatik
cannot provide any support for the creation of your own DLLs.
Name:
CAPL_DLL_INFO_LIST
Function:
Export of functions to CAPL
Description:
Column 1 contains the name of the function to be exported
Column 2 contains the address of the function in the DLL. All functions must be
defined and exported with the PASCAL calling convention.
Column 3 contains a description of the function parameters and return values.
The following character symbols are possible:
Symbol Meaning Comment
V void
L long
D unsigned long
I int Only together with field size > 0
W unsigned int Only together with field size > 0
B unsigned char Only together with field size > 0
C char Only together with field size > 0
F float Means "double" in 8 byte 80387 for-
mat)
0xabcd Symbol for valid table
Example:
The complete example is included in the CAPLDLL subdirectory of your system direc-
tory.
Note: A DLL function cannot be directly accessed from CAPL. In order to access the
functionality implemented in CAPL-DLL, the mapping between the name of the new
CAPL function and the DLL must be entered in the CAPL export table.
Example:
The function
appPut ({"dllPut", (CAPL_FARCALL)appPut, 'V', 1, "D"})
must be accessed in CAPL via dllPut and not via appPut.
output(message msg)
output(errorFrame)
Function:
Outputs a message or an error frame from the program block.
Parameters:
Variable of the type "message" or "errorFrame"
Example:
message 0x100 m100;
...
output (m100);
output (errorFrame);
resetCan()
Function:
Resets the CAN controller. Can be used to reset the CAN controller after a
BUSOFF or to activate configuration changes. Since execution of this function
takes some time, and the CAN controller is disconnected briefly from the bus,
messages might be lost here.
Example:
on key ‘r’ {
// After BUSOFF the controller is reset
resetCan();
}
Function:
Sets a different baud rate. The values do not become active until the next call of
the "resetCan()" function. This function can also be used to automatically set the
baud rate.
It should be noted that the values will depend on the CAN Controller used.
Parameters:
CAN channel:
0: Both controllers
1: Channel 1
2: Channel 2
BTR0: Value of Bit Timing Register 0
BTR1: Value of Bit Timing Register 1
Example:
Function:
Sets the Output Control Register. The values do not become active until the next
call of the function "resetCan()".
Please note that the values depend on the CAN platform used.
Parameters:
CAN channel:
0: Both controllers
1: Channel 1
2: Channel 2
OCR: Value of the Output Control Register
Example:
Sets the CAN controllers to "passive monitoring" when the CAN AC2/200/ANA is
used.
Function:
Outputs a byte to a port.
Parameters:
Port address or "LPT1"/"LPT2"/"LPT3" and value to be output.
Example:
Function:
Outputs a byte to a parallel port. This function automatically switches the parallel
port to the correct transmission direction.
Parameters:
Port address or "LPT1"/"LPT2"/"LPT3" and value to be output.
Example:
Function:
Reads in a byte from a port.
Parameters:
Port address
Return:
Byte that is read-in
Example:
Function:
Reads-in a byte from a parallel port. This function automatically switches the
parallel port to the correct transmission direction.
Parameters:
Port address
Returns:
Byte that was read in
Example:
long getCardType()
Function:
Determines the type of CAN platform being used. This is required, for example,
in programming the BTR / OCR values.
Return:
Value Board Type
0 DBB196 - Daimler-Benz Board FullCAN
1 DBB196B - " with BasicCAN
2 CANIB - Bosch CANIB
3 DEMO - Demo driver
6 CANAC2 - Softing AC2/200/ANA
7 CANAC2X - Softing AC 2/527/ANA
8 CPC/PP = EMS Wish Module
9 INDIGO - Silicon Graphics Indigo2
10 CANCARD - PCMCIA 11 Bit
11 CANCARDX - PCMCIA 29 Bit
12 CANAC2B - Softing AC2/527 11 Bit
13 VAN462 - NSI VAN Card
14 VANDEMO - VAN demo driver
16 Vector CAN-Dongle
17 Vector CANCardx
18 Virtual CAN driver
19 Caesar
20 Softing CANcard-SJA
Example:
switch( getCardType( ) ) {
case 6: setOcr(0,0x02);break;
case .....
default:
write("Unknown driver %d",getCardType());
break;
}
Function:
Determines the type of the CAN controller being used.
Parameters:
Value: CAN Channel:
0: Both controllers
1: Channel 1
2: Channel 2
Return:
Value Type of Controller
5 NEC 72005
200 Philipps PCA82C200
462 MHS29C462 VAN Controller
526 Intel 82526
527 Intel 82527
1000 SJA 1000 (CANcardX)
1001 SJA 1000 (CANcard)
Other types may occur. Demo versions return the result 0 or simulate one of the ex-
isting types. The function result is 0 if an attempt is made to access a nonexistent
channel (e.g. Channel 2 with CPC/PP) or if the driver used does not support this
function.
Function:
Outputs a text message to the Write window.
Parameters:
Format string, variables or expressions
Write is based on the C function "printf".
Valid format entries:
"%ld","%d": Decimal representation
The compiler cannot check the format string. Invalid format entries lead to unde-
fined results.
Example:
i = 10; j = 12;
write ("d = %ld, h = 0%lxh",i,j);
/* Yields: "d = 10, h = 0ch" */
Function
Sound output. In the Windows version of CANalyzer and in CANoe the parame-
ter duration has no effect.
Parameters
freq = Integer for sound pitch.
In the Windows version the parameter freq establishes which sound is to be out-
put. These sounds are defined in section [SOUND] of the file WIN.INI. This entry
is made in brackets.
Value of freq Meaning
0x0000 SystemDefault
0x0010 SystemHand
0x0020 SystemQuestion
0x0030 SystemExclamation
0x0040 SystemAsterisk
0xFFFF Standard Beep
Return: None
Note: If no sound card is installed in your computer, Windows always generates the
same signal sound whenever the function is called. In this case the freq parameter
has no effect.
sysExit()
Function:
Exits CANalyzer from a CAPL program.
sysMinimize()
Function:
Minimizes or restores the application window of CANalyzer. On the first call of
the function after system start, the application window is minimized; afterwards it
is alternately restored to normal size and minimized.
dword keypressed()
Function:
This function returns the key code of a currently pressed key. If no key is being
pressed it returns 0. For example, this can be used in a timer function to query
pressing of a key. A reaction can be made to the release of a key too.
variables {
msTimer Zeitgeber; // Timer
message 100 botschaft; // CAN message
}
on key F1 {
setTimer(Zeitgeber,100); // Start 100ms timer
write("F1 pressed"); // Output Write window
}
on timer Zeitgeber {
if(keypressed()) {
setTimer(Zeitgeber,100); // Restart timer
// Transmit as long as key is pressed
output(botschaft);
}
else {
// Reaction to release of key
write("F1 released");
}
}
trigger()
Function:
Initiates triggering of logging.
Example:
Note: Please note that the call of the trigger() function must be made from a
CAPL program in the logging branch or from CANalyzer's transmit branch.
Function:
Outputs a text message to an ASCII Log file. The functions are based on the C
function printf(). The compiler cannot check the format string. Invalid format
entries lead to undefined results.
The function writeToLog() outputs a comment symbol (//) and time entry at
the beginning of the line. The function writeToLogEx(), on the other hand,
leaves the output format entirely up to the user.
Parameters:
Format string, variables or expressions
Valid format entry: (cf. write()function)
setLogFileName(char filename[])
Function:
Sets the name of the log file
Parameters:
New name of the log file. This name can be entered as an absolute path or as a
pure file name. If a path is entered, all path levels that do not already exist are
created. Entry of a file name causes the log file to be created in the directory of
the active configuration. The directories within the path must be delimited by a
double backslash ('\\'). The file name may not contain any file extension; this is
determined automatically by the system.
Example:
Function:
Checks the parameter for extended identifier (29 bit) or standard identifier (11
bit)
Parameters:
Variable of the type "message" or ID portion of a message
Return:
1 if check is successful (true), else 0
Example:
if(isExtId(this)) { ... }
std = isStdId(m100.id);
Function:
Returns the value of a message identifier regardless of its type.
Parameters:
Variable of type message* or ID portion of a message
Return:
Identifier as Long variable
Example:
Function:
Returns an extended identifier
Parameters:
ID portion of a message
Return:
Extended identifier
Example:
msg.id = mkExtId(this.id);
stop()
Function:
In Online mode the running measurement is stopped. In Offline mode the call of
stop() causes a programmed break in the measurement run. Afterwards, the
measurement can be resumed by the main menu functions Start|Start,
Start|Animate, or Start|Step.
Example:
stop();
canOnline()
canOffline()
Function:
The function canOffline() disconnects the node from the bus. Then it is no
longer possible to transmit and receive messages. After this function has been
called, the node can be reconnected to the bus with the function canOnline().
Messages transmitted by the node are then passed to the bus again.
Note: These functions are only available in CANoe's simulation setup. For example,
they may be used there with network management - in simulations of the remainder
of the bus - to assure that a node simulated in CAPL does not send messages any
longer after the transition to bus quiet.
setStartdelay(int delay)
Function:
Sets the value of Startdelay for this network node. This function can only be
called in the event procedure preStart. After that, the value of Startdelay can not
be changed any more.
Parameter:
delay = an integer for the start delay in ms. This value can be between 0 und
999999. If this value is larger or smaller than this range a warning will appear in
the Write wiindow.
int getStartdelay()
Function:
Determines the value set for Startdelay for this network node in the simulation
setup.
Return:
Start delay in ms. If no Startdelay was set, the function returns null.
Example:
int val;
on preStart
{
setStartdelay(10000); // Set Startdelay to 10 Seconds
}
val = getStartdelay(); // val is allocated the value of
Startdelay
3.7.6 Time Management
Function:
Sets a timer
Parameters:
Timer or msTimer variable and an expression which specifies the duration of the
timer.
Example:
cancelTimer(msTimer t)
cancelTimer(timer t)
Function:
Stops a running timer
Parameters:
Timer or msTimer variable
Example:
setDrift(int drift)
Function:
A constant variance (deviation) can be set for all timers of a network node with
this function. Values between –100.00 % and 100.00 % can be entered. If the
value does not lie within this range, an announcement will appear in the Write
window.
Parameter:
drift = an integer for constant deviation.
int getDrift()
Function:
Determines the constant deviation when the drift is set.
Return:
Drift in +/- 1000,00%.
Example:
int val;
setDrift(3550); // sets the drift at 35.5 percent
val = getDrift(); // assigns the drift to val
Note: Setting a drift causes any jitter that may be present to be reset.
Function:
The jitter interval for all timers of a network node can be set with this function.
Both values can lie between –100.00 and 100.00 percent. If one of the values is
outside this range, an announcement will appear in the Write window.
Parameter:
min = an integer for the lower limit.
max = an integer for the upper limit.
Example:
int getJitterMin()
int getJitterMax()
Function:
Determines the upper or lower limit for the permissible deviation when the jitter is
set.
Return:
Upper or lower deviation in percent.
Example:
Function:
Sets the acquisition time for a message as the acquisition time for another mes-
sage or as the actual time. This function is obsolete and its only purpose is to
provide compatibility with older versions.
Parameters:
Variable of the type "message" or "now".
Example:
dword timeNow()
Function:
Returns the current system time
Return:
System time in units of 10 µsec. This time is determined with the help of the PC
timer with a resolution of 1 msec.
Example:
float x;
x = timeNow()/100000.0; //Actual time in seconds
Function:
Time difference between messages or between a message and the current time
in ms. The difference can also be calculated directly in units of 10 microseconds
(msg2.time-msg1.time bzw. now-msg1.time).
Parameters:
1. Variable of the type message
2. Variable of the type message or now.
Return:
Time difference in ms;
Example:
getLocalTime(long time[])
Function:
Provides information on the current time and date in an array of the type long.
The components of the array are filled with the following information:
No. Meaning Value Range
1. Seconds 0 - 60
2. Minutes 0 - 60
3. Hours 0 - 24
4. Day of month 1 - 31
5. Month 0 - 11
6. Year Beginning at 1900
7. Day of week 0-7
8. Day of year 0 - 365
9. Flag for Daylight Savings 0 - 1, 1 = Daylight Savings Time
Time entry
Parameters:
An array of the long type with at least 9 entries.
Example:
long tm[9];
getLocalTime(tm);
// tm now contains the following entries:
// tm[0] = 3; (Seconds)
// tm[1] = 51; (Minutes)
// tm[2] = 16; (Hours)
// tm[3] = 21; (Day of month)
// tm[4] = 7; (Month beginning with 0)
// tm[5] = 98; (Year)
// tm[6] = 5; (Day of week)
// tm[7] = 232;(Day of year)
// tm[8] = 1; (Daylight Savings Time)
getLocalTimeString(char timeBuffer[]);()
Function:
Returns the current date and current clock time in the form ddd mmm dd
hh:mm:ss yyyy (e.g. "Fri Aug 21 15:22:24 1998„) in the buffer that is provided.
Parameters:
Buffer in which the time is written. The buffer must have a capacity of at least 26
characters.
Example:
char timeBuffer[64];
getLocalTimeString(timeBuffer);
// Now in timeBuffer, for example:
// "Fri Aug 21 15:22:24 1998"
getValue
Syntax
int getValue(EnvVarName); // Form 1
float getValue(EnvVarName); // Form 2
long getValue(EnvVarName, char buffer[]); // Form 3
long getValue(EnvVarName, byte buffer[]); // Form 4
long getValue(EnvVarName, byte buffer[], long offset); // Form 5
Function:
Determines the value of the environment variable with the identifier EnvVar-
Name. The data type of the value returned is determined by the type of environ-
ment variable (int for discrete (Form 1), float for continuous environment vari-
ables (Form 2)). When (character) string environment variables (Form 3) and
environment variables with data bytes (Form 4 and 5) are used, the most current
value is written to a buffer, which is given with the function call.
Parameter
Environment variable name, buffer for the return value (Forms 3, 4 and 5) and,
when using Form 5, the offset for the first data byte to be copied.
Return:
Forms 1 and 2 : most current value of the environment variable.
Forms 3, 4 and 5: number of bytes copied into the buffer.
Example:
int val;
float fval;
char cBuf[25];
byte bBuf[64];
long copiedBytes;
Syntax
putValue(EnvVarName, int val); // Form 1
putValue(EnvVarName, float val); // Form 2
putValue(EnvVarName, char val[]); // Form 3
putValue(EnvVarName, byte val[]); // Form 4
putValue(EnvVarName, byte val[], long vSize); // Form 5
Function:
Allocates the value val to the environment variable with the identifier EnvVar-
Name. Integers are stored in discrete environment variables (Form 1), floating
Parameter:
Environment variable name, new value of the environment variable (Forms 1 and
2), or buffer with the new data (Forms 3, 4 and 5). When Form 5 is used, the
number of bytes to be copied.
Example:
byte dataBuf[64];
// Assign the value 0 to the environment variable Switch
putValue(Switch,0);
// Assign the value 22.5 to the environment variable
Temperature
putValue(Temperature, 22.5);
// Copy the string “Master” into the environment
variable NodeName
putValue(NodeName, "Master");
// Copy 64 bytes of the contents of the buffer into the
environment variable DiagData
putValue(DiagData, dataBuf, 64);
callAllOnEnvVar()
Function:
Executes the on envVar ... event procedures for all environment variables.
This may be necessary at the measurement start to initialize environment vari-
ables, set timers that are activated when environment variable values change, or
to send messages on the bus with start values of environment variables.
Example:
on start {
write("Traffic light module started");
word swapWord(word x)
int swapInt(int x)
dword swapDWord(dword x)
long swapLong(long x)
Function:
Interchanges the bytes of the parameter
Parameters:
Value whose bytes are to be swapped.
Return:
Value with bytes interchanged.
Example:
bigEndian = swapInt(1234); /* Generation of constant
1234 for Motorola processor */
double sin(double x)
Function:
Calculates the sine.
Parameters:
Value in radians whose sine is to be calculated.
Example:
double cos(double x)
Function:
Calculates the cosine.
Parameters:
Value in radians whose cosine is to be calculated.
Example:
double sqrt(double x)
Function:
Calculates the square root
Parameters:
Value whose square root is to be calculated.
Example:
double exp(double x)
Function:
Calculates an exponential function
Parameters:
Exponent to base e
Example:
long abs(long x)
double abs(double x)
Function
Returns the absolute value
Parameters:
Value whose absolute value is to be returned.
Return:
Absolute value of x.
dword random(dword x)
Function:
Calculates a random number between 0 and x
Parameters:
Maximum value that the function should return
Example:
Function:
Opens the file filename, finds the section section and writes the value value to
the variable entry. If entry already exists, the old value is overwritten. The result
of the function is the number of characters written, or 0 in case of error.
Function:
Analogous to the function fileWriteString(), but instead of writing a text, it
writes a Long variable to the file. If the function result is 0, an error has occurred;
otherwise the function was executed successfully.
Example:
fileWriteInt("DeviceData","DeviceAddr",2, "TEST.INI");
Function:
Analogous to the function fileWriteString(), but instead of writing a text it
writes a float variable to the file.
Function:
Finds the variable entry in the section section of the file filename. Its contents
(value) are written to the buffer buffer. Its length must be passed correctly in
bufferlen. If the file or entry is not found, the default value def is copied to buffer.
Function:
Finds the variable entry in the section section of the file filename. If its value is
numeric, this number is returned as the function result. If the file is not found or
entry is not found, or if entry does not contain a valid number, the default value
def is returned as the function result.
Example:
myAddress=fileReadInt(
"DeviceData","DeviceAddr",0,"TEST.INI");
If this call is made according to the notation given in the example for
fileWriteInt(), the variable myAddr is assigned the value 2. If the entry
DeviceAddr does not exist in the file TEST.INI, the default value 0 is assigned.
Function:
Analogous to the function fileReadInt() for floating point numbers.
Function:
Searches for the variable entry in the section section of the file filename. Its con-
tents are interpreted as a list of byte values. The numbering format is decimal or
- if it has the prefix 0x - hexadecimal. The numbers are delimited by a blank
character, tab, comma, semi-colon or slash. The buffer is filled with up to buffer-
len bytes.
Return:
Number of characters written.
Example:
File TEST.INI:
[DATA]
FIELD=1,2,3,0x20,100
int len;
char buf[20];
len = fileReadArray(
"DATA","FIELD",buf,elCount(buf),"TEST.INI");
The result len is 5. The array buf is filled with the values 1, 2, 3, 32, 100.
Function:
This function opens the file with the name fileName for read access.
Return:
The return value is the file handle, which must be passed as a parameter for
read operations. If an error occurs, the return value is an error code <= 0.
Function:
This function closes the file specified by the handle file. All buffers used by the
system are cleared upon closing.
Return:
If successful the function returns the value 0. If an error occurs a nonzero error
code is returned.
Function:
The function reads at most bufferSize characters from the file identified by the
handle file to the array buffer. In doing so, the position pointer is incremented by
the number of characters successfully written. If an error occurs the value of the
position pointer will be indeterminate.
Return:
The return value contains the number of characters successfully read. It may be
smaller than bufferSize if an error occurred or the end-of-file was reached.
Function:
The function reads at most bufferSize-1 characters from the file specified by the
handle file to the array buffer. After an end-of-line or end-of-file character, no fur-
ther characters are read. The end-of-line character is not copied to buffer.
The function seqFileGetLine() does not terminate the character string with
‘\0’; seqFileGetLineSZ() terminates the character string with ‘\0’.
Return:
The return value contains the number of successfully read characters. It is nega-
tive if an error occurs.
Note: The CAPL function seqFileGetLineSZ() corresponds to the function
fgets() of the standard C library.
Function:
The function resets the file specified by the handle file back to the beginning.
Return:
If successful the function returns the value zero. If an error occurs a nonzero er-
ror code is returned.
Example
In the sample CAPL program the test file TEST.DAT is opened at measurement
start, and after pressing the ‘a’ key it is copied byte-by-byte to message 100 and
is transmitted on the bus in blocks of 8 bytes at 10 ms intervals. Pressing the ‘r’
key causes the file to be reset to its beginning, and it is re-transmitted on the
bus.
variables {
message 100 msg = {DLC=8};
char filename[50] = "test.dat";
long handle;
msTimer ReadNextBlock;
}
on start {
// /Open data file on start of measurement
handle = seqFileLoad(filename);
if (handle <= 0) {
write ("Error opening file");
write("Error code = %d", handle); stop();
}
else {
write ("File %s opened",filename);
write ("Press key a to start reading the file");
}
}
on stopMeasurement {
// Close data file on stop of measurement
if (handle > 0) {
if (seqFileClose(handle)==0) write("closed");
else write ("error closing file");
}
}
Function:
This function converts the string s to a LONG number. The numbering system is
decimal. If the string begins with 0x, base 16 is used. Leading blank characters
are skipped over when reading.
Function:
The number val is converted to a string s, whereby base indicates the numbering
system base between 2 and 36. The string s must be large enough to accept the
converted number!
Function:
This function corresponds to the C function sprintf(). Additionally, the pa-
rameter len indicates the maximum length of the array dest. The total length of
the resulting string must not exceed 100!
The function result is the number of characters written. The format string has the
same meaning as for the function write() and is described there.
Function:
The function result is the length of the string s.
Function:
This function appends src to dest. The parameter len indicates the maximum
length of src and dest. This function assures a terminating ‘\0’. Consequently, a
maximum of len-1 characters are copied.
Function:
This function copies src to dest. The parameter len indicates the maximum
length of src and dest. The function assures a terminating ‘\0’. Consequently, a
maximum of len-1 characters are copied.
Function:
This function compares s1 with s2 for a maximum of len characters. If they are
identical the function result is 0. If s1 is less than s2 the result is -1, else it is +1.
long elCount(...)
Function:
Determines the number of elements in an array.
Parameters:
Array of any desired type
Return:
Number of elements
Example:
Function:
Initiates a run-time error. Outputs an error message in the Write window, giving
the error number and the passed number, and it then terminates the measure-
ment.
Parameters:
Numbers which are represented as instructions in CANalyzer. The values less
than 1000 are reserved for internal purposes. The second parameter is reserved
for future expansions.
Example
fileName()
Function:
Output of CAPL program name in the Write window. Helpful for debugging pur-
poses.
Example:
fileName();
3.8 Examples
To practice running the following example it is best if you always begin with a new,
empty configuration (Menu item: File|New configuration). A CAPL program always
runs in a CAPL program block, which you can insert at any of the hotspots in the
measurement setup .
Note: CAPL programs which are to transmit messages must always be inserted in
the transmit branch of CANalyzer's measurement setup. The graphics menu indeed
allows you to insert CAPL programs directly before the analysis blocks in the meas-
urement setup. However, since the data flow in the measurement setup is directed
from left to right, messages that are transmitted from there only reach the analysis
blocks to the right and do not reach the CAN bus. Therefore, you should only insert
CAPL programs intended for analysis here.
Then, in the popup menu assign a file name to the CAPL program blocks you have
inserted in the measurement setup , e.g. EXAMPLE1.CAN. From the Edit menu open
the CAPL Browser (cf. section 3.3), with which you can enter and compile the sam-
ple programs. After compiling you can immediately test the programs by starting the
measurement.
Make sure that you parameterize the CAN controllers properly before the measure-
ment start. In each case you must configure the bus parameters correctly. To follow
along and practice running the sample programs you should connect the two CAN
controllers on your card to one another using the supplied cable ("short circuiting").
This gives you a real CAN bus with two stations that you can control entirely from
CANalyzer. In this case, remember to set the bus parameters so that they are exactly
the same for both controllers.
Task statement:
Messages with the identifier 180 should be cyclically transmitted every 100
msec. The first two data bytes should be interpreted as 16-bit variables, and they
should be incremented by 10 after each transmission.
Solution:
First a global variable is declared with the name sendTimer and type msTimer
(Timer based on milliseconds). This is done in Browser's upper right pane:
variables {
msTimer sendTimer; /* Timer for period. Send */
}
To activate the timer generated in this way, it must be set in the start event pro-
cedure. To input the start event procedure select the event type System in
Browser tree. In the popup menu of the procedures text editor you then select a
new Start event procedure which is called at the measurement start.
The only action at the measurement start is to set sendTimer to 100 msec.
on start {
setTimer(sendTimer,100); /* Schedule timer */
}
To define what should occur when the timer elapses you now set up a timer
event procedure. To do this, select the event type Timer in the Browser tree,
and create a procedure of this type. As a result, a template for a timer event pro-
cedure appears in the Procedures Text Editor, in which you enter the name of
the particular timer in front of the opening procedure bracket, in this case
sendTimer.
Within the procedure brackets, first a local variable is declared: sendMsg of the
type message with identifier 180. The variable sendMsg is initialized with data
length 2 and data contents 0.
The first instruction in the event procedure is to reset the timer sendTimer to
100 msec. This causes the event procedure to be run cyclically every 100 msec.
Then the output() function outputs the message sendMsg at the program
block's output, and it is sent on the bus. After transmission the content of the first
data word is increased by 10.
After compiling this event procedure the name sendMsg appears in the proce-
dure window. It can be selected directly for further handling.
on timer sendTimer {
The program is started from CANalyzer's main menu item Start|Start. The trans-
mitted messages can be observed in the Trace and Statistics windows. It is
transmitted as long as desired until the measurement is ended by pressing the
<ESC> key.
Therefore, the on timer procedure for solving this task could be written as fol-
lows:
on timer sendTimer {
setTimer(sendTimer,100);
output(sendMsg);
// Increment counter by 10
sendMsg.Counter = sendMsg.Counter + 10;
}
Please note that the type definition for the message to be sent includes both the
key word message and the message name StateInfo. Only afterwards does
the variable name sendMsg occur. To react to messages in event procedures
you use the symbolic message name from the database and no variable names.
For example, you would write on message StateInfo {} to react to the oc-
currence of the message with identifier 180.
Solution:
You should set up a key event procedure to define what should occur in re-
sponse to pressing the spacebar. The name of a key event procedure is either
the corresponding ASCII character in single quotation marks or a symbolic name
(cf. section 3.5.4). In the Browser tree select the event type Keyboard. In the
template for the new key event procedure, replace the text <newKey> by the
spacebar character ' '.
Within the procedure brackets, first the local variable spaceMsg is declared.
This message is transmitted when the procedure is run through. The 3rd data
byte is used directly as the counter for transmission frequency.
output(spaceMsg); /* Send */
spaceMsg.byte(2) = spaceMsg.byte(2)++; /*Count along*/
Solution:
You would set up an appropriate message event procedure to define what
should occur when a specific message is received. This involves creating an
event procedure of the type on message. In the procedure template you would
replace the text <newMessage> by the identifier to which the reaction should
take place: 120.
Within the procedure brackets, first the local variable responseMsg is declared.
When the procedure is run through, receipt of the message 120 is reported on
the screen via the write() function. Afterwards, the reply message is transmit-
ted.
on message 120 {
Since this query is not used, the event procedure reacts identically to received
and transmitted messages.
It would only be possible to test this event procedure if a message with identifier
120 were actually received (or transmitted). This can be generated by a separate
bus station or by CANalyzer itself. A quick test might be, for example, to select
the identifier 210 instead of identifier 120 - as programmed above - which is sent
when the spacebar is pressed.
Task statement:
A gateway should be programmed between two buses, which essentially lets all
messages pass unhindered in both directions. However, when the message with
identifier 34 is transferred from Bus 1 to Bus 2 it should be "falsified" by setting
byte 4 to 0.
Solution:
A node is inserted in CANalyzer's transmit branch, to which the CAPL program
described below is assigned.
Message 34 is modified as follows in the transfer from Bus 1 to Bus 2:
on message CAN1.* {
// Entry of '*' identifies all messages
// that are not processed in any other
// procedure.
message CAN2.* sendMsg;
if (this.dir!=RX) return;
sendMsg = this;
output(sendMsg);
}
on message CAN2.* {
message CAN1.* sendMsg;
if(this.dir!=RX) return;
sendMsg = this;
output (sendMsg);
}
Task statement:
The user is observing the system on the screen and would like initiate triggering
by a key press ('t' key).
Solution:
In parameterizing the logging block, CAPL is selected as the Trigger type. As a
result, data logging will be initiated by the CAPL function trigger(). Please
note that the function only triggers logging if it is located before the logging
branch or is in CANalyzer's transmit branch.
The CAPL program consists of a single event procedure for the 't' key, in which
triggering is initiated.
Naturally, there are also CAPL programs for triggering which look significantly
more complicated. For example, by adding a message event procedure trigger-
ing could also be initiated when a certain message with certain data contents is
received.
Since global variables (Flags) can be introduced, you can also formulate trigger
conditions that are a function of a combination of different events.
Task statement:
Available on CAN2 from an analog I/O module is the scaled engine speed infor-
mation N. This should be used to calculate a zero moment signal NM which is to
be output cyclically on CAN1.
Solution:
The value of the N signal is acquired, and is converted to NM which is saved
temporarily in a variable nullMoment. This value is accessed in the timer func-
tion, and the cyclic output is generated:
variables {
int nullMoment = 0; /* Calculated value */
int c1 = 10, c2 = 20; /* Conversion constants */
msTimer t1; /* Timer */
}
on start {
setTimer(t1,100); /* Setting of timer */
}
on message CAN2.ioData {
nullMoment=this.N*c1+c2; /* Linear transformation */
}
on timer t1 {
message CAN1.EngineData m; /* Data carrier */
setTimer(t1,100); /* Setting of timers */
m.NM = nullMoment; /* Entry of active
value */
output(m); /* Send out on CAN1 */
}
Task expansion:
Calculation of the zero moment should be table-based.
Solution:
A table is created with result values. The table is accessed by means of indices,
whereby the value range is checked.
variables {
int nullMoment = 0; /* Calculated value */
int values[20] = { /* Table */
0,0,3,8,15,24,35,48,63,80,
99,118,140,164,190,218,220,
218,210,195
}
msTimer t1; /* Timer */
}
on message CAN2.ioData {
int index; /* Auxiliary variable */
index = this.N; /* Value as index */
if (index < 0) index = 0; /* Range check */
else if (index>=20) index = 19;
nullMoment = values[index]; /* Conversion
with table */
}
Note: Please note that in this solution information on the CAN protocol layer flows
into the CAPL program: In this recommended solution the CAN controller numbers
are part of the CAPL program. If the user wanted to connect to the card's CAN con-
trollers in another way, the program code would have to be modified. Section 4.3.1
describes how you could avoid these undesired dependencies of the CAPL applica-
tion on the concrete configuration.
4 Special Topics
Database CANdb-Editor
*.dbc candb32.exe
parbrow.ini
Start options for CANalyzer and Browser are provided in the linked INI files. If you
are starting Browser from CANalyzer's measurement setup, a temporary file
PARBROW.INI is automatically generated with the proper start options and is passed
to Browser.
plan. During a measurement two program modules work closely together to this pur-
pose: First the CANalyzer real-time library (CANRT.DLL) retrieves the information
arriving at the card, provides them with a time stamp and shifts them to a ring buffer.
In the course of a measurement the PC-card registers CAN messages on the bus
and passes them through the simulation setup to the measurement setup, and from
there to the specified paths in the data flow plan and on to the evaluation and analy-
sis blocks at the far right of the plan. During a measurement two program modules
work closely together to this purpose: First the CANalyzer real-time library
(CANRT.DLL) retrieves the information arriving at the card, provides them with a time
stamp and shifts them to a ring buffer.
In a second step these data are read out by the actual main program (CANW32.EXE)
and are evaluated in the function blocks on the right-hand side of the data flow plan.
Main Buffer
CAPL Transmit Measurement
Branch
ca. 1500 Msg (16 bit)
ca. 15000 Msg (32 bit)
Interrupt DPRAM
CAN
PC Board
CAN File
You can influence the data flow in both program modules by inserting function blocks
in the measurement setup. In this context the real-time module is comprised of the
PC-card block, all function blocks between the card block and the transmit branch,
and all blocks in the transmit branch itself. All other function blocks are used to con-
figure the data flow in the evaluation branch.
If you insert blocks in the real-time library, i.e. CANalyzer's transmit branch/, you
should be make sure that they do not demand too much computing time, so that sys-
tem reaction times are not lengthened. Moreover, in CAPL programs you may only
access files from here using special precautionary measures (cf. section 3.7.10).
You can view the fill level during the measurement in the left corner of the status bar.
If the ratio between arriving and processed events is balanced, the indicator has a
green color. However, if it appears in red, significantly more events are arriving than
can be processed at the given time. This is a clear indication that the system is over-
loaded. If the queue fill level reaches an alarming limit, the system attempts to relieve
the load by selectively deactivating individual evaluation windows. If desired, you can
have the queue's state displayed with the help of the entry ShowMainQueue=0 in
the [System] section of the CAN.INI file.
You can also have the fill level displayed in the Write window. To do this, set a mini-
mum value of WriteLevel = 3 in the [Environment] section of the CAN.INI
file. Then, when the ring buffer overflows the Write window shows the report "Load
transition: NORMAL->DATA LOST" and informs you of the data loss. After the
overload situation has ended (e.g. after a brief burst on the bus) you are similarly
informed as soon as a normal situation has been restored. You can recognize this in
the Write window by the report "Load transition: QUEUE HIGH ->
NORMAL".
For testing purposes you can provoke overload situations yourself by taking hold of
the title bar of the main window with the mouse or by moving the window on the
screen. This will interrupt the main program's data display until you release the title
bar again. The work of the real-time library, however, remains unaffected by these
actions. If messages are being registered on the bus, the ring buffer will be filled
without the data being able to be processed by the main program, and as a result the
queue will overrun. As soon as you release the title bar you can observe the effects
of this overrun in the individual windows.
Trace Window
In the Trace window choose the output mode Fixed position for cyclic update. As
a result, the window contents are no longer updated with each new arriving mes-
sage, rather they are only updated cyclically. If necessary select a longer update
time.
Data Window
If you have configured many signals in the Data window, you should choose the
cyclic refresh mode here (Configure Timer entry in the Data window's popup
menu) and enter a cycle time of maximum 500 milliseconds. The window is then
only updated cyclically which saves on computing resources.
Graphic Window
If you have configured many signals in the Graphic window, you should choose a
relatively large user-defined refresh (200 ms to 2 s) in the Measurement Setup
Dialog (Options item in the popup menu) . This defines how often the graphic
window display should be updated. Small values result in a fluid representation
of the signal response, but they place high demands on computer resources,
and with slower computers this might lead to performance problems. High val-
ues, on the other hand, reduce computing demands but lead to a more disturbed
and delayed display of the signal response.
Statistics Window
Deactivate the statistics report in the Statistics window's popup menu to save on
computing power. Furthermore, the averaging time can be selected in the con-
figuration dialog of the Statistics block. Short time intervals place high demands
on computer resources and might result in severely oscillating lines in the win-
dow. Very long averaging times make the display slower, but also less comput-
ing intensive.
If you insert blocks in the real-time library, i.e. in CANalyzer's transmit branch, you
should ensure that they do not demand too much computing time, so that they do not
increase system reaction times. Furthermore, you may only access files in CAPL
programs if you observe special preventive measures (cf. section 3.7.10)
On the other hand, it may be advisable at high bus loading to perform a data reduc-
tion as early as in the real-time library to relieve loading in the evaluation branches of
CANalyzer.
It is not possible to predict an optimal configuration of the measurement setup for all
situations. Cyclic updating indeed saves computing time, but also leads to poorer
representation of the information. Under some circumstances it may be advisable to
completely disconnect analysis branches that are not needed in the measurement
setup (Insert Break item in the hot-spot's popup menu) or reduce the volume of data
at the input to the measurement setup using filter functions. Moreover, you might
also try to insert individual CAPL programs between the real-time library and the
evaluation branches and observe the behavior of the program during another meas-
urement run.
To filter out certain messages from the measurement setup, pass filters and blocking
filters are provided as insertable function blocks. Furthermore, the supported PC
cards with acceptance filtering (Messages item in the popup menu of the card icon in
the measurement setup) also offer you the option of filtering out certain messages in
hardware, thereby relieving both the real-time library and the main Windows program
of the need to evaluate unnecessary information.
CANalyzer supports the simultaneous use of multiple databases. You can configure
the databases that you would like to associate with CANalyzer using the menu com-
mand File|Associate database. Afterwards you can use the symbolic names for mes-
sages and signals from all databases in all function blocks and in CAPL. To do this,
you would simply enter the symbolic name in the appropriate input box. There is a
list of all symbolic names in the signal selection dialogs which you can open by acti-
vating the small buttons next to the individual input boxes. You would select the de-
sired symbolic names there.
If you are using more than one database, the messages in the databases that follow
the first database are qualified with the database name, i.e. the message name is
preceded by the database name followed by two colons. However, you will only need
to use these qualified names to resolve ambiguities. As long as the symbolic names
are unique among all databases, you can forego qualification of symbolic names in
all function blocks and when editing CAPL programs.
In this consistency check, the symbolic names of all CAN messages used in the
measurement and simulation setups are compared to names in the database. If the
message name has been changed in the database, an automatic adaptation is made
to this name, and an appropriate message appears on the screen. If CANalyzer
could find neither the name nor the message ID in the database, the user receives
an error message. In this case the measurement cannot be started until the particu-
lar message is removed from the configuration.
In the Channel Definition Dialog you can choose whether or not a consistency check
should be performed after configuration. The consistency check covers database
assignments and the configuration of all function blocks with the exception of CAPL
blocks. The check monitors whether invalid channels are referenced. If this is the
case an inconsistency is reported. These reports can be output to the Write window
if desired.
With CAPL blocks a determination of whether all referenced channels are valid is not
made until compilation. A warning is output if any channels are invalid. Therefore, it
is advisable to recompile all nodes after each new definition of channels.
If you use undefined channels, CANalyzer behaves as follows in Online mode:
• Channel configuration does not cause any filtering of messages in the data flow
plan.
• When receiving on controllers not assigned to a defined channel, the received
messages are passed through the measurement setup.
• When transmitting from a Generator block or Replay block on the right of the
transmit branch to an undefined channel, the transmit request is similarly passed
through.
• An error is reported in the Write window for a sender in the transmit branch as
soon as the transmit request is given to an undefined channel. The message is
not transmitted.
• CAPL blocks do not transmit messages to which an undefined channel is as-
signed.
unit uniquely. The server passes this to the client in the course of the transaction. An
item can be an integer, a character string or a bitmap. You can use the items
ConfigurationRequest and DynamicStateRequest of the System topic to query infor-
mation regarding the system's current state.
Value Meaning
1 Configuration has a name
2 Configuration modified/not saved yet
4 Mode is Online
Value Meaning
0 Measurement is not running
4 Measurement is running
A data request to the item Formats returns the supported data formats. At this time
the only format supported is TEXT. This refers to the clipboard format CF_TEXT ac-
cording to DDEML convention.
The DDE Execute transaction initiates execution of a CANalyzer command via DDE.
At this time there is still no genuine return to indicate the success or result of the
command. Nevertheless, some effects of the command can be queried by the items
ConfigurationRequest and DynamicStateRequest.
This command string consists of a command token, and if necessary command pa-
rameters that are separated by commas and may be optionally enclosed in round
brackets. String parameters may not be placed in quotation marks. The command
string may be enclosed in square brackets (DDEML convention). A single Execute
transaction can only transmit one command, i.e. scripts or command sequences are
not permitted. The command tokens are not sensitive to upper/lower case and are
delimited by blank characters.
The following commands are supported:
Command Meaning Remarks
LoadCfg <name> Loads the configuration If <name> is empty the File Selection
<name> dialog is opened.
SaveCfg <name> Saves the configuration If <name> is empty the File Selection
under the name <name> dialog is opened.
Examples of Execute
The following lines show some examples of command strings that can be transmitted
with the Execute transaction:
LoadCfg c:\canwin\demo_cl\motbus.cfg
LoadCfg (c:\canwin\demo_cl\motbus.cfg)
[LoadCfg (c:\canwin\demo_cl\motbus.cfg)]
LoadCfg
Start
Stop
desktop and in program groups which - when double clicked - behave like the file
itself.
Note: Since CANalyzer and CANoe use the same extension (CFG) for their configu-
rations, at any given time on a single system only one of the two programs can be
configured as described here. However, another action (e.g. Open CANoe) could be
added for the file type CFG to open the second program.
4.5.5 COM-Server
A COM-Server is implemented in addition to the DDE-services. It helps the program
to be gated or controlled by other applications. Besides accessing configuration-
specific data it is also possible to control the measurement. You can also call CAPL
functions, read signal values, and both read and write access environment variables.
Control can either be realized by COM-ready script environments (ActiveX Scripting:
VBScript, JScript, Perl, ...) or by stand-alone applications, which can be written with
RAD development environments (Visual Basic, Delphi, ...) or in C/C++.
Please see the Online-Help for a more detailed description of the COM-Server.
5 Appendix
5.3 Troubleshooting
See section 5.4 for a list of error messages occurring during initialization or during a
measurement. In this section tips are offered for handling problems of a general na-
ture.
CANalyzer will not start
CFG file destroyed? Often it is helpful to delete the active configuration file
MYCONFIG.CFG. First, the file should be backed up under a different name so
that its contents are not lost. After the problem has been cleared up it can be re-
named back to MYCONFIG.CFG.
CANalyzer runs too slowly
Power managers, which are particularly common on notebook computers, may not
be installed for CANalyzer/ operation. Among other things, the power manager de-
prives the application of CPU for long periods of time. Therefore, transmit times are
incorrect and messages can be lost when a power manager is installed. To remove
the power manager from your system, please compare the instructions in the hard-
ware installation guide.
For less powerful computers it may also be advisable to reduce the resolution of
the system clock. The time stamps for messages may then be less accurate, but
fewer demands are placed on computer CPU. To do this, enter the following line
in section [PCBOARD] of the CAN.INI file:
Timerrate = 200
or under some circumstances even the value:
Timerrate = 400
These correspond to time resolutions of 2 or 4 milliseconds, respectively.
Timeout ...
With error messages of this type, CANalyzer cannot establish a connection to the
CAN hardware. Check the installation of the CAN card. You will find hints for trouble-
shooting in the hardware installation guide.
Above all, notebook PCs frequently use a power manager. This must be deacti-
vated!
No partner on the bus? If the bus is only connected to one of the two CAN con-
trollers, and there are no other bus nodes, the controller does not receive any
acknowledge for transmission attempts.
Baud rate and output control set? The controller register can be programmed by
the popup menu of the CAN-card icon. See section 2.2 for a more detailed ex-
planation.
Error message:
An error has occurred in ...
For further information please report the
LINE and FILE to our Hotline
At the current level of technology it is impossible to develop completely error-free
programs that are non-trivial. Unfortunately, this is also true of CANalyzer. To better
localize and correct system errors that occur very seldom, CANalyzer has diagnostic
mechanisms that report these errors. Please be sure to write down the exact text of
the error message. With this information our telephone Customer Support can then
help you to correct the problem more quickly.
rather the associated symbolic names from the database. If you use another da-
tabase for the playback, the symbolic names might not be interpreted - or might
be misinterpreted - when the replay file is read-in.
Load transition:
The ring buffer between the real-time library and the CANalzyer main program
has a fill level indicator. If the buffer is full or is overflowing, an appropriate mes-
sage appears (NORMAL->QUEUE HIGH bzw. NORMAL->DATA LOST) in the
Write window. If the load is then reduced (possibly after a burst of messages),
you are also informed of this by the message QUEUE HIGH -> NORMAL.
Remedy: Terminate measurement and restart. If this does not help, the reset
button can be pressed for some cards. Otherwise, the PC should be rebooted.
6 Index
Beep · 3-44
binary · 2-65
! Binary · 2-65
Bit time · 2-12
Bit timimg · 2-12
! Load symbol · 4-3 Bit timing · 2-12
Blocking filter · 4-6
Branches · 1-3, 2-4
< Break · 2-67, 2-68, 2-69
Break condition · 2-68
<F10> key · 1-20 Breakpoint · 2-68
Browser tree · 3-18, 3-20
BTL cycles · 2-10, 2-12
BTR programming · 3-42
7 Burst · 2-56
Bus driver box · 5-5
72005 · 2-11, 2-13 Bus load · 2-5, 2-9, 2-37, 2-42, 4-3
Bus load measurement · 2-43
Bus loading · 4-3, 4-6
8 Bus parameter · 3-66
Bus parameters · 2-10
82527 · 2-11, 2-13 Bus registers · 2-10
82C200 · 2-11, 2-13 Bus statistics · 2-14, 2-42, 2-43, 2-66
Bus statistics display · 4-3
Bus statistics information · 2-43, 2-66
Bus Timing Register · 2-11
A BUSOFF · 3-27, 3-39
Button · 1-21
abs() · 3-17, 3-58
Absolute value · 3-58
Acceptance code · 2-13 C
Acceptance filtering · 2-13, 2-14, 4-6
Acceptance filters · 2-10 callAllOnEnvVar() · 3-56
Acceptance mask · 2-13, 2-14 CAN card · 2-9
Acknowledge · 2-12 CAN channel · 4-9
Activity indicator · 2-28 CAN.INI · 2-7, 2-44, 2-65, 2-68, 3-2, 3-36, 4-4
Advise loop · 4-11 CAN-AC2 · 5-2
Ambiguities · 2-26, 3-16, 3-22 CANalyzer without card · 2-18
Analysis blocks · 3-66, 4-5 CANcard · 2-9, 5-2
Analysis branch · 4-6 CANcardX · 2-9, 3-12
Animate · 2-25, 2-68, 2-69
cancelTimer() · 3-11, 3-17, 3-50
Animation factor · 2-18
CANdb++ · 1-23, 2-19, 4-1
Array · 3-21, 3-38, 3-61, 3-64, 3-65
canOffline() · 3-48
Array size determination · 3-17 canOnline() · 3-48
ASCII · 2-65, 3-69, 5-2 CAPL · 2-4, 2-62, 3-19, 5-2, 5-9, 5-11
Assertion · 5-4 CAPL Browser · 4-1
Attribute · 3-14, 3-15 CAPL program · 2-44, 3-2, 3-9, 3-23, 3-24, 3-71, 3-
Attribute name · 3-14 72
Attribute value · 3-14, 3-15 CAPL Program · 2-45
Averaging time · 2-40, 2-43, 4-5 CAPL_DLL_INFO_LIST · 3-37
Axis options · 2-31, 2-33 Card clock · 2-16
Card driver · 2-15, 2-17
Channel · 2-9
B Channel definition · 2-9, 4-9, 4-10
Check box · 1-21
Backus-Naur form · 3-23 Chip allocation · 2-9, 4-9
Bar-type display · 2-28 CIF files · 2-8
Basic image · 2-40 Clipboard · 2-43, 3-20
Basic-CAN controller · 2-9 Colors in the Graphics window · 2-37
Baud rate · 2-43, 3-39 Comment · 2-45, 3-22, 3-46
Baudrate · 2-10, 2-11 Comment box · 1-21
Grammar · 3-23
Grid · 2-36
M
Main memory · 2-63
Measurement configuration · 1-20
H Measurement control · 3-17
Measurement marker · 2-34
Hardware configuration · 4-9 Measurement point · 2-32
Help · 1-23, 2-14, 3-27 Measurement setup · 2-4, 2-15, 2-44, 2-48, 2-49,
hexadecimal · 2-13, 3-61 2-58, 4-2
Hexadecimal · 3-14 Measurement start · 2-6, 2-9, 2-33, 2-66, 3-4, 3-7,
Hexadecimal representation · 3-44
High load · 2-57 3-18, 3-66, 3-67
High-load operation · 4-3 Measurement value acquisition · 2-32
Hotspots · 1-4, 2-16 Memory protection violations · 3-5
Menu operation · 1-20
Message attribute · 2-16, 3-15, 3-34
Message declaration · 3-6
I Message display · 4-3
Message Explorer · 2-19, 2-20, 3-22
IEEE · 3-5 Message rate · 2-40
Import of configuration descriptions · 2-8 Message variable · 3-8
Incrementer · 2-57 Messages window · 3-20
Infinite loop · 2-17 Mode signal · 2-52, 2-57
INI file · 2-7, 2-44, 2-65, 2-68, 3-36, 4-4, 5-3 Mode-dependent signal · 2-52
INI-Datei · 3-2 Motorola · 3-13, 3-57
Initialization of environment variables · 3-56 Moving blocks · 2-5
inport() · 3-17, 3-41 msTimer · 3-4, 3-5, 3-11, 3-24, 3-49, 3-50, 3-
inportLPT() · 3-41 67, 3-72, 3-73
Input box · 1-21, 2-71 Multiplex message · 2-52, 2-57
Integer value · 3-15 Multisignal mode · 2-29, 2-33, 2-34
Integer values · 3-15
Integer variable · 3-18, 3-19
Intel · 3-57
Interactive generator block · 2-54 N
Interrupt · 5-10
Network nodes · 2-4
Nodes · 2-4
Nonterminal · 3-23
K Notebook · 5-3
Numbering system · 2-8, 3-64
Key codes · 3-10
Keyboard · 3-69
Keyboard control · 2-58
Keyboard event · 3-9 O
Keyboard handling · 3-10
OCR · 3-40, 3-42
Offline mode · 2-67, 2-68, 2-69, 2-70
on key · 3-69
L on message · 3-70, 3-71
Online mode · 2-5, 2-6, 2-9, 2-15, 2-16, 2-59, 2-69
Language elements · 3-23 Operating instructions · 1-19
Layout · 2-4, 2-43 Operating mode · 1-21, 2-18
Line type · 2-32 Optimization · 2-28, 2-37, 4-4
Load operation · 4-3, 4-4 Trace window · 2-24
Load situation · 4-3 Options button · 1-21
Load transition · 4-4, 5-6 outport() · 3-17, 3-40
Log file · 2-48
outportLPT() · 3-40
converting · 2-72
Output mode · 2-32, 4-3, 4-5
exporting · 2-72
file icon · 1-17 output() · 2-45, 3-1, 3-17, 3-38, 3-67, 3-68, 3-69,
Log file name · 3-46 3-70, 3-71
Logging output(this) · 2-45, 3-9, 3-10, 3-13
time period of · 2-62 Overload situation · 4-3, 4-4
Logging export · 2-72 Overload symbol · 2-67
Long-duration measurement · 2-64
Low-speed driver · 5-7
Symbol selection dialog · 3-22 Trigger condition · 2-49, 2-50, 2-51, 2-55, 2-56, 2-
Symbolic database · 3-72 59, 2-63, 2-70, 3-72
Symbolic databases · 2-18 Trigger mode · 2-60
Symbolic triggering · 2-71 Trigger time point · 2-56
Synchronization edge · 2-12 Trigger type · 2-62, 3-72
Synchronization jump width · 2-11, 2-12 trigger() · 3-2, 3-17, 3-46, 3-72
Syntax · 3-23, 3-29, 3-30 Triggerblock · 2-67
sysExit() · 3-45 Triggering · 2-63, 3-2, 3-46, 3-71, 3-72
sysMinimize() · 3-45 Triggering of logging · 3-46
System directory · 2-1 Trigonometry · 3-57, 3-58
System loading · 2-28 Tx attribute · 2-17, 2-40
System messages · 2-43 Tx error counter · 2-42
System time · 3-52, 3-53, 3-54 TXDATA · 3-31, 3-34
TXREMOTE · 3-31, 3-34
TXREQUEST · 2-14, 3-7, 3-31, 3-33, 3-34
T TXREQUESTDATA · 3-31, 3-34
TXREQUESTREMOTE · 3-31, 3-34
Terminal · 3-23 TxRq attribute · 2-17
Text editor · 3-20
this · 3-10, 3-11, 3-12, 3-13, 3-31, 3-34
Time base · 2-69 U
Time basis · 2-69
Time management · 3-17, 3-49, 3-50 Undo function · 2-10
Time resolution · 5-3
Time stamp · 2-16, 2-23
Time window · 2-61, 2-63
timeDiff() · 3-52
V
timeNow() · 3-17, 3-52
Value range check · 3-5
Timeout · 5-3, 5-10, 5-11 Value table · 2-52
Timer · 3-1, 3-4, 3-24, 3-28, 3-34, 3-67 VAN · 3-42, 3-43
ToOffline · 4-13 Virtual channel · 2-9, 4-9
ToOfflineCopy · 4-13
Toolbar · 2-31, 3-19, 3-20, 3-21
ToOnline · 4-13 W
ToOnlineCopy · 4-13
Topic name · 4-11
Topic System · 4-12 Warning Limit · 3-7, 3-12
Trace Watch functionality · 2-24 Wildcard · 3-25
Trace Watch window · 2-24 WIN.INI · 3-44
Trace window · 2-20 Window control · 2-6
Configuration of columns · 2-23 Window layout · 2-43, 2-44
Optimization · 2-24 Windows timer · 5-6
Transmission of messages · 2-54 Working directory · 2-7
Transmission time · 2-18 write() · 2-43, 3-11, 3-17, 3-43, 3-64, 3-70
Transmit block · 2-15
writeToLog() · 3-17, 3-46
Transmit branch · 2-15, 3-71
Transmit error counter · 3-33 writeToLogEx() · 3-17, 3-46
Transmit list · 2-55, 2-56
Trapezoidal function · 2-53
trigger · 3-2 Z
Trigger · 2-59, 2-61, 2-62, 2-63, 2-66, 2-70
Trigger block · 2-66, 2-67 Zoom · 2-40
Zoom mode · 2-5