Stepper controller test code.

[Luke Weston]

I have uploaded StepperTest2.pde to the group.

Feel free to improve it, debug it or comment on it.

If I take the maximum clock frequency (magic number in the call to map
() ) above about 16 k, the stepper stops spinning at the fast end of
the input pot's range... I would have thought the hardware could be
able to go faster than we had it going... so maybe it's a programming
issue, such as integer overflow, inappropriate type etc?

[Nic Jones]

Short time luker, first time poster.

16k seems about normal to me, depending on how many microsteps you're
doing. I had a quick look and couldn't see a torque-speed curve for
the motors you're using, but the torque for a NEMA-17 is usually down
at about 10% of the holding torque at that sort of speed in half-
step. Even free-standing, resonances in the motor are going to make
it lock up at high speed. When it's in the machine, the resonance
points will change, usually down, and you'll see the motors come to a
sudden halt even earlier.

A better driver will get you more speed at the top end but I wouldn't
expect more than (very roughly) 1000RPM from stepper motors in a CNC
machine.

Nic Jones

[michaelc]

Thanks Nic, that's very helpful information. The driver board was
operating in 1/8th step mode and the motor is 1.8 degrees per step, so
16KHz would correspond to 600 rpm. However, it looked to me like the
motor was spinning considerably faster than we expected when we
clocked it 1KHz, which means that we were probably already exceeding
your suggested top speed when clocking at 16KHz. I'm starting to
wonder if perhaps the driver was not micro stepping in the mode we
thought it was. I think it might be a good idea to take a look at the
driver output and see what it's really doing.

From a practical perspective, the axis of the machine that we wired up
was moving faster than we're ever likely to be able to mill any real
material.

Michael Collas

[George Patterson]

2009/11/1 Nic Jones <nic.l...@gmail.com>:

>
> Short time luker, first time poster.
>

Are lukers related to Lukes? :-P

But seriously welcome about.

> 16k seems about normal to me, depending on how many microsteps you're
> doing.  I had a quick look and couldn't see a torque-speed curve for
> the motors you're using, but the torque for a NEMA-17 is usually down
> at about 10% of the holding torque at that sort of speed in half-
> step.  Even free-standing, resonances in the motor are going to make
> it lock up at high speed.  When it's in the machine, the resonance
> points will change, usually down, and you'll see the motors come to a
> sudden halt even earlier.
>

Apparently Luke had set up the board to do 8 microsteps so another
approach *could* be to reduce the number of microsteps. However, there
was plenty of speed for the Z-axis, even if you are wanting to quickly
jog the tool some position.

Well done all on reaching that milestone!

Regards

George

[Mitch Davis]

On Sun, Nov 1, 2009 at 6:37 PM, Luke Weston <reindeer...@gmail.com> wrote:
>
> I have uploaded StepperTest2.pde to the group.
>
> Feel free to improve it, debug it or comment on it.

After Luke's post, I did some further work on the code: If you put
the pot in the central position, the stepper stays stationary. If you
turn it either side, the stepper turns at a rate which is proportional
to how much you've turned the pot. We hooked the board up to the
stepper on the Z axis, and we could make the Z axis go up and down at
varying rates with the turn of a dial.

I was inclined to use this action to drill the holes on my Pebble
board, but I was talked out of it.

Mitch.

[dpgeorge]

> If I take the maximum clock frequency (magic number in the call to map
> () ) above about 16 k, the stepper stops spinning at the fast end of
> the input pot's range... I would have thought the hardware could be
> able to go faster than we had it going... so maybe it's a programming
> issue, such as integer overflow, inappropriate type etc?

The boards are (should be) running in 1/8th microstepping mode. This
is more to make the motion smoother, rather that achieve more
accuracy.

In the firmware I have written, the maximum stepping clock speed is
12247 Hz, which is a spindle rotation speed of 7.654 Hz, which is 459
RPM. With the ball screw and linear slide connected at this speed,
you get 24.3 mm/s linear speed. To get up to this speed from a stand-
still, you need acceleration code (to overcome the static friction).

Cheers,
Damien.

[Nic Jones]

> The boards are (should be) running in 1/8th microstepping mode.  This
> is more to make the motion smoother, rather that achieve more
> accuracy.

I sell CNC kits as part of my day job, and 1/8th is the most popular
(~80%) setting people use, and what we recommend. The only thing to
be aware of is that with most steppers (hybrid or variable reluctance
types) microsteps beyond halfstep don't have quite the holding torque
that the "real" steps have.

> In the firmware I have written, the maximum stepping clock speed is
> 12247 Hz, which is a spindle rotation speed of 7.654 Hz, which is 459
> RPM.  With the ball screw and linear slide connected at this speed,
> you get 24.3 mm/s linear speed.  To get up to this speed from a stand-
> still, you need acceleration code (to overcome the static friction).

Once you start putting acceleration in that in you really start to
push the limits of the AVR, so have have to get clever with your
routine. I wouldn't want to use the standard floating point divide
routine employed by the Arduino environment. (Not to mention the AVR
on the Arduino is running 20% below its top speed) You might be able
to get away with just using fixed-point routines, but to leave as much
CPU processing time in the AVR as possible for doing other stuff (like
servicing the UART to receive commands, or later working out curves)
I'd probably try to aim for something like this:
http://www.embedded.com/columns/technicalinsights/56800129?_requestid=55193

Either that, or bump up to a better processor. There's a slowly-
growing range of ARM-based boards designed to folow the same open-
hardware ethos of the Arduino. I'm personally chomping at the bit to
get my Leaf Labs Maple board, but there's the Cortino, the Illuminato
X Machina and I think another I'm forgetting about (though I was
interested in using the Sparkfun Logomatic at one stage, so maybe it's
that I'm thinking of.)

Nic

[Luke Weston]

On Nov 2, 8:00 am, Nic Jones <nic.l.jo...@gmail.com> wrote:
> > The boards are (should be) running in 1/8th microstepping mode.  This
> > is more to make the motion smoother, rather that achieve more
> > accuracy.
>
> I sell CNC kits as part of my day job, and 1/8th is the most popular
> (~80%) setting people use, and what we recommend.  The only thing to
> be aware of is that with most steppers (hybrid or variable reluctance
> types) microsteps beyond halfstep don't have quite the holding torque
> that the "real" steps have.
>
> > In the firmware I have written, the maximum stepping clock speed is
> > 12247 Hz, which is a spindle rotation speed of 7.654 Hz, which is 459
> > RPM.  With the ball screw and linear slide connected at this speed,
> > you get 24.3 mm/s linear speed.  To get up to this speed from a stand-
> > still, you need acceleration code (to overcome the static friction).
>
> Once you start putting acceleration in that in you really start to
> push the limits of the AVR, so have have to get clever with your
> routine.  I wouldn't want to use the standard floating point divide
> routine employed by the Arduino environment.  (Not to mention the AVR
> on the Arduino is running 20% below its top speed) You might be able
> to get away with just using fixed-point routines, but to leave as much
> CPU processing time in the AVR as possible for doing other stuff (like
> servicing the UART to receive commands, or later working out curves)

> I'd probably try to aim for something like this:http://www.embedded.com/columns/technicalinsights/56800129?_requestid...

>
> Either that, or bump up to a better processor.  There's a slowly-
> growing range of ARM-based boards designed to folow the same open-
> hardware ethos of the Arduino.  I'm personally chomping at the bit to
> get my Leaf Labs Maple board, but there's the Cortino, the Illuminato
> X Machina and I think another I'm forgetting about (though I was
> interested in using the Sparkfun Logomatic at one stage, so maybe it's
> that I'm thinking of.)
>
> Nic

The proper CNC machine hardware certainly isn't running on Arduino...
it's just used for a quick test scaffold for the stepper driver
electronics.

We don't need to change the hardware away from the (assembly-coded)
AVR as Damien used, because we know it works very well.

[Mitch Davis]

On Mon, Nov 2, 2009 at 8:00 AM, Nic Jones <nic.l...@gmail.com> wrote:
>
> I sell CNC kits as part of my day job, and 1/8th is the most popular
> (~80%) setting people use, and what we recommend.  The only thing to
> be aware of is that with most steppers (hybrid or variable reluctance
> types) microsteps beyond halfstep don't have quite the holding torque
> that the "real" steps have.
>

> Once you start putting acceleration in that in you really start to

Thanks for that information Nic, I really enjoyed reading it,
especially the article from embedded.com. You really know what you're
talking about! Can you tell us about the kits you sell? A link to
your website would be great.

Mitch.

[dpgeorge]

> Once you start putting acceleration in that in you really start to
> push the limits of the AVR, so have have to get clever with your
> routine.  I wouldn't want to use the standard floating point divide
> routine employed by the Arduino environment.  (Not to mention the AVR
> on the Arduino is running 20% below its top speed) You might be able
> to get away with just using fixed-point routines, but to leave as much
> CPU processing time in the AVR as possible for doing other stuff (like
> servicing the UART to receive commands, or later working out curves)

> I'd probably try to aim for something like this:http://www.embedded.com/columns/technicalinsights/56800129?_requestid...

I use an AVR running at 20MHz, with all code written in assembly. I
have 24.8 and 16.16 fixed point routines (~100 cycles per mul, ~15 per
add, ~1300 per sine). The acceleration/deceleration code uses a small
lookup table, which is multiplied by a factor computed in real time
for each line segment. The AVR has plenty of grunt to clock the
steppers at full speed, perform Bresenham's line algorithm to
rasterise small line segments, while also converting a parametric
curve into such line segments (eg, turning r*cos(t), r*sin(t) into
small straight line segments). The UART code takes very little
resources.

Cheers,
Damien.

[Nic Jones]

> I use an AVR running at 20MHz, with all code written in assembly.  I
> have 24.8 and 16.16 fixed point routines (~100 cycles per mul, ~15 per
> add, ~1300 per sine).  The acceleration/deceleration code uses a small
> lookup table, which is multiplied by a factor computed in real time
> for each line segment.  The AVR has plenty of grunt to clock the
> steppers at full speed, perform Bresenham's line algorithm to
> rasterise small line segments, while also converting a parametric
> curve into such line segments (eg, turning r*cos(t), r*sin(t) into
> small straight line segments).  The UART code takes very little
> resources.
>
> Cheers,
> Damien.

Well, one one hand I'm impressed, on the other I think you're a little
bit crazy. I enjoy assembly as much as the next man, (which is to
say, not much beyond an academic interest) but for me I think I'll
just stick to higher level languages and solve my problems by throwing
~$1 more silicon at it.

I'd be interested in seeing your code if you've written it under a
permissive licence. If it's something like GPL it's probably best I
avoid looking at all because we don't release the source for our work
projects and I don't want to get GPL'd code in any current or future
work.

> Thanks for that information Nic, I really enjoyed reading it,
> especially the article from embedded.com. You really know what you're
> talking about! Can you tell us about the kits you sell? A link to
> your website would be great.

It seems a little crass to be pimping out the company I work for after
only just joining, so apologies in advance to anyone it might offend:
I work for Ocean Controls. Our CNC kits are here:
http://oceancontrols.com.au/motor_controller/motor_controllers.htm
They basically consist of Fulling stepper motors, Leadshine drivers,
switching power supplies and a parallel port breakout card we designed
and make. We're waiting on a remodel of the website before we do a
full refresh of all the kits. We plan to additionally offer a smaller
servo kit (based on the Leadshine DCM5020 and DCS303) and stepper kits
with the anti-resonance drivers:
http://oceancontrols.com.au/motor_controller/microstepping_digital_controllers.htm

Nic

[Mitch Davis]

On Tue, Nov 3, 2009 at 1:22 AM, Nic Jones <nic.l...@gmail.com> wrote:
>
>> I use an AVR running at 20MHz, with all code written in assembly.  I
>> have 24.8 and 16.16 fixed point routines (~100 cycles per mul, ~15 per
>> add, ~1300 per sine).

> Well, one one hand I'm impressed, on the other I think you're a little
> bit crazy.

Yes that's Damien, who wrote his own FP routines. He also wrote his
own assembler and linker for the CNC project, and a 3-d modeller to
design the mechanicals. Did I mention he wrote his own PCB design
software too? Insanely great stuff....

> It seems a little crass to be pimping out the company I work for after
> only just joining, so apologies in advance to anyone it might offend:

Of course I can't speak for the others, but I'm not offended, as I
like to know where I can get good stuff with knowledgeable advice!

Mitch.

[dpgeorge]

> Well, one one hand I'm impressed, on the other I think you're a little
> bit crazy.  I enjoy assembly as much as the next man, (which is to
> say, not much beyond an academic interest) but for me I think I'll
> just stick to higher level languages and solve my problems by throwing
> ~$1 more silicon at it.

Yeah, I guess that is a more sensible and pragmatic approach. But I
really do enjoy coding in assembler! The exercise was more for a
challenge/fun than doing it in a short time. And, anyway, I only had
AVR silicon at my disposal (I wanted to make the PCB myself). Also, I
have only written an AVR assembler, not a high-level language that
compiles to AVR, so I was stuck using assembler... Basically, one of
the goals was to use my own tools/software for as many of the parts of
the project as possible.

> I'd be interested in seeing your code if you've written it under a
> permissive licence.  If it's something like GPL it's probably best I
> avoid looking at all because we don't release the source for our work
> projects and I don't want to get GPL'd code in any current or future
> work.

I'd love to show it to you, but it will probably be GPL'd in the
future. But, there is no sense in keeping good ideas to yourself, so,
if you want, I can email the source to you for your entertainment.
It's written in my own AVR assembly dialect, with my own pre-
processor, so there is no risk in you using it cut-and-paste :)

Cheers,
Damien.

[Nic Jones]

> I'd love to show it to you, but it will probably be GPL'd in the
> future.  But, there is no sense in keeping good ideas to yourself, so,
> if you want, I can email the source to you for your entertainment.
> It's written in my own AVR assembly dialect, with my own pre-
> processor, so there is no risk in you using it cut-and-paste :)

Well, okay, please do. Hopefully it's not so far from standard code
that I can still understand it. I suppose if it comes down to it, I
could always twist the boss's arm into offering you something to grant
the company a licence.

Cheers,
Nic Jones