Uploading the application into the terminal via CAN without CANopen

(only available for certain terminals without CANopen)

This document describes how the terminal application can be uploaded into devices with CAN, but without CANopen. This applies to terminals like "MKT-View", and possibly some others.
If does NOT apply to terminals with CANopen protocol, because a CANopen network has all the protocols we need to access the terminal (SDO).

Contents

How to upload via CAN (without CANopen)
Activating the transfer mode in devices without a keyboard (using the device's serial number)
Technical notes

How to upload via CAN (without CANopen)

Because we don't know which CAN-Identifiers will be used in generic CAN networks ("without CANopen"), we cannot reserve certain CAN-Identifiers for this purpose. Instead, the terminal must be switched manually into transfer mode as follows :

First, enter the terminal's "Main" system menu (by pressing the two keys, usually F2+F3), then
select the menu entry "Transfer via CAN = xxx", then press ENTER (or the rotary button)
Use the cursor up/down-keys (or the rotary button) to enable 'transfer via CAN'. The menu must show something like:
Transfer via CAN = ON
Press enter, and scroll back to the top of the system menu (to "EXIT !"), and press enter again to return from the system menu.
If the programmable device doesn't have a key keyboard, use the remote control function, or use the trick described in the following chapter.

The terminal will now listen for CAN-messages on a certain CAN identifier (see tech notes), so the PC can communicate with it.
Now start the program transfer from PC to terminal "via CAN":

In the programming tool's main menu, select "Transfer" ... "Send Application to Terminal via CAN" (deutsch: Transfer ... Applikation per CAN ins Terminal laden).
A dialog box appears which shows the CAN-baudrate and -identifiers which will be used during transfer.

CAUTION: Take the notes in this box seriously. There must be no other CAN-node connected besides the PC and the programmable device. Furthermore, the CAN connection must be reliable so no CAN-frames are lost. Don't try to upload via a 'shaky' CAN connection, for example with missing 120 Ohm terminator, or illegal bus topology !
Click OK in the dialog to continue if the settings are correct. The PC will now try to connect the terminal via CAN. During the upload (or download) process, a progress indicator will be shown (a counter of the lines of program code). If the upload doesn't start, check CAN interface, CAN cables again. If you can't get the CAN driver working with the program, use the RS-232 port or the Flash Memory card instead.

Connecting to a remote device without a keyboard (through its unique serial number)

In 2009, new devices were introduced which neither had a keyboard, nor a rotary control knob ("encoder"), nor a touchscreen. So there was no way to enter the system menu for these devices, thus it was impossible to set Transfer via CAN = ON (see previous chapter) - at least not without the remote control protocol, which was added later.

First solution (kludge) : Such devices could be switched into transfer- or remote control- mode by operating them at a higher 'programming voltage' .

Better solution (available since 2010-05-12) : Such devices can be permanently switched into a third state for the 'Transfer via CAN' parameter in the system menu, which is described below.

The option 'Transfer via CAN' can now be set to

Transfer via CAN = OFF / Auto

in the system menu (if necessary, via remote control, which is possible through other communication ports besides CAN). In this state ...

the terminal will not react to 'normal' CAN messages on CAN identifiers 0x07F0 / 0x07F1
the terminal only passively monitors traffic on these CAN-message IDs
when detecting a certain (!) 256-byte-pattern (including a special pseudo-random noise sequence) in 32 consecutive "special" CAN messages,
the addressed device will enter transfer mode .

This way, it's almost impossible to activate the transfer mode by accident, because the special 256-byte sequence includes the remote device's serial number. So you must enter it in the programming tool's Transfer menu before starting :

First, select Transfer ... Connection Parameters ... Remote Serial Number in the programming tool's main menu, and enter the device's serial number () :

(Screenshot of the dialog for entering the serial number.
Please not that "123" is just an EXAMPLE !
You will hopefully find the serial number on the device's faceplate.... if not :
It is shown on the device's display shortly after power-up, for example SerialNr: 123 )

Next, select Transfer ... Send Application to Terminal in the main menu .

The programming tool will first try to establish a connection the usual way (without sending the serial number in a pseudo-random noise sequence). This will fail after a few seconds, because Transfer via CAN isn't set to ON but OFF in the device's system menu. After a few seconds (if no response is received), the programming tool will switch over from the 'usual' protocol to the one described above using the pseudo random number sequence, and -if the remote device's serial number has been entered correctly- a connection will be established, and finally the upload process begins.

Because the serial number is unique (at least, for the same class of devices), only ONE device will respond by sending a CAN message ^(*). So, in this special case, it wouldn't hurt if more than device are connected to the same physical bus.

(*) Of course, this only works if the option 'Transfer via CAN' is set to 'OFF / Auto' for all devices on the same CAN-bus. If any of them is set to Transfer via CAN = ON , there will be collisions because two devices will try to send a response on the same CAN-ID (0x7F1). This is illegal, and must be avoided under any circumstance !

If you don't want that your terminal can be uploaded via CAN at all, set

Transfer via CAN = Disabled

in the system menu, then select 'System Setup' ... 'Save and Exit' . In this state, the device cannot be connected for program up/download, at least not via CAN .

Technical Notes (communcation terminal <-> PC via CAN, without CANopen)

As noted in the introduction, we cannot simply reserve two CAN-identifiers to communicate between programming tool and terminal in all circumstances (this would lead to collisions sooner or later, or make things complicated).

But in fact, two CAN identifiers are used for this communication, but the terminal (!) only uses them after being switched to "Transfer Mode via CAN". The CAN-identifiers are:

0x7F0 : from PC (programming tool) to the terminal
0x7F1 : from terminal to the PC (programming tool)

The transfer uses a proprietary, text-based protocol which uses commands and keywords. In fact, most of the transmitted lines have the same format as used to save the terminal application in a text file. More information are available on request ("subject to change") .

File: ..?..\uptwin1\help\canup_01.htm
Author: W.Büscher, MKT Systemtechnik
Last modified: 2010-05-12 (ISO8601, YYYY-MM-DD)