Using the virtual terminal for universal remote access: Difference between revisions
(Created page with "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”...") |
No edit summary |
||
| Line 1: | Line 1: | ||
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. | 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. | 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 | |||
Revision as of 18:38, 10 April 2014
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