What began as a small proof of concept laser engraving build quickly flourished into a large scale multi-purpose machine.
I started with a small X/Y CD tray setup driving by a raspberry Pi using custom software to interpret the g-code and inkscape to generate it. Here's a pic of that initial build:
I was using a 2W 445nm laser diode with manually adjusted power to cut/burn. Once that was working I then modified an inkscape extension which when all complete allowed me to rasterize an image into g-code changing the feed rate of the laser to vary the darkness of the pixels it was burning. It worked reasonably well given it was something I hacked together, but the small 1.5" x 1.5" work area left me wanting more.
Further I had the RPi turning the laser on and off through one of it's GPIOs as well as controlling the stepper motors for motion, but any adjustment to laser power had to be done manually through a trim pot in my circuit.
So this resulted in me wanting to scale up to a larger bed size to be able to do "normal" size objects. That quickly migrated into adding laser power control and eventually the desire for a Z-axis. Oddly the Z-axis originally was simply to prevent having to refocus the laser every time a different thickness of material was used. I could simply focus it on the bed and then adjust the z-axis when needed based on the material height.
Once I had a working Z-axis though, I realize if I expanded it to a larger height I already had most all the workings of a 3D printer. I had wanted a 3D printer for ages but never had the time or money to invest in one. Having a second purpose for the machine made it all the more lucrative to build and build right.
Yet again I realized during the design phase that if I did it right I could easily add a spindle (probably an RC motor since I have several of them laying around anyway) and have a decent milling/routing machine as well.
So ultimately this will be a machine that's capable of laser engraving and etching wood, plastic, mirrors, burning grey scale images into wood, and cutting various materials and light woods. It will also be able to route/mill wood and light metals. When the subtractive process gets a little boring then it'll just be another simple swap to start printing with the additive process!
Here are a couple images of my initial design. Well, actually it's a second design as I decided to heavily modify the first after discovering that the parts and setup of another open build project I was basing it on wouldn't actually work!
I'll be using a Belt and Pinion system to drive the axes. The bed will move on the Y axis, while the entire X aixs carriage will be driven on the Z axis. The end result should give me a good stable platform with minimal wobble/backlash while still supporting a large build volume and minimal structure.
Update 12/29/14: My parts arrived over the holiday weekend and I started building. The frame is built and motors and linear motion is working great.
Now there are two initial problems I need to get squared away. I'm hoping they'll be simple to address but until I have a chance to dig deeper I just won't know.
1) The Z axis starts off out of level. When the motors are disabled and the carriage drops the left side drops about 1/32nd" lower than the right. Oddly a quick examination couldn't determine the source of this. In a worse case scenario I'll simply install some hard stops in the channel that will be adjustable. The extra height shouldn't be a problem as it extends much lower than it should ever need to anyway and my "head" can just extend lower anyway to make up for it, ultimately it would just result in a possibly shorter work area height.
2) The "runner" for the table mount seems to be a bit confusing. There is no play or noticeable flex, yet it initial examination seems to show it running in a bow. I.e. when the Y axis is extended all the way to the bottom (i.e. 0 orientation point) the runner seems to be tilted ever so slightly up in the rear. When extended to the top it's tilting up in the front. Exactly the opposite of any anticipated problems. I was afraid the weight extending that far beyond the gantry could result in it pulling the front or rear down at extended positions, but instead it's doing the exact opposite and coming up. It really doesn't make any sense but I need to really spend some time with it to try to figure it out.
I'm also starting to think about what to do for the table itself. One thought is to run a few supports from front to back then use pieces of 20x20 with brackets as adjustable clamps. This would also give an easy way to mount a pane of glass (with or without hotbed under) for when it comes to the 3D printer portion as the glass could be captured in the T slots front and rear and/or on the sides. It would also allow easily securing a piece of waste board for routing. I'm just not sure what my best option is at this point to keep the weight and costs down yet be able to clamp whatever I need into place.
Updated 12/30/14: Got a bit more done last night. It's starting to come together nicely.
I got the above mentioned problems sorted out I think. The initial problem with the Z-axis I sorted out by doing exactly what I mentioned. Despite the brackets being in place correctly the screws themselves were skewed a bit and causing one to hit a little sooner than the other (on the delrin wheel). Aside from the issue of not being level, I also didn't like the fact that the wheels were hitting on such a small point like that when powered off. So I cut two small aluminium plates to install on the inside of the Z-axis support. The top of this plate hits flush with the gantry on either side, so it allows me to adjust the starting point easily as well as providing a good solid metal to metal surface for a stop.
The second issue with the Y table support I think I've resolved as well. First it occurred to me that it really isn't as critical as I was thinking it was anyway. The tool will always be at a fixed point on the Y axis. As long as that fixed point doesn't change (which it doesn't) it won't make any difference what it's doing at the extreme edges. On the other hand, I still wanted to address it as much as possible. I loosened some of the brackets up and re-squared everything. I'm guessing something was in a bind because once redone the table is perfect.
In the mean time while diagnosing this issue I did find that there was a slight amount of flex in the table when extended to the extreme positions. A larger weight off balance large item might have flexed it a bit and caused some issues. I doubt it, but again, address what I can when it's easy. So I installed another support brace under those two. This also rests flush on the surface it's sitting on so helps to add additional support.
Next up was getting the diode module mounted in the heat sink. The heat sink is an old CPU heat sink. I decided to use it because I had a bunch of them laying around, plus it has large copper core and the fan makes it perfect for not only removing heat but also removing smoke away from the lens.
Once that was complete I mounted the laser head to the gantry plate. I tossed around a couple different ideas, but in the end decided on what I felt was the most simple solution. A couple of screws into the side of the heat sink securing an L-bracket, which then mounted to the plate. This makes it easily removable yet also provides a very secure mount. There's no flex or wobble in it.
Here you can see the bracket as well as the Lasorb which will protect the diode from ESD and transient spikes.
On the top support brace I mounted a 12 terminal barrier strip. The connections for the 2 Z-axis motors and the X-axis motor will be made here. The Z-axis motors will have the wire tucked into the channel nicely, while the X-axis will need to float. A 12-conductor wire will then run from there down to the xPro.
Update 1/5/2015: The build has been completed. I'll post more pics soon. Initial testing was very positive! No noticeable backlash or wobble. Laser could be focused as small as .07mm which would give about 360dpi. For speed considerations I will probably slightly defocus to give a larger size and shoot for around .15mm or so.
I did find one issue, which I hadn't considered. Wood burns much easier than I thought. The usable power range when focused to a .07mm dot is about 150mA to 500mA of current through the diode. Given that this diode can handle 1.8A comfortably that meant that there were only a few of the 256 steps (on the PWM output) that fell into the usable range when adjusted to swing full power. However, if the swing was adjusted down so the 256 steps fell into the usable range, that meant it lost it's cutting ability. So the solution was to modify the laser driver to make it have two switchable modes. Low power and high power. When in high power mode the 256 steps cover from 150mA to 1.8A. When in low power mode the steps cover 150mA to about 550mA.
Unfortunately in doing so, and working way past my bedtime I made a 3am mistake that resulted in the death of my diode. While I'm waiting for the replacement to arrive, here's a rough schematic of the control board and control panel. I'll get some additional pics of them posted soon.
A couple of notes here. Originally I was going to put limit switches on both ends of all axes. I quickly realized that this really wasn't necessary. My motors don't have the power to torque anything or do any real damage. Worst case scenario they may snap a belt, but most likely it would just skip some teeth and maybe add some additional wear on the belt. Besides, with GRBL having soft limits built right in to the code (I tested this and sure enough the moment it gets a command that moves it outside of the usable area it drops into alarm mode and must be reset) there just isn't really a practical need for it. For soft limits to work however, and more importantly for the reliable positioning it offers, I did install and suggest using one limit switch on each axis for homing.
Here's is the Y-axis homing switch mounted directly to the gantry. A single L-bracket acts as the contact point for this switch.
The X-axis switch is a little harder to see in this pic, but I used a single L bracket attached to the Z-axis gantry to mount it. The V-wheel is actually the contact surface for this one.
And here is the Z-axis, again on a single L-bracket and using the V-wheel as a contact point.
The 12-contact barrier strip was replaced with a 16-contact one to give 4 additional connections for the fan and laser wires. Originally I was going to run these separate but figured for simplicity it would be better to just put them all on one strip.
I'm supplying the CNC xPro with power from an ATX power supply. This also activates the 12V input to function as a 12V output which I'm using to drive a small fan (from a CPU heatsink) mounted in the box containing the CNC xPro. I have not sinked the drivers and don't anticipate any heat related problems from them given the max current for the NEMA17 motors is 1.68A. The fan is in the top of the enclosure and I drilled air holes all the way around the bottom, so circulation should be good inside the box. If I do find a problem I'll just add some small heatsinks.
Here's the ATX power supply (bottom) and [email protected] power supply for the laser as well as the box for the CNC xPro. Yes it's sloppy, but I'm not going for perfection here.
The laser driver is the 3A Russian version available on Ebay. It's basically the only thing in the build that's not open source. However, it's easy enough to construct something on your own to do the same, it was just way easier to use something pre-made. I've talked to the guy who makes and sells these and he's a great guy who is very willing to help. He even offered to send me some spare parts for free when a rogue screwdriver accident resulting in demolishing one of the surface mount resistors on the board. Anyway, the driver can drive up to 3A and accepts a modulated analog (or in my case PWM) input. Originally I had run the math and created an RC low-pass filter to run the PWM through before hitting the driver, but initial testing showed this was unnecessary. The default PWM signal out of the CNC xPro is running a 2MHz if memory serves me correctly. Due to it's speed and the response time of the driver it actually functions great. There is a sawtooth to the laser output but it's period is small and should have no effect on the final outcome at the speeds we're running at.
I did have to modify the driver slightly (how the rogue screwdriver accident happened). There are two 20k trimmers mounted on the driver. One is to set a bias (minimum operating current of laser) and another to set gain (how much power is put to the laser when modulated input is a 5V). However as explained earlier I needed 2 modes of operation. One mode for low power where my 256 steps of power adjustment fell with in narrow band of about 150mA to 550mA of power, and a high power where those steps ranged from 150mA to 1.8A. The latter mode being used for etching anodized metal, cutting wood, TTL image work on mirrors, etc. So I removed the 20k gain trimmer and wired it externally (this also made it so I could adjust the gain from the front of my control panel), and then wired it with a SPDT switch one side of which feeds another trimmer. This allows me to set the normal gain trimmer to my "low power" maximum, then switch over and set the additional trimmer to my "high power" maximum. This way a simple switch thrown on the control panel switches between high power and low power mode.
Another quick note on the CNC xPro. The default grbl it comes with works, but is not well suited for this type of build. Why you ask? Because using the PWM to control a laser isn't really its intended purpose. It's meant to control the speed of a spindle which typically isn't very time sensitive. In fact, when a spindle speed change command (S gcode) is sent, there is a dwell state that gives the spindle a moment to change speed.
There is a fork of grbl that has this modified, it's actually a switchable feature that can be turned on or off if you want to use it for a regular spindle control using the $40 setting. I tried updating the CNC xPro using the methods suggested on their site but I could not get any of these methods to work. In the end I ended up just compiling the code in Atmel Studio and using my Dragon ISP output to program the xPro. This worked perfectly.
Here's a pic of the face of the finished control panel.
For the table itself I decided to take a very minimal and simplistic route. I mounted one piece of 20x20 using an L-bracket to the table support. This I made sure to square up with the support and tightened down firmly so it will never move. On the opposite side I attached another 20x20 with an L-bracket. This allows a fairly versatile setup. An object or plank of wood can be clamped in by simply loosening the far side clamp and tightening it in place. When it comes to doing routing or anything where a wasteboard is needed the wasteboard can be clamped in using the same method. For 3D printing the shape of the v-slot will make it perfect to use the same method to clamp a pane of glass onto the table riding in the v-slot itself.
Here's a shot of a piece of wood clamped in. The patterns were just some burn/calibration tests I was running while experimenting with power levels.
1/19/2015: It's been about a week since I've updated this site, and a lot has changed! I'll try to detail as much as possible.
After spending quite a bit of time trying to perfect my calculations I was having a very hard time getting it right where I wanted it. It was just extremely touchy. A little too much and all the darker portions were way too dark while the lighter portions looked ok. A little bit the other way and the image was way too light and the lights were washed out.
After giving it some thought I realized that what I was really lacking was speed. I did some tests and found out that regardless of what feed rate I was calling for I was maxing out at about 400mm/minute when streaming continuous lines of g-code with S commands in them. However, when streaming the exact same file with Z commands instead of S commands my feed rate was exactly what I asked for, all the way up to the 12,000mm/minute I have my machine limited to.
This started a long and tedious process of looking deeper into the grbl code. I had found and flashed a fork of grbl that supposedly eliminated delays in the PWM changes, but while it offered a very slight improvement it didn't seem to have hardly any effect.
After looking through it more closely I realized there were several things that could be cleaned up substantially and a few things that might explain it not working properly. I decided at that point just to create my own fork of grbl (available on GitHub with username rusirius76) and start from scratch while basing it largely on the forked version I was currently running.
Essentially what my fork does is to add a "Laser Mode" option to the settings. When this bit is toggled on, any time an S command is received by itself or with another block command such as seek, machine control, etc it processes it just like normal. Which by the way is to empty the planner buffer first THEN adjust the PWM and reset the timer. This is why my feed rate was maxing out at 400mm/minute, because every single line of g-code was causing it to flush all the blocks (only the previous one) first, THEN update the PWM and reset the timer. Only then would it proceed and read the next block.
However, in my code, the S command is passed down through the blocks into and through the planner. So if the S command is received on a line that includes a linear move (G1) then it bypasses all of this (assuming the laser mode is turned on) and simply changes the PWM.
This makes the PWM updates in real time with the blocks that request them, yet allows the blocks to still flow through the planner without any dwells while emptying the planner, reseting timers, etc.
The result is that I can now run any requested feed rate without a problem. About 1500mm/minute is where I max out (due to laser power not being able to burn "black" at any faster rate than that). This not only DRASTICALLY decreased the amount of time it takes to run a burn, but also made the images much cleaner. Further, getting my feed rate up really opened up the range of gray scale I'm capable of.
I'm still tweaking settings, but so far the images i'm producing are coming out great!
As a side note, I also bought a Bosch hand router over the weekend. This will soon get mounted to a plate to complete the second phase of this project which will give it the ability to route/mill. Originally I had intended to use an RC motor (brushless outrunner) for a spindle, but this is a quick and dirty solution that should work very well, it just won't be CNC variable speed. Later once I complete the 3D printer portion I'll revisit this and get a variable speed spindle on there.
1/20/15: Looks like I've got things going pretty good now! Here's a sample of a plaque I made for my parents. I made a few screw ups on it (entered a bad offset for leaving room for text at bottom that resulted in it overrunning the top, a false start that resulting in an errant mark in the middle, and being in a rush and not sanding it as well as I should have, etc. Still it came out pretty good!
(oh, and the black box isn't a defect, I edited the image to remove the name)
and here's a short video of the machine during the run:
I still have to tweak a bit, but it's getting pretty close!
1/21/15: Well, now that my speed is up I've determined another issue. That is, that the faster I push the feed rate, the more "blurry" the image gets... To the point where at say 1800mm/minute it loses pretty much all definition.
After digging through the code I believe I found the issue, though until I run some more high speed tests I can't be certain. I did run a very small test last night at 1800mm/minute and it seemed to be good, so we'll see what further testing bears.
1/27/15: So I've went through a tremendous amount of trial and error with the code. I decided at one point to download the current edge version of grbl (.9h) and start with that since it seemed like the motion algorithms were smoother and cleaner and I felt like I needed to "go back to the drawing board" anyway. After re-implementing the changes I believe I have it running perfectly. Unfortunately in the mean time my lasorb failed. Now generally that's not a big deal, other than not knowing exactly why. I checked the driver output and it looked very clean and solid. To further complicate things, initially I thought the diode itself had failed, but after removing the lasorb I found that the diode was functioning perfectly. My first thought was that maybe I had a loose connection or something, so I wired the lasorb back in. That's when it took it's final breath and took out my diode along with it. The annoying part is knowing if I had just left the lasorb out of the circuit everything would be fine right now until I got a replacement. Anyway, this time when I re-ordered the diode I decided to go a little different.
The current diodes I've been using are M-140. Since these are pulled from projectors there really is no datasheet available on them. Most of the information out there is speculation at best. That speculation says that these should be able to run at 1.8A comfortably, and 1.6A for extremely long life. I'm starting to question that.
So instead this time I went with a 9mm Nichia diode which I can get a datasheet for. Being the 9mm diode I'll be able to run the same current as I was running with the 5.8mm diode, but instead of being stressed (and if my thoughts about the speculation are correct, REALLY OVERSTRESSED) the 9mm should be very comfortable and give it quite a nice long life. I've been running one of these 9mm diodes in a laser pointer for quite some time now kicking out close to 3W and it seems quite happy.
1/28/15: During my "down time" I've reworked a few things. The first is that I've eliminated the high/low switch on the laser output. The reason is that after fixing my issue with the feed rates I've found it to become completely unnecessary. If I require less power delivered to a given area I can simply increase the feed rate and get the same result.
I've also changed the mounting of the laser driver inside my control panel. Originally it was mounted directly to the box using it as a heat sink. While this was probably perfectly fine, I did notice the end of the box got quite hot during operation. So I instead have now mounted the laser driver to a large aluminium block which then mounts to the box to help distribute and dissipate some of the heat before getting to the box itself. I've also drilled some air holes around the top edge of the box. I don't believe a fan will be necessary, but if I still find it getting to be too hot then I'll install a fan to move air around inside the box instead.
When the new diode arrives I'll be running a few tests. The first I want to run is to see how much if any a difference using the straight PWM versus using an RC low-pass filter to get an analog signal to input to the driver makes. Initially the PWM seemed to work great so I didn't bother installing the filter, however I want to see if there is any noticeable difference.
In speaking to another fellow "laserist", he found that using a stepper motor to drive a shaft encoder that generated an analog signal to give him the best results. What I'm curious to find out is rather it was the cleaner analog signal that gave better results versus the PWM, or rather it was a "normalization" effect created by the method.
With driving PWM direct, changes to the laser output are going to happen essentially instantaneously. With his shaft encoder setup those changes are going to come as sweeps from one power level to another depending on the speed of the stepper. Now he has his setup using very small movements and fast stepper speeds, which means it happens very quickly, but when you consider at 2200mm/minute with a pixel size of .15mm you're talking about 4mS per pixel. Now even if each step of the stepper is only equal to a change of 1-bit, going from 0 to 255 would take 255 steps... 255 steps in 4ms means 16uS per step... The steps from grbl are set at 30uS intervals, making this impossible even if each and every tick was moving the stepper.
So what may be happening is that in areas where pixels shift large ranges of brightness the encoder may not be moving all the way to it's setpoint before the next pixel comes along and it must reverse direction and head back the other way. This means that pixels in an "area" will be lighter or darker in relation to each other, but not their "true darkness" in relation to other pixels in other areas. That sounds like a bad thing, but in truth I think this may result in a normalization that actually seems more pleasing to the eye.
With that in mind, I'm also going to test different RC filter values with longer response times to see if I can replicate this type of delay in movement and therefore possibly get better image results.
2/8/2015: A couple of updates here! I've been playing around with various mediums including mirrors and getting fantastic results!
I did find a problem with the PicSender software I was using to stream the gcode. It utilizes a method of communicating with grbl called the "call-response" method. The recommended method for communications with grbl is the "Advanced Character Counting" method. The final result was that I couldn't get feed rates above 1800mm/minute with streaming the type of "image" gcode files I generate. Basically grbl was being starved because the method utilized waits for an "ok" response after each and every line sent. This means since the lines of gcode represent such very small movements that it would be finished executing before the next line of gcode ever came in. Resulting in a road block of 1800mm/minute. In testing I found that UGC was capable of streaming these types of gcode files with rates up to 2900mm/minute before any sort of stuttering or issues developed. The problem with UGC is that it tends to have stability issues with larger gcode files, and these types of files are VERY large since they contain a gcode line for each and every pixel in the image.
I was actually in the process of writing my own gcode sender when I got a message urging me to try 3dpburnersender. I tried this software and almost instantly fell in love. It's very simple and compact yet everything is very intuitive. It matches the type of workflow I was hoping for perfectly. Getting the laser jogged to the starting point, zeroing the axes, selecting the file, and finally streaming it is just very smooth and flows well. Further it also gets me up to the 2900mm/minute feed rate for these types of files. Which is way more than I'll ever need since I can't imagine ever needing more than 2600 or 2700mm/minute even for the softest woods or materials. Plus this speed makes even large files run pretty quickly. It's a win-win!
I've also ordered all the supplies I need in order to implement the 3D printer portion. Though I've made a shift from my original idea.
Originally I was going to use the same setup I'm running now and just have a swapable head. For the CNC xPro I'm using this meant pulling the 4th axis off and running it to another external driver. It also meant utilizing the coolant flow and spindle enable for heat to the bed and head. Implementing a PID routine for these wouldn't have been easy in the tight code space left with grbl on the ATMega328. I had considered external PID controllers, but eventually when working out the details I realized that it would be much easier just to make a swapable "controller" that got swapped in with the head. It deviates a bit from my original intentions, but the truth is, the new controller could actually handle the Laser portion just fine, so in reality I could probably just leave the one control unit installed for everything. I'll just have to test when I get it, but it certainly is looking that way from the specs.
So I've ordered a RAMPS 1.4 board with an ATMega2560 MCU. I'll be using the same DRV8825 drivers that the xPro uses since I really like these.
This will give me all the outputs I need to drive the machine as is, as well as tons more outputs for additional things later. Including onboard PID routines for the heatbed and hotend.
Further, since I'll be running Marlin (a much advanced version of grbl) with it, there is a new feature they just implemented recently for automatic bed leveling. Essentially the way I'm going to implement this is to put a microswitch on a servo arm (since the RAMPS board also gives me servo control). This way when the process is run it can swing the servo down into place, measure the distance at the corners of the bed and then know exactly what if any "tilt" exists in the bed. Then the job is offset to accommodate this. This could also be great for laser jobs as well, especially if a piece of wood isn't perfectly planed, etc...
2/20/15 : Since it's been a while since I've updated I figured I'd fill in a bit of my recent work. I haven't had a lot of time to devote to it but I've got some things accomplished which I'll try to get some pics of soon.
First I kinda reworked my wiring a bit. I'm not using a 30A 12v power supply for the ATMEGA and stepper motors. Overkill, but not once I get the 3D printer portion done. The ATX power supply I was using just wasn't going to cut it so I figured I'd do the upgrade now while waiting for the rest of those parts to come in.
Since I made the decision to possibly have a "swapable" control module, I needed to get away from the hard wiring I had. I found a nice 24-pin connector with built in lock. I actually used the laser to cut the plastic project box to mount the plug in the box. Wired everything up so that the 30A power supply and connections to the machine itself (i.e. stepper motors, limit switches, etc) go through this plug. The control panel which is customized for the existing controller and laser setup remain hardwired as well as the power supply for the laser itself. This way it's truly just a matter of unlocking the plug and the power supply, laser driver, control panel, and controller all are free to remove and be replaced by the 3D printing controller.
For that I'm using an ATMEGA2560 and DRV8825 drivers, the same I'm using with the other controller since they've worked so well for me. I've also ordered an LCD display panel controller, SDCARD reader, etc... Initially I won't bother boxing this together since once it's up and running I'll print a nice containment box for all the electronics to mount in. I'm currently awaiting for most of this to arrive from China (silly holidays).
I have however received the extruder and hotend I'll be using. It's a GT9L J style hotend with a bowden extruder. The both mounted perfectly to double L-brackets I had left over from my build so I'll be using those to attach.
I've been researching a bit to decide on a software toolchain to use. I've pretty much made my mind up to use the Marlin firmware for the 2560. Probably Repetier-Host for the host and probably Cura for slicing.
Aside from some of the advanced features in Marlin, I'm also pretty sure it'll work perfectly fine for the milling and laser etching I do as well, so if that's the case, then I should be able to eliminate swapping the controller. I haven't really decided on that part yet since it's really still going to be extremely easy to do the swap.
More updates to follow soon!
A CNC platform designed with swapable heads to do laser engraving/etching/cutting, routing and milling, as well as 3D printing.
- Build License:
- CC - Attribution Share Alike - CC BY SA
Inspired byThe pocket laser engraver by Groover was the original inspiration. I took it a step further by using a Raspberry Pi I had laying around to do the control versus an Arduino. When trying to get it to "fill in" shapes I discovered how easily InkScape could rasterize an image which then lead to creating an extension to output g-code with variable feed rate based on pixel darkness. Basically one step just led to another.
Qty Part Name Part Link Comments 2 20x40 V-Slot (1500mm length) http://openbuildspartstore.com/v-slot-20-x-40mm/ Link 3 20x20 V-Slot (1500mm length) http://openbuildspartstore.com/v-slot-20-x-20mm/ Link 4 25pk Low profile M5 screws (8mm length) http://openbuildspartstore.com/low-profile-screws-m5/ Link I actually used mostly 10mm screws, but found I had to add washers to almost all. Using 8mm would have prevented this and been cleaner. 1 25pk Low profile M5 screws (10mm length) http://openbuildspartstore.com/low-profile-screws-m5/ Link 16 Solid-V Wheel Kits http://openbuildspartstore.com/openbuilds-solid-v-wheel-kit/ Link 8 Eccentric Spacers http://openbuildspartstore.com/eccentric-spacers/ Link 4 GT2 20 tooth timing pully http://openbuildspartstore.com/gt2-2mm-aluminum-timing-pu... Link 8 GT2 Timing Belt (8 feet length) http://openbuildspartstore.com/gt2-2mm-timing-belt/ Link 4 NEMA 17 Motors http://openbuildspartstore.com/nema-17-stepper-motor/ Link 16 Aluminium Spacers (1 1/2" length) http://openbuildspartstore.com/aluminum-spacers/ Link 16 M3 Cap Head Screws (45mm length) http://openbuildspartstore.com/m3-cap-head-screws/ Link 4 Motor Mount Place (NEMA 17) http://openbuildspartstore.com/motor-mount-plate-nema-17/ Link 4 V-Slot Gantry Plate http://openbuildspartstore.com/v-slot-gantry-plate/ Link 5 Tee Nut (25pk) http://openbuildspartstore.com/tee-nuts-25-pack/ Link 15 Single L Brackets http://openbuildspartstore.com/universal-l-brackets/ Link Due to price difference of $1 versus $1.25 I actually got 8 double brackets and cut them in half. A lot of work to save a few dollars though. 8 Double L Brackets http://openbuildspartstore.com/universal-l-brackets/ Link 3 Limit Switch Kits http://openbuildspartstore.com/micro-limit-switch-kit-wit... Link At the time these were not in stock so I sourced my own, I'm sure the kits would have made it easier. 1 CNC xPro by Spark Concepts http://openbuildspartstore.com/cnc-xpro-controller-steppe... Link 1 ATX Power Supply (Should be at least 15A on 12V) Link This is the supply for CNC xPro, Stepper Motors, etc. 1 12v @5A power supply http://www.ebay.com/itm/201204252733 Link This is the supply for Laser Driver. 1 445nm m140 Laser diode in module https://sites.google.com/site/dtrlpf/home/diodes/445-m140... Link Others have reported better luck with 3-element lens, I use G2 because I already had it. 3-element is cheaper. 1 Lasorb ESD Protection for Diode http://www.ebay.com/itm/LASORB-ESD-absorber-for-laser-dio... Link This is optional, but highly recommended since diodes are very sensitive. 1 CPU Heatsink Link I used one with a nice solid copper core that was easy to drill out with a 15/32" that fit module with a press fit 2 12v Cooling Fans Link One of these goes with the heat sink and should come with it. The other is to mount in box with CNC xPro to keep drivers cool. 1 16 Terminal barrier strip Link I used this for connections at top of unit. You'll need crimp or solder connectors for wires as well. 1 4 position Molex connector Link This is for the connection to laser diode and fan to make it easily removable/swappable. 2 Project Boxes Link One of these is to house the CNC xPro so size appropriately. The other is to house the "control panel" for the device. 3 Momentary push buttons Link These are for the Start/Res, Feed Hold, and Abort/Reset on the control panel. 4 SPST Switches Link These are for the Fan and Laser control, as well as power level control and main power. 1 50k Trimmer Link This is if you modify the laser driver as I did to have a high and low power. 1 Analog modulated Laser Driver http://www.ebay.com/itm/161353680119 Link 1 Voltage/Current Monitor http://www.amazon.com/gp/product/B00J1A4J5M Link This can be built, or sourced as I did. I used a RioRand shown in the link. 0 Wiring. 12 conductor, 4 conductor and 2 conductor Link I used 12 conductor for connections to CNC xPro from device for stepper motors and control panel, 4 conductor for laser and fan connections, 2 conductor for power connections to control panel, limits