Well this seems to be an opportunity to good to be missed!
A friend of mine was throwing out (THROWING OUT!!) the aforementioned CNC router. Well he wasnt, his educational establishment employer was. so it was rescued for me.
A quick flick through the manual indicates that either the manual is for a slightly different machine, or the machine is missing some vital bits, including a futuristic "memory card device reader" and a data input keyboard As it stands, i think if i repaired a few dodgy wires the control would be a manual, real time game pad style controller. (a bit rubbish!) or require interfacing with a computer from the 90s (which i dont have).
However my last project was my V plotter:
https://www.robotshop.com/letsmakerobots/node/35846
, which i got running GCode in the end. I dont see why i cant just chop off the existing mid 90s controller box, and replace it with an Aruino and Motordriver wired straight onto the motors, and lift solenoid. The V plotter already handles GCode off an SD card, so why cant i get this bad boy milling GCode?
I might remove the milling head and replace it with a marker pen to start with, but once that is under control i dont see why i cant put it back together with a "dremel" style chuck. I could even use it as a "stacking layers" type 3d printer too?.
Is anyone else as stoked about this freebie as me?
On the off chance i actually succeed on this project, ill mill y'all some custom PCB's?
13/01/2015: It lives!
having pulled a few covers off, and had a bit of a fiddle, i found that the motor drivers are contained within the Box on the bed, and the "control" is provided by the key pad, with very little overlap of functions. In short, i can just replace the keypad with an arduino and have to very little in the way of electronics.
Thanks to a bit of a nudge and advice froom Bdk6, i traced the copper tracks across the bottom of the motor driver PCB, and have worked out which pin on the ribbon cable connector, connects to what (for the most part at least)
Unfortunately, in my excitement i forgot that the ribbon cable not only recieves communication from the control pad, but provides the control pad with power. As you can see from the second picture above, i neglected to secure the other connection i wasnt using, resulting in a short and (thankfully) a blown fuse on the motor driver box. I dont have any fuses in stock, so im at a stop till i can get to the hardware store tommorow, but it did move!! Confusingly, the wiring on the steppers, does not compaer correctly to the pinouts on the datasheet. this is the next obstacle to overcome. In the mean time, i have soldered ALL the wires onto two strips of proper headers so that i can use a breadboard effectively, rather than try and stuff lightweight multicore copper into the board.
For your information, and for my reference when i inevitably lose the notebook i have written it down on, the pinouts are as follows (1 - 15, with the numbers actually marked on the plug. a question mark denotes that this needs to be confirmed):
- Y axis - yellow wire
- Y axis - red wire
- Y axis - black wire
- Y axis - orange wire
- Tool Motor (can be manually over ridden to permenantly on by rocker switch on the controller)
- 0V
- Connects to switched power rail. pin returns 3V when the board is live (safety lid is closed)
- 13V
- X axis - orange wire
- X axis - black wire
- X axis - red wire
- X axis - yellow wire
- 0V
- Tool lift Solenoid
- 13V
The current plan is to get it going with a breadboard, and then buy an arduino SD card shield in order that i can solder it all up on the proto area and use GCode from the SD card as data. i should also have enough spare pins to use the interupts as stop switches, allowing me to add a datum function.
04/01/2015
I replaced the fuse, and secured the wires. Having had a read around (http://library.solarbotics.net/pdflib/pdf/motorbas.pdf) and a play with a multimeter to confirm wiring of the coils (the data sheet is definately wrong) I found that a little sketch gets everything spinning nice and strong.
I found that lowering the delay below 12ms caused the motors to get tripped up, but i pressume that is because the coils take a certain amount of time to energise, and the shaft takes a certain amount of time to move. pulsing the highs and lows too fast doesnt give it enough time to move to the new position? Either way, 12ms runs about as fast as it ran under manual drive, so it should be fast enough.
Now to get rid of the delays, and build some code so that i can move each motor both backwards and forwards with simpler commands (which is building a library i guess?)
06/01/2015
I got a bit confused by the wiring. Swapping the wires that were successfully running the X axis motor, didnt run the Y axis motor as they should, and visa versa. The problem was this: Wires coloured Yellow, Red, Orange and Black, running through transistors labeled T1 to T9, through a pin out on the connector 1 - 15, trough matching coloured jumper cables, to pins 1 - 13 on the arduino, was just too much for my little brain to keep track of.
Then on top of that, i was just not getting my head around pushing bits back and forth in arrays. In my bit pushing research i found there is a stepper class already included in the arduino libraries, which reminded me i had found an excellent stepping library already, that was serving me well on my V plotter.
Not really sure why i wast bothering with manually controlling the steppers in the first place, other than to work out the pinouts!
Still, hurdle overcome (or more crushed by someone else)
http://www.airspayce.com/mikem/arduino/AccelStepper/
28/01/2015
What with this that and the other, this kind of fell by the wayside until today. Anyhoo, I was having real problems with the motors not moving smoothly. In my frustration at the "limits of the hardware", i loaded up a basic "stepper party" sketch and gave that a whirl. WOOSH. they all shot around perfectly smoothly and quietly. (and FAST!)
Turns out, the Accel stepper library REALLY doesnt like being interupted while it's working. I was asking it to send the location to the serial port as it was working, and this was really slowing it down. (obviously, nooby mistake i guess)
Anyway, in the past hour i have butcherd my polargraph code, wired up the SD card breakout, and produced a sample GCode test path. It lives! I am now at the stage where i could wire it in properly and worry about the code!
When I had put the polargraph to bed last spring, i was begining to look into how to interpolate two points in the GCode, the sketch currently just moves between two points as fast as possible (G00), meaning the shorter move axis gets there first, resulting in a dog leg in the cut (or currently, pen line).
I think the obvious thing to do would be make a "Case Switch", which references each G instruction, and carries out slightly different maths for each job.
These are the G codes i anticipate i will need. Some are just a case of toggling the tool on or off, others will require work.
M3: Spindle Run (CW)
F: Feed rate (Stepper max speed)
G21: Define prgramming in mm
G00: Rapid Position: Move fast (without interpolation)
G01: Straight line cut
G02: Clockwise radial cut
G03: Counter clockwise radial cut
M5: Spindle Stop
M2: End of Program
I think to start with i might assign things like to the feed rate to an analogue read potentiometer, so that i can change it on the fly.
10/02/2015
Ive been working on G01. Initially it worked quite well adjusting the speed in accordance with the ratio of the XY distance. But it wasnt quite right.
Now i have worked out a sketch where by it works out the difference between the two points, divides it by an iteration (say 100), then moves to each of the 10 points in turn using a for loop. (ie, moveTo: the first position + (the total distance /100) * i))
I think due to the rounding effect of the code, it ends up a shade short of hte target, but this only ends up being a fraction of a mm in real terms, so upon finishing the last iteration, i then tell to go to the original target, just to be sure.
it works well!
For now i am going to use the same movement profile for the curves too, but i might see if i can get my head around the maths some time....
29/11/2015 It Works better
Ive been off for a while, summer, outside and all that., with the drawing in of the nights i have returned to the CNC thingy that has been gathering dust on my side desk.
Curves have proven a little more difficult than the above, and it still isnt perfect, but its getting there and i can work around the one remaining fault for now.
Getting the arduino to take the existing coordinates, target coordinates, and the offset of the "pivot point", calculate the hypotenuse of the triangle created, and then re run the calculation for every point between the two positions, while working within the limitations of the arduino, has been emotional. I do however, have it cracked (ish). Very shallow curves are set to be straight lines, as the hypotenuse of the "pivot point" of the curve causes the arduino to overflow and crash.
Also, my code is restricted to curves within the four quadrants of a circle. what i mean by this is: it can do a curve from 12:00 (o clock), to 3:00, 3:00 to 6:00, but it cant handle curves from 1:00 to 5:00, due to the curve turning in on itself.
Still working on this, but not sure if i might have to totally rethink the approach the sketch takes to get there.
I have also written my code, so that it i run it with the interlock (lid) open, it runs the sketch as fast as the arduino clock will go, and produces a Comma Seperated series of coordinates, that can then be dumped into excel and plotted as a scattergraph. By doing this i can quickly assess the tool paths and work out if there are likely to be any faults.