I got the parts in from digikey today, and assembled a couple of the rStep boards.  Seems that sanguino uses the 644p and I ordered the 644.  Additionally, I’m clocking the 644 at 20Mhz while the sanguino expects 16Mhz.  I had to make a number of changes to make the 644 work with the arduino.  First, I had to modify the bootloader by adding an entry for the 644 @ 20Mhz, recompiled it, and uploaded it through the JTAG port.  Additionally, the boards.txt file had to be changed to reflect the 644 @ 20Mhz.  Now, it is compatible with the arduino IDE and I was able to compile a simple LED blinking application and upload it without problems.  A few more tests and I’ll be able to send out the beta boards to the developers for further testing.

Electronics, rStep arduino, atmega644, cnc, rstep, sanguino

After a failed order (and 2+ months of waiting) for a PCB order from dorkbot, I reordered the PCB through seeedstuio. $40 shipped for 10 PCBs was great, but they ended up shipping me 18 (must have had extra space on the panels). I paid an extra $10 for the white soldermask (I’m so sick of green. I never want to see a gree PCB). A few weeks later, I got them.

For those of you who have stopped following my CNC posts, I’ve still be active working on an open-source project called rStep. Yes, the r is for Reza. I’m egotistical that way. Anyhow, it’s been a really interesting experience and I’ve gained a lot of insight in running an open-source group. Last I checked, there were 78 members subscribed to the mailing list, and we have about 1/2 dozen active participants who are submitting code, testing, etc. I love seeing an idea start to become something real with people who are interested in the same stuff as I am and see the advantages to such a system. Check out the rStep page for more information.

The parts order is in place, this will be the final beta version (v3) and v4 will be a production run.

Electronics cnc, Electronics, hardware, pcb, rstep, stepper controller

So I’ve managed to avoid blogging for a full year. It’s not that I had a reason to stop blogging, nor is there a reason I’m posting almost exactly one year later. I just think it’s a bit neat. I’ve also noticed my last post was about CNCing — I can’t believe I’ve been working on that project for this long. A lot has happened, but I’ll save that for a future post. I just wanted to recount a debugging episode as I think it might be useful to someone.

I bought an HP 6236B triple output benchtop powersupply off ebay some time ago, and a few months back, the output voltage dropped accoring to it’s analog display, about 10-20%. I thought it a strange failure mode, but I didn’t have much need for it and put off trying to fix it – which I did over this past weekend. One thing I love about older electronics is that they actually expected people to fix them, rather than designing things so complex that they have to be replace or entire circuitboards replaced. I found the manual online (adding copy here for posterity), and not only did it contain the schematic but a debugging guide on what to check for what set of conditions.

Manual for HP 6236A, 6236B, 6237A, 6237B

So the instructions tell you, for a lower output voltage, to first start off by checking the reference voltages. I did, and found all the voltages were lower than they should have been – this seemed quite odd to me. Here’s the schematic of the reference voltage stage:

The debugging instructions said that if the +7.5V supply (first one it had me check) was too low, to check for a short in VR3, a zener diode. So I removed it from the PCB and tested it — worked fine. It gave me a finite list of other possible failure modes: U1, U2, U3, and U4 — all the op amps in the device — but I was reluctant to try to desolder them, and I didn’t expect the problem to be there. I poked around for a few hours but couldn’t think of the cause of the problem so I retired for the night. The next day I started to poke around some more, and wanted to look at the power off the transformer which would have been AC across CR56, CR55 using my oscilloscope. It looked reasonable, and having that out, I decided to use it to poke around a bit more – and noticed that it wasn’t that the reference voltages were lower, rather, they had dips in them corresponding to the lines 60Hz voltage. Sure enough, the multimeter was averaging the value and giving me a stable readout even though the votlage was not constant – and that had led me down the wrong path. The instruction manual even said to use a multimeter for debugging – and no where did it suggest I check out what is, in electronics, the most common point of failure – the capacitors. A bit of testing later, and I had narrowed the problem down to C33 – the capacitor that’s supposed to generate a DC voltage from the AC power line input. It had a strange configuration – 4 prongs (3 GND on the can and one positive terminal). It was also very very light and large – I’m still planning on taking it apart, but don’t think it’s electrolytic. I replaced the 85V 490uF cap with 2 50V 1000uF in series that I had in my workbench, and sure enough, it works like new again.

I did learn two lessons I would like to share. The instructions told me where to look, and that was great, but it also led me down the wrong path. Had I had the schematic and no debugging instructions I would have solved the problem more quickly. It’s important to rely on your instincts as well. In addition, I learned that older PCBs can’t take the heat. I tried to use my hot air reflow station to desoler the cap, but only managed to delaminate and burn part of the back of the PCB. I’ve not had that problem with newer PCBs — so don’t do that.

Electronics, Random capacitor, HP 6236B, repair

Success!

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/

Electronics arduino, cnc, gcode, mill, stepper motor

It’s a step forward, two steps back. I burnt out one of the channels running some preliminary tests, and I just got the replacement board in from Pololu.com. Spent longer than I wanted trying to hook it up (note to self: don’t use such low gague wire). But I was still seeing more jitter in the clocking than I wanted. I tried a few different configurations, and finally came up with an approach that seems to work well, and exhibits a jitter equal to the resolution of the micros() call (4uS). In this approach, it computes the time when the next step happens, figures out which channel needs to step next, then waits for that time in a tight loop:

// 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

Electronics arduino, gcode, stepper motor controller

Just a quick update, I’ve added support for limit switches in the firmware. Enable them by specifying the associated pin, and if it’s active high or active low.  The preferred method is active low otherwise you need to add your own pulldown resistor if it’s active high.

// 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

Electronics arduino, stepper motor

I’ve recently posted about my new stepper motor controller. Well, I was unhappy with the implementation used in the RepRap project, and what started as a code cleanup has turned into a near full rewrite. I’m fairly happy with the code now and finished my preliminary testing. I based my original version of the re-written code turned out to be a variant of Bresenham’s algorithm (though I found this out after I had written the code). The algorythm would determine the axis which required the most travel, step that axis, then add the required travel from one of the other axis to an error term for that axis. When the error term was equal to or greater than one, it would step that axis and subtract one from the error term. This resulted in stepping synchronized with the major axis timebase. Looking at the output of the stepper motor driver, this pattern emerged.

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.

Electronics arduino, controller, gcode, motor, stepper, temporal

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.

Electronics A4983, arduino, motor, stepper

Anyone want to guess what I’m building now?

Electronics, Personal heatsink, peltier, steampunk, tubes

I was in an art store and came across a neat looking alabaster rock.

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

Electronics ajax, art, avr, led, lighting, rock, usb