DC motors + RepRap + Arduino

[I've just joined the forum so sorry if this has been discussed before or I am posting in the wrong place]

I'm trying to evaluate RepRap to determine if it will work in my project and save me from reinventing the wheel. The project is a drawing machine- an art project - basically a 20' x 20' XY plotter. I've built the rig and drive it with Maxon DC motors that have tacho encoders. I'm using synchromesh cable so the movements are accurate enough for my needs. I've built some DC motor controllers and use Arduino to do the speed PWM and read encoder states. I am able to rout commands to the Arduino from a desktop app through the USB port.

I've gotten stalled on writing a trapezoidal velocity profile type routine and searching around for some examples came across RepRap again- and was very excited to see the work @ using Arduino. It got me thinking about revising my project to do some crude 3D "printing" using clay slip.

Anyway- I have a few questions ;-)

--I've looked through the source code and it doesn't seem like there is any velocity control going on for the steppers. Did I miss it?

--Am I wrong in thinking I can adapt RepRap to use these DC motors? It seems like if I can solve the velocity control thing I can get it to work (the reason for not using steppers is that the ones I have tried are too slow)


Hope this is not too far off topic + thanks for any tips!

(oh - in the post discussing Arduino there was mention of the Wiring board. I've mostly used Wiring for my projects (http:www.roypardi.com) and it's great, with lots of I/O capability, memory, etc.)

--Roy

Edited 1 time(s). Last edit at 12/29/2007 02:12PM by roypardi.

Roy,

I haven't looked through the actual source code yet but the program does have a stepper exerciser dialog that has speed control sliders for the steppers. This leads me to believe that velocity control is adjustable in code. Could be changed in code on the fly with a bit of fiddling on your part.

Hope that helps.

Demented

Hey Roy,

I wrote most of the Arduino code so hopefully I can answer your questions.

1. the current code is setup to control steppers, but you could probably adapt it so that it uses DC motors + encoders with a weekend of solid programming. infact, i'd love to see that as its one of the things i'd like to do at some point in time. (this is one of the major benefits of arduino... is that you can reconfigure the electronics really easily, write new code and be good to go.)

2. i'm not 100% sure how speed control works since i've only implemented the firmware side of things, but for most of the movement commands (seek, DDA, etc) there is a speed parameter and a position parameter. since you're looking at DDA movement (coordinated X/Y line drawing) the host software will take the max speed you set, calculate the lower speed for the dual-x/y movement, and then send the commands. the speed is sent as a 1 byte value (0-255) which makes it pretty well suited for DDA.

i think that we could come up with some sort of way that RepRap could drive your electronics. we could probably come up with a hacked version of the host software, and some custom firmware. you'll probably have to code alot of it yourself, but i'm definitely interested in helping. the biggest things i would love is to see is your tach/encoder code, the circuit schematics, and then from there we can work on getting a non-stepper firmware going as well as a hacked firmware to do simple 2D drawings.

let me know what you think, this sounds fun and exciting!

Hi Zach-
A big thanks for the Arduino code! I've been looking through it a bit today but haven't really dived into it yet. One thing - Arduino squawked @ the sketch names beginning with a number and wouldn't load them. Adding a char before the name ("s3Axis_SNAP.pde") fixed that. I guess that is a restriction of the IDE. Fwiw - since Arduino is based on Wiring, any Arduino code will run on the Wiring board (at least in my experience. I've using the Wiring board more than Arduino). So the discussion @ using 2 Arduinos, etc. - maybe the Wiring board would serve since it has more I/O, etc. Of course it is more $$. I got one of the Freeduino kits last week for $17. and had it soldered and tested within a half hour. That's hard to beat!

Prior to considering RepRap (and I have also been looking at EMC2 (http://www.linuxcnc.org/ - but there seems a lot of complexity/capability with that that I don't need/don't understand) I was thinking along the lines of:

--all the motion control is on the Arduino/Wiring board
--logic and image processing code is on a desktop-based app
--an XY position is sent to the Arduino/Wiring board, it does the move and reports back when it is complete. That board also controls the "print head" (I used a simple solenoid valve in an earlier version of this project), so a "print" command is sent.

The thing I got stalled on was velocity control: since this rig is fairly fast (which is what I wanted) I didn't want it to jerk at full velocity to each new position. By PWM the DC motors I can ramp up/down the speed - I just haven't figured out the routine for that yet (have tried some stuff with cubic easing but haven't worked it out yet. I'm mostly an artist with some basic programming chops).


Anyway, the encoder stuff is fairly straightforward. Using a hardware interrupt on the Wiring board, when a change is detected the interrupt occurs and a counter is adjusted. I've found this to be very accurate- though it needs the velocity adjustment part to "stop on a dime" and not over shoot because of momentum.

the barebones encoder stuff is below. I stripped out the rest of the routines to simplify things.

--Roy


int Xencoder0PinA = 2;
int Xencoder0PinB = 15;
int Xencoder0Pos = 0;

void setup(){

//---------------------
Serial.begin(115200);

// Set up X axis
pinMode(Xencoder0PinA, INPUT);
pinMode(Xencoder0PinB, INPUT );
attachInterrupt(Xencoder0PinA, XdoEncoder, CHANGE);
}

void XdoEncoder(){
if((digitalRead(Xencoder0PinA) == LOW) ^ (digitalRead(Xencoder0Pin == HIGH)) {
Xencoder0Pos++;
} else {
Xencoder0Pos--;
}
}

hey,

hmm... i've never had a problem loading them. thats strange. did you open them from a folder with the same name? anyway, minor problem. i'm sure the firmware would run on processing with very little changes. its definitely something to look at if we need.

as for velocity control, you could probably just consider the speed from the microcontroller the 'top speed'. i dont have an algorithm for you, but you could probably do something with some sort of lookup table where you have the pwm values you use as you ramp through the various speeds and just stop when you get to the max value you got from the host. its a tricky problem we havent really tackled yet (we still dont move our head too fast) you could probably do it all in firmware.

as for your other requirements... you could do that very easily. reprap is basically setup that way already. it might be a bit of a challenge for you to modify the host software to do what you want (or maybe not). there are a couple routes you could take:

1. hack the host/firmware to do what you want. you could either create STL files that have the drawings in them (ugly route) or add the ability to load whatever format files you want and print those (pretty route). right now the software is setup to pretty much only use an extruder, but you could hack the extruder firmware to work for you. the major commands are set temp / get temp / set extruder speed. you could hack the get temp command to return the set temp value it passed to you. then for the setspeed command just use that value to turn on/off the solenoid (its used to turn on/off the motor for the extruder)

2. write your own custom interface code. i think this would be very cool. the low-level commands to the extruder / cartsian bot are very simple. we have fully documented them here: [www.reprap.org] you would just send the commands you want and it would be very flexible.