Plays well, runs with forklifts

  • 10-Sep-2008 02:36 EDT
forklift_300-1 (2).jpg

Jungheinrich developed in-house its forklift specifications, in which the company's global CANopen object dictionary contains all necessary information to run the systems.

­­­

Forklifts use a variety of electronic devices that are networked via one or more CAN networks, quite often with the CiA CANopen higher-layer protocol. Jungheinrich, for example, manufactures a variety of pallet trucks, forklifts, and order stackers that use CANopen networks. 

With more than 40 different machines, the company uses a CANopen design tool to address such diversity with an approach that enables its engineers to deduce individual systems and device descriptions from a CANopen global object dictionary (OD).

Jungheinrich develops some of the electronic devices for its forklifts in-house but also outsources developments to third parties. The one thing always developed in-house is the design of the vehicle system. This design step includes the development of the device specifications, even though the company may not manufacture the actual parts itself.

To ensure fast development cycles over such vehicle range, the company uses what it describes as a holistic approach, from which the vehicle systems and the individual device descriptions can be derived. Its global OD contains all objects in the company-specific area of the OD that are required to run and service Jungheinrich forklifts.

The idea behind a holistic approach is to divide the total amount of objects into subsegments in such a way as to enable a vehicle-system designer to generate the ODs of all devices within the system by simply importing segments from the global OD. For example, a system designer could have the task of designing the communication structure of a vehicle, which uses devices such as the master controller, the ac drive of the powertrain, the ac drive of the lift motor, and inputs and outputs for the interfacing devices.

The global OD contains a subsegment for the basis functions of all CANopen participants in Jungheinrich equipment, including objects for the system time, log entries, default settings of the service parameters, execution of the system self tests, etc. This subsegment of “standard objects” is the first to be imported into the device-specific OD; next are the specific subsegments for the device ODs, which describe the device functionalities.

For ac drives, such objects may include the revolution speed's nominal and actual values, the description of the motor equivalent circuit diagram, the settings of the encoders, or the status messages concerning the output stage.

It is possible to combine several subsegments within a single device because of the fixed, non-overlapping subsegment areas within the global OD, which could be the case for the drive control with interface functionality, for example.

At the end of the design process, the system designer defines the communication parameters for the process and service data communication. Thus, all communication profiles are developed quickly, whether for Jungheinrich’s own device manufacturing or as specification basis for third parties.

If this whole process was done via software such as C source code, all participants in the development process—including third-party suppliers—would have to use the very same protocol stack. Logistically, this is not feasible.

Jungheinrich has used the CANopen protocol stack by ­Port for several projects. Along with its software stack, its CANopen design tool makes it possible to assemble an OD from the CiA CANopen device profiles.

The CANopen design tool administers device data bases, from which the OD and an initialization function in C-code; an EDS (electronic data sheet) and documentation are produced automatically. It simplifies the configuration of the CANopen library and the CANopen driver packages, and it runs with Linux or Microsoft Windows. Jungheinrich uses it to assemble its global OD as reference for all device ODs used within a project.

To create and administer the individual device profile, the tool extension CAN-Merge contains functions to compare and mix projects done in the CANopen design tool, enabling Jungheinrich “to coordinate the different CANopen projects in the forklifts in a comfortably and time-saving fashion,” according to Rüdiger Schwarz, Head of Software Development at the company.

Since the tool outputs the EDS files into a standardized XML format, further processing into reports is possible with XSL-style templates via commonly available XML tools. The design tool also supports the version management in such formats as CVS or Subversion. Version management is not just useful but an essential requirement in projects that are subject to rigorous quality checks, such as forklifts.­­­

Heinz-Jürgen Oertel, Port, and Holger Zeltwanger, CiA, wrote this article for SAE Off-Highway Engineering.

.

Share
HTML for Linking to Page
Page URL
Grade
Rate It
5.00 Avg. Rating

Read More Articles On

2016-09-16
Manipulator position sensing is a key issue in the study of hydraulic excavator automation. A neural network-based vision system was developed to estimate the boom, arm, and bucket cylinder displacements of an excavator manipulator during a grading operation simulation.
2016-08-25
Autonomous driving and machine system automation continue to increase productivity and convenience in farm production.
2016-11-11
Baumer's inductive sensor technology measures a distance on a target with high speed and high precision, enabling equipment condition assessment.
2016-11-11
NOsparc arc suppressors from Arc Suppression Technologies are designed for both ac and dc power applications.

Related Items

Standard
2014-07-09
Training / Education
1997-05-29
Article
2016-11-11