Feb 172014

The Goal

I have an old White 1602 knitting machine that uses a light scanner to produce patterns in the knit fabric. The bed of the knitting machine syncs up with the controller via two obsolete rotary encoders and the stitch patterns are produced as a sequence of pulses causes specific needles to be selected.

The first problem is that the light scanner has a lot of mechanical parts that have deteriorated with age. Parts are no longer available.

The second problem is that the width of the pattern is constrained by the width of the mylar that feeds into the light scanner to product the pattern.

The third problem is that while the light scanner does its job well when it's functioning, all of its capabilities could be performed more efficiently and accurately by a computer.

My goal is to completely replace the light scanner with newer technology. This post illustrates a prototype for how I might use an optical coder to track the position of the knitting carriage as well as when it changes direction.


Arduino Mega 2560 R2
US Digital Optical Encoder S1-1250-I
4 male-to-female jumpers
Electrical tape

About The Encoder

While obsolete, the S1-1250-I encoder is a very capable piece of hardware, but much more expensive than what's available on today's market. I used it because I already had one, but the information presented in this post should work with any rotary quadrature encoder. I'll most likely replace the US Digital with a SparkFun's COM-11102 1024 P/R Quadrature Encoder I have on order.

About The Approach

There are basically two ways to interface with the encoder: polling and interrupts. A little project I'm playing with will require a considerable amount of accuracy, so I chose to use interrupts as polling might result in missed pulses.


The encoder has 3 outputs: channel A, channel B and index. We're not going to use index, so we need to make 4 connections -- one for each of the two channels, one for power and one for ground. The encoder has raw wires so we need to add pins in order to attach it to the Arduino.

  1. Make sure the Arduino is powered off.
  2. Strip 1/4" - 3/8" of insulation from the encoder's leads for power, ground, channel A and channel B.
  3. Insert the end of each wire into the female end of a jumper and secure with electrical tape.
  4. Connect the power lead to the 5V power pin.
  5. Connect the ground lead to one of the Arduino's ground pins.
  6. Connect the channel A lead to digital pin 20. This pin is one of the 6 Arduino pins that support interrupts. The other pins with interrupts are 2, 3, 18, 19 and 21.
  7. Connect the channel B lead to digital pin 17.

The Code

How It Works

Lines 8 - 12 define a few useful constants to make the code more readable. What they do should be obvious from the comments.

Lines 15 - 16 define global variables that will be modified by the interrupt handler.

Line 19 & 22 define other global variables we'll use inside the Arduino loop.

The setup() function on line 24 configures our channel A and channel B pins for input, attaches an interrupt handler to channel A's pin and configures the serial port so we can see some diagnostic output. Note that we're going to interrupt on a rising state change so we know that the state of channel A will always be high when our interrupt is triggered. Using a rising or falling interrupt means:

  • We always know the state of A without having to perform a read: A is always high in a rising interrupt and always low in a falling interrupt.
  • Since we always know the starting state of A, we only have to test the state of B to determine direction and track the current position.

The Arduino loop() function on line 40 does nothing more than print some diagnostic information about what we're reading from the encoder. To avoid chatter, the loop is tracking current values against previous values to we don't print information we've already seen.

The interrupt handler on line 55 does all the heavy lifting:

  • When the encoder is moving in one direction, the pulse from channel A is leading the pulse from channel B. When the encoder is moving in the other direction, the pulses are reversed.
  • When the state of A and B are equal, B must be leading A, so the encoder is turning counter-clockwise. Otherwise, A is leading B, so the encoder is turning clockwise. Remember when we configured our interrupt to fire on rising? The state of channel A will always be high, so we only need to check the state of channel B to determine direction.
  • By comparing A to B instead of hard-coded constants, we can change the interrupt between rising and falling without breaking the interrupt handler.

The code on line 75 keeps the counter within the range 0 to 1249. This would allow us to compute angle or synchronize the position of the encoder to some other device.

The code on line 78 is an extra bit of diagnostic info we can use to track how many times our interrupt has fired.

Further Discussion

It's much easier to understand how the interrupt handler works if you understand what's happening when you turn the encoder shaft and reverse direction.

When you turn the encoder's  shaft clockwise, A is leading B. This results in 4 distinct transitions that are repeated over and over as long as the shaft continues rotating in the same direction.


What's important is this:

  • The inputs are latched, meaning that when we read B's value from A's interrupt handler the value we get is B's state as it existed at the time the interrupt handler was fired. 
  • The handler is fired when A goes high.
  • When the shaft is turning clockwise, the handler is fired between the first two transitions --before B goes high -- so we know the shaft is rotating clockwise when A is high and B is low.

If the shaft is turning clockwise and you stop turning, A remains high and B remains low.

If the shaft then starts turning counter-clockwise, B is leading A. This means that B has to go high before A's interrupt fires again. Therefore, when both A and B are high, the shaft must be turning counter-clockwise.

Some makers may be inclined to use interrupts on both A and B. Unless you have an application where you absolutely must perform some action between A and B going high in both directions, the second interrupt is completely unnecessary. Interrupts are an expensive, limited resource so it's wise to only use them when you need them.