CAN Logger Configuration / File Conversion Utility

german flagbritish flag(only available for certain terminals with 16- or 32-bit CPU and a special firmware variant)

Contents

  1. Introduction to the CAN Logger Configuration / File Conversion Utility
  2. Usage of the CAN Logger Configuration Utility
    1. Starting the CAN Logger Utility
      1. Selecting the target hardware
    2. The CANdb Import / Signal List Tab
      1. Searching for signal names
      2. The "Signal Info" display
      3. The CAN-Message-Layout-Display
    3. The Logged Messages Tab
    4. The Logger Configuration Tab
    5. Trigger
      1. The Trigger State Machine
      2. Pre- and Posttrigger
      3. The Trigger Option Tab
      4. The Trigger Condition Tab (for MKT-View I )
      5. The Trigger Condition Grid (for MKT-View II )
    6. Logging CAN messages which are not defined in a CANdb file
    7. Logging GPS (navigation) data
    8. Logging other data (no CAN messages)
    9. Saving the logger configuration file
    10. Changing file- and directory names
  3. Usage of the CAN Logger
    1. Logging and analysis cycle
      1. The power-good flag (and why we had to implement it)
  4. Usage of the CAN Logfile Converter
    1. Conversion parameters
    2. Other converter options
    3. Options to convert GPS data
    4. The Graphic Preview Window
    5. Notes on DIAdem
      1. Known Issues
  5. Limitations
  6. Appendix
    1. How to enter the unlock codes for CAN-logger and CAN-snooper
    2. Tips for program operation
      1. How to associate *.CLC and *.CLD files with the CAN Logger Utility
      2. Command line arguments , Batch operation
    3. Internals
      1. File formats
    4. Storage Media
    5. Power Supply
    6. Legal Terms
    7. Latest Revisions


Further information:

Hint: If you use a browser like Firefox, and open the help system from the utility, this document will automtically be scrolled to the right position. The same was possible with IE6. But with IE7, this didn't work anymore. Now it's your decision which browser to use...

Note: If you received this document as a Word- or Adobe Actobat file (pdf) on a CD-ROM, you will possibly read an outdated 'copy' in this moment. The guaranteed latest revision is only the documentation in HTML format, which can be found in the subdirectory \help in the CAN Logger Configuration Utility ! To make sure you are studying the latest version of this document, download the CAN Logger Utility from the MKT website, install it, and read the manual in HTML-form with your favourite browser. (Hint: With a good HTML browser like Firefox, these pages can also be printed nicely, with properly formatted page borders )

1. Introduction

The CAN-Logger/Snooper is an extra software feature in certain terminals by MKT Systemtechnik or their resellers. A special firmware is needed to use the features described in this document, and the terminal must have a CF- or SD- memory card drive, because the storage medium for the logged data is a Flash memory card with DOS-compatible file system (FAT16, for MKT-View III/IV also FAT32).

At the time of this writing, the CAN-Logger/Snooper was supported by the following devices (there may be more than listed below) :

Some definitions of terms which are frequently used throughout this document, to make sure we know what we are talking about..

The CAN-Logger
is a piece of hard- and firmware inside the programmable terminal. It writes the received CAN traffic to a disk file, message-by-message. To reduce the file size, the CAN identifiers of the logged messages can be selected (from a CANdb file or "manually").

The CAN-Snooper
is a subroutine in the CAN-logger-firmware. When activated, it works like a simple CAN analyzer utility to monitor "unknown" CAN traffic. Received CAN messages are displayed on the terminal's screen. You don't need a PC to use the CAN-Snooper. The CAN-Snooper is a part of the firmware in all display terminals which also have the CAN-Logger functionality. There is no CAN-Snooper without CAN-Logger, and there is no CAN-Logger without CAN-Snooper - except for the possibility that one of these functions is unlocked while the other is not ! A more detailed description of the CAN-Snooper-mode can be found in the description of the programmable terminal, but not in this document (this link only works if you installed the tool in the default directory). This document only describes the CAN-Logger.


The CAN-Logger-Configuration / File-Conversion Tool (abbrev'd "CAN logger utility")
is a PC program which helps you to configure the CAN logger, and to convert the logged data into a format which can be loaded in your analysis program. The CAN logger utility is *not* a CAN-Logger itself, but it...

In principle you can use the CAN logger without the CAN logger utility. You can instead write the CAN logger configuration file yourself (with a text editor) and write your own import routine for the logfiles (with a programming language of your choice). If you really consider this, look into the "file formats" section in the appendix of this document.

The next chapters provide detailed information about the operation of the CAN-Logger Configuration and File Conversion Tool. More information about Display Terminals with CAN-Logger can be found in the manual of the terminals itself or in the help system of the terminal programming tool. The description of the programmable terminal is beyond the scope of this document ! The basic usage of the CAN logger is briefly explained in a later chapter.

If you have installed the terminal programming tool in its default directory, you can follow this link to the description of some interpreter commands, which give you "extended" control over the CAN logger. For normal applications, you don't need to control the logger via interpreter commands. The only exceptions are the commands power=1 (to inform the terminal that the power supply is safe now, so files may be written) and power=0 (to indicate that the power supply is not safe anymore, and that ALL files with write-access must be closed IMMEDIATELY). More information is in the help system of the terminal programming tool.

back to top

2. Usage of the CAN Logger Configuration Utility

This chapter explains how to use the CAN Logger Configuration Utility. Producing a logger configuration file is usually the first step. The usage of the CAN logger itself is explained in a later chapter, also how to convert logfiles will be described later.

2.1 Starting the CAN Logger Utility

The simplest but most ineffective way to start the CAN Logger Configuration / File Conversion Utility is to double-click its icon on the desktop, or in the task bar. It is easier (for every-day use) to associate the file extensions "CLC" (CAN Logger Configuration) and "CLD" (CAN Logger Data) with the utility. A detailed how-to can be found in the appendix.

If you double-click on a CAN logger configuration file to start the utility, it automatically switches to the Logger Configuration tab.

If you double-click on a CAN logfile (*.cld), the utility automatically switches to the File Converter tab.

To convert logfiles automatically, the program can be invoked with a command line (use the \bm switch to enter "batch mode").

2.1.1 Selecting the target hardware


When launching the utility for the first time (after installation), the program will ask for the target hardware. This is necessary (since February 2008), because some features and array sizes depend on the target. For example, the "MKT-View I" (terminal with C167 CPU) has less trigger signals than a logger built inside the newer "MKT-View II" (terminals with ARM-7 CPU) .

The following dialog allows you to select the target hardware (its appearance may have changed since the time this document was written) :

This screen will also appear when you create a new logger configuration, with the option to restore everything  to the default values.

The properties of the used hardware can be checked in the tabsheet "Setup", on the "Options" panel. Some of the hardware/firmware properties of the selected device are displayed on this panel, for example:

When changing the logger device family, beware that they are not 100% compatible. For example, the CAN logger inside the "MKT-View I" can filter out a maximum of 48 different CAN messages from the stream, while the "MKT-View II" supports a maximum of 128 (or even more). So when switching the device family from "MKT-View II" to "MKT-View I", some message- and/or signal definitions may get lost.

2.2 The CANdb Import / Signal List Tab

Because the CAN logger was primarily intended to log CAN-SIGNALS(*), you must select these signals on a special tab of the utility:

sample CANdb-signal table

(screenshot CANdb tab)

On the CANdb tab, you can

To import ("load") a CANdb file, use the file menu. If you have used a certain CANdb file earlier, you will find it in the "Most recent CANdb file" list - which is quite handy because this way you don't have to remember the full path name, and it may save a dozen mouseclicks in the file selector box.

To select signals from a loaded CANdb file, you can use..

To copy a signal from the tree view, you can drag it with the mouse and drop it into the list of logged signals. The same is possible with entire messages (containing multiple signals), nodes (containing multiple messages), or CAN buses (containing multiple nodes). You may get a warning if duplicate signal names are already present in the list of logged signals (in the right part of the window). Avoid duplicate signal names in your CAN databases whereever possible.

Alternatively, you can select an item in the table view and then click the "Add signal(s) to list" button.

The list of logged signals will be saved as part of the logger configuration file. The CANdb file will never be modified because the CAN logger configuration utility is not a CANdb-editor !

You can use up to four of the logged signals as trigger signals.

(*)footnote:
Apart from selecting logged signals from a CANdb file, it is possible to..

2.2.1 Searching for signal names

To simplify the selection of signals from large databases, there is a search function for signal names. You can enter a search pattern in the edit field close to the "Search"-button, and press ENTER after that (or click the search button). The search pattern may contain the following wildcard characters:

? Placeholder for "any single character (letter or digit)
* Placeholder for a whole group of characters. Must not be used at the 1st position in the string !

Search pattern examples:

2.2.2 The "Signal Info" display

The properties of any logged signal can be displayed in the "Signal Info" box. It is in the lower right corner of the signal definition tab. The contents of this editor-like window may look like this:

Display (example) Explanation
PrintedChars Signal name
id=0x0000007B CAN id (+ explanation of the most significant bits 31..29 if set)
node="Terminal" name of the sending node
msg="MuxedMsg" name of message containing this signal
mapping=(8,8,I,U) mapping info: position of LSBit, number of data bits,
  byte order: Intel/Motorola,
  data type: Signed/Unsigned/Float/Double
MuxVal=#0, MuxMap=(0,8,I) Only if multiplexed : multiplexor value, multiplexor mapping (see above)

To see the properties of the logged signal, select it in the list of logged signals.
Additionally, you can check the CAN message layout in graphical form as explained in the next chapter .

2.2.3 CAN-Message-Layout display

The layout of a logged CAN message can be displayed in graphical form. This may be handy when problems with the interpretation of different bit-counting schemes occurr (for example, "Intel-format", "Motorola forward", "Motorola backwards" and other oddities).

Sceenshot

The graphic shown on the left shows an example of a CAN-message which carries various signals. The currently selected signal is marked with a bold arrow, and its name is displayed at the bottom of the window. The arrow always points from the least significant bit (LSB at the end) to the most significant bit (MSB at the arrow head).

The bit numbers within a data byte are listed at the top of the display. Please note that -as usually for binary numbers- the most significant databit is on the left side; the numbers for 8 bits within a byte always runs from 0 (=LSB, right) to 7 (=MSB, left).

Within the 64 bit of a CAN data field, the bit count runs as shown in the diagram: The first byte [0] containts bits 7 to 0; the last byte [7] contains bits 63 to 56. It doesn't matter if the CAN message contains signals in Motorola- oder/and Intel-Format ! (Caution, some CANdb-editors count bits in a different fashion, but of course this must not change the physical position of a bit within the CAN frame).

If the selected signal is multiplexed (as shown here in the example), not only the signal's data bits, but also the multiplexer for this signal will be shown (using the same colour, but hatched). The values of the multiplexer-bits will also be displayed (since the multiplexer value is a constant which identifies this signal).

Note:
The multiplexer/multiplexor is also called "mode signal" in other documents, but this name is rather meaningless so we avoid it.

To select other signals in the displayed message, click into the diagram with the left mouse button.


Contents

2.3 The Logged Messages Tab

This tab of the Logger Configuration Tool contains a list of the CAN messages which shall be logged (and some other specialities too).

The lower part of this tab contains a table for "other" logged values, which will be explained in one of the next chapters.

But first look at the upper table. It contains a list of all messages which shall be logged. There is one row in this table for every CAN-message. The columns in this table are:

Usually this table will be filled automatically when you select signals for logging. To add entries manually (because you have no CANdb file to select signals from), look here.


Contents

2.4 The Logger Configuration Tab

Switch to the "Logger Configuration" tab of the utility. You will see the current settings in several edit fields, check boxes, combo lists etc. Modify them for your needs and save the modified configuration (the tool will ask you upon exit if you want to save the changes, if any).


(screenshot "logger configuration" tab)

The controls on this tab are:

The upper part of the panel titled "What shall be logged ?" contains three radio buttons (only ONE option can be selected at a time) :


The lower part of the "What shall be logged ?" panel allows to select some other data (which are not related with normal CAN messages):

Group "Options":

Other options..

Note: The trigger conditions and trigger options are configured on other tabsheets !

2.5 Trigger

2.5.1 The Trigger State Machine

The CAN logger is controlled by a state machine which can be checked with the function logger.state (if the CAN logger is part of a programmable terminal):

Logger state diagram

The logger states are:

Stopped (or "off")

Engaged

Triggered

The initial logger state after power-on can is defined on the Trigger Option tab ("triggered by default" etc).

The transitions between the logger states are either initiated by the logger itself, depending on the trigger conditions, or with an interpreter command. A complete list of logger control commands is in the manual of the terminal programming tool. Here just a few of those commands :

logger.run
Activates the CAN logger, but does not necessarily trigger it (depending on the configuration). Switches from stopped to engaged, but not from triggered to engaged. If the firmware refuses to switch into the engaged state, there may be something wrong with the memory card.
logger.stop
Stops the CAN logger. The logfile on the memory card is closed, so you can safely remove the card. No popup window appears (in contrast to the 'card.remove' command. In the stopped state, the trigger condition is not permanently checked in every received CAN message, which saves a large amount of CPU power !
logger.trigger(X)
Triggers a recording (X=1) or clears the trigger flag (X=0). Does not close the logfile. Intention: Manual trigger or trigger by the user-programmable terminal application. Examples:
logger.trigger(1) : rem Start recording to the CF card
logger.trigger=1 : rem Same effect as above, only different syntax
logger.trigger=0 : rem Stop recording, but keep buffering received frames
If the firmware refuses to write data to the memory card, the reason may be power=0 (power-good flag not set).
  Note about "logger.run" vs "logger.trigger":
Setting the trigger (=begin writing to the logfile) with this command automatically includes activating the logger (logger.run). But, if the logger was not running when executing the trigger-command, there will be nothing in the pretrigger-buffer.
So, if you need pretrigger-data, activate the logger before triggering it !
logger.state
Returns the current state of the CAN logger as a numeric value. Possible results :
0 = "stopped" (file not open, or buffer not filled in interrupt, possibly a problem with the memory card)
1 = "engaged" (file open, ISR active, but not triggered yet)
2 = "triggered" (file open, ISR active, AND "triggered" )
3 = "post-trigger" (after "triggered"). Only occurrs if the post-trigger time in the logger configuration is non-zero.

Notes:

2.5.2 Pre- and Posttrigger

Pretrigger

You may be interested in the history of the logged signals a short while *before* the trigger event. This is possible, because the logger records the most recent message in a RAM buffer even if the logger is not in the 'triggered' state. By setting the pretrigger-field to a value greater than zero (seconds), a part of the messages in the RAM buffer will be flushed to the logfile when the trigger start condition becomes TRUE.
Note: Depending on the size of the RAM buffer, and the average message rate on the CAN bus, the logger firmware may not be able to save as much 'seconds of pretrigger data' as you want. The buffer capacity which is available for pretriggering is roughly 3000 messages.
The pretrigger interval is defined on the 'trigger options' tab.

Posttrigger

To record a few seconds *after* the trigger condition became FALSE (and/or the stop condition became TRUE), set the posttrigger-field to a value greater than zero (0 means "no post-trigger"). Usually, recording to the logfile stops 0...10 milliseconds after the trigger is stopped. With the posttrigger option, you can record some additional seconds. The posttrigger's internal function is very different from the pretrigger, there is no limitation due to the RAM buffer size for the posttrigger (the maximum is 327.67 seconds of post-trigger data).
The posttrigger interval is defined on the 'trigger options' tab.

2.5.4 The Trigger Condition Tab (MKT-View I)

This chapter only applies to the older "MKT-View I" with 16-bit CPU !
If you are using the "MKT-View II" (with 32-bit CPU), use the Trigger Condition Grid as explained in the next chapter instead !

In the MKT-View I, you can use up to four signals as trigger sources. The trigger condition tab may look like this:

sample trigger conditions
(screenshot "trigger conditions", blue marks explained below)

The components of a trigger definition are:

1 = Trigger Signal (source)
The list in this combo box contains a list of all possible trigger sources. If the list is empty: see notes below.
2 = Compare Operator
Possible comparisons are: <, >, <=, >=
3 = Comparation Value
Enter a numeric constant here. The format is the signal's scaled value. But caution:
Internally, the trigger operates on RAW CAN VALUES. So avoid values which don't exist on the CAN bus, for example 0.5 if the signal is a one-bit-value which can only be 0 or 1.
4 = Inner boolean combination
The two comparations can be logically AND - or OR -combined.
5 = Outer boolean combination
Defines how the two conditions shall be combined. For example, logging may start when BOTH conditions are true ("AND"), or when ANY of the conditions is true ("OR"). If you do not need the second conditional term, set the outer combination to "--".

Usually, there is a trigger START condition and a trigger STOP condition. If you don't need a STOP condition, you can use lines 5...8 of the trigger condition as an additional set of START conditions.

There are four trigger sources, which must be connected to SIGNALS. The combo boxes are filled with the list of logged CAN SIGNALS. If these lists are empty, you must import some logged signals on the CANdb import tab before you can define the trigger conditions !

Notes:

The trigger input works as explained in the following circuit schematics. The trigger is, of course, realized with a piece of microcontroller firmware instead of logic gates.

trigger schematics

Each of the four trigger input variables (V1...V4) is compared against two constants (C1...C8). The comparator results can be selected individually for 'less than' (<), 'less or equal' (<=), 'greater' (>) or 'greater or equal'  (>=) with the comparator output switches CO1...CO2.
In the next stage, the comparator outputs are combined in two stages, each selectable for logical AND or OR combination. The combined results are labeled Start and Stop signal in the above diagram. They are the inputs into a Set/Reset flipflop with the following truth table:

START STOP new trigger state
0 0 NO CHANGE
0 1 untriggered (engaged)
1 0 triggered
1 1 triggered (!)

Usually, the logger operates in a state-triggered mode (as shown in the truth table). Alternatively, it can be set to edge-triggered mode as shown in the next chapter.

Note that if both START and STOP condition are TRUE (1) at the same time, the logger will be triggered !

2.5.5 The Trigger Condition Grid (MKT-View II/III/IV)

This chapter only applies to the newer "MKT-View II" with 32-bit CPU (ARM-7) !
If you are using the older "MKT-View I" (with 16-bit CPU), use the Trigger Condition Tab as explained in the previous chapter instead !

The MKT-View II allows the definition of up to ten (?) trigger signals. Each of these trigger signals can be used either as START- or as STOP-condition. In contrast to the older MKT-View I, the trigger signals are defined in a table ("grid") as shown below.

Note: Before you can select trigger signals, you must import at least one CANdb file, and select all ignals which shall be logged.

Definition of trigger conditions for MKT-View II

The columns in the trigger definition table are ..

Hint: You can check the actual state of the trigger signals during operation on the "MKT-View II". To do this, enter the terminal's system menu, or open the shutdown screen. Select "CAN-Logger" or "CAN logger config", "Trigger Settings"..."Show Trigger Conditions". You will see all trigger signals (in the same order as in the table shown above), along with the signal names, the current signal values (column "SigValue", if the signal has been received since we started), and the result of the comparison in each line :

Kontrolle der Triggerbedingungen beim MKT-View II

The screen also shows the combined start- and stop conditions, and the current state of the logger (passive / enaged / triggered / post-trigger ).

 < under development ... more coming soon ... ;-) >

2.5.3 The Trigger Option tab

The following TRIGGER options can be defined on this tabsheet of the Logger Configuration Utility :


(Example for an edge-triggered configuration, with time-limited recording for each new event)

(*) Note: "Rising" / "Falling" edge applies to the trigger-start-condition (TRUE/FALSE), not to the physical value of the trigger signal itself ! If you don't understand this little but important difference, look at the trigger block diagram again. The trigger signals are on the left side, the trigger conditions are the outputs labelled "Start" and "Stop".

2.6 Logging CAN messages which are not defined in a CANdb file

You can, if requrired, also log other CAN messages which are not defined in a CANdb file. You may use this as a makeshift solution if there is no CANdb file available at all.

sample message definitions

The contents of this table were explained in a previous chapter - if you missed it, click here .

Note: The messages defined this way cannot be 'decoded' into signals ! So defining your own messages here only makes sense if you want to have a listing of CAN messages (no signals) and their data in hexadecimal form. Defining own signals is not possible with this tool - use an external CANdb editor for that task ! There are some very nice CANdb editors around, for example by Vector or Kvaser which can be used to create your own CAN database.

2.7 Logging GPS data

Certain terminals (like "MKT-View") have a built-in NMEA-decoder, which allows them to decode data from a GPS receiver. If that function is available, the GPS data can be logged together with the other data. Of course, you need a suited GPS receiver with an RS-232 interface (often called "GPS mouse") for this job. Furthermore, if the GPS receiver needs some special initialisation sequence to start, make sure you configure it correctly (this can be done with the display program, using the "gps"-commands which are not scope of this document). Just an example, usually located in the event definitions on page 0:

gps.baud=9600 : gps.prot="NMEA" : gps.cfg=1 : rem Init GPS-mouse, 1 Hz

To record GPS data with the CAN logger, set the checkmark "Log data from GPS receiver" on the logger configuration panel. This flag will be saved as part of the logger configuration file (logger.clc). Alternatively, you can turn GPS logging on or off in the terminal's system menu (select "CAN logger config" ... "Buffer/Mode settings" ... "Record GPS (nav) data", and set the parameter value to TRUE or FALSE. Don't forget to save the modified configuration after that ! ).

To define how the GPS data shall be converted into other files later, there is a special tabsheet named "GPS" in the CAN logfile converter.

2.8 Logging other data (besides CAN messages)

In addition to logging CAN messages, the logger in the MKT-View terminal may also log some other data. For this purpose, you may enter up to eight numeric expressions in the table shown below.
These expressions will be evaluated once per write interval (if there is no write interval specified, once every 100 milliseconds).
The same table is (internally) also used to log script variables, more on that later.

2.8.1 Logging calculated numeric expressions (via CAN-Logger)

Remember that built-in functions always begin with a lower case letter, user-defined display variables must begin with an upper-case letter ! More information about numerical expressions can be found in the manual for the terminal programming tool.

sample expressions

The definition table for numeric expressions is on the lower part of the "Messages, etc" tab of the CAN logger configuration utility. In the example, the following values are logged: The first analog input (ain1), the terminal's supply voltage ( sys.vsup, here scaled into Volts), the terminal's internal temperature (sys.temp, here in degrees Celsius), the current page number (pn), and the count of "lost" messages (logger.lost). These values will be added in extra columns of the converted logfile. If no name is specified in the table, the expressions themselves will be used as column names - which may cause problems in the exported ASCII file if the expression contains the column separator character.

The min- and max values are only used for the graphic preview window. The values actually recorded and exported will *not* be limited to this range !

Notes: Because evaluating these expressions with the interpreter may be quite time-consuming, it makes no sense to use sampling intervals below 100 milliseconds. Logging the interpreted results only makes sense if the output type for the logfile converter is set to Signals (not Messages !).


2.8.2 Logging script variables (via CAN-Logger)

Since January 2014, it is possible to log script variables along with the CAN traffic.
To achieve that, ... After reading the logger configuration file, the device firmware will automatically append the names of all SCRIPT VARIABLES declared with the 'logged' attribute as 'numeric expressions' (after those entries which you possibly entered yourself, manually, in that table).

sample expressions

It's not necessary (and not possible!) to enter the names of script variables in the table shown above - it's enough to declare them as 'logged' in the script sourcecode.
The sampling rate for those script variables is the same as for the other rows in the 'NUMERIC EXPRESSIONS', defined as write interval (limit) on the Logger Configuration tab.
See also: Script language manual (pdf, online) .

2.9 Saving the logger configuration file

After all logged signals are defined, and the logger configuration -including the trigger settings- is finished, you must save the CAN Logger Configuration file (*.CLC) on a Compact Flash Memory Card because this is the only way to transfer the configuration into the logger hardware. On the memory card which will be used in the logger later, the configuration file must have the name LOGGER.CLC because only this file will be read automatically from the Compact Flash Memory Card when the logger is powered up.

To achieve this almost "automatically", you can set the tool's default directory on the Settings tab so the logfile will be automatically be written to the memory card (if you have a  suitable memory card reader / writer installed in your PC). The next chapter will show you how.

If the configuration has been changed, the program will ask if you want to save the modified configuration in a file. If you have the memory card in the drive at that time, click "Yes" and the new configuration will be written to the memory card without further questions.

2.10 Changing file- and directory names

On the Settings tab of the logger utility, you can define the default directories for some frequently used file types :

screenshot with directory settings
(screenshot "directories")

Note: On the author's PC, drive "I:\" is the memory card's drive. This will be different on your PC !

To modify the file- or directory names, you can either type the name in the edit field or click on the "..." button to its right to open a selection dialog. The following fields can be modified in the Directories group :

CAN log files
This is the default directory for logfiles. You may set this to your CompactFlash card drive, but often the file conversion runs faster if you copy the logfiles from the memory card to your local harddisk before converting them (especially if these files are very large !)
Logger config
The name and location of the CAN logger configuration file. For your convenience, select your memory card drive here, and use the filename LOGGER.CFG because this file will by loaded into the logger automatically during power-up.
CANdb files
This is the default directory for importing CANdb files
Exported
This is the directory where the converted files are written to ("exported").

back to top

3. Usage of the CAN Logger

The CAN Logger can be used in two basic modes:

The messages which shall be logged can be selected with the Logger Configuration Utility (as already described in another chapter). The signals which shall be logged may be selected from a CANdb file. The Logger Configuration Utility produces a configuration file for the logger, which will be loaded by the logger during initialisation. The following steps must be performed for a complete configuration / logging / analysis - cycle:

3.1 Logging and analysis cycle

  1. Produce a logger configuration file as explained here . This includes selecting what you want to log , and how to log the data !
  2. Copy the logger configuration file to a Compact Flash Memory Card
    (or save it directly on the card from the logger configuration utility)
  3. Turn the CAN logger off (obey the proper power-down sequence)
  4. Insert the memory card in the logger's CF memory card slot
  5. Connect the logger with the CAN bus which you want to analyze
  6. Turn the CAN logger on
  7. Set "power=1" in your terminal program (via interpreter, when the supply voltage is REALLY safe).
  8. Let the logger log (triggered or untriggered)
  9. Set "power=0" if there is the risk that someone cuts off both supply voltages simultaneously
  10. Turn the CAN logger off (obeying the proper power-down sequence !)
  11. Remove the memory card from the logger and insert it in your PC's card reader
  12. Start the logfile converter as explained later
  13. Load the converted files into an analysis tool of your choice

The logger configuration is saved in a small textfile named LOGGER.CLC (CLC = Can Logger Configuration), which must be placed in the root directory of the memory card. Usually this file will be created and modified by the Logger Tool; in other words the file LOGGER.CLC is the connection between the tool and the logger itself. It's usually a one-way-street: The CAN-Logger-Configuration-Utility writes this file, the CAN-Logger (hardware) only reads the CLC-file !

While the logger is active, it usually waits for the trigger condition, and -once triggered- records the selected messages in a file with the extension CLD (Can Logger Data). When logging is stopped, the file is closed. When a new trigger condition occurrs, a new CLD file may be written (the old data are not lost). To remove the card from the logger, you must either turn the logger off, or invoke a firmware command to close the logfile. Otherwise you would damage the data on the card (directory or FAT). If this happens by mistake, you must run the program SCANDISK to repair the card's file system.

The logged file(s) can be converted with the logger tool into various other file formats, which will contain the decoded signal values (not the raw CAN messages). These files can then be loaded into other programs like Excel™, DIAdem™, and some other programs too.

Alternatively, the logfiles can be converted into Vector™ ASCII CAN logfiles, which -for example- can be played back into the CAN network in the laboratory for testing purposes. MKT's own CAN-bus-tester can do this too.

3.1.1 The power-good flag (and why we had to implement it)

The supply voltage of first hardware versions of the MKT view terminal (I, not II) was specified 9 to 36 Volts, for both "switched" and "standby" voltage. As mentioned in the hardware manual, the standby voltage is required to shut the terminal down properly, including closing all open files which very important to keep the CF memory card's directory structure and file allocation table in order.

Caution: While data are been read from or written to the memory card,
it must not be removed from the device, and the device must not be turned off.
On some devices (for example, terminals with SD-/MMC-cards)
a red LED near the card slot signals this state.
Ignoring this rule may damage data on the card.

Backup your data wherever possible !

MKT Systemtechnik will not accept responsibility for any data loss
or loss directly or indirectly caused by data loss.

A problem arose when the terminal was used in passenger cars with 12 Volt power supply, when both (switched + standby) voltages were fed by the same battery. When starting the engine, the battery voltage dropped to 6 Volts which is not sufficient for the terminal. When, in this condition, a logfile was open, the data on the card were corrupted (destruction of FAT and/or wrong directory entries).

Note: If there was an illegal / unexpected power shutdown, the terminal will show the following message when turned on again:

SOS - Device has NOT been shut down
properly, maybe supply voltages
are connected in parallel ?
THIS MAY DAMAGE THE MEMORY CARD !
USE MS-"SCANDISK"(*) TO REPAIR IT !

(*) The program SCANDISK was used under Win 98.
Under Win XP, it doesn't exist any longer;
use CHKDSK or a similar utility in that case.

To relax this hardware problem via software, the flash memory card is disabled for any WRITE-access until your terminal application sets the "power good" flag. This can be done with the following interpreter command:

power=1
This command means "The power supply is safe now, there is no risk of losing both supply voltages at the same time".
You may use it in an event definition, triggered -for example- by a comparison of the engine revolution speed. If the motor runs at 1000 RPM or more, set power=1 .  If you cannot access the motor's RPM value via CAN, use a hotkey to set "power=1" - with the disadvantage that it will be the operator's responsibility to press the button only AFTER starting the engine.
power=0
This command means "The power supply is unsafe now, there is the risk that both supply voltages will fail at the same time".
You may use it in an event definition, triggered -for example- if the motor runs at 500 RPM or less.
Setting "power=0" disables write accesses to the CF memory card. This will cause the terminal to close all files which were opened for writing, including the logfile, etc.

For testing or 'diagnostic' purposes, you can read the state of the power-good flag like an ordinary variable. But remember, it is YOUR task to keep this flag up-to-date.

The default state of 'power' is zero, which means power is unsafe, and writing to the CF memory card is impossible. In a future redesign of the terminal hardware, this may change. If the terminal runs properly at 6 Volts (or less), we may modify the firmware so the power-good flag will be '1' by default.

In the sample terminal application "LogDemo1.cvt" (distributed with the terminal programming tool), you will find an example for the usage of the power-good flag. In the simple example, the user is asked to "press any key" as soon as he thinks the power is safe, and to press the F1 key later before turning the engine off. As explained above, you may replace this with a more sophisticated solution, using the engine's revolution speed to set power=0 or power=1.

The problems mentioned above do not apply to the MKT-View II (with ARM-CPU, available since 2008). The MKT-View II has an internal backup-capacitor, which can provide the power for a few seconds after removal of the external supply voltage. So the CPU can savely power down the memory card, even if all external voltages are removed. For compatibility reasons, the power-flag still exists in the MKT-View II, but it is automatically set to TRUE as soon as the backup capacitor is fully charged (which takes a few seconds after power-on).

back to top

4. Usage of the CAN Logfile Converter

Note: This document describes a  work in progress. The finally released version may look different !

To convert a logfile from the CAN logger into some format, use the "File Converter" tab of the CAN logger utility. If you double-click on a *.cld file (CAN Logger Data file), this tab will be opened automatically.

Screenshot CAN Logfile Converter

The list on the left side contains the names of all files which shall be converted. With the Select files button, you can add more files to the list. Alternatively, you can add logfiles (*.cld) from an explorer window via drag- and drop.

4.1 Conversion parameters

The fields in the Destination box describe the format of the output file. The settings in this box depend on the program used for post-processing (for example: spreadsheets, data visualization tools, statistic evaluation programs). You will only have to adjust these settings once, because they are saved permanently in a special configuration file (not in the logger configuration file !).

To start the conversion, click on the Go! button. The name of destination file will be automatically produced by the tool, matching the input file but using a different extension; it is displayed on the bottom of the File Converter tab.

The conversion parameters are:

Output Type
Signals: Write signals, not CAN messages into the output files. All signals which are contained in the logfile are decoded, the results are written into the output file.
Messages: Do not decode the messages from the logfile, instead write the CAN message frames in hexadecimal form (one frame per text line). Though this mode may sound exotic : it fulfils the function of a true CAN LOGGER !
Output file format
An awful number of different output file formats had to be implemented for various users, here just a few...
Text
A plain textfile ("ASCII") which can be viewed with any text editor, or imported into many spreadsheet programs.
You must define the separator characters for the text ouput format in a few other edit fields, see below.
CSV, international
Comma Separated Values. Can be imported into many spreadsheets on a PC with an english windows installation
"CSV", german
This 'nationale' CSV-variety can use a comma instead of the decimal point. Some (german) programs then use the semicolon as a coloumn separator, others (like the german version of Open Office) use the comma for both (!), and put the characters of a fields in double quotes. In contrast to the "international" CSV, both column- and decimal-separator can be selected individually for this format, so you can produce "comma-separated values" with this format as well as "semicolon-separated values".
DIAdem, ASCII
Produce a separate "header" file (*.dat!) and a "data" file (*.asc) to be loaded into DIAdem. Never tested because our old copy of DIAdem crashed whenever trying to make a graphic plot from the logged data (-> DIAdem V7 showed a steaming coffe cup but no response to any user action, not even CTRL-ALT-DELETE).
DIAdem, INT32
Produce a separate "header" file (*.dat!) and a "data" file (*.i32). May load a bit faster into DIAdem but never tested successfully.
DIAdem, REAL64
Similar as above, but here the data are saved in binary files as 64-bit floating point numbers. This format avoids some problems with scaled time channels, because floating-point numbers offer the best resolution and the largest possible value range.
Stiegele MDF (c) STIEGELE Datensysteme : MDF = Measure Description File.
This format also uses separate header- and data files. The header file (*.mdf) contains all informations required for post-processing; the data file (*.dta) contains the measured data. Note: MKT's Logfile-to-MDF-Converter only supports data types 'float', 'double', and 'ymdhms' for this file format.
VECTOR-MDF (*.dat)
This is VECTOR's MDF format. It may (or may not) be compatible with recent versions of ETAS / INCA / MDA but we could not validate this. Because of trouble with ETAS MDA V4.0 (files didn't load even though Vector's MDF Vaildator showed no problems), the time channel now starts at zero at the begin of each measurement.
VECTOR-compatible, ASCII (CAN message log)
Similar like the ASCII logfile format used by Vector's CANoe / CANalyzer, but does not support all features because we had no detailed specifications about this format. In contrast to the Vector tools, the identifier is always noted in hexadecimal form, also the message data bytes.
Since 2010-05-26, the converter appends an 'x'-suffix to 29-bit identifiers, for compatibility with Vector's CANoe.
ETAS ASCII ("ETASAsciiItemFile")
Added 2011-02-17, when certain files (in Vector's MDF format) didn't load properly in ETAS MDA. The ASCII format has the big advantage that it's not a binary file format (in contrast to MDF / ".dat") so you can easily examine these files with a text editor. Hint: Use a good text editor like Notepad++, set the tab size to 20 characters or more (so the columns are properly aligned on the screen), and you have a quick tabular display for your ASCII data files. The column separator is always the TAB character (0x09).

Column separator (field separator)
Select space, tab, comma or semicolon as column separator. Only enabled for output file format = text. Not adjustable for most other output file formats (especially not for binary formats).
Decimal separator
Select period(.) or comma(,) . Even German users should use the period character if they are working for international companies, and have to mail their results across the pond !
Time Column
Select if the output file shall have a time column, and which format shall be used (where applicable). For certain output file formats, the format of the time columns cannot be modified (like DIAdem where the time colum, if selected, will always be something like year+month+day+hour+minute+second, which is not very accurate because the seconds can only be integer values. See notes on diadem for details). For text file output, the following time column formats are possible:
YYYY-MM-DD hh:mm:ss  = ISO8601-formatted date and time
Milliseconds = only the "high-resolution" timestamp (which starts at zero when the device is powered on). Integer value !
Seconds = Similar as above, scaled into seconds, as a floating point value .
Note: If multiple test runs are recorded in a single file, during which the device is turned off and on again, the time-channels formatted as seconds or milliseconds will not be monotonously rising within that logfile ! If your post-processing program cannot handle this, use the option new filename on startup in your logger configuration !
Write Interval (for logfile conversion)
Can be used to reduce the size of the output file. If, for example, you only need a 1-second raster for the exported lines instead of a 10-millisecond-raster in the logfile, you can reduce the data size, set this write interval to 1.0 before starting the conversion.
If you know before your logging session, that you don't need millisecond-resolution for the logged data, limit the write interval for messages in the logger configuration. This will reduce the size on the flash memory card, and reduce the CPU load of the CAN logger itself. 

back to top

4.2 Converter Options

Additional (less frequently used) settings for the CAN logfile converter can be defined on the tabsheet "Converter" ... "Converter Options" :

Invalid Signal Value
Some analysis tools need a certain value for "invalid signals". An invalid signal is, for example, a signal which has not been received yet. The value from this edit field will be copied into the output file as long as a signal is invalid. Once a signal has been received, it is and remains valid.
If the output file format is a text file, you may enter any string here. For all other file formats, this field has either no function (because the invalid signal value is fixed), or must be a numeric value like "-99999999".

Signal Values: Raw or Scaled ?
Has been used during development. Should be set to "Scaled" usually.
Raw: Do not convert the raw CAN value into the physical value (do not apply offset and factor)
Scaled: Convert the raw CAN values into physical values, using the signal's conversion parameters offset and factor

Headlines
Defines, if and how many header lines shall be written before the actual data ("values"). Only available when converting into TEXT files (*.txt or *.csv). The headlines contain:
- First line: Contains the column names (often: signal names) which is helpful when post-processing the file with a spreadsheet program
- Second: If enabled, this line contains the physical units for each data column.
- Third: Rarely used; if enabled this line contains the logger-info-string (read from the logfile !)
If "Headlines" is set to zero, none of these lines will be written into the output file. For export file types like "DIAdem" and "Vector", this parameter has no effect.

"Ignore signal definitions from logfile, use currently loaded signals instead"
You can try to use this option to convert logfiles into signals, if the logfile itself does not contain any (or not the right) signal definitions ... for example, because you have only set the option "Record all identifiers" in the CAN logger configuration, without selecting any CAN signals from a CANdb file (*). Be very careful with this option, and make sure you picked the right CANdb file, which matches the CAN messages in the recording. Otherwise you may end up with an empty (at best) output file, or an output file containing only 'garbage'.
(*) The reason for missing CAN signal definitions in the logged file (*.cld) may be a mistake of the person who prepared the CAN logger configuration (logger.clc), but this may also be done deliberately  by "someone" to keep the CAN signal definitions secret. Whether a CAN logger configuration (or a CAN logfile) contains signal definitions or not can be easily checked with a text editor: If the file header only contains two "dummy definitions" like the the following ...
Msg00: id=0xFFFFFFFF,mn="",nn="",wi=0
Sig00: id=0xFFFFFFFF,sn="",ty=S,un="",fa=1,of=0,mi=0,ma=0,sb=0,nb=0,bo=M
.... then the logfile cannot be converted into signals (only into a CAN message dump) without the option "Ignore signal definitions from the logfile" - and of course, only if you have access to the CANdb files ! Details about the file formats can be found in the appendix.
When using this option, proceed as follows:

You can avoid this complexity by always adding all required CAN signal definitions to the CAN logger configuration. The CAN logger itself will copy these definitions to the logfile then, so the converter "automatically" knows how to decode the signals. But in some conditions, or to keep the signal definitions 'secret', you can use this converter option (along with the logger option "record ALL identifiers"). Neither the logger configuration file, nor the logfile need to contain any information about how to decode the recorded signals then.

Skip data until all channels are valid
Use this option if your post-processing software cannot handle 'invalid' values.
When set, the converter will ignore everything in the original recording until all channels are valid.
The reason for a channel being invalid may be manyfold:
By default, this option is off which means the converter starts emitting data immediately, even if "something" is missing at the begin. For text files, missing (invalid) data are replaced by the 'invalid signal value' as explained further above.

Combine output into ONE file
This option can be used to combine multiple input files (e.g. canlg000.cld, canlg001.cld, canlg002.cld ) into one common output file (e.g. canlg000.asc in Vector ASCII format).
Note: At the time of this writing (2014-01-22), this option only worked when converting CAN logfiles into the Vector ASCII format (*.ASC) !

back to top

4.3 GPS Output Options

The CAN logger can optionally record position data (from a GPS receiver) too. To make use of this GPS-logging facility, you must convert the GPS data into a format which your post-processing software can handle. The GPS data can ...

Note:
You must set the option "Log Data from GPS Receiver" in the logger configuration, before starting the CAN logger. This option is disabled by default, because it may cost a lot of disk space. Furthermore, you must tell the terminal which kind of GPS receiver is connected, and how it shall be initialized. More on this can be found here.

While converting data from a logfile which contains GPS data, the GPS track can be plotted as a preview in a simple map window.

Unfortunately, there is are thousands of different GPS file formats, since every GPS map software seems to implement their own track format. The CAN logfile converter only supports the following output formats:

Fortunately there is a freeware tool called GPSBabel with can convert the NMEA format into zillions of other formats - most likely, also the format which can be imported into "your" mapping software.

A few GPS converter options are built inside the CAN logfile conversion utility. Select the GPS tab to define your required output format:


(screenshot GPS Converter Output Options)

The GPS Converter Output Options are:

The table in the lower part of the GPS tab can be used to define which GPS-columns shall be added to the output file. You don't have to fill out this table yourself ! Instead, recall one of the "Presets" from the combo list below the table. Only for very special applications, you may have to edit the contents of the definition table manually. You can change the equence of the table entries by holding the mouse down in the "Nr"-column, while moving the cell up or down. To delete unneccessary entries, just delete the "Title" cell. A list of possible entries in the "Contents" column is here .
Don't forget to click the "Apply" button when the modified table is complete (  ) .

back to top

4.4 The Graphic Preview Window

While converting your log data (which may take a fair amount of time), you may show the converted data in graphic form. This shall not -and never will be- a replacement for a post-processing tool, but it can give you a short impression if "it worked". In fact, the author implemented the graphic preview window exclusively for testing purposes, because he had no suitable post-processing tool. Beware: the graphic preview window may still have a couple of bugs, so if you don't really need it, don't use it... and don't complain about the ugly colours ;-)

screenshot graphic preview
(screenshot Logfile Conversion Preview)

To use the graphic preview window, set the checkmark graphic preview on the File Converter tab before clicking "Go !" to start the conversion. The converted data will then be displayed as simple graphs on a common screen in the preview window. Old data may be scrolled out on the left edge of the window, when new data are added to the right.
If the display is too confusing because too many channels are visible and overlap each other, you can turn channels of by clicking at the channel names in the color legend field.

Note: The graphic preview only works if the file converter's output type is set to 'SIGNALS'. It cannot display CAN MESSAGES !

4.5 Notes on DIAdem®

Supported DIAdem - formats

NI DIAdem® supports a large variety of file formats. The CAN logfile converter described in this document can only generate a subset of these formats, which are listed below.

Known Issues

When testing the conversion routines into the DIAdem format, only a quite old version of DIAdem (V7) was available for us. With this old version, there were a lot of unexplainable system crashes, whenever trying to produce a graphic view (with DIAdem VIEW). The sympton was a frozen mouse cursor (alias DIAdem's steaming coffee cup), not even the final rescue grip CONTROL-ALT-DELETE was possible then ! So we can only advise you to use extra care, make backup copies of all important files, and be prepared for the big bang when working with converted logfiles in an old DIAdem version.

The ASCII format of our old DIAdem (V7) obviously has meager resolution of just ONE SECOND (because only placeholders for year, month, date, hour, minute and second are mentioned in the specification, but no fractional values). This is unacceptable for many applications. To circumvent this, set the format of the time column to 'IMPLICIT' before conversion. In this case, the utility can place a scaling factor matching the write interval AS A FLOATING POINT VALUE in the DIAdem channel header.

Exporting GPS-Data into any DIAdem-format is impossible, because neither the required informations nor a suitable test environment were available at the time of this writing.

back to top

Limitations

In the old 'MKT-View Plus', the logger was restricted to...


Since the MKT-View "Plus" / MKT-View I has been phased out years ago, and replaced by MKT-View II / III / IV by almost every customer, the above restrictions don't apply anymore. The logger's main bottleneck isn't the CPU speed but the SD memory card.

Conflicting logger options:

back to top

Appendix

How to enter the unlock-codes for the CAN-Logger and/or CAN-Snooper

If CAN-Logger or CAN-Snooper have not  already been unlocked by the manufacturer (for example because you didn't order these software functions when buying the hardware), enter the unlock-codes yourself in the terminal's system menu. The manufacturer (MKT Systemtechnik) will provide these codes via phone or email. Please note: The unlock-codes are tied to a device's serial number ! The serial number is displayed in the terminal's system menü. To enter the unlock codes, proceed as follows (here as an example for the MKT-View "plus" with software art11089.hex) :

  1. User: Invoke the system menu by pressing F2 and F3 on the terminal simultaneously
  2. User: Select menu item "System Setup / UNLOCK" with cursor keys and ENTER (alias rotary button).
    (if the main system menü only has "System Setup" but not "System Setup / UNLOCK", there are no unlockable special functions - possibly wrong firmware)
  3. User: Write down the serial number(s) from the terminal's system menu (item "SerialNumber=XXXXX"), then contact MKT Systemtechnik (phone or email), tell us the serial number(s), and ask for the unlock code(s) .
  4. MKT: Check if the user/customer is authorized ("has paid for") the special function(s); if yes, tell him the unlock code via phone or email.
  5. User: Select "Enter UNLOCK Code" in the terminal's system menu
    (press ENTER once, so the cursor jumps to the first digit of the edit field)
  6. User: Enter unlock code in the system menu
    (for MKT-View: use the rotaty button to increment/decrement digits, use F1 and F2 to move cursor left or right as replacement for "real" cursor keys)
  7. Finish the input with ENTER and wait ...
    (the terminal's firmware checks the code and shows which functions were unlocked, like :
    CAN-Logger = 1
    CAN-Snooper = 1 if both functions were unlocked)
  8. If required, enter the second unlock code (for example CAN-snooper, repeat steps 5 to 7).

If and which special functions have been unlocked on a particular device will also be displayed when entering the system menu (as long as the keys to activate the system menu are held down).

Tips for program operation

How to associate *.CLC and *.CLD files with the CAN Logger Utility

Note: If the CAN Logger Utility was installed with an installation script, the script will -most likely- have registered the file extenstions *.CLC and *.CLD already. Only if the extensions were already associated with another program, you may have to change the association yourself.

As mentioned in the chapter Starting the CAN Logger Utility, it is helpful to associate the extensions CLC (CAN Logger Configuration) and CLD (CAN Log Data) with the CAN Logger Utiliy.

This can be done easily with the function "Register files and extensions" in the program's main menu:
Select "File"..."Register files and extensions". The program will ask you which file extensions shall be associated with the CAN Logger Utility, and -if you agree- will save these settings in the windows registry (under "HKEY_CURRENT_USER".."Software".."MKT Systemtechnik").

Command line arguments

When launching the program, a few parameters can be passed in the (DOS-)command line. This is used -for example- in the Terminal Programming Tool which may invoke the CAN Logger Utility to pass the names of the currently used CANdb files, or to instruct the utility to load a certain file upon startup.

The command file arguments are:

/bm
Let the program run in batch mode. Without this switch, the program runs in "interactive mode".
/cwNNNN
Programm start with client communication. The parameter NNNN is the window handle of the client. This is required for communication between client and server (the server sends a message to the client as soon as he is ready for business).
<filename.clc>
Command to load a CAN Logger Configuration file (detected by the file extension).
<filename.cld>
Command to load a CAN Logger Data file (detected by the file extension).
<filename.dbc>,<BusNr>
Command to load a CANdb filei. The <BusNr> parameter defines for which bus the file shall be loaded (1 or 2).
<filename.cmd>
Command file mode. May replace the DOS command line if there is not enough space in it. Every line in the command file will be treated the same way as a single command line argument.

Batch mode operation

You may invoke the logfile converter from your own application, using the "batch mode" switch ( /bm ) in the command line. In this mode, the program will run "automatically", without user interaction. This means:

When using the batch mode, you should also specify one or more logfile name(s) in the command line, and -if required- the name of the target file(s). The utility will know which of the files are "input" and which are "output" by looking at the extensions. Example:

CanLoggerUtility.exe /bm canlg001.cld testdrive1.dat

Internals

<work in progress>

File formats

Format of 'primary' CAN log files on the memory card

A CAN log file contains everything which you need to decode all all logged signals. For this reason, the header contains a small database with signal definitions in a "textual" form. The CAN logger actually writes messages (not signals) to the memory card. A single data record in the logfile consists of 16 bytes of information, including..

A complete and up-to-date desciption of the CAN logger's primary file format may be found in this document, or obtained from MKT Systemtechnik. Please ask the software development engineer Mr Buescher for the "CAN-logger file format specification" (camouflaged email address).

Format of CAN log files exported "as text"

These files are not produced by the logger itself, but with the CAN-Logger File Conversion Utility. The utility can read the primary logfiles (produced by the logger) and convert them to other file formats, either message- or signal-based.

By the time of this writing (2003-10-09), the "message"-based text exported format looked as follows. It is a human readable format which you can analyze with a simple text editor :

Time_second CanIdentif d0 d1 d2 d3 d4 d5 d6 d7
000117.8600 0x00000123 15 00 00 00 15 00 15 00
000117.8603 0x00000301 0F 02 5F 01 03 00 03 00
000117.8606 0x32345678 02 00 02 00 03 00 03 00

Beware: The output formats are subject to change without further notice. This especially applies to the textual display of "other" entries in the logfile, like evaluated expressions, trigger status lines, etc.

The first column is the timestamp (here in seconds), the second is the CAN identifier which contains the bus number and the 29-bit-flag, followed by the message data bytes in hexadecimal form. There is no "data length code" because CAN messages can only have up to 8 message data bytes, which you can count yourself !

Storage Media

Storage medium for the old 'MKT-View Plus' (with CompactFlash memory card)

The configuration and data files are stored on a Compact Flash™ memory card for the terminal's memory card slot. We tested a few of those cards from various manufacturers, with sizes between 4 and 512 MByte. Be careful, because:
For the old MKT-View "Plus", the CF memory card must be DOS-formatted !
Other formats like FAT32, NTFS, etc will not work ! Fortunately most cards are still DOS-formatted with a 12- or 16-bit FAT by their manufacturer. If your PC has no suitable interface for the memory card: There is a large number of cheap interfaces for the USB port; a web search for

or

will take you further. The author used an "USB 6-in-1 Card Reader/Writer". By the way, the CAN logfiles are usually much too large to be transferred through the terminal's serial interface. So you *must* have some kind of memory card interface to transfer the files !

Storage medium for 'MKT-View II' and 'MKT-View III' (with SD memory card)

These newer devices with 32-bit CPU (ARM) use an SD memory card, which must be treated even more carefully than the old (large) CF memory card.
MKT-View II, III, and possibly all later devices support FAT16 and FAT32, thus they are suited for disk volumes larger than 2 GByte.

Note
MKT-View II / III still do not support NTFS, and long filenames, to avoid hassle with several software patents.

General notes about storage media (CF, SD)

The memory cards must be handled with care. Though some precautions were made when constructing the terminal hardware, you should disconnect the terminal from before inserting or removing the memory card to avoid electrostatic discharges. During logging, some files may be opened on the memory card. If there is a sudden loss of power during file writes, the data on the card will be corrupted, and -worst case- the file allocation table and directory structures will be damaged. In the latter case, use your PC and a 'Scandisk' utility to repair the file system.

To avoid corrupted data caused by sudden power failure, the terminal (when equipped with a memory card slot) requires two separate power lines: A switched supply voltage, and a permanent supply. More about the terminal's power supply can be found in the hardware manual - the description of the terminal's power supply would go beyond the scope of this document.

back to top

Power Supply

As mentioned in the chapter 'Storage Media', the terminal must power itself down in a controlled manner to avoid data loss on the memory card. There is

Both supply lines have the same electrical characteristics (specified in the hardware manual). Typical supply voltages are 9.0 V .... 24 V. If the 'permanent' suppy voltage is missing or below 9 V, the terminal will show a warning message like

Bad standby supply voltage !
Measured: 06.8 Volt

In this case, you should check the electric wiring, connectors, and -possibly- the battery voltage.

DO NOT CONNECT BOTH SUPPLY VOLTAGES IN PARALLEL ! Data losses and a corrupted file system on the memory card will be the result, when the 'permanent' voltage is turned off together with 'switched' voltage, so the terminal has no chance to close all opened files properly.

Because there may be the risk that both supply voltages may drop below 9 Volts when starting the engine of a passenger car, the terminal must be informed if the power is "reliable" or not. More details are in the chapter about the power-good-flag.

If there is something wrong with your supply voltages or the cable connections, you will get this message when turning the terminal's power on :

SOS - Device has not been shut down
properly,maybe the supply voltages
are connected in parallel ?

! RISK OF DESTROYING THE MEMORY CARD !
! NOW USE MS-"SCANDISK" TO REPAIR IT !

[press any key to continue]

In this case, you should

Notes:

back to top

Legal Terms

Namings for products in this manual, that are registered trademarks, are not separately marked. The same applies to copyrighted material. Therefore the missing ®(r) or ©(c) does not implicate, that the naming is a free trade name. Furthermore the used names do not indicate patent rights or anything similar.

CANdb®, CANoe, CANalyzer are trademarks or registered trademarks of Vector Informatik GmbH.
Compact Flash™ is a trademark of Sandisk Corp.
Intel® and the Intel logo are registered trademarks of Intel Corporation.
NI DIAdem is a registered trademark of National Instruments Corporation.
Excel, Microsoft, Windows, Win95, WinNT, WinXP® are registered trademarks of Microsoft Corporation.

THIS SOFTWARE IS PROVIDED BY MKT SYSTEMTECHNIK ''AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, OR NON-INFRINGEMENT, ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHORS OR THE DISTRIBUTOR BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

FURTHERMORE THE AUTHOR IS NOT LIABLE FOR VIRUSES AND OTHER FORMS OF "MALICIOUS" SOFTWARE WHICH MAY HAVE INFECTED THIS SOFTWARE, AND ANY DAMAGE OF ANY KIND RESULTING FROM THIS.

HIGH RISK ACTIVITIES

The Software is not fault-tolerant and is not designed, manufactured or intended for use or resale as on-line control equipment in hazardous environments requiring fail- safe performance, such as in the operation of nuclear facilities, aircraft navigation or communication systems, air traffic control, direct life support machines, or weapons systems, in which the failure of the Software could lead directly to death, personal injury, or severe physical or environmental damage ("High Risk Activities").

MKT Systemtechnik specifically disclaim any express or implied warranty of fitness for High Risk Activities.

Latest modifications (with date in ISO8601 format, YYYY-MM-DD)

2014-02-04: Added the option to log script variables.
2011-02-17: Implemented and documented support for the ETAS ASCII format (*.ascii, "ETASAsciiItemFile")

back to top