CNC Success
Success!
I was showing a friend my progress with the code, and he was complaining that the stepper motors were loud, and suggested I turn on fractional stepping. I switched to 1/16th steps, and he was right, the motors sounded much better. Additionally, the Z-axis magically started working! I was also impressed how well my code handled high stepping rates — well, more surprised that it worked without more surprises. So I’ve passed a big hurdle. I need to test the circle routine (pretty much the only piece of code I’ve not rewritten from the original code base), do some more tests, and try milling my first PCB!
Here’s a quick video demonstrating it moving in 3 axis at different rates, 1/16th step.
You can browse the latest version of the code here: http://code.google.com/p/rsteppercontroller/source/browse/
I’ve been looking for something like this! Currently I’m testing a similar program called grbl (http://github.com/simen/grbl) but would like to give yours a try too. What settings do I need to change in order to get this to work with my setup? Send me an email with basic instructions if you have time: (edward at edslifedaily dot com)
Nice machine!
Nice, I’m going to have to have a look at the code. I’m in the planning stage of building a CNC router aimed at milling prototype PCB’s. I’m going to use a home built controller with an ATxmega64D3 on it though. I will write the code in C/C++ (I personally like C++). I have a 5inch LCD touch screen(160×128) that I have made for a customer that I will be using for the CNC mill interface (it has an ATmega2560 as the main processor).
Keep up the good work, looking forward to reading more progress updates
Thanks, Brad
i’ll update the code for you — it’s pretty simple really, it takes in gcode and spits out step/dir pulses. in comparing it to the grbl code, it seems that the biggest difference is that i spend a lot of effort ensuring that the steps are correctly spaced with sub-microsecond resolution and I use the arduino code-base to simplify the implementation, but i can’t do this and be asynchronous. for my application (PCB mill) it doesn’t make a difference as I handle one command at a time – but for extruder based operations, the addtional delay of parsing lines will cause problems. Finally, I’ve been having issues with the arduino latching up as of late – which I’m guessing is due to EMF problems. I’m going to try adding some ferrite shells around the cabling to see if that will help fix the problem. otherwise, the grbl code looks like it’s well written.
I have been playing with your code to use on either Pic32mx or an Arm – which for me, means making it compile as a ‘C’ program and working around the ‘FAVORS’ Arduino and G++/C++ seem to do.
Anyway, in the R16 version of rsteppercontroller.pde – in your setup() function, you need to move the first call to getMaxFeedrate() after the call to init_steppers() – xaxis, yaxis, zaxis are initialized in init_steppers(), and being pointers, that could be an problem.
void setup() {
…
_feedrate = getMaxFeedrate();
//reprap init code
init_steppers();
Keep up the good work.
Bob.
Thanks. Just uploaded R17 with the fix. -reza
Yeah, it’s a bit of a pain dealing with the arduino-ness of it all, but my goal is to make it more accessible to more people, and the arduino platform is quite popular. been meaning on building an arduino shield which incorporates the stepper hardware to make it even simpler.
Hi
In The rsteppercontoller file init.h thet are 3 binary bit shifts ie
#define _STEP_X (1<<3). Why are these used or needed.
Thanks
Clive
I just searched the source and found this..
xaxis->direct_step_pin = _STEP_X;
yaxis->direct_step_pin = _STEP_Y;
zaxis->direct_step_pin = _STEP_Z;
For the arduino, you can specify a pin by a number. but that actually maps to a port and pin number. The default code implies that port B pin 3 is what it is physically connected to it. The arduino library adds a lot of overhead to the code to make it simple to use. by accessing the pin directly, it is much faster for a time critical application.