PCBs for CNC machine

[Luke Weston]

Presently revised designs (for FT232 board and for slightly tweaked
microcontroller board) are now online, located at GitHub -> lukeweston
-> CNCMachine /revised_hardware/

Tell me what you think.

The ability to control a transistor to turn off the optocoupler LEDs
is now implemented, but this requires a redesign of the machine-
mounted breakout board, which isn't done yet.

Need to learn how to export CAM/Gerber data from EAGLE, which I've not
done before, and we need to write something which can plug into
Damien's code and take the EAGLE-derived Gerber or other CAM data and
drive the machine.

We can go right ahead whenever we please and manufacture 3 x A3977
boards using Damien's original design since he has of course already
got the files in the appropriate format. Unless someone suggests some
way of improving the A3977 boards?

Cheers.

[michaelc]

On Aug 30, 11:44 am, Luke Weston <reindeerfloti...@gmail.com> wrote:
> Presently revised designs (for FT232 board and for slightly tweaked
> microcontroller board) are now online, located at GitHub -> lukeweston
> -> CNCMachine /revised_hardware/
>
> Tell me what you think.
>
> The ability to control a transistor to turn off the optocoupler LEDs
> is now implemented, but this requires a redesign of the machine-
> mounted breakout board, which isn't done yet.
>

On the microcontroller board, it looks like you have enough room to
get C6 closer to the micro - on the other side of C1. Realistically
it's not likely to be a problem because you've got such wide traces,
but the closer you can get the decoupling cap to the micro's power
pins the better.

Unless your goal is to create an exact replica of Damien's circuit, it
might be good to bring out some more of the micro's left over I/O to
connectors. From what I observed today, there would be value in one
extra input line to use for a Z-axis zeroing probe, and another couple
of outputs to control the Proxxon's motor speed (maybe via a digipot).
I also noticed the emergency stop being used a few times today, and my
paranoid side thinks that from a safety perspective it might be good
if the emergency stop button could directly cut power to the drill and
stepper drivers instead of only doing this through the micro.

> Need to learn how to export CAM/Gerber data from EAGLE, which I've not
> done before, and we need to write something which can plug into
> Damien's code and take the EAGLE-derived Gerber or other CAM data and
> drive the machine.
>

Exporting gerbers from Eagle is not hard but there's room for things
to go wrong: maybe you could start with this cam file:
http://www.sparkfun.com/tutorial/Eagle-DFM/sfe-gerb274x.cam. It's
worth checking the output with a gerber viewer to make sure things are
scaled right.

Michael Collas

[Luke Weston]

> Unless your goal is to create an exact replica of Damien's circuit, it
> might be good to bring out some more of the micro's left over I/O to
> connectors. From what I observed today, there would be value in one
> extra input line to use for a Z-axis zeroing probe, and another couple
> of outputs to control the Proxxon's motor speed (maybe via a digipot).

So, just bring them out to pin headers for now, or something? good
idea.

RE: controlling the Proxxon speed, do you mean hacking inside the
Proxxon tool and replacing the pot in its control circuit with a
digital pot? wow, that's an ambitious hacking job.

> I also noticed the emergency stop being used a few times today, and my
> paranoid side thinks that from a safety perspective it might be good
> if the emergency stop button could directly cut power to the drill and
> stepper drivers instead of only doing this through the micro.
>

My understanding of Damien's current system (I might be wrong) is that
when the emergency stop is executed, the X and Y positions are kept
fixed and the Proxxon is turned off, but the Z axis drive is pulled up
a bit away from the work area. This means that you can't just cut off
power to the stepper drives in hardware. But you could certainly
implement a hardware-based cutoff of the power to the tool.

[Clifford Heath]

On 31/08/2009, at 4:37 PM, Luke Weston wrote:
>> it
>> might be good to bring out some more of the micro's left over I/O to
>> connectors.

> So, just bring them out to pin headers for now, or something? good
> idea.

When you're operating in a motor control (noisy) environment,
you should put an external fast diode clamp on any such pins.
Otherwise you risk blowing the CPU from stray noise pickup.
A double-diode clamp like a BAV99 is an easy way to do it.

Clifford Heath.

[Nic Jones]

Sorry for digging up an old topic. I've only just found the files and
had a look.

I'd suggest a real relay in addition to (or in place of) the SSR for
the mill. SSRs leak a small amount of current even when completely
off, and I've seen this actually be enough to have small rotary tools
slowly spinning. SSRs are great for speed control, but most of the
rotary tools have a little speed control on them already.

Also, given you're going down from 24V to 5V, driving a bunch of LEDs
(the optoisolators) and you probably want to leave room for future
expansion, it's be a good idea to make sure the 7805 can have a
heatsink on it. I use this one in a lot of the things I design to run
up around 24V:
http://www.altronics.com.au/index.asp?area=item&id=H0630
It might fit on the microcontroller board as is. I would try to avoid
standing the 7805 vertical to make it fit if it doesn't though - lying
against the board like you've got it is better for vibration
resistance.

I'd also suggest moving C4 closer to the 7805 on the microcontroller
board. The 7805 is rugged as all get out, but it's good practise with
linear regulators to have the caps close to prevent oscillations.

The ground for the microcontroller is only connected by a small trace
between pins 16 and 17 of the MCU. Given those pins aren't being
used, why not just connect them to ground? Unless there's something
strange about those pins (I haven't looked a the datasheet for the
chip) they should be high-impedance input pins by default anyway.
That would give you much more copper connecting the ground plane.

Nic Jones

[michaelc]

> The ground for the microcontroller is only connected by a small trace
> between pins 16 and 17 of the MCU.  Given those pins aren't being
> used, why not just connect them to ground? Unless there's something
> strange about those pins (I haven't looked a the datasheet for the
> chip) they should be high-impedance input pins by default anyway.
> That would give you much more copper connecting the ground plane.

Those pins are general purpose IO, with TxD1 / RxD1 as alternate
functions. I'd suggest leaving them open. If you get runaway software
for any reason, there's a risk those I/O pins could be pulled high by
the micro, in which case you'll have the supply line shorted to ground
through the micro and it may get toasted. It's also nice to have the
second serial port available (even if we have to connect via clips)
for debugging purposes.

Michael Collas

[Nic Jones]

> Those pins are general purpose IO, with TxD1 / RxD1 as alternate
> functions. I'd suggest leaving them open. If you get runaway software
> for any reason, there's a risk those I/O pins could be pulled high by
> the micro, in which case you'll have the supply line shorted to ground
> through the micro and it may get toasted.

Given that this is a CNC machine controller, run-away software has far
more concerning consequences than shorting out the microcontroller.
In fact, that's one of the safer failure modes. I have a long-
standing belief that all microcontrollers, deep within their dark
silicone hearts, want to kill us all. If I can figure out github I
might have a bash at editing the layout in the next couple of days.
(Unless there's some reason these are effectively "released to
master"? I'm still catching up on the current state of the project)

In the best of all possible worlds, all the unused pins would be
brought out to .1" headers, but it's clear from the current board
layout that it's designed to be home-etched single layer, so not all
things are possible. Is there a list of restrictions (track width,
spacing, etc) that we're trying to stick to?

Nic Jones

[michaelc]

On Nov 5, 4:02 pm, Nic Jones <nic.l.jo...@gmail.com> wrote:
> Given that this is a CNC machine controller, run-away software has far
> more concerning consequences than shorting out the microcontroller.
> In fact, that's one of the safer failure modes.  I have a long-
> standing belief that all microcontrollers, deep within their dark
> silicone hearts, want to kill us all.

Especially me :) I get nervous when people network micros, because I
know they're just communicating to plot ways to get me.

> If I can figure out github I
> might have a bash at editing the layout in the next couple of days.
> (Unless there's some reason these are effectively "released to
> master"?  I'm still catching up on the current state of the project)
>

As far as I know, the board has already been produced by milling it on
Damien's original machine. Other than that, the status of the project
is that the mechanics are nearly complete - initial version of x and z
axis complete, and y axis probably only a couple of productive work
sessions away. We have not been giving the electronics as much
attention because there are less uncertainties in that area, but Luke
has recently put quite an effort in and has a stepper driver up and
running. For now our plan is to use Damien's host software, firmware,
and hardware completely unmodified because it is a known quantity and
it will get us started quickly. I don't expect we'll want to build new
hardware, firmware and software for quite some time yet. Once the
mechanics are done and electronics assembled I'm hoping we'll be able
to get to first cuts quickly because we have pre-built firmware and
host software. From that point I'm expecting we'll take some time to
get the machined dialed in - it is hand built after all, so there will
quite a bit of adjusting to do.

One day there will be replacement hardware. I have hardware and
software plans in mind that are very different, but they're just my
plans and other people might have other ideas. Personally I like the
idea of multiple sets of hardware, firmware and software being
developed, so I'm hoping that other people are also scheming away.

> In the best of all possible worlds, all the unused pins would be
> brought out to .1" headers, but it's clear from the current board
> layout that it's designed to be home-etched single layer, so not all
> things are possible.  Is there a list of restrictions (track width,
> spacing, etc) that we're trying to stick to?
>

Agreed that it would have been nicer to break out more I/O. There are
other things that would have made sense to integrate onto the same
board, e.g. the USB communications.

As far as I know the board was designed for isolation milling and has
been milled. If I'm wrong about that and it's intended for photo
etching, then there are a number of people at CCHS who are experienced
at this, and we each have our own capabilities and preferences so
what's needed for this board depends on who produces it.

I have Eagle DRC files that suit my current processes - it boils down
to 10 mil tracks with 10 mil clearance minimums for normal cases. I
also have a very strong preference for surface mount because it's
easier to solder and because I don't enjoy drilling lots of tiny holes
in fiberglass. Others I've spoken to have very different approaches,
which I think is a good thing to maintain because collectively it
gives us a broader range.

Michael Collas

[Luke Weston]

On Nov 5, 11:15 am, Nic Jones <nic.l.jo...@gmail.com> wrote:
> Sorry for digging up an old topic. I've only just found the files and
> had a look.
>
> I'd suggest a real relay in addition to (or in place of) the SSR for
> the mill. SSRs leak a small amount of current even when completely
> off, and I've seen this actually be enough to have small rotary tools
> slowly spinning. SSRs are great for speed control, but most of the
> rotary tools have a little speed control on them already.
>
> Also, given you're going down from 24V to 5V, driving a bunch of LEDs
> (the optoisolators) and you probably want to leave room for future
> expansion, it's be a good idea to make sure the 7805 can have a
> heatsink on it. I use this one in a lot of the things I design to run
> up around 24V:http://www.altronics.com.au/index.asp?area=item&id=H0630
> It might fit on the microcontroller board as is. I would try to avoid
> standing the 7805 vertical to make it fit if it doesn't though - lying
> against the board like you've got it is better for vibration
> resistance.
>
> I'd also suggest moving C4 closer to the 7805 on the microcontroller
> board. The 7805 is rugged as all get out, but it's good practise with
> linear regulators to have the caps close to prevent oscillations.
>

> The ground for the microcontroller is only connected by a small trace
> between pins 16 and 17 of the MCU. Given those pins aren't being
> used, why not just connect them to ground? Unless there's something
> strange about those pins (I haven't looked a the datasheet for the
> chip) they should be high-impedance input pins by default anyway.
> That would give you much more copper connecting the ground plane.
>

> As far as I know, the board has already been produced by milling it on
> Damien's original machine.

No. We need to make this ourselves, once I've finished designing it.
(This also means you can propose whatever you like with regards to
changing it or improving it at this stage if you feel so inclined.)

However, the stuff on GitHub really doesn't reflect the current state
of my work, I'm really busy and tired at the moment, but I'll do some
more work on that on the weekend probably and push it out to GitHub so
it's more up to date.
(eg. yes, I moved the decoupling capacitor...)

It has some simple modifications and improvements from Damien's
original one:
7805 on the same PCB, three 3-pin connectors to distribute the power
rails out to the motor controllers neatly, CP2102 replaced by a
FT232RL and moved onto the same PCB as the microcontroller, etc,
pretty straightforward but obvious and compelling areas where it would
be improved over Damien's original 1.0 without truly changing the
design to any meaningful degree.

So, what you end up with is the two wires, 24V and ground, going from
the SMPS to the microcontroller board, three three wire cables with
Molex headers going from the microcontroller board to the stepper
controllers, and three six wire ribbon cables going from the
microcontroller board to the stepper controller boards, again they're
just cables wired straight across between two Molex style 0.1" female
header connectors. The LCD is also connected to the microcontroller
board.

Plus you've got the sensor and misc control odds and ends that come
from the microcontroller going to the D25 connector, plus a bunch of
shielding grounds from the microcontroller board, plus the stepper
motor leads, all of which goes to the D25 connector, and then on the
machine end, that cable goes to another breakout board where the
steppers, optocouplers, etc. connect.

It is only a single sided board though, so board fabrication by the
usual photolithographic means (or even toner transfer if anyone would
like a demonstration of that) will be straightforward.

> > In the best of all possible worlds, all the unused pins would be
> > brought out to .1" headers, but it's clear from the current board
> > layout that it's designed to be home-etched single layer, so not all
> > things are possible.  Is there a list of restrictions (track width,
> > spacing, etc) that we're trying to stick to?
>

I'm happy to aim for that goal on the board layout... there will be a
few 16 thou tracks down the middle of two adjacent pins on the IC (~20
thou away from the pads, or so?), but that is pretty much the closest
spacing you'll need to deal with... oh, and the 12 thou or so pads on
the surface mount FT232RL. Maybe even a wire link or two if worst
comes to worst... but I've got no wire links yet and I'd like to keep
it that way. :)
Clearly nothing else on the board will have routing clearances or
widths as small as those associated with a 28-pin SSOP chip.

The requirements are very different to Pebble... it does not need to
be laid out as agriculturally as possible for noobs to solder it.

> Agreed that it would have been nicer to break out more I/O. There are
> other things that would have made sense to integrate onto the same
> board, e.g. the USB communications.
>

Yeah, break out all the unused pins to 0.1" headers. Sure. Will do.
And USB on the main board. I'm integrating that at present. It removes
a little flexibility with respect to the board mounting position
within the case, but I don't think that's a big deal.

PS: Who's got an AVR programmer? Mike B, you've got one, right?

What kind of ICSP header pinout on the target device is appropriate? 6
pins, the same as an Arduino? Is that OK?

Ugh, time for sleep now I think.

Cheers,
Luke.

[Luke Weston]

Also: Re. Nic's comments regarding solid state relays.

Solid state relay:
* Proven to work on Damien's machine using same Proxxon tool without
this issue you describe. (You've got the manual safety lock out switch
too for when working on the tool)
* Easily driven straight from low-current 5V TTL from microcontroller
output.
* High reliability / MTBF since it's solid state
* No clicking noise (not a big deal admittedly)
* Cool solid state bit of silicon
* I've already got one to use.

Electromechanical relay:
* Basically caveman technology....
* Will break eventually... less reliable
* Contact arcing when switching an inductive 240VAC motor?
* Need to go and buy one
* Needs a transistor and resistor and diode added to PCB to drive it.

One should be able to tell which one I'm leaning towards.

[dpgeorge]

> Solid state relay:
> * Proven to work on Damien's machine using same Proxxon tool without
> this issue you describe. (You've got the manual safety lock out switch
> too for when working on the tool)

Yes, it does work on my machine. But not perfectly. Very
occasionally it doesn't turn off, which is probably what Nic was
getting at. It has never turned on spontaneously though. I've not
tried to debug it because it is difficult to reproduce the behaviour.

> Electromechanical relay:

> * Needs a transistor and resistor and diode added to PCB to drive it.

This is the main reason why I didn't use an electromechanical one.
Requires a lot of current (poor 7805!) and a transistor to be driven
from the atmel.

Cheers,
Damien.

[Nic Jones]

I think that a lot of this depends on the desired goals for the
project. If it's just to replicate Damien's machine, then you can
leave out various bits and pieces for the sake of expediency at the
cost of reliability. If the goal is to make an open source CNC
machine, though, there's the implication that people will come along
and build the machine themselves, probably without understanding the
risks involved with choices made at the design stage. The wider a
public reach we expect the design to have, the more I think we're
responsible for trying to make the design as safe as reasonably
possible.

> Solid state relay:
> * Proven to work on Damien's machine using same Proxxon tool without this issue you describe. (You've got the manual safety lock out switch too for when working on the tool)

Again, if the desire to release the design publicly, there's no
guarantee other builders are going to use the exact same rotary tool,
or that their parts are all going to be the same quality as the ones
you've purchased. And it's almost certain that some people are going
to be lazy and work on the mill without cutting the power.

> Electromechanical relay:
> * Basically caveman technology....

Which I consider an advantage. They're a known quantity, and have
been switching current on and off for a long, long time. An SSR, on
the other hand, can suffer from failure modes to do with voltage
spikes damaging the switching transistor, and clearly there are issues
with latch-up and not fully switching off. It's not clear which
brands are high quality and which are rubbish.

> * Will break eventually... less reliable

Everything breaks eventually, but as to "less reliable", I'm not sure
I agree.

> * Contact arcing when switching an inductive 240VAC motor?

Well, snubbers and suitably sizing the relay can overcome this
problem, but ideally the board would have an SSR and a dry-contact
relay. The SSR would be used for speed control, and when it comes
time to switch off the mill, the SSR would bring the speed down to 0
for, say 100ms before the relay is deactivated.

I agree with the rest of your points.

> Yes, it [the SSR] does work on my machine. But not perfectly. Very occasionally it doesn't turn off, which is probably what Nic was getting at

I haven't seen that happen, but that's equally, if not more, scary. I
suspect the particular behaviour depends on the style of SSR (zero-
cross or instant) and whether it uses an SCR or FETs.

> > Electromechanical relay:
> > * Needs a transistor and resistor and diode added to PCB to drive it.
>
> This is the main reason why I didn't use an electromechanical one.
> Requires a lot of current (poor 7805!) and a transistor to be driven
> from the atmel.

The idea would be to use a 24V coil relay. The only current the 7805
would need to supply to switch it on would be the microamps to switch
on the transistor via the MCU.

> What kind of ICSP header pinout on the target device is appropriate? 6 pins, the same as an Arduino? Is that OK?

I prefer the 6-pin if only because it takes up less space. Adapters
aren't hard to come by if you've got a 10-pin programmer.

[michaelc]

On Nov 6, 9:32 am, Nic Jones <nic.l.jo...@gmail.com> wrote:
> I think that a lot of this depends on the desired goals for the
> project.  If it's just to replicate Damien's machine, then you can
> leave out various bits and pieces for the sake of expediency at the
> cost of reliability.  If the goal is to make an open source CNC
> machine, though, there's the implication that people will come along
> and build the machine themselves, probably without understanding the
> risks involved with choices made at the design stage.  The wider a
> public reach we expect the design to have, the more I think we're
> responsible for trying to make the design as safe as reasonably
> possible.

Our highest priority is to get the machine up and running. Our
strategy for achieving this goal is to replicate Damien's design as
closely as possible. In the longer term we'll have much more interest
in improving the machine and making it more suitable for others to
build as well, but that's an issue for the future. There may be
significant redesign of the non mechanical components on the way to
that point, but it is not something we intend to do now if it
interferes with our highest priority short term goal.

Michael

[michaelc]

On Nov 6, 2:21 am, Luke Weston <reindeerfloti...@gmail.com> wrote:

> PS: Who's got an AVR programmer? Mike B, you've got one, right?
>
> What kind of ICSP header pinout on the target device is appropriate? 6
> pins, the same as an Arduino? Is that OK?

I have a programmer we can use. I'd prefer the 10 pin connector
because I don't happen to have a 6 pin cable, but maybe someone else
has one?

Michael Collas

[dpgeorge]

> Well, snubbers and suitably sizing the relay can overcome this
> problem, but ideally the board would have an SSR and a dry-contact
> relay.  The SSR would be used for speed control, and when it comes
> time to switch off the mill, the SSR would bring the speed down to 0
> for, say 100ms before the relay is deactivated.

I just wanted to say that the Proxxon I (and the hackerspace) are
using has inbuilt electronic speed control (good quality speed
control, that's what you are paying for for the model we are using)
and trying to control it's speed by a duty cycle on the 240v power is
probably a very bad idea. Instead, I would suggest hacking into it's
variable speed potentiometer (servo or digital pot).

Cheers,
Damien.

[Michael Borthwick]

On 06/11/2009, at 2:21 AM, Luke Weston wrote:

> PS: Who's got an AVR programmer? Mike B, you've got one, right?

Yes I have a Dontronics DT006 AVR Programmer board http://www.dontronics.com/dt006.html
that I use with PonyProg http://www.lancos.com/prog.html to load (for
example) Arduino bootloader .hex files onto raw ATmega8's and set
their fuses for much win.
This approach needs a parallel port. If you download the schematic
from Don's site you'll see there is not-much-to-it.

Mike Beta

[Nic Jones]

Well, I don't want to work on older copies of the board, so I'll wait
until Luke has a moment to upload his latest work.

It's usually fairly easy to put holes and pads in for more than one
type of relay on top of each other, or to put holes for the transistor
& resistor and have the relay on wires. (The diode would be soldered
directly across the relay terminals) I think the best type of relay is
this sort:
http://www.altronics.com.au/index.asp?area=item&id=S4211
which would be mounted on the panel in the box (if there's room) but
Altronics / Electus / Jaycar only have a 12V version. Rockby might
have something suitable but I haven't checked.
Electus / Jaycar have a 24V DPDT version, but, again, it might be a
bit big:
http://www.electusdistribution.com.au/productView.asp?ID=9249

I've had a quick look at the code now and it's pretty inscrutable.
Impressive, but not really hacker-friendly. Given that this board has
come so far already I think it'd be better to just keep tweaking it to
get things going, and have a second project going to make a new
controller.

Porting / re-creating Damien's work in a more approachable language is
going to come at a performance penalty, and the MCU used in the
current controller is about the highest performance you can get
without going to chips that only come in surface-mount packages. I'd
say that an open-source CNC controller (which I'm quite interested in
working on) is going to need at least an ARM to have all the features
people would like while being programmed in C/C++. I'm going to wait
until my ARM development hardware comes in and I can have a play
before committing to that, though.

The other options are the AVR XMega line, but we're going into those
at work and, again, I want to keep as much separation as possible to
avoid inadvertently allowing open-source effort into closed products.
If somebody wants to use those chips to do a CNC controller I'd not
want to be involved.

There's the parallax propeller, but I'm not sure it'll have the
grunt. It's also expensive and availability is not the best. I
haven't used it.

The highest-performance option is an FPGA. The problem here is that
the tools are, well, shit. I don't think there's an open-source
toolchain at all for FPGAs. Xilinx are a little more Linux-friendly
than Altera, but it's not smooth sailing by any means and Mac users
are SOL. Even using the things on Windows is an unpleasant
experience.

Nic Jones

[michaelc]

On Nov 9, 11:56 am, Nic Jones <nic.l.jo...@gmail.com> wrote:
> Well, I don't want to work on older copies of the board, so I'll wait
> until Luke has a moment to upload his latest work.

Have components already been purchased based on Damien's design? I
know that some have, so there will be some fixed things, but I'm not
sure if all have been purchased.

> I've had a quick look at the code now and it's pretty inscrutable.
> Impressive, but not really hacker-friendly.  Given that this board has
> come so far already I think it'd be better to just keep tweaking it to
> get things going, and have a second project going to make a new
> controller.
>

That code is far from hacker friendly, but that's OK because it suited
Damien's purpose and we have no intentions of hacking it. As
described above, the short term plan is to get a working machine
running as soon as possible - any changes that would involve firmware
or host software changes should probably be ruled out. Damien wrote
his own assembler: I'm not sure if we'll be working from pre-build
binaries or from source.

> Porting / re-creating Damien's work in a more approachable language is
> going to come at a performance penalty, and the MCU used in the
> current controller is about the highest performance you can get
> without going to chips that only come in surface-mount packages.  I'd
> say that an open-source CNC controller (which I'm quite interested in
> working on) is going to need at least an ARM to have all the features
> people would like while being programmed in C/C++.  I'm going to wait
> until my ARM development hardware comes in and I can have a play
> before committing to that, though.
>
> The other options are the AVR XMega line, but we're going into those
> at work and, again, I want to keep as much separation as possible to
> avoid inadvertently allowing open-source effort into closed products.
> If somebody wants to use those chips to do a CNC controller I'd not
> want to be involved.
>
> There's the parallax propeller, but I'm not sure it'll have the
> grunt.  It's also expensive and availability is not the best.  I
> haven't used it.
>
> The highest-performance option is an FPGA.  The problem here is that
> the tools are, well, shit.  I don't think there's an open-source
> toolchain at all for FPGAs.  Xilinx are a little more Linux-friendly
> than Altera, but it's not smooth sailing by any means and Mac users
> are SOL.  Even using the things on Windows is an unpleasant
> experience.
>

My own plans for a rebuild of the non-mechanical components involve
offloading all the grunt work back to the PC where it's much easier to
deal with. We can get away with that quite easily because we have an
open loop system and plenty of bandwidth available. That way, mostly
what we'll need on the milling machine side is something simple enough
to cache a reasonable buffer full of stepping instructions and drive
the stepper driver chips. My calculations suggest that a fairly
regular AVR (I'm planning on at90usb1287 because I happen to have a
spare) should cope fine providing we're careful with the
communications protocol. At present I'm considering G-code
interpretation and rendering to be solved problems, so for me
personally solving those problems again would be quite a diversion
(albeit an interesting one) from my other goals. Having said that, if
you're up to making an ARM version that does the rendering in
firmware, that would be interesting to see too.

Michael

[dpgeorge]

By way of background info, the current firmware I have written accepts
the following high-level commands from the PC:

IDLE, SLEEP(millisec), STEPPER_CTRL(on/off), DRILL_CTRL(on/off)
SET_XY_SPEED(mm/s), SET_Z_SPEED(mm/s)
MOVE_TO_XY(x,y), MOVE_TO_Z(z), MOVE_TO_XYZ(x,y,z)
MOVE_PARAMETRIC_PATH(t_start,t_end,x(t),y(t),z(t))
INTERP_BYTE_CODE(bytes)

Hopefully that is self-explanatory :) The BYTE_CODE argument is made
up of a string of bytes of the following commands (which are 1 byte
each):

BC_END
BC_STEP(direction, number_of_steps)
BC_XY_SPEED(mm/s)
BC_Z_SPEED(mm/s)

These commands are sent over the USB/UART converter to the AVR, and
are stored in the RAM on the AVR in a double buffer of 512 bytes.
Here, they are processed by the AVR until the buffer runs out. Double
buffering means that the PC can fill one of the buffers while the
other is being interpreted.

> My own plans for a rebuild of the non-mechanical components involve
> offloading all the grunt work back to the PC where it's much easier to
> deal with. We can get away with that quite easily because we have an
> open loop system and plenty of bandwidth available. That way, mostly
> what we'll need on the milling machine side is something simple enough
> to cache a reasonable buffer full of stepping instructions and drive
> the stepper driver chips.

What you want to do is already implemented in my firmware using the
INTERP_BYTE_CODE command. But of course, if you only want to use this
command, then my firmware can be simplified dramatically! And I
encourage you to write your own version (for fun!).

The main problem is bandwidth from PC to microcontroller, and RAM on
microcontroller. If I want to cut out a shape described by, say, 10
straight line segments, then I can do it with the above MOVE_TO
commands in about 1000 bytes or so. This corresponds to two 'packets'
of 512 bytes maximum each sent to the AVR. Cutting out the shape
might take 5 minutes, so most of the time the PC-AVR comms link is
idle (and so is the PC).

If you wanted to cut out such a shape (or any shape) using
INTERP_BYTE_CODE commands, you would need much more data to be
transferred. Some typical numbers would be:
max_step_freq = 24kHz
bytes_per_step = about 1 (difficult to estimate. you need to send a
BC_XY_SPEED command often to get smooth curves, but sometimes you can
do multiple steps with one BC_STEP command)
That means you need to send about 24 kbytes/s. Bandwidth (of USB or
UART) is not really a problem. The problem would probably be draining
the buffer on the AVR if the PC is busy multitasking. You could quite
easily imagine your PC CNC control program pausing for 1 second while
some Java ap in firefox is running (for example). To protect against
a 1 second pause at the PC side, you need a buffer of 24 kbytes on the
AVR. Maybe you can do this with external RAM.... otherwise you will
need to be very strict with what you can run on the PC which is
controlling the machine (or compile a linux kernel with special
options set).

I think it is worth trying to solve these problems with the byte
code. If you just have the microcontroller doing low-level byte code
movement, then you can use EMC (www.linuxcnc.org) to control the
machine, which can do g-code and all that.

Cheers,
Damien.

[andyg (@geekscape)]

hi All,

On Nov 10, 1:00 am, dpgeorge <damien.p.geo...@gmail.com> wrote:
> By way of background info, the current firmware I have written accepts
> the following high-level commands from the PC:

Thanks for the details.

I've created a new shared Google Doc for the "CNC milling machine
firmware" ...
http://docs.google.com/Doc?docid=0AQn57C-zoS-lZGdyYmh4Ml83Y250cW41ZGg&hl=en_GB

I've copied the main firmware commands description from Damien's email
into this document.

It would be good to keep updating this Google Doc as more information
is provided / discovered.

I've updated the main CNC milling machine project page accordingly
(with a link to the document and updated status).

cheers andyg (@geekscape)

[Luke Weston]

I have pushed the CNC microcontroller board over to github... so you
should all be able to check it out.

I'm going to merge the off-list email discussion we were having
tonight with this post... I see no reason not to. (Sorry, if anyone
objects!)

http://github.com/lukeweston/CNCMachine/raw/master/microcontroller-board.pdf

http://github.com/lukeweston/CNCMachine/blob/master/microcontroller-board.png

We've got a FT232RL chip integrated onto the same board with the
microcontroller.
We've also got the 7805 integrated into the same board, so except for
the A3977s it's an integrated one-board solution.

What I've imagined is that we ultimately make 3 x 6-wire cables (for
the stepper controller digital lines) and 3 x 3-wire cables (power to
the stepper controllers) with simple "straight through" wiring, with
those 0.1" Molex KK style locking header plugs, and then you just plug
them all in and it just works. You just bring in the 24V from the
power supply onto this board with one pair of wires.

A transistor to drive an electromechanical relay with 24V coil is
incorporated to turn the drill on and off.

All the A3977 controller lines are on microcontroller port C, and all
the enable and reset lines are tied together... some simple
improvements to tidy it up a little bit as Damien suggested in a post
in the past.
This means that some simple firmware changes are required in regards
to the mapping of a particular function onto a particular IC pin...
but as Damien said, this is not a problem. It's just digital output,
and it's not using a hardware device on the IC (such as UART or
similar) so it's a simple firmware change as it should be for any
microcontroller system to remap the pins. (There's a past post where
Damien discussed some of this stuff, can't find it at the moment.)

The x, y and z limit switch signals, the emergency stop, and a signal
to turn off the IR LEDs, plus 5V and ground go out to a header where
they will run, ultimately, to the machine optocouplers.
There may be some pull-up resistors on those lines and current
limiting resistors for the LEDs needed... I'll just put those on the
machine-mounted breakout board.

The emergency stop signal should be pulled down with a resistor and
tied high by a normally closed switch. (Or vice versa logically, but
the key point is that the stop switch is a NC switch.) That way it is
fail safe if you unplug it or a wire breaks or something.

A lot of the spare microcontroller pins are bought out to pads - so
this can be used for ICSP, or future hacking, modding or expansion.

>> I've got single sided Kinsten I'm happy to use for this board. I'd prefer to expose and etch the board at home though, because that's where I have the things to support my process - chemicals, running water, microwave, and
>> other random tools.

Well, I'll let everyone have a look first and allow a little time for
feedback, but if we're happy with it and you're happy with it, and
you're happy to go and fabricate it yourself when you have a chance,
that's great, I'd appreciate it, and you can just give it to me the
next time I see you or something and I'll populate it. I used 0805
SMDs since Mike B. said he's got those, and I had originally used
0805s anyway, so I didn't need to change it :)

Thanks,
Luke

[Andy Gelme]

hi All,

Luke Weston wrote:
> You just bring in the 24V from the power supply onto this board with one pair of wires.

Spending of which ... Pete has the 24V power supply.

I'll grab it from him on Friday ... and it'll be ready for any action
over the weekend.

--
-O- cheers = /\ /\/ /) `/ =
--O -- http://www.geekscape.org --
OOO -- an...@geekscape.org -- http://twitter.com/geekscape --

[Nic Jones]

If you make R1 a through-hole resistor you'll have a much better path
for the ground between the 24V power terminal and the 7805. As is the
path goes half way around the board and via a tiny track near the
FT232RL. I'd probably still leave the jumper in the circuit, though.

There's a junction in the 5V track near the 7805 that has two tracks
meeting at ~45º. The track is thick enough that it probably doesn't
matter, but I try to avoid angles <90º because the etchant can build
up in the V and eat away at the junction.

You could move the 5V track at the top of the board a little higher to
give the ground out the molex connectors a bit more thickness.

It's looking pretty good though.

Nic Jones

[michaelc]

> This means that some simple firmware changes are required in regards...

Do we have a working version of Damien's assembler? I wasn't sure
about that - I think Andy knows. I'd rather avoid firmware changes if
they're not absolutely necessary, even if they seem like small things
that shouldn't ever go wrong. Last minute changes based on assumptions
about what will be simple are the sort of thing that tends trips up
complex software, especially when the code is unfamiliar and doesn't
have good test coverage.

> The emergency stop signal should be pulled down with a resistor and
> tied high by a normally closed switch. (Or vice versa logically, but
> the key point is that the stop switch is a NC switch.) That way it is
> fail safe if you unplug it or a wire breaks or something.

Anyone have access to Damien's code know which way it has it? NC
switch? Active high with an external pull down, or active low with the
micro's internal pull up?

> Well, I'll let everyone have a look first and allow a little time for
> feedback, but if we're happy with it and you're happy with it, and
> you're happy to go and fabricate it yourself when you have a chance,

Yep, we can let things settle for a bit. We've got enough other work
in the pipeline for a while yet: complete mechanics, complete and
install stepper drivers, and align the machine (probably quite a slow
task). It's less glamorous than a shiny new board, but we can do it
all first or in parallel because none of it depends on the controller
board.

[Andy Gelme]

hi Michael,

michaelc wrote:
> Do we have a working version of Damien's assembler?

On the Linux system in the HackerSpace, is a copy of the firmware
source, assembler and linker. Before Damien left, he went through the
process with me ... and that Linux system has successfully built the
firmware.

> I'd rather avoid firmware changes if they're not absolutely necessary

It would be good to start with the original as a baseline, prior to
making any modifications (unless it is something essential, like a
different pin-out).

> Anyone have access to Damien's code know which way it has it? NC
> switch? Active high with an external pull down, or active low with the
> micro's internal pull up?

Let's check on Sunday.

[Luke Weston]

Minor revisions have been made and pushed to GitHub, as per Nic's good
suggestions above.

[dpgeorge]

> Do we have a working version of Damien's assembler? I wasn't sure
> about that - I think Andy knows. I'd rather avoid firmware changes if
> they're not absolutely necessary, even if they seem like small things
> that shouldn't ever go wrong. Last minute changes based on assumptions
> about what will be simple are the sort of thing that tends trips up
> complex software, especially when the code is unfamiliar and doesn't
> have good test coverage.

I left you with a working version of the build chain tools, so that
you can modify and compile the firmware yourselves. If you want, I
can make modifications for you and send you the assembly code. This
is probably much easier for me to do because I know the code well.

> > The emergency stop signal should be pulled down with a resistor and
> > tied high by a normally closed switch. (Or vice versa logically, but
> > the key point is that the stop switch is a NC switch.) That way it is
> > fail safe if you unplug it or a wire breaks or something.
>
> Anyone have access to Damien's code know which way it has it? NC
> switch? Active high with an external pull down, or active low with the
> micro's internal pull up?

Looking at my code now, it says: SENS_EMG on port B0, active low
input, internal pull-up resistor enabled. Uses pin change interrupt
to detect any changes of the logic level of the pin.

IR sensor power: IRPOW on port B1, active low output.
IR sensors: IRX, IRY, IRZ on port B2, B3, B4 respectively, active low
input with internal pull-up resistor enabled. Uses pin change
interrupt to detect changes.

A3977 control logic on port C:
C0 = common reset
C1 = common enable
C2 = x-dir
C3 = x-step
C4 = y-dir
C5 = y-step
C6 = z-dir
C7 = z-step

These things are easy to change. I think maybe you guys don't have
the latest version of the firmware with these assignments. Check the
file a3977.s.tl, near the top of the file it should have these (or
other) assignments. I will get a tarball of code ready for you with
these latest changes.

Cheers,
Damien.

[andyg (@geekscape)]

hi All,

On Nov 12, 9:12 pm, dpgeorge <damien.p.geo...@gmail.com> wrote:
> I left you with a working version of the build chain tools, so that
> you can modify and compile the firmware yourselves.  If you want, I
> can make modifications for you and send you the assembly code.  This
> is probably much easier for me to do because I know the code well.

Just to re-confirm ... Yes, I do have the working version that Damien
left us (on the Linux system in the garage).

The date/time stamp on the files is 2009-08-02.

$ cksum a3977.s.tl
718023613 4864 a3977.s.tl

> These things are easy to change.  I think maybe you guys don't have
> the latest version of the firmware with these assignments.  Check the
> file a3977.s.tl, near the top of the file it should have these (or
> other) assignments.  I will get a tarball of code ready for you with
> these latest changes.

Yes, the file does have the pin assignments.

Could you please start including version numbers at the top of each
source file ?
It'll make future discussions about "which version are you running ?"
much easier !

If you email me the tar-ball, I'll update the "cnc-controller" on our
system.

cheers andyg (@geekscape)