DeutschEnglishSchweizChinese
Contact | Impressum | RSS

Search:

contact

History in the Making


CAN and Motion Control in Medical Engineering

System Architecture
In order to meet the high stability requirements, a system architecture was chosen that comprises CAN field bus in association with the CANopen protocol and an industrial PC. This decision was prompted, above all, by the fact that the CAN field bus technology has already proved itself in local and relatively static applications, e.g. in automobile development. In addition, the CANopen protocol already offers a motion control profile which standardizes the manner in which a control unit communicates with the motor controller of an axis to execute computed motions with the highest level of precision. Moreover, the development of the software for a functional model on an industrial PC can be carried out quickly and efficiently thanks to the highly advanced and ergonomic PC development environment. The decisive advantage, particularly in this project, is, however, that software that evolves in this way can easily be transferred to the prototype and the series device at a later stage using a microcontroller-based solution.

Project implementation
The task of finding powerful motors for the 13 axes which were then to be controlled via the CANopen controller was not particularly difficult. Thanks to the established and proven
CANopen protocol there are now many providers for such technologies. Selected were the DC motor series with CANopen controllers from the renowned Swiss manufacturer MAXON. The dynamics of the DC motors did allow rapid prototyping in the functional model of the automated DNA analysis and therefore significantly reduced the development period for the automated DNA analysis system. Since the series device won’t need these dynamics less expensive stepper motors will be used in the series device but the software architecture and the main software components will, however, be fully taken over.

Utilization of standards
Standards that are already well established and proven in the market were used in this project. This saves time and significantly reduces the technical risks associated with a new development. In addition, this does, of course, also take consideration of the IVD requirements relating to controlled and orderly development.

One of these standards has already been referred to above: the Motion Control Profile from CANopen. This profile is published under the name "CANopen DS 402-Profile" from CIA, CAN in Automation, and describes uniform profiles for drives and motion control.  Using this profile, the command procedure for an axis that is controlled by a motor with CANopen motor controller is always the same, irrespective of the manufacturer.
 

Figure 1: CANopen profiles and their usage
One further standard is IEC 61131-3. This standard regulates the uniform programming of programmable logic controllers such as the industrial PC and the microcontroller. In addition to specifying the utilization of data types and declarations, it defines, in particular, five programming languages for industrial automation.

The entire motion of an axis is executed via a chain of function block instances which also coordinates with further axis motions  This takes place via the successful Motion Control Profile of the IEC 61131-3 user organisation "PLCopen". The Motion Control Profile is based on function blocks which are individually responsible for a defined section of the axis motion. After processing, this responsibility is passed on to a further function block instance.
In this project, the mapping of this PLCopen Motion Control Profile on the CANopen DS 402 profile proved to be a very significant aspect of the software development. Particularly as the
application software for the functional model had to be IEC 61131-3-based for enhanced portability while the motor activation is CANopen-based. Both profiles each define a status diagram which then have to be merged. This is performed by the Motion Control Library which not only has an IEC 61131-3-based function block interface but also operates the motor controller on the CAN bus via the DS-402 profile.
CANopen and IEC 61131-3 are no strangers to each other and the idea to combine these
standards did not originate from infoteam. The CANopen DS-405 profile "Interface and Device Profile for IEC 61131-3 Programmable Devices" describes how access can be gained to devices on the CANopen bus using IEC61131-3 variables and function blocks. infoteam played an important role in the creation of this profile within the CIA work group and its subsequent publication in March 1998.

Details on the CAN bus
Communication was optimized to keep bus utilization at a constant, low level. The process data is, to the greatest extent possible, not transferred cyclically but only "Upon Change", i.e. when a single piece of data was actually changed. This guarantees that the signals are transferred collision-free and promptly to the CAN bus which, in this case, is operated at 1Mbit.


Details relating to the implementation of the Motion Control Library
The existing implementation of the Motion Control Library supports only single axis function blocks but does not implement those that are used to synchronize several axes - which is also not necessary for the automated laboratory systems. The library does, however, implement function blocks of various motion modes. Aside from MC_MoveAbsolute and MC_MoveRelative of the Discrete Motion Mode, the library also implements MC_MoveVelocity of the Continuous Motion Mode. Both of these are modes from the PLCopen Motion Control Profile. These are mapped on the Profile Position Mode and the Profile Velocity Mode of the DS-402 profile from CANopen. The additional MC_TorqueControl uses the Profile Torque Mode, also from the CANopen DS-402 profile.
The SDOs (service data objects) und PDOs (process data objects), which are specified in the CANopen DS-301 profile, form the basis for all communication on a CAN bus with CANopen protocol. In the IEC 61131-3 implementation of the Motion Control Library external variables are used to access the quickly changing PDOs of the bus. Function blocks are, on the other hand, used to access the SDOs which do not change so quickly.

Flexibility of the combination
The flexibility of software environment played a key role in the development of the software for the automated laboratory systems. In the case of the functional model, the Motion Control Library was implemented and tested with the programming system in Structured Text for the purpose of rapid prototyping. The OpenPCS execution time system was ported to the industrial PC and extended by a CAN stack which realizes the CAN bus connection. This could also be implemented rather quickly from a rapid prototyping viewpoint as the IPC operates under a normal Windows XP system which was enhanced with the real-time extension RTX from Ardence. In this way, the popular, advanced and powerful development tool Visual Studio from Microsoft was available and, in addition, the system even had real-time capabilities thanks to RTX.
In the case of the prototypes, the Motion Control Library was - for performance and handling reasons - taken over in the firmware of the execution time system which could be ported to a PowerPC platform with relative ease. One of the particular benefits of this solution is that all the application software that had been developed up to that time could be operated on the new platform without changing the program code.  Thanks to the well-conceived and stable, but yet flexible software architecture on the basis of OpenPCS, the tried and tested software components in the functional model could simply be taken over in the prototypes. This saved a great deal of time and development costs.


Now the laboratory assistants, biologists and chemists are focusing on ways of further improving the biological procedures that are controlled with these automated laboratory systems with the ultimate aim of integrating them into a process. Here, they use the included CFC editor (Continuous Function Chart) for the purpose of modeling these processes on the automated system. Even though the natural scientists are not very familiar with the automation technology, these specialists can use environment as a modeling tool in the areas of biology and chemistry.

 


©2010 infoteam Software AG, http://www.infoteam.de/