Has anyone compiled this using the Arduino Due and selecting either the Programming Port or the Native USB Port? If so, how did you do it so I can follow the same steps?

What isn't working is the buttons on the pronterface to go X Y Z 0.1, 1, 10, or 100 mm. It freezes the board, I have to reset it.

This is the output I get if I enable the debug gcode in pronterface.

SENT: G91 SENT: G1 Y10.0 F500 SENT: G90 RECV: got G91 SENT: M114 RECV: ok RECV: got G1 Y10.0 F500 RECV: ok RECV: got G90

I removed that debug looking "got G…" message (changed the code), but it didn't change much, the board still freezes.

SENT: G91 SENT: G1 Y10.0 F500 SENT: G90 RECV: ok SENT: M114 RECV: ok

This is how it looks, if I copy&paste the commands (one by one) to a terminal:

got G91 ok got G1 Y1.0 F500 ok got G90 ok got M114 Huh? M114 ok

Well, apparently M114 is not supported, but I changed the code to eliminate the "Huh? M114", and the board still freezes with pronterface.

Downloading a gcode file works.

Has anyone managed to make the buttons work in pronterface?

Thanks,
Miki.

I was wondering if I am vary far off, or is this really the maximum this construction can do. I am seeing expected feed rates (the sweet spot) above 1000mm/min for some operations.

Can I use lithium grease? Other discussions say nothing can really harm delrin.

Of course, I am 3 dimensionally challenged, so I may just not see the big picture…

Thanks,
Miki.

Part Number Belt Type Pitch No. Of Grooves Belt Width Material Tension Member Pitch Length
Inch Inch
A 6B 3-120031 Single Sided .200" (XL) 120 0.3125 Polyurethane Kevlar 24
A 6B 3-120037 Single Sided .200" (XL) 120 0.375 Polyurethane Kevlar 24
A 6B 3-120025 Single Sided .200" (XL) 120 0.25 Polyurethane Kevlar 24
A 6B 3-120050 Single Sided .200" (XL) 120 0.5 Polyurethane Kevlar 24

Thanks,
Miki.

In general, have you guys found some reliable, and not too expensive motor you would recommend? So far I ordered all my materials from the sources recommended in the part lists, and I was very happy with them. I have great confidence in your selection of sources. :-)

Thanks,
Miki.

"Pre-fabricated rail supports will be available for purchase separately from a kit."

"Pre-fabricated rings will be available for purchase separately from a kit."

I guess they are still not available for purchase, at least I couldn't find them on contraptor.org.

I couldn't find any by internet search either.

Anyone knows a source I could by some from?

I guess I will have to redo all the templates, to satisfy my thick blade. BTW, are the templates created from the 3D models? How? Or is it only the commercial version of SketchUp that can do that?

Thanks in advance for any advice!

I can make the motors move with a function like

void step(boolean dir,int steps){ digitalWrite(dirPin,dir); delay(50); for(int i=0;i<steps;i++){ digitalWrite(stepperPin, HIGH); delayMicroseconds(100); digitalWrite(stepperPin, LOW); delayMicroseconds(100); } }

Note the delayMicrosecond() function. I try with different values for the delay and the motor stop working below 50 microseconds delay and start to vibrate frenetically.
However, with the contraptor firmware the motors doesn't move at all, just a bit of vibration for less than a second (even in long moves, for example sending G1 X10000).

Any ideas or directions?

Best regards from Argentina (sorry about the English) and thanks in advance.

Joaquin

Im keen on working with other machine builders here and helping them sort out issues which they have while building these products.

Hope to hear a lot from this group.

Regards
Rahul Dhinakaran
rahul dot dhinakaran at gmail dot com

I'm wondering what the feasability of not using the stepper control circuits and "directly" driving the stepper windings from the Arduino firmware would be.

I know the Arduino can't directly drive the windings, I would be using a darlington pair plus protection diodes for each winding. What I'm interested in is bypassing the more expensive driver boards and using 4 pins per motor to do the stepping.

I know that I would have to make code changes to the grbl firmware for the Arduino. I'm interested to know if it would be a fairly isolated change or if it would be a very difficult thing to do.

Thanks!

now my problem with grbl is that i can only get the 1 axis to work(or just 2 output pins to work at a time) the other 2 just stall. i have ran all 3 axis off the 2 output pins i know work and i can get all 3 steppers to move at the same time, just not individually in there assigned pins like they should…

then i tried to use the code from instructables "how to wire a 3 axis cnc" and now i can get 2 of the 3 steppers to move but the 3rd one stalls… i tried to reassign the 2 pins that didnt work to two other ones but with the same result 2 out of the 3 working.. once again if i put the stalled stepper signal pins on the output pins on a working one i can get all 3 to spin.

so i know its not a power supply issue, not a stepper drivers issue, and not a stepper motor issue…..

any help would be greatly appreciate and i mean ANY help! lol

almost forgot to add im using:
arduino uno ATmega328 and or a arduino mega 2560
3 big easy drivers from spark fun, in single step mode 2A per phase
3 400 step steppers spark fun 3.3v 1.7A per phase
atx power supply, i think 300watt 14A 12V

I am building the mini-cnc mod with the contrapteur scheme and want to show you some pics of the actual building state. I would call it pre alpha, because it needs a lot of tweaking and is not entirely finished BUT it moves really smooth (way better than expected) if you turn the spindles :D

The basic concept is as said before the mini-cnc converted to metric 20mm grid (instead of 25 like the genuine metric converion; forum search contrapteur).
During the building process i encountered some difficulties getting all the required materials, so I took what I could get and then went on improvising.
That meant a lot of trial and error and restructurizing the original plan and took me some times to the edge, but I am kind of proud to have managed it to this build stage.
The electronics are in the workings.

Motor: 3x NEMA 23 stepper (1NM, 2,0A, bipolar, 200 steps) Driver: 3x Pololu a4988 Controller: Arduino UNO

_{I know, it doesn't look that good,but with my skills its ok for me ;)}

Thank you

Harware: Arduino Uno Pololu a4988 drivers; Power supply ( regulated 0-24V/ up to 35 A), stepper motor (bipolar)
Software: grbl 0.8.a flashed with Xloader , serial terminal, processing with Mmarz's Gcode sender (from the forum)
My problem is, that the flashing is working and the serial console is promting

Grbl v0.8a '$' to dump current settings

Available serial ports listed below : COM3 Attempting connection on COM3. Waiting for handshake... it appears there is nothing present on this COM port All available serial ports were tested and none responded with the appropiate authentication sequence Please ensure that arduino is connected via a USB serial cable and try again

Any help would be appreciated (and thanks arthurwolf for your help so far ;))

Set the queue size using "#define QUEUE_SIZE" in main source file. For the Atmega328, 20 moves seems to be the maximum it can hold. If you set this value too high, you'll lockup the arduino when the buffer fills up. If you use the 1280, it will hold considerably more moves. The only way I was able to exhaust the 20 move buffer on the 328 was by having many many tiny movements back to back. This should all but eliminate the deceleration and acceleration problem that some were having.

I've also added lots of custom functions. For example, adding a z-surface pin that will automatically find the surface of your platform. Read the code for more info. Do not use the custom functions unless you have the z-surface pin attached or you will damage your machine.

The limit pins have been redesigned. They are no longer connected to the arduino. They instead are connected directly to the cw/ccw pins of the stepper driver. When the platform reaches the end of it's movement, the limit switch forces the driver to reverse direction without notifying the arduino. This means that there is never the possibility of hurting your platform even if the arduino locks up. This also frees up the arduino to worry about the timing of the movements and does not need to constantly check the limit pins.

There is also code for using an external joystick to move the platform. Make sure these pins are disabled if you are not going use this feature.

I've included the processing script that will communicate with the firmware. You cannot use any other script to communicate with this firmware. This is because the firmware and script have been optimized to use the least about of communication to reduce any delays. If you read through the script, you can probably reverse engineer it fairly easily. Besides the streamlined communications, I've expanded the interface to have more functions.

Enjoy!

Firmware: http://www.mediafire.com/?86g1bh81zhczhqw
Processing script: http://www.mediafire.com/?uetaa14aadkx48z

Let me know if you catch any bugs. I haven't tested this thoroughly, but to the extent that I have, it has worked flawlessly.

I see very smart and knowledgeable people here in this forum, so I would like some advise (hopefully step by step), on the best choice to take on MOTION CONTROL software (from CAD to Driving steppers, using free and compatible softwares available on the net), according the hardware I have now to build a CNC milling and in the near future (hopefully with the same hardware) a RepRap to be driven via USB. I have now an Arduino ONE board, an old DTK computer power source (5-12 volts/20-8 amps), six steppers (4.1 vol/1.1 amp) and four pololu A4988 motor drivers, Windows XP an Ubuntu 10.04 on my PC.

Final question: Does Contraptor Processing program has 3D simulator?

Thanks Viny

++

heading level 2

In the course of a project headed by the University of Economics and Business Vienna, we are looking for potential application fields of a magnetic encoder.

Basically the technology allows measuring the position of a magnet.

Can you imagine a field, where for instance one or several of the following problems occur;

• Positions have to be measured contactless
• Extreme external conditions (dust, other magnetic fields, temperature, vibrations) have to be passed over
• Maintenance is difficult due to the high complexity of the final product/application
• Linear, rotating or three-dimensional positions have to be measured
• The space is limited and expensive
• It is vivid to avoid/know about malfunctions of position tracking systems
• Easy implementing and catch/use of the signal is necessary
• An energy effective solution is important.

Or do you know somebody who could imagine that or needs that?

Thank you very much!

Opened it, checked it, looks good : 

Ok, first thing : this stuff is very very very heavy.
You'd think you can move the boxes, but you can't.

After a good part of the afternoon, they are now safe in storage.
And I'm close to death.

So, let's take a look at the various stuff in there :

Contrator

The contraptor angle looks awesome !
Ok actually everything in there does.

And here, for comparison, you can see contraptor ( 1" ) and contrapteur ( 20mm ) side by side : 

Contrapteur angle

Took some contrapteur angle up to the appartment to play with test and measure :

Contrapteur beam

Contrapteur beam is 20mm T-slot, supposed to play nice with contrapteur angle : 

Testing

So, inevitaly, some pictures of angle and beam, with nuts and bolts :

It all seems good, and to work very weel together.
Nothing measured yet, that's next.

I have only one thing to add to all this :
WHEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE !

In doing so I found a deadlock situation that also exists in the original firmware:

the fragment below can (and did!) result in a deadlock when the G0 command finishes while the G90 command is being handled
G91
G00 X1.0
G90

Situation

The G00 step is running
The G90 command is received
This line locks the move_queue (process_string.pde)
// Lock move queue while adding new move
172 move_queue_lock_main = true;
The G0 step finishes
470 // If finished, start next move
471 if ( move_finished ) {
472
473 // Make sure queue not being modified by
474 // main routine and then advance
475 if (!move_queue_lock_main) advance_move_queue();
476
477 // If the queue is locked by the main routine, we can't hang about
478 // and wait for it as this would freeze up the whole system,
479 // so we just wait until the next time the interrupt routine
480 // is called and try again
481 }
The G90 command waits until the move is done (process_string.pde)
303 while (moving) {} // Do not try and do this while moving

Now the move_queue is locked, and moving is still true => deadlock

I fixed this situation by adding a 'move_queue_main_lock=false;' line before all 'while (moving) {}' lines

Jaap.

I've been using a hacked together Python script for communication with Arduino GCode Interpreter, including sending gcode files. This has generally worked well, but it's not very convenient to jog a robot from command line. I also thought it would be great to have a simple and intuitive UI with these basic functions, and use keyboard for jogging.

There seems to be plenty of host sotfware out there, including things specifically written for *duino based GCode interpreters, like gctrl , as well as 3D-printing oriented hosts like Reprap Host and ReplicatorG. There are also numerous scripts in Python and other languages. They all probably work well, but I wanted a UI and a bit more functionality usually found in command line hosts; on the other hand, a lot of functionality and controls in 3D-printing hosts would probably be an overkill for someone who just wants the basics.

After spending several evenings dabbling in Processing and controlP5 (a great UI library for Processing) here is something with a working name of GRemote. It can do three things - issue GCode commands from text input, move the robot with jog buttons and send GCode files. It's intended to work with Arduino Gcode Interpreter, but it should also work with any firmware which understands ASCII GCode and whose responses are "start" for the initialization, and "ok" is the last response for every command sent. The baud rate is fixed at 38400 though that should probably be exposed in the UI via another dropdown (next to the serial port).

Hopefully the following is self evident from the UI and common sense:

Jogging only works in Relative mode and 1 jog distance is 1 unit - mm or inch, depending on the mode. Only X,Y,Z jog buttons work at the moment as I'm not yet clear what to assign to INS, DEL, END (more axes?) and to a lesser degree, HOME.

The Absolute and Inch modes are toggles - unless remote is sending a file, these can be clicked and remote will issue appropriate command to the firmware. The commands being sent to firmware (when sending a file or from text input) are also inspected and in some cases (like the Absolute/Inch mode change) acted upon.

The "console" display shows last 10 lines of what's going on, and on Linux, these are also written out to terminal from which GRemote is launched. On Windows, I'm not sure how to bring up a separate console, other than running source in Processing PDE. I'm guessing it's simple and should be easy to do with some research - if not, logging to file can be added.

File send can be paused (making jog and mode controls available), resumed and cancelled. Few words about pausing:

Jogging has to be done either with limit switches operational, or without hitting physical constraints of the axis. Hitting the physical axis constraints make steppers skip steps which moves coordinate system origin. Not a big deal if you're just jogging, but if you've paused a file and intend to resume it, it's a problem.

Upon resuming the file, the Absolute and Inch mode settings should be the same as before pausing - otherwise things will go wrong. Maybe remote should remember the mode state before pausing and force-restore it upon resuming.

If the file being sent uses Absolute mode, after pausing and resuming the file, the very next command should go to the right position even if robot was jogged elsewhere. If the file being sent uses Relative mode, the robot should be manually returned to pre-pause position before resuming.

The zip file with Windows, Mac, Linux versions and the source is attached to this thread: http://www.contraptor.org/local--files/forum:thread/GRemote.zip
Unzip the appropriate application.* folder to your local machine and run GRemote.exe or GRemote bash script.

Anybody has a debugged version of Chris Meighan's "reprap new firmware"? I was not lucky with the version I downloaded from Sourceforge/Contraptor. With Arduino 0017, I got this error: 'CHAR WORD [128]' REDECLARED AS DIFFERENT KIND OF SYMBOL. With Arduino 0018 I got this error: EXTRUDER_MOTOR_DIR_PIN WAS NOT DECLARED IN THIS SCOPE.

Any help appreciated,

ProfScrew

loading contraptor, I stepped down from arduino 22 to 21, so it would compile and upload properly. After it uploaded, used serial to connect at ~38400 and sent it "x10" or "y15" etc just random stuff that under grbl would make it move. the machine responds "ok" but nothing ever moves.

being that my test sketch works properly, I believe I have a problem with a library or something not being where it should be. I am using a straight copy of the firmware from sourceforge. I have triple checked the pinouts.

I am not at all sure what is causing this. any input would be appreciated.

A while ago I contacted Barton Bring from the Makerslide project about Contrapteur ( 20mm Contraptor clone ), and this morning I received a few of the wheels in advance in the mail. Thanks !

The wheels look very nice. The bearings fit so well that I was not able to remove them for the picture.

So the plan for today is to find ways to get Makerslide and Contrapteur to work together.

I don't have the Makerslide rail ( yet ). This would work out of the box with Contrapteur ( also 20mm based ), and I'll try it as soon as the Kickstarter reward gets here.

Second option would be to make a rail specific to Contrapteur, like this : 

That should work well, and I'll try it soon ( diagonal lasercutting ! ), but I needed something simpler for today. I went for the "angle as rail" option Contraptor uses for the sliding element.

There are two options here : the wheels in a diagonal plane and the angle in the "normal" plane, or the angle in a diagonal plane and the wheels in the "normal" plane. Chose the first one here, but I'd like to try the other one too.

First part is a mount for the wheels, lasercut in 4mm acrylic :

The bending was made with a hot air SMD station. Here is how it looks when sliding on a rail ( contrapteur angle ) : 

It slides very well. Here is a video.

It is very smooth, even better than the Contraptor linear rail, and much much easier to assemble.

The fact that the part is lasercut allows to make it the exact dimension to fit the angle, so there was not even any adjustment required ( also my brain refuses to understand how the Makerslide eccentric spacers work … ) it worked the first time after assembly.

So now we have two sliding elements on two separate rails, but the goal here was to have a single carriage.

Because the bending is made by hand, it is not possible to know exactly it's exact position in the part ( with my current bending skills, it would be different at each bending ), so the distance between the two parts can vary, so it's not possible to make a part with holes that would fit them exactly for sure.

Here is the solution I came up with :

The "long holes" allow to connect the two parts together even without knowing how further apart they are.

Once assembled it looks like this :

And a video of it sliding :

This works surprisingly well ! The carriage is very sturdy, the sliding very smooth and silent.

Makerslide is awesome, plus it's opensource, plus it's awesome !

Plus it's cheap.

Plus it's 20mm based.

I can't wait to play more with it ( next thing will probably test having the angle at a diagonal and the wheels in the normal plane ).

EDIT : Spent all the rest of the day trying to lasercut rails for it : diagonal lasercutting is veeeery difficult ! Finally got one rail right, see pics below : 

It works quite well, the wheels slide well and it seems sturdy.

But it's a lot of work to make : the lasercutter must be ajusted at the 1/10mm, the diagonal support was a lot of work, and even thenit takes several tries to get a rail right. Getting better at it thought.

Tomorrow I'll try to make another one, and use the two to support a carriage.

A while back I made a prototype of the sliding element for T-slot. Since then there were a few tweaks to it, however it was never really tried in action.

I received an email recently asking whether it was possible to use Contraptor to build contraptions of larger size (e.g. 2x4 ft). This would definitely call for T-slot - which I happen to have several standard lengths of (12", 18", 24"). I also have several fabricated T-slider prototypes. To test a number of assumptions about how these sliders would behave, I intend to build a robot with light X and heavier Y driven by belts, and heavy Z driven by four leadscrews. The robot would be ~2ft in X, ~1.5ft in Y and ~1ft in Z - but it could be scaled up. The actual work volume would be smaller than these dimensions. The screenshot on the right is work-in-progress on that robot.

So far I've assembled the basic T-slider belt drive. The test below uses Arduino GCode Interpreter and grblShield (1/8 microstepping). The speed is 600 IPM.

Noise has been somewhat of a problem with mini CNC. The machine is fairly quiet at most of the feedrates. However there are a couple of feedrates that result in loud and nasty vibration. In my testing these are 2.1 IPM and to a lesser degree, 4.2 IPM. Any diagonal move that happens to have one of the axes moving at these speeds becomes a problem.

Short version

To reduce the noise, I basically followed Arthur's previous work at the link above and added some degree of vibration isolation between the following:

Leadscrew and bearing
Instead of steel nut, a plastic nut is in contact with the bearing. Not visible in the picture, there is some teflon tape wrapped around the leadscrew where the (ball) bearing is. This prevents leadscrew from rattling around. I added the thrust bearing for reasons other than noise control, but it also has a plastic nut. The combination of plastic nuts with steel nuts should eliminate the need for spring washers (which were skewing the nuts).

Motor and motor mount
The motor is connected to the mount with nylon screws and nuts. There are several neoprene washers in between, as well as a pair of grommets in the mount holes (visible on the right pic). I found that metal screws didn't really work well there. The motor flexes on this mounting, but not in the twisting direction so it seems OK.

The plastic/neoprene parts are fairly cheap in 100 qty at Mcmaster:

neoprene washers: #90133A017
rubber grommets: #9600K66
nylon 1/4 nuts: #94900A029
nylon 10-24 3/4 screws: #97263A245
nylon 10-24 nuts: #94900A011

Microstepping
I kind of knew this already, but besides vibration isolation, the other important thing that reduces vibration is microstepping. With half stepping, the noise was still too much even with the 2 modifications above. I went an extra step and made a 1/4-20 Delrin nut for X-axis because there was an audible rattle between leadscrew and leadnut; thinking that it would quiet things down. However, with half stepping, that didn't significantly help - but the noise reduction was more pronounced with microstepping. I used TinyG but I'm planning to switch over to grblShield - both are 1/8 step.

I measured the following max values using Sound Meter Lite Android app. Anything under 60 dB sounds good enough to me. Again, these are supposed to be worst case scenarios - with the disclaimer they were tested on a single axis.

This is a sketch from few months back showing how V-track might be a part of Contraptor. At that time, I looked at the prices of V-tracks and V-groove bearings and found them fairly expensive. Nevertheless I had ordered some material to build and test the prototype, and this weekend I finally got around to it.

Below are V-tracks that can attach to Contraptor angle or 1" T-slot. Fabricating wasn't too difficult but took some time. 3/16" holes were drilled in V-track at 2" intervals. 4" intervals could probably also work, but 2" fit nicely with 1ft and 2ft track lengths. One difficult thing was tapping small screw holes in the aluminum bar. I usually drill 1/8" hole and 6-32 screw self-taps into the hole with little effort. This works great in 1/8" thick aluminum. Here, the holes were about 3/8" deep and screws would stop dead after a certain point. I tried 6-32 tap in the power drill to save time and it broke on pull out after stopping too late. Basically the holes had to be tapped manually, advancing about quarter of a turn and then stepping back a couple of turns. Anyhow, this was only needed to be done once as they're not intended to be disassembled.

The V-bearing element still needs to be made. I only have 2 V-groove bearings from VXB.com and I'm trying to find them for a reasonable price (not $15 a piece). They are angular contact bearings so they can support combined loads and have very little axial play. The V-track + V-groove bearings with T-slot should be able to handle loads of a larger CNC machine - 1ft x 2ft and perhaps 2ft x 4ft.

I want one !

Actually started a design in eagle for just that … I think I'm going to give up on circuit design, these guys do a much better job.

ril3y

When designing the contrapteur mini-cnc, I had to find out how to place the diagonal bar ( so that the holes of the diagonal bar it right in front of holes in the two other angles.
Now that I have the actual angle to play with, it's quite easy, but in Sketchup, trial and error was quite a burden.

Here is an array I used, that gives the round hypotenuses for different angle lengths, it was quite usefull to decide which length to give to which angle : 

And the Perl script to generate it :

print "|| ||~ ", join('||~ ',map $_ , 1..30 ) , "||\n"; for my $x ( 1 .. 30 ){ print "||~ $x ||", join('||', map int(sqrt(($_*$_)+($x*$x)))==sqrt(($_*$_)+($x*$x)) ? int(sqrt(($_*$_)+($x*$x))) : ' ' , 1..30 ) , "||\n"; }

Just in case this can help someone else …

Sketchup has built-in Ruby interpreter, and I spent last couple of weeks figuring out how Sketchup could interpret an assembly sequence based on a Ruby script. Borrowing some methods from OpenSCAD, I think the script below looks readable. There are 2 classes - Component (which maps to Sketchup component instance) and Assembly (which maps to Sketchup group). The component names are also the file names in the Contraptor library (in Sketchup/Components) folder.

The following sequence:

Was produced from the following script (this is the base assembly of the mini-CNC):

def base base_front = Assembly.new("Base front") base_front << Component.new("perforated-angle-12").rotate!([0,0,-90]).translate!([0,0,-2]) base_front << Component.new("perforated-angle-4").rotate!([0,90,-90]).translate!([1,0,0]) base_front << Component.new("perforated-angle-4").rotate!([0,90,-90]).translate!([7,0,0]) base_front << Component.new("perforated-angle-2").rotate!([90,0,180]).translate!([4,0,-2]) base_front << Component.new("perforated-angle-2").rotate!([90,0,90]).translate!([8,0,-2]) base_front << Component.new("perforated-angle-2").rotate!([90,0,90]).translate!([4,0,-1]) base_front << Component.new("perforated-angle-2").rotate!([90,0,180]).translate!([8,0,-1]) base_front << Component.new("perforated-angle-2").rotate!([0,-90,0]).translate!([4,-1,0]) base_front << Component.new("perforated-angle-2").rotate!([0,0,0]).translate!([8,-1,0]) base_front.screenshot base_back = Assembly.new("Base back") base_back << Component.new("perforated-angle-12").rotate!([0,180,-90]) base_back << Component.new("perforated-angle-3").rotate!([0,-90,-90]).translate!([0,0,-2]) base_back << Component.new("perforated-angle-3").rotate!([0,-90,-90]).translate!([9,0,-2]) base_back << Component.new("perforated-angle-2").rotate!([90,0,-90]).translate!([3,0,-2]) base_back << Component.new("perforated-angle-2").rotate!([90,0,0]).translate!([9,0,-2]) base_back << Component.new("perforated-angle-2").rotate!([90,0,0]).translate!([4,0,-1]) base_back << Component.new("perforated-angle-2").rotate!([90,0,-90]).translate!([8,0,-1]) base_back.screenshot(camera = 1) base = Assembly.new("Base") base << base_back.rotate!([0,0,180]).translate!([12,18,0]) base << Component.new("perforated-angle-18").translate!([1,0,0]) base << Component.new("perforated-angle-18").rotate!([0,-90,0]).translate!([11,0,0]) base.screenshot base << base_front.rotate!([0,0,180]).translate!([12,0,0]) base.screenshot end # Create top level assembly contraption = Assembly.new("mini-CNC") # Set up extra cameras - they are shared among all instances of Assembly class contraption.set_camera(1,[-30,-30,30]) contraption.set_camera(2,[30,0,0]) # Add subassemblies to the top level assembly contraption << base # Take a final screenshot using default camera contraption.screenshot

The images are not in color yet, but it should be easy to add. Also, there are no fasteners - while they can be added via Component.new() - just like any other component in the library, this would probably make the script too bulky. Trying to figure out if there is a way to make them go to where they should be with minimum commands.

The plugin is attached (unzip in Plugins folder, restart Sketchup): http://www.contraptor.org/local--files/forum:thread/AIG.zip
The folder $SketchupHome\Components\Contraptor should contain SKP files with Contraptor components in order for plugin to work - alternatively, change component library path in assembly.rb and use arbitrary components.

Finally, there is no error handling and the code is a bit kludgy, but it works for me on Sketchup 8/WinXP

Ok so end of the suspense, to summarize : it's good, it works ! ( but it's not perfect ).
All dimensions are good, except for the centering of the holes, that is a very very small bit off ( 0.2mm or maybe less in the direction of the inside … ) but when using the angles, it works ( maybe the fact that the bolts are not exactly 5mm helps ).
The angles are a bit "dirty", but they look super good once cleaned with water and soap.
Also, they are deburred only on one side, but the other one is clean so that's ok.
They weight less than the contraptor angles obviously, that feels better when building, but it's subjective.

The small problem with centering scared me a bit so I decided to try it and build something with it, you should recognize it :) :

I didn't have the exact angle length for the present plans of the contrapteur mini-cnc, so I used lengths that were close …
The screws are the shorter they had at the hardware store ( 15mm ), it needs even shorter screws ( 8mm would be good ).
The machine feels very stiff, and the fact that the screws all fit perfectly makes building it very very easy : everything just stays wherever you put it :)
Small problem : due to the light weight , lack of control when using a big electric screwdriver sent the machine flying to the other side of the room, hurt my arm a lot … will be more cautious next time.

When ordering more, I'll have to ask for the holes to be better centered … maybe define a set of tests/shapes for the angles to be sure before shipping.
With the holes better centered, it would really be perfect.

That's all for today !
Super happy !

All the Makerbot drivers seem to be out of stock as I think they've upgraded their electronics. Can I just buy Pololu driver boards and plug straight to an Arduino Mega - will the Arduino Gcode interpreter work with this setup?

Are there any other alternative boards people have been using successfully?

As an alternative I have been recommended swapping the arduino firmware and makerbot with replicatorg and a RAMP setup - can anyone shed any light about this?

I'm new to this and any help would be much appreciated.

Here is a new project for contrapteur : the wall drawer.
Nothing new, you can find similar projects here, here, here and here.

Basically, it is a small robot, suspended by strings, that rolls the strings to move, and doing so, draw ( on a wall ).

It is still at the draft stage, but the main ideas are here.

Main eccentricities of this design :

• Uses belt and pulleys instead of strings. More expensive, but more reliable and precise.
• Has motors on-board, adds weight, makes it less giggly.
• Will use software calculation to maintain the robot aligned with the horizon.

To get an idea of how it works here is a picture of the back ( part that faces the wall ) :

Basically, the motors turn the pulleys, the pulleys push/pull the belt, and that makes the robot move. As simple as that. You actually need cosine things in the software to have Cartesian coordinates/movement, that's probably the most difficult part of the project.
At the top you can see the pen, attached to a servo. The servo is for not-drawing when not necessary, or even for controlling depth if you use a brush, or brush-pen.
Not featured here, the contact between the robot and the wall ( other than the pen ) will be handled by roller balls.

A picture of the top :

You can see the motors, arduino and servo. Missing are the arduino shield with pololu drivers on it.

Design challenges :

• Figure out if this can work
• Design a contrapteur part for the roller balls
• Find how to attach the servo to contrapteur … maybe via a lasercut part.
• Find how to attach the pen to the servo. Lasercut or 3D printed part. Or something dirty at first.
• The software is the real challenge. Must understand Gcode, like the mini-cnc, but moves nothing like it.

Apart from that it all seems fairly easy.
I'll continue to refine the design, and when the contrapteur sample parts arrive, assemble it and test it … it should be a quick build.

Note : This took 15 minutes to design, contraptor really rules !
Should be easy to do in ( inch ) contraptor too.

It includes :

• 18 ball bearing holders
• 8 lead nut mounts
• 8 lead nut mounts for sliding element
• Templates for punching the angle
• Templates for punching the 40mm square tube
• Templates for punching the motor mount and cutting the rubber dampers

It will include :

• Design tests for lasercut motor mounts ( inspired by riley's )
• Templates for punching the sliding elements, linear rail stage, etc … they are still at the design stage, not sure about where all the holes will be.

Any idea of usefull stuff that could be added in the white space that helps when doing contraptor ?

Edit : Optimism FAIL, it's way more costly than thought at first, forgetting about ordering two materials.

This will be the thread for the contrapteur mini-cnc project.
The goal is to make a complete replica of the mini-cnc, but using metric parts.
The good thing about the mini-cnc is that it uses all contraptor parts, so translating it's part is basically translating contraptor.

So to start, we need a frame with about the same dimensions as the contraptor mini-cnc.
Here bellow is a draft, conversion has been made the following way :

• For short parts, use parts with the same number of holes.
• For long parts, use parts about the same length.

It ends up looking very much alike.
Some things may need to be changed once we start adding the moving parts, we'll see then.

So now that there is a frame ( in sketchup ), what is needed next ?

• Sliding elements : design already started in the big-cnc project, raw aluminium square tube easily available.
• Linear bearings : TBD, main problem is here is that aluminium channel is hard to find. Could be made by shortening U profile legs.
• Linear rails : design started in sketchup, same problem with aluminium channel.
• Coupling nut clamp and Lead nut mount : TBD
• Shaft mount : easy, will be made with laser cut holders, see discution
• Belt clamp : easy too.
• Motor mount : design already started in the big-cnc project, from square tube cut in half, with rubber vibration isolation.
• The rest ( parts column ) : TBD, but lots of progress already done for the big-cnc project

Documentation : 

• Wiki page ( under Metric version )
• Sketchup file to be uploaded to 3D warehouse
• Build log with pictures
• Trying to document it as well as the original mini-cnc

Any comments/advice is super welcome !

When I started Z-axis assembly, it became clear that the design wouldn't allow to easily perform the leadscrew alignment steps, so I ended up modifying Z-axis to accommodate that. By the way, one of the advantages of construction sets is that a new version of an assembled device doesn't require time/expense of making/buying modified parts, as the case may be with a traditional kit. I simply rearranged the existing parts - construction set is more like software in that sense.

Here is the new Z-axis:

The design allows to assemble and align each of the rails independently.

It also provides more Z axis travel - almost 3" (measured without Dremel). This may be useful for some of the attachments such as drill chuck.

The first tests went well, but when I replaced 6" flat plexi bracket on the rear of X stage with AL angle to enable grounding of the limit switches, I ran into um.. a runtime error when the X stage rear angle crashed into one of the stepper driver heatsinks with Z raised all the way up. I didn't really crash, X stage just kept going, getting more and more skewed as the top was blocked and the bottom continued to move.

So now I have to remove the entire X axis and (mostly) re-assemble and re-align it from scratch. However this means I can take care of another narrow assembly spot - securing X axis to Z stage. It's somewhat difficult with the wrench and using hex socket is almost impossible. There is no reason why the flat screw/nut at the end of the linear rail can't be removed/moved 1" inward - that way it won't interfere with the hex socket.

I'd like opinions on this idea for a ball bearing mount.
I really like the simplicity of the one in the contraptor set, but in my mini-cnc when building they popped off very often.
Also the bearing I will get for the big-cnc project do not have edges that sharp/square, they are a bit rounded so that will make it more difficult to stay in place with that technique.

My current idea is to entirely surround the ball bearing.
This only needs two small pieces of aluminium ( or maybe some lasercut plastic, maybe cheaper and/or simpler ) with a hole the size of the ball bearing, and smaller holes for screws.
And then the angle is drilled the same way, but with a bit smaller diameter for the ball bearing hole, which makes the ball bearing hold.

What do you think ?

This software is very sophisticated and gives a lot of control and possibilities to run a mill.

No Arduino is necessary for this, but a parallel port.

What I have done is discussed in the LinuxCNC forum

To get running this, I made a Reprap Stepper Motor Driver v1.2 parallel port adapter with KiCad.

As soon as possible I will describe it in detail and will attach all files.

Christoph

I've modified the Contraptor firmware to include XZ and YZ arcs. The way I implemented this was by creating dummy indices I_Axis, J_Axis, & K_axis. I-J is the plane that the arc resides in and K is always normal to it. So for XY arcs I = X, J = Y, & K = Z. For XZ, I = X, J = Z, & K = Y. Since the code originally only acted on the XY plane, I made it act on the new generic I-J plane. The way I set it up, the code will behave identically to the original unless you provide it with the g-codes G18 or G19. G18 = XZ plan. G19 = YZ plane. Although I did add a small fix to the way feedrates were handled after a change in the unit system. The original code would not change the units for the feedrate properly if an arc move immediately followed the unit change command.

The syntax for arc moves goes like this:

G90 G20 G17 G1 X0.0 Y0.0 Z0.0 G3 X0.5 Y-0.5 I0.5 J0.0 G18 G1 X0.0 Y0.0 Z0.0 G3 X0.5 Z-0.5 I0.5 K0.0 G19 G1 X0.0 Y0.0 Z0.0 G3 Y0.5 Z-0.5 J0.5 K0.0

That should draw the same quarter circle in all three planes. If you wanted to draw a helix, you can use the following command:

G90 G20 G18 G1 X0.0 Y0.0 Z0.0 G3 X0.5 Z-0.5 I0.5 K0.0 Y1.0

G17 = XY plane, G18 = XZ plane, G19 = YZ plane.

Other bonuses in this code include:
-arthurwolf microstepping fix (I haven't tested this but he seems to know what he is doing)
-Albanetc's arc fix
-Added M2, M3, M5 and M30 codes for starting and stopping your cutting head. Use TOOL_HEAD_PIN in _init to select which pin that will act on. Set it to -1 if you don't want to use it.
-Added manual controls:

1. -START_PAUSE pin is an analog pin connected to a pull down resistor and a high side switch. When switched to high, it exits all of the running code, and enters a while loop that allows you to jog the stage. The jogging isn't taken to account by the main program. So absolute positioning is not maintained. I used an analog pin for START_PAUSE, so that I can add other functions later.
2. -TOOL_HEAD_SW_PIN will turn on the cutting head when the code is paused. If it is left high when you enter the paused loop, it must be toggled low and then high again to turn on the cutting head (safety feature).
3. -HOLD_PIN will enable and disable all of the steppers. If it is left high when you enter the paused loop, it must be toggled low and then high again to turn on the steppers (safety feature).
4. -MAX_MIN_PIN is an analog pin which all of the limit switches are connected to. A resistor ladder is used to differentiate between the limit switches. This is necessary when manually jogging if you want to back off of a limit switch. This also frees up more pins.
5. -_LEFT_RIGHT are analog pins connected to pots to move the axis. 2.5V = no movement. 0V = fastest left. 5V = fastest right. All directions can be moved at once. I used an old gaming controller and wired the existing pots to my arduino.

You can enable and disable the manual controls code by using MANUAL_ATTACH inside reprap_new_firmware_arc.pde. If you don't want the manual controls, set #define MANUAL_ATTACH 0 and the firmware should behave like the original.

Here is the firmware: http://www.mediafire.com/?6756ivkwz7kk8ih

(Small update: fixed an issue that caused the manual controls to not work.)

To show you visually what is happening:

Arduino
{X-driver}
{Y-driver}-{Y-stepper}
{Z-driver}-{Z-stepper}
(Y and Z function correctly)

Arduino
{X-driver}-{X-stepper}
{Y-driver}-{Y-stepper}
{Z-driver}-{Z-stepper}
(Only X functions correctly)

Also, if the X stepper motor is attached, but I disable the X-driver using the L297 disable pin, then Y and Z works fine. I thought it might be a problem with my power supply. So I upgraded my power supply to one that had 3 times the calculated amperage, but the issue stayed the same. I know the motors are wired correctly because they all individually work. I only run into a problem when all of them are wired at once.

Update: I tried replacing the L297 on the X driver but the problem remains. With X disabled, Y and Z function without hissing. With X enabled, strong hissing is heard and only X moves smoothly. I think my next step will be to try to replace the L298n on the X driver.

Do you guys normally hear a hissing? I know the chopper is supposed to make a noise but when only Y and Z are enabled, I hear no hissing and they work perfectly.

Update 2: Solved!!!

The problem had nothing to do with the X axis. I had combined all three stepper drives onto a single 3" by 4" board, and in doing so, I forgot to multiply the capacitor on the +5V line. When one of the steppers would stop at half a step, it would put a heavy load on the 5V side and the other chips would become unreliable (jitter, move, act crazy). I guess when I only had two motors enabled, the cap on the board could handle the load. I put a huge capacitor on the board and everything is running smoothly now. This is funny because I had assumed this was a problem with the 24V line. I already had a 4000uF cap on there and changed my power supply to a 24A one. I hope this helps someone else that runs into the same problem.

Update 3: Solved Secondary Problem with Acrs

[http://www.contraptor.org/forum/t-192541/mini-cnc-case-study#post-749373]

The GUI is a Processing Sketch.
You need to download the processing program here.
Download the GUI sketch here.

Then run the processing.exe and open the GUI sketch, Gcode_Feeder_GUI.pde. Press the play button and the GUI pops up. The sketches have the same extension as Arduino sketches, so don't accidentally try to run the processing sketch with the Arduino IDE.

To connect to the Arduino you can press "connect" and it will try every available port until it connects, or you can type in the com port and press enter. Example: "COM19" <—The case matters.

Let me know if you find any errors.

This website has been a great help in my CNC build. Thanks for all of the information.

I'm asking because I can get :

• 1 meter of aluminium angle for 1,022 euros
• 1 meter of cold rolled iron angle for 0,643 euros

So the money concerns tell me to get iron, but something tells me aluminium was not choosen for nothing.
What are the inconveniences and advantages of each and why was aluminium choosen for contraptor ?

Thanks :)

Edit : Also, in case this may be usefull to other metric folks, the website I'm planning to buy from ( delivers to France, Belgium and Netherlands ), it's the cheapest I found ( tell me if you find cheaper ) : 
The website is leboutte.be
Google translation : Aluminium and Iron

Edit 2: I just saw this : http://www.contraptor.org/forum/t-202736/ , gives me a short answer, but I'd still be curious to know a more.

Google did not give me any simple tutorial on anything, just bribes, and all suppose I already know a lot ( but maybe I also don't know what to look for ).

Reprap has documentation on how to use the reprap for 3d printing, but that's not of big use for everything else.

Specifically what I'd like to learn how to do : 
- Drawing text ( http://www.timeguy.com/cradek/truetype produces gcode, but I don't get how to get the GUI, I just have CLI, and the gcode is filled with variables that need interpolation )
- Drawing/Engraving circuit boards
- Previewing the Gcode's effect before actually sending it to the machine ( something a bit like http://replicat.org/ )
- Carving 3D objects ( from Sketchup files ? :) )

I'm sure there is a lot more to learn and a lot more to document also.
Only basic info on how to get from 0 to a complete run for very simple cases ( with screenshots ) would help get on the train to learn further.

Documentation on the contraptor site is very well done, but that part is missing ( in the Learn menu maybe ? ).
This page has links : http://www.contraptor.org/motion-control, I just saw cambam has video tutorials, going to look at them now.

Just throwing an idea, I can't do it myself as I don't have the knowledge, and I think writing this documentation would take lots of work.

Edit: spent a part of the day learning cambam, it' easier to get now that I have read the documentation, fills a lot of the gaps I'm asking here to fill, still, contraptor-centric documentation/introduction on it would be nice, maybe I can do it when I know more.

Best,
Diego

So, I'm still trying to get my mini-cnc to work with the pololu steeper drivers and my sanguino.
I have run into some trouble, all of which seeming to be related to the fact that I use 1/16 micro steeping.

This leads me to values like :

#define X_STEPS_PER_MM 2500 #define X_MOTOR_STEPS 3200

Which the firmware seems not to like.

First problem I ran into was the firmware didn't do accelerations for feed-rates superior to 217 mm/m ( went directly to full speed ).
I'm not sure who writes this firmware so I'm posting this here, tell me if you know who to report this to.
Fix is, in stepper_control.pde , replace :

next_move_ptr->steps_to_accelerate = (int)floor(square(master_axis_feedrate) * steps_per_unit / ( 120 * units_based_constants[MAX_ACCEL] ));

next_move_ptr->steps_to_accelerate = (long)floor(square(master_axis_feedrate) * steps_per_unit / ( 120 * units_based_constants[MAX_ACCEL] ));

The second problem is one I'm still stuck with :
During acceleration, at higher feedrates, the motor stops working after accelerating for a while. Depending on values, it might start working again when maximam speed is reached, then stop working again during deceleration.
I asked on pololu forums, where I was told it may be resonnance from the stepper, or a problem with the signals my microcontroller sends.
I disconnected the stepper driver, and connected a speaker on the step pin instead : the problem is with the signal the step pin sends.
I have read most of the code for this pin, and still can't find where the problem is.
Here is the detail of the problem:

I have added the following code just before the end of the pin interrupt loop thing ( OCR1A = timer1LoadValue; ) :

 if( sequence_step_number % 100 == 0 ){ Serial.print(millis()-last_dump); Serial.print(" "); Serial.print(sequence_step_number); Serial.print(" "); Serial.println(timer1LoadValue); last_dump = millis(); }

Note : the problem exists even without this debug code, it's not causing it, it just adds a bass line to the sound from the speaker.
So now every 100 steps I get the time it took to do that step, the step's number, and the duration we will wait untill sending the next step signal.
I made a graph with the data : 

X is step number, green Y is timer1LoadValue, and red Y is the time the step took ( it's supposed to be the same as the green one ).

What it looks like is that when the timer1LoadValue variable gets near 255 and 127, the steps take a lot longer to iterate than they should.
These two values don't seem random, but I don't find the problem in the code.

Anybody has an idea ?

Thanks a lot !
( will post this in the reprap forums in a few days if no answer here )

EDIT : 

To get only the iterations that are too long, I put the following debug code :

 if( (double)(micros()-last_dump) > 30000 ){ Serial.print((double)(micros()-last_dump)); Serial.print(" "); Serial.print(sequence_step_number); Serial.print(" "); Serial.println(timer1LoadValue); } last_dump = micros();

Here is an example of the data this outputs :

start 1775536.00 2 23432 ok 32876.00 13308 246 32876.00 13315 246 32876.00 13322 246 32876.00 13379 244 32876.00 13510 244 32872.00 14889 232 32876.00 14910 232 32876.00 14916 232 32876.00 14964 232 32876.00 14989 232 32876.00 15010 232 32876.00 15183 230 32876.00 15218 230 32880.00 15234 230 32876.00 15249 230 32876.00 15252 230 32876.00 15265 230 32876.00 15330 228 32876.00 15334 228 32872.00 15367 228 32876.00 15383 228 32876.00 15589 226 32876.00 15748 226 32884.00 15758 226 32884.00 15764 226 32876.00 15779 226 32876.00 15791 226 32888.00 15793 226 32876.00 15795 226 32876.00 15797 226 32876.00 15799 226 32876.00 15801 226 32876.00 15805 226 32876.00 15807 226 32888.00 15809 226 32876.00 15811 226 32876.00 15813 226 32876.00 15815 226 32876.00 15817 224 32876.00 15831 224 32876.00 15841 224 32876.00 15853 224 32876.00 15862 224 32884.00 15866 224 32876.00 15870 224 32888.00 15877 224 32876.00 15881 224 32876.00 15886 224 32876.00 15896 224 32884.00 15930 224 32872.00 15962 224 32876.00 16030 224 32876.00 16036 224 32872.00 16053 224 32876.00 16063 224 32872.00 16068 224 32876.00 16073 224 32876.00 16096 222 32876.00 16103 224 32876.00 16119 222 32876.00 16130 222 32876.00 16133 222 32884.00 16136 222 32876.00 16148 222 32884.00 16152 222 32876.00 16159 222 32892.00 16182 222 32888.00 57610 214 32872.00 57661 214 32872.00 57666 214 32872.00 57676 216 32872.00 57682 216 32872.00 57726 216 32872.00 57880 216 32872.00 57891 216 32872.00 57899 216 32872.00 57927 216 32880.00 57935 216 32872.00 57939 216 32872.00 57950 216 32868.00 57956 216 32872.00 57968 216 32872.00 57979 218 32872.00 57989 218 32868.00 57991 218 32872.00 57993 216 32872.00 58015 218 32872.00 58024 218 32872.00 58026 218 32872.00 58035 218 32872.00 58050 218 32872.00 58055 218 32872.00 58067 218 32868.00 58073 218 32884.00 58099 218 32892.00 58129 218 32884.00 58498 220 32876.00 58538 220 32876.00 58558 220 32872.00 58571 220 32872.00 58574 220 32872.00 58601 222 32872.00 58612 222 32876.00 58614 222 32872.00 58616 222 32872.00 58661 222 32872.00 58803 222 32884.00 58823 222 32876.00 58838 222 32872.00 58850 222 32872.00 58866 222 32876.00 58872 222 32872.00 58878 222 32872.00 58886 224 32876.00 58898 224 32872.00 58922 222 32876.00 58935 224 32876.00 58952 224 32872.00 58958 224 32872.00 58973 224 32872.00 58997 224 32880.00 59086 224 32872.00 59166 224 32876.00 59183 226 32884.00 59200 226 32872.00 59217 226 32872.00 59252 226 32872.00 59258 226 32876.00 59301 226 32872.00 59426 226 32876.00 59435 226 32876.00 59456 226 32884.00 59489 228 32876.00 60514 236 32872.00 60942 238 32872.00 60949 238 32876.00 61045 240 32828.00 75002 120

So it seems the loop lasts 32768 microseconds too long for some values.

EDIT 2:

Putting the last_dump = micros(); just after ISR(TIMER1_COMPA_vect) { shows the problem is not with the calculations being too long ( never lasts over 200microseconds ), so the problem is with the PWM thing.

So here is what I did to make it less noisy.
The big idea is to not have metal touching metal between the motor and the machine.

The small black rubber things come from a meccano set, I guess you can find something equivalent in an hardware store for cheap.
I cut them in two to have more, and so that they are smaller.
The black rubber band I don't know how it is named, it stretches, and becomes solid(er) once used, I use it a lot but I don't have a box for it, it's used for pipes I think.

So step by step:

And it's done.
Once everything is together, parts can move a bit.
That was not a problem for my X-axis, but for the Y-axis I had to add a third bolt ( but that may be due to another problem with the axis ).

Now everything makes lots less noise, very calm and low sound :

When I send the M code "M05" it should turn the laser off (pin 19 to GND), but instead, it turns it off, and before the next move starts, it turns back on again.. any suggestions ?
The following snippet is from ""process_string.pde" where the commands are interpreted…

 if (intCodesSeen & M_CODE_SEEN) { switch (intVals[M_CODE_INDEX]) { //turn extruder on, case 03: // extruder_set_direction(1); extruder_set_speed(extruder_speed); //digitalWrite(EXTRUDER_MOTOR_SPEED_PIN,HIGH); //analogWrite(EXTRUDER_MOTOR_SPEED_PIN, extruder_speed); break; //turn extruder off case 05: // extruder_speed = 0; extruder_set_speed(0); //analogWrite(EXTRUDER_MOTOR_SPEED_PIN, 0); //digitalWrite(EXTRUDER_MOTOR_SPEED_PIN,LOW); break;