Using the virtual terminal for universal remote access

From CANopen-Lift
Jump to navigation Jump to search

In a complete lift control system, there are many different intelligent devices today. Of course, first there is the main controller, which could be considered the “brain” of the system, but there are also the VVF inverter (for an electrical lift) or the hydraulic drive for a hydraulic lift, the door operator, the load measuring unit, the car and floor panels, and so on.

All these interconnected devices are now complex electronic devices, and to best fit the targeted lift, most of the time a local HMI (human-machine interface) is integrated to adjust the parameters and give a better diagnosis when needed. Some of these devices also propose an optional remote tool, but very often with a specific protocol upon a specific wire, which offers a friendlier HMI. Now think of the lift technicians during installation or maintenance, as they have to master all of the tools of all the devices. Just think of your living-room table with the set of four or five remote controls – and sometimes more for your home audio-video devices (TV, DVD-player, recorder, audio amplifier, satellite decoder) – and you won't be far from the problem of our technician. But even if the technicians are quite at ease with many different tools, the physical access to the devices becomes also more difficult. Nowadays, with the increase of machine roomless lifts, the frequency inverter and sometimes the main controller – the most consulted devices – are very often located in the lift shaft.

There are two issues to solve: the universality of the tool and the remote access with this tool. And for years, a solution has been offered by the CiA 417 CANopen application profile for lift control systems.

Background

Members of the CANopen SIG (Special Interest Group) Lift have developed the CiA-417 application profile. These members are different designers and manufacturers of lift equipment located in different European countries. This profile, whose main objective is to ensure interconnectivity of lift devices, describes how data is exchanged over a CAN network based on the CANopen application layer (internationally specified in EN 50325-4, also known as CiA 301).

In the communication profile area of the CANopen object dictionary, the CiA-301 defines the “OS prompt” object (Index = 1026h) in order to permit remote configuration and remote debugging of a can node. This is done by the use of well-known input and output streams: the stdin and stdout. Sub-index 01h of object 1026h is the stdin, and sub-index 02h is the stdout, each of one byte. These entries are intended to send a keyboard character to a node (the stdin) and receive a text character from this node (the stdout).

Inspired by this object, the CiA-417 profile introduces the Virtual Terminal Interface object (at index 600Ah) with the two same sub-indexes but with a size of 4 byte to improve the stream transfer rate. With the "front-end" contents of the standard input/output streams (keyboard/screen), this is the best way to achieve compatibility with any HMI, and therefore to have a unique tool, which is able to connect to every device of a lift system, while the remote access is inherently given by the connection upon the CAN network.

Implementation

Both nodes, the remote tool and the lift device consulted, shall implement the virtual terminal interface object, with opposite accesses (the remote tool sends the stdin, and receives the stdout, while the lift device receives the stdin and sends the stdout). But what is the best service to transmit this data? It clearly looks like the connection between both nodes should be in a peer-to-peer manner with client/server relationship: the remote tool is the virtual terminal client, which wants to virtualize the HMI of the lift device, which is then the virtual terminal server.

First we naturally think of SDOs, as SDOs are designed for a peer-to-peer connection in a client/server relationship and the range of CAN-IDs for SDOs have lower priority than PDOs so the transfer of HMI data won’t disturb more important data. But for every SDO client request, there is a response of the SDO server. It could slow down the transfer rate and cause bad behavior of the remote tool because of a delay (remember how unpleasant it is to press a key and see the screen react one or two seconds after). SDOs should be used, as the problem of the delay will only be relevant when using big HMI with a lot of characters to be transferred, but there is the need to find a more efficient transmission service.

Then we naturally think of PDOs, which are designed to process data, (this is the case with stdin/stdout), but the broadcasting of a PDO is a little bit annoying: every virtual terminal server will react to the transmission of the stdin (600A 01h) by the virtual terminal client! Because we need a peer-to-peer connection and because there are up to 127 nodes connected on a CANopen-Lift profile network, that means 127 different PDOs have to be defined only for the remote access of each device. This reduces the range of other PDOs available on the network for other purposes drastically. So normal PDOs are not the best solution either.

There is another service available, not the most well known, but recommended by the CiA 417 for transmission of virtual terminal data: the MPDO service. MPDO stands for Multiplexed Process Data Object. In a nutshell, these objects are hybrids between SDOs and PDOs. There are no PDO mappings for MPDOs as the address of the object (index and sub-index, called the multiplexer) is given in the message like a SDO, but this transfer is without confirmation, like for a PDO. MPDOs allow multicasting and unicasting with up to 4 byte of data within each message. There are two kinds of MPDOs: the DAM-MPDO and SAM-MPDO, meaning “Destination Address Mode” and “Source Address Mode”. The names simply indicate that the multiplexer is a reference object of the transmitter in SAM mode or of the receiver in DAM mode. The SAM-MPDO allows multicasting, while the DAM-MPDO is used for unicasting. Using a DAM-MPDO, the virtual terminal client (the remote tool) sends key-codes to the virtual terminal server, which answers by SAM-MDPO carrying screen characters. The used key-codes and screen characters are from standard ASCII codes according to ISO 88915. The virtual terminal server may also use control sequences (e.g. to clear lines or move the cursor in only one command), defined by the old but efficient VT52 terminal. More details on the contents of the transmission can be found in the CANopen-Lift wiki.