Difference between revisions of "New Functions with CANopen-Lift"

From CANopen-Lift
Jump to navigation Jump to search
(Created page with "A lot of electronic assemblies are needed to realize the desired functionality, the ride quality and the current safety requirements called for in modern list systems. These e...")
 
Line 1: Line 1:
 +
[[File:Logo_CANopen-Lift.png|thumb|CANopen-Lift is the base for manufacture independent linking of electronic components]]
 
A lot of electronic assemblies are needed to realize the desired functionality, the ride quality and the current safety requirements called for in modern list systems. These electronic assemblies are networked via modern bus systems and use these systems to exchange status information or commands. In order to achieve this, it is necessary to have all assemblies involved in communication “speak and understand” the same bus protocol. This is only possible when all assemblies use an open, standardized protocol or a proprietary protocol produced by only one manufacturer. An example of an open standardized protocol is the application profile CiA-417 Lift Control “CANopen-Lift” that is based on “CANopen”. In this application profile all parameters and commands of a modern lift system are standardized, e.g. like the parameters of the frequency converter in the drive unit or the door controls and commands such as “Open door A”, “Cab call floor 8” or “Position 23.263 m; Speed 0.8 m/s; Acceleration 0.5 ms2”. In the following paper the most important milestones of the development of CANopen-Lift and the latest functions are presented.
 
A lot of electronic assemblies are needed to realize the desired functionality, the ride quality and the current safety requirements called for in modern list systems. These electronic assemblies are networked via modern bus systems and use these systems to exchange status information or commands. In order to achieve this, it is necessary to have all assemblies involved in communication “speak and understand” the same bus protocol. This is only possible when all assemblies use an open, standardized protocol or a proprietary protocol produced by only one manufacturer. An example of an open standardized protocol is the application profile CiA-417 Lift Control “CANopen-Lift” that is based on “CANopen”. In this application profile all parameters and commands of a modern lift system are standardized, e.g. like the parameters of the frequency converter in the drive unit or the door controls and commands such as “Open door A”, “Cab call floor 8” or “Position 23.263 m; Speed 0.8 m/s; Acceleration 0.5 ms2”. In the following paper the most important milestones of the development of CANopen-Lift and the latest functions are presented.
  
 
== RETROSPECTIVE ==
 
== RETROSPECTIVE ==
[[File:2003_Interlift_CANopen.jpg]]
+
[[File:2003_Interlift_CANopen.jpg|thumb|CANopen-Lift at Interlift 2003]]
 
On the occasion of the Interlift 2001 for the first time 20 small to medium-sized lift component manufacturers agreed to participate in producing an open standard for the communication on the CAN-bus. At the beginning of 2002 these manufacturers agreed to use as a development basis the “CANopen” standard already widely used in automation technology for years and extend it by the functions needed for lifts. Within the CAN-in-Automation (CiA) a Special Interest Group (SIG) “Lift” was founded. This SIG was expected to check existing profiles to see if they are suitable for lift engineering purposes and extend or redefine functions that are needed. The result of this review was the application profile CiA-417 Lift Control (CANopen-Lift) published in June 2003. This profile determined many “virtual units” of a lift system, objects and messages of these virtual units as well as technical marginal conditions (baud rates, services, pin assignments of connectors, etc.). At the Interlift 2003 several manufacturers exhibited the first prototypes of components at a common stand developed by the Special Marketing Group Lift founded for this particular purpose. In the following months the manufacturers integrated the functions step by step into their components and as early as 2005 the first 1000 lifts were supplied with CANopen-Lift components and put into operation. In the years between 2003 and 2009 an increasing number of units were equipped with a CANopen interface and mostly those functions were integrated into the standard which had already been realized conventionally and/or with other interfaces, such as the serial communication between converter and control system with the DCP protocol. The full functionality is available with version 2.0 of CiA-417 which was passed 2010 and is freely available since 2011 as Draft Standard. In order to illustrate the functionality, the Special Marketing Group Lift developed the CANopen-Lift-Demonstrator which was presented for the first time in March 2009 on the occasion of the Heilbronner Aufzugstage. To allow the interoperability to be checked, so-called PlugFeasts were introduced which take place on a regular basis since the beginning of 2009. During the PlugFeasts check lists are used to successively test the functionality of individual units with units of other manufacturers. The developers have the opportunity to directly remedy smaller shortcomings cropping up during the tests. During these PlugFeasts tests were also carried out to check the physical boundaries of the CANopen specification. The stability of the connections with different lengths of bus connections up to a length of 230 m was checked and the units were subjected to a bus stress test in which the bus load was gradually increased with high and low prioritized messages up to 100% bus load while the behaviour of the units was tested.
 
On the occasion of the Interlift 2001 for the first time 20 small to medium-sized lift component manufacturers agreed to participate in producing an open standard for the communication on the CAN-bus. At the beginning of 2002 these manufacturers agreed to use as a development basis the “CANopen” standard already widely used in automation technology for years and extend it by the functions needed for lifts. Within the CAN-in-Automation (CiA) a Special Interest Group (SIG) “Lift” was founded. This SIG was expected to check existing profiles to see if they are suitable for lift engineering purposes and extend or redefine functions that are needed. The result of this review was the application profile CiA-417 Lift Control (CANopen-Lift) published in June 2003. This profile determined many “virtual units” of a lift system, objects and messages of these virtual units as well as technical marginal conditions (baud rates, services, pin assignments of connectors, etc.). At the Interlift 2003 several manufacturers exhibited the first prototypes of components at a common stand developed by the Special Marketing Group Lift founded for this particular purpose. In the following months the manufacturers integrated the functions step by step into their components and as early as 2005 the first 1000 lifts were supplied with CANopen-Lift components and put into operation. In the years between 2003 and 2009 an increasing number of units were equipped with a CANopen interface and mostly those functions were integrated into the standard which had already been realized conventionally and/or with other interfaces, such as the serial communication between converter and control system with the DCP protocol. The full functionality is available with version 2.0 of CiA-417 which was passed 2010 and is freely available since 2011 as Draft Standard. In order to illustrate the functionality, the Special Marketing Group Lift developed the CANopen-Lift-Demonstrator which was presented for the first time in March 2009 on the occasion of the Heilbronner Aufzugstage. To allow the interoperability to be checked, so-called PlugFeasts were introduced which take place on a regular basis since the beginning of 2009. During the PlugFeasts check lists are used to successively test the functionality of individual units with units of other manufacturers. The developers have the opportunity to directly remedy smaller shortcomings cropping up during the tests. During these PlugFeasts tests were also carried out to check the physical boundaries of the CANopen specification. The stability of the connections with different lengths of bus connections up to a length of 230 m was checked and the units were subjected to a bus stress test in which the bus load was gradually increased with high and low prioritized messages up to 100% bus load while the behaviour of the units was tested.
  
Line 9: Line 10:
  
 
=== Energy metre ===
 
=== Energy metre ===
[[File:CANopen_Energy_metre.png]]
+
[[File:CANopen_Energy_metre.png|thumb|Energy measurement with linked components based on CANopen-Lift ]]
 
Until now, the measurement of the energy needs to be done manually during a defined test drive. With the integration of the protocols of an automatic, continuous measurement in the CANopen Lift Standard the total energy requirement can be calculated over a longer period.
 
Until now, the measurement of the energy needs to be done manually during a defined test drive. With the integration of the protocols of an automatic, continuous measurement in the CANopen Lift Standard the total energy requirement can be calculated over a longer period.
  
Line 19: Line 20:
  
 
=== Virtual console ===
 
=== Virtual console ===
[[File:Virtual_console_graphical.png]]
+
[[File:Virtual_console_graphical.png|thumb|Configuration of components with mobile devices]]
 
Every unit can place a virtual display content on the bus and every other unit with a display and keys can be used for the representation and configuration. One could for example use an LCD display in the cab and the keys of the cab panel to display the control menu in the cab during maintenance and access the parameters or information on malfunctions. Right now a method is under development to allow the transfer of the graphical displays’ contents.
 
Every unit can place a virtual display content on the bus and every other unit with a display and keys can be used for the representation and configuration. One could for example use an LCD display in the cab and the keys of the cab panel to display the control menu in the cab during maintenance and access the parameters or information on malfunctions. Right now a method is under development to allow the transfer of the graphical displays’ contents.
  

Revision as of 12:28, 9 July 2013

CANopen-Lift is the base for manufacture independent linking of electronic components

A lot of electronic assemblies are needed to realize the desired functionality, the ride quality and the current safety requirements called for in modern list systems. These electronic assemblies are networked via modern bus systems and use these systems to exchange status information or commands. In order to achieve this, it is necessary to have all assemblies involved in communication “speak and understand” the same bus protocol. This is only possible when all assemblies use an open, standardized protocol or a proprietary protocol produced by only one manufacturer. An example of an open standardized protocol is the application profile CiA-417 Lift Control “CANopen-Lift” that is based on “CANopen”. In this application profile all parameters and commands of a modern lift system are standardized, e.g. like the parameters of the frequency converter in the drive unit or the door controls and commands such as “Open door A”, “Cab call floor 8” or “Position 23.263 m; Speed 0.8 m/s; Acceleration 0.5 ms2”. In the following paper the most important milestones of the development of CANopen-Lift and the latest functions are presented.

RETROSPECTIVE

CANopen-Lift at Interlift 2003

On the occasion of the Interlift 2001 for the first time 20 small to medium-sized lift component manufacturers agreed to participate in producing an open standard for the communication on the CAN-bus. At the beginning of 2002 these manufacturers agreed to use as a development basis the “CANopen” standard already widely used in automation technology for years and extend it by the functions needed for lifts. Within the CAN-in-Automation (CiA) a Special Interest Group (SIG) “Lift” was founded. This SIG was expected to check existing profiles to see if they are suitable for lift engineering purposes and extend or redefine functions that are needed. The result of this review was the application profile CiA-417 Lift Control (CANopen-Lift) published in June 2003. This profile determined many “virtual units” of a lift system, objects and messages of these virtual units as well as technical marginal conditions (baud rates, services, pin assignments of connectors, etc.). At the Interlift 2003 several manufacturers exhibited the first prototypes of components at a common stand developed by the Special Marketing Group Lift founded for this particular purpose. In the following months the manufacturers integrated the functions step by step into their components and as early as 2005 the first 1000 lifts were supplied with CANopen-Lift components and put into operation. In the years between 2003 and 2009 an increasing number of units were equipped with a CANopen interface and mostly those functions were integrated into the standard which had already been realized conventionally and/or with other interfaces, such as the serial communication between converter and control system with the DCP protocol. The full functionality is available with version 2.0 of CiA-417 which was passed 2010 and is freely available since 2011 as Draft Standard. In order to illustrate the functionality, the Special Marketing Group Lift developed the CANopen-Lift-Demonstrator which was presented for the first time in March 2009 on the occasion of the Heilbronner Aufzugstage. To allow the interoperability to be checked, so-called PlugFeasts were introduced which take place on a regular basis since the beginning of 2009. During the PlugFeasts check lists are used to successively test the functionality of individual units with units of other manufacturers. The developers have the opportunity to directly remedy smaller shortcomings cropping up during the tests. During these PlugFeasts tests were also carried out to check the physical boundaries of the CANopen specification. The stability of the connections with different lengths of bus connections up to a length of 230 m was checked and the units were subjected to a bus stress test in which the bus load was gradually increased with high and low prioritized messages up to 100% bus load while the behaviour of the units was tested.

NEW FUNCTIONS

Since 2009 new functions are constantly integrated into the standard and into the units of the manufacturers which would not have been possible in this way without an open standard. Some of them are shortly described in the following sections.

Energy metre

Energy measurement with linked components based on CANopen-Lift

Until now, the measurement of the energy needs to be done manually during a defined test drive. With the integration of the protocols of an automatic, continuous measurement in the CANopen Lift Standard the total energy requirement can be calculated over a longer period.

Energy management

In addition to the existing modes (such as “drive”, “ready”, “standby” or “off”) the power saving mode reduces the demand during the business hours, without compromising the operational readiness of the lift. The resulting savings are much greater than the previously used full shutdown during limited hours.

Bootloader

This process not only allows a software update to be carried out in an assembly but also the parameter sets of all assemblies to be read out and secured following commissioning. This easily allows system manipulations to be detected which are effected after the final inspection. This not only is of interest to the servicing company and operator of a lift system but also to the monitoring authority or the fire brigade in case of damage.

Virtual console

Configuration of components with mobile devices

Every unit can place a virtual display content on the bus and every other unit with a display and keys can be used for the representation and configuration. One could for example use an LCD display in the cab and the keys of the cab panel to display the control menu in the cab during maintenance and access the parameters or information on malfunctions. Right now a method is under development to allow the transfer of the graphical displays’ contents.

IN THE FUTURE

The CANopen-Lift standard is full of life and under constant development. The essential novelties are still coming from Germany, but CANopen-Lift is also increasingly gaining in international importance. In the future CANopen-Lift will be the basis for the remote diagnosis of all components over the Internet and for the safety-related data transmission in lifts. More and more companies are taking part in the development of CANopen-Lift and introduce new ideas into the standard which are available to all participants. The future remains exciting.