Show EOL distros:
Package Summary
The package cob_canopen_motor implements a controller-drive component which is connected to a can-bus and works with a canopen-interface. "CanDriveItf" provides a - more or less - generic interface to the controller-drive components. "CanDrvie..." then implements a specific setup, e.g. an ELMO Harmonica Controller in case of the "CanDriveHarmonica".
- Author: Christian Connette
- License: LGPL
- Repository: care-o-bot
- Source: git https://github.com/ipa320/cob_driver.git
Package Summary
The package cob_canopen_motor implements a controller-drive component which is connected to a can-bus and works with a canopen-interface. "CanDriveItf" provides a - more or less - generic interface to the controller-drive components. "CanDrvie..." then implements a specific setup, e.g. an ELMO Harmonica Controller in case of the "CanDriveHarmonica".
- Author: Christian Connette
- License: LGPL
- Source: git https://github.com/ipa320/cob_driver.git (branch: release_electric)
Package Summary
The package cob_canopen_motor implements a controller-drive component which is connected to a can-bus and works with a canopen-interface. "CanDriveItf" provides a - more or less - generic interface to the controller-drive components. "CanDrvie..." then implements a specific setup, e.g. an ELMO Harmonica Controller in case of the "CanDriveHarmonica".
- Author: Christian Connette
- License: LGPL
- Source: git https://github.com/ipa320/cob_driver.git (branch: release_fuerte)
Package Summary
The package cob_canopen_motor implements a controller-drive component which is connected to a can-bus and works with a canopen-interface. "CanDriveItf" provides a - more or less - generic interface to the controller-drive components. "CanDrvie..." then implements a specific setup, e.g. an ELMO Harmonica Controller in case of the "CanDriveHarmonica".
- Author: Christian Connette
- License: LGPL
- Source: git https://github.com/ipa320/cob_driver.git (branch: groovy)
Package Summary
The package cob_canopen_motor implements a controller-drive component which is connected to a can-bus and works with a canopen-interface. "CanDriveItf" provides a - more or less - generic interface to the controller-drive components. "CanDrvie..." then implements a specific setup, e.g. an ELMO Harmonica Controller in case of the "CanDriveHarmonica".
- Maintainer status: developed
- Maintainer: Matthias Gruhler <mig AT ipa.fhg DOT de>
- Author: Christian Connette
- License: LGPL
- Source: git https://github.com/ipa320/cob_driver.git (branch: hydro_release_candidate)
Package Summary
The package cob_canopen_motor implements a controller-drive component which is connected to a can-bus and works with a canopen-interface. "CanDriveItf" provides a - more or less - generic interface to the controller-drive components. "CanDrvie..." then implements a specific setup, e.g. an ELMO Harmonica Controller in case of the "CanDriveHarmonica".
- Maintainer status: maintained
- Maintainer: Matthias Gruhler <mig AT ipa.fhg DOT de>
- Author: Christian Connette
- License: Apache 2.0
- Source: git https://github.com/ipa320/cob_driver.git (branch: indigo_release_candidate)
Package Summary
The package cob_canopen_motor implements a controller-drive component which is connected to a can-bus and works with a canopen-interface. "CanDriveItf" provides a - more or less - generic interface to the controller-drive components. "CanDrvie..." then implements a specific setup, e.g. an ELMO Harmonica Controller in case of the "CanDriveHarmonica".
- Maintainer status: developed
- Maintainer: Matthias Gruhler <mig AT ipa.fhg DOT de>
- Author: Christian Connette
- License: Apache 2.0
- Source: git https://github.com/ipa320/cob_driver.git (branch: kinetic_release_candidate)
Package Summary
The package cob_canopen_motor implements a controller-drive component which is connected to a can-bus and works with a canopen-interface. "CanDriveItf" provides a - more or less - generic interface to the controller-drive components. "CanDrvie..." then implements a specific setup, e.g. an ELMO Harmonica Controller in case of the "CanDriveHarmonica".
- Maintainer status: maintained
- Maintainer: Matthias Gruhler <mig AT ipa.fhg DOT de>
- Author: Christian Connette
- License: Apache 2.0
- Source: git https://github.com/ipa320/cob_driver.git (branch: kinetic_release_candidate)
Package Summary
The package cob_canopen_motor implements a controller-drive component which is connected to a can-bus and works with a canopen-interface. "CanDriveItf" provides a - more or less - generic interface to the controller-drive components. "CanDrvie..." then implements a specific setup, e.g. an ELMO Harmonica Controller in case of the "CanDriveHarmonica".
- Maintainer status: maintained
- Maintainer: Matthias Gruhler <mig AT ipa.fhg DOT de>
- Author: Christian Connette
- License: Apache 2.0
- Source: git https://github.com/ipa320/cob_driver.git (branch: kinetic_release_candidate)
Contents
Elmo Recorder
General overview, workflow
Elmo controllers have the functionality to record drive information (like position,velocity, current) at a very high frequency into their own flash memory. Later on, you can read out the recorded data and analyze it on a (remote) PC. Read-out can easily be done by connecting the computer over RS-232 directly to the Elmo-MC.
Another way, that realizes a much easier way of reading out multiple Elmo MCs at once, is to do this via CANopen protocol using the CAN-bus, that is described in the following.
The package cob_canopen_motor contains an implementation for Elmo Harmonica drives. The integrated class ElmoRec provides functions to give the user easy access to the recording functionalities of these drives.This class performs all necessary steps to configure the recorder and to read out and process the data.
These steps to get drive information from the Recorder are described in the following chapters.
In order to get data, you have to perform the following steps:
- Configure the recorder using binary interpreter commands. You have to set properties such as recording length, which data should be recorded, start-trigger...
- Start the recorder if not done automatically by a preset trigger
- Read-out data, after recording is finished
- Request one specific recorded channel via SDO Request
- Performing a “segmented SDO Upload”
Configure the recorder
You can find a lot information about advanced functions and configuration options on the Elmo MC website (http://www.elmomc.com/products/whistle-digital-servo-drive-main.htm).
In the following, one example configuration of the recorder is given:
(See also SimplIQ Software Manual, 7.4 The Recorder).
//Stop Recorder if it's active RR = -1
// Record: // Main speed (index 0, ID1) // Main Position (index 1, ID2) // Active Current (index 9, ID10) // Speed Command (index 15, ID16) // RC = 2^(Signal1 Index) + 2^(Signal2 Index) + ... e.g. 2^0 + 2^1 + 2^9 + 2^15 = 33283 RC = 33283
// Set Recording Length // RL = (4096 / Number of recorded signals) as Elmo MC can store 4096 data points RL = 1024
// Set Time Quantum, Default: RP=0 -> Time Quantum = TS * 4; TS is 90us by default RR = 0
// Set Recording Gap // Recording Gap specifies, every which Time Quanta a data point is recorded RG = 1
// -> Total Recording Time = 90us * 4 * RG * RL
That all was the very basic configuration of the recorder. Next, you can specify various trigger events or optionally start the recorder immediately.
// Set trigger type to immediate and start recording RR = 2
//or start at next BH-command RR = 1
Now you have to wait until recording of data has finished. To request the recorder state, use the general status register (binary interpreter SR), that contains 2 bits (bit 16 - 17) telling the recorder state (0: Recorder inactive, no valid recorded data , 1: Recorder waiting for a trigger event , 2: Recorder finished; valid data ready for use , 3: Recording now) When the recorder has finished, you can start the read-out process.
Read out recorder via CAN
In this document, only the read-out via CAN is described. For information about how to get data via RS-232, please refer to SimplIQ Command Reference.
You can get the recorded data using a ServiceDataObject (SDO). SDOs are part of the CANopen protocol and are documented properly in the CANopen DS 301 Implementation Guide by Elmo.
You have to initiate a (segmented) SDO Upload (upload means from Elmo MC to computer) according to the CANopen protocol (see 4.3f in CANopen DS 301 Implementation Guide). Each received segment must be answered by a message including a toggle-bit. Every segment has one header byte for managing SDO transfer (including toggle-bit, last-segment-bit and number of unused bytes). The other 7 bytes are actual data.
Recorded data is stored in SDO object 0x2030, the subindex specifies which signal should be uploaded. You can only upload signals, that have been explicitly selected for recording earlier.
After starting the SDO transfer you get a data stream of the values of the selected signal.
Consider, that all the data you get is “Little Endian” formatted. That means, the least significant byte of a value stands first in the stream. The first 7 bytes of the emitted stream contain header information:
Header byte of emitted data stream |
|||
Byte 1 |
Byte 2 - 3 |
Byte 4 - 7 |
|
4 Bit Int |
4 Bit Int |
Integer |
Float |
Type of values: |
DeltaT between data points in N * TS(90µsec) |
Number of recorded data points = number of data items (á 4 or 2 bytes) |
Factor, which every data value has to be multiplied with |
Remember always to apply “Little Endian” conversion byte-wise.
Float values are given in IEEE 754 representation and have to be converted (see http://en.wikipedia.org/wiki/IEEE_754-1985).
Flowchart of read-out process