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.

Here is the first draft of the template :

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.

Picture :

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

Picture of a first draft :

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.