Cost will be more than $200 – The motor drivers were the most expensive bit of it. One could bring down the cost by hand-building the driver boards, but I sourced the PCBs from BatchPCB.
Plans for this robot: learn about CNC machines and control systems, and machine prototype PCBs for other robots. […]
Credit where credit is due: My CNC is deeply indebted to TinHead’s work on the motor driver (node/6967), driver software, Arduino controller software, and hardware design, along with the discussions on the “Valkyrie” robot page (node/9006). Driver software is http://github.com/TinHead/Valkyrie-CNC-source-code/tree/master . Somewhere in the driver and Arduino source code, the RepRap project gets kudos as well. Debt is also owed to http://buildyourcnc.com for some of the construction tips. I wouldn’t be able to join the wood so well without learning good drilling technique. Also, ladyada’s AVR tutorial ( http://www.ladyada.net/learn/avr/ ) was essential to programming the ATTINY2313 used in the stepper drivers. The controllers were programmed on a minimalist target board from evilmadscientist.com ( http://www.evilmadscientist.com/article.php/avrtargetboards ).
Giving back: I’ll be posting more detailed plans for my iteration of this machine. It is TinHead’s design, but where there needed to be alterations (e.g. the PCB design needed changes before BatchPCB would accept it) I made changes, and where there were ambiguities, I had to figure them out (for example, the views of the robot from the back, sides, and bottom I wished I could see). Also, I ground a copper-clad board into my first prototype circuit board (first ever!) while waiting for BatchPCB, and if I wanted to spend many hours grinding copies of that prototype motor driver board, I could have saved easily $70 on manufacturing the boards (toner transfer would have been quicker but I had a new rotary tool to try out). If the proto driver board works, I’ll post that as well. My plans for this homage to the Valkyrie is to document the building as best I can, so that more pics and plans are available online for folks like me who want to tinker.
The limiting factor for speed of a stepper motor is probably the length of time the motor takes to heave its coils and the load it is moving a half or whole step. I am picturing a motor driver circuit (oblivious to the motor position) sending a signal to the L298, which switches the 12 volt motor current to a different winding in the stepper. The stepper motor now is exerting a torque on the drive shaft. The drive shaft is lifting or moving an inertial load and needs time for the force to do its work. Optimizing the time I give the driver to move the half-step will allow the CNC to move faster while not missing steps. If the driver code is too eager, it will skip steps since the load cannot be moved by the force I am applying in the short time I am applying the force. If I give the driver code all the time in the world to apply the force, the steppers will be moving slowly.
For a RepRap, the amount of time I give the motor to work will not be the speed-limiting factor. The extruder speed is probably more limiting than the stepper speed in terms of how quickly the machine can fabricate a flyswatter or hairbrush or a corner block for another RepRap. If the speed of the motor driver/Arduino system was based on the RepRap speed, there should be room for adjustments.
Since the inertial load and friction are different between the CNC and RepRap (and between individual CNCs) there is room for optimization of a particular machine. In fact, if I do not optimize, and my machine has more friction or weight than the driver was built to handle, I’ll end up with a CNC that does not go where it is told to go. I expect that a CNC that I build with the motors and hardware I am using will have different requirements than the Valkyrie CNC or the Beast CNC due to friction, weight, and motor capability.
Thinking like a physics student who likes simple examples (that’s me!): as long as the torque can overcome the static friction of the machine, I can compensate for torque by giving the motor more time to act. As you mentioned though, too slow a movement and the steppers will cause resonance and efficiency will be lost – allowing the resonance to settle is an option, but will slow down the machine.
The feedrate calculation is one of the steps in the Arduino/RepRap code I have my eye on. I suspect that the delay between steps serves two purposes: to let the motor do its work, and also to allow the extruder time to extrude more plastic. I intend to tinker with that calculation until the only delay is the one to let the motor move the machine. The delay caused by running the calculations on a 16MHz processor I could subtract from the calculated feedrate, or I could try to trim down the code to a lighter program. All theory for now, testing on Friday or Saturday to see how fast the Arduino and I2C driver can drive an unloaded stepper.
attiny2313 fuses, Stepper wiring, and I2C experiments
So the fuses on ATTINY2313 should be set -lfuse 0xff to set the 16MHz external crystal. I bricked my extra attiny2313 while learning (so that it’s now set to use an external clock instead of a crystal), which reinforces a learned lesson: always order an extra.
avrdude -c usbtiny -p t2313 -U lfuse:w:0xff:m
The stepper wiring was quite a debugging problem, solved by accident: The wires out of the stepper are two rows of 3 wires, the middle of each row is ignored. Allegedly, these should be in order {A1,A2,A3} and {B1,B2,B3}. Initially I wired the A1 to pin 0 (A1 pin in the code), B1 to pin 1 (B1), A3 to pin 2 (A2), B3 to pin 3 (B2). This was wrong, which I figured out by noticing that the stepper vibrated, and slowing down the test pattern just slowed down the back-and-forth stepping. Reading the data sheet which gave the order as A1,A3,B1,B3 (which matched the sequence in the code, I switched A3 and B1 accidentally and it solved the problem: the stepper rotated. So {A1,A3,B1,B3} wires go to {A1,B1,A2,B2} pins. Lesson: learn the sequence by reading the documentation!
So the I2C is all that remains. I don’t know whether I can use a seperate power supply for the Arduino that is not linked to the drivers (so far the separate supply isn’t working). The drivers run off an ATX PSU 12V with a regulator that gives 5V to the attiny2313 driver microcontroller. The Arduino uses a DC adaptor plugged into the wall. The “Wire.h” library reference indicates that Analog Pin 5 is SCK and Analog Pin 4 is the data line. SCK is pin 19 on the attiny2313, and data is pin 17. No success yet, so I’ll check my driver circuit for shorts or errors and the nearest Radio Shack for a plug to power my Arduino from the 12V ATX PSU.
