Contraptor

Sure, I can try it out (as is on your sketch) if you include it.

Thanks for the quick reply!

Rethinking my future requirements, I'm aiming at minimum (woodwork) dimensions of 30"x18"x5" (LxWxH).

However, even using the RepRap motors, the CNC would be much faster than I doing the routing, carving, cutting, rounding, etc. manually.
Of course the larger the CNC, the more power is required to move the router.
I have no clue whether the motors are powerful enough to move almost twice the weight.

I'm pretty skilled in software dev. - Do you think, the arduino hardware is not capable of handling larger motors, or is this a pure driver (software) issue?

A few more points:
Is there any info on how well the transformation from CAD-format (e.g. dxf) to G-Code works? - I had a look at the specs and there're also codes for changing the CNC tools etc. I'm curious if this actually works with the Contraptor/RepRap software stack.

Has anybody of you guys ever tried using models generated in Blender with Contraptor?

Have you considered using Contraptor to reproduce itself (metal CNC'ing itself).

schoeftinger

Your dimensions should be "doable" however there would be quite a bit of tweaking here and there to be done. Sorry for the confusion but when I refer to a stepper driver I am referring to the PCB board that "drives" or "powers" the motor. Like this, http://www.thingiverse.com/thing:760

I have never used blender to design stuff. Google Sketchup works very good for our purposes. Perhaps when we create an contraptor extruder blender will be required.

For metal CNC'ing. YES! very much so. :) In fact Vitaly created a contraption for making the angle you can see it here: http://www.garagefab.cc/contraptor/what-can-be-built/perforaptor Its older and from what I remember it didnt really work super great but hey its a start. There are also a few other options. Like, getting a proxxon rotary tool instead which is suppose to be more powerful etc. And lastly you would need to slowly remove material in small steps. Not like a giant 1/4" thick cut at a time like you can do with mills etc.

Personaly I have not converted any DXF to Gcode but I think you can look on the reprap forums or post there for input.

Hope that answers a few questions. Thanks for being active in the contraptor community. Let use know / see what you build. We are attempting to grow a list of contraptions!

Ril3y

More powerful motors would require more powerful driver boards (like Geckos as James mentions below). The driver board interface is typically simple: digital pulse steps the motor, so in principle Arduino should be able to control the boards. Cdegroot mentioned inexpensive 3-axis board (Xylotex) in another thread, maybe he'll try it with Arduino :)

To go from DXF to G-Code, you need CAM software. I've been using CamBam recently and there are other free/open source alternatives out there too. Once I have functional mini CNC, I hope to get to documenting the software chain. Arduino G-code interpreter supports very basic subset of G-Code - straight lines, circles, pauses. No advanced stuff like tool changing (you'd need a tool changer for that too:).

As far as Blender - we'd love to see Contraptor components converted to other 3D formats since not everyone prefers Sketchup. Blender, being open source, would be a great start.

Hi again,

thanks - I'll need the luck! ;-)

I've already had a look at the other contraptions - including your mini router.
Why did you change the design for your cnc so radically? - Stability?

Besides that, I'm struggling with ideas how to fix the workpiece to the cnc table, while routing.
Large CNCs kind of suck the workpiece and therefore don't require additional clamps, etc..
However, when using clamps the workpiece might start moving around on the cnc table (once the part of wood where the clamp is fixed is cut off).
Neither is it feasible to attach a clamp somewhere at the center of the workpiece or attach it from beyond (using screws or whatever means).

How to you fix your work pieces on the mini cnc?

Before starting some actual work, I think I'll need to clarify a few more issues, such as this.

Another thing: given your response times, I assume you guys are either American night owls or europeans, right?
I'm asking because it appears that you support each other with building your contraptions…
BTW, I'm in Austria

Hi Schoeftinger,

I'm simply trying different designs, T-slot is useful with larger sizes and it is also faster to build with. On the other hand it's more expensive than angle so there isn't as much flexibility in trying different designs. One of the goals for this particular design above was to build a mini CNC router for cutting 12"x24" size of plywood/MDF/acrylic with Dremel/Proxxon.

Regarding workpiece clamping - with the mini-router, I milled the material in shallow passes - about 1/32" - so the cuts were gradually made deeper without disconnecting the milled part. Deeper passes are difficult for Dremel anyway, and this allows the workpiece to be clamped at the corners. The table can have the grid of holes drilled and tapped for clamping screws.

I can't speak for everyone here but Riley and I are American night owls, correct :)

Good… then on with the questions. ;-)

On the reprap page (http://reprap.org/bin/view/Main/Generation3Electronics) I saw that they have a new mainboard (V1.2) and new stepper drivers (2.3).
Do you actually use the original reprap board or is your arduino board something else?

The reprap site says, the new stepper driver can control motors up to 2A.
I'd select the following NEMA 23 motor:
http://uk.farnell.com/jsp/displayProduct.jsp?sku=4743167&CMP=e-3e6f
Do you think this particular motor may be powerful enough?

Since buying multiple sets of hardware will become very costly, I'd be happy to choose appropriate hardeware from the beginning.
Please let me know, if you have better motor/stepper driver proposals…

As soon as I have a shopping list, I'll sort out the total costs and go on…

Thanks for all your input!

Hi Schoeftinger,

We're currently using Reprap v1.2 Stepper Driver Boards to drive stepper motors and Arduino as controller. We have not tested Reprap v2.3 stepper board with Contraptor steppers - so I can't really say that they work, but unless overheating of the board is an issue, they should.

The motor you linked has higher torque than Reprap recommended one, but also higher resistance/rated voltage (8V) which makes me wonder whether the stepper board (either v1.x or v2.x) will have enough power to drive this stepper. Usually steppers are driven at significant overvoltage - for example Contraptor steppers are rated for 2.3V while PC power supply puts out 12V.

If you're looking at the above 80/20 sketch, my wild guess is that torque rating around 150-200 oz*in would be needed to move the gantry with more or less decent speed. This would require more powerful stepper board. Please don't hold me to this number though :)
Y and Z motors on the contrary would not need to be as powerful, so if you needed to upgrade, it would likely be for one motor/board set.

My preference in an unknown situation is to start with something cheaper and upgrade as needed, but that's me.
Alternatively, you could estimate the power you'd need based on the estimated weight of the gantry and your desired speeds and accelerations.

Yes, Your summary is accurate.

The Cubespawn projects goals are to:
Provide a starting point for a bootstrapped manufacturing facility, with open source versions of the main (existing) manufacturing techniques to be added over time. (flexibility is desired over capacity) Like Vacuum Forming, pick and place, CNC routing/milling - and perhaps someday: Aluminum re-melt (induction/arc furnace) plastic re-grind - plastic or aluminum extrusion, on and on…

To keep part counts as low as possible - if it has to make its own parts, then re-useing components and short BOMs are important.

To add a library of parts to make whatever is needed over time and share that as open source designs.

To do it at a reasonable cost - there is more to it than that, but…

There are two main (percieved) benefits to the cube approach…
Mechanical:
Structural ridgidity from a relativly lightweight frame, also modularity - its not clear on the site yet, but it incorporates a pallet handler at the base, power, network, motion control in a small package - I have started with the 1/2 meter version to control costs while prototyping - but most designs will scale up well.

Form Factor:
If designers have a standard to build to, and the completed designs are modular, everybody wins for usability - anything I design, you can use - and if you contribute your designs, I (or anyone else) can then use them, but more important, if you design a Vacuum former, it'll bolt up to my router so you can form and trim-out parts in one process.
This is an open ended system, no constraints except working envelope - but, at the same time, it retains the benefits of standardization.

One thing to note - the cube form makes it harder to access the workpiece, but a second (open) frame for loading/unloading the pallet solves this, and, really, the goal here is automated handling - so its not intended to work like an open CNC table….

I hope this answers your questions, if you have any more, I'll do my best to answer them ;-)

James

Hi Christoph,

Before checking anything, rule out the EM interference from motor wires. I try to route logic wires as far as I can from the motor wires:

Ideally, the logic wires need to be very short. This is the shortcoming of the current electronics kit, which is meant as an upgradeable starting point for trying things out.

I ran the same code on my mini CNC. Before it worked, I had to manually (via serial terminal) ensure that:

• metric units are selected (G20G21)
• absolute mode selected (G91G90)
• zero is set (G92 X0 Y0 Z0)

Another difference is that my mini CNC currently has ACME leadscrews on X and Y which move the stages 0.25" per revolution, but I don't think this should affect anything as long as the feedrates are within the range of all-thread screws.

I also have to add that once I upgraded to Arduino Duemilanove from Diecimila, I could not reproduce the problem that I posted above.

The pen was bending a bit, so some lines are not quite straight. An interesting thing is that "e" is rendered with an extra circle around the letter (see the large inch version). I'm not sure whether this is in the GCode or if it's interpreted that way.

Some observations:

• GCode Interpreter can't process several G commands on one line. There is a line in the beginning of the file, switching to metric and absolute mode on one line. That command probably has no effect on the interpreter.
• I saw problems with feedrate and units after switching between metric and imperial. As if the next command after switch is still executed in previous mode. Sometimes it looks like feedrate value is taken from another system (too slow in metric mode and too fast in imperial mode). To add to the complexity, there are 2 values of the feedrate - current (supplied via F code) and fast (used with G0 moves). All of this looks like a problem in the interpreter and needs more research.
• The feedrate should not exceed bot capabilities, otherwise the motors will stall and lose the position. Depending on your friction, flywheels, alignment, the upper limit should be about 15 IPM for all-thread leadscrew. 20 IPM was unreliable in my tests. Sometimes a stall might happen in the normal speed envelope (probably due to vibrations/noise) but it's rare from my experience.
• Default setting for fast feedrate (G0) in the firmware may be too fast. It was in my case and the motors stalled on a couple of G0 moves. This can be fixed by restricting the fast XY feedrate in the firmware.
• After the gcode file is completed and if units are changed (G20 or 21), the bot often responds to the next command unpredictably. For example the command would be "G1 X1", but all 3 axes would start moving in unexpected direction. I wrecked a Shapie fine point that way :( I'm not sure why this happens, but again, I think it's something in the interpreter/arduino as everything works fine after reset.

So, in summary:

Assuming that the interference is ruled out, I think the problem is most likely that the bot was running in relative mode - i.e. every supplied XY coordinate is treated as offset from current position, as opposed to absolute target coordinate. This is the default mode and the switch to absolute never takes place because the absolute mode command (G91) is on the same line with metric mode command (G21, first line in your file).

Also, the feedrate used (4 and 8 mm/min) seems to be too slow, which probably adds to the impression that the bot is doing something strange. You might want to regenerate the file (or search/replace) with faster feedrate (say, 250 mm/min).

I also looked at the interpreter code yesterday and I think I tracked down the problem with switching between metric and imperial modes. I'm going to try some modifications and see if they fix it.

I'm getting complete unpredictable results. This should be a hint to interferences. Have a look at my wiring:
The cables from arduino to the stepper boards are shorter than showed in the picture above. The distance to the cable of the stepper motors are as far as possible also to the cables of the PC power supply. Also I separated the perf bord for the PC power supply from the Mini CNC frame. The next step would be to make a complete EMF isolation.

Beside that I will post step by step what I have done.

• I changed my firmware settings in init.pde to

//our maximum feedrates in units/minute
#define FAST_XY_FEEDRATE_INCH 15 //300
#define FAST_Z_FEEDRATE_INCH  15
#define FAST_XY_FEEDRATE_MM 360
#define FAST_Z_FEEDRATE_MM  360

• I changed all the speed settings for the F commands to 180.0

• I changed the beginning of my GCode file to

G21 (metric units)
G91 (incremental mode)
G92 X0 Y0 Z0 (set zero)

• I removed all commands from the GCode file, which gives something like "Huh? M3" (G17, G64, T0 M6 etc.), but not at the very end M5 M30, which should also give a "Huh?" response. (Being in incremental distance mode has no effect on the action of G92. see http://www.linuxcnc.org/handbook/RS274NGC_3/RS274NGC_33a.html#1015878

• I made a reset several times. After that I powered the PC power supply and send via serial the GCode file.

My environment is a Arduino Duemilla and Arduiono 0018.

Conspicuous is, that I don't get any "Huh?" responses from the last both commands, also the Z axis is moving up only in the beginning, afterwards there are no more movements. It looks like some (most) commands are not executed by the Arduino firmware.

Please post your GCode (maybe just for the letter "H") and all your step by step instructions, how you got it run!

Hmm, even with interference, you should get some movement from X and Y. I'm assuming limit switches are wired correctly. Also I'm assuming that Arduino is Duemilanove, since you shouldn't be able to fit this code in Diecimila.

I actually ran your file as it is (only search/replacing the feedrate value in F commands). Prior to running, via serial terminal, i set the interpreter to metric (G20G21), then absolute mode (G91G90) and then zeroed the origin (G92 X0 Y0 Z0), then ran the file.

What is your acceleration settings from _init.pde?

Regarding the "Huh? <cmd>" response, I noticed that sometimes it seems to be out of order, but I haven't looked at the problem closely.

P.S. Sorry for the confusion above, I mixed up G20 with G21 and G90 with G91.

I get movements from X and Y but just one from Z. The limit switches are working correctly. And I am using Duemilanove (included in the set).

Here is my complete init.pde:

// define the parameters of our machine.
// belt drive
//#define X_STEPS_PER_INCH 200.0
//#define X_STEPS_PER_MM   7.874

// all thread leadscrew
#define X_STEPS_PER_INCH 8000.0
#define X_STEPS_PER_MM   314.961

// ACME leadscrew
//#define X_STEPS_PER_INCH 6400.0
//#define X_STEPS_PER_MM   251.968

#define Y_STEPS_PER_INCH 8000.0
#define Y_STEPS_PER_MM   314.961

#define Z_STEPS_PER_INCH 8000.0
#define Z_STEPS_PER_MM   314.961

//our maximum feedrates in units/minute
#define FAST_XY_FEEDRATE_INCH 15 //300
#define FAST_Z_FEEDRATE_INCH  15
#define FAST_XY_FEEDRATE_MM 360
#define FAST_Z_FEEDRATE_MM  360

// Maximum acceleration in units/minute/second
// E.g. for 300.0 machine would accelerate to 150units/minute in 0.5sec etc.
#define MAX_ACCEL_INCH 50.0 //500.0
#define MAX_ACCEL_MM 1200.0

// Maximum change in velocity per axis - if the change in velocity at the start
// of the next move is greater than this for at least one axis, we will decelerate
// to a stop before commencing the move, otherwise we will keep going
// value is units/minute
#define MAX_DELTA_V_INCH 5.0
#define MAX_DELTA_V_MM 100.0

// Set to one if endstop outputs are inverting (ie: 1 means open, 0 means closed)
// RepRap opto endstops are *not* inverting.
#define ENDSTOPS_INVERTING 1

// Optionally disable max endstops to save pins or wiring
#define ENDSTOPS_MIN_ENABLED 1
#define ENDSTOPS_MAX_ENABLED 1

// How many temperature samples to take.  each sample takes about 100 usecs.
#define TEMPERATURE_SAMPLES 5

// The *_ENABLE_PIN signals are active high as default. Define this
// to one if they should be active low instead (e.g. if you're using different
// stepper boards).
// RepRap stepper boards are *not* inverting.
#define INVERT_ENABLE_PINS 0

// If you use this firmware on a cartesian platform where the
// stepper direction pins are inverted, set these defines to 1
// for the axes which should be inverted.
// RepRap stepper boards are *not* inverting.
#define INVERT_DIR 1 // CHANGED CM - ONLY ONE FOR ALL AXES

#define STEPPERS_ALWAYS_ON 0

/****************************************************************************************
* digital i/o pin assignment
*
* this uses the undocumented feature of Arduino - pins 14-19 correspond to analog 0-5
****************************************************************************************/

//cartesian bot pins
#define X_STEP_PIN 3
#define X_DIR_PIN 4
#define X_ENABLE_PIN 5
#define X_MIN_PIN 6
#define X_MAX_PIN 7

#define Y_STEP_PIN 8
#define Y_DIR_PIN 9
#define Y_ENABLE_PIN 10
#define Y_MIN_PIN 11
#define Y_MAX_PIN 12

#define Z_STEP_PIN 14
#define Z_DIR_PIN 15
#define Z_ENABLE_PIN 16
#define Z_MIN_PIN 17
#define Z_MAX_PIN 18

//extruder pins
// NOTE - USING Timer1 FOR STEPPER TIMER SO CAN'T USER PINS 9 OR 10 FOR PWM
// OUTPUT (EXTRUDER_MOTOR_SPEED_PIN, EXTRUDER_HEATER_PIN, OR EXTRUDER_FAN_PIN)
#define EXTRUDER_MOTOR_SPEED_PIN   19
#define EXTRUDER_MOTOR_DIR_PIN     19
#define EXTRUDER_HEATER_PIN        19
#define EXTRUDER_FAN_PIN           19
#define EXTRUDER_THERMISTOR_PIN    -1  //a -1 disables thermistor readings
#define EXTRUDER_THERMOCOUPLE_PIN  -1 //a -1 disables thermocouple readings

The _init.pde looks correct.

So, what happens if you update the feedrate in your file, replace "G21 G90 G64 G40" line with the following:

G21 (mm)
G90 (absolute)
G92 X0 Y0 Z0 (zero to current position)

and send the file to interpreter? Can you take a video?

Christoph,

I forgot to ask one question - what are you using to send GCode file to the interpreter? The thing here is that the host software should wait for the "ok" response from the interpreter before sending next command, otherwise the commands get lost etc.

Sorry, I should have documented this. I added a Python script which can be used to send GCode file to the interpreter in this manner: http://www.contraptor.org/motion-control

Hi Vitaly,

just at the moment I'm uploading several videos which are showing all strange results. I did the uploads of the GCode files with cutecom, which of course doesn't wait for the 'ok' responses. This should be the explanation for the strange results. I will test the python script and will post the outcome.

Thanks for that hint.

YEAH!!! Thanks, that's it! :-D

The photo shows something what is hard to read as "Hello World" because the pen bended. But now it's working.

All the time I wondered, whether Arduino firmware has a storage or routine which waits for the 'ok'. My fault, maybe I have been to narrow minded.

Oh I think it's a documentation omission. Right now it sounds as though you can send a file from terminal, which is not the case. I've been meaning to write a simple client in Python allowing user to jog the machine, switch units, have current position readout, as well as to open or copy-paste GCode for execution.

Today I made my first engraving :-). It's a "Happy Easter" wish. the hight of one letter is about 1.5 cm which is about 0.6". What I realized is, that the working piece isn't in an exact right angle to the Z axis and there seems to be some failures in circle drawings like for the "e". Also there are three unmotivated circles in the lower right, which didn't apear in CncSimulator. But nevertheless I'm happy to get the machine working :-D

Here you can see the beginning of the engraving.

In case of "e", the interpreter is drawing a full circle where it only needs to draw a small segment:

G1 X2.8045 Y1.4874
G3 X2.8894 Y1.2057 I0.8737 J0.1096

My guess is that the inaccuracies in other letters ("o","k","b") and extra circles in your engraving have the same root cause.

What I have engraved is

"Frohe
Ostern
liebe Vesna"

The letters which went wrong are marked bold. The root cause seems to be, that there are failures in the Arduino firmware, which misinterpret circles and parts of circles.

I will do some testings in it.

I think I fixed the problem:

In process_string.pde, find the following fragment:

      // Must reverse if dominant sign is negative and clockwise, or positive and counterclockwise (which is the same as dominantSign != direction)
      if (dominantSignTbl[startOctant] != arcDirection) stepOffset = -stepOffset;

and replace it with the following:

      // Must reverse if dominant sign is negative and clockwise, or positive and counterclockwise (which is the same as dominantSign != direction)
      // Must count backwards in sign table for counterclockwise
      if (dominantSignTbl[(arcDirection == ARC_CLOCKWISE) ? startOctant : 7 - startOctant] != arcDirection) stepOffset = -stepOffset;

It fixed the problem with "e" in my tests and I think should also fix the other problems with arcs. I'll upload the updated code to Sourceforge.

Today I tested these changing on process_string.pde. The arcs are looking much better, but all movements towards +X seem to have a -X component.

This is how it should look like:

And this is what I got:

Here is a video of the milling:

Hmm. Can you post the GCode from this example?

Here it is:

( Made using CamBam - http://www.cambam.co.uk )
( e-circles 4/10/2010 1:23:46 AM )
( T0 : 0.0 )
G21 
G90 
G64 
G40
G92 X0 Y0 Z0 (set zero)
G0 Z1.5
( T0 : 0.0 )
T0 M6
( Engrave1 )
G17
M3 S0
G0 X17.6075 Y35.6797
G1 F100.0 Z-0.5
G1 F200.0 X21.4068 Y35.2654
G2 X20.1819 Y32.7363 I-9.0526 J2.8233
G2 X18.0773 Y30.7072 I-6.54 J4.6773
G2 X15.1243 Y29.4444 I-4.7414 J7.0037
G2 X11.8677 Y29.0857 I-2.9605 J11.9147
G2 X7.7803 Y29.6697 I-0.3853 J11.899
G2 X4.31 Y31.6621 I2.4791 J8.3368
G2 X2.1243 Y35.0552 I6.0574 J6.3024
G2 X1.532 Y38.9227 I12.7433 J3.9306
G2 X2.1286 Y42.9079 I14.0281 J-0.063
G2 X4.3508 Y46.4175 I8.5166 J-2.9342
G2 X7.6794 Y48.45 I6.1647 J-6.3539
G2 X11.6635 Y49.084 I3.6279 J-9.9636
G2 X15.5393 Y48.4587 I0.3433 J-10.1968
G2 X18.7718 Y46.4716 I-2.8213 J-8.2124
G2 X20.9465 Y43.0285 I-6.1748 J-6.3083
G2 X21.5294 Y39.1209 I-13.2192 J-3.9692
G2 X21.509 Y38.2561 I-32.37 J0.3319
G1 X5.3313
G3 X5.8549 Y35.6831 I9.9322 J0.6816
G3 X7.3535 Y33.4277 I5.7532 J2.1971
G3 X11.8881 Y31.7522 I4.14 J4.2305
G3 X15.3402 Y32.689 I0.3404 J5.5742
G3 X16.7206 Y34.0389 I-2.9329 J4.3799
G3 X17.6075 Y35.6797 I-7.0816 J4.888
G0 Z1.5
G0 X29.5284 Y38.6416
G1 F100.0 Z-0.5
G1 F200.0 X39.2186
G3 X38.9042 Y40.1621 I-7.6857 J-0.7967
G3 X38.1074 Y41.5387 I-3.7855 J-1.2722
G3 X34.4634 Y43.0376 I-3.3263 J-2.9075
G3 X31.0481 Y41.8413 I-0.2988 J-4.6203
G3 X29.9468 Y40.3676 I2.9347 J-3.3414
G3 X29.5284 Y38.6416 I5.236 J-2.1831
G0 Z1.5
G0 X39.1859 Y34.4474
G1 F100.0 Z-0.5
G1 F200.0 X42.2254 Y34.1159
G2 X41.2455 Y32.0927 I-7.2421 J2.2587
G2 X39.5618 Y30.4694 I-5.232 J3.7418
G2 X37.1993 Y29.4592 I-3.7931 J5.6029
G2 X34.5941 Y29.1722 I-2.3684 J9.5318
G2 X31.3242 Y29.6394 I-0.3083 J9.5192
G2 X28.5479 Y31.2333 I1.9833 J6.6694
G2 X26.7993 Y33.9478 I4.8459 J5.0419
G2 X26.3255 Y37.0418 I10.1947 J3.1445
G2 X26.8028 Y40.23 I11.2225 J-0.0504
G2 X28.5806 Y43.0376 I6.8133 J-2.3473
G2 X31.2434 Y44.6636 I4.9317 J-5.0831
G2 X34.4307 Y45.1708 I2.9023 J-7.9709
G2 X37.5314 Y44.6706 I0.2746 J-8.1574
G2 X40.1174 Y43.0809 I-2.257 J-6.5699
G2 X41.8571 Y40.3264 I-4.9399 J-5.0467
G2 X42.3234 Y37.2003 I-10.5754 J-3.1754
G2 X42.3071 Y36.5085 I-25.896 J0.2656
G1 X29.3649
G3 X29.7839 Y34.4501 I7.9457 J0.5452
G3 X30.9827 Y32.6458 I4.6026 J1.7577
G3 X34.6104 Y31.3053 I3.312 J3.3844
G3 X37.3721 Y32.0548 I0.2723 J4.4593
G3 X38.4764 Y33.1347 I-2.3464 J3.504
G3 X39.1859 Y34.4474 I-5.6653 J3.9104
G0 Z1.5
G0 X49.3379 Y36.3608
G1 F100.0 Z-0.5
G1 F200.0 X56.6056
G3 X56.3697 Y37.5011 I-5.7643 J-0.5975
G3 X55.7722 Y38.5335 I-2.8392 J-0.9542
G3 X53.0391 Y39.6578 I-2.4947 J-2.1806
G3 X50.4776 Y38.7605 I-0.2241 J-3.4653
G3 X49.6517 Y37.6553 I2.201 J-2.506
G3 X49.3379 Y36.3608 I3.927 J-1.6373
G0 Z1.5
G0 X56.581 Y33.2151
G1 F100.0 Z-0.5
G1 F200.0 X58.8606 Y32.9665
G2 X58.1257 Y31.449 I-5.4315 J1.694
G2 X56.8629 Y30.2316 I-3.924 J2.8064
G2 X55.0911 Y29.4739 I-2.8448 J4.2022
G2 X53.1372 Y29.2587 I-1.7763 J7.1488
G2 X50.6847 Y29.6091 I-0.2312 J7.1394
G2 X48.6025 Y30.8045 I1.4875 J5.0021
G2 X47.2911 Y32.8404 I3.6344 J3.7814
G2 X46.9357 Y35.1609 I7.646 J2.3584
G2 X47.2937 Y37.552 I8.4169 J-0.0378
G2 X48.627 Y39.6578 I5.11 J-1.7605
G2 X50.6242 Y40.8773 I3.6988 J-3.8123
G2 X53.0146 Y41.2576 I2.1767 J-5.9782
G2 X55.3401 Y40.8824 I0.206 J-6.1181
G2 X57.2796 Y39.6902 I-1.6928 J-4.9274
G2 X58.5844 Y37.6243 I-3.7049 J-3.785
G2 X58.9342 Y35.2798 I-7.9315 J-2.3815
G2 X58.9219 Y34.7609 I-19.422 J0.1992
G1 X49.2153
G3 X49.5295 Y33.2171 I5.9593 J0.4089
G3 X50.4286 Y31.8639 I3.4519 J1.3183
G3 X53.1494 Y30.8585 I2.484 J2.5383
G3 X55.2206 Y31.4206 I0.2042 J3.3445
G3 X56.0489 Y32.2306 I-1.7598 J2.628
G3 X56.581 Y33.2151 I-4.2489 J2.9328
G0 Z1.5
G0 X64.964 Y34.0799
G1 F100.0 Z-0.5
G1 F200.0 X69.8092
G3 X69.6519 Y34.8401 I-3.8429 J-0.3983
G3 X69.2536 Y35.5284 I-1.8928 J-0.6361
G3 X67.4315 Y36.2779 I-1.6632 J-1.4537
G3 X65.7239 Y35.6797 I-0.1494 J-2.3102
G3 X65.1732 Y34.9429 I1.4673 J-1.6707
G3 X64.964 Y34.0799 I2.618 J-1.0915
G0 Z1.5
G0 X69.7928 Y31.9828
G1 F100.0 Z-0.5
G1 F200.0 X71.3125 Y31.817
G2 X70.8226 Y30.8054 I-3.621 J1.1293
G2 X69.9807 Y29.9937 I-2.616 J1.8709
G2 X68.7995 Y29.4886 I-1.8965 J2.8015
G2 X67.4969 Y29.3452 I-1.1842 J4.7659
G2 X65.8619 Y29.5788 I-0.1541 J4.7596
G2 X64.4738 Y30.3757 I0.9917 J3.3347
G2 X63.5995 Y31.733 I2.423 J2.521
G2 X63.3626 Y33.2799 I5.0973 J1.5723
G2 X63.6013 Y34.874 I5.6112 J-0.0252
G2 X64.4901 Y36.2779 I3.4067 J-1.1737
G2 X65.8216 Y37.0909 I2.4659 J-2.5416
G2 X67.4152 Y37.3444 I1.4511 J-3.9854
G2 X68.9655 Y37.0943 I0.1373 J-4.0787
G2 X70.2585 Y36.2995 I-1.1285 J-3.2849
G2 X71.1284 Y34.9223 I-2.4699 J-2.5233
G2 X71.3616 Y33.3592 I-5.2877 J-1.5877
G2 X71.3534 Y33.0133 I-12.948 J0.1328
G1 X64.8823
G3 X65.0918 Y31.9841 I3.9729 J0.2726
G3 X65.6912 Y31.0819 I2.3013 J0.8788
G3 X67.5051 Y30.4117 I1.656 J1.6922
G3 X68.8859 Y30.7865 I0.1362 J2.2297
G3 X69.438 Y31.3264 I-1.1732 J1.752
G3 X69.7928 Y31.9828 I-2.8326 J1.9552
G0 Z1.5
G0 X5.5355 Y40.9225
G1 F100.0 Z-0.5
G1 F200.0 X17.6484
G3 X17.2553 Y42.8231 I-9.6072 J-0.9958
G3 X16.2594 Y44.5438 I-4.7319 J-1.5903
G3 X11.7043 Y46.4175 I-4.1579 J-3.6343
G3 X7.4352 Y44.9222 I-0.3735 J-5.7754
G3 X6.0586 Y43.08 I3.6683 J-4.1767
G3 X5.5355 Y40.9225 I6.5451 J-2.7289
G0 Z1.5
G0 X0 Y0
M5
M30

Strange, I can't reproduce this, I get the series of "e"s as shown on the simulator. The only difference between machines is number of steps per unit distance. Let me post the version with some debug output on Sourceforge.

Today I tried it again and it worked. I guess there is a slack joint somewhere in X axis driver board.

Today I fixed the slack joint. Everything now works perfectly. As soon as possible I will post a video of awesome e-circles. Thanks for your assistance. The next step will be to mill a pcb. :-)

Additionally: It's a good idea to put some drops of oil to the axis!

Awesome! You're right, a bit of oil or grease really helps with smoother motion - it's important considering that when steppers rotate fast, they don't put out a lot of torque.

Regarding PCB milling - might I suggest making the table flat first. From what I read it's critical to have the flat table for accurate PCB milling. I think this could be achieved by resurfacing a sacrificial piece of plywood attached to the table.

Yes of course! Meanwhile I made some accurate adjustments for the table with my micrometer. I will document that procedure how this is to be done for the Z axis. I made some good experiences with fixating the workpieces with double sided tape. First I will attach some sacrificial plywood to the table and on top of this the metal blank. Before starting milling I will verify that all is properly adjusted.

Don't expect a result tomorrow, because I have to get more experiences how to convert a board layout to gcode. ;-)

Looking forward to it :) I did a quick google search and found this: http://www.cnczone.com/forums/showthread.php?t=40777
Is this what you're using to get gcode from pcb layout?

That's the question! Today I tested pcb-gcode with excellent results. It produces multi passes for milling and increments the isolation after each pass. So the result can be made very accurate. I guess the ability in producing gcode with pcb-gcode is better than with CamBam. pcb-gcode is a plugin for eagle.

For myself I prefer using KiCad. One but not the only reason is, that it is Open Source. The tool chain would be exporting a dxf file and import it into CamBam. I have done this before and it works. But my target is to use a complete Open Source tool chain.

So no of these alternatives are perfect in my sense. But this is just a question of time.

Meanwhile I will use both alternatives. KiCad / CamBam for my own boards and eagle / pcb-gcode for boards I derive from others, who use eagle.

I will produce my first board with eagle / pcb-gcode. It will be the dorkpov (eagle files) from our dorkbot group in Aachen. There I presented Contraptor and so the board should have some connection to that group. ;-)

The size of the board is a little bit smaller then the Arduino board.

Might be the reason is stalling. At the moment I can't install a flywheel on the X axis, because I shortened it too much and can't get imperial threaded-rod here, maybe I will look around in the net. So I will try a slower feedrate. I emailed the file.

I tried to draw this, unsuccessfully.

First, I'm having a problem with Z axis - sometimes it loses its position. The Z axis connection at Arduino end is not very solid and I think what's happening is vibration might be making some contacts loose every now and then, probably closing limit switches (they're +5V in open position). When that happens, Z doesn't move in response to commands, loses its position, and ruins the entire job. This can be seen towards the end of the video when "TINYPOV" is being plotted:

Second, I noticed that at some point there was offset (maybe -0.5mm) on the X axis (the long one, I think it's your Y). In my second test offset was repeated so I think some specific command might be causing X to skip steps, and this could probably be fixed by reducing feedrate (I ran this file at 1500 mm/min for XY and 125 mm/min for Z). However, to get to this, I need to resolve the problem with the Z first.

In fact vibrations are a hard stress test to the electronics. This might be the reason for my slack joint while testing e-circles. The ultimate solution could be to place the electronis somewhere completely separated in a housing with satisfying cooling. I will not do that (now, maybe in the future). One effort beside the vibrations could be to use the electronics with other Contraptors. Now this means for me to make all connections as good as possible and to avoid cold solder joints ;-). But what I will improve definitely are the connections of the limit switches at the stepper boards. This has been several times a source for failures.

You are right, according to DIN 66217 my X axis goes from left(-) to right(+), my Y axis from ahead(-) to back(+) and the Z axis from bottom(-) to top(+).

Now I have put some oil to all axis, reduced the fast feedrate (10 IPM (~250 mm/min) and I'm looking forward to mill the very first PCB with MiniCNC worldwide ;-D

Well, I hope reducing the feedrate works, it's a pretty long milling job with a lot of opportunities to skip steps. To fix my Z problem, I'll try to reduce max Z feedrate (to rule out Z stalls when moving up) and if it doesn't help, I'll move the electronics off the frame.

Awesome! :-D

Through-hole milling is definitely doable, because this is a board with 9 (!) through-hole traces ;-)

The weak point in electronics n my opinion are the connectors, specially that ones for the limit switches.

PS.: I have seen that you are using a Canon camera, might be the Canon Hack Development Kit is interesting for you ;-)

PPS.: You are not disqualified because of ACME leadscrews (tuning is allowed), but we both didn't start from scratch. And beside that, you have done a drawing not milling into a solid material. ;-)

Result of a fully completed milling run :-D

The run took about 1 hour. With ACME leading screws it would be much faster.This has been done with a 0.6 mm cutter. Therefor I doubt that every trace would conduct (in the upper right). These dorkbot people sometimes are doing too strange things (lot of university people ;-). But luckily I have a cutter with 0.2 mm diameter. The next run in a copper board should make a functional board.

Also this shows, that the accuracy must be much higher than the estimated 0.01"

Very nice! What were your feedrates, normal and fast?

Regarding the accuracy, don't forget that there has been virtually no resistance from the workpiece. We'll see whether mini CNC has enough rigidity to hit 0.01" milling PCB copper, especially in X axis (one with Dremel).

I also found a couple of areas where traces differ from the dorkpov board, but this is how they are in the NC file. I left notes on this flickr photo.

In _init.pde I'm using these feedrates:
#define FAST_XY_FEEDRATE_INCH 10
#define FAST_Z_FEEDRATE_INCH 10
#define FAST_XY_FEEDRATE_MM 250
#define FAST_Z_FEEDRATE_MM 250

The workingspeed for Z direction F100 the other directions are F200.

Some minutes ago I started milling in PCB copper. I haven't seen any difference with milling in wood. But I aborted that run, because I realized, that my 0.2mm cutter is VERY excentric :-(, so that it mills broader than my 0.6mm cutter!

Here is what I got:

And here is a short impression of milling:

Have a look how much dust is produced. This is an epoxy board. Tomorow maybe I will do an open air milling ;-) and I will test miiling into a card board with 0.6mm cutter. I will generate a new GCode file.

Of course the original board looks different. I just used the eagle files to create the GCode entirely by myself. Because in fablab another software for generating GCode is used, there are some differences.

PS.: Just in the moment I have had a look at your comments at the flickr photo. I used NCPlot to have a quick look to the GCode. In this back tracker also no insulations has been showed at that points you marked. Maybe the reason are some settings in pcb-gcode. Thanks for the hint.

One question - how are you tightening the bits in Dremel? I used to tighten them with the supplied wrench and I had noticeable runout (eccentricity), until I read the manual where it said to finger-tighten the bits.

I tightened it with the wrench. So I will do it manually next time.

Regarding the differences between boards. The traces actually appear almost identical; however in at least two instances the adjacent traces on the TINYPOV board are joined (presumably because they're too close). The same traces are isolated on the dorkpov board.

Compare this (see notes and full size image):

to this:

Also, thanks for the CHDK pointer, I'll check it out, I definitely like the timelapse feature.

Today I have had a close look to the milled board. You are right regarding the not isolated traces. I checked it and realized that I got it from pcb-gcode. Maybe my fault, because this has been my first board with pcb-gcode and the board is too sophisticated, because it has been designed for that high-tech machine in fablab Aachen.

I also have had a close look to the "waves". I found them only in that region, and maybe this is conditional upon the wooden structure below the black color. I can't truely say, whether this depends on some changings in the color of the wood or in different density of fabrics. The challenge will make it clear.

Today I also did a second milling with that "0.2mm" cutter. It is a 0.2 mm to 0.5mm konical one. If you just touch the board it's diameter is 0.2mm, deeper cuts are 0.5mm broad. Also before I tightened the cutter to strong with a wrench into my dremel. Now I do it manually.

But these kind of cutters are very difficult to handle. They are used with a very high-end mill hci.rwth-aachen.de/mill. I doubt seriously that it is possible to get the precision of that machine with a Contraptor MiniCNC. So I will have a look for different cuters.

Also I will make a new PCB design, because the measurements of the layout in some regions are to sophisticated for DIY hobbyists. I doubt, that I could do it with the toner transfer method I used until today.

Read this article on instructables to gte an idea what I mean.

I decided to make another GCode file available for the contest. It's much more easier, it's milling time is about 13 minutes and you can use a 0.5mm cutter, which is much more gettable for dremels, proxxons etc.

It is the blinkie board from instructables realizing the "Design Rules". Each isolation route is milled four times, so the milling time could be recuced do about 3 minutes. This is the very coarse end of MiniCNC, while the TINYPOV seems to be the very fine end.

You can download this file here.

Here is the result in plywood

and here in copper

So, as I understand, the difficulty with 0.2mm cutter is uneven Z of the surface? Or do you still have the runout (eccentricity) even if it's finger-tight?
I'd really like to try and mill the TINYPOV board, just for demonstration purposes :)

One thing is your table and material has to be VERY plane and exact adjusted. The other thing is that very small movements in the Z axis will have a "big" effect on the milled diameter. A few minutes ago I chatted with René from fablab Aachen. What they are using is a "Tiefenbegrenzer" ("depth limiter?" I don't know the English word for it). It's an instrument to get very exact control about the milling depth so that it is possible to adjust uneven surfaces etc. On Wednesday I will meet René and we will speak about to make a DIY Tiefenbegrenzer.

Beside that, I tightened the 0.2mm cutter manually, it nevertheless has some eccentric. It's not a new one and maybe the students ruined it a little bit ;-)

I'm also still interested in milling a working TINYPOV. This should be done with a newly generated GCode file with pcb-gcode. Now I know, where to adjust the settings for milling, more important: how to adjust that settings.

Some posts above I promised to explain, how I adjust my table in a way, that it is parallel as accurate as possible to the Z axis.

The trick is to don't do anything to the table, but only to the right Z axis. First on the left side of the table I put something for example a construction angle in a way showed in the picture. Than I lower the Z axis, that it gets in touch with that angle. Afterward I put the angle to the right side ans unscrew the pulley of the right Z axis. Than I turn the right Z axis until it touches the angle also. When both sides touch the angle equally I fasten the screw of the pulley. Voila!

For better results you should move the table, so that the middle of the table is below the gantry.

Nice. Regarding the height dependency when milling PCB - take a look at this blog post and video:
http://builders.reprap.org/2010/03/open-source-circuit-boards-using-reprap.html

The idea of Gavilan (based on Poul-Henning Kamp) software solution PcbSubtraction is brilliant. First he scans the gcode and takes some probes. Afterwards he adjusts the gcode with measurements from the probes. Because he is also using the reprap firmware it should be possible to adopt his solution. My programming skills are not good enough for that job.

I haven't looked at it in depth but I think it shouldn't require any coding, just flashing the firmware and using host from PcbSubtraction package. Well, and connecting the probe pins to Arduino. As long as this firmware fork has acceleration support, it should work in general as well.