Gaugette

SwitecX25 Quad Driver Tests

Sat, 29 Apr 2017 14:16:00 +1000

This article demonstrates a modification of the Arduino SwitecX25 driver library to use a AX1201728SG quad driver chip (equivalent to the X12.017 or VID6606). This chip offers some significant advantages over driving the motor directly:

it uses microstepping to provide smoother positioning - 12 steps per degree rather than 3.
it requires only two GPIO pins per motor (plus one global reset pin)
it protects the microprocessor from the inductive effects of the motor coils
it places lower current requirements on the microprocessor

In the past I’ve been unable to find a low-volume supplier for the X12.017 Quad Driver Chip, or any of the functionally identical chips from other manufacturers. These are the ones I know about:

The VID VID6606 Quad Driver (datasheet)
The NOST Microelectronics BY8920 Quad Driver (datasheet, in Chinese)
The AX1201728SG (by EmMicroe maybe?)

Recently both the AX1201728SG and VID6606 have become readily available in small quantities.

The AX1201728SG

The AX1201728SG is available in single quantities from ebay for a few dollars apiece. The one complication is that they are SOP28 surface mount packages, which are a little harder to prototype with than DIP packages. I bought some drivers, and some SOP28 to DIP28 adaptors so I could mount the drivers on a breadboard for testing.

Mounting

I haven’t worked with SMD chips before, so I had a friend help me mount them. We used tweezers to apply the paste, and a regular household oven for reflowing. Very basic, but it worked fine.

Wiring It Up

Initially I’m testing with a single motor on output A. The wiring is as follows:

VSS (chip pin 12) to GND
VDD (chip pins 1 and 15) to 5V
RESET (chip pin 26) to Arduino pin 10
CW/CCW A (chip pin 27) to Arduino pin 9
f(scx) A (chip pin 28) to Arduino pin 8

The motor connections are:

OUT1A (chip pin 7) to Motor pin 1
OUT2A (chip pin 6) to Motor pin 2
OUT3A (chip pin 4) to Motor pin 3
OUT4A (chip pin 5) to Motor pin 4

Software

I started with a basic hello-world program to run the motor forward and backwards so I could work out any setup issues before switching to the more complicated driver software.

/*
  X12.017 Quad Driver Test
  Drive the motor forward and backwards through 270 degrees
  at constant speed.
 */

const int LED = 13;
const int DIR_A = 9; // pin for CW/CCW
const int STEP_A = 8; // pin for f(scx)
const int RESET = 10; // pin for RESET
const int DELAY = 250; // μs between steps
const int ANGLE = 270; // of 315 available
const int RANGE = ANGLE * 3 * 4;
int steps = 0;
bool forward = true;

// pull RESET low to reset, high for normal operation.

void setup() {
  pinMode(DIR_A, OUTPUT);
  pinMode(STEP_A, OUTPUT);
  pinMode(LED, OUTPUT);
  pinMode(RESET, OUTPUT);

  digitalWrite(RESET, LOW);
  digitalWrite(LED, HIGH);
  digitalWrite(STEP_A, LOW);
  digitalWrite(DIR_A, HIGH);
  delay(1);  // keep reset low min 1ms
  digitalWrite(RESET, HIGH);
}

// The motor steps on rising edge of STEP
// The step line must be held low for at least 450ns
// which is so fast we probably don't need a delay,
// put in a short delay for good measure.

void loop() {
  digitalWrite(STEP_A, LOW);
  delayMicroseconds(1);  // not required

  steps++;
  if (steps > RANGE) {
    forward = !forward;
    steps = 0;
    digitalWrite(DIR_A, forward ? LOW : HIGH);
    digitalWrite(LED, forward ? HIGH : LOW);
  }

  digitalWrite(STEP_A, HIGH);
  delayMicroseconds(DELAY);
}

This worked, mostly. If I leave the motor running for a while I notice that the needle position drifts, which indicates either missed steps, or a counting problem. Increasing the inter-step delay from 250ms to 500ms resolved that problem, so most likely I’m exceeding the (low) torque limit during the turnaround. I’m not worried about that - once I port the SwitecX25 library I can find a safe set of acceleration parameters to keep it from dropping steps.

Adapting the SwitecX25 Library

The SwitecX25 library provides an acceleration/deceleration model, and some higher-level control abstractions. Importantly, it is asynchronous. The caller sets a desired step position and then calls the update() method as frequently as possible and the library manages the scheduling of the steps.

One concern I have about supporting the quad driver is the being able to service the pin transitions quickly enough. When driving the motor directly we need to update 4 outputs once per step. With the quad driver we need to pulse the f(scx) line low then high once per micro-step, which equates to 8 transitions per full step. It may turn out to be difficult hit all of the timing deadlines to drive 4 motors at full speed simultaneously.

My first cut at this is to create an entirely new class SwitecX12 which duplicates the key timing code from SwitecX25, with new output logic and an adjusted acceleration curve.

The code below zeroes the needle, moves the needle to the centre of the sweep, then cycles between ¼ range and ¾ range.

#include <SwitecX12.h>

const int STEPS = 315 * 12;
const int A_STEP = 8;
const int A_DIR = 9;
const int RESET = 10;

SwitecX12 motor1(STEPS, A_STEP, A_DIR);


void setup() {
  digitalWrite(RESET, HIGH);
  Serial.begin(9600);
  motor1.zero();
  motor1.setPosition(STEPS/2);
}

void loop() {
  static bool forward = true;
  static int position1 = STEPS * 3/4;
  static int position2 = STEPS * 1/4;
  if (motor1.stopped) {
    motor1.setPosition(forward ? position1 : position2);
    forward = !forward;
  }
  motor1.update();
}

Conclusion

The AX1201728SG looks very promising. It’s a bit of a nuisance to deal with surface mount devices if you aren’t set up for it, but not insurmountable.

The microstepping is really smooth. Below is a video showing how smooth. I used a very exaggerated acceleration table to keep the needle in the slow range for longer.

Resources

Tue, 01 Nov 2016 14:39:00 +1000

Source Code

Switec X25 Series Stepper Motors

VID29 Series Motors

VID23 Series Motors

VID23 Transparent Shaft Motor

MCR Motor MR1107/MR1108

Driver Chips

X12.017 Quad Driver Chip Data Sheet
BY8290 Quad Driver Chip Data Sheet (in Chinese), and here’s a link to a Google-generated English translation of the data sheet
VID6606 Quad Driver Chip Data Sheet

Gauge Build Number One

Sat, 28 Jan 2012 15:56:00 +1000

This weekend I opened up one of the cheap-but-funky thermometers/hygrometers from Lets Make Time and replaced the thermometer mechanism with the Arduino-controlled Switec X25.168 stepper. The thermometer and hygrometer are installed in identical one-part plastic housings with no screws or seams, so it wasn’t clear how to crack them open. I used a Dremel to cut away the back panel giving access to the thermometer mechanism, but to my surprise the dial face was still firmly locked in place. After a bit of poking around I discovered that I could push the whole assembly out forward - in fact the plastic lens is only held in by friction, and the dial and mechanism are held in by the lens. No cutting was required. #LFMF

This turned out to be important because after careful measurement I realized that the motor would have to be mounted snugly against the the back of the housing to leave the drive shaft protruding enough to attach a needle. The plastic panel I cut away would have been ideal to screw the motor to. Starting again with an undamaged housing, I gently pried out the plastic lens, removed the face and mechanism. This time I only cut away enough plastic on the back to allow the drive shaft to pass through.

The needle and the bi-metal thermometer coil came off the face easily enough, but the mounting for the coil is a crafty two-piece deal that mounts through the centre of the dial. It appeared to be assembled a bit like a rivet, and a couple of solid blows from the back with a punch released it cleanly from the dial face.

I originally intended to use screws to secure the stepper to the back of the housing, but there isn’t much tolerance for positional error, which made me nervous. Instead I used the conical rivet-thingy to precisely align the motor drive shaft in hole in the dial and held it all in place while I hot-glued it to the back of the case. Alignment was spot-on the the motor seems to be solidly secured. So far so good.

Next I wired up the Arduino and zeroed the motor against the low stop and put the needle on. There were some unexpected complications at this point. The motor has a sweep of 315 degrees, but this dial only allows about 230 degrees of needle movement. I modified the library to support a soft range limit to avoid exceeding 230 degrees, while still running through a full 315 degrees during reset.

While trying to calibrate the dial I found the needle slipping at times, especially under vibration caused by the power-on reset or slow stepping. With the needle slipping calibration was impossible. I tried applying the smallest drop of hot glue I could manage to the back of the needle. That really didn’t work - the tiny irregular mass between the needle and the dial face would sometimes bind against the dial face, causing more problems.

I believe the needle hole is dished a little, so I removed the needle, cleaned the glue away, and smacked it with a hammer to flatten out the dish and close up the hole. That worked a little too well and I had to ream the hole out a bit with a thumb tack. Now the needle is nice and snug, no slippage.

So here’s how it looks assembled. Calibration is slightly out, but I’m going to make a new dial face anyway, so no need to sweat about that.

A Simplified Acceleration Model

Thu, 26 Jan 2012 09:42:00 +1000

The logic in the advance() function of the Switec X25 library steps the motor forward or backward one step, then computes the delay in microseconds until the next step is due. This logic determines the acceleration curve and maximum speed of the needle. My first cut at this code used floating point arithmetic to model this as time/accel/velocity problem. The motion was nice and smooth, but it was overkill, and consumes too many precious Arduino compute cycles. When driving multiple motors, this will create an artificial ceiling on the maximum motor speed. I’ve rewritten that logic to use a simple lookup table instead. This is a fairly obvious approach, but it was reassuring to see similar approaches recommended in both the VID 29 documentation and the MCR MR1107 data sheet .

The acceleration curve is defined as pairs of vel,delay values:

unsigned short accelTable[][2] = {
  {   10, 5000},
  {   30, 1500},
  {  100, 1000},
  {  150,  800},
  {  300,  600}
};

We maintain a variable vel (which isn’t actually velocity, but is a surrogate for velocity) that increments each step under acceleration, and decrements each step under deceleration. When stationary, vel is zero. After 1 step of acceleration it is 1. For simplicity I’ve made the acceleration and deceleration curves identical so they can share the same lookup table.

To determine the inter-step delay at any given value of vel, we find the first table entry such that accelTable[i][0] < vel. In practice this means that the motor will step at 5000 µS intervals for 9 steps, then 1500 µS steps for the next 30 steps, 1000 µS for the next 100 steps, and so on. The peak speed with a delay of 600 µS equates to 1666 Hz step rate or about 500 degrees per second.

The motion control logic first determines if the motor is subject to acceleration, at full speed, or deceleration and adjusts vel accordingly. Using steps as the unit for vel makes it very easy to determine when to declerate: when vel is greater than or equal to the number of steps to reach our destination, we need to start decelerating.

The new logic also ensures that if the motor is moving at speed in one direction and is directed to a new position in the opposite direction it will decelerate to a stop before accelerating in the opposite direction.

The constants that make up the acceleration table are constrained by the the inertia of the needle attached to the motor. The VID 29 documentation gives some recommendations for calculating these values, but I actually didn’t use that. I experimented until I found values that were within operational limits and look nice to me.

I tested this code driving 3 motors simultaneously with an Arduino Uno. All good. New code is in the library on Github.

Two Motors, One Arduino

Mon, 23 Jan 2012 14:39:00 +1000

Last night I built a pair of improved wiring harnesses so I could connect two motors to the Arduino. Once concern I have is that the control logic that manages the acceleration and deceleration could be so slow that it will interfere with the motor drive signaling when trying to control more than one motor. I have in mind to replace the floating point logic with a lookup table, but for now I like being able to easily fiddle with the motion parameters.

It turns out that two motors work pretty well with only minor tweaks to the existing code.

Motor Acceleration and Deceleration

Sun, 15 Jan 2012 19:38:00 +1000

My first cut at the Switec X25 library stepped the needle at a constant speed. You can see the constant speed motion in the original video.

I’ve updated the library to support acceleration and deceleration, partly because it seems more aesthetically pleasing, and partly because I have a notion that I should be able to reach faster peak speeds by ramping the speed up. Motion is now specified by 4 parameters: minimum speed, maximum speed, acceleration, deceleration.

For now I’ve used floating point calculations to compute each step period standard Newtonian velocity/distance/time calculations. This works okay, but is unnecessarily compute-intensive.

The Switec X25 library supports multiple motors and no doubt this computation will become a factor when I try to drive more than one motor, so I’ll have to address that at some point.

One interesting aspect of the control logic is that the calculations are done at the start of each step, in distance-domain rather than in time domain like most simulations. This means the calculations must be done more frequently at higher needle speeds. This is going to set an upper bound on maximum step rate.

When it does become an issue, I think I could replace the entire floating point calculation with a small table of pre-computed (step-count, step-period) pairs with little perceptible difference.

Initial Results

Mon, 09 Jan 2012 14:16:00 +1000

Wiring It Up

Given the comments by Toby Catlin about cooking the motors while soldering, I opted to make up a harness with a connector rather than soldering directly to the motor. The pins on each winding exactly match the spacing of the first and fourth pins of a standard 0.1” connector. JST RE connectors are the right pitch, but the pins on the motor are too short and too narrow to engage with the connectors. For my first harness I cut up a floppy disk cable connector into two 4-hole sections and soldered wire to the first and fourth pins. It worked fine but it is pretty bulky, and the metal contacts in the connector did not solder very easily. For now I just pushed the tinned ends of the wires directly into the Arduino connectors. I wrote some code for the Arduino to step the motor using the IO pattern established in this post and a quick ruby script to query my pfSense firewall to get some live data to test with.

Add some duct tape for a gauge, and behold the simplest analog bandwidth meter ever:

What is Gaugette?

Thu, 05 Jan 2012 13:11:00 +1000

Gaugette is a project detailing the construction of custom analog gauges using an Arduino microcontroller and Switec X25.168 stepper motors. Each motor requires 4 digital I/O pins, and a single Arduino can drive three motors. The limit is purely due to Aruidno limit of 14 digital I/O lines.

Source code for the project is available on GitHub.

Motivation

After playing with the motor shield party pack from Adafruit, I started thinking it would be fun to have a couple of analog gauges mounted on the wall somewhere to show system health indication; maybe network bandwidth or web traffic? Of course I’ve seen the very beautiful TorrentMeter by Skytee which is so pretty it makes me weep, but beautiful brass antique voltmeters are in short supply around here.

The servos and steppers in the Adafruit pack aren’t ideal for driving gauges. The little stepper they include runs really hot. The servo seemed like possibility and it is driven by PWM, so I wouldn’t even need the motor shield. But it is quite bulky and noisy, so I started looking for something better.

The Switec X25 Stepper Motor

I noticed a lot of sellers on eBay selling tiny Switec X25 motors as replacements for GM auto instrument clusters. They were developed by the technology arm of Swatch, so I figured they should be low power and pretty quiet. Certainly they are cheap; under $5 each!

The X25 motors have 6 steps per revolution, and a 180:1 gearbox, giving a resolution of 1/3 degree. The data sheet indicates they draw no more than 20mA per winding, which is low enough to source directly from the 5V Arduino data pins, raising the possibility of driving these without an intermediate controller chip. Yes, I understand the risks associated with wiring inductive loads directly to the microcontroller. Arduinos are cheap, why not try it?

On the net I found an excellent overview of the Switec X25 by Mike Powell. Mike expresses concerns about driving inductive loads directly from the microcontroller and uses an external L293D driver. There is an intriguing thread by Toby Catlin which approaches the issue of driving these without a controller, but the thread ends abruptly at the point where he sees the first signs of success. What happens next? Blue smoke?

At the price I figured it was worth a shot driving these directly, so I ordered 6 from one of many eBay stores selling them. Apparently a complete GM instrument cluster has 6 motors, so 6 is a popular quantity. In all it cost about $25 including postage from the US to Australia. At the time of writing they carry both the X25.168 with rear contacts, and the X25.589 with front contacts and a longer indicator shaft. Both have internal stops. See the buyers guide for details on the different models.