Skip to main content
Firmware Stable

ECHO: drive the motor over CAN

Applies to​

A motor controller running ECHO (swid contains _ECHO_), after the motor identification playbook has finished with its power cycle. ECHO takes its commands from the user's own control unit over CAN; this playbook tells the user what to send and sets up the messages the controller sends back.

Before you start​

  • The rules of the general method apply. Writes and save -y need Allow writes.
  • Tell the user plainly: the motor is identified, and the controller now does what the CAN commands say. Their control unit is responsible for the motor; test with the motor free to turn.

Steps​

1. State​

/driver/error and /common/error 0; /driver/motor/Rt not 0 (identified). The controller must have been power-cycled since the identification: while a stop is active, it ignores CAN commands without any error.

2. CAN basics​

The defaults are 1 Mbit/s and address 0 (CAN messages). Ask whether the user's control unit uses the same. Changing either is a separate decision: the bitrate with msgconf, the address with setaddr (interface commands); both change how the controller is reached, need Allow dangerous commands, and take effect after a restart.

3. The drive command​

Point the user to the drive command and its example: the frame carries the drive mode (driver modes) and the command. The control unit must repeat it faster than every 200 ms; when frames stop, the controller lets the motor coast. Explain what the user asks about from those pages; do not compose frames from memory.

For the first test the user sends the example frame (a small voltage command) repeatedly. While it arrives, read /driver/cmd, /driver/mode and /driver/enable (3 = motor driven) to confirm the controller receives it (command).

The controller ignores the commands:

  • a stop still active since the identification: power-cycle;
  • CAN itself: battery power, CAN GND, termination, bitrate and address (power and connection playbook step 4);
  • the frame: the first data byte is the receiver's address (CAN messages); the data length selects the frame variant, and in a variant with a live counter the counter must change in every frame, otherwise the frame is ignored (drive command);
  • the repetition: faster than every 200 ms, typically every 20 to 50 ms.

4. Periodic messages​

Ask which status values the control unit needs (state, speed, current, voltage, temperatures) and how often. Set the matching /sampling/<message>_period parameters (ms, 0 = off) and /sampling/interface_no (3 = CAN) as described on sampling; the message contents are on status messages. save -y; they start after the next power-up. The control unit can also set them at run time with the setup-sampling command described there.

Hand back​

The user power-cycles the controller and checks that the status messages arrive and the drive command moves the motor.

Report​

  1. Device: name, serial number, swid; CAN bitrate and address.
  2. The first test: what was sent and what /driver/cmd, /driver/mode and /driver/enable showed.
  3. The periodic messages set up; what was saved.

Escalate​

The motor does not follow the commands while they arrive: the motor driver playbook.