• Programming Tool
• A-Z
• Pages
• Simulator
• CAN
• Scripts
• 

Programming tool for CAN displays

    Last modified: 2024-12-06 (YYYY-MM-DD)
            Available online at www.mkt-sys.de/MKT-CD/upt/help/progt_01.htm.


Contents

1. Programming tool for CAN displays
   1. Introduction
      
      1. Keyword Index ("A to Z")
      2. Context- and Command-specific Help System
      3. Disclaimer, Legal Issues
   2. Installation
      1. Note for users of windows 7
      2. After the installation: Check if a firmware update is available or necessary
      3. Program start with or without 'Disclaimer'
         
         1. Removal of the programming tool's 'Disclaimer'
   3. The Main Window
      1. The programming tool's main menu
      2. Status Bar
      3. Tabsheets
         1. Settings (tab) / Programming Tool Settings
   4. LCD simulator window and LCD device selection
      1. Device Selection / LCD Settings (screen resolution, colour model, landscape/portrait mode)
   5. Communication Channels
      1. SDO Channels
      2. PDO Channels
      3. Generic CAN Channels ("CANdb")
   6. Application Variables
      1. Properties of display variables
      2. Finding all references to a variable, function, signal, string, etc (globally)
      3. Variables on SDO channels
         1. Usage of "index" and "subindex" for SDO variables
      4. Variables on PDO channels
      5. Variables connected to the own CANopen object dictionary
      6. Variables connected to CAN-Signals
      7. Variables connected to 'openABK'
      8. Data Breakpoints (to stop on assigning certain values to a certain variable)
   7. Settings (on tabsheets and dialogs in the programming tool)
      1. Parameters in the right part of the 'Settings' tab
         
         1. Programming Tool Settings
         2. Selection of folders (directories)
      2. Parameters in the left part of the 'Settings' tab
         
         1. Terminal constants (1st part of the tabular display)
         2. Terminal settings (2nd part of the tabular display)
      3. CAN bus timing parameters (dialog)
      4. General Terminal Options (dialog)
      5. Optional Setup (formerly only configurable in the device's own setup menu)
      6. Checking the supported graphic functions
      7. Creating a UPT File Description (string displayed in the 'App-Selector')
      8. Simulation of the memory card (on a PC, as replacement for the memory card in a 'real' device)
      9. Checking external file references (in the application)
   8. Definition of a Text Array (antiquated, for devices without script language)
      
      
   9. Display Page Definitions
      1. Introduction to programmable display pages, with an
           overview of available display elements
      2. The page definition header
      3. Definition of display lines (manually, without the graphic editor)
      4. Properties of a display line (position, font, colour, text, ... )
      5. The Format String with backslash sequences and HTML-like 'tags'
      6. Edit Fields on a programmed display page
      7. Buttons (and similar 'active graphic areas')
      8. Icons (bitmap graphics)
      9. Using Display Lines as Menu Items
      10. Bargraph diagrams (optional)
      11. Y(t)- and X/Y-diagrams (optional)
      12. Multi-Line Text Panels (for the script language)
      13. Graphic Panels (displaying script-generated 'Canvas' graphics)
      14. Inserting other grahic elements on a display page
      15. Overlapping graphics
      16. Touchscreen support (in certain terminals)
          
      17. Multi-Language Applications (and how to realize them)
          
          
   10. The "simple" editor for display pages
       1. The page editor's toolbar
       2. Dialog box for alphanumeric display elements
       3. Creating and modifying polygons
       4. Creating an anlog meter (needle instrument)
       
       
   11. Defining Events - overview
       1. Defining Events - the definition window
       2. Defining Events - the definition language
          1. Keyboard Events
       3. Global and Local Events
       4. Global Event Catalog
       5. An alternative for 'events' : the Script Language (only for 32-bit CPUs)
   12. Assistants
       1. Assistant to create a new display application
       2. Variable Selection Dialog
       3. Menu Link Dialog
       4. Assistant 'Check and correct all pages'
       5. Global Event Catalog (deprecated)
   13. Display Page Overview ("all pages")
   14. The Icon import screen
       1. Reserving memory for icons (and other special features)
       2. Flexible memory usage (for newer terminals with 32-bit CPU)
       3. Determining the Flash memory usage in the target
       
       
   15. User defined fonts
   16. Debugging
       1. Watch window
       2. Test Command Window
       3. CAN logfile playback utility
          1. Starting the CAN Logfile Player
          2. Rejecting certain CAN messages in the Logfile Player
          3. Automatic Stop of the CAN Logfile Player via script debugger
       4. CAN Message Generator / Bus Simulator
       5. Wireshark-compatible Ethernet packet capture
   17. CANopen Configuration
       1. CANopen SYNC configuration
       2. CANopen NMT configuration
       3. Devices with 'CANopen V4' (most terminals with 32-bit CPU)
       4. The CANopen object dictionary (OD)
       5. PDO-Mapping with the Terminal Programming Tool(for CANopen V4 only)
       6. EDS files (electronic device specification)
       7. EDS/DCF-Generator to transfer the CANopen-configuration into a PLC software (like CoDeSys)
   18. Data Transfer between programming tool and device
       1. Transferring the application into the terminal ("Upload")
          1. Transfer via CAN / CANopen
          2. Transfer via Ethernet / LAN (UDP)
          3. Automatic display program update via FLASH memory card
       2. Firmware-Update
       3. Screen Snapshot via CAN  (or HTTP?)
       4. The PC's CAN-Interface
       5. Terminals with integrated virtual COM port (USB-to-Serial adapter)
       6. Remote control (for devices without a keyboard)
       7. Transferring other files (with the File Transfer Utility)
   19. The UPT's internal System Menu
       1. Display-, Audio-, CAN-Bus-, and other items in the System Setup
       2. Network Setup (for TCP/IP, UDP, etc)
       3. Power-on/off behaviour of the device, e.g. Wake-up via CAN
       4. Unlocking 'special' features
       5. Remote Control (for the system menu)
       6. Storage Directory
   20. The Error Page
       
       1. Mousecklicks into the 'Errors & Messages' list
       2. Error classes an display of other messages (CAN, CANopen, ..)
       3. Display of the Trace History under 'Errors & Messages'
   
   
2. The Display Command Interpreter
   1. Numeric Expressions
      1. Numbers
      2. Numeric Operators
      3. Variables as part of interpreter expressions
      4. Inspecting interpreter expressions via mouse pointer
   2. Interpreter Functions
      1. List of interpreter functions by alphabet
      2. Keyboard Functions
         1. Extended kb()-function for devices with 32-bit CPU
         2. Detailed explanation of 'kh' and 'kc' (keyboard functions)
         3. System Key Codes returned by the 'kc' function
      3. Arithmetic and other functions
      4. Konvertierungsfunktionen 'val' (value) und 'eval' (evaluate)
      5. CANopen-specific functions
         
         1. PDO Functions of the Display-Interpreter (CANopen)
         2. SDO access functions (CANopen)
         3. CANopen-SYNC-functions
      6. Generic CAN functions: CAN bus status flag, CAN reception, CAN transmission
      7. String Functions
      8. String Expressions
      9. Real Time Clock functions
      10. Timer functions
      11. Bit-Counting function ("nbit")
      12. Functions to access non-volatile values (nv[0..31])
      13. Functions to read (onboard-) analog and digital inputs
      14. Functions for the rotary encoder knob (rot.xxx)
      15. Functions for an (optional) analog joystick
   3. Interpreter Commands
      1. Overview of interpreter commands
      2. Special display commands
      3. Timer commands and functions
      4. Page-Scan mode
      5. The assign-command (@, deprecated)
      6. The "Output"-command (out)
      7. The "CAN Transmit" command
      8. "System" functions and -commands of the interpreter
      9. Other special interpreter commands
   
   
   
3. The script editor / compiler / debugger
   
   
4. Appendix
   1. Frequently asked questions (separate document)
   2. Manuals for the programmable terminals (in PDF format)
   3. Boot Screen (optional graphics displayed after power-on)
   4. CANopen objects inside the UPT
   5. SDO error codes
   6. FAQs ("frequently asked questions")
   7. Troubleshooting (and older FAQs)
   8. Glossary
   9. Author's Info
   10. Revision history of the UPT family

Programming tool for CAN displays

Introduction

• show signals received via CAN bus in numeric form on the built-in display
• switch between different programmable display pages (like 'motor', 'gearbox', 'brakes'), controlled by the operator
• send special ("programmable") CAN messages in response to user input
• fast boot, only a few seconds between power-on and execution of the user's application
• low cost (the original device used an 8-bit controller and just a 128 * 64 pixel LC display)

• graphic display- and control elements like bitmaps, buttons, bargraphs, diagrams, tables
• a device simulator, integrated in the programming tool, to develop applications without 'real' hardware
• a script language to control those elements, and to 'talk' to external devices and control units
• support for larger displays (in 2015, up to 800 * 480 pixel TFT displays with 64k colours)

Example for a recent user-programmable display (2013) : MKT-View III with 2*CAN and Ethernet on the right side.
A list of devices supported by MKT's programming tool can be found in the feature matrix.

Keyword Index ("from A to Z")

Context- and Command-specific Help System

(Example using an alternative browser, on the author's PC installed under "P:\Iron_Browser")

Note: A few 'newer' devices with at least 4.3" display may have a built-in help system, invokable from the devices's System menu and certain submenus.

Some 'printable' manuals are located in "DOKU\MANUAL.DOC": "DOKU" ( a bit outdated), furthermore a description of the System Menu, and finally the special functions for terminals with CANdb (instead of CANopen). Note: The latter document is available in german language only.

Further infos (sample programs, translations into other languages, possibly some device descriptions) can be found in the index or on the MKT website.

Context-specific help:

• Press F1 if you need help on any component of the programming tool's user interface, for example if you want to know what the "display property"-window is for. Before pressing F1, click on the element (to set the "focus" to the dialog element).

Command-specific help:

• Press F2 if you need help on one of the interpreter commands of the User Programmable Terminal.
  For "simple" edit-fields, place the blinking cursor on the command you need help about, then press F2.
  For "tables", click into the cell with a command, leave the mouse on the command, then press F2.
  The programming tool will then try to analyze the contents of the input field where the cursor is blinking, and switch to the help page with information on that particular command.

Note on both types of "specific help":

• These help functions only work, if the main window of the programming tool is the "active" window. You can tell the active window from all other windows by the color of the window title, a blue window title usually indicates the active window.

For translators of the help system into other languages: please contact the author for details on the HTML anchor names !

New devices with at least 4.3"-display and sufficiently large Flash memory (e.g. MKT-View III/IV/V) have a internal help system ("browser") which can be opened from the device's System Menu. The internal help system only covers topics like the system menu itself, the CAN snooper, and other integrated diagnostic tools, but it doesn't cover the aspect of developing applications for the MKT-View. The 'built-in' help pages (in the UPT device firmware) can be extended or replaced by applications-specific pages. An example 'index'-page can be found in the subdirectory 'fonts'(!) after installing the programming tool, file index.htm. How to open the internal help system via script is described here (system.show_help), and the specification of the file format is here.

Disclaimer, Legal Issues

CANdb® is registered trademark of Vector Informatik GmbH.
NTCAN API is copyright (c) by ESD electronic system design GmbH.
PCAN Dongle and the PCAN API is copyright (c) by PEAK-Service GmbH.
Microsoft, Windows, Win95, WinNT, WinXP® are registered trademarks of Microsoft Corporation.
The Hershey fonts are a collection of vector fonts developed circa 1967 (!)
by Dr. Allen Vincent Hershey while working at the U.S. National Bureau of Standards.

The software and accompanying written materials (including instructions for use) are provided "as is" without warranty of any kind. Further, MKT Systemtechnik does not warrant, guarantee, or make any representations regarding the use, or the results of the use, of the software or written materials in terms of correctness, accuracy, reliability, currentness, or otherwise.

The entire risk as to the results and performance of the software is assumed by Licensee and not by MKT Systemtechnik or its distributors, agents or employees.

THERE ARE NO OTHER WARRANTIES, EITHER EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO
IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS
FOR A PARTICULAR PURPOSE,
WITH RESPECT TO THE SOFTWARE, THE ACCOMPANYING
WRITTEN MATERIALS, AND ANY ACCOMPANYING HARDWARE.

MKT Systemtechnik
Haßkamptraße 75-77
32257 Bünde (Germany)

Phone: 05223/493933-0
Fax: 05223/493933-20

Web: http://www.MKT-SYS.de

This software and appendant hardware may influence or control a CAN-based system or network. Your actions can therefore lead to severe damages. For this reason, only persons which have understood the possible consequences of their actions with this product may use it.

The manufacturer's warranty shall be restricted to the terminal hardware itself, but does not cover effects caused by its use in a CAN network. Neither MKT Systemtechnik nor its employees or partners will be liable for improper use of these products.

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.

If you do not agree to the above limitations, please uninstall the software, and send the hardware back to the distributor IMMEDIATELY. He will then refund the price you paid for the unit. Customers of MKT Systemtechnik please contact via email, info (at) mkt (minus) sys (dot) de.

Installation of the programming tool

If you also wonder why there are these three different programming tools, follow this link .

If the HTML-based help system doesn't work properly, you may modify the command line to invoke the browser (e.g. Firefox, Chrome / Iron, or if nothing else is available "Internet Explorer"), as described here. That way, you can use any browser as 'help system' for the programming tool, not necessarily the system's "default browser".

Notes on Windows Vista / 7 / 8 / 10

Unfortunately we never saw the installation on a PC with 'english' windows locale, so below is the german original, describing how to update the ‚CANdb-Terminal Programming Tool'

1. Programm starten (rechte Maustaste > Als Administrator ausführen)
2. Menüpunkt Hilfe / Auf Updates prüfen (per Browser)
3. Das MKT-Browserfenster öffnet. Wählen Sie den Link >here<, der
   Download wird automatisch gestartet.
4. Schließen Sie das ‚CANdb-Terminal Programming Tool‘ nachdem der
   Download beendet ist.
5. Wichtig: Installieren Sie dieses Update aus dem Download-Ordner Ihrer
   lokalen Festplatte (rechte Maustaste > Als Administrator ausführen)!
6. Folgen Sie den Anweisungen. Danach starten Sie das ‚CANdb-Terminal Programming Tool‘ neu,
   Sie arbeiten nun mit der aktuellsten Version.

Another annoyance related with Windows 7/8/9(?) are the desktop icons, created by the installer. By default, they will also try to launch the program without admin rights.
Consequence: The program is unable to write its own configuration file (*.INI), located in its own directory. Thank you, Microsoft. Workaround: Modify the desktop shortcut ("icon on the desktop") to launch the programming tool as administrator.
Here is how to achive this with a certain flavour of windows 7 (as usual, things may be different in other and future versions of windows..) :

1. After installing the program, right-click the shortcut ("icon on the desktop")
   
   
2. In the context menu, select 'Properties' ( ? - 'Eigenschaften' on a German PC )
3. In the dialog window which appears then, select 'Compatibility' (tab or menu or whatever..)
4. Set the checkmark for option 'Run this program as administrator' ( ? - 'Programm als Administrator ausführen' on a German PC)
5. Click OK to close the dialog window

Reason for the necessity of an administrator accound under Windows 7 / 8 / 10 :
In opposition to earlier windows versions, these days Windows doesn't grant write permission for files which have been placed in the application's own directory (see examples below). But, for tradional reasons, the installation script keeps 'all files in one place' instead of spilling all over different folders of your harddisk (like, in german, those annoying "Eigene Dateien", "Dokumente und Einstellungen", and similar crap which changes with each new version of Windows). For that reason, you will still find the examples in the following folder :

PC with 'german windows' :

C:\Programme\MKT\CANdbTerminalProgTool\Programs\*.cvt;  *.upt

PC with 'english windows' :

C:\Program Files\MKT\CANdbTerminalProgTool\Programs\*.cvt;  *.upt

oder (possibly, depending on where Microsoft wants to have 32-bit applications installed) :

PC with 'german windows' :

C:\Programme (x86)\MKT\CANdbTerminalProgTool\Programs\*.cvt;  *.upt

etc...

If you prefer to follow the "new rules" (by Microsoft) and store 'your files' where they want you to, you can change the default directories after installation of the programming tool, on the tool's 'settings' tab.

Alternative to circumvent the trouble with "Vista" or Windows 7 and non-writeable folders and stupidly padlocked files ():
Do not install the program where Microsoft wants you to install everything.
Instead, install the software in a directory of your choice (where you will have unlimited write permission), outside the Microsoft-dictated 'Programs' folder. For example (again, on a German PC):

Instead of installing the software somewhere under

"C:\Programme\MKT\xyz",   alias   "C:\Program Files\MKT\xyz", or wherever they want you to,

install the software under

"C:\MKT\xyz" .

• C:\Documents and Settings\All Users\Documents\no idea where.. (Windows XP, english)
• C:\Dokumente und Einstellungen\Alle Benutzer\Faselblah\keine Ahnung wo.. (Windows XP, deutsch)
• C:\Users\Public\Public Documents\...?...\no idea where.. ("Vista", english)
• C:\Users\Frustrated Windows User\Documents\Where the heck are MY FILES\..??.. (some other PC)

If you used the suggested destination (for the programming tool), you will find the samples for your target device at:

c:\MKT\CANdbTerminalProgTool\programs	(with subdirectories for different targets)
c:\MKT\CANdbTerminalProgTool\programs\script_demos	(Examples for devices with script support)
c:\MKT\CANdbTerminalProgTool\programs\MKTview2	(Examples for MKT-View II / III, most without script)
c:\MKT\CANdbTerminalProgTool\programs\MKTview4	(Examples for MKT-View IV, most using scripts)

After the installation: Check if a firmware update is available or necessary

Hint:

When invoking 'Check for Update (via browser)' in the tool's 'Help' menu, you will see an excerpt from the version history, with the latest changes on the beginning of the list. Some of these modifications don't just apply to the programming tool, but to the device firmware.
So you can decide for yourself if you need those 'new features' or not.
If your web browser cannot be invoked via the tool's Help menu, you can reach the same website from here through the following link:
www.mkt-sys.de/check4update/ctptwin1.htm

Example:

MKT-View III with CANdb + Logger  ISO-Date: 2013-07-22 16:24:00 Software: art11392 V0.2.4-1 (...) Compiled: Jul 24 2013 (RV) (...) press ENTER to quit

Explanation:

'ISO-Date' is the current date and time in ISO-format. It doesn't have anything to do with the firmware compilation date !
'Software' is the identification of the device firmware, including the software article number (art...) and the version number (Vx.y.z-b) .
'Compiled' is the the firmware compilation date. Details about this in the next sub-chapter.

                       
(Links to the Feature-Matrix - click on image to check if there's a "CANdb" or "CANopen" firmware available for your device)

Details about the Firmware Compilation Date

Example:

On November 27, 2009, the syntax of certain graphic display elements has been modified in both the programming tools, and in the firmware of a few devices produced by MKT. Since then, the width and height of a display element is entered in two extra columns of a page's display definition table. Older devices (for example the old "MKT-View") don't support this, and thus loading a "new" application into such an "old" device would cause problems.

To avoid such problems, the programming tool will only show the columns "W" and "H", if the firmware compilation date is at least 20091127 (ISO8601, YYYYMMDD).

Originally, the programming tool was always connected 'directly' (via CAN or RS-232) to the programmable device, and could read the compilation date of the device when downloading or uploading the application.

With the more-common method of "transferring" the application "as a file on the memory card", this is not possible anymore, because no data can be transferred from the programmable device back to the PC / programming tool !

Due to this 'unidirectional' transfer (from PC via memory card into the device), the programming tool can only be informed 'manually' if about the firmware revision / compilation date of the to-be-programmed device. The device's firmware compilation date can be read out through the system menu . Details, and how to invoke the system menu, are in document #85115.

Example: "Old" MKT-View (MKT-View "Plus"), Firmware #11089 .

Compilation date 2008-12-02 (shown as "Compiled: Dec  2 2008" in the ugly __DATE__-format of the C-Compiler)
The value displayed in the programming tool under "Settings"..."Terminal constants"..."Firmware compilation date" must never exceed 20081202 then.
Otherwise, there may be the risk that you use a feature in the programming tool which doesn't exist in the firmware yet !
If necessary, the date can be modified via mouse click on the compilation date (numeric value in ISO-8601 format)

You can check if there is a newer firmware (along with a newer programming tool) through the menu  "Help" .. "Check for Update", or (if a stupid or paranoid web browser doesn't co-operate) in the file readme.txt in the "firmware" folder after installing a new programming tool .

Known problems with older firmware are listed in the firmware Release Notes .

See also: firmware update, software revision history (web link) .

Program start with or without 'disclaimer'

"Disclaimer" dialog, displayed on program start

Removal of the programming tool's 'Disclaimer'

In the main menu, select "Tools"..."Remove disclaimer on startup".

The same password dialog may also pop up in other situations which require a higher level of authorisation, for example when updating device firmware.

The Main Window

• define Communication Channels
• configure the supported communication protocols like CANopen or CANdb (depends on the tool used)
• define Variables that use Communication Channels
• define Display Pages that you want to have on the User Programmable Terminal
• define Icons for your terminal application
• show an overview of all your "programmed" display screens
• display and modify some settings of the device and the programming tool
• show errors in an error history window

The programming tool's main menu

File

Functions to load application from a file (*.upt or *.cvt), save as file, define password for the application, etc.

Assistant

may help you to create simple applications, or invoke dialog screens to link menus in the terminal, and replace variables (which are shown on the current display page)

Edit

Contains a global search function, and functions to create and modify display pages. Many other "editing" functions can be invoked through popup menus when clicking on the control elements with the right mouse button !

Transfer

transfer the application into the terminal, firmware update, selection of the (serial) interface

View

Switch to other windows of the programming tool, for example:
    LCD simulator, Watch window, Test Command Window, File References.

Options

Modify options of the programming tool, query supported graphic functions, change memory distribution in the terminal. The following options affect the appearance of the programming tool's user interface (GUI) but not the application created with the tool:

User profile "Novice" :

Novices may configure simple numeric displays by picking signals from a list, and mainly (almost exclusively) use the 'simple' graphic editor.
The programming tool only displays the basic tabsheets which are 'always' required to create a very simple display application.

User profile "Intermediate" :

The more experienced user doesn't freak out when seeing a lot of tabsheets in the upper part of the programming tool (he knows which one to chose). The programming tool still starts with the graphic editor instead of the tabular display (with 'all display elements on the current page').

User profile "Expert" :

An expert user prefers to enter sourcecode directly (for the display definition and the script), and is familiar with tables, pixel coordinates in numeric form, the versatile format strings.
In this mode, the programming tool starts with the tabular display of all elements on the first display page. The Expert knows how (and when) to switch between graphic and tabular display. He sees all tabsheets in the programming tool.

The user profile can also be selected in the 'Disclaimer' dialog, before the tool's main window opens.

Tools

Invoke internal tools or external auxiliary programs, which may be installed additionally - for example the font editor, CAN logger utility, CAN Bus Simulator, etc.

Icon

Import graphics from bitmap files

Run, Stop, Reset

start, stop, and reset the simulated application on the PC (firmware simulator integrated in the programming tool).
Note: An application can only be edited while the simulation is stopped.
'Reset' (in the programming tool's main menu) simulates a power-on reset (aka 'cold start' of the target. 'Run' resumes the program (and script-) execution at the point where it was stopped (manually) or paused (by hitting a breakpoint).

Help

Show help on various topics. Requires a properly installed HTML browser, but not necessarily an internet access

Status Bar

The second panel from the left (here: "Running") shows a quick info about the current state of the programming tool or the application program. Some possible labels are:

• Running: Your application is running (i.e. it is being executed)
• Stopped: Your application has been stopped for any reason (e.g. hitting a code- or data- breakpoint)
• Transfer: A program upload or download is in progress.

The right field in the status bar will display the last error message (if any) or other system messages. In the example shown above the last system message was an indication that the CAN interface has been successfully initialized.
You may switch to the error page by double-clicking into the status message field.
The rightmost field in the status bar may also show info about the 'word' (or sub-expression) currently under the mouse pointer. For example, the current value of a variable, expression, or sub-expression can be inspected by hovering over certain grid cells with the mouse as explained here. The display of the last error message has priority over 'mouse pointer info' in the status line. To clear a (static) error message in this field and switch back to 'inspect-anything-via-mouse' - mode, click into the message.

For debugging purposes you may also send a command string to the UPT's command interpreter by typing it into the rightmost statusfield.

return to the description of the main window

LCD simulator window and device-dependent selections

The LCD simulator window is used to show the contents of the LCD screen, which you would see after loading your application into the user programmable terminal.

This window shows the current display page.

As long as the LCD simulator window has the "input focus" (blue title background), all keyboard inputs will be passed on to the terminal simulator.

This allows you to test your programmed event handlers etc.

The LCD simulator window can be moved and sized independent of the main window. You may even maximize it to a real "full screen view". The panel below the simulated display shows the state of (optional) LED's, digital in- and outputs. If you don't need this, or run out of (PC-)screen space, turn the lower panel off through the simulator's menu.

By clicking into the LCD simulator window with the left mouse button, you can select (or move) a single text display line. The MAIN window of the programming tool will automatically switch to the display definition tab ("Page N") where you can modify all properties of the selected line.

Holding the left mouse button pressed on a visible display line in the simulated display while slowly moving the mouse allows to move the display line aroud (only works for normal text display lines, not for general graphic commands like "line", "rectangle" etc).

When simulating terminals with a touchscreen, the left mouse button is the replacement for the "finger" (or touch pen). To check if the simulated device has a touch screen or not, use the dialog for supported graphic functions.

Clicking into the simulator window with the right mouse button opens a popup menu, which allows you to insert several display elements on the current page, and to enable the mouse wheel as a replacement for the terminal's rotary encoder knob (while the simulator is running). The option 'stay on top' (ex: 'always in the foreground') may be helpful if you only have one monitor connected to your PC, and want to debug the application (or the script) with the tool's main window maximized.

If there are many overlapping graphic elements on a display page, it may be difficult to select a certain element via mouse-click in the LCD simulator window. In such cases, as an alternative, you can use the mousewheel to switch to a certain display element, while the input focus is on the definition table (in the main window). This is possible because the 'synchronisation' of the currently selected object in the LCD simulator and the display definition table works in both directions (from simulator to definition table, and from definition table to simulator).
To have all display elements temporarily marked in the simulator, press and hold the Control key (aka 'Strg' on a german keyboard). This feature was initially used for software development, but it also helped a lot when trying to understand a customer's display application, which used a lot of overlapping graphics. With that option enabled, graphic areas will be marked by transparent markers with different colours (to distinguish them when overlapped), with the number (zero-based index) of the display element in the upper left corners:

Display in the LCD simulator with multiple transparently marked elements.
The simulator can be configured to mark objects 'never', 'always' or via CONTROL key.

Independently of the transparent colour markings shown above, when clicking into the LCD simulator (unless 'running' a simulation), the programming tool tries to find the definition of the graphic object, and -if successful- switch to the object's definition, to highlight the definition on tabsheet 'Display Lines' or 'Other Commands' (depends on where the object was found). In any case, since a single definition line may contain multiple graphic objects (or areas), the part of the string that rendered the object will be highlighted by a green background in the table.

You can copy the contents of the simulated LCD into the windows clipboard through the simulator's menu (button), "Copy image to clipboard". This simplifies making screenshots of the simulated LCD screen for the documentation (e.g. user's manuals, etc). You can also transfer screenshots from a real terminal into bitmap files using the snapshot via CAN utility.

If the LCD settings of the simulator don't match the display in your target device, you have to enter the LCD simulator settings to adjust them.

Hint regarding the LCD simulator's "frame" or background image:

To align graphic buttons or other objects close to the function keys of the terminal's keyboard, turn on a suitable background picture for the LCD simulator (in the simulator's menu). In the backgrounds folder, you will usually find the right picture (bitmap) for your keyboard. If not (for example because you use a customer specific keyboard) :
For customer-specific keyboards, usually only the surface will have a different "look", but the position of the keys will usually not be modified. So one of the standard images should be ok. If not, you can make your own background picture with a paint program as a bitmap file. Please note, the black framed region of the LCD must exactly match the size of the simulated display in pixels. Everything inside the LCD must remain white !
For a self-defined background image (like lcdsim_XYZ.bmp) you must also create a matching description file (lcdsim_XYZ.txt) with the graphic coordinates of the keys (which can be clicked to simulate pressing a key). A good example for such a 'background image description' is the file for the MKT-View II .

lcdsim_128_64.bmp, used for the old UPT 515 (128*64 Pixel) .	lcdsim_128_160.bmp, used for HBG 18 (128*160 Pixel) .	lcdsim_abe167.bmp, used for 'ABE' handheld (128*64 Pixel) .
lcdsim_320_240.bmp, used for old MKT-View (320*240 Pixel) .	lcdsim_scandi320.bmp, an OEM design (320*240) .	lcdsim_mktview_2.bmp, used for MKT-View II, III (480*272 Pixel) .
lcdsim_dt85.bmp, used for DT85 (320*240 Pixel) .	Your design here ?	lcdsim_no_background.bmp : Select this file if no background image shall be displayed in the LCD simulator.

return to the table of contents

Device Selection / LCD Settings

Since the introduction of large displays, the programming tool supports different types of displays. Usually the programmig tool will detect the type of the display automatically when uploading or downloading a UPT file from (or into) the target. All required information about the display is stored in the UPT program file. So, if you load a UPT file from disk, the proper LCD settings are automatically adjusted.

If you have no possibility to connect the programming tool to a target, you must define the LCD type of the simulated device yourself (otherwise the simulated screen will look very different from what you will see later..). To do this, enter the following dialog (from the Main menu, "Options" ... "LCD settings"):

Some example settings:

UPT515:

Screen width=128, Screen height = 64, Display type = 1 (monochrome)

UPT 167 "monochrome", IPE-View, MKT-View:

Screen width=320, Screen height=240, Display type = 1 (monochrome)

UPT 167 "Color":

Screen width=320, Screen height=240, Display type = 4 (4 bits per pixel). Discontinued, replaced by "UPT 320 Color" .

MKT-View, MKT-View "+":

Screen witdh=320, screen height=240 Pixel; display type=1 (monochrom)

MKT-View "+", CANdb or CANopen, mounted for "Portrait Mode"

Screen width=240, height=320 Pixel; Anzeigetyp=1 (monochrom)
(Your application must be written for portrait mode right from the start !
The programming tool cannot convert a program from 320*240 to 240*320 pixels automatically)

MKT-View II, Landscape

Screen width=480, height=272 Pixel, TFT with 256 different colours (8 bit / pixel), touchscreen.
This is the default configuration for the MKT-View II, when mounted with the connectors on the right side of the device.

MKT-View II, Portrait

Screen width=272, height=480, used for MKT-View II when mounted with the connectors on the bottom of the device.
Similar 'Landscape' / 'Portrait' options are available for other devices, too.
See also: Selecting clockwise / counterclockwise rotation in portrait modes.

MKT-View III, with Landscape and Portrait mode

Screen resolution 480 * 272 or 272 * 480 Pixel, 4.3"-TFT with 65535 colours (16 Bit/Pixel). Successor for the MKT-View II with a faster CPU (Cortex-M3).

MKT-View IV, with Landscape and Portrait mode

Screen resolution 800 * 480 or 480 * 800 Pixel, 7"-TFT with 65535 colours (16 Bit/Pixel). Funktionalität similar to MKT-View II/III, but faster CPU, and significantly larger.

MKT-View V, with Landscape and Portrait mode

Successor to the MKT-View III with similar size but much faster CPU, and at least one CAN FD capable interface (details were unknown in 09/2019).

UPT 320 "Color":

Screen width=320, height=240 Pixel, 5.7" TFT with 65536 different colours (16 bit / pixel), touchscreen, rotary encoder button, ARM CPU, keyboard with 6 (?) keys.
Replacement for the discontinued "UPT 167 color". Firmware available for raw CAN / CANdb (#11352) and for CANopen (#11353) .

UPT 800:

7" - Display panel with 800 * 480 pixel ("WXGA") TFT, 65536 colours (16 bit / pixel), Touchscreen, but neither rotary encoder button nor keyboard.
Designed for panel mount. So far (2011-11), only available as prototype with "CANdb". Firmware #11372 (for Controller type LPC2478, ARM-7, not ARM-11).

If a standard device (with standard firmware!) is used, the programming tool will know everything it needs to know about the target from an internal database.
All these settings are updated when selecting Options...Device Selection / LCD settings from the tool's main menu.

See also: Feature matrix (for various targets), Settings (tab), supported graphic functions (dialog), Table of Contents

Communication Channels

This page is used to define the communication channels which the terminal uses to exchange data with other devices on the CANopen network.

There are different types of communication channels:

• SDO channel (Service Data Object)
  a "slow"device-to-device connection which allows to exchange data from a device's object dictionary. Many different objects can be accessed through a single SDO channel !
• PDO channel (Process Data Object)
  a "fast" communication channel which is used to transfer process data with a high priority, for example digital inputs, analogue values from sensors etc.
• 'Signals' defined in a CAN-file
  This optional functionality is only implemented in the programming tool for terminals with CANdb-functionality and therefore not explained here.
  Details about variables connected to generic CAN signals ("CANdb"-signals) are here .

The type of a communication channel is implicitly defined by a variable's channel number (if it is connected to a communication channel).

Note that the terminal should only "listen" to PDO channels. It can not request the transmission of a PDO from another device (because this may cause a lot of trouble ...)

You have to define at least one communication channel for every device that the terminal shall communicate with. The channels will later be used to transfer values from other devices into the variables of your terminal program.

related topics: Variables on SDO channels , Variables on PDO channels , Receiving CAN messages which are neither connected to 'variables' nor 'signals' .

return to the table of contents

SDO Channels

Note:

SDO channels are not supported by the MKT-View terminals with 'CANdb' !
Only for a few devices (like MKT-View II,III), there is also a firmware variant which supports CANopen.

SDO channels provide a versatile but "slow"device-to-device connection which allows to exchange data from a device's object dictionary.

You have to define the CAN-identifiers of all SDO-channels which the terminal shall use to communicate with other devices. You can do this later with a CANopen configuration tool (if you have one), or in the SDO-channel table:

You will find the Identifier values in the description of the device that transmits a particular PDO or in the CANopen Draft Standard 301 (CiA "DS301"). Most I/O-devices use a "pre-defined connection set" with the following definitions for the SDO's CAN-Identifier (which DS301 calls "COB-IDs").

SDO(server->client) : CAN-Identifier = (1408+node-ID) = 1409...1535

SDO(client->server) : CAN-Identifier = (1536+node-ID) = 1537..1663

All CAN-Identifiers here are decimal values. The "client->server"-ID will be transmitted from the client (which is the UPT) to the server (which may be an I/O-module) to initiate a transfer ("request"). The "server->client"-ID will be transmitted from the server to the client (as "answer"). If you prefer hexadecimal notation for the CAN-IDs, you can change this on the ID format panel.

Hint: If you erase all cells in the above table, only enter the server node ID's, and click "Apply" afterwards. The tool will then fill out the missing CAN ID fields according to the predefined connection set specified in CANopen DS301.

Always be aware:

An SDO connection is just a "point-to-point" link between two partners. You must take extra care to use only SDO connections that are not yet occupied by other devices. If a simple I/O-device only has one SDO channel and this SDO is already occupied by an other device (maybe a PLC, SPS, a servo drive or something else), you must not connect the UPT to this device via "active" SDO request because this would cause severe collisions on the network (same CAN-ID transmitted by several devices, SDO protocol violations etc.).

In the User Programmable Terminal, a variable can be connected via SDO to an other device in the network. With the newer "MKT-View with CANopen" and other (newer) UPT's with 16-Bit-CPU it is possible to read values through the build-in SDO client via interpreter funktion "sdo(<index>.<subindex>)", without using a variable.

See also:

• Variables on SDO channels
• The CANopen Object Dictionary (one of the key elements of CANopen!)
• CANopen object index and subindex
• Using SDO channels (clients) in the script language: cop.sdo, cop.sdo2
• EDS files (electronic device specification)
• Features for devices with 'CANopen V4' (applies to most devices by MKT with CANopen and a 32-bit CPU) .

PDO Channels

Note:

PDO channels are not supported by the "CANdb" terminals (CAN without CANopen) !

PDO channels provide a "fast" communication channel that is used to transfer process data with high priority, for example digital inputs, analogue values from sensors etc. One PDO telegram can carry different parameters (if the transmitting device allows "variable PDO mapping"). More info can be found in the CANopen standard published by CiA.

In contrast to SDO-Channels, a single PDO-channel is always a one-way-street where the flow of traffic cannot be reversed during operation.

The following table is used to define all PDO channels ("RX" and "TX"):

For any PDO channel that you want to use in your application, you have to define:

• the CAN-Identifier used by the PDO (sometimes called "COB-ID"),
  can be set to the default value (according to DS 301) with the button 'Default IDs'.
  Use the button labelled 'Communication..', or double-click into the 'CAN-ID' column to open a Dialog to modifiy the PDO Communication Parameter - it may be easier for you to pick the values from a dialog instead of entering them in the PDO table.
• the transmission direction (transmit, receive or "be passive")
• the transmission type as it is defined by the CANopen-standard. Similar as for the 'COB-ID' (CAN-ID), it may be easier to use the PDO Communication Parameter dialog to pick one of the quite 'cryptic' PDO transmission types.
• the transmission cycle ,
• and –possibly- some flags to activate "special" PDO functions .

In the (old) User Programmable Terminals like UPT515, a variable should be used to receive values from a PDO channel, or to put some data bits into a PDO which will later be transmitted, depending on the PDO‘s transmission type.

In the (newer) UPT II (like UPT320, UPT800), there are special variables in the CANopen Object Dictionary, which solely exist to be mapped into PDOs. They can be accessed from the application through their CANopen-index and -subindex (using the obd()-function), or be tied to interpreter variables. Because these variables do always exist, they are listed in the terminal's EDS-file, and can therefore be used by any CANopen configuration tool to setup the PDO communication in the network. More on that in the document about CANopen "V4" .

Be careful when tansmitting PDOs on a CAN-network which you do not know exactly ! Transmitting a PDO with the wrong identifier may cause a minor catastrophy - just imagine what would happen if you accidentally started an electronically controlled motor which *should* be off...). For this reason, the UPT was originally not able to transmit CAN messages, but "receive only" (this limitation had to be removed when someone wanted to use the UPT515 as a kind of PLC). Usually a CANopen device configurator / network configuration manager is used to configure "everything" in the network, including the process data channels. In newer devices with CANopen V4 (see Feature Matrix) the PDO's are controlled exclusively through the PDO communication- and mapping parameters, which are part of the standardized CANopen communication profile. So these parameters can be accessed from any CANopen configuration tool, after you loaded the application into the terminal. More information on this can be found in an extra document.

In a CAN network it is not allowed that more than one device transmit the same CAN identifier. Therefore the terminal should only "listen" to a PDO channel.

With the old UPT515 (since September 2001), it was possible to modify some of the PDO channel definitions with the UPT's interpreter. See PDO-Functions .

For terminals with CANopen V4 (since April 2005, see feature matrix), the PDO parameters can NOT be modified through the interpreter - instead, they can only be controlled through the terminal's local CANopen object dictionary !

See also:

• variables (of the interpreter)
• variables on PDO-channels
• channel number of a variable (which defines the type of the communication channel, too)
• fixed-type variables in the CANopen object dictionary of the terminal ("CANopen V4" only), which can be accessed through the function obd(<index>.<subindex>) .

PDO CAN Identifiers

PDO1(tx) : CAN-Identifier = (384+node-ID)₁₀ = 385...511

PDO1(rx) : CAN-Identifier = (512+node-ID)₁₀ = 513...639

PDO2(tx) : CAN-Identifier = (640+node-ID)₁₀ = 641...767

PDO2(rx) : CAN-Identifier = (768+node-ID)₁₀ = 769...895

All CAN-Identifiers here are decimal values. Note that "tx/rx" in this table has to be seen from the I/O-devices point of view, so the "tx" PDO's are transmitted by an I/O-module and can be received by the UPT. The possible values for node-IDs are 1..127. Simple devices like I/O-Modules often use a DIP-switch to set the node-ID.

Example:

You want to receive the state of digital inputs of an I/O-Module. The I/O-Module uses its PDO1(tx) to transmit process data, which contain the digital inputs. The node-ID of the I/O-Module is set to "1", so the resulting CAN-Identifier will be (384+1)=385(decimal).
To receive this PDO with the UPT-Terminal, you want to use the first PDO-channel of the UPT. Just enter the value "385" in the column "CAN-ID of PDO". The UPT is now able to receive a PDO with this identifier, and you may define variables that use the PDO data as "input values".

Note:

Changing a CANopen device's node-ID shall affect the PDO CAN identifiers, according to the 'predefined connection set' specified by CANopen CiA "DS301". If your applications requires a different CAN identifier for a certain PDO, first change the node-ID (which resets most CAN-identifiers to the defaults), and after that modify the CAN-IDs on the 'Channels' tab under 'PDO', as shown in the screenshot further above.
This is always necessary if two (or more) CANopen slaves shall exchanged data via PDO directly, without a CANopen master (-> "PDO Linking") .

PDO Transmission Direction

Since the year 2000, displays with CANopen supports Reception and Transmission of PDOs. Therefore you have to specify, if a PDO channel shall receive(1), transmit(2) or be passive(0). For devices with CANopen V4 (since 2005), the transmission direction is fixed for all PDO channels like in an ordinary CANopen device. See feature matrix .

Note: "Transmit" and "Receive" must be seen from the UPT's point of view.

PDO Transmission Type

Since 2000, displays with CANopen support different types of PDO transmission.

The PDO transmission type is defined by a numerical value. It is taken from CiA DS301.

You may find more information on this in CiA Draft Standard 301, Version 4.0 (16.6.1999), Page 9-83 in the description of Objects 1400h-15FFh (PDO Communication Parameter), Table 54, "Description of transmission type":

PDO Transmission Type	Cyclic	Acyclic	Synchronous	Asynchronous	RTR only
0		X	X
1-240	X		X
241-251 reserved
252			X		X
253				X	X
254				X
255				X

A transmission type of zero means that the message shall be transmitted synchronously with the SYNC object but not periodically (?????).

A value between 1 and 240 means that the PDO is transferred synchronously and cyclically, the transmission type indicating the number of SYNC which are necessary to trigger PDO transmissions/receptions.

The transmission types 252 and 253 mean that the PDO is only transmitted on remote transmission request. The UPT515 treats both 252 and 253 exactly the same way.

Transmission type 254 is "manufacturer specific" (which is not defined yet).

Transmission type 255 is "defined in the decive profile" (which does not exist here).

For transmission types 254 and 255 you can use a PDO's Event Timer for cyclic (but not sync-related) transmissions. See transmission cyclePdo_TxCycle.

Since August 2013, the PDO transmission type can also be modified in a special PDO Communication Parameter dialog.

PDO Transmission Cycle

Only for the old "UPT515": Special PDO Channels

• Byte[0] = UPT run mode (e.g. 1 = "running")
• Byte[1] = digital Inputs of the UPT
• Byte[2] = current display page of the UPT
• Byte[3] = Key-Matrix[0], the "first" 8 keys of the keyboard driver.
• Byte[4] = Key-Matrix[1], the "next" 8 keys of the keyboard driver.

You should leave all flags "zero" to use flexible TX-PDO-Mapping from Variables. Again, the fixed 'system PDO' described above only exists in the old "UPT515" with 8-bit CPU. All newer, user-programmable CANopen terminals (with 16- or 32-bit CPU) use flexible PDO mapping so we don't need this 'fixed' mapping anymore.
(On this occasion: Early samples of the UPT128 used a membrane keyboard labelled 'UPT515', but in fact the UPT128 is not a UPT515: It has a modern 32-bit CPU inside, not a stoneage 8051-compatible controller).

PDO Mapping

Generic CAN Channels ("CANdb")

Application Variables (display interpreter variables)

All variables are defined in a table, their properties can be edited in the table or on a special property panel.

Most of your variables will be connected to a communication channel, but they can also be used as internal variables which keep temporary values etc.

Notes:

• All "display variables" can be accessed by the display-interpreter, which means a variable name can be a part of a numeric expression.
• The name of a variable must always begin with an upper-case letter, and it may never have more than 8 characters. Only in certain devices with CANdb functionality up to 16 characters may be used (see constant parameter "max var name length" under Settings).
• The above limitation does not apply to script variables ! Script variables are not defined on the tabsheet 'Variables'. Instead, they are declared the script sourcecode.
• To assign a new value to a variable during run-time, use the assign command ("@"). This only makes sense for ('display'-) variables which do not receive their values from a communication channel.
• To show the value of a CANopen object on the screen, you don't need to connect it to an application variable. You can access any CANopen object (inside the device's own CANopen object dictionary) by its CANopen index and -subindex ( obd(index.subindex) ).

Related topics:

• Connecting variables to display lines with a special dialog
• Communication Channels
• Variables on SDO-Channels (only for certain terminals)
• Variables on PDO-Channels (only for certain terminals)
• Variables linked with objects in the terminal's own CANopen OD
• Variables on CANdb-SIGNALS (only for certain terminals)
• CANopen object index and -subindex
• Variables as part of a numeric expressions for the interpreter
• Components of a variable which can be accessed via interpreter
• fixed-type, fixed-index CANopen variables (only for devices with CANopen V4)
• Inspecting variables remotely, using an internet browser (only for devices with ARM-CPU)
• Finding all references to a variable (in global events, local events, display pages, etc)
• a href="scripting_01.htm#variables">script variables

Properties of display variables

(Example of a table with variable declarations; here for CANopen)

• Name : Up to 8 characters for small systems (like UPT515), otherwise up to 16 characters
• OD-Index : Only for CANopen; non-empty means this variable is connected to one of the objects
  in the terminal's own CANopen object dictionary. Details here .
• Channel : Defines if and how a variable is connected with the outside world :
  0...4 = SDO client (CANopen), 5...9 = SDO server (CANopen), 10..19 = PDO (CANopen),
  30 = connected to a so-called signal which is defined in a DBC-file ("CAN per database", not CANopen)
  31...99 = reserved for future communication channels (device specific)
  100...149 = reserved for devices which have more than 5 CANopen SDO clients
  150...199 = reserved for devices which have more than 5 RPDOs (Receive-PDOs)
  200...249 = reserved for devices which have more than 5 RPDOs (Receive-PDOs)
  250...254 = reserved for future, "exotic" communication channels
  255 = this variable is not connected to the outside world (it only exists "internally").
  The programming tool automatically shows the meaning of the numeric code in the definition table.
• Channel-params: PDO / SDO / CANdb_signal_definition (channel type specific)
• Update Time (or "cycle time" for CANdb-signals)
• Data Type: Should be modified only for 'internal' variables !
• Unit (only for CANdb, where physical units are defined in a database)
• Access Rights: 0=read only, 1=read/write, 2=write only
• Flags: Automatically filled in by the tool (where applicable)
• Value Table: May have been imported from a CAN database. Certain 'special values' may be displayed as one of these strings instead of a numeric value (e.g. "SNA" = "Signal Not Available" instead of 255 for an 8-bit signal).
  Syntax: <decimal value 1>=<display string 1>,<decimal value 2>=<display string 2>, ..
  Example: 255=SNA,0=off,1=idle,2=normal,3=max dry,4=max reheat,5=combat
  To show the matching entry in a value table (instead of e.g. a decimal number), set the display element's numeric base to ZERO (='automatic', which means 'if there's a value table, show the matching entry if possible, otherwise show the value as a decimal number); instead of Base = 10 (which means 'always show the value as a decimal number').
  If necessary, a variable's value table can also be edited in the programming tool instead of modifying it in the CAN database (which would include re-importing the modified database). To edit the value table, double-click into the cell in the 'Value Table' column. This opens an editor with one value/text pair per line, which makes editing items easier than editing the long string of value=text pairs in a single cell of the 'Variables' definition table.
  

  

  The value-table editor shows the decimal value on the left side, and the display text on the right.
  See also: Details about signal value tables from CAN databases and the 'decoding process'.
  
• Default Value
• min, max: Limit the value for display and editing (on screen).
• factor, offset, divisor: Used to convert the value sent via CAN-bus into the physical value.
     Do not modify these parameters manually; they are usually taken from a database (CANdb) !
• DAQ channel number (DAQ = data acquisition unit; optional; details here )

During the simulation (in the programming tool), the current values can also be displayed in an extra column of the definition table. To activate this option, check Show current values in the table (last column) in the context menu.
Alternatively, a variable's current value can also be inspected by hovering over the variable name with the mouse as in most other definition tables.

Most properties of a variable can be modified on this "property"-panel:

Some properties (components) of a variable can also be accessed during run-time of the terminal application from the UPT's interpreter.

Udate-Time of a variable

Only for variables which are connected to CANdb-"signals":

Here the 'update time' has the meaning of a 'transmission cycle time'.
In old devices (like MKT-View "Plus"), the cycle time also affected the strategy for allocating message-objects in the 'Full CAN' controller.
For transmitted CAN signals (from the MKT-View's point of view), the 'Upd-Time' parameter defines the transmit cycle (for periodically transmitted CAN frames).

If necessary, the transmit cycle can be modified at runtime as in the following examples:

      ThreeSines1.cy := 0;    // Turn off periodic transmission
      ThreeSines1.cy := 300;  // Periodically transmit every 300 ms

(Source: Test/demo application ?/programs/CdbSendT.cvt, page 4)

Data-Type of a variable

• UPT515: Variables which are connected to CANdb signals may be handled as floating point values internally. The mantissa only contains ~~24 bits. Values like 1000000.05 cannot be stored in this kind of "short" floating point variables !
  
• You can determine the (CANopen-compatible) data type of a variable at runtime using the "ty" property ("type").
  
• To convert a numeric data type code (a la CANopen) into a human-readable string, use the function type2str() (type-to-string) .

Access Rights of a variable

For example:

A variable is connected to an analog output of an I/O-module via SDO, and you want to set the voltage of that output with the terminal. After assigning a new value to the variable (by editing it or by assigning a value with the assign-command), the terminal will send a "write request"-telegram via SDO to the I/O-module to update the output. The variable must be writeable for this purpose.

A "read-only"-Variable will never be transferred to an external device via communication channel.

A "write-only"-Variable will never be read from an external device via communication channel.

With a few exceptions (for CANdb) below, the access-rights of a variable are coded as numeric values according to the CANopen-Standard.

Possible values are in this case (CANopen):

0 = Read Only
1= Read/Write
2 = Write Only

For variables connected to CAN signals, the column "Access" in the variable definition table shows if the signal is receved or transmitted from the terminal's point of view.
(Reception is the normal case, Transmission will only be possible with new firmware since November or December 2009) .

Possible "Access" values are, in this case (CANdb):

RX = The terminal receives this signal from the network (and all other signals contained in the same CAN-message !)
TX = The terminal transmits this signal into the network (and all other signals contained in the same CAN-message !)
In contrast to CANopen, combined read/write access (as in CANopen) is impossible in this case,
because a CANdb file doesn't specify any protocol for that !

Finding all references to a variable, function, signal, string, etc (globally)

• Click into the variable definition table on the name of the variable (here: Tank1Level).
• Click on the 'Menu' button above the table, or click into the table with the right mouse button

(screenshot of the context menu for the variable definition table)

• all global event definitions, in both the 'Event', and the 'Reaction' column;
• all local event definitions, on all pages;
• all display definition lines, also on all pages;
• all lines of the Script Editor (where such variables are prefixed by the keyword 'display.');
• all definition lines of the CAN simulator (with signal definitions and 'Conditional Actions').

(screenshot of the 'search variable reference' result window)

Variables on SDO channels

Note:

SDO channels are not supported by the MKT-View terminal (CANdb only)

A variable can be "connected" to an object in an other device in the network via SDO channel.

The "objects" of a CANopen-device are located in a so-called dictionary. Every object of this dictionary is defined by its Object-Index and Subindex .

These parameters are defined on the following panel, which will be visible if the current variable is connected to an SDO-channel:

To "connect" a variable to an object of a CANopen-device, you have to define:

• the SDO channel number (which connects the UPT to a certain device)
• the index and subindex of the CANopen object
• the data type of the object
• the access rights (i.e. "read only")

See also:

• Channel number of a variable (which also defines the channel type, like SDO-client, SDO-server, etc)

Variables on PDO channels

Note:

This chapter only applies to older terminals, with a very old CANopen version. In newer terminals, only objects in the CANopen-OD can be mapped into a PDO.
In terminals with "CANdb" (CAN without CANopen), PDO channels are not supported at all !

The input of a variable can be connected to a part of a PDO channel (a PDO can carry up to 8 bytes of information, and you will usually only use a part of that data field).

To "connect" a variable to a PDO channel, you have to define:

• the "UPT-internal" number of the PDO channel
• the number of data bits that shall be transferred from the PDO into the variable
• the number of the fist data bit in the PDO (which is the least significant bit)
• the data type of the object

These parameters are defined on the following panel, which will be visible if the current variable is connected to a PDO-channel:

Notes:

• In the "UPT-2" (with CANopen V4, like "UPT320"), it is not possible to map interpreter variables directly into a PDO. In those cases, you must use the PDO-mappable variables in the terminal's CANopen-Object Dictionary, instead of mapping the old self-defined variables into a PDO ! To access those variables from the application, use the interpreter function obd(<Index>.<Subindex>) , or connect the CANopen-objects with interpreter variables as explained here . Those special variables have the big advantage of being defined in the terminals EDS-file (in contrast to the self-defined variables), so they are recognized by any CANopen configuration tool - which greatly simplifies the configuration of the network !
• only 1-bit-parameters can be read from any bit-position in the PDO.
• 8-, 16-, 24- or 32-bit-Parameters must start on a BYTE boundary in the PDO data field, so the "number of the first bit in the PDO" must be a multiple of 8. The bit-count starts at 0 (ZERO) not 1(ONE), in contrast to some strange programming languages.
• Parameters with more than 8 databits are always transferred in "low to high-byte-order".
• The UPT simulator does not support PDO functionality, because the PC's CAN-Interface is just a BASIC-CAN-Controller.

Related topics: communication channels , SDO channels , PDO channels ,  channel number of a variable

Variables connected to the terminal's "own" CANopen object dictionary

Hint:

If you are familiar with CANopen, you will  have noticed that these indices are simply 0x4000 plus the CANopen data type code, for example code "4" means 32-bit signed integer.

If no CANopen object had been connected before starting the dialog, the program may decide to select an object which matches the variable's data type as close as possible (if enough unused subindices of such an object are remaining). Each object has 10 or 40 subindices, depending on the terminal firmware (option "Monster-OD" only available for devices with 32-bit CPU), resulting in a grand total of 360 individual values which can exist in this part of the OD. Unfortunately, because the CANopen-OD is 'static', these dimensions cannot be changed.

The programming tool will try to pick the next unused sub-index of the object automatically. You can see (and edit) the subindex after closing the dialog box with "Ok" .

Interpreter variables connected with the CANopen object dictionary are always visible to 'the outside world', because a CANopen configuration utility may map it into a PDO (even if you didn't map it in the UPT programming tool). Furthermore, such objects can always be accessed via SDO, if an external SDO client knows the OD-index and -subindex. For CANopen, such external connections are usually configured with a special utility (for example with the CANopen Configuration Manager, which doesn't just configure a single CANopen node, but an entire CANopen network). During normal operation ("operational state"), only PDO will be used between CANopen slave devices, because the few SDO servers in most CANopen slave devices are reserved for the CANopen master, and thus cannot be used by other devices.

Back to the overview of an interpreter variable's properties .

(*)

Unfortunately, these objects in the CANopen-OD cannot have 'talking' names, because the name of CANopen objects is not variable (at least not in the EDS file). For this reason, you will only find such general, unspecific names like "Application Vars 32 bit signed" for object 0x4004 in the EDS file.
To simplify using the display terminal as CANopen slave in combination with external PLC software (like z.B. CoDeSys), the UPT programming tool (2) can generate a DCF (device configuration file), which will then contain the "talking" names (i.e. the name of the variable, if a variable is connected to a certain CANopen object in the display's own CANopen-OD). The UPT VARIABLE NAMES will appear as Denotation in the DCF. Details about the DCF-Generator are here .

Usage of "index" and "subindex" for SDO variables

The "objects" of a CANopen-device are located in a so-called dictionary. Every object of this dictionary is defined by its Object-Index and Subindex.

The Object-Index is a 16-bit-number which is usually defined in hexadecimal format. In the terminal programming tool, hexadecimal numbers begin with the "0x" or "$"-prefix, otherwise the interpreter would treat them as decimal numbers.

The Subindex is an 8-bit-number which is often used for arrays or structured objects.

For example, a DS401-type module with 5 digital inputs may have an Object 0x6020 which contains the state of the digital inputs. Subindex 0 of this object will have the content "5" to indicate that there are 5 digital inputs, subindex 1 will hold the actual state of the first digital input, subindex 2 the state of the second input and so on.

Index and Subindex of CANopen-Objects are often defined in a device's manual. But for many objects you may also find the required information in a so-called DeviceProfile . There are device profiles for different types of CANopen-devices, for example:

DS401: Device Profile for I/O Modules

• digital in- and outputs
• analog in- and outputs

DS401, Digital In- and outputs

 DS401, Analog In- and outputs

Variables connected to 'generic' CAN-Signals (described via *.dbc)

Only for certain terminals which support the reception of signals defined in a CAN database (*dbc, Database for CAN) !
THIS IS NOT FOR TERMINALS WITH "CANOPEN-COMPATIBLE PROTOCOLS" !
Details about connecting variables with "CANdb"-signals are in a different file  .

<BusNr>,<CAN-Identifier>,<position of LSBit>,<number of databits>,<INTEL/MOTOROLA-flag>,<signal type>

BusNr

may be 1 or 2, if the device has two physical CAN interfaces (e.g. MKT-View II/III/IV);
   or 3 or 4, if the device supports CAN-via-UDP or LIN.
For MKT-View II / III / IV, "CAN1" and "CAN2" are labelled as such on the adapter cable (or, maybe, "KFZ-CAN1" / "KFZ-CAN2" as requested by some customer).
Those "Bus-Numbers" are usually set when importing a CAN database, because before selecting the database filename, the bus number is selected on tabsheet "CAN" in the tree view ("CAN1", "CAN2", ...), or by using button 'Load DBC #1' (for CAN1) or 'Load DBC #2' (for CAN2). If anything else fails (because the CAN database isn't available for you anymore), you can edit the bus number on tabsheet 'Variables', but the preferred method of selecting the bus number is importing the database for a certain bus.

CAN-Identifier

= 3- or 8-digit hex number, depending on 11- or 29-bit identifiers for CAN messages

position of LSB in CAN message

is explained in another document in detail. For CAN and LIN, data bits in the payload are numbered from 0 to 63.
If we ever get hold of a microcontroller that properly implements CANfd, the numbers may be higher, but the principle ("start counting bits at zero") remains the same.

Number of databits

is also explained in the other document

Flag for INTEL- or MOTOROLA format

is what makes CANdb signal processing even more complicated ;-) ... you already guessed it, details are in another document
I = "Intel" (aka little endian, least significant byte first)
M = "Motorola" (aka big endian, most significant byte first)

Signal type ("raw signal format" on CAN)

U = Unsigned (Signal wird auf dem CAN-Bus als vorzeichenlose Ganzzahl übertragen)
S = Signed (Signal wird auf dem CAN-Bus als vorzeichenbehaftete Ganzzahl übertragen)
F = Float (Signal wird auf dem CAN-Bus als 32-Bit-Fliesskommawert übertragen)
D = Double (Signal wird auf dem CAN-Bus als 64-Bit-Fliesskommawert übertragen)

Additional information may be contained in the definition for MULTIPLEXED signals.

Don't try to change the CANdb signal definition yourself here ! It is possible to define everything on the 'Variable' definition tab (and possibly your only chance if you don't have a CANdb file describing your network), but you better use the method described below (and in a separate document) .

The preferred method is to use an external CANdb file editor for this, and re-import the modified CANdb file as explained here. This will take you to the 'CANdb' tabsheet, where you can browse the database, and connect a few signals to display variables ('UPT interpreter variables') :

( CAN Database display; more details here )

See also (concerning 'CANdb'):

• Basic principle to build a display application for CANdb-signals
• Timeout monitor function for CANdb signals
• Modifying the CAN-identifier of a variable connected to a CAN-signal 'on-the-fly'
• CAN Message Layout (display window, also available for variables with CAN bus connection)
• Overview of application variables
• CAN Message Generator / Bus Simulator

Variables connected to 'openABK'

Data Breakpoints (to stop on assigning certain values to a certain variable)

Hint about the principle of data breakpoints (as implemented here):

A data breakpoint defined this way behaves like an edge-triggered oscilloscope. The "trigger" (in this case, pausing the simulation with message 'why') only occurs if the old variable value was outside, and the new value is within the value range defined as described above. When setting (defining) a new data breakpoint, the variable's current value is internally stored as 'old value' to prevent false triggers.

Settings (on tabsheets and dialogs in the programming tool)

Parameters in the right part of the 'Settings' tab

Programming Tool Settings

• Interface type and/or I/O-Port address of the PC's CAN-Interface
• CAN baudrate to establish a connection to the programmable terminal
  (Note: There are additional CAN bit timing parameters, part of the User Settings, which only have an effect inside the programmable device)
• Serial interface (e.g. "COM1"): This was formerly used to download the application into the terminal via RS-232 (utterly slow).
  This port can also be used to connect a GPS mouse, to emulate devices connected to a GPS receiver in the programming tool;
• Serial Port Baudrate: Used by the programming tool, also during 'simulation'. Note: Not all baudrates are supported by all devices !
  Especially baudrates like 230400 and 460800 bit/sec will only work with suitable hardware (like USB adapters).
  This baudrate is used for the normal program download via RS-232 (which is still possible, if the programmable device has such an interface), and also for the file transfer utility.
• The terminal node ID affects the SDO-identifier of the programming tool (for CANopen, this must match the node ID of the device you are going to program)
• The 'simulated' node ID is used if the programming tool runs as a 'simulator', emulating a CANopen device with this ID
• Simulated sound: This combo defines if and how the device's audio output shall be emulated, e.g. "off" (no sound) or using the PC's soundcard with MIDI synthesizer
• Select help language: This item should speak for itself
• mark edited object in the simulator: See description of the LCD simulator
• Emulate embedded web server: Allows simulating the HTTP server (integrated in a few devices) on the PC). For details about the web server, follow this online line.
  Because running a web server in a PC program may cause trouble with the PC's firewall, this option is disabled by default.
  Besides the option 'emulate Embedded Web Server', the server's (TCP-)port number can also be modified on this panel. The port number (usually 80 for HTTP) only applies to the simulation on the PC ! The web server in the 'real' device (MKT-View) is configured in the device's 'Network-Setup'.
  The 'TEST' button (right next to the port number) can be used to establish a connection to the server (running on the same PC, using the loop-back IP 127.0.0.1 .

The 'Terminal Node ID' (for CANopen) and the CAN-Baudrate must match the settings in the terminal, if you want to upload programs successfully via CAN.

Selection of disk folders (directories)

Below the 'Programming Tool Settings' you will find the 'Directories', which are used by the programming tool to store different kinds of files.

The adjustable directories / paths include...

• the directory in which you want to store your terminal applications (by default, this is the 'programs' folder),
• the directory which contains the help system in HTML format (you certainly never need to change this, in contrast to selecting a different HTML browser),
• the directory from which 'Icons' are imported by default (this can save a lot of time wasted in window's "file selector" dialogs),
• the directory for your own script include files,
• the 'fonts' directory,
• the directory where the optional font editor has been installed (so the programming tool can launch it from a menu),
• the directory where the optional CAN logger utility has been installed ( " "  " .. ),
• the directory with wave audio files (used to simulate certain terminals with analog audio output capabilities),
• the directory for the simulation of the memory card, used to develop advanced applications (with file I/O via script) without a 'real' target hardware.

• Programming Tool for displays with 'CANopen' : C:\WINDOWS\MKT_CANopenTerminalProgTool.ini
• Programming Tool for displays with 'CANdb'     : C:\WINDOWS\MKT_CANdbTerminalProgTool.ini

Parameters in the left part of the 'Settings' tab

The next two sub-chapters describe the entries of the upper table ("Constants") which describe the device, and the lower table ("Terminal Settings") which configure the device.

Terminal constants (upper part of the tabular display)

• Hardware profile: Name of the target hardware, e.g. "MKTVIEW_3_Landscape".
  You can click into this cell to select a different target device (also for the "Software Profile").
• Software profile: Explained in the description of the target selection dialog.
• Firmware Compilation Date (of the programmable device), important to avoid conflicts with 'old' firmware .
• (max number of) SDO channels
• (max number of) PDO channels
• (max number of) Variables
• maximum size of the script sourcecode (in kBytes, target specific, and unknown by the time of this writing)
• max length of a format string (also usable as static display text or as menu item)
• max length of an event "condition" definition (number of characters, usually 25)
• max length of an event "reaction" definition (usually 48 characters)
• max number of "global" events (usually 20)
• max number of commands per display page (usually 15)
• max number of display pages without "specials" (like text array and icons, usually 150)
• max length of a page name (usually 8)
• max length of a variable name (usually 8)
• max number of lines in the text array (usually 1024)
• max number of icons, limited by memory manager
• Flash memory management type (static/flexible)
• display type: 1=monochrome, 4=color with 4 bits/pixel
• display width: 128 pixels for UPT515 and UPT-Handheld, 320 for UPT320, "MKT-VIEW","IPE-VIEW"; 480 for "MKT-View II / III"; 800 for UPT800.
• display height: 64 pixels for UPT515 and UPT-Handheld, 240 for UPT320, "MKT-VIEW","IPE-VIEW"; 272 for "MKT-View II / III"; 480 for UPT800.
• Supported fonts as a bitwise combination for all font numbers.
  As for some other parameters, click on this item to open a special dialog:
  

  
  Dialog with a list of fonts supported by a certain device.

  
  
• plus a lot of 'other' infos which were used by the software developer for debugging purposes ;-)

Terminal settings (lower part of the tabular display)

• Baudrate and bit timing parameters for the device's CAN interfaces.
  Click on a value of any of the CAN-related entries to open a configuration dialog (here: dialog 'CAN Bus Parameters').
  Wherever possible, set the CAN-baudrate under "Programming Tool Settings" and "Terminal Settings" to the same value - especially if you must download the application via CAN into the terminal while the application is running (which is always the case for CANopen devices ! ). If the download via CAN fails, read the extra document 'Download troubleshooting'.
  
• Maximum number of display pages,
  maximum number of icons,
  maximum number of text-array lines:
  Only relevant for older devices without 'flexible storage'.
  In older devices, these three parameters were required for partinioning the memory inside the terminal when downloading a new application. More on the memory distribution here.
  
• The keyboard combination used to enter the UPT's system menu.
  Click on the value to open a dialog for the system-menu key combination (and a few other 'Options' for the UPT = User Programmable Terminal).
  
• Up to 32 non-volatile values which can be accessed through the UPT's interpreter (nv[]) or via script (system.nv[]).
  As for other parameters, click into one of these cells to open a special input dialog.
  

CAN bus timing parameters (as part of the "Terminal Settings" / "User Settings")

To open this dialog window, select 'Options' .. 'CAN / LIN bus settings' in the tool's main menu.

The following CAN-related parameters can be modified^{( * )}:

Baudrate

CAN-Baudrate in kBit/second. The baudrate "666" actually means 666.66666 kBit/sec; "83" is 83.33333 kBit/sec. All other (and less exotic) CAN baudrates are precise integer values, not truncated.

Position of Sample Point

Position of the sampling point within a CAN data bit. Unit is percent (of the nominal CAN bit time). For automotive applications, usual values are 80 ... 83 percent, where 83 % is, in most cases, actually 83.3333 % . In most devices with CANopen, this parameter has no effect.

Sync Jump Width (SJW)

Width of the CAN synchronisation jump, measured in 'time quanta' units. Possible range is 1 to 4 time quanta, but additional restrictions apply (depending on the position of the sampling point). The CAN controller / firmware divides each CAN bit into as many possible time quanta as possible. In some automotive specifications, the number of time quanta per CAN data bit is also called 'BTL cycles' (BTL = bit timing logic in the CAN controller). Thus the true SJW length (in microseconds or nanoseconds) depends on the hardware; especially on the crystal clock frequency. As a rule of thumb, each CAN data bit is divided into 10 to 20 time quanta. The actual value (used in the programmable device) can be examined in the system menu, as described in the chapter titled "CAN Bit Timing Parameters" in document #85115 (PDF) .

Flexible Data Rate (FD)

Bitrate for the 'fast' data field after the CAN FD bitrate switch (between message-ID and data field).
Usual bitrates for CAN FD are 1000, 2000 or 4000 kBit/second, in rare cases also 8000 kBit/sec (if cable, connectors, and the transceivers on both sides permit).
This field is only enabled if the currently selected device supports CAN FD, for example the MKT-View V (under development in 2019, planned for 2020).
When selecting a device/display, the info about which of the CAN ports also supports CAN FD is copied from an internal database into the current device profile. For example, an i.MX RT1064 has three CAN controllers, but unfortunately only one of them supports CAN FD. In that case, the device firmware would map the FD-capable controller (called "FlexCAN3" by NXP) to the first logic CAN port ("CAN 1").
See also: Notes on CAN FD capable ports in the MKT-View V.

Activate the following flags, and include them in the config :

With this (rarely used) option, during a program transfer into the target device, settings made in the device's System Setup menu will be overwritten with the settings from the new application (*.cvt). If this option is not checked, the CAN-related parameters listed below will remain unchanged (in the nonvolatile system setup, e.g. EEPROM):

Enable Transmit and Acknowledge

Allows transmitting CAN frames and acknowledging received frames.
If this option is unchecked, the CAN node will be turned into a 'passive listener' (Listen-Only Mode).
Note: This option only works for devices with suitable CAN-hardware or -controller, like MKT-View III / IV / V !

Active Terminator (Resistor)

Turns on the CAN bus termination resistor (usually 120 Ohms), if that resistor is switchable aka "software controlled". Please consult the literature on CAN bus topologies to learn where the 120 Ohm resistor should be located (on the end of the cable or a long stub, but that's now the whole story).
Devices with a software-switchable CAN termination resistor are MKT-View II, III, IV, V, and possibly any later device. Details about the availability of a switchable terminator (and its resistance) are only in the device's datasheet.

^(*) In very old devices like MKT-View "Plus", or devices with firmware older than April 2011, only the CAN baudrate could be configured, but not the position of the sampling point and the SJW parameter (Sync Jump Width).

See also: Configuration of the PC's CAN interface (used for program transfer),
      LCD settings dialog, Optional Display Setup, Memory distribution dialog,
      UPT File Description, System menu in the terminal , Table of Contents.

General Terminal Options (dialog)

(Originally only for "UPT" = user programmable terminal,
meanwhile also for MKT-View and others)

The "General Terminal Options" – dialog can be used to set some settings that will be transferred into the UPT when you upload your application. This dialog can be started by clicking on the "General Option"-value on the "Settings"-Tab.

The option Enable System Menu may be turned off if you are shure that you do not need the UPT's system menu functions (because you need the keyboard combination F2+F3 in your own program and you don't want that the user of your application enters the system menu).
However, even if the option "Enable System Menu" is turned off, you may still enter the UPT's system menu to adjust the LCD contrast if you hold F2+F3 during power-on (but at that point, the application data are not loaded yet, and "secret" parts of your application cannot be inspected).

The option Enable Debugging was intended to be used by the author of the UPT firmware only (because he didn't have a target debugger). You should leave this option off.

The option Readout Protection can be set to prevent reading the currently loaded application from the terminal later (via CAN or RS-232). This option is only supported by firmware compiled 2009-05-20 or later.

The option Auto-Scale for larger display resolutions should be set if your application doesn't use 'pixel-precise' graphic output, and you want to re-use a program once designed for 320 * 240 pixels on a 480*272-pixel display (without wasting space on the display). More info in the FAQs on how to migrate from the older MKT-View to the newer MKT-View II / III.

The key combination to enter the UPT's system menu can now be changed from the programming tool, because the old (fixed) combination F2+F3 collided with the application of a valued customer. Be careful with this option, because not all key combinations can be detected by some targets (especially those with multiplexed keyboard hardware). If you entered an ‚impossible‘ key combination, you can only enter the UPT's system menu by pressing F2+F3 during power-on.

See also: Supported graphic functions (dialog), LCD settings dialog, Optional Display Setup, Landscape- and Portrait Modes, Memory distribution dialog, "Settings" (tab)

Optional Setup (LCD backlight settings, formerly only accessable through the device's built-in system setup)

Since 2011-07-12, the display (LCD) in few new devices can optionally be configured through the programming tool. Formerly, these hardware specific settings could only be modified in the device's built-in system menu (via System Setup / Display Setup / LCD Dimming) .

To open the following configuration screen, select Options  ... Display Setup from the programming tool's main menu .

Important: When transferring the display application (*.upt or *.cvt) into the target device, these settings will only be included (in the download) if the checkmark 'Include these settings when downloading the configuration' has been set in the dialog shown above. If that option is not set, the display setup will not be saved (or sent), keeping it compatible with earlier firmware revisions.

In fact, when downloading a *.upt or *.cvt file which has the 'Include these settings'-flag set, these settings actually overwrite the system settings one single time. After that, they can still be modified through the terminal's built-in system menu, unless the key to invoke the system menu has been disabled through the 'general options'.

Note: The efficiency of certain display backlights (usually white LEDs, but sometimes CFL tubes) may vary greatly between different devices. Thus the same 'brightness' control value may give different results on different devices. Details on the automatic (ambient-light depending) LCD brightness control can be found in the description of the device's system setup menu, see document #85115 .

See also: Feature matrix (for various targets), Settings (tab), Table of Contents

Checking the supported graphic functions

• Screen inversion ("inverse" means white characters on black background, see interpreter command "di").
• Graphic buttons
• Bargraph diagrams
• Y(t)-diagrams
• user-defineable fonts
• presence of a touchscreen (required for simulation)
• and other functions which were unknown at the time of this writing !

The following dialog window can be opened by clicking on the "General Option"-value on the "Settings"-Tab:

If a checkmark is not set in this dialog, it does not necessarily mean that your terminal does not support the associated function. The information which of the graphic functions are supported is embedded in the storage file (*.upt or *.cvt). If you load an "old" application, you may find some of the functions indicated as not supported, though your "new" firmware supports them. For this reason, you can modify the "support-flags" in this dialog yourself (*). Usually, after transferring the program into a terminal and reading it back (via CAN-bus) the programming tool knows which graphic functions are really supported, and sets the checkmarks in this dialog accordingly.

(*) be careful not to activate functions which are not supported by the firmware in your terminal. The resulting display may look very strange after downloading your application into the terminal !
An overview of devices, firmware variants, and their capabilities is in the feature matrix .

The option "Width and Height of display elements in extra columns" cannot be set directly. This option solely depends on the firmware compilation date. If necessary, the latter can be modified on the 'Settings' tab, for example if a bidirectional transfer between programming tool and the programmable device is impossible (i.e. transfer only via memory card). Devices with firmware older than 2009-11-27 did not support width and height of display elements in these extra columns - instead, width + height were encoded inside the parameter list of a button or bargraph (which is now deprecated).

See also: General UPT options (dialog), LCD settings dialog, Memory distribution dialog ,

Creating a UPT File Description

; File:  c:\MKT\CANdbTerminalProgTool\programs\Brake_T1.cvt
; Saved: 2015-03-05 11:12:13
; Type:  program file for user programmable terminal
; Producer: programming tool compiled Mar  5 2015
Description="Brake Test, Track 1"
Encryption=0
PwdHint1=""
Password1=""

Simulation of the memory card (on a PC, as replacement for the memory card in a 'real' device)

1.8.9 Checking for external file references (in the application)

Some display applications will access files stored on the memory card, or in certain areas of the terminal's internal FLASH memory, for example audio files.

If you wrote such an application, and need to pass it on to somebody else (a customer, colleague, etc), don't forget to include all files which your application uses.

To simplify this task, the programming tool checks for external file accesses during the simulation, and when 'checking all pages'. The result of those tests can be checked by selecting "View".. "External File References" in the programming tool's main menu ("Ansicht".."Externe Datei-Referenzen" in German) :

Each line of the file list contains the name of a referenced file, the display page on which the file was referenced (if it was referenced on a display page), the line number, and the date in ISO-8601 format when the file was last referenced (this hasn't got anything to do with the file's creation date).

If you are sure you don't need the file list anymore, you can delete the entire list in the dialog shown above by clicking the 'Delete' button (button with a red cross symbol).

If you think that certain files are missing in the list, or some old files shall be removed from the list, you can do this manually by editing your UPT (or CVT) application with a text editor. You can find the list of referenced files in the section 'Audio- and other  files (REFERENCES)', for example:

; ----- Audio- and other files (REFERENCES) -----
a file0="dog.wav"   pn=0 li=1 da=20091207
a file1="puppy.wav" pn=0 li=2 da=20091207
a file2="sheep.wav" pn=0 li=3 da=20091207

where

pn = page number, li = 'line of page', and da = date in ISO format.

The length of the file reference list is limited to 64 entries (due to memory restrictions in the terminal firmware).

Finding all references to external files may sound trivial, but it's not. Consider this interpreter command :

audio.play( "msg" + str("***",AudioMsgNumber) + ".wav" )

where 'AudioMsgNumber' is a numeric value received through some communication channel. It is impossible (at least for the programming tool) to find out which audio file names will actually be produced by the above string expression. Even during a simulator session, not all possible values of 'AudioMsgNumber' may occurr. So, if your application uses tricks like the one shown above, maintain a list of all files used by your application, and don't forget to distribute (or upload) them along with your *.upt or *.cvt file(s).

User-defined fonts may be considered 'external files' too, but  at the moment, they are not (and thus *.fnt files are not listed in the file reference table). To find out which user defined fonts are used, check the user-defined font list.

Definition of a Text Array

Hint:

If you only want to display two or three text alternatives (like "ok"-"too hot" - "too cold"), depending on a numerical value, you can use the interpreter's "arithmetic if-then-else" within a format string. This is explained in the chapter BUTTONS(!).

See also:

• Popup window (can be used to show text messages which are received from the CAN-bus; acts like a small virtual terminal inside the terminal).
• String functions
• Array in the script language (an alternative to the display interpreter's single 'text array', but the script language is not available for some older devices)

Display Page Definitions

(Screenshot of the 'display page definition table' in the programming tool)

Introduction to Display Page Definitions

• a header definition
• multiple display elements which can be defined in text form, or with the 'graphic' editor.
  Examples:
  • simple Text, with or without the value of a variable (using placeholders like '*****.*'),
  • advanced text displays, using backslash sequences,
  • edit fields,
  • multi-line menus,
  • icons (graphic images, switchable depending on signal values),
  • bargraphs, vertical or horizontal,
  • buttons (user-defineable touchscreen areas),
  • Y(t)- and X/Y-diagrams,
  • text panels (can be 'printed to' via script),
  • graphic panels (displays a tCanvas, filled via script),
  • tables (via script, also useable as control element / selection list / etc),
  • analog meters (pointer instruments),
  • lines, polylines, closed and filled polygons,
  • ...
• some rarely used low-level graphic display commands
• event-definitions (explained later in this manual, after the introduction of the interpreter language. Only required for special applications ! )

Besides the page definition table shown above, display pages can also be modified with a graphical editor (more on that later) :

(Screenshot of the 'simple graphical editor' for programmable display pages)

After starting, the programming tool shows 'page zero' of your application (like the 'real' display after power-on).
To switch to an other page of your terminal program, you may use the page overview , where you can see all pages that you have already programmed.

To switch from one display page to another in the programming tool, use the red-arrow-buttons (,in the upper right corner) or the display page overwiew, where you can see all programmed pages. To switch to another page in the terminal, use buttons, menus, self-defined events, script, or page-scan-sequences . But first, let's look at the elements which belong to a single display page...

Page Definition Header

The Page Definition Header contains general information about a display page, like :

• the NAME of the page. Please replace the automatically generated name by something more descriptive, like
  "MainMenu" instead of "page2". For most target systems, up to 8 characters are allowed (no spaces)
• the flag "Always redraw this page completely"
• the flag "do not clear the screen automatically"
  (Leave this option unchecked unless you really need it. When set, the system will not automatically clear the screen before rendering the elements on the current display page. In this case, it's your responsibility to clear the screen 'programmatically', e.g. controlled via script or display-interpreter command).
• the flag "do not update the screen if keyboard buffer is full"
• the flag "circular wrap when navigating"
• the flag "inverse screen (dark background)" [only for certain terminals]
• the flag "include this page in the page-scan sequence"
• A page update interval (in milliseconds), which can reduce the page-update rate, to improve readability of numeric values which are otherwise updated too frequently (making it difficult to read the numbers, especially on stoneage passive LCDs).
• Default text colour, default background colour, Day/Night: Only for colour displays. Details and an example are in another document.
• Special Background Filler: Usually, the background of a display page is just a "blank screen". If you enter one of the graphic commands in this field, it will replace the automatic "Clear Screen" operation. Beware: The "background filler" should erase the entire screen, not just a part of it. Example: Command to fill the screen (here: background) with a colour gradient.

(Screenshot 'Display Page Header' for a programmable page)

If the option always redraw this page completely is selected, the whole page will always be updated completely. This requires quite a lot of CPU time but may be necessary if you use overlapping or moving graphics. A complete screen update always includes erasing the screen, so there will be no remaining garbage on the display if you let an icon crawl across the screen.

If "always redraw.." is not activated, only the text lines with modified contents may be updated to save some CPU time. A typical display update-rate will be about 10 screens per seconds (but this depends very much on the number of display-lines with flexible contents).

A typical display-update with the option "always redraw.." took about 250 ms (on old terminals like "UPT-515" and "MKT-View" / "MKT-View Plus" with 8- or 16-bit CPU). On newer devices with Cortex-M CPU (like MKT-View III), even a complete screen-update usually takes less (much less) than 100 milliseconds.
In any case, the update rate greatly depends on the complexity of the display page, and the screen resolution.
As an alternative to the option always update page, you can use the option always update this line on the display line property panel. This will save a lot of CPU power, especially if a large display or a color display is used (UPT 167, IPE-VIEW, MKT-View I / II / III).

Definition of Display Lines

The columns (or edit fields) labelled "X" and "Y"

define the position of the upper left corner of the element defined in this line, measured in graphic pixels.
Besides entering the pixel coordinate in numeric form, you can use the graphic editor to modify an element's position.

The columns "W" and "H"

define the width and height of certain (not all!) display elements, measured in pixels. For 'normal' alphanumeric display lines, these fields may be empty (unless text shall be centered or aligned in a fixed-size field).
For other 'fixed size' elements (like buttons, etc) the size must always be specified.
For devices with firmware older than 2009-11-27 (ISO, YYYY-MM-DD), the columns "W" and "H" are not displayed in the table, because old devices (MK-View 1) / old firmware do not support these properties. In case of doubt, check your device's firmware compilation date in the system menu, and -if necessary- let the programming tool know the compilation date of the device firmware on the 'Settings' tab under 'Firmware compilation date'.
For "normal text fields", width and height are usually not specified (so the element only occupies as much space on the screen as it needs to). For aligned text fields, the field size must be specified (for right-aligned text, at least the width).
In the graphic editor, the size can easily be modified by pulling the lower right 'sizing corner' (small square) with the mouse.

The "Name" column

is rarely used so far (because only terminals with 32-bit CPU support this function). If a display element has a name, you can easily access it from the interpreter or via script, using this name as a reference. The maximum length of any name in this column is 7 characters. More details here .

The "Text" column

can be used as format string for numerical values, or as a menu item. The text string can also be used to display icons , bargraphs, buttons and other special graphic elements.

The column "Var/Expr" column

usually contains the name of a variable, a numeric function, or a string function which shall be displayed/edited or an interpreter command which shall be executed if a menu entry has been activated. The calculated value can be accessed from the interpreter with the "v"-function.

The "Access/HotKey" column

defines the access rights for a displayed variable or a ‚hotkey‘ definition if the display line is used as a menu item (more about this on the property panel).

The columns "Draw Mode", "Color", "Font" etc

affect the appearence of the displayed line on the screen (see property panel).

The "property"-panel on the right shows more detailed information about one single display line.

You may edit the properties of a display line in the table or on the property panel, the information will always be updated on both parts.

To inspect the current value of variables or expressions in the page definition table, simply point the mouse over the cell (without clicking). If the interpreter can evaluate the 'word', sub-expression, or the complete expression under the mouse pointer (details here), the result will be displayed in the rightmost field of the status bar at the bottom of the main window.

If the simulated LCD is visible, you will immediately see the effects of the changes to a display line. For example, if you change the Y-Position of a display string via up/down-scroller in the display line property panel, you will see the text moving on the simulated LCD screen. The currently edited display line is marked with a dotted rectangle.

If some graphic elements or text lines on the screen overlap, you should be aware of their drawing order ! The order of the definition lines can be modified with the mouse. Hold the left button pressed while moving the mouse in the column "Nr" up or down. A black horizontal bar shows the location where the moved entry will be inserted when the mouse button is released. This row-moving procedure is also possible in some other tables of the programming tool.

Many possibilities are explained in the UPT examples (separate document in HTML format, some examples for the MKT-View terminals can be found on the MKT website).

Display Line Properties

• X-position, Y-position
• Width and Height of the display element. Details here.
• Draw Mode (i.e. normal, inverse, blinking; only for monochrome displays).
  For colour displays, this field is meaningless because they don't support "blinking" text.
  
• Text- and background- colours (only for color displays).
  For displays with 256 colours or more, you can double-click these fields to select a colour from a palette.
  The second background colour is used for gradient fills in graphic buttons and similar objects, and to fill polygons.
  Standard colour values are listed here.
  Hint: Set both foreground- and background colour to -1 (minus one) for most display lines. The terminal will use the default values (from the page header) in that case, so you can easily switch between day- and night-design as explained here.
• Font (since 2018, the drop-down list also contains a few vector fonts).
  

  1 : Fixed bitmap font with 4*6 pixels

  2 : Fixed bitmap font with 6*8 pixels

  3 : Fixed bitmap font with 7*12 pixels

  4 : Fixed bitmap font with 8*8 pixels

  5 : Fixed bitmap font with 8*16 pixels

  6 : Fixed bitmap font with 16*16 pixels

  7 : Fixed bitmap font with 16*32 pixels

  8 : Fixed bitmap font with 32*32 pixels (only for devices with 'large' displays)

  9 : Fixed bitmap font with 12*24 pixels (only for devices with 'large' displays)

  10 .. 15 : User-defined bitmap fonts

  21: Vector font 'Hershey Simplex' (freely scalable, with thin lines)

  22: Vector font 'Hershey Duplex' (freely scalable, with double lines)

  By clicking on the underlined label 'Font', a table showing all characters (or glyhs) contained in the current font can be displayed, along with their hexadecimal codes.
  To find out which of the fonts are really supported by a certain device, switch to the programming tool's 'Settings' tab, Terminal constants, scroll down to 'supported fonts', and double-click on the hexadecimal value. Each bit represents one of the font numbers listed above.
  
  
• Zooming factor for text and bitmaps. There are individual controls for 'X' and 'Y' (horizontal and vertical axis).
  Bitmaps and bitmap-fonts can only be zoomed by 1,2,3,4 .. 15 (integer factors). The scaling range for vector fonts is 0.2 to 15.9, because vector fonts can not only be magnified, but also downsized in small steps.
  
• Variable/Expression/Menu Command
  For any kind of 'display element', this field contains the name of a display variable (which delivers the displayed 'value'), or a short numeric expression, etc.
  If the display element is used as a menu item, this field may contain an interpreter command which is invoked when the user selects the item.
  
• Access: The value of a variable with READ/WRITE access can be edited during run-time (integer values only, no floats).
  If the access is "read only", the value can be displayed but not modified on this page.
  Certain display elements (like bargraphs) will turn into an interactive control element, if this field (in the 'display line properties'!) is set to read/write instead of the default 'read only' access. For example, a bargraph can be used as a slider or scrollbar, operated via touchscreen.
• Control ID: Only required when events for this control element (button, menu item, edit field) shall be handled in the script language.
  The control ID allows to identify which control element has fired the event, by using a select...case statement in the script.
  If this field is empty, the script will not be notified if "something special" (-> event type) happens with this control element.

  

  If a script with user-defined constants already exists (and was successfully compiled), the control ID can be picked from a list by double-clicking the 'Control ID' field shown above:

  
  Screenshot with a list of user-defined script contstants,
  after double-clicking on 'Control ID' in the programming tool.

• "This line is a menu item"
  Setting this flag turns a simple Display Line into a menu item. The user may move through the menu on a display page using the cursor keys and press ENTER to execute the command defined in the property "Variable/Expression/Menu Command" .
• "always redraw this line completely"
  forces the UPT to repaint a single line of the display as often as possible. Use this option if a line has "side effects" like a dynamic text display. You do not need this option to display a simple variable which may change its value (the UPT firmware takes care of this).
• "Text" (title of an extra tabsheet in the panel's lower part):
  
  • Text (input): Static text and/or a format string with optional backslash sequences)
    
    
  • Flags :
    

    "Update output channel while editing"

    With this flag set, the current value of an edit field will be transferred to the output channel while editing the field, not only when pressing ENTER to finish editing.

    "Edit on Virtual Keyboard"

    If the value is editable, and the operator wants to edit it, open the Virtual Keyboard to edit the value there.

    
    
  • Base : Show value in binary, decimal, hexadecimal form, or from a value table ?
    0 = "automatic" : If possible, show string from the variable's value table.
        If that's impossible (no matching entry in the value table), show it in decimal form.
    2 = Show the value as a binary number (base two)
    10 = Always show the value as a decimal number (base ten); no value-table lookup
    16 = Show the value as a hexadecimal number
    In any case, the number of placeholders (*,#) in the format string specifies the number of digits, or limits the number of characters displayed from a value table.
    
    

Properties wich are not supported by a particular device will be disabled on the panel (weak gray color).

The connection between display lines and variables can be easily modified with the Variable Selection Dialog.

Format String (for display lines)

• be a simple constant text string like "Hello, world !"
• be a 'switch-list' of different strings, to be selected from a numerical value
• contain special "place holders" like "****" for numeric digits or variable strings
• contain several backslash sequences as explained below
• be used to display icons (in backslash sequences like "\iMyIcon" )
• contain a few simple HTML-like tags, e.g. '<u> underlined text </u>'
• also be used to control the behaviour of edit fields.

Special characters in a format string, backslash sequences

* (asterisk) will be replaced by a numerical digit or a single character from a string

For floating-point values, leading zeroes are suppressed (replaced by spaces), but not for integer values.

# will be replaced by a numerical digit, similar as the asterisk (*) .

In contrast to the asterisk, leading zeroes are ALWAYS suppressed (for integer as well as floating point).

0 (digit zero): will be replaced by a numeric digit from the value (like '*' and '#').

In contrast to '*' and '#', zeroes are NEVER suppressed by this placeholder.

. (point) is the decimal separator.

CAUTION: Older devices didn't support floating-point values in an edit field !

, (comma in the Format-String, not in interpreter commands)

can be used as decimal separator for german users since 2009-10-06;
but only if the comma is immediately followed by a placeholder for a digit.

- will be replaced with the sign

of a numeric value (+,-)

\\ displays a single backslash

\< displays an opening angle bracket (instead of interpreting it as an HTML tag)

\- displays a "-"-character (minus character, not a placeholder for the number's sign)

\0 displays a "0"-character (zero character, not a placeholder for a digit)

\ar   align right (applies to the rest of the text string within its field ^(*) )
\al   align left (applies to the rest of the text string, up to the next alignment option ^(**))
\ac   align centered (applies to both X and Y, for the rest of the string, within its field ^(*) )
\ah   align horizontally centered (center the X- but not the Y-coordinate, i.e. center only horizontally, and leave the vertical position unchanged ^(*) )
\av   align vertically centered (aligns the rest of the string vertically; horizontal position remains unchanged ^(*) )
\at, \ab : Reserved to align fields on the screen (not the text within its field)

Only for targets with 32-bit CPU and firmware compiled 2013-03-25 or later.
The right and bottom margins for output is the position ("X","Y") plus the fixed size of the display element.
Without a fixed size of the display element, most of the 'alignment' switches treat the right and lower edge of the screen as 'the end' of the alignment area.
The following example from programs\AlignTst.cvt uses coloured backgrounds to show the alignment areas:

  

\acac:Center	\arar:Right	\ahah: H-Center
\avav: V-Center	\av\arVert+Right	\avV-Center,\nmultiple\nlines .

(**) Because left-aligned text is the default, the alignment option '\al' (align left) is hardly ever used.
      It was implemented to modify the default center aligned text on graphic buttons.

\bar(width,height,flags,ticks,pattern...)

inserts a Bargraph (only supported by certain devices, explained in another file)

\btn(width,height, ...)

draws a Button (only supported by certain devices!)

\chr(N) displays a single character with the code N, from the currently selected font. Examples:

\chr(65) displays the letter A.
\chr(v) displays a character with the code resulting from the numeric expression in the current display line (see "v"-function)
\chr(56) displays a "fast forward" symbol, if the user-defined font font "Webd3232" is selected (only for certain terminals). "Webd3232" is a symbol font, compatible to "Webdings" (c) Microsoft Corporation.
Since 08/2016, for devices like MKT-View III,IV, chr(N) also supports a few Unicode symbols. For Unicode, the code (N) should be expressed as a four-digit hexadecimal number (prefix 0x), e.g.:   \chr(0x2611)
(draws a 'checkmark in a box', ☑, usable for 'checklist' tables and buttons with a checkmark).
Alternatively, use backlash-U to show characters by their hexadecimal Unicode value.

\cN sets the text- (and "foreground"-) colour for the subsequent output.

N should be one of the standard colours defined here.
Example: \c7 sets the text colour to white.

\CN sets the background-color for the subsequent output.

Also here, N should be one of the standard colours defined here.
Usually, there's no need to change the colour within the format. Instead, text colours are defined by the display line properties.
Example: \C0 ("Colour Zero") sets the background colour to black.

\dia( <diagram-definition> )

part of a Diagram-definition (only supported by certain devices!)

\e( <expression> )

Evaluate a string expression (instead of a fixed string). Only allowed at the begin of the format string in a display line definition.

\fN (N=font number as used in the display line panel)

selects font number N for output.
Example: \f

\fr(x1,y1, x2,y2)

draws a rectangular frame. The coordinates are *relative* to the display line's position. Example: Menu \M0\fr(-2,-2,260,32)

\fi(x1,y1, x2,y2)

Draws a solid ("filled") rectangle with the current foreground colour. Also here, the coordinates are relative to the element's position.

\i<Icon-Name>[,<Invert-Flag>]

inserts an Icon (see examples below). This sequence is usually generated by the programming tool (automatically, when placing an icon on a display page), but it can also be generated at runtime via script, e.g. to display glyphs for far-east languages in a table-driven translation ('internationalisation'). Example:
\i"hourglas"   (here with the name limited to 8 characters, to eventually load the image from a file at runtime, on a FAT file system without 'Long Filenames').

\li( [options] x1,y1, x2,y2 [, x3,y3, ..] )

draws a graphic line or a polygon. The coordinates are *relative* to the display line's position. Options: w=width(1..3), p=pattern (16-bit for 16 pixels).
A comma between two points (coordinates) draws a line between these points, a semicolon does not (it only 'moves the pen' to the new point without drawing, aka 'pen up').
As for most other display elements, the colours used for lines or filled polygons are taken from the display element's drawing colours :

• Solid lines are painted with the foreground colour
  (the same colour as used for normal text, inidividually defined for each 'definition line');
• The background of the polygon's rectangular drawing area may be filled with the first background colour,
  or left transparent (dummy colour value "-2" = transparent).
• Filled polygon areas ("polyfill") use the second background colour.

Rotated text can be displayed in the \li sequence as shown in one of the examples below:

   \li(0,15, 100,15)                     draws a line between the two coordinates (relative to the object's position)
   \li(w=2,polyfill(13,44,52,44,32,12))  draws a filled triangle with 2-pixel wide border
   \li(font=1, "Test" )                  draws a few characters using font 'Hershey Simplex'
   \li(font=2, rot=45, "Test" )          draws text rotated by 45° (positive = clockwise)

To insert or edit polygons, the graphic editor can be used instead of editing the polygon 'as text'. But variable coordinates (etc) for animated graphics are only possible by entering the '\li' sequence manually. Examples of the \li sequence with open, closed, and filled polygons -some of them quite tricky- can be found here.

\mN switches the draw mode

for the following displayed characters in the current line. In a selected menu line (inverted), the mode is inverted automatically. The mode may be a numeric expression in parentheses.
Example: "\m((v>0?0:10)" sets the draw mode to 'normal' (0) if v is greater than 0, and to 'erase'(10) otherwise. This allows you to hide certain parts of the display depending on variable values.
The draw mode values are the same as for the interpreter command dm .

\MN switches the draw mode

for the following displayed characters in the current line. Unlike "\m", the mode will not be modified even if the display line if "inverted" as a menu selection.

\n new line (plus carriage return).

The output position of the following text is moved to the left margin (=position defined in a display line) and the next line.

\panel [(optional options)]     :   multi-line text panel.

Defines a rectangular area, which can be used by the script language to display lines of text (like a small text display window).
At the moment, the multi-line text panel can only be filled by the script language, using the print command. Details about the 'panel' element are here .

\s(<condition>)?"<string1>":"<string2>"           (available since May 2003)

A "switch"-list for strings. Depending on <condition> (a comparison, etc), either <string1> or <string2> will be displayed. Follow the link for details.

\script.<function name>(<argument list>)"           (only for devices with script language)

Invokes a script function to retrieve a text string. The result value (which must be a string) is inserted instead of the backslash sequence. Follow the link for details.

\vvv

placeholder for the name of a VARIABLE. The backslash itself is part of the placeholder, so "\vvv" will show only the four first letters of the variable's name.
Prefixes like "script." will be skipped (not displayed on the screen).

\uuu

placeholder for the UNIT of a variable. The backslash itself is part of the placeholder, so "\uuu" will show four letters of the unit. If the unit is shorter (like °C ), the rest is filled with spaces.

\U+<hexadecimal Unicode>

Draws a single Unicode character by its hexadecimal code (only one "code" per backslash-U).
Example (in a format string): "\U+1F50D Zoom in" .
The hexadecimal code ends with the first non-hex character (usually a space as in the example, which draws a "left-pointing magnifying glass" if that character exists in the current font).
Supported special Unicode characters (and in which fonts they can be rendered) are listed here.
Most Unicode-'special characters' (with codes above 0x00FF) are implemented in the vector font 'Hershey Simplex'.

\x hexadecimal coded special characters (plural, since October 2009)

Begins a hexadecimal code sequence of 8-bit characters, similar to the "C" programming language. All characters after Backslash-x are interpreted as two-digit hexadecimal character codes. For each code, the equivalent character is emitted using the current font. Details about backslash-x (and how to generate such sequences) are here.

\zN

sets the zoom factor for characters. ONLY FOR DISPLAYS WITH 16-bit CPU. "\z0" restores the programmed default zoom for the current display line. To set the horizontal and vertical magnification factor independently, use two digits like this:
\z14High but Narrow \z0Back to normal

\s(<condition>)?"<string1>":"<string2>" Conditional sub-strings       (available since May 2003)

A "switch"-list for strings. Depending on <condition> (a comparison, etc), either <string1> or <string2> will be displayed.
<String1> is used if <condition> is non-zero (= TRUE), otherwise <string2> (the 'else'-branch).
The condition should use the numeric funktion 'v' to access the value of the variable is displayed in the current line.
The comparisons can be nested, if more than two possible strings shall be displayed.

Examples:

\s(v<15)?"too cold":(v>25)?"too warm":"Temp ok"

If 'v' (Value of the variable) is less than 15, the display shows 'too cold'.
If 'v' is greater than 25, it shows 'too warm'.
Otherwise, it shows 'Temp ok'.

\s(v)1"Mon":2"Tue":3"Wed":4"Thu":5"Fri":6"Sat":7"Sun":"err"

Here, the value of <v> is compared with the constants 1, 2, 3,...7, until a match is found. If there is no match, the string "err" is displayed in this example. As an exception, the questionmark (used as "if"-suffix) is not manatory here.

\s(v)0"Zero":1"One ":2"Two ":"****"

Values 0, 1, 2 are shown as plain text,
all other values are shown in numeric form (decimal, integer, four digits).

func OneTwoThree( int n )
   select n
      case 0 : return "Zero";
      case 1 : return "One";
      case 2 : return "Two";
      case 3 : return "Three";
      else   : return itoa( n, 4 );
   endselect;
endfunc;

Backslash-x begins a hexadecimal code sequence, similar to the "C" programming language. All characters after Backslash-x are interpreted as two-digit hexadecimal character codes. For each code, the equivalent character is emitted using the current font.
This function is especially suited to display special characters, for which there is no equivalent "key" on a western PC keyboard.
The hexadecimal numbering scheme makes this quite easy to achieve:
If the (up to 256) characters of any 8-bit font are displayed (or printed) as a grid with 16 * 16 fields,

• with the 16 grid columns labelled 0..9,a..f;
  
• and the 16 grid rows labelled 0..9,A..F;
  

then the first (most significant) digit of the hexadecimal code is the table row (0..9,A..F); while the second (least significant) digit is the table column (0..9,a..f).
For the terminal, it doesn't matter if A..F or a..f is used in a hex number. We only use A..F in the most significant digits, and a..f in the least significant digits to improve the readability of "longer" hex sequences.
In contrast to the "C" language, the hex sequence may be as longer than just one character. It ends at the first letter which is not a valid hex digit (for example, the space character).
The following example will show 'Hello ' if a normal alphanumeric ASCII font is used:
\x48656c6c6f .
To create a hexadecimal sequence of 'special characters', click on the 'more' button of the text line definition panel, and select Font Table.

(click into the font matrix to append a character to the backslash-x sequence)

Hex values above 0x00FF (= decimal 255) are treated as Unicode characters by the LCD driver. But from the large amount of 137000 known 'Unicode characters', only a small subset can be rendered. At the time of this writing (2018-12), the following characters could be rendered from the 'Hershey Simplex' font. To embed such codes in a string, use backslash-U (for "Unicode"), not backslash-x.

           U+0203C = Unicode Character 'DOUBLE EXCLAMATION MARK'
           U+02190 = Unicode Character 'LEFTWARDS ARROW'  
           U+02191 = Unicode Character 'UPWARDS ARROW'  
           U+02192 = Unicode Character 'RIGHTWARDS ARROW'
           U+02193 = Unicode Character 'DOWNARDS ARROW'
           U+02194 = Unicode Character 'LEFT RIGHT ARROW'
           U+02195 = Unicode Character 'UP DOWN ARROW'  
           U+025AD = Unicode Character 'WHITE RECTANGLE'
           U+025B3 = Unicode Character 'WHITE UP-POINTING TRIANGLE'
           U+025B7 = Unicode Character 'WHITE RIGHT-POINTING TRIANGLE'
           U+025BD = Unicode Character 'WHITE DOWN-POINTING TRIANGLE'
           U+025C1 = Unicode Character 'WHITE LEFT-POINTING TRIANGLE'
           U+02610 = Unicode Character 'BALLOT BOX' (empty "checkbox")
           U+02611 = Unicode Character 'BALLOT BOX WITH CHECK' (checkmarked)
           U+02612 = Unicode Character 'BALLOT BOX WITH X'
           U+1F50D = Unicode Character 'LEFT-POINTING MAGNIFYING GLASS'
           U+1F50E = Unicode Character 'RIGHT-POINTING MAGNIFYING GLASS'

HTML-like 'tags' in the format string

• <b> bold text </b> (only looks good with vector fonts or large bitmap fonts, at least 12*24 pixels)
• <i> italic text </i> (artificial 'italification' by skewed printing, only ok for vector- or large bitmap fonts)
• <u> underlined text </u>
• <wN>text rendered with N-pixel wide lines</w> (only works with vector fonts)

Edit Fields on a programmed display page

• The edited variable must have read+write access, both in the variable-definition table and in the display definition.
• The variable must be an integer, floating point, or 'string'
• In old devices (e.g. MKT-View I aka "MKT-View Plus"), only variables with data type 'integer' could be edited.
• Even if an edited variable is 'only' an integer, you can insert a decimal separator ('.', point !) in the format string to make it look like a fixed point value. For example, if you have an editable temperature value ranging from -20.0°C ... +70.0°C coded as -200 ... 700 in an integer variable, use a format string like "+**.*" (one decimal place after the point). If the display is in edit mode, the user can only select the three decimal places with the cursor but not the decimal point.
• Variables which receive their values from CANdb Signals (in the MKT-View terminals) cannot be edited.
• To enter edit mode for a certain cell, and to navigate between edit fields on a display page, use either the cursor UP/DOWN key or the rotary knob.
• For special applications, you can check if a field is in select- or edit-mode with an interpreter function (mm).
• If an edit field isn't connected to a display variable, but -for example- to a global script variable, the display interpreter doesn't know your variable's limiting range (min,max) when incrementing or decrementing the value via cursor keys or rotary encoder. To set a custom min/max range when 'beginning to edit' in such cases, you can define a Control Event Handler (OnControlEvent / evBeginEdit ) in your script, which writes the min / max range for editing into the system variables display.EditValueMin and display.EditValueMax .
  By listening for the evEndEdit event, a script can check and 'apply' the modified value after the operator finished editing it.
  This may appear a little clumsy on first sight, but it allows those min/max ranges to be determined at runtime, read from a database, received via CAN, etc.
  

Buttons (on a programmable display page)

• Pressing the optional hotkey (assigned to a certain button)
• Select the button with the cursor keys, or the rotary encoder knob, then press ENTER
• Use the touchscreen (optional, only available for certain devices)

Depending on the display hardware (TFT, colour or monochrome..), buttons can have different colours, colour gradients, or styles. For TFT displays with at least 255 colours, buttons can be transparent (or completely invisible), so they can be placed as invisible 'active touchscreen areas' over a background image (bitmap).

Details about the programmable buttons can be found in this extra document .

Icons (bitmap graphics on a display page)

(screenshot of the 'icon import' tab)

(screenshot of a complex icon definition on the "properties" panel)

• If the Icon in a "\i<Icon-Name>"-sequence is unknown (because it is not defined on the Icon Page), the sequence will be displayed as normal text.
• You should activate the option "always redraw this line" in the line property panel header, if you use "invertable" icons in a display line.
  Reason: The interpreter may not notice that the state of the <Invert-Flag> has changed because the Invert-Flags are evaluated only if a display line is "redrawn".
  To use the value from the "var/expr"-field as invert-flag, use the "v"-function.
• You should activate the option "always redraw this page completely" in the page definition header, if you use the "\m<Draw-Mode>"-sequence in a format string and <DrawMode> is a variable expression.
  Reason: Same as above.
  
  
  
• In devices with 32-Bit-CPU (like MKT-View II / III / IV), the position of an icon on the screen can be modified at runtime
  - see description of the script function display.elem[].x,y .
  
  
• For devices with 32-bit CPU, icons or bitmaps don't necessarily have to be imported (with the programming tool) before they can be used. Instead, icons can also be "loaded on demand" from a bitmap file stored on a suitable medium. Such a storage medium may be the memory card or (depending on the target system) a 'Flash drive' inside the programmable device.
  This feature was first implemented in the "MIL-terminal" with firmware #11356, where an 8 MByte extra "Audio-Flash" could also be used as a storage for icons. The necessary files had to be loaded into the device via File Transfer Utility, because that device didn't have a memory card. Other devices don't have an extra Flash chip (but a memory card), but the principle remains the same - regardless if the "suitable medium" is a memory card, the "font_flash"-partition, the "audio_flash"-partition, the "ramdisk", or a combination of all those media.
  The firmware will only try to load an icon from a bitmap file, if the icon with the specified name (in the backslash sequence) could not be found in the list of 'imported' icons.
  Reason: Importing the bitmap from a file, and adapting the pixel colours for the target-specific format at runtime is slower than importing the bitmap directly into the application. In the latter case, the programming tool has already adapted the colour palette, and modified each pixel in the bitmap, for the target device at design time. Thus, use bitmaps "loaded from files at runtime" only if you really need to; for example if your application uses megabytes or even gigabytes of graphics, which are impossible to embed inside a *.upt / *.cvt application.
  An example with images (bitmap graphics), which have not been embedded (imported) into the *.cvt / *.upt - file can be found in the demo application ?/programs/MKTview2/BitmapsFromExternalStorage.cvt .
  Since 2015-03-25, the icon backslash sequence may contain an complete (Pseudo-)file path for that purpose, e.g.:
    \i"memory_card/fant6.bmp"
  That way, you can be sure the bitmap will be loaded from the intended medium, even if a file with the same name exists in one of the other storages listed further above ("font_flash",etc).
  
  

  
  Screenshots from application 'BitmapsFromExternalStorage.cvt', with (left) and without (right) the required files on a storage medium.
  For non-existing images ("files not found"), the filenames are displayed instead of the graphics. Click on any image to magnify.
  

  If your application relies on bitmaps 'loaded from files at runtime', don't forget to distribute all those extra files along with the *.upt / *.cpt application (or upload them with the file transfer utility into "font_flash", etc) ! The bitmaps for the above demo are stored in the 'sim_mc' folder ("simulated memory card"), not in the programming tool's 'icons' folder.
  
  
• For coloured icons, i.e. icons imported from bitmaps with 4 or 8 bit/pixel, one of the 16 or 256 possible colours (in the bitmap file) can be used as transparent colour. An example for such a display page can be found in the file arm7_special\transparent_color_bitmap.cvt. The second colour value (which would be the 'background colour' for normal text lines) must be set to -2 (minus two, means "no background colour but transparent"). The third colour value must be set to the colour of all pixels in the bitmap file, which shall appear transparent on the screen later. In the test application, all white pixels (colour number 7) in the wolf spider image appear transparent on the screen (see left screenshow below). Because the "spider2" icon is always painted as the last element (when updating the display), the spider seems to sit on the screen (in front of all other display elements).

     
(screenshots from the 'transparent bitmap demo')

See also: Transparent buttons, Overlapping graphics, System Icons (Indicators for Logger, Audio Recorder, Power Supply).

Using Display Lines as Menu Items

Example:

g"Menu2" (assuming there is a display page called "Menu2" in your application)

This command has to be entered in the "Var/Expression" column of a display page definition. If you don't know the name of the 'destination' page yet, leave this field empty and use the Menu Link Dialog later to define all menu jumps (when all display pages of your application exist, much easier to use, the goto-command will then be generated automatically !).

You can –additionally- define a ‚hotkey‘ for this kind of menu on the display line property panel.

There are some UPT interpreter functions that give you additional control over this kind of menu:

• mi : returns the line number (index, 0..n) of the current menu item.
• mm: returns the current menu mode. It may be one of the following values:
  0 = Menu is "Off", that means the menu selection bar is invisible
  1 = Mode "Selecting", that means the menu selection bar is visible, the user may move the selection between all "menu items" on the current page using the cursor.
  Other "modes" are only valid for numeric edit fields, for example 2 = "editing the value".

There are also some "SET"-Procedures for this kind of menus, which have the same names as the "GET"-Functions:

• mi( <new_item> ) allows setting the "current" menu item under program control
• mm( <new_mode> ) allows setting the "current" menu mode under program control

You may find an example for this kind of menus in the file \programs\NEWMENUS.UPT.

Note: If you use a Display Line as a Menu Item, you cannot show the contents of a numerical parameter in that line !

Single Bargraph diagram (optional)

Display page with bargraph diagrams as 'tank level' indicators,
using transparent bitmaps as frames in the foreground.

Y(t) and X/Y-Diagrams (optional)

Dual channel Y(t) diagram on a 480*272 pixel screen.

Multi-Line Text Panels (used as "text screen" for the script language)

bo=<line width of the outer border in pixels>

The outer border is is painted with the display element's foreground colour .

bi=<line width of the inner border in pixels>

The inner border is is painted with the display element's background colour .

Example:     \panel(bo=6,bi=2)
defines a text panel with a 6-pixel wide outer border, and a 2-pixel wide inner border ("frame") around the text area, which reduces the size of the remaining 'netto text area' by 8 pixels on each edge (upper, lower, left, right).

(Screenshot from the script example "GPS Receiver Test")

To turn a display-element into a multi-line text panel, set the display element's type to 'Multi-Line Text Panel' on the page definition tab:

During edit mode, as long as the script has not printed any text into the text screen buffer, the programming tool will fill the text area with dummy characters, so you can easily see if the size of the text panel is properly aligned to a multiple of the font size. All characters in a multi-line text panel use the same font (as defined for the display element, see screenshot above).

A text panel can also be used as a control event (for example, react to touchscreen events). Details and examples can be found in the manual for the script language.

See also : script language (external link, only works in the HTML-based help system, but not in PDF documents), script: print, script: gotoxy, script : setcolor .

Graphic Panels (displaying script-generated 'Canvas' graphics)

Example for displaying a Canvas object in a backslash sequence.
Here, the script contained a tCanvas-object named "MyCanvas",
which will be set to the specified size of 748 by 400 pixels.

Inserting other grahic elements on a display page

Overlapping graphics

For some special effects you may place some visible elements (text or graphics) in front of other visible elements.

For example, there may be a large icon in the background and a text display line in front of the icon.

To achive this effect, the icon must be drawn first and the text must be drawn afterwards. The sequence (or "drawing order") is defined by the row number in the screen definition tables.

The first line in the display definition table (line "0") will be drawn first, the second line will be drawn after that and so on.

When using overlapping graphics, you may have to set the option "redraw page completely" in the page definition header, even though this slows down the application a bit. The same applies for moving graphics.

If a graphic element is completely overlapped by another element (like the completely opaque vertical bargrah in the following example, which is completely overlapped by a transparent bitmap) it's sufficient to set the flag 'always redraw this line completely' (instead of completely redrawing the entire page):

(screenshot from the 'Transparent Bitmap Demo',
file arm7_special\transparent_color_bitmap.cvt)

To modify the drawing sequence, press and hold the left mouse button over the leftmost column (labelled "Nr") in the display line definition table, then (with the mouse button still pressed) move the item up or down. Remember, the topmost element in the table is painted first, and the last element in the table is painted last.

See also: Table of contents, selecting an overlapped element in the LCD simulator,
      transparent bitmaps, transparent buttons, scripted graphics in the OnPageUpdate-handler.

Touchscreen support

Multi-Language Applications (and how to realize them)

• Duplicate all existing display pages from the 'primary' language, and rename the cloned display pages by adding a language-indicating prefix or suffix in the Seitennamen, e.g. "Menu_01" instead of just "Menu" for the main menu in English language, "Menu_49" for the main menu in German, etc..
  

  Disadvantage:

  You also need to carefully edit all page-switching commands in your application ("goto <page-name>) by adding the language suffix/prefix, e.g.
  g "Menu_49" to jump into the main menu in German language,
  g "Menu_01" to jump into the main menu in English language, etc.
  
  

  Advantage:

  Easy to implement and understand, and the tool's display page overview will show all display pages in all languages implemented so far.

  
  
• Move (or copy) all character strings from all display pages into a string table, text file, or similar; whatever you can access with a self written script function (e.g. script.GetText() in example 'MultiLanguageTest.cvt', or TranslatePage() in 'i18nDemo.cvt', from where the screenshots shown further below were taken).
  To translate all strings on any display page via script, immediately after the original (non-translated) page has been loaded from Flash memory into RAM, implement the OnPageLoaded() in your script (it was designed especially for that purpose), or copy it from script_demos/i18nDemo.cvt (don't forget to tailor the "multi-language string table" in the script for your application).
  
  

  Disadvantages:

  Quite advanced for a beginner (you will need at least a bit of programming experience), and (if all those character strings are moved into a text file or string lookup table) not easy to test, because simply by looking at the translation table, you don't see if a translated string still fits into all display elements (text fields, graphic buttons, etc) on all display pages. So you need to run the multi-language application, and test all languages, to find out if everything still fits (not an easy task if you don't know the language, to judge if a truncated string is still 'sufficiently informative').
  Also: Loading a 'translation file' via script at run-time from a file may take a few seconds (once, when booting), and is only possible on devices with the 'extended' script functions unlocked because otherwise, the script doesn't have the file I/O functions for accessing the SD memory card and/or the Flash-Speicher (in pseudo-folder "font_flash" oder "audio_flash").
  As an alternative, use a hard-coded translation table in the script itself.
  

  Advantage:

  Regardless of how many languages you support in your application, the number of display pages doesn't change because each page itself is 'multi-language capable' itself. Once multi-language capable, it's easy to add more features (and display pages) to an existing application, because you only add a page and it's "program logic" once.
  

   
One of the script-translated display pages in script_demos/i18nDemo.cvt.
This simple example uses a 'string translation table' implemented in the script itself.
Thus the application only requires the *.cvt file, no other (external) dependencies.

The "simple" (graphic) editor for display pages

Page editor toolbar

 (Arrow or Pointer tool) : Move or modify items on the screen.

Hold the mouse pressed and move it, to modify the element's pixel position.
Use the CTRL-key, or pull a marker frame (start in an empty region on the screen) to select multiple items at once. More on that further below.
Single-click on an item to select it (for cut / copy / paste operations).
Double-click on an item to open a special property editor for it.
Sizeable elements (like buttons) can be resized after being selected by dragging the small square in the element's lower right corner with the left mouse button. The 'sizing corner' then turns orange (instead of the normal red frame around the selected element), which indicates 'element is being resized'. While resizing, the element's upper left corner remains fixed:

Modifying the size of a display element (here: a button)
by dragging the orange-coloured 'sizing corner' .

 (Text tool) : Insert a simple alphanumeric TEXT line on the screen.

First select this tool (click at the symbol in the toolbar).
Single-click into the screen to place a new text item there.
After that, a special dialog opens where you can edit the new item.

 (Icon tool) : Insert an Icon (symbol; bitmap graphics).

Use this tool to insert small bitmap graphics ("Icons") on the display page.
Note: Before you can insert bitmaps here, they must be imported on the tabsheet "Icons" in the programming tool.
After inserting an icon, you can modify its appearance (colour, zoom, different symbols depending on the value of a variable, etc). Use the arrow tool for this, and double-click on the icon in the editor screen.

 (Button tool) : Insert a graphic button.

First select this tool, then click into the screen to add a button.
After that, a special dialog opens where you can edit the button.

 (Bargraph tool) : Insert a bargraph.

First select this tool, then click into the screen to add a bargraph.
After that, you can modify the bargraph in a special dialog window.

 (Diagram tool) : Insert a diagram.

After selecting this tool, click into the screen to add a diagram.

 (Insert Other Objects) : Opens a sub menu with other 'insertable display elements'

Those less frequently used elements include tables, polygons, analog meters ('needle instruments'), etc.

 (Cut tool) : Cut out the selected item.

First select the item which you want to remove (with the Arrow tool),
then select the "Cut" tool (scissors).
When cutting, the selected item is copied into an internal clipboard-like memory, but this is not the windows clipboard.

 (Copy tool) : Copy the selected item.

First select the item which you want to copy (with the Arrow tool),
then select the "Copy" tool.
The selected item is copied into an internal clipboard-like memory, but this is not the windows clipboard.

 (Paste tool) : Paste item into selection.

First select the item which you want to overwrite (with the Arrow tool).
If you don't want to overwrite a selected item, select nothing.
The item stored in the internal clipboard-like memory will be pasted to the screen.
If an item was selected (marked with a red selection frame), it will be replaced with the "pasted" item.
If no item was selected, the item will be inserted at the position of the insert cursor, which is marked with a small red dot.
The insertion cursor can be set (before inserting an item) with a short click into a non-occupied screen area.
After inserting an element, the insertion cursor will be moved down (or right, at the bottom of the screen), depending on the size of the object which has been inserted, so that there will ideally be no overlap. This way, it's quite easy to fill a page with equally spaced items.

 (Undo tool) : Undo recent operation(s).

Click this 'UNDO'-button to undo the recent operation.
In the page editor, up to 20 (?) operations can be undone, because they are saved in an undo-history.
Caution: If you exit from the current page in the editor, the changes cannot be "undone" anymore !

 (Redo tool) : Redo recent undo-operation(s) aka "un-undo".

Click the 'REDO'-button to undo the recent und-operation.
In the page editor, up to 20 (?) undo-operations can be undone, there is an extra buffer for this.
Caution: If you exit from the current page in the editor, the changes can neither be "undone" nor "redone" anymore !

The selected object is marked with a red frame in the drawing area.

To move or copy a group of objects, use the 'Arrow / Pointer' tool to select multiple objects. Hold the CTRL-key pressed, and click on each object which shall be added to the selection.
Alternatively, first move the mouse (pointer) into an empty area, close to the upper left corner of the first to-be-selected object. Then press and hold down the left mouse button, while pulling the mouse from the upper left to the lower right corner of the selection area. This spans a shaded rectangle over the marked items as shown below:

(Screenshot of the 'simple graphical editor' with multiple objects selected via mouse; left mouse button still held down)

When releasing the mouse button, the shaded rectangle (spanned with the mouse) disappears, but all objects covered by it remain selected.
To move the selected objects on the screen, grab one of the selected items with the left mouse buttons (otherwise, clicking outside the selected objects de-selects all), and -with the left mouse button held down again-, move the selected object(s) to the new position.
If multiple objects are selected by red frames, 'Copy', 'Paste' and 'Cut' applies to all of them. So you can quickly copy a block of multiple objects from one display page to another.

The combo box in the editor's toolbar allows you to select individual display elements (in addition to selecting them with the arrow tool). This may be necessary for example, if a display element is completely obscured by another, and cannot be selected with the mouse directly.

Selecting a single object in the drawing area (with the arrow tool) will also select that object in the combo box shown above.
The entries in the combo box can be interpreted as follows :

[line number] ELEMENT-TYPE : element-text

Example:

[5] TEXT : The EA515..

which means:

The currently selected display item is defined in line number 5 (an array-index; numbering starts at zero);
the item is a simple TEXT (alphanumeric);
the display text begins with the string "The EA515..".

Graphic controls can be aligned to an 8 * 8 pixel grid. To show this grid, or let a coordinate snap to the grid, select "Option"..."Page Editor" in the programming tool's main menu. If the option "Snap coordinates to 8*8 pixel grid" is active, the upper left corner of an object will be aligned to the nearest grid point when moving the object with the mouse.

At the time of this writing, only the following display elements were supported by the "simple" page editor:

• TEXT : simple text, with or without variables (use asterisks as placeholder characters). Can be edited in a special dialog.
• ICON : small bitmap graphics ("symbols")
• BUTTON : graphic button (details in 'btns_01.htm').
• BARGRAPH
• DIAGRAM : Y(t) or X/Y-Diagram (details in 'diagr_01.htm').
• TABLE : Table (Control- or display element with multiple rows and columns)
• POLYGON: Polygon (lines, or shapes like rectangles, triangles, etc; editable "point by point").
• METER: an analog meter ('needle instrument')

Special functions like graphic interpreter commands or script-generated text are not supported by this editor (they must be edited 'as text').

The functions Copy / Cut / Paste, and the 'Property' dialog for a certain display element can also be launched through the graphic editor's context menu (right mouse button).

Dialog box for alphanumeric display elements

Creating and modifying polygons with the graphic editor

For experts and advanced users:

The graphic editor generates an "\li" backslash sequence ("li" = "lines"), followed by the coordinates of all points in the polygon.
The argument list (after "\li") may also contain graphic elements like polygon(), polyfill(), etc.
The syntax of "\li" is described here (including the use of commas and semicolons to control drawing lines between points).
Like any other display element, a polygon can also be edited 'as text'.
To do that, mark the polygon in the editor, right-click into it, and select 'Properties' in the context menu shown further below.

Examples for lines, polylines, polygons using the '\li' command

Simple line with start- and endpoint taken from variables (requires manual input 'as text'):

\li(x1,y1, x2,y2)

Four-pixel wide line (parameter "w"=width)

\li(w=4, x1,y1, x2,y2)

Two lines (note the semicolon as separator between coordinates with "pen up")

\li(8,8, 8,88, 88,88; 16,16, 16,80, 80,80)

Closed, but not filled polygon (here: triangle)

\li(polygon(0,99, 50,0, 99,99))

Filled polygon with a 'thick border' :

\li(polyfill(w=4, 5,95, 50,5, 95,95))

Filled polygon without border (no lines around the filled area) :

\li(polyfill(5,95; 50,5; 95,95))

Creating an analog meter (needle instrument) with the graphic editor

Screenshot from application 'analog meter test'

Bearings on a compass (in degrees)

Examples:
  Analog voltmeter: StartAngle=-45 (or 315 degrees), EndAngle=45 .
  Round tachometer: StartAngle=-135, EndAngle=135 .
  Analog clock (see example shown further below): StartAngle=0, EndAngle=360 .

For round instruments, the pivot (rotating axis) is always centered.
For instruments with rectangular shape, the pivot is optimally placed for the largest possible circular path of the indicator's tip. Thus the position of the pivot depends on the angle range. For small ranges (like the "Voltmeter" with StartAngle=-45, EndAngle=45°), the pivot point may even be outside of the visible area.

Besides the main arrow (or needle), two additional indicators (pointers, needles, markers) can be displayed inside the analog meter. The position of these extra indicators may be a simple numeric constant (value), variable, or even a numeric expression to scale them properly.

To insert an analog meter on a display page, right-click into the LCD simulator window, and select 'Insert analog meter' ('Zeigerinstrument einfügen'). As for any other display element, the specific properties can be modified in the right half of the programming tool's main window:

Property panel for an analog meter (Zeigerinstrument)
in the programming tool's display page editor

Defining Events – overview

• User presses or releases a certain key on the terminal
• User turns the optional rotary encoder knob
• The value of a variable exceeds a certain value (may have been received via CAN)
• One bit of a variables is set to a certain value
• and more combinations.. see event definition language in the next chapter.

For every event you also have to define a special "event reaction". A reaction can be defined as a sequence of interpreter commands .

Possible reaction methods are:

• Switching to an other display page
• Setting a certain variable to a certain value (which may be sent via CAN)

For the definition of events we use a simple event definition language, but you may also define events for a display page by selecting them from list.

Events may be defined...

• "global", that means not depending on the current display page;
• "local" on a display page, which means only active when this page is the current page.

To define events, you can use the event-definition window explained in the next chapter. Advanced users will enter the interpreter code directly, others may prefer the 'global event catalog' .

Related topics:

• interpreter commands
• numeric expressions
• Event Handling in the Scripting language (for devices with 32-bit CPU, for more advanced control)

Defining Events - the definition window

The propery-panel on the right shows more detailed information about one single event definition.

You may edit the properties of a display line in the table or on the property panel, the information will always be updated on both parts.
A single breakpoint can be set on a certain event by checking 'Set breakpoint on this event' on the property panel. It will fire whenever the condition for that event becomes TRUE, before actually executing the reaction. To execute a single step (after being stopped by a code- or data-breakpoint), press function key F11 on the PC keyboard. There is no button or menu item for this.

The "Add event" and "Add reaction"-Buttons on the property panel open special dialog windows, which can be used to define event definitions or reactions (especially if you are not familiar with the event definition language).

To inspect the current value of variables or certain expressions in an event definition table, simply point the mouse over the cell (without clicking). If the interpreter can evaluate the 'word' (delimited by spaces or other special characters) under the mouse pointer, the result will be displayed in the status line at the bottom of the main window.

During a simulator run, the background colours of cells in the event definition table indicate which events (conditions) are currently active (condition = TRUE), and thus which reactions have been invoked during the last update cycle (as far as the GUI update speed permits).
This is similar as the 'Condition Actions' in the CAN-Simulator:

• Light green background :
  The condition in this line is (or was) TRUE, and the reaction has been executed without errors.
  
• Yellow background :
  Indicates the next to-be-executed line in single-step mode, e.g. after hitting a breakpoint as explained further above.
  
• Light red background :
  There was an error when evaluating the event (condition), or when executing the reaction (command line).

Defining Events - the definition language

Note:

The programming tool may display some of these events in a longer, human readable form, like page_enter instead of "pe".

A few simple expressions are listed below:

Event-Type / expression	Parameter (if required)	Description
kd	key-name	user has pressed a key
ku	key-name	user has released a key
kb	key-name	buffered keyboard event. The specified key will be removed from a buffer !
kh		any key has been hit (system keys too)
kc		reads and removes a system key code from a buffer.
kcb		reads the code of the last pressed key, but does not remove it from a buffer
cb		CAN-Error: Bus Off See also : 'cs' (CAN Status)
ce, alias ce0		Severe CAN-Error on the first CAN port
ce1		Severe CAN-Error on the second CAN port
cw		CAN-Warning
ch		CAN-hardware fault
co		CAN-Error: Overflow
ct		CAN-Error on transmit See also : 'cs' (CAN Status)
else		Returns TRUE, if the previous Event-condition was FALSE. Only supported by firmware compiled 2012-10-15 or later ! Example
t0 ... t3		User-timer ( nr. 0...3) has run off
ti_ms>1500		Over 1500 milliseconds elapsed since power-on
pe     alias page_enter		Current page has just been entered (Page Enter)
pq     alias page_quit		Current page will soon be left (Page Quit). Like any other page-event, this event can only occurr on the currently 'visible' page, not on any other page ! To implement a centralized method to react on 'any kind of page-switch' (regardless of the current display page number), we highly recommend to use the Script Language ("OnPageLoaded").
pr     alias page_redraw		Page Redraw, the current page must be redrawn. Occurs together with "pe" or after calling cls (=clear screen command), or when setting display.redraw in a script.
pdo[N].rcv		A PDO telegram has been received .
rot.l, rot.r, ...		The rotary encoder ("knob") has been turned
syn.rcv		A SYNC-Telegram has been received .

The terminal's interpreter evaluates the event definition as a boolean expression. You may also use more complex numeric expressions as event definitions.

If the result of an event-definition (or expression) is non-zero, the system interpreter executes the corresponding reaction method. An event reaction method is (internally) coded a string of interpreter commands.

Example: Modify the background colour of a display element (from 'Auslieferungstest.cvt'):

   Event (condition)                 Reaction
   (sys.vsup<120)||(sys.vsup>260)    dis.VSup.bc = (ti&8)?7:4 : REM flashing supply-voltage warning
   else                              dis.VSup.bc = white      : REM no voltage warning
      
      

See also: Overview of numeric interpreter functions.

Global and Local Events

For example, you may wish to "call" a certain display page whenever there is a severe error on the CAN-Bus. This can be achieved by the following example:

Event-Definition: ce (which means: "if there is a Can Error"...)
Reaction: c"CanError" (which means: ... call the page named "CanError")

Define this Event and it's reaction method on the "Global Event" page, so you don't have to define it on every used page (remember, the number of lines on a page is limited !).

There are some rules for global events that you should use:

• Use global events for all events that would otherwise be equal on every page definition.
• Don't use display output commands in the reaction methods of global events, because this might "interfere" with the screen output of some of your pages.
• If you defined a certain event as a global event (like "ce" in the example above), you should not define this event again as a "local" event on any display page. However, defining an event twice does not hurt the event handler. If many event definitions are TRUE at the same time, all their correspondig reaction methods are executed.

Local events always belong to a certain display page (they are only checked if that display page is visible). In most applications, local events react on keyboard actions and switch to other pages.

Simple GLOBAL events can be selected from the global event catalog (a special dialog which can be opened from the Global Events page).

return to the event definition overview

Assistants and dialog-based utilities

Assistant to create simple display applications

(Screenshot 'Select target hard- and software profile')

Technical brackground:

For many devices, for example MKT-View II, there is only one hardware profile, which contains the screen resolution, colour model, and much more. In addition there are multiple possible software profiles (for the same hardware), depending on the loaded firmware.
For example, you can select a software profile for a CANopen device (UPTv1=DS301 V3, UPTv2=DS301 V4); or (for all devices withoutCANopen-Firmware, but instead 'CANdb') select 'CVTv1' as the software profile (CAN-View-Terminals, z.B. MKT-View II mit Firmware #11314).
The programming tool may ask you to use a different tool; because (for example) the programming tool for devices with 'CANdb' (DBC, automotive) doesn't support CANopen itself, and thus will not be able to load the display application into the device via CAN.

(Screenshot 'Create Display Pages')

Variable Selection Dialog

(Screenshot "Buttons on the display line tab")

(Screenshot of popup menu "display lines")

For devices with CANdb functionality only:

If you have a large number of SIGNALS, it may be difficult to find the required signal, when you don't know the exact name of the NODE and MESSAGE. There is a global search function for SIGNAL NAMES through all NODES and MESSAGES. Activate it by right-clicking into the NODE LIST. A popup-menu appears; select "Find Signal" and enter the signal name. The search function is not case-sensitive, so don't care about upper or lower case letters when entering the search string.
Because different messages could carry different signals with equal signal names, the search can be continued at the current position in the database ("find next occurrence of XYZ").

See also:

• Properties of a Display Line Definition
• Variables

return to the table of contents

Menu Link Dialog

The menu selection (=blue mark in the table) will switch to the next menu line after selecting a new menu (which minimizes the number of mouse-clicks if you want to re-define all menu links on a display page). You can also select another menu line by clicking into the table.

Note:

Modifying the text of menu lines, or the graphic appearance, is not the task of this dialog. Use the display definition screen to change the displayed text, font, graphic location, etc.

If there is something wrong with the menu definition, an error message in red color appears on the dialog screen. Usually, the reason is a menu link to a non-existing display page. All invalid menu destinations are also marked in red color in the table.

There are some checkboxes in the lower right corner of the menu link dialog:

Select new line automatically

Enables or disables the automatic selection of a menu line (to minimize the number of mouse-clicks)

Replace (variable-) name in menu (-text)

If the name of the destination page is embedded in the menu text, it will automatically be replaced with the name of the new destination page. If the name of the destination page was not part of the menu text, the menu text will not be changed.
Note: To EDIT THE MENU TEXT, use the display page definition tab.

If the menu link dialog has been opened from the display page overview, you can use the "previous" and "next" buttons to modify the menu links on another display page.

After you have selected destination pages for all existing menu lines, click "OK" to accept the changes.

return to the table of contents

Assistant 'Check & correct all display pages' When 'recycling' display pages from an old application for a new purpose, problems may occur if (for example) the copied display page contains references to variables that have not been defined in the new application yet; commands to jump to another (not-yet-existing) display page, aka "broken links", etc.
To spot such problems more easily, in the programming tool's main menu, select 'Assistant', option
    Check & correct all display pages .
The programming tool then scans all pages (and all display definitions on those pages) for errors like:

• References to undefined / deleted display variables on a display page
• Placeholders for not yet defined variables on a display page (e.g. <SelectMe> instead of a proper variable name)
• Jump to a display page with unknown name or 'number' (e.g. a 'broken menu link' / "goto")
• Errors in numeric expressions (i.e. if the to-displayed value isn't a simple variable, but 'calculated', with a bug in the formula)

Depending on the type of the error, and the position (page, definition line, column), the corresponding table cell will be coloured (on the tabsheet "Page #"). Errors like references to non-existing varibles will have a red cell background, warnings (e.g. placeholders like '<SelectMe>) are marked with a yellow background.
Besides that, if necessary, this assistant may automatically invoke the dialog to select variables on a display page.

Global Event Catalog (deprecated)

(Screenshot 'Global Event Catalog')

• switch from one page to another
• switch to a certain page if a serious CAN-BUS error occurrs
• ...

See also:

Event definition overview

Display Page Overview ("all pages")

• insert a new, empty page (before the selected page)
• delete the selected page
• copy & paste a page (to modify the page sequence)
• check all menu links on the selected page

Options for the display page overview:

[v] Stretch view

The display page overview uses streched (or compressed) preview-images with a fixed size (usually smaller than the original display resolution).
You won't see each pixel with this option, but more pages will fit on the screen without scrolling.

[v] Allow calling script

Without this option, no script functions are called when generating the preview. This improves the speed of the update, especially if the script must do a lot of work (for example, read the actual display text from a network, or from a file).
Instead, when generating the preview for a display element which uses a script to retrieve the text (string), the preview will show '<generating preview>'.
Depending on your script, this option may also avoid side-effects like increased network traffic.

See also: display page definitions, table of contents

The Icon import screen

You can modify the icon pixel by pixel (click into the image on the right) but it's easier to use an image editor like "Paint".

The name of the bitmap file must be a valid DOS filename, because the internal storage of huge objects may be based on a file system similar to DOS . For that reason, make sure the filename is compliant with the following guidelines (which applies to other names, too):

• The name must begin with a letter (a..z, A..Z) .
• The name must be 1 to 8 characters long .
• The 2nd to 8th character must be one of the following:
  a..z, A..Z, 0..9, or _ (underscore character). NOTHING ELSE. Especially no spaces, even though some think it's cool to allow spaces in filenames. WE DON'T.

In older devices with only 256 colours (e.g. MKT-View II), only bitmaps with 1, 4, or 8 bit per pixel could be imported; thus monochrome, 16-colour, or 256 colour bitmaps. The colour palette is always fixed, so don't expect the image to look exactly the same way as in your image processing software with 16 million colours ("true colour").

For experts:

• The tabular overview with all imported icons/bitmaps list names, width / height (in pixels), and the bitmap type / colour depth. The decimal codes for these 'bitmap types' are the same as used when embedding imported bitmaps 'as text' in the *.cvt- or *.upt file:
  

  0 = monochrome (one bit per pixel)

  1 = 16 colours, four bits per pixel, only standard colours (colour indices 0 .. 15)

  2 = 256 colours, eight bits per pixel, no palette but format RGB-3-3-2

  3 = 256 colours, eight bits per pixel, reserved for bitmaps with an individual colour palette

  4 = 65536 colours, 16 bits per pixel, format RGB-5-6-5

• The 256-colour palette uses 2 bits for the blue channel, 3 bits for the green channel, and 3 bits for the red channel. Some image conversion tools (like IrfanView) can optimize "high colour" or "true colour" image for such a palette, using a smart method like Floyd-Steinberg dithering. Such methods produce better results than the simple import filter (implemented in the programming tool), which always picks the closest colour from the device's 2+3+3-bit RGB palette.
  
• The process of converting an image with IrfanView, using an optimized palette, is described in the file 'readme_irfanview.txt' located in the 'icons' folder of the programming tool.
• Since November 2021, the 'remaining free space' (number of kBytes in Flash) displayed in the lower panel of the icon import screen must be taken with with a grain of salt, because many targets (like the MKT-View III and IV) internally compress certain bitmaps to reduce their memory footprint.
  The only reliable indicator for the target's remaining Flash memory space is in the target itself; it can be invoked from the Setup/System Menu via Diagnostics .. Storage Directory. The occupied and remaining internal Flash memory is displayed in the bottom line (below the list of stored items), e.g.
    Used: 672; unused: 357 kByte .
  
• In some devices (with sufficient code memory), the list of imported icons, and their individual memory consumptions can be inspected by selecting the line with 'Type=ICON' in the 'Storage Directory' and pressing ENTER. This opens the 'Icon Browser', where all Icons can be listed (and optionally displayed as graphic), along with their compressed and uncompressed sizes.
  

Reserving memory for icons (and other special features)

static (very old)

All display pages have the same size in their flash storage (a simple array), icons are stored in an extra memory area (or even a separate Flash device). This method was only used in very old devices with an 8-bit CPU, e.g. "UPT-515".

static, shared (old)

Display pages still occupy a fixed size in Flash, but share the same memory area with icons, text arrays, display pages, etc. This method was only used in old devices with a 16-bit CPU, e.g. "MKT-View I".

flexible, shared

Display pages only occupy as much Flash memory as needed, depending on the number of elements on a page (and their 'complexity', i.e. length of the definition line. All kinds of strings are stored with a variable length ("as short as possible", as far as CPU-dependent memory alignment permits). Icons, display pages, text arrays, scripts, variable declarations, extracts from CAN databases all share the same Flash memory. This method is used in all newer devices with a 32-bit CPU, e.g. "MKT-View III / IV / V".

Memory usage for older devices (with 8- or 16-bit CPU, or firmware compiled before 2009-08-05) :

Flexible memory usage for newer devices (with 32-bit CPU)

• Icon Memory Shared (which is the parameter "t icons_shared" in the *.CVT / *.UPT - file) :
  0 = Icons use their own FLASH memory sector; display page sizes are static ( "old" terminals / firmwares, MKT-View, all 16-bit CPUs)
  1 = Icons and display pages use a common FLASH area, display page sizes are static (for example "UPT515")
  2 = Icons, display pages, and others use a common FLASH area, all objects have a variable size in FLASH-memory (only for 32-bit CPU,
  for example "MKT-View II", "MKT-View III", "UPT 320", and other devices with 32-Bit-CPU (ARM-7 or Cortex-M); firmware compiled in August 2009 or later)
• Max. Data FLASH Size (which is the parameter "t max_free_mem_kbyte" in the *.CVT / *.UPT - file) :
  Spezifies the size of the FLASH memory usable to store display pages, variable definitions, text array lines, icons (images), and other objects. A different part of the FLASH memory is used for the terminal's firmware and operating system; making the available "free" memory size depending on the hard- and firmware. For example, in the "UPT 320" (terminal with 5.7" TFT display, 320*240 Pixel) with firmware #11352, there were 896 kByte FLASH memory avaiable for the user application ("display program").
  

CANdb Display Terminal (...) Compiled: Aug 5 2009 (...) Loading .... ( unused : 761 kByte )

For that reason, to adapt an "old" application for a "newer" terminal firmware (with flexible FLASH memory usage),

select Options .. LCD Settings / Device Selection in the tool's main menu,
and select your target device from the list again (even if it is already selected).
The programming tool will then look up the properties of the target hardware from an internal database, and adapt the most important settings if necessary.

Determining the Flash memory usage in the target

Estimated Flash Memory Usage Item Size Display pages : 38 kByte Display vars : 6 kByte Global events : 21 kByte Text array : 1 kByte Icons, Bitmaps : 142 kByte User def'd fonts: 1 kByte Script Sourcecode: 0 kByte CAN databases : 8 kByte CANopen (config): 1 kByte Target Size : 832 kByte Total USED Size : 214 kByte Remaining, free : 618 kByte ...

Note:

In many devices, the Flash memory is not only used for the user application, but also for the device firmware and the bootloader. This is already considered in the 'Target Size'. Thus, for many devices, the indicated 'Target Size' isn't a nice power of two (as one would expect for a Flash memory chip). The precise target- and firmware-dependent memory size(s) can only be determined by the device itself (see link to the 'Storage Directory' display further below). Especially devices with a customer specific firmware may contain items that the programming tool isn't aware of !

Return to the table of contents

User-defined Fonts

Debugging

• The "watch"-window can be used to examine the contents of some variables or other expressions;
• The "test command"-window lets you enter commands for simulated received CAN-telegrams etc.
• The "Error page" shows error message from protocol violations, and other messages.
• The "Logfile Replay Utility" allows to play CAN messages from a file, instead of a 'real' CAN bus.
• For the script language, additional tools like breakpoints, single-stepping, inspection of (script-)variables, trace history, etc are avaiable.

Besides that, the following debugging options can be used without a programming tool :

• For devices with Ethernet (LAN) port and integrated web server (like MKT-View II), you can remotely control and supervise the device through a web browser (at least, with Firefox). On the 'Remote Control'-page, you can send commands to the display interpreter, and you can inspect variables (similar to the programming tool's 'watch'-window). Technical details about the web server can be found here (online, on the MKT website).
  Details about the network configuration (IP address, HTTP server port, etc) can be found in document #85115, "System Setup" .
• Devices with a 32-bit CPU (like MKT-View III/IV) have a built-in error history, which can be inspected through the terminal's system menu (in the system menu, select 'Diagnostics'..'Error History'). The number of errors, warnings, or notifications currently stored in the history is shown in parentheses, so without actually entering the history, the 'Diagnostic' menu indicates if the error history is empty or not.
  The 'Error History' may also show warnings and notifications from the script compiler and -runtime.
  

Try the table of contents if you need further help.

Watch window

The watch window is a debugging tool. It can be used to display the values of some numeric expressions. This window can be opened via the main menu of the programming tool ("View").

You may enter any numeric expression in the left column of the table, but you should avoid calling functions with "side effects" (like kb) in the formula. To examine values of your script (running in the background), use the prefix 'script.' before the name of a script variable or -function call. Inspecting entire structs or arrays is not supported here - use the script debugger for that purpose.

The 'Format' column can be used to define how the calculated values shall be displayed (output type and number of digits). Possible format types for the watch window are:

• d,D decimal
• +,- decimal, always signed
• h,H hexadecimal
• b,B binary

You may also specify the number of digits for the watch display. Type the number of digits directly after the format letter. Examples:

Expression	Format	Result (value)
script.Math.sqrt(2)	d20	+             1.414214
script.display.EditValueMin	d7	- 100.00
script.display.EditValueMax	d7	+ 100.00
10 / 3		+00000003 (result = integer)
1.0 / 3		+ 0.333 (result = floating point)

Note: If a watch expression is incorrect, the interpreter will generate error messages which may appear on the error page of the main window. Because all expressions in the watch window are evaluated frequently, the list of error messages may get quite long !

The current value of the expression is displayed in the column titled "Result". In some cases (for example if the expression is just a simple variable) it is even possible to modify (edit) the displayed value here. To do this, click into the cell with the displayed value, overwrite it (type the new value into the field), and press the ENTER key when finished.

See also: Inspecting Arrays, Overview of Debugging aids, table of contents

Test Command Window

Note:

The "sim_rx" command dates back to the early days of the programming tool (anno 1999).
The CAN bus simulator is a more versatile replacement.

The lower part of the window is used to display "results" after some commands like "print" or if errors occurred during the execution of a test command.

Note: All these commands are executed "locally" by the command interpreter of the UPT programming tool. You do not have to connect a real UPT-hardware for debugging.

See also: Overview of Debugging aids, table of contents

Logfile Replay Utility

Starting the CAN Logfile Player

'Tools' ...

Play CAN Logfile to the Simulator

from the programming tool's main menu. A file selector will ask you for the location of the CAN logfile, and for the file type (usually 'Vector ASCII Logfiles / *.asc').

After that, a control window for the logfile player will pop up:

Click on the VCR-style 'Play' button [►] to start playing CAN messages from the file into the simulated CAN-bus. In fact, the messages read from the logfile are injected into the CAN-driver's low-level receive buffer.

Optionally, you can play the logfile over and over in 'Loop Mode'. This is especially helpful if the file only covers a few seconds of recorded CAN traffic.

Since May 2015, the relationship between CAN bus numbers in the Vector ASCII Logfile (*.asc) and the CAN interface number in the simulierted device can be edited in the Logfile Player's control window (see screenshot, "Source Channel for Bus 1" = 1", "Source Channel for Bus 2" = 2). If necessary, up to four source channels can be entered (separated by comma). With these defaults, CAN messages recorded as 'channel number one' in the ASC file will be treated as if being received from "CAN1" (in the simulated MKT-View), etc. Reason for this: A customer had to simulate a CAN network where the first CAN interface (from the MKT-View's point of view) had been recorded as channel number 8 (EIGHT) by some unknown tool.

During playback, the CAN-messages can also be displayed on the 'error page' (set the option 'Show RX Frames' to see received CAN messages; in this case: "received" means "played from the CAN logfile into the simulator").

Rejecting certain CAN messages in the Logfile Player

Automatic Stop of the CAN Logfile Player via script debugger

CAN Message Generator / Simulator

Wireshark-compatible Packet Capture option

Browser-Screenshot with 'Ethernet Packet Capture'. Click into the image to magnify it.

'Real' Wireshark screenshot showing the same captured data. Click into the image to magnify it. Note that Wireshark identified a 'TCP Retransmission' to indicate a minor problem, which the built-in capture display (shown in the screenshot on the left) did not.

Packet Capture Status : Running, captured 5 packets .

    No.    Time    Source            Destination     Prot Length Info
    1     0.00000                   CAN1:0x07B        CAN    8  00 02 03 04 05 06 07 08              
    2     0.13405 CAN1:0x000003FF                     CAN    8  05 44 4C 34 59 48 46 20              
    3     0.43712                   CAN1:0x07B        CAN    8  01 02 03 04 05 06 07 08              
    4     0.53385 CAN1:0x000003FF                     CAN    8  05 44 4C 34 59 48 46 20              
    5     3.12532 192.168.0.206     192.168.0.234     TCP  117  TX "HTTP/1.0 200 OK\r\nContent-Type:"

• Looking for 'lost messages', for example in periodically sent CAN frames :
  Define a filter like "frame.time_delta > 0.1", to show only frames following a (time-) gap of over 100 milliseconds (since the reception of the previous packet).
  Because filtering for a certain CAN message ID is (or at least was) difficult in Wireshark, turn off the option 'any ID' via web browser, before starting the capture. Without the option 'any ID', the packet capture will only contain CAN messages with 'registered' message identifiers, for example messages that your application wants to receive via script, or CAN messages carrying signals defined via DBC-Import, and connected to display variables.
  

See also: Overview of Debugging aids, CAN functions in the scripting language (added 2010-09), table of contents .

CANopen Configuration

Not for terminals with exclusive "CANdb" functionality like MKT-View (see Feature Matrix)

Configuration of the SYNC message

NMT Configuration (CANopen network management)

• CANopen object dictionary of the programmable terminal
• SDO access functions (only for terminals with CANopen V4)
• SDO error codes ("abort codes")

Data Transfer between the programming tool and the programmable device

1. Transferring the application into the terminal ("Upload")
2. Firmware-Update
3. Remote control (for devices without a keyboard)
4. Transferring other files (with the File Transfer Utility)
5. Upload via Ethernet ( UDP ) using the programming tool
6. Uploading files via web browser (TCP/IP; external link)
7. Discovering MKT devices on Ethernet (using a DHCP server)
8. Automatic display program update via FLASH memory card

For devices with FLASH memory card (like MKT-View) we strongly recommend to transfer the application (*.upt or *.cvt) via memory card, because this is much faster than transferring files via CAN or RS-232 .

See also: Accessing files via HTTP Server (external link)

Program Upload

Transfer via CAN / CANopen or RS-232

• Enter the terminal's system menu (this is usually achieved by pressing the 2nd and 3rd function key simultaneously)
• Navigate to the menu item "Transfer via CAN = xx", press enter (or the rotary knob)
• Switch from "Transfer via CAN = OFF" to "Transfer via CAN = ON" (with the cursor keys or rotary knob)
• Press enter again to finish editing, and leave the system menu.

Transfer ...

Send Application to Terminal .

After a 'fresh' install, you may have to define how the programming tool shall establish the connection. To do this, select the following item in the main menu:

Transfer ..

Connection Parameters ....  Medium ....  CAN   or   Serial Port ("COM")   or   UDP/IP (Ethernet) .

If the programming tool cannot establish a communication, check the interface cables, termination resistors, communication parameters (baudrate etc) and try again. If still no success, check the programming tool's error page.

If you never sent a program to the terminal before, there can also be a problem with the installation of the CAN interface. Check our notes about the installation of a CAN interface, and carefully(!) read the documentation supplied with your CAN-interface.

To upload the application via CAN into terminals without CANopen protocol (like "MKT-View"), read this document too.

During the transfer, the programming tool shows its own software version (as 'recommended firmware' for the target), and the firmware version read from the remote device. Ideally, but are equal:

Certain terminals like "MKT-View" can be loaded via asynchronous serial interface ("COM1" or "COM2"), or via memory card. See Feature Matrix. All terminals which have the load-via-card feature, have a unique way to update the display program automatically as described in a later chapter (-> "Autoload").

To transfer the application via serial port you will need to know the baudrate which is currently configured in the target device.
Note: There is no universal 'default value' for the serial port speed, because some devices only support rather low speeds (especially those with 8- and 16-bit CPU);
furthermore the port's communication parameters could have been modified via command in the display application itself.
The currently used baudrate is displayed on the device's screen after entering 'transfer mode via RS-232', for example:

Transfer mode active
 Receiving PROGRAM
 RS232/3964R: 19200 bit/sec

To develop advanced applications (including scripts), the development cycle (modify-upload-test) can be speeded up by transferring the application into the target's RAM instead of the target's Flash memory. Details about script development, and how to test applications in the target's RAM (i.e. "send to terminal without flashing"), are in the document about the Script Language. Transfer 'without flashing' can save about 10 to 60 seconds, depending on the Flash chips used in the target hardware.

Last not least, certain terminals (MKT-View II / III / IV) also support a general file transfer method which uses the YModem protocol. For example, you can load all kind of files (if they are small enough) into the terminal's internal FLASH memory, or copy files to the memory card via serial interface, CAN bus, or Ethernet / UDP/IP .

If there's a problem during (or shortly after) program transfer in the remote device, the programming tool may display them in a message box like this:

Message box displayed when finishing a program transfer
with error text originating from the device firmware
(here: the line with "Couldn't save user settings")

• Couldn't save var-defs
  The application's variable definitions couldn't be stored in the target system (at least not completely).
  This may be caused by insufficient memory in the target, or a hardware problem (Flash memory).
  
• Couldn't save global event-defs
  Global event definitions couldn't be stored.
  Possible reasons: Similar as for other "Couldn't save .."-errors .
  
• Couldn't save the page-array
  At least some of the user-defined display pages count't be stored in the target.
  Possible reasons: Similar as above ...
  
• Couldn't save general settings
  The general settings count't be stored in the target,
  or are not compatible with / supported by the target system.
  
• Couldn't save user settings
  The User Settings (settings also editable in the device) could not be stored permanently.
  Since (in contrast to other parts of the configuration) these are usually not stored in Flash memory, but in an bytewise programmable EEPROM, the reason for this error may be a defective EEPROM chip. Please check the device's local 'Error History' (accessable via system menu). If there's an "EEPROM verify error at adr..", it's most likely a hardware problem that you cannot fix with a firmware update.
  
• Couldn't save an icon in Flash
  At least one of the user-defined bitmap graphics couldn't be stored in the target's Flash memory. Since a part of the Flash memory is managed like a 'disk volume' (with flexible size), it may be possible to cure this problem as follows:
  In the device's system menu, select 'Diagnostic' / 'Erase Flash (data)',
  and then try again to load your application.
  If nothing helps and you're in a hurry, ignore this problem - the application will run anyway, and missing icons will be omitted on the screen.
  
• Couldn't save Flash-shadow-RAM
  This problem can only occurr on devices with 'large RAM but small (insufficient) Flash memory' for your application, or if there's a hardware fault. Similar as explained above, check the entries in the device's error history.
  
• Couldn't save PDO channel defs
  CANopen-specific problem, related with Process Data Objects.
  
• Couldn't save SDO channel defs
  CANopen-specific problem, related with Service Data Objects.
  
• Couldn't save CANopen-config
  CANopen-specific problem, for other reasons (neither PDO nor SDO).
  

Transfer via Ethernet ( UDP )

NETWORK SETUP (7) NAV MAC: 00-50-C2-8E-70-03 Name : MKTVIEW3 DHCP : disabled (static IP below) IPaddr: 192.168.000.242 Local TCP Server Ports HTTP:80 TN:23 FTP:21 VNC:5900   CAN via UDP : SERVER Remote IP:192.168.000.242 Ports: R=55556 L=55556

( Entering the remote address and port number in the programming tool.
IP address and port number taken from the remote device's network setup,
see screenshot on the right. Note: CAN-via-UDP set to SERVER . )

→

Main system menu (9) EXIT ! Load program from FILE Transfer via CAN = OFF/Auto Other transfers ... ▶ Audio Recorder CAN snooper mode CAN logger config User Settings System Setup / Unlock System Test Network Setup Diagnostics General Settings ...

→

NETWORK SETUP (7) NAV MAC: 00-50-C2-8E-70-03 Name : MKTVIEW3 DHCP : enabled (dymanic IP below) IPaddr: 192.168.000.112 Local TCP Server Ports HTTP:80 TN:23 FTP:21 VNC:5900   CAN via UDP : SERVER Remote IP:192.168.000.242 Ports: R=55556 L=55556 F3: Save & Exit [↑] [↓]

( Determining the IP address of an MKT-View when DHCP is in use.
Grayed entries in field 'IPaddr' mean 'leased address, not editable'.
In this case, the fields show the currently leased IP address. )

The UDP port number is actually shared with the CAN-via-UDP server (thus, the item 'CAN via UDP' must be set to SERVER). Many devices made by MKT have this server for the CAN-via-UDP protocol built inside, as crude replacement for a physical CAN interface installed on the PC. (For developers, details about the protocol are in the documentation 'CAN-via-UDP').
But the presence of the CAN-via-UDP server in the firmware doesn't mean it is enabled ! Instead, it may be disabled through the device's Network Setup for security reasons. A typical Network Setup (with the CAN-via-UDP server enabled) looks like this:

NETWORK SETUP (27) NAV MAC: 00-50-C2-8E-70-03 Name : MKTVIEW3 DHCP : disabled (static IP below) IPaddr: 192.168.000.242 Subnet: 255.255.255.000 Gatew.: 192.168.000.254 Local TCP Server Ports HTTP:80 TN:23 FTP:21 VNC:5900   CAN via UDP : SERVER Remote IP:192.168.000.234 Ports: R=55556 L=55556 F3: Save & Exit [↑] [↓]

typical CAN-via-UDP client/server configuration   and   Network Setup in an MKT-View III

When initiating a transfer via Ethernet (UDP/IP), some paranoid 'Internet Security Suite', or the windows firewall, may block the transfer. In some cases, such a security software will inform you that it has blocked the access ("blabla is trying to act as an internet server" which is nonsense, anyways..), or will ask you for permission:

Other Examples :

• "Eine Anwendung, die als Internetserver fungiert, hat sich seit der letzten Ausführung verändert." (after program updates)
• "ctptwin1.exe (or uptwin2.exe) is trying to access the internet / act as a server / etc" .  
• ... (feedback, please)

Kindly allow the programming tool to access the "internet" (in fact, it doesn't access the internet, it only tries to establish a connection through the local network using UDP).

Details about the Network Setup can be found in document #85115, "System Setup" (PDF, for users / operators) .
The protocol (on top of UDP/IP) is described in document #85140, "CAN via UDP" (PDF, for developers) .
How to use transfer other files via Ethernet is described in the 'File Transfer Utility / Transfer via Ethernet' (HTML, part of the help system) .
See also:
    file transfer via web browser (HTTP; external link),
    Discovering MKT devices on Ethernet (using a DHCP server) .

Discovering MKT devices on Ethernet (via DHCP or OpenABK-'Discovery')

This function may be used to 'discover' an MKT-Device in the local network,
 without knowing the IP address of the remote device.

In the next step, this program will try to find an MKT-Device, using the
 OpenABK-'Discovery'- and DHCP protocol.
 Depending on the windows version, you may have to allow this in the firewall.

Click 'OK' to allow this program to act as a DHCP-SERVER
 and as an openABK-CLIENT temporarily.

The built-in DHCP server has been started, and is now waiting for reception 
of a 'DHCP-Discover' packet from a display made by MKT Systemtechnik.

THE MKT DEVICE MUST NOW BE RE-STARTED FOR THIS PURPOSE.

Please make sure the devices is configured for DHCP, and connect it 
to the PC via Ethernet cable. Then turn on the device.
Shortly after turning the device on, the Ethernet activity LED should
light up, the reception of a 'DHCP-Discover'-Packet should be detected here.

Click on 'CANCEL', if you want to abort the connection set-up.

Rx:DHCP-Request cip=192.168.0.106 mac=00:21:00:DD:19:A1   (etc)

A DHCP server has received a 'DHCP-Discover'-Paket from an MKT device,
and assigned IP-address

     192.168.0.101

to that device.

Click 'Connect' to establish a connection to that device via web browser,
   or 'OK' to select this device as the current target system,
   or 'CANCEL', if you want to abort the connection set-up.

At the last step, click 'Connect' to establish a connection between PC and the programmable device via web browser.
You can now use your web browser to upload display applications (*.upt or *.cvt) into the device, transfer other files, update the device firmware, remotely control it, get a screenshot of the current display (via copy-and-paste), dump the values of all display variables, examine the trace history, etc. Example:

More details about the device's integrated web server are here (external link).

Alternatively (without a web browser), the UPT programming tool can use the new detected IP address to upload the application (or other files) as explained in the previous chapter, using UDP (not TCP/IP).
To do this, don't click on Connect in step 3 but on 'OK'. This will copy the new IP address into the programming tool's configuration. The (UDP-)port number will be set back to the default value (55556).
After this, if the target's CAN-via-UDP server is enabled, you can transfer your display application quickly into the target by selecting Transfer ... Send applikation to terminal.

OpenABK 'Discovery' Protocol

(Screenshort with devices discovered after 'Transfer'..'Discover MKT- and OpenABK devices in the local network'.
Various devices have been found in the local network,
amongst them an MKT-View (4) with host name "MKTVIEW4WB"
and an Open-ABK-'Test'-Server reporting a wrong IP address in the response )

Automatic display program update via FLASH memory card

• "autoload.cvt" for all terminals without CANopen (parametrized through CANdb, like the original MKT-View)
• "autoload.upt" for all terminals with CANopen-support (like the "UPT2"-family of devices)

Firmware Update

Notes:

• The firmware in MKT's UPT515 can only be updated via CAN-Bus, because this device has no serial port. You need a special program (written by MKT) in this case. For more info, see fwupdate.htm.
• Never interrupt a firmware update, if it's already in progress ! During transfer, do not start any other programs to minimize the risk of a PC crash. If such an accident happens, or someone rips the cables off, you must activate the terminal's bootloader manually be pressing the 1st and 3rd function key while turning the terminal's power on, and repeat the firmware update.
• (Not translated into english yet ... use your imagination ... )
  Für Geräte mit ARM-CPU (z.B. MKT-View II, seit 11/2008) wird zur Ablage der Firmware nicht mehr das HEX-Format ("Intel Hex") verwendet, sondern ein platzsparenderes, segmentiertes Binärformat mit der Dateinamenserweiterung "BI2" . Achten Sie darauf, dass Sie beim Laden der Firmware für diese Geräte in der Dateiauswahlbox den Dateityp von "HEX Files" auf "SEGMENTED Binary Files (*.BI2)" ändern, andernfalls werden Sie die passende Datei nicht finden.
• For newer devices with Cortex CPU, 'sufficiently large RAM, and an integrated web server the firmware can be uploaded into the device's RAMDISK via HTTP .
  Details are in the desciption of the embedded HTTP server .

Screen Snapshot via CAN

The PC's CAN interface

• PCAN-Dongle by PEAK
  The PCAN dongle is a simple interface for the parallel port. Since August 2001, using one of Peak's CAN software drivers is recommended, preferrably the "PCAN Driver V2".
  
• NTCAN by ESD
  The NTCAN API supports several CAN interfaces, like interfaces for the parallel port, ISA- and PCI-slot.
  
• KVASER CANLIB
  A universal and very robust driver Kvaser AB, supporting all (?) of Kvaser's recent CAN bus interfaces for the PC.
  Since 2019, the programming tools by MKT also support CAN FD with suitable interfaces by Kvaser. In the programming tool, the 'fast' bitrate for CAN FD must be configured in the CAN Bus Parameters dialog to match the current device settings.
  
• VECTOR XL Driver
  Last tested with 'CANcase / VN1610' on a Windows 7 PC, where the relation between 'Channel' and physical interface required a bit of trial-and-error (until arriving at the correct 'Channel Name').
  See hints about the Vector CAN Hardware here.
  

Configuration of the CAN interface for program transfer

Note

If the 'Programming Tool Settings' (concerning program transfer via CAN) are not sufficiently compatible with the settings for the to-be-programmed device's first CAN interface ("CAN1"), the programming tool will mark those dialog elements with a red background.
But the programming tool will never try to 'automatically' correct any CAN-related setting !
In the screenshot below, there's a conflict because the PC's CAN interface was currently configured for 'classic CAN' not CAN FD, while the to-be-programmed device (MKT-View V with CAN FD) was configured for a "fast data phase" ("FD") with 4000 kBit/second.

USB-to-Serial Port interfaces (Virtual COM Ports)

If Windows fails to recognize the USB device, try to find the right VCP driver for your operating system on the FTDI website, and install it yourself. Please respect the fact that we (MKT Systemtechnik) were unable to test the FTDI VCP drivers on all of the fourteen different windows versions which supported the FTDI chip (FT232R) in January 2010.

If you run into trouble with the USB drivers, it may help to plug the device into a different USB connector (your PC will definitely have more than one). Sometimes windows seems to lose track of the USB drivers installed on the system, and refuses to recognize the device with a message like this:

(Did you really expect to fix an USB driver bug by clicking on this message ... ?)

Important note on USB, which has always been a nuisance for developers:

Always connect the programmable terminal to the same USB plug on your PC.
Otherwise, Windows will always select a NEW COM PORT NUMBER which is very, very annoying.
If, for example, Windows decided to use "COM10" yesterday, but "COM11" for the same device today, you will find something like the following in the combo list of serial ports:



Furthermore, connect the terminal's "USB port" (which is in fact a virtual COM port) to the PC before starting the programming tool.

If the connection between the PC (programming tool) and the programmable device (terminal) uses USB and a Virtual COM Port, the 'serial' baudrate can be set to unusually high values (like 230400 or 460800 bit/second) on the 'programming tool settings' tab. In 2010, most new devices with ARM-CPU and USB/VCP had an automatic baudrate detector function built inside the firmware, so in those cases, the file transfer utility can use this higher baudrate even though the default baudrate (in the terminal) is only 19200 bit/second, or the display application has switched to a different baudrate via interpreter command .

See also:

• Program Upload
• File Transfer Utility

The UPT's internal System Menu

Details about the system menu are in the printable PDF, see the link to document #85115 at the end of this chapter.

In many devices, the system menu can also be operated via remote control, for example through the RS-232 interface and a terminal program, or through the Ethernet port using TCP/IP and TELNET. In those cases, send CTRL-S (STRG-S) from the remote terminal as a replacement for simultaneously pressing F2+F3.
Here is one example of a system menu (snapshot taken from old UPT515 firmware, it may look totally different on your hardware but the basic principle is the same):

The basic operation of this system menu (and sub-menus) is as follows:

• press the special key-combination to enter the system menu (if not disabled by the general options, otherwise use the trick described here )
• use the Cursor UP / DOWN keys to scroll the black selection bar to the desired menu item
• press ENTER to edit the value of a menu item or to "jump" into that menu
• press ESCAPE to return from a menu
• use the menu item "Save & Exit" after modifying values that shall be saved permanently (like, for example, the contrast value for the LC-display)

Where applicable, you will find menu items to initiate a program upload manually (in the Mobile CAN Terminal, where the SDO server must be activated expecially for program upload).

Display-, Audio-, CAN-Bus-, and other items in the System Setup

• Display setup, hardware dependent, possibly with LCD-contrast adjustment, backlight control,
  clockwise or counterclockwise rotation for 'Portrait' mode (depending on how the device is mounted), touchscreen gesture options, etc;
• Audio setup, also hardware dependent, with settings like touchscreen click volume, microphone gain (where applicable), speaker output volume, etc;
• Date and Time setting, if a battery-buffered real time clock is supported;
• CAN setup: Important for the communication between UPT and programming tool.
• Module/Node-ID (very important for the communication between UPT and programming tool)
• Network Setup : see next chapter .
• other hardware dependent features like CAN-Transmit-Enable etc
• Enter an unlock code to activate certain, 'special' features
• Diagnostic functions like bootloader invocation, recall default settings, error- and trace history display, manual 'browsing' of display pages, memory usage ("Storage Directory"), etc.

Note: CAN-Baudrate and Node-ID must be equal in the UPT's Setup menu and in the programming tool. Otherwise you cannot upload UPT files from the programming tool into the UPT (see chapter general settings ).
Caution: The terminal application may have to run with a CAN baudrate which is *not* supported by the PC's CAN interface (10 kBit/sec for example). For that reason there is an extra definition for the CAN-baudrate for the application in the programming tool on panel "Terminal Settings". These two different places to set the CAN baudrate caused some confusion in the past - more on that in the chapter about the tool's Terminal Settings panel (remember this when the programming tool cannot communicate with the terminal, because you changed the CAN baudrate somewhere !).

On certain terminals, there is a menu item called User Settings where you can..

• Show and modify the "operational" baudrates for two CAN interfaces. These CAN baudrates are part of the application, not part of the terminal's system settings. The "User Settings" take effect when the terminal loads and initializes the application. If there is no application loaded, the terminal uses the CAN baudrate from its "system" menu. If the CAN-baudrate in the terminal is different from the CAN-baudrate used by the programming tool, you may get into trouble... see 'Download troubleshooting' in that case !
• If you need a CAN-baudrate which you do NOT find in the list of supported baudrates, you can -alternatively- define the value written into the CAN controller's BTR (bit timing register) directly in hexadecimal form. Caution: this option only exists in a few terminals (like MKT-View "Plus"), and we highly recommend NOT to use this feature because you will have to calculate the BTR-value yourself. More info on that subject can be found in this extra document (only available in english language).
• Edit the values of the non-volatile numeric array (located in EEPROM, can be accessed through the UPT interpreter)

In devices with a sufficiently large code memory, the following 'diagnostic' functions can be invoked through the system menu / submenu "Diagnostics":

• Inquire version info, compilation date, and status of unlockable features
• Invoke the bootloader (for a firmware update)
• Restore the "BIOS" default settings (baudrates, node identifiers, etc)
• Show the error- and/or trace- history (for devices with script support)
• Browse the programmable display pages:
  After switching to a different page (here: via cursor keys or rotary button), the current page number and -name as briefly displayed. Press Escape or F3 to return to the 'Diagnostic' menu.
• List all display variables (including their current values)
• List all objects currently stored in Flash memory ("Storage Directory")
• Erase all Flash memory ranges with data and application ("declassify" before shipping)
• Show extended CAN / CAN FD bit timing parameters

Devices with built-in CAN logger (e.g. "MKT-View") also have a built-in CAN bus monitor (CAN Snooper), which can also be invoked through the system menu.

Some of the functions in the system menu can also be invoked directly from the user application with an interpreter command , for example to adjust the display contrast or set the battery-buffered clock (if present).

If the device has neither a keyboard, nor a rotary encoder knob, nor a touchscreen, the system menu must be invoked via Remote Control (requires a special terminal program).

Since 2011-07-12, a few (display-related) setting in the system menu can optionally be overwritten when downloading a configuration (*.cvt or *.upt). See optional display setup for details.

More information about the terminal's "System Menu" can be found in this printable document (PDF #85115) .

Alternatively, devices with Ethernet (and TCP/IP) connection can be configured via web interface (HTTP) .

Network Setup (in the system menu, only for devices with Ethernet / TCP/IP)

(1) The device's Ethernet MAC address .

(2) The device's name (hostname) in the local network .

You can access the device by entering this name in your web browser, which may be easier than entering the IP address - especially in combination with DHCP.
The default name is "upt" (short for User Programmable Terminal), but you may want to modify the name. You must change the name if you have multiple "upt"s or MKT-Views in your local network.

(3) Configuration of DHCP (static or dynamic IP address)

If a dynamic IP shall be used, there must be a DHCP server somewhere in the network, and the following fields (4..6) are meaningless.
A fixed IP may be easier to use, especially when communicating with other embedded devices which don't support DHCP.

(4) The device's own (local) IP address .

This is the static IP, which is saved in a configuration EEPROM. Only has an effect if DHCP is disabled (see item 3).

(5) Subnet mask

Like the static IP (4), this parameter only has an effect DHCP is disabled.

(6) Default Gateway Address

Like the static IP (4), this parameter only has an effect DHCP is disabled.

(7) Local TCP Server ports:

HTTP: Integrated HTTP server aka "web server" (default port: 80), Telnet (default port: 23), and FTP (not functionable yet, default: 21)

(8) CAN-via-UDP mode : Possible settings are "off", "Client", or "Server".

Note that unlike some PC software, the terminal can be either client or server, but not both at the same time.

(9) CAN-via-UDP parameters :

IP address of a remote CAN-via-UDP server (used if the device acts as a client),
and local port number if the device acts as a CAN-via-UDP server itself.

Note: If you are not familiar with the basics of TCP/IP, follow the external links (which mostly lead to Wikipedia). Furthermore, read a good textbook on network basics !

Pressing the enter key (or, if no such key exists, the rotary encoder button) to switch between 'Navigate' (i.e. move the selection) and 'Edit' (i.e. modify the selected parameter). A short note about the currently selected parameter is visible in the bottom line.

Details about the network setup can be found in document #85115 ("System Menu and Setup").

Alternatively, the network setup can be modified via web interface as described here .

See also:  Suppressing popup messages when launching certain services (e.g. DHCP, CAN-via-UDP, WLAN)
       Wireless LAN Setup (for devices with WLAN/'Wi-Fi' instead of Ethernet, e.g. MKT-View V)

Power-on/off behaviour of the device, e.g. Wake-up via CAN

• In the 'Main system menu', select 'System Setup / UNLOCK'
• In the 'Setup Menu', scroll down to the item 'WakeupSource'.
• Press ENTER (or the rotary encoder knob) to switch from 'Navigate' to 'Edit'
• Using the up/down key (or rotary encoder), select one of the items explained further below.

 Setup Menu (12)
 EXIT !
 Save & EXIT !
 Display setup    .. ▶     
 Audio setup      .. ▶
 Date and Time    .. ▶
 CAN-Baudrate =500
 Module/NodeID=000
 CAN1_TxEnable=1
 CAN2_TxEnable=1
 CAN1_120_Ohm=1
 CAN2_120_Ohm=1
 WakeupSource=Key, Vin     
 GPS Rcv Type=NONE / off
 ...

(Configuring the device's 'wake-up' behaviour)

Key (only)

The device (MKT-View) can only be turned on via (power-) key.
If will not automatically turn itself on when the supply voltage ("Vin") returns.

Key, Vin

The device (MKT-View) can be turned on via key (after manually being turned off), and it will automatically start when there is a low-to-high transision at "Vin" (supply voltage).

Key, Vin, CAN

Similar as above. In addition, the device will automatically start when there is activity on the first physical CAN bus interface.

Key, DIN, CAN

Similar as above. In addition, the device can be started via onboard 'digital input' (DIN). Please consult the hardware manual for details and specifications.

Key, Vin, DIN, CAN

Combination of all the above (power-on via key, rising supply voltage, digital input, CAN-bus-activity).

Key, CAN

Power-on only via key or CAN-bus activity. Rising edges on VIN or DIN are ignored.

Vin, CAN / Vin, DigIN / Vin (only) / CAN (only)

Rarely used combinations that don't allow the human operator to turn the device on by himself. These were requested by a 'good customer' many years ago, and are possibly not available on newer devices anymore.

Unlocking 'special' features

Remote Control (for the programmable terminal's system menu)

Storage Directory (in the 'System Menu' under 'Diagnostics')

Switched from page 0 to page 2 ("Engine"), reason: GOTO on page 0, line 9

Global text search for 'ISO15765_ADDR_FORMAT_FIXED_NORMAL' :
  Script sourcecode, line 133  : ISO15765_ADDR_FORMAT_FIXED_NORMAL = 2;
  Script sourcecode, line 617  : iAddrFormat := ISO15765_ADDR_FORMAT_FIXED_NORMAL;
Found 2 occurrences of 'ISO15765_ADDR_FORMAT_FIXED_NORMAL'.