I was showing a friend my progress with the code, and he was complaining that the stepper motors were loud, and suggested I turn on fractional stepping. I switched to 1/16th steps, and he was right, the motors sounded much better. Additionally, the Z-axis magically started working! I was also impressed how well my code handled high stepping rates — well, more surprised that it worked without more surprises. So I’ve passed a big hurdle. I need to test the circle routine (pretty much the only piece of code I’ve not rewritten from the original code base), do some more tests, and try milling my first PCB!

Here’s a quick video demonstrating it moving in 3 axis at different rates, 1/16th step.

You can browse the latest version of the code here: http://code.google.com/p/rsteppercontroller/source/browse/

// start move
while (xaxis->delta_steps || yaxis->delta_steps || zaxis->delta_steps) {
        a = nextEvent();
        while (micros() < (starttime + a->nextEvent) ); //wait till next action is required
        if (can_move(a)) {
                _STEP_PORT |= a->direct_step_pin;
                //need to wait 1uS
                __asm__("nop\n\t""nop\n\t""nop\n\t""nop\n\t""nop\n\t""nop\n\t");
                __asm__("nop\n\t""nop\n\t""nop\n\t""nop\n\t""nop\n\t""nop\n\t""nop\n\t");
                _STEP_PORT &= ~a->direct_step_pin;
        }
        if (--a->delta_steps) {
                a->nextEvent += a->timePerStep;
        } else {
                a->nextEvent = 0xFFFFFFFF;
        }
}

The latest version of the code is checked into SVN on google code.

So anyhow, I get everything working nicely only to find that the Z-axis controller is also fried — these guys are way too sensitive. Need to order yet another board.

Reza

// specify min-max sense pins or 0 if not used
// specify if the pin is to to detect a switch closing when
// the signal is high using the syntax
// #define MIN_X 12 | ACTIVE_HIGH
// or to sense a low signal (preferred!!!)
// #define MIN_Y 13 | ACTIVE_LOW
// active low is preferred as it will cause the AVR to use it's internal pullups to
// avoid bounce on the line.  If you want active_high, then you must add external pulldowns
// to avoid false signals.
#define ACTIVE_HIGH _BV(7)
#define ACTIVE_LOW  _BV(6)
#define MIN_X 0
#define MAX_X 0
#define MIN_Y 0
#define MAX_Y 0
#define MIN_Z 0
#define MAX_Z 0

Here the G-Code command was “G1 X3 Y2 Z1″ — and indeed the ratio of steps is 3:2:1, but notice that the Y-steps are required to align with the X-Steps (master axis because it moves the furthest), but because 3 is not divisible by 2, it skips every third step. This motion is bad for the stepper motor, and it can cause all sorts of problems.

It is *extremely* important the steps be evenly spaced, unless you’ll be content with slow, unreliable operation. Jitter in the step pulse train will limit your top speed, as it *will* cause the stepper to stall. -Ray L.

So I spent some time thinking about it, and came to the conclusion that the Bresenham’s Algorithm only makes sense if you are dealing with a pixelated output (its main purpose is for fast rendering of lines on computer screens). I realized that I needed was a temporal based one, and came up with something. I still need to do a literature search to see if someone has come up with it yet (would be surprising if no one has) but this is basically what I came up with.

1. Determine the number of steps per axis
2. Determine the distance of travel for the command, and based on the feedrate, compute the duration of the command.
3. Compute the time between steps (TBS) for each axis (duration / steps)
4. Start the main loop.
5. 1. If the time elapsed is equal to 1/2 the TBS, then step that particular axis.
   2. Wait 1/2 TBS, then go to step 5.

I prototyped this in python, and came up with

maxtime = 100.0; #duration of motion in microseconds
steps = 41.0;  #number of y steps
timePERstep = maxtime/steps; #time per step
y=0;
stepped = 0;
oldTimeIntoSlice = 0;
for time in range(0,int(maxtime)):
        timeIntoSlice = (time%timePERstep);
        if (timeIntoSlice < oldTimeIntoSlice):
                stepped = 0;
        oldTimeIntoSlice = timeIntoSlice
        if (timeIntoSlice >= 0.5*timePERstep) and (stepped == 0):
                        #print 'step'
                        stepped = 1;
                        y = y + 1;
        print '%d,%d' % (time,y)

Which generated this sort of a stepping profile. Notice that the steps are pretty evenly spread out..

After rewriting the arduino code, I tried the same test (with G1 X1 Y2 Z3 this time) and got much better results

Notice how everything is nicely spread out. Looking at the timestamps, the maximum step jitter is about 150uS. The next step is to hook this up to some stepper motors and see what it does.

I’ve also released the code for the arduino here in case it might be of help to anyone. I’m thinking of making a daughter board for the arduino with the stepper controller ICs on it in order to simplify deployment for others — if there is interest.

Decided to drop my PCB and use some prebuilt modules from pololu. Doing the math, this turned out to be the cheapest option (3x$13 vs. $50 for the PCB plus another $30-$50 to populate). The pololu modules use Allegro’s A4983 intgrated h-bridge drivers rated at up to 2A – which amazes me given the size of the ICs. I’m a bit worried but I suspect that they’ve already been tested. I’m going to power it with a +/- 15V 3A supply I have, and use the g-code parser from the reprap project.

Anyone want to guess what I’m building now?

And for some reason, I thought it would be cool to stick some lights in it, which started yet another project. I started out by building a circuit on the cheap using some components I had lying around.

I thought it would be cool to control the color from the PC, so I decided to check out the AVR-USB project. The cool thing about AVR-USB is that it handles the USB protocol in firmware alone and doesn’t require any additional ICs. I had a number of hickups – the biggest one being that as soon as a USB packet was received, the SPI on the AVR would stop working. After many hours of not being able to figure out the culprit, I resorted to bit-bang SPI and everything started working. The lights are shiftbrites from macetech. The cable is an ISP programming interface for the AVR. Component count is fairly low – a crystal, a bypass cap, a supply cap, two USB termination resistors and a pullup resistor.

I used a masonry bit to drill a lot of holes in the bottom of the rock, then used a hammer and chisel to finish enlarging the space. The board just barley fits in there.

And the effects were pretty cool..

The communication is via a modified hidtool.c application (an example shipped with AVR-USB) which transmits a 4 byte payload which is then shifted onto the LEDs. For completeness, I wrote a small application in perl to act as a webserver and handle requests – forwarding valid requests to the hidtool application. And I also put together a nice color picker front end which uses AJAX to update the color on the fly. So as you move the color picker, the rock changes color accordingly. I put together a video of everything working together here :

There is a small amount of lag, which is to be expected — the chain of operations is…

1. open web app, and pick a color
2. color picker uses AJAX to send requests to a server running on my desktop
3. server forks hidtool.exe with the color arguments
4. hidtool then connects to the USB device (rock) and transmits the new color strings.

This chain of events is repeated every time the color changes – this happens as the cursor is being moved around thus it can generate quite a few requests. To improve throughput, I would need to merge the C app into the perl app, or visa-vera.

I’ve gone ahead and put the application online here so go ahead and set your mood color which will be displayed on my rock.

Live Feed

This image is updated every 5 seconds.  Or go here.

Resources

• Web Application – change the AXAJ target by modifying js/layout.js
• Firmware & Command Line Tool
• Perl WebServer
• Schematic

My nixie tubes arrived today from Russia. Trying to decide what to make with them. Any ideas? The one on the left displays numerals, and the one on the right is bar graph. I have 10 of each. I was thinking of perhaps a 10 channel spectral analyzer for my stereo with the bar graphs. A lot of people make clocks with the tubes on the left, but that seems almost a bit too generic.