Features of the programmable Terminals with "CANopen V4"

(Only for certain terminals with CANopen DS301 V4.0, not for UPT515)

When compared to "older" terminals (like UPT515), "newer" terminals with CANopen-Protokoll "V4" have some differences concerning communication and programming. This document will point out some of these differences, and demonstrate how to use the new features. The feature matrix shows if CANopen V4 is available for your terminal hardware.

Contents

1. Differences between terminals with CANopen "V3" and CANopen "V4"
2. Connecting 'Display-Interpreter-Variables' to CANopen objects in the terminal's own ('local') object dictionary (OD)
3. Connecting 'Display-Interpreter-Variables' to CANopen objects in a remote OD (per SDO)
4. How to display CANopen objects without using interpreter-variables
5. Communication Profile
6. PDO Communication Parameters
7. PDO Mapping Parameters
8. EDS-Files

Links to other documents about programmable terminals with CANopen :

• Objects in the terminal's CANopen-Dictionary
• Defining SDO Channels with the programming tool
• Interpreter Functions to communicate with remote devices via SDO-Client
• Defining PDO Channels
• PDO-Mapping with the Terminal Programming Tool
• CANopen configuration (in the programming tool)
• Interaction between the CANopen protokoll stack and the optional script language
• EDS/DCF generator (generates a DCF, or a 'patched' EDS file, for external PLC development tools)
• EDS-Dateien auf der 'MKT-CD' (externer Link zur MKT-Website)

Differences between terminals with CANopen "V3" und CANopen "V4"

There are some functional differences between terminals with CANopen V4 and "older" terminals:

• Number of process data objects (PDOs): Terminals with "CANopen V4" have 3 RPDOs plus 3 TPDOs. In contrast to the older UPT's, the transmission direction (RX or TX) is always fixed for a certain PDO channel now, due to the strict and uncompromising implementation of CANopen V4.
• Modified PDO-Mapping: In terminals with "CANopen V4", only object which exist in the CANopen object dictionary can be mapped to a PDO, if they have the attribute "PDO-mappable". This means, only process-variables and a few other objects (like the keyboard matrix, the current display page number, and a few optional LEDs on the front panel) can be mapped into a PDO now. For these reasons, it is no longer possible to map interpreter-variables "directly" into a PDO. Instead, an interpreter variable which must be connected to one of the "process variables" to transfer the value via PDO.
• Strict checking of the data types when writing an object via SDO: For example, a 16-bit write access to an object with 32-bit data type is impossible now.
• New object dictionary: Some objects from the terminal's CANopen object dictionary (OD) were discarded when migrating to CANopen V4, a few others have been added.
• Node-Guarding should be replaced by Heartbeat protocol if possible. At the moment, the terminal supports both (not tested yet !)
• The protocol to transfer the UPT application between programming tool and programmable terminal had to be modified, rendering "new" and "old" programming tool incompatible. To program and "old" UPT515 you must use the "old" programming tool (UPT-Programming Tool 1); for the "newer" terminals with CANopen V4 (UPT-Handheld, UPT-Mobil aka "MKT-View with CANopen", ..) only the "newer" programming tool (UPT-Programming Tool 2) must be used.
• The Feature-Matrix shows which of MKT's programmable terminals use CANopen V4 .

Connecting 'display variables' to CANopen objects in the terminal's own object dictionary

On the tool's 'Variables' tab, you will find a column titled 'OD-Index', where the desired CANopen object index and -subindex can be entered. The object index must match one of the existing objects.
For example, the terminals's own object dictionary contains 10 (or 40) freely usable objects with data type '32-bit integer', at object index Objekt 0x4004, with subindices ranging from 1 to 10 (or, for devices with the so-called 'Monster-OD', 1 to 40 because there are fourty objects for each type) zu verbinden.

More details about connecting an interpreter variable (aka 'display variable') with objects 0x4001 to 0x4009 in the terminal's own, local OD can be found here .

See also: CANopen-OD inside the terminal (aka 'local OD'); Display interpreter variables (managed by MKT's programming tool) .

Hint about the 'CANopen process variables' in the terminal's own OD (indices 0x4001 to 0x4009) :

The installation archive contains a sample application named 'Obd_Test.upt'. This application can be used to examine the contents of these 'CANopen variables' (objects) when accessing them from the outside world (via SDO); furthermore it demonstrates how to connect 'normal' display interpreter variables with these CANopen objects internally.

Connecting 'display variables' to CANopen objects in a remote OD (via SDO client)

See 'Variables connected via SDO channels' in the common documentation of the programming tool.
(this works for devices with CANopen V3 as well as for devices with CANopen V4, thus no extra chapter in this document)

How to display CANopen-Variables without using interpreter-variables

Terminals with CANopen V4 have a set of variables in their CANopen OD, which are accessable via CAN (SDO or PDO), but also through the terminal's built-in interpreter. Use the function "obd(<index.subindex>)" to access any object in the terminal's local OD. You may, for example, enter the following expression in the "Var/Formula" column of the display definition table to show the first 32-bit-integer variable on the display, without the need to connect it to an interpreter variable :

obd(0x4004.01)

This expression works (almost) like a normal variable, so you may even edit the value on the terminal's display (if it's read- and writeable). Other devices in the network can access it via SDO, just like any other object in the OD, and also via PDO because object 4004_(hex) is PDO-mappable.

Instead of typing the "obd"-statement yourself, you can let the programming tool generate it for you. You can select the object which you want to display from a list, which may be easier. Double-click into the "Var/Expr"-column of the display page definition table to open the VARIABLE-Replacement-Dialog (which was once used only to connect display lines and "normal" interpreter variables). This dialog will open:

Select any CANopen object which shall be displayed in the CANopen OD list (on the right side). A click with the left mouse button into the list copies the selected entry into the display line definitions (left side), possibly replacing the old definition. More info about the VARIABLE selection dialog can be found here .

Communication Profile

Terminals with CANopen V4 have some new objects in the CANopen Communication Profile (as specified by CiA DS301, object index range 0x1000 – 0x1BFF). These objects can be used to identify the terminal in a CANopen network. These Identification-objects are constants (read-only) :

CANopen-Index	Contents
0x1000	Device Type (not applicable, only DS301 at the moment)
0x1018	Identity Object
0x1018.1	MKT’s vendor ID (0x004D4B54)
0x1018.2	Product Code (70055=UPT515, etc)
0x1018.3	Revision Number (ex: 0x00010002 = V01.02)
0x1018.4	Serial Number (expect this to be ZERO)

PDO Communication Parameter

<ToDo>

PDO Mapping Parameter

<ToDo>

See also: Dialog window for PDO mapping

EDS-Files

You will need an EDS file to modify the terminal's communication parameters with a third party's CANopen configuration tool. The following file have already been unpacked when the terminal programming tool was installed :

• "universal" EDS file for all terminals with CANopen "V4", with 10 variables for each CANopen data type (standard OD)
  
• "universal" EDS file for all terminals with CANopen "V4", with 40 variables for each CANopen data type (codename "Monster OD")
  
• "Readme" about the EDS folder
  
• More EDS files on the 'MKT-CD' (link to the MKT website; requires an internet connection)

Note: Depending on the hardware setup of a particular device, some of the objects in these files may have no function, but they alway exist in the OD ! If, for example, there is an object named "Front Panel Lamps" (0x5201) though your terminal has no such lamps (LEDs) at all, you can forget this object...

: .

See also:

CANopen object dictionary ("OD");
Generator for EDS (electronic datasheet) and DCF (device configuration files).