Who is interested in working on a propeller driven CNC control?
ddstarkey
Posts: 6
Who is interested in working on a propeller based 3-axis CNC control for a stepper motor driven CNC machine? (Router, Plasma burner, Mill, Lathe,Laser, etc.)
I have written and tested the linear & circular interpolation code in PASM but I am running out of steam on the SPIN front end.
What I have so far works but is far from a finished product. I would like to focus on optimizing the PASM code.
E-mail me if you have interest in working on this project.
Don@StarkeyMail.com
I have written and tested the linear & circular interpolation code in PASM but I am running out of steam on the SPIN front end.
What I have so far works but is far from a finished product. I would like to focus on optimizing the PASM code.
E-mail me if you have interest in working on this project.
Don@StarkeyMail.com
Comments
My design goal was to make an inexpensive high quality CNC controller for the hobby market. I played with TurboCNC a few years ago and felt that it worked fairly well but the user interface was rather primitive. There was also a limitation on the step rate but that wouldn't be an issue today with the speed of today's processors. It ran on DOS (not windows).
With the advent of the propeller, I felt that the multi-core design lends itself to this type of application and thus began working with steppers controlled with PASM code. The timing issues are working great in PASM and the movement is nice and smooth.
My test CNC machine consists of a 3-axis gantry type milling machine. I have 1-each stepper motors on the Y & Z axis and 2-motors on the X-Axis (one on each side with a connecting belt between the lead-screws to prevent misalignment.) Both X-axis motors are paralleled. I am using some older Superior SD200 stepper motor drivers that can source 2.5 amps each. I might change these out in the future as my motors will handle higher current. At the ends of each axis I have limit switches to detect overtravel. My schematic shows simple switches on each end when in reality, I am using optical detectors to sense when each axis is "home" as well as an +overtravel condition. I don't know for sure but I think this will provide more accuracy.
I also have a I2C analog-to-digital converter chip and a pot as a feedrate override control. This give me 0-200% of the programmed feedrate with the turn of a knob. I hate the Up/Down arrow feedrate control for a number of reasons. 1. Its not intuitive and 2. it messes with the acceleration/deceleration profiles and could be the source of missed counts as it causes abrupt changes in the speed. I thought about using the RC timing method using a pair of the propeller's pins but I had the I2C chip ready to go and it works well.
On the software end of things, I am currently using 7 of the 8 cogs.
The first cog is the SPIN interpreter that runs the main user interface. It then launches the following cogs.
1 Serial Driver to communicate with a serial terminal on an attached computer.
2 F32 Math Routines used by the circular and linear interpolation cogs.
3 Circular Interpolation - My implementation of Bresenham's circle algorithm.
4 Linear Interpolation - My implementation of Bresenham's line algorithm.
5 Output Driver - communicates with the step drivers and handles the timing.
6 SD memory card driver
This leaves one cog for other functions.
In the interest of time, I decided to use an external serial terminal to display and communicate with the user. My thought was that most people now have laptop computers that they can bring to the shop. I would prefer to program on a real computer than on a CNC control. I wanted a terminal that would handle addressable cursor, colors and automatic scrolling and free as a download.
I found a VT100 terminal emulator program called "Tera Term" that seems to work. I figured that once it was configured properly, the configuration file could be distributed along with the CNC program for others to use with minimal tweaking required. I have one problem with it that it seems to "stall" periodically and then come back to life after some time elapses. I don't know why this is happening but it is low on the to-do list. The thing I don't like with the PC based terminal is that I am once again forced to use the up/down/left/right, etc. keys for jogging. I have an encoder type "Manual Pulse Generator" that I thought about using but this is a fairly expensive luxury that most people don't have and I didn't want to base the control on expensive hardware.
I am currently storing the CNC programs on a SD memory card (not currently shown on the schematic). SD memory cards are cheap and work well with the propeller. I would have liked to use USB instead but the parallax USB hardware I got a few years ago wasn't ready for prime time. It worked but not with the newer USB thumb drives. There might be a firmware upgrade to fix this limitation.
The heart of the project was the linear & circular interpolation routines that I wrote in PASM. These are based on Bresenham's circle and line algorithms. Both calculate very quickly using integer math and are very accurate. My implementation extends these to work with floating point numbers at the expense of longer calculation times. I have some ideas for improving the calculation time. Right now, they can calculate faster than my motors can step but I think it can be improved. With 4000 Counts/Inch, I can move at maybe 100-IPM. I have acceleration and deceleration at the beginning and end of each move. This works ok but again, I think I can make some improvements where no decel/accel is needed.
Both interpolation cogs feed the output driver cog. It's purpose is to handle the timing, control the stepper drivers, check for overtravel and some other minor functions.
With 65536 steps per inch you'd have +/- 32767 inches of workspace, and both those numbers are well beyond the values used by machines I've seen in practice. Just curious more than anything - I haven't tried to implement anything like this, but given that Bresenham's algorithms are integer based, it would seem to be a good fit.
By using longs, the numbers so fit. Because of the way Bresenham's works, the arcs/circles starts at 0-degrees. For a CNC control, I needed a way to detect when to start moving along the circular path. This involved some trigonometry which led me back to using floating point math.
The propeller-chip has an inbuild sinetable I don't remember the resolution. But I guess it es enough too.
Did you consider this?
best regards
Stefan
I've considered making a controller that just broke curves into very small line segments, representing their end-points as step counts. You'd use one cog to interpret the line / arc commands and feed the outputs into a buffer that contained the resulting line segments. Then use a Bresenham line routine to actually output the step commands for the motors. I wrote one a while back for a PIC chip that did this (as a test), but it only supported lines, and I still haven't given any thought to acceleration curves and where that logic would go. That's where things start to get tricky.
Good point. From section 5.1.4 of the datasheet, 2049 unsigned 16 bit sine samples covering 0 to 90 degrees is 0.0439 degree increments
(use symmetry to get 360 degrees)
cheers
tubular
There's a couple folks that are interested and discussing this on a couple other threads.
The one I started is http://forums.parallax.com/showthread.php?129448-Prop-based-CNC-3D-printer&highlight=prop+based+cnc
Right now we are finishing up our development envirionment, there should be some extensions for CNC this spring.
The goal will be a drop in replacement for the current Sangino electronics used on the RepRap machines.
My part of the project uses Forth as the develpment environment, but the algorithms and PASM bits should be similar. We can swap ideas and code when we get to that point if you are interested.
If there is interest out there for a lightweight CNC control for homebrew milling machines, this certainly could be a very inexpensive answer.
I have already cut parts with the software but I am looking for some help on the user interface (G-code parser).
If you are interested I can post my code. It's not completely finished. My code can divide a G-Code commandline like
"N007 G01 X100 Y200 Z300 F150 .... " into its parts meaning G01 the command itself X100 the x-coordinate etc.
best regards Stefan
Don't know if this is what you have in mind, but we are looking at re-using the entire RepRap tool chain so that all we need to make is "firmware" for the prop, and all the rest of the work (to generate the models and slice into G code) is done on the PC or other external work station.
I haven't looking into milling yet. Is there some existing tool chain for milling that you can re-use?