(only available for certain
terminals ! )
(only available for certain
terminals ! )
Contents
Most terminals with RS-232 interface had a simple XMODEM (1k) / YMODEM server built inside.
Thus standard software like Microsoft HyperTerminal (tm) can be used to load
certain files from the PC into the terminal, without the need to use MKT's
programming tool at all. However, using the programming tool's
integrated file transfer client may be
easier for you. The steps below are only required if you want to upload something
into the terminal without MKT's programming tool.
File transfer without MKT's programming tool
We cannot go into details here (yet), but the following principle can be
used to upload the display application (and possibly a few other file
types):
Enter the display terminal's system menu (if necessary, via remote control) .
Select the item "Other Transfers".."XMODEM / YMODEM via RS-232" (for example).
Look at the terminal's display, it will show the communication port and the current baudrate.
On a windows PC, click 'Start'..'Programs' ("Alle Programme") .. 'Utilities'
(? - "Zubehör") ..
'Communication' ( ? - "Kommunikation") ... 'HyperTerminal' .
Or, if you know things like PuTTY, you will certainly do better without
HyperTerminal .
Whatever terminal program / YMODEM client you use, configure the port (RS-232 or whatever) as required.
In the terminal program, a long row of 'CCCCCCCCCC' characters will creep
up now.
This is the YMODEM server's way of saying 'I'm open for business, and want
to use CRC (cyclic redundancy check).
If you can see a few 'C's, start sending the file using the YMODEM
protocol.
With Hyperterminal on a German PC : "Übertragung".."Datei
senden".."Protokoll: Ymodem" .. "Durchsuchen"..."Senden" .
Wait until the file transfer is complete
Send the next file if necessary, otherwise the XMODEM / YMODEM server will time out and switch back into remote control mode, or command line mode.
Reboot the display terminal when finished, or wait for 30 seconds without sending anything (the terminal will quit transfer mode automatically then).
Special file types (recognized by the programmable terminals)
A few special file types (three-character file extensions) are recognized
by the terminal's built-in XMODEM / YMODEM handler.
These are ("including but not limited to") :
See also: Pseudo-directories in the programmable terminals .
XModem and YModem were designed to work over a serial connection (RS-232),
typically a using a telephone modem.
In some of MKT's programmable display terminals, the same protocol can be
'tunnelled' through other transport protocols, or other transport media.
In 2010-03-11 (when this section was written) the details were not completely
known, and some adaptions were still 'under development'.
If you seriously consider to use this protocol in your own programs, ask
the software development engineer (Wolfgang Büscher) at MKT for up-to-date
details.
To retrieve a directory listing from the remote device, it was necessary to add a few proprietary extensions to XMODEM / YMODEM. These extensions MAY render the protocol incompatible with 'pure' YModem clients ! Instead of XMODEM blocks (with 128 or 1024 bytes netto size), these extensions use plain ASCII strings terminated with carriage return (chr #13) and new line (chr #10). Here is an incomplete list of commands which can be sent from the file transfer client to the file server:
The response will be a single text line (ending with CR+NL, like the command); or (for the directory listing) a sequence of lines each terminated with CR+NL. The end of the directory listing (and similar future commands) is indicated by the string "Ready." + CR + NL. If CANopen is used as the transfer medium (see below), repeatedly poll object 0x5112 through an SDO read request until you reached the end of the list.
To Be Specified ..
In devices without CANopen, the same pair of CAN identifiers (one for RX, one for TX) normally used to load the display application into the terminal can also be used for the XMODEM file transfer. However the XMODEM file server in the terminal must be 'informed' that the CAN bus shall be used as the XMODEM transport medium, which requires an additional 'tickler sequence' of CAN messages. This avoids unintentional activation of the file server. Details are not specified yet.
In devices with CANopen, it's illegal to "reserve" special CAN identifiers.
For that reason, the XMODEM (or YMODEM) file transfer uses a special object
(index 0x5112) which is embedded in the device's CANopen object dictionary.
Basically, the X/YModem blocks or other commands can be sent to the file
server by writing them into this object (in blocks of 1024 bytes plus some
overhead), or read from the file server by periodically polling this object
(via SDO read request). In CANopen geek speak, this is a 'Segmented Domain
Transfer' via SDO, thus object 0x5112 has the data type 0x0F = "Domain".
In certain states, where the XMODEM file sender would expect to receive an
acknowledge character over the serial port, a successful SDO-read-access
replaces this acknowledge (this eleminates the need to write the
ACK character into object 0x5112 after each 128- or 1024-block read
from object 0x5112). If you need to know more details about how to upload
or download files via CANopen object 0x5112, get in touch with the software
developer (ask for Wolfgang Buescher).
Note: Object 0x5112 is not
PDO-mappable . It can only
be accessed via SDO .