As part of the Large Scale Delta project I needed to control multiple stepper motors, each being over a distance of roughly 50 to 150 feet. To control each motor I chose to use the Sparkfun AutoDriver board which will drive up to 3 amps continuously and communicates over SPI. The AutoDriver, which uses STmicro’s L6470 chip, has built in current limiting, over current protection, stall protection, micro stepping and more but what is most important is that it has motion commands which handle the low level motion control aspects allowing you to command a position and it will handle the rest. This along with Sparkfun’s AutoDriver Library allow for easy and precise control of a stepper motor from an Arduino. While a SPI bus is easy to use over short distances it was not designed to run more than probably a few feet and definitely not tens or hundreds of feet, when you get to that kind of distance it introduces a few issues that need to be overcome.
The first thing that must be overcome is drive strength and noise, an Arduino or any microcontroller for that matter would not be able to directly drive a clean signal over the distances required so an additional drive is required, plus the amount of noise picked up over such a long run would render any signal left utterly useless. To solve both of these problems I decided to run the SPI bus over RS-485, which is designed for communicating over long distances and in noisy environments. With this configuration I would not be able to run the SPI bus at its maximum speed, 5 Mbit/s for the AutoDriver, but would be limited to around 2 Mbit/s as the bandwidth of RS-485 is dependent on the length of the run. This limitation is not critical because that would still be more than enough bandwidth to control multiple stepper motors quickly enough to for my purpose.
The second thing to consider when running SPI over such a long distance is timing and delay. The SPI protocol is synchronous, meaning that there is a clock signal that accompanies the data which is used to latch data into a register. If this clock gets to far out of sync with the data due to various delays along the way you will get corrupted data. Luckily Thomas over at TI wrote a great article that covers a way to keep a SPI bus synchronized over long distance and also reaffirmed my choice of using RS-485. His method is to run the SPI CLK and MOSI signals from a controller though a set of RS-485 transmitters and then over twisted pair and through a set of receivers where it is then connected to the slave SPI device. For the return path you take the CLK from the RS-485 receivers along with the MISO from the slave SPI device and run them through another set of RS-485 transmitters over a different set of twisted pair and through a second set of receivers. This return set of SPI signals is connected back to the controller as an SPI slave device, not the master device used to transmit. Using this method you could theoretically have an SPI bus run over thousands of feet.
One of the nice features of SPI is that it allows you arrange the bus so each SPI slave is independent, enabled by separate slave select signals, or to daisy chain them and use only a single slave select signal. The AutoDriver, really the L6470, was designed to work with both configurations and that is something that I wanted have as an option, but for my purpose the daisy chain configuration was going to be the best. To use the Sparkfun library there are five signals that are required, the CLK, SS, MOSI, MISO and RST signals. Using the RS-485 method described above in a daisy chain configuration I will need four pairs of wire from the controller to the AutoDriver, four pairs from AutoDriver to AutoDriver, and three pair from the last AutoDriver back to the controller as shown below. The benefit of using this configuration is that it will allowed me to use Cat5 or Cat6 cable which is readily available and cheap in bulk.
Continue on to the prototype boards add testing…