UPT Programming Tool : CAN-Simulator

 

Contents

  1. CAN Message Generator / Bus-Simulator
    1. Introduction
    2. Extracting CAN signal definitions from UPT variables
      1. Treatment of UPT variables flagged as 'TX' (Transmit from the simulated device's point of view)
    3. The option 'Inject values into simulation'
    4. The option 'Send on real CAN bus'
    5. CAN signal definition table
      1. Signal stimulus (expression to 'feed' into the current value)
      2. Transmit cycle (interval for periodically transmitted signals)
      3. Parameters to map a signal into its container (e.g. CAN message)
    6. The CAN Simulator's "Update Interval"
    7. Automation / Programmable test sequences
      1. Conditional Action table (with columns "IF.." and "THEN..")
        1. 'select'..'case'..'endselect'-blocks in the Conditional Action table
      2. Special interpreter functions for the CAN Simulator
        1. Check for CAN reception via can_rx(<ID> <data field>)
      3. Special interpreter commands for the CAN Simulator
        1. Access CAN signals / internal variables / timers
        2. Details about command-driven signal transmission
        3. Command-driven signal transmit timing
        4. Transmission of multiplexed messages
        5. Direct transmission / "injection" of CAN messages via can_tx(<ID> <data field>)
      4. Breakpoints and single-stepping through the Conditional Actions
      5. Programmable Buttons (on the 'Automation' tab)
      6. Text Console (text screen showing output from 'csim.print')
      7. Options to synchronize display application and CAN Simulator

  2. Hints about the CAN Message Generator usage (for advanced users)

CAN Message Generator / Bus-Simulator

Introduction

If you have access to the 'real' CAN-Bus, e.g. vehicle with a functional motor control unit, you don't need the CAN message generator / simulator described in this document. Any simulation will not spot errors like misconfigured CAN bus (baudrate, sampling point, terminators, ..), problems with adapter cables, etc. So if you can, test everything on the 'real' target hardware.

But sometimes, when developing an application for the programmable display, a suitable test environment (like a motor control unit or an entire car or truck) may not be available. In that case, the 'CAN simulator' described in this document can be used to replace 'real' CAN signals. Your display application already contains all that the programming tool needs to know for 'simulating' the signals that in a real-world application would be received via CAN.
The Simulator can be opened from the programming tool's main menu via 'Tools' .. 'CAN Message Generator / Bus Simulator'.


'CAN-Simulator' screenshot (part of the UPT programming tool)
with tabsheet for the CAN signal definition table and 'value slider'.

The CAN message generator can do the opposite: Using the information that you have imported from a CAN database, it can assemble CAN messages that it can play "into the display simulator".
If the PC is connected to a suitable CAN bus interface, it can even send those messages to a real hardware.

Extracting CAN signal definitions from UPT variables

The fastest way to simulate all CAN-signals used in your application is to extract their definition from the application itself (because the 'UPT display variable' definitions contain all the simulator needs to know for assembling such messages):
  1. Open the CAN Simulator window: From the tool's main menu, select Tools .. CAN Message Generator / Bus-Simulator
  2. There: Add signal .. Copy ALL signals from UPT display variables
  3. Check option Inject values into simulation, and if you promise to be careful, Send on 'real' CAN bus
  4. Click into the table on the signal you want to 'simulate' (or send), to select the row
  5. Use the vertical slider (that is now connected to the selected signal) to modify the value
The above method is only the fastest / easiest way to simulate a single signal. To modify multiple values simultaneously, enter a stimulus (numeric expression) in the column titled 'Expression (Stimulus)'. The display interpreter will periodically evaluate this expression, and use the result as new 'physical' value. More on this in a later chapter.

Treatment of UPT variables flagged as 'TX' (Transmit from the simulated device's point of view)

Since the user-programmable display (UPT, e.g. "MKT-View") may optionally transmit CAN signals, there's a potential problem: If the CAN-simulator would also transmit those variables (as CAN signals), besides the 'real' UPT connected to the same bus, the result would be a collision of CAN message identifiers (*). But except for deliberate 'stress tests' (in the lab), transmitting the same CAN message ID from more than a single node (here: the UPT, e.g. MKT-View, and the CAN-simulator) must be avoided.
Since 2023-01-05, the CAN simulator (integrated in MKT's "CAN Terminal Programming Tools") tries to avoid CAN message identifier collisions as follows:


(*) If two CAN nodes simultaneously try to send a message with the same ID, the result is an 'identifier collision' aka 'priority collision' during the bus arbitration phase.
Both nodes "think" the bus is free for their transmission, because both nodes successfully send the same ID during the arbitration phase (by chance, simultaneously).
But after the arbitration phase, the data fields (with different content) collide, causing checksum errors, error frames, and thus no acknowledge from any node in the entire network.
Due to the automatic CAN retransmission, the collisions may repeat multiple times.


The option 'Inject values into simulation'

By default, the option Inject values into simulation is set. This causes the signal values modified via slider or stimulus (numeric expression) will enter the simulation within the programming tool, as a replacement for CAN messages received from the CAN-Bus.
In many cases, this option is already sufficient to test and develop an application on the PC ("run it inside the PC"). Unlike option 'Send on real CAN bus', it doesn't affect any external devices connected to the PC. Furthermore, it can be used without a CAN-bus interface on the PC.


The option 'Send on real CAN bus'

The option Send on real CAN bus should only be used if the PC (with the programming tool) is directly conntected to the MKT View (or similar DUT, 'device under test') with a suitable CAN-bus interface, and no other active CAN nodes are connected to the same network. In this case, the programming tool sends those messages, which the DUT expects to receive from a vehicle's control unit or similar. If both (CAN-simulator and vehicle) were connected simulaneously, this would cause severe collisions on the bus which must be avoided under any circumstance. If multiple nodes send CAN frames with the same message identifiers, there will be unresolvable conflicts during the bus arbitration phase, which sooner or later may cause one of the sending nodes to enter 'Bus-Off' state, i.e. it stops sending. You don't want to experience this in a vehicle while driving !
The 'Send on real CAN' option also controls the behaviour of the simulator command can_tx() as explained here (footnote for can_tx).

See also: Recording and playing back messages via 'CAN-Snooper',
        Playing back recorded CAN-traffic in the simulator,
        The PC's CAN bus interface.


CAN signal definition table

As mentioned in the introduction, signal definitions for the CAN simulator are usually extracted from the application's variable definitions, or from the CAN database (if still available).
Alternatively, signal definitions can also be entered manually in a definition table.


Signal definitions table for the CAN simulator. As usual,
column widths can be adjusted via mouse in the table header.
When selecting a cell, its full text is shown below the table.

Some of the colums in this table (listed below) have the same meaning as described in the manual about display variables connected to CAN signals.
Details about the "CAN-(Message-)ID", "position of the least significant bit", "Intel / Motorola byte order", etc can be found in the document linked above.
Name
Usually copied from the variable definitions table as explained here.
Hint about signal names:
You can launch a global search for all display variables in the currently loaded application through the signal definition table's context menu. Right-click on the name in the grid to open the context menu, then select 'Global search for XYZ' (where XYZ is the clicked name). This does not only search the name in the CAN simulation, but also on all display pages, event definitions, etc, of the loaded application.

Expression (Stimulus)
Optional 'generator function'. If present (non-empty string), this numeric expression will be periodically evaluated by the display-interpreter (interval adjustable on the right side). The result will be copied into the Current Value, from where it can be mapped into a CAN message.
A double click into an empty cell in this column generates an expression for a low-frequency sinewave. Each signal will have a slightly different frequency, and the amplitude will be scaled for the signal's MinValue and MaxValue. To repeat this for all signals defined in the table, select 'More..' (button), and menu item 'Generate Stimuli for ALL signals'. Thus, with very little effort, the simulator can generate ever-changing "dummy values" for the CAN signals. Example:
isin(tsim_ms) / 4   creates a sine wave
                with amplitude 32767/4 = ca. 8191,
                period = 1024 milliseconds, i.e. frequency about 1 Hz,
                with the first rising zero-crossing
                at the start of the CAN-simulation.
(Explanation: The interpreter function tsim_ms delivers the elapsed time, in milliseconds, since the start of the CAN signal simulation ("Run"-button) as an integer value. The older function ti_ms (which, unlike tsim_ms, is also available in the device firmware) delivers the number of milliseconds elapsed since the display application was launched, or a "simulated target reset" was issued through the tool's main menu. The isin function expects an argument range of 0..1023 for a full 360 sine wave cycle, and delivers an output value range of -32767 to +32767.)
Note:
A stimulus may be disabled via command. In that case, the definition cell will be marked as 'temporarily disabled' with a transparent cross as explained in chapter 'Automation'.

Current Value
The signal's current physical value. Can be modified via vertical slider on the right side, or by entering a suitable stimulus under 'Expression'.
Even without a stimulus, the Current Value may be generated via command (csim.<SigName>) on the Automation tab.
See also:
Signal value stimulus vs. signal value set via command.

TX cycle (ms)
Transmit cycle for this signal in milliseconds.
Without a cycle (0 ms), a signal will be transmitted immediately after being modified via slider, stimulus, or command (csim.<SigName>), i.e. "event-driven". This can cause a huge bus load if many values are modified at the same time (in a single update cycle) !
Via menu item More ... / Set transmit intervals for all signals, you can activate the periodic transmission of all signals contained in the table with just two mouse-clicks. For all signals that don't have a transmit-cycle yet, the time (in milliseconds) will be copied from the edit field in the right half of the window.
CAN signals that have been imported from "to-be-TRANSMITTED" UPT variables will be marked for RECEPTION ("(RX)") in this column, to avoid CAN message ID collisions as explained here.

Message ID
Hexadecimal CAN message identifier with prefix '0x'. Three digits for "standard-IDs" (11 Bit), eight digits for "extended IDs" (29 bit).

Bus
Only for systems with two or even more physical CAN interfaces.
So far, only tested with multi-channel Kvaser interfaces like 'Kvaser Hybrid 2xCAN/LIN'.
Bus 1 transmits into the first CAN interface ("CAN1" on the MKT cable, "Ch.1" on the Kvaser interface), etc.

LSB pos
Position of the signal's least significant bit within the CAN data field (0..63 for "classic" CAN).

Num bits
Number of data bits occupied by the 'raw' CAN signal (within the CAN data field, max. 64 bits for "classic" CAN).

Byte order
For historic reasons, 'M'="Motorola" (most significant byte first) or 'I'="Intel" (least significant byte first) ... the annoyance known as 'endianness'.

Data Type
U=unsigned integer, S=signed integer, F=single precision float, D=double precision float.
Type of the 'raw' value, inside the CAN data field (usually integer; float or double as 'raw signal type' is quite rare).

Factor
Multiplier for converting the 'raw' CAN value into the physical 'display' value.

Offset
Will be added when converting the 'raw' CAN value into the physical 'display' value:
  Physical value (e.g. Oil Pressure in Bar) = raw_value * Factor + Offset

MinValue, MaxValue
Possible range for the physical value. In the CAN-simulator, used to scale the 'vertical slider' position into a new physical value: Top = maximum, bottom = minimum.

Multiplexer
Definition of an optional signal multiplexer, used to squeze more signals into a CAN message than permitted by the 64-bit data field (for 'classic' CAN).
Details and format (syntax) as explained here.
Since 02/2021, the CAN simulator may indicate a problem ("red cross") if there is a stimulus (expression) defined for a MULTIPLEXER SIGNAL (not just a multiPLEXED signal):


Illegally defined stimulus ("Expression") for a Multiplexer Signal.

In this case, the error indicator (red cross) would disappear by clearing the stimulus.
See also: Peculiarities with the transmission of multiplexed CAN messages.


To quickly add all signals that you need for testing a certain 'display application', first load the application in the programming tool (so the tool 'knows' all signals and how to map them into CAN / CAN FD messages), then switch to the CAN simulator, and click on 'Add Signal(s)' as shown below:


Steps to quickly fill the 'signal definition table' from a loaded UPT display application

Click on "More ..." (button) ...
    "Generate stimuli for ALL signals"
to let the program fill out the table with expressions (stimuli) for each signal, generating sinewaves with amplitudes matching the signal's full range, and frequencies depending on the signal index (so all signals will have different values when sent to the bus, or 'injected' into the simulation).

The content of the definition table can also be exported as a CSV file. To export the table, select More .. Save definitions as file. In the same menu, definitions can also be imported (Load definitions from file). If the exported file with signal definitions still exists during the next session, it will automatically be loaded when opening the CAN simulator window. The CSV file has almost the same structure as the visible table.


The CAN Simulator's "Update Interval"

The 'Update Interval' defines the minimum time between two updates of the CAN signal definition table, but also the periodic evalation of the Conditional Action table (explained in a later chapter). Depending on the speed of your PC, the actual updates of the GUI may require longer than this parameter ... especially with update intervals below 100 milliseconds, the PC (and/or the Borland VCL-based GUI) may not be able to keep up the pace. Thus, take the 'Update-Interval' (editable as a value in milliseconds in the common part of the CAN simulator window) with a grain of salt.

Automation / Programmable test sequences

In many cases, the cyclic transmission / simulation of CAN signals is sufficient to replace signals from a real network (CAN, etc).
In a few advanced test cases, the CAN simulator additionally has a kind of 'programmable' control itself, quite similar to the programmable 'Event-Definitions' in the UPT display application.
The basic principle is:

In addition, user-defined actions (command lines) can also be invoked "manually" via three programmable buttons, located in the upper part of the 'Automation' tab.

Conditional Action table

The "Conditional Actions" are displayed in a table (string grid) on the 'Automation' tab.
The function is similar to display application's event definitions. Inspired by PLCs (programmable logic controllers), all lines of this simplistic 'program' are executed once per update cycle.
The definition table for Conditional Actions may look like this:

Screenshot "Conditional Actions"
'Conditional Actions' for the CAN simulator (loaded from programs/CANSim_for_SignalMultiplexerTest.csv)

If a cell in the "IF.." column (condition) delivers a nonzero value (logical "TRUE") when being evaluated by the interpreter, then the cell in the same row under the "THEN.." (action) is executed as a command line.
Both conditions and actions are evaluated/executed by the same interpreter that is also used for the programmable display application. To use this interpreter for the CAN simulator without interfering with the display application, it has been extended with a few simulator-specific functions and commandss that will be presented later in this document. For example, the CAN simulator's "interpreter stub" (invoked on module prefix csim) allows accessing the simulator's timebase (tsim), extra timers (csim.t0 .. t9), extra variables (csim.var.<VarName>), and so on.

All conditions that are momentarily TRUE will be marked with a green background in the corresponding cells (in the "IF"-column). If an error occurrs when evaluating a condition or action, the cell will have a red background, and the status line (below the table) will show details about the error. A yellow background in the first column (with the line numbers) means 'a breakpoint in this line has fired, and paused the execution' or 'this line is the next, waiting for execution in single-step mode'.
More about breakpoints and single-stepping follows in a later chapter.
The entire Conditional Actions ("CA") table is evaluated / executed in a single over (unless debugging in 'single step' mode).
The CA table is used to implement state machines. It is not a replacement for a full-grown scripting language. Typical use cases are:


To modify the sequence of conditions and actions in the table, you can simply grab the 'Nr' cell you want to move with the left mouse button, and -while keeping the button pressed- move it up or down to the new destination. While dragging items, the grid (visual table) marks the new location (row) by a bold horizontal line.

To inspect the current value of variables or certain expressions in the CA table, simply point the mouse over it (without clicking). If the interpreter can evaluate the 'word' (delimited by spaces or other special characters) under the mouse, the result will be displayed in the info field below the table.

To undo the last 'cell editing' operation, press the ESCAPE key while the keyboard focus is on the string grid. Pressing ESCAPE a second time will 'redo' the 'undo' operation.

'select'..'case'..'endselect'-blocks in the Conditional Action table
Besides as simple "IF.."/"THEN.." lines, the conditions (table column labelled 'IF..') can be used to implement a select-case-default-endselect block as in this example:

 Nr IF.. (Condition) THEN.. (Action) 
1initialisingcsim.var.SendState := 0 : csim.ts0(10)
1csim.t0csim.tr0 : csim.var.SendState := 1 // start state machine
2select(csim.var.SendState)// branch on the value of 'SendState' ...
3case 1 :csim.sig.EngineRPM := 0 : csim.var.SendState++
4case 2 :csim.sig.EngineRPM := 500 : csim.var.SendState++
6case 3 to 100 :csim.sig.EngineRPM := csim.sig.EngineRPM + 12.3
7csim.var.SendState++ // increment to next state
8default :csim.var.SendState := 0 // state machine stops
9endselect// end select(SendState)

Similar as the select..endselect statement in the script language, the CAN simulator's case and default labels don't "fall through" from one case to the next, so there is no need for a 'break'-statement after each case. Also note the CAN simulator's 'select'/'endselect' uses default:, not else, to avoid misinterpreting them.
Note: At the time of this writing, the CAN simulator's select-endselect only supported numeric values. Floating point is ok. It cannot be used to branch by string values.
In contrast to the "C" programming language and the display's script language, case-values don't need to be constants - but they usually are.

Special interpreter functions for the CAN Simulator

In many cases, the 'Conditions' (events) will be simple comparisons as shown in the previous chapter (e.g. tsim > 10).
The following special interpreter functions have been implemented especially for the IF-column (condition, event) in the CA table:

Reminder: A function returns a value to the caller, and thus can be used as part of a numeric expression or, in this context, a condition. A command (or procedure) as listed in the next chapter does not, and thus cannot be used as part of an expression. But a command may be part of ..err.. a command line or, in this context, an action.

Check for CAN reception via can_rx(<ID> <data field>)
The interpreter function can_rx checks if since the last call, a CAN message with a certain message identifier or/and a certain data field ('payload') has been received.
The syntax is similar as in the author's 'CAN Tester for Windows', and matches the format of the simulator's can_tx() command (which can inject CAN messages into the simulation, but also send messages on a 'real' CAN bus interface). The length of the data field (in bytes) is automatically detected from the content of the data field (which may contain "xx" as placeholder for data bytes with 'any value' accepted for filtering).
Intended to be used as 'condition' in the simulator's 'Conditional Actions' on the 'Automation' tab, can_rx() [when invoked with an argument list in parentheses but nothing after that] returns 1 = TRUE if a matching message was received since the previous call, or 0 = FALSE = "no matching CAN reception".

Examples :

can_rx( 0x123 00 11 22 33 44 55 66 77 )
   checks if since the last call from the same line in the 'conditional actions',
   a CAN message with hexadecimal message identifier 0x123,
   and an eight-byte data field 00 11 22 33 44 55 66 77 
   has been received.

can_rx( 0x123 FF xx xx )
   checks if since the last call (.. see above ..), a CAN message
   with a three-byte datafield, with the first data byte containing 0xFF,
   has been received (with xx = "don't care" for the 2nd and 3rd byte).


Special interpreter commands for the CAN Simulator

Besides the interpreter's standard commands, the following special interpreter commands (and a few functions) have been implemented especially for the THEN-column ("actions") in the CA table:

Accessing CAN signals, internal variables, and 'programmable' timers
The Conditional Actions typically modifies a few CAN signal values (accessed by their names) which the simulator will map into CAN messages (or similar containers), just as if their values have been taken from a stimulus. Examples for this have already been presented in the previous chapter.
The interpreter can also access (read and write) self-defined internal variables that only exist within the CAN simulator.
Last not least, the interpreter also has a few programmable timers that can be used to generate certain waveforms (peridic timers) or act like a timeout monitor (single-shot, "retriggerable" timers).
Most of the commands and functions to access those objects have already been listed in this chapter. The subchapters below provide more details, but are not necessary for simple test applications.

Details about command-driven signal transmission
This subchapter describes details and extensions for the csim.<SigName> command. The assignent can be used in the long form, setting e.g.
csim.sig.EngineRPM.value := 2300
or in the short form without the optional ".sig" and ".value" tokens:
csim.sig.EngineRPM := 2300
in the Conditional Action table assigns a new value (here: 2300 RPM) to the signal (here: "EngineRPM").
Even if there was a stimulus for this signal, the assignment via command overrides the value from the stimulus for the current update cycle (remember, the Condition Actions work like a PLC, where all outputs are sent to the "outside world" at the end of a PLC cycle. With rare exceptions (*), signals and their containers like CAN-messages are only sent once in an update cycle).
Whatever remains at the end of an update cycle (set via command, stimulus unless disabled, or "value slider") will be sent once per cycle or not at all - depending on the signal's individually adjustable Transmit cycle (TX cycle in milliseconds).
A signal stimulus can also be disabled or re-enabled for more than one update cycle via command, e.g.
csim.sig.EngineRPM.enable_stimulus := 0 // disable signal stimulus
csim.sig.EngineRPM.enable_stimulus := 1 // enable signal stimulus
Stimuli that have been permanently disabled via command (enable_stimulus=0) will be marked with a blue cross in the signal definiton table.
Stimuli that are temporarily disabled by assigning a signal value via command will be marked with a green cross.

The next subchapter explains how the simulator's update cycle, a signal's transmit cycle, the interpreter's csim.sig. command, and the actual transmission of CAN messages (or similar containers) affect each other, and how you can force transmission of a signal (along with its container) even if the value is unchanged, and regardless of the "scheduled" TX cyle.
Command-driven signal transmit timing
Simply modifying a signal's current value as shown in the example above will not immediately map it into its 'container' (CAN message, PDU, etc).
Instead, if a non-zero transmit cycle has been defined for the signal in the signal definition table, it may take up to one 'TX cycle' until the new value is emitted to the network. As specified for the 'TX cycle', a cycle time of zero means the signal is event-driven. Event-driven signals will be sent as soon as all Conditional Actions have been evaluated. At this point, the CAN simulator compares all signal values from the current update cycle with the 'old' values from the previous update cycle. All signals with a now different value will automatically be marked as 'pending for transmission'. Later, after mapping all all signals into their transport container, the 'TX-pending' flags are checked and cleared as soon as the container has been sent (or injected into the simulated display applicaion). This is the last step of the CAN simulator's update cycle.

In most cases, signals are transmitted periodically, and it doesn't matter how frequently they really arrive at the receiver (with pure CAN, the 'arrival' of a certain message at all intended receivers cannot be guaranteed anyway). You just provide signals like "EngineRPM", "VehicleSpeed", "OilPressure", etc, and if a single CAN message gets lost on the way, the intended receiver will hopefully get the next one (in the next signal transmit cycle).

In other cases, signals are not transmitted periodically but event driven as already mentioned in the introduction. This is easy - you just set the signal's transmit cycle to zero, and the simulator will only send it if the value is different from the previous update cycle.

In rare cases, you may want a signal to be transmitted both periodically and event-driven. Simply assigning a different value via command will not cause an immediate transmission if the transmit cycle is nonzero, because that would make the code in the 'Conditional Actions' unnecessarily complex for most test cases. For that purpose, the interpreter may force (erzwingen) signal transmission regardless of the signal's transmission cycle, and regardless of the signal value being different (from the previous update cyle or not) as follows:
This will cause the simulator to map this signal into its container (e.g. CAN message), even if the value is still the same as in the previous update cycle, and even if the signal's individual transmission timer hasn't expired yet. The transmit-flag will be automatically cleared after transmission of the container.

Transmission of multiplexed messages
Depending on their transmit interval, signals defined with a multiplexer may exhibit some unexpected behaviour when sent by the CAN simulator:

Direct transmission / "injection" of CAN messages via can_tx(<ID> <data field>)
The simulator's interpreter command can_tx can be used to send simple CAN messages, without assembling the message data from signals (see previous chapter).
Instead, the can_tx command expects the to-be-transmitted CAN message identifier, followed by the to-be-transmitted data field, in the parameter list in parentheses.
The length of the data field does not need to be explicity specified (the number of bytes to send is simply counted from data field).

Examples :

can_tx( 0x123 00 11 22 33 44 55 66 77 )
    "Sends"(*) a CAN message with the hexadecimal 11-bit ID 0x123,
    and the hexadecimal 8-byte data field 00 11 22 33 44 55 66 77,
    or (if the option 'Send on reak CAN bus' isn't set)
    only injects this message into the device simulation that currently runs in the programming tool
    (to replace a message transmitted from an ECU or similar external device).

can_tx( 0xABCDEF.x 01 02 03 04 05 06 )
    "Sends"(*) a CAN message with 29-Bit message ID 0x00ABCDEF (.x = "Extended"),
    and the specified data field (also hexadecimal per default).

The CAN-simulator's "can_tx()" command uses the same parser as the ctx()-command implemented in certain programmable devices (e.g. MKT-View "without CANopen"). Since both commands invoke the same parser, can_tx() can also send the content of any interpreter variable as part of the CAN message data field, including a conversion into the data types specified here (e.g. ".il" = "Intel-Long", ".mw" = "Motorola-Word", ... ).


(*) The can_tx() command only "sends" on a 'real' CAN bus if the option 'Send on reak CAN bus' is set on the CAN-simulator's Signals tab. Without this option, can_tx() only injects these messages (which "would have been sent" by the simulated ECU) into the device simulation that runs inside the programming tool.

Breakpoints and single-stepping through the Conditional Actions

For hardcore debugging, breakpoints can be set in any line of the Conditional Actions.
If the condition in a line with a breakpoint gets TRUE, the breakpoint 'fires', causing the periodic evaluation of the CA table, and the periodic evaluation of stimuli in the Signal Definition to pause. This 'pause' begins exacly between the evaluation of the condition and the execution of the action in the same table row.
This gives the developer a chance to inspect 'what is going on', e.g. immediately before a CAN signal was set to a certain value (via csim.<SigName>">command).

To set a breakpoint on a certain line in the CA table, click into the line on the fixed column titled 'Nr', and (in the context menu) select 'Toggle breakpoint in line X'. This can be done at any time, regardless of the CAN simulator running or not.
Later, if a breakpoint 'fires', the simulation pauses in single-step mode. The line waiting for execution (of the programmed action) is marked yellow, and the simulation pauses in single-step mode. In that state, press F11 (with the keyboard focus on the CA table) to single-step into the next (yellow) line, or resume normal operation by clicking "Run". After being paused by a breakpoint, "Run" will not 're-initialize' the simulation, e.g. this will not set the initialising flag.

See also ("related subject"): Options to synchronize display application and CAN Simulator.

Programmable Buttons (on the CAN simulator's "Automation" tab)

The three buttons on the upper part of the 'Automation' tab are freely programmable. They can be used to invoke any sequence of interpreter commands, similar as the commands used in the Conditional Action's 'action' column.
Whenever the operator clicks on the button (using the left mouse button), the programmable 'OnClick' handler (command) is invoked. Clicking on a programmable button with the right mouse button, or (for touchsceen users) holding the shift key pressed while clicking the button opens a popup menu as shown below, with choices to modify / edit the button:


Screenshot of the CAN simulator's "Programmable Button" context menu

The 'Caption' (text displayed on a button) can not only be edited manually, but also modified via command csim.btn[0..2].caption.
The 'OnClick' handler (string of commands executed on a normal mouse click) may be any sequence of colon-separated interpreter commands, just like the commands entered in the 'Conditional Actions' "THEN.."-column (action), for example:

Button's CaptionOnClick (command line)
Stop Simulationcsim.btn[0].caption := "Stopped" : csim.stop

The "programming" of these buttons (Caption and command line for the "OnClick"-handler) are stored as part of the CAN Simulator's configuration (*.csv file). This way, the entire test configuration can easily be passed on to the customer as a file (along with the 'display application' in the *.cvt file).

Text Console (text screen showing output from 'csim.print')

During a test run, output generated via command csim.print will be displayed on a multi-line 'console' (text editor) on the Automation tab, or (larger display) on the 'Console' tab:


Screenshot of the CAN simulator's 'Text Console'
with deliberately exaggerated use of colours.

Lines of text, or the entire text can be copied from the console and pasted into a user's own documentation as 'Rich Text' (including colour attributes).
The console window was initially limited to 100 lines of text with up to 128 characters per line. If a test application 'prints' or 'writes' more lines into the console than the buffer permits, the existing text is scrolled up, and the topmost (oldest) line disappears.
The current 'output cursor' position can be accessed as zero-based text coordinate in csim.tscreen.cx (current column) and csim.tscreen.cy (current row). The constants csim.tscreen.width and csim.tscreen.height retrieve the screen buffer size in 'characters per line' (128 ?) and 'number of text lines' (100 ?).

Because the 'console' is in fact a RichText edit control, the colours (especially for the background) are limited. Thus, when assigning colours to csim.tscreen.fc (foreground colour) and csim.tscreen.bc (background colour), or when passing colours to csim.print as function arguments, only use the following symbolic colour constants:
clBlackclWhite   clRed    clGreen    clBlue  
clCyan clMagentaclYellowclDkGrayclLtGray
Per default (without explicitly setting colours), text is printed 'black on white' into the console. The csim.tscreen.cls command erases the entire console by filling the buffer with space characters, using the background colour assigned to csim.tscreen.bc before invoking csim.tscreen.cls. Last not least, csim.tscreen.fill(x1,y1,x2,y2," ") fills a rectangular text area with the specified character (in this example, with space characters).

Both commands for output to the console (csim.print and csim.write) support the control characters and a few HTML-like tags listed further below. The difference between 'print' and 'write' is the automatic appending of 'carriage return' ("\r") and 'new line' ("\n") after the output from print (which also clears the 'rest' of the line, which write does not).
Control characters and -sequences in strings written or printed to the text console:

Options to synchronize display application and CAN Simulator

The CAN simulator's 'More ...' button opens a menu with the following options for the synchronisation and interaction between display application (running in the programming tool's integrated firmware) and the CAN simulator:

Hints about the CAN Message Generator usage (for advanced users)

  ... This chapter has not been translated yet.
    If possible, use the german original,
    or an automatic translation of the online version.