My answer is: what accuracy can I expect? Ideally accuracy below 0.1 mm (what the human eye can see, but that demand is probably insane) but I would be pleased if it was no more than 0.5 mm - am planing to use multiple colors, so after one round of drawing I plan to change the color and start again (there goes the accuracy:-) ).

What I would like is the following:

• I want to be able to use real paint when reproducing a computer generated artwork and I would like to use different layers of paint, hence the accuracy. (I am planning to make my own paint markers, but this is the wrong forum for that)
• I suspect that my files are going to be rather on the big side because they will have lots of details. Think 10 to 20mb per color - about 250.000 vector points or more. (will probably use a program called vectoraster that converts images to black and white rastered eps files) And yes, I am aware that each round of drawing might take 10 hours or longer.
• I want to start small, A3 sized (17"*11") or maybe A2 (22"*17") and then perhaps go bigger - especially in the length (several meters) - so being able to reuse the components would be awesome.
• And of course, I am not rich, I work a shitty payed job a couple a days a week, make art on the side, so it should not cost too much :-)

So if there is any information anyone can give me, I would be happy - but you are of course also free to tell me that I am insane/ have to wait a couple of more years/ or that it is only doable if you invest like 10K and up and then maybe.

1. *step_output_reg[X_AXIS] sets the pin high/low for a step in the X axis. For linear and arc moves, there are two different routines for setting the pin high. And this will set the direction for movement.
fastDigitalWrite(direction_output_reg[i], direction_bitmask[i], !current_move_ptr->direction[i]);

0=x-axis, 1=y-axis, 2=z-axis

Again, it is implemented in two different locations for arc vs linear.

2. enable_steppers() and disable_steppers().
3. This portion is what constitutes a completed move:
if ( move_finished )

1.Variables for targeted X,Y and Z Coordinates.
2.The variable for drive enable/disable.
3.Where to respond with a moveComplete=true.

I could post back my code mods if I get it going.
Thanks in advance.

Just found this : http://www.thingiverse.com/thing:14980
It's a gcode viewer, opensource, make in processing, with 3D etc …
Do you think you'd have a hard time integrating this into GRemote, to get something like a "preview" button ?

The new features include:

• jogging in both absolute and relative mode (using gcode parser and position tracking)
• jog settings with jog size (decimal + fractional) and feed rate (incl. seek/rapid option)
• multi-axis/multi-size jogs using "accumulate" button (XYZ/DEL)
• arc movements given direction, radius, start & end angle (ARCS/INS)
• homing to preset limits, separate for XY and Z
• zero and memory set/goto per each axis (HOME,END)
• baud rate selector
• keyboard shortcuts: try j, h, a, +, -, X/x, Y/y, Z/z
• scaling feed rates with inch/mm switch
• modifications to support Grbl (though it /support/ is far from perfect)
• console for Windows (must run GRemote.bat instead of .exe)
• many modifications/improvements under the hood, including
  • waiting-for-response state support
  • code cleanup/rearrangement though there's still a lot of work on this

Screenshot:

You solution reset the timer and prevent overflow run, but as negative result, it doubles the step interval. Motors sounds "noisy" in the acceleration phase (and I suppose they skip steps).

I have a better solution. On non-modified firmware, add a line after

  if (inTimer1InterruptRoutine) return; inTimer1InterruptRoutine = true; // set very long time to disable timer1 interrupt until we are finished here OCR1A = 0xffff; 

and replace

  OCR1A = timer1LoadValue; 

  OCR1A = max(timer1LoadValue, TCNT1+10); 

If the calculation time is longer than the wanted step time, next step will follow just after calculations will be finished.

Another problem of current firmware is variable (and not-predicted) pulse duration. I have added a code to set precise and configurable pulse duration using second timer. It is to complicated to write differences here, but it is about 10 lines of code total.

As a result, I can now get smooth motion with feeds 300 and even 500 mm/min without skipping steps. It is 2 times better than before.

chuck

chuck

Thanks for the tip I'll go stare at the firmware code some more as none of the other things I've tried have worked.

chuck

https://sites.google.com/site/chuckscncarduino/

chuck

Thank you for developing Gremote. That's exactly the kind of software necessary for Contraptor success.
I installed it on Win XP and got the same results as Anydany: The interface shows only the com port dropdown and the Gcode entry line. However, I was able to set the proper com port and and I could send Gcode sucessfully through the entry line. The Gcode was executed and returned an "ok".

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.

hope you can help to get it running… I have started your app under os x (old ppc) and I can only see the serial port dropdown, and the gcode entry line. all the other buttons are nonexistant in my UI. any idea? I haven't played around alot, just asking if you have a quick answer to that.

also when rebuilding the app from processing, I get no warnings. anyway, I am totaly newbie to processing… glad if you have an idea, thanks.

The data you have submitted contains following errors:

Guests and low-karma users are not allowed to publish links on this site.

chuck

Sorry, I guess I'm not allowed to put a link in.

chuck

After seeing a few serial errors on WinXP I'm now wondering if I need to add the checksum function with corresponding firmware changes. Somehow serial errors almost never happened to me with pySerial on Ubuntu. Not sure if it's the USB Serial drivers, or Java RXTXcomm..

chuck

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.

It works now! :-)

I screwed up… The first time I downloaded the firmware from sourceforge, the files lost their underscores in the process. I later added them by hand so that Arduino could integrate them to the main program; but I missed the underscore just before init.pde. Following your advice, I re-downloaded the firmware. I then noticed that there was an underscore before init.pde. I renamed that file as _init.pde and it compiled properly. It also uploaded to the Duemilanove 328 without problem. I use Arduino 0018 on Win XP.

Thanks for your help!

ProfScrew

It looks like you might have an old version of the interpreter - the current version doesn't have "CHAR WORD [128]".

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

 // now see if digits match checksum //================================= rsum = search_string('*', instruction, size); if (rsum == csum) return true; else { //... return false; } 

I guess the host software that goes along with this firmware computes the checksum and adds it to the line of GCode being sent.

Note that the above code sets limit switch inputs to high which means open only when ENDSTOPS_INVERTING == 1 in _init.pde - though the default setting is 1. Just to rule out limit switches, you can try setting ENDSTOPS_MIN_ENABLED and ENDSTOPS_MAX_ENABLED to 0 in _init.pde.

thinking that there was something wrong with my computer, I did try a netbook. fresh copy of arduino 21, reprap_new_firmware, and also tried the code posted above, again code would upload fine but no stepper movement. I could send the unit "x10" or "LMFAO" and either way it says "ok"

my current setup is just 3 pins, 2,3,GND and as i said before, i found a sketch somewhere that just ran the stepper to let you know its all hooked up right. I am not using any endstops, extruders, etc. hardware setup is a duemilanove and sparkfun easydrivers (only one of which hooked up right now.

my guess is I am missing a library or some setting in the _init file. thanks again for any help.

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.

chuck

// Arduino G-code Interpreter
// v1.0 by Mike Ellery - initial software (moc.liamg|yrellem#moc.liamg|yrellem)
// v1.1 by Zach Hoeken - cleaned up and did lots of tweaks (moc.liamg|nekeoh#moc.liamg|nekeoh)
// v1.2 by Chris Meighan - cleanup / G2&G3 support (moc.liamg|nahgiemc#moc.liamg|nahgiemc)
// v1.3 by Zach Hoeken - added thermocouple support and multi-sample temp readings. (moc.liamg|nekeoh#moc.liamg|nekeoh)

// v1.3a mmcp - removed extruder functionality
// - changed variable array called word (!) to array called aWord
// - added sum to serial comms

// v1.4 mmcp - extended M114 to report limit switches as well as co-ordinates
//============================================================================

#define FIRMWARE_VERSION "v1.4"

#include <HardwareSerial.h>

Here is the checksum function

boolean Checksum(char instruction[], int size) {
// compute checksum
// return TRUE if ok
// return FALSE if not
//====================

int i;
int csum;
int rsum;

// start with 0
//=============
csum = 0;

// xor each byte
//==============
for (i=0; i<size; i++) {
if (instruction[i] == '*')
break;
csum = csum^instruction[i];
}

// now see if digits match checksum
//=================================
rsum = search_string('*', instruction, size);
if (rsum == csum)
return true;
else {
if (DebugLevel > 1) {
Serial.print("line: >");
Serial.print(instruction);
Serial.print("< length: ");
Serial.print(size, DEC);
Serial.print(" received: ");
Serial.print(rsum, DEC);
Serial.print(" calculated: ");
Serial.println(csum, DEC);
}
return false;
}

If that is not what you were looking for I'd be happy to provide more.

chuck

chuck

Chuck

sudo ln -s /dev/ttyACM0 /dev/ttyS32

No ideas why I have 31 serial ports, but I did and I had to use 32.

I'm still not moving, but that could because I might be using the wrong G code interpreter.

chuck

chuck

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.

Other than 1', 1.5' and 2' lengths of 80/20 T-slot, it uses the standard Contraptor parts, with the exception of T-sliders, flat motor mounts and 3 custom belt lengths for Z axis. There are a couple of advantages of the flat motor mount over the current angle one - a) it's laserable, b) the motor center axis is on the line between mount points, c) it should also work with NEMA 17. I haven't extensively played with this mount in various arrangements (e.g. leadscrew), but so far it looks promising. I made a couple of prototype parts a while back, and I figured I'd use them here.

The motor assembly for both X and Y is mounted on nylon standoffs, which are cheap (<$10/100pk) and available in many lengths, including 1/8", 1/4", 1/2" and 1". There is often a need to add an eighth or a quarter inch of a padding between parts. The spacers/standoffs work well for that purpose in most places, unless there is only one attachment point (in which case parts turn relatively easily), or if surface to surface contact is needed for rigidity. For example, in the video below, a couple of 1/8" spacers would replace the orange plexi piece.

Finally, I assembled and tested leadscrew-driven T-slider on 1' T-slot, just as a sanity check for any unexpected issues. I've been able to run it at 15 IPM - any higher would stall the motor, but I think it's because I'm not using Contraptor standard motors for this test. Again, it's grblShield (1/8th step) with Arduino GCode Interpreter firmware. The test script basically runs the axis up and down:

The element doesn't resist twisting so it either has to be loaded with weight from the top (like the Y axis in the sketch) or there should a connected pair of these opposite to each other (like the Z axis). The belt drive results are encouraging so far and I want to see how easy the friction adjustment would be in the opposite pair arrangement.

How will you drive the Z axis ?

How well does this work compared to the linear bearings ?

How much "play" does it have ?

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.

About microstepping, at the spped 1/2 stepping makes a lot of noise, it indeed makes things much better.
But I have found that ( when changing to microstepping ) the noisy range does not dissapear but moves ( eg. happens at different speeds ), and that the range of speeds at which this happens reduces too.
The thing to be careful about is that while you get less vibration, and vibration less often, you loose much more torque when the vibration happens with microstepping than with half stepping. Meaning that with microstepping you have more chances that your axis actually "blocks", while with half-stepping, you get a lot of noise, but you get less chances to block.
In the end, you can get a microstepping set-up to never block, mostly by fine-tuning the current setting, and having a well-aligned machine.

Having a nearly silent machine is very pleasant. Of course it looses a lot of it's charm when you turn the dremel on :)

For the contrapteur mini-cnc I'll be trying every ( lasercuttable ) material I can get my hands on for the dampening, so you'll hear about what works best :)

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.

If you want metric extrusions, I can send you some contrapteur :) ( the sample I already have here is not good enough to sell, but is good enough to use ).

Aluminum extrusion like that would be flat so easier to punch (though still added cost comparing to just an extrusion like T-slot). I also backed Makerslide, looking forward to play with it… will probably need to get some metric extrusions.

The idea is to make something lasercuttable ( or extrudable if needed ). Picture :

The goal is to have the same functionality as the makerslide rail : 

but using the aluminium angle as support ( or anything with 20mm dimensions ), and a plastic part as the rail.

The holes and shape of the plastic rail can be lasercut directly. But for the "rail" part ( the angles at each side ), you need a special holder that will hold the parts at 45 degrees angle inside the lasercutter.
About material, I'll use acrylic for the first prototypes as that's what I've under hand, but Acetal is probably better in the range of lasercuttable plastics.

For price, with acrylic it should cost almost nothing, and with acetal, less than 1$/feet ( not including the aluminium angle ).

More on that when the makerslide kits from the kickstarter project ship.

Pre-drilled V-track is available here: http://www.qbcbearings.com/BuyRFQ/LinearB_Track_VG_P.htm# (BK#COM-T107250D), but it's pretty steep $13/ft unhardened or $17/ft hardened. Plus they have very limited quantities.

AL 5/16" bar could probably be swapped for 1/4" bar ($0.75/ft at Onlinemetals), and something 1/16" thick under it, but then pre-drilled track may not work since the holes are centered in its inner wall which is 5/16" tall.

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.