educa wrote:Thats not a problem Ben, as soon as possible (I believe in about 1 week) I'll setup another HDD with your configs on it (I suppose its best to test on a fresh machine, since I don't think I can add both your and jvccs config on 1 machine ? You don't use the same freq component ?
If he changed the behavior without renaming it you can just rename the component (not just its filename, I think the component name is on the first line of the .comp) and change the references in the HAL. Or if you don't want to do that, use comp --install to reinstall between uses.
I actually think his is the same as mine except when given negative values, but you might want to check.
educa wrote:Does that mean that it now works out of the box on 2.5 ? Or are people still experiencing problems with rastering ?
I hope that's true. I think I've also cleaned up some math issues (where LinuxCNC's floating results were slightly different from python's, leading to disagreement on the exact raster geometry). That might have been related to the dual engrave issue you saw.
I'm afraid I can't test dual engrave for you right now because I'm set up for the Mesa 5i25 and with the stepgen in HW the raster trick I used does not work. I still need to add rastering to the FPGA.
BenJackson wrote:"Trigger on pulse width < 1us" was super handy.
That's a good oscilloscope you have there. I have a Tektronix 2465B, but now I have scope envy.
I have a Tek TDS 2014. 4.5 lbs! Another big advantage yesterday. It was expensive (I think about $1700 refurb from Tek) but it has more than paid for itself. These days I'd probably settle for one of the $400 Rigol DSOs, but that wasn't an option when I got mine.
Nope. I was losing a ton of steps (the problem seemed to be getting worse) and although signal quality looked fine at a "macro" level there were dropouts of 10-30ns in the step pulses themselves, but only on the X axis (parallel port pin 2). After swapping just about everything around and having it follow pin 2, I finally measured at the back of the PC and it was fine. So I measured at the end of the cable and it was crap (due to reflections, I think, not crosstalk). I assume the FPGA is just putting much faster edges out than the parallel port. Another cable looks much better (and does not lose steps! Yay!) and it looks even better with termination. I may pull the laser interface board and add terminators to it just to be sure. I could put caps on 24V closer to the pololus, too.
All hail the mighty oscilloscope, without which I would have been hosed. "Trigger on pulse width < 1us" was super handy. Also my new headlamp, for hands-free delving into the electronics bay.
BenJackson wrote: All my settings are identical from parallel port to FPGA, except the FPGA is actually able to make the 1us pololu pulses. I assume I will need to stretch those a bit, which shouldn't have any effect on my max speeds. I could also put a scope on the pololu if I want to do some contortion to check the signal quality.
I made another spool with the timings bumped from 1us/200ns to 2us/400ns and no lost steps. Makes sense that you'd have to consider the waveform at the pololu and be less aggressive. The min step time on the pololu is around 30us anyway so the signalling time hardly matters.
I made another spool and lost steps again, so I put a scope on it and dug into the code. The signal quality is actually fine for the original 1us signals. I saw occasional back-to-back steps at the fastest possible signal speed, though (much faster than the fastest motor speed). The part of the manual I was glossing over:
(float r/w) maxvel Maximum speed, in position units per second. If set to 0, the driver will always use the maximum possible velocity based on the current step timings and position-scale. The max velocity will change if the step timings or position-scale changes. Defaults to 0.
In other words, the driver will try to make pulses as fast as the signalling is allowed. I assumed it was safe to leave this at 0 because the position command (and thus indirectly the velocity) is already being driven by the trajectory planner, which already limits the axis velocity. However if the hostmot2 stepgen slightly disagrees with the trajectory planner it is willing to catch up "as fast as possible". With maxvel set and the scope on infinite persistence I didn't see any more doubled steps. I hope I have this nailed down!
BenJackson wrote: All my settings are identical from parallel port to FPGA, except the FPGA is actually able to make the 1us pololu pulses. I assume I will need to stretch those a bit, which shouldn't have any effect on my max speeds. I could also put a scope on the pololu if I want to do some contortion to check the signal quality.
I made another spool with the timings bumped from 1us/200ns to 2us/400ns and no lost steps. Makes sense that you'd have to consider the waveform at the pololu and be less aggressive. The min step time on the pololu is around 30us anyway so the signalling time hardly matters.
I just cut some big circles to make http://www.thingiverse.com/thing:41958 and the ends of the cuts don't match the beginning. All my settings are identical from parallel port to FPGA, except the FPGA is actually able to make the 1us pololu pulses. I assume I will need to stretch those a bit, which shouldn't have any effect on my max speeds. I could also put a scope on the pololu if I want to do some contortion to check the signal quality.
I will add that having a red dot to position the laser made it much easier to efficiently use my material than ever before. I should have done that a long time ago!
kbob wrote:I wish there were a way that didn't require a new belt. I can think of a couple, but they are complicated or flimsy. Oh, well. A belt isn't that expensive.
With a 3D printer you could probably print a series of gears (one on the stepper, an idler or two, one on the threaded rod). In the end it was about $20 with S&H to get two $4 belts from Stock Drive.
Maybe I can work a trade with someone for my spare (long) belt for some post-install t-nuts (I'm sure ordering them from Misumi will kill me on S&H too).
(BTW you can move the drive to the bottom (with the stepper inverted and held up with spacers) and use the same belt, you just give up some Z travel. Honestly I've never needed all the Z travel but I might engrave boxes or build a rotary attachment some day. The advantage of my mod is that the lost Z travel is where the table is out of focus anyway)
My Stock Drive order with new Z belts arrived so I went ahead and rebuilt the Z axis drive. I went from 285mm of Y travel to 310mm. The next obstacle is the bolts on the laser tube brackets. I actually just barely clear those (or just barely rub) but I've exceeded 12" which was my main goal. With low-profile bolts on the laser tube I could probably get another 1/2" at least.
In my previous description I talked about re-using the existing stepper plate, but I just 3D printed a bracket to mount the stepper to the back rail. I remember the top Z plate being a pain in the ass to align to the bottom (being a different size/shape than all the others) so I worked really hard to avoid taking it off. I had to take the lid off its hinges so I could slide the threaded rod straight up out of the machine. The other tricky bit was unbolting the stepper which was hiding partly under the end of the laser tube. You can see the clearances issues in one of the above pictures.
I ordered two belts from Stock Drive (since the S&H dominated anyway). One was 117 teeth (which I had estimated to be just enough) which is what I ended up using. The other was 125 which I could have made work by offsetting the motor mount. The P/N are A 6Z16-117025 and A 6Z16-125025
I am now beyond out of post-install T-nuts. The relocated X endstop is only held on by one bolt. Too many accessories!
New setup from below and above:
Reminder to remove the right door stop or you're gonna have a bad day:
I'm thinking about an alternative which doesn't waste any useful Z travel. If I move the large Z pulley below the 2020 rail I lose about 30mm of Z travel (thickness of 2020 plus thickness of the fat part of the pulley). At that point I can still focus on paper-thin material on the surface of the bed (or even run the bed into the air nozzle). Now the Z motor can't just move 30mm straight down because it would hit the Y drive shaft. However, there should be room for it between the drive shaft and the back rail. So here's my proposal:
Take the existing Z drive plate (mounts a bearing to hold the Z shaft and the stepper motor) and cut it basically in half. This yields one bearing holder (basically like all the others) and one stepper mount plate. Move the big pulley from above the plate to below (trimming off excess 1/4" rod). Remount the Z stepper plate (pulley facing upwards) to the bottom of the back rail. The back rail is 2040 so the net motor pulley movement will be 40mm. The centerline of the large pulley on the Z rod also moved 40mm. Voila! Just need a slightly longer MXL loop belt (and any odd length can be compensated by offsetting the stepper plate).
kbob wrote:Wow, Ben! I can't decide whether to be grateful or annoyed. You're doing exactly what I wanted to do, _again_, but you have a year's head start. (-:
I'm dragging my feet as much as I can! I wanted to print one of these as soon as I saw it, but my attempts to edit the STL to make the original (Daniel Bauen's) version printable all failed in various ways.
kbob wrote:This is awesome. I will steal your design post haste, since I just got the top door installed. Thank you!
Two questions. What laser module did you use, and how well does the laser return to position each time you open the door?
They also make other (non-focusable) modules which are sometimes superior (in line, cross, dot) but they are smaller so you'd have to tweak the design.
If the hinge is in the right place the arm registers against the beam it's attached to (on the front face). I've flipped it up and down with my finger to see if I can get it to mis-register but it seems to return fine. The motion is very smooth so there's no real chance of it getting hung up. The aiming isn't even super-critical.
My red dot is about 1mm from the actual laser hit at this point but that's close enough for me.
jv4779 wrote:I have been very happy with my kluge analog out method of getting the raster data into a HAL component. It has proved to be very reliable and easy work flow. How will you get the bitmap data into the FPGA ?
It will get into the FPGA via the HAL, so it's independent of what method is used to get the data into the HAL in the first place (where I used the streamer module and you used sneaky analog data).
Given that I'll have to modify LinuxCNC to make it work at all (there's no way to extend hostmot2 with pluggable modules) I could just add some way (similar to yours, perhaps) to get bitmap data in via gcode.
MattyZee wrote:Another question, Would this method of PPM work with a Mesa FPGA card? The PC i'm running LinuxCNC on is a bit slow and i'm limited in my max speed. I like the possibility of offloading the step generation to an FPGA ( i think that makes more sense than upgrading the pc). However, my understanding is that the make_pulses in the fast base-thread wouldn't be needed as that would be handled by the Mesa card. Only the slower servo-thread would exist. So would that mean some custom drivers would be needed to drive the Mesa card to do PPM?
I just bought at Mesa card and you can use my PPM config (but not my raster config) with it. You will still want to configure the fastest BASE_PERIOD you can and then you put the hm2_pci write_gpio thread in your fast thread ("addf hm2_5i25.0.write_gpio laser-thread"). That function drives just the GPIO outputs (while the normal "read" and "write" threads are operating at the slower servo-thread speed) so you can use the FPGA GPIOs at the same speeds you used to drive the parallel port. Now your PPM will be limited by the BASE_PERIOD but it's not nearly the restriction that it was for stepgen.
(Of course this won't work well for USB, ethernet or parallel connect Mesa cards)
Meanwhile I will be making an FPGA component to do PPM and ultimately raster engraving directly from the FPGA. Those solutions should work with *no* fast threads and even for the non-PCI Mesa cards.
educa wrote:Any idea Ben at what speed you can aproximately switch on and off a co2 laser tube during raster engraving ?
I think that's a tricky question. On the one hand you seem to be asking for minimum on/off time (shorter being "faster") which would be important for dithering. I think I saw a paper that said something like 2-3kHz for that.
However, for raster engraving you really only care about the edges of the on/off areas and the responsiveness of the laser to being turned on/off at those edges. The laser actually stays on for more than the minimum dot width (it doesn't fire for every DPI dot in the image, it fires continuously for each stripe of "on" dots). Given that alternating lines of the engraving are done in opposite directions you should be able to see any difference in on/off times as a raggedness of what would otherwise be a straight vertical edge. I was satisfied with the quality of those edges so I didn't pursue the issue further.
One of the biggest changes is the engraving is done in pure gcode (with a custom component) so that the resulting file can be touched off and combined with any other gcode without issue.
Wow, I just read that. That is... insane! I never would have thought of getting data into the component that way.
I had actually thought of combining streaming + raster (once I realized how easy it was to make a component) to avoid all the HAL logic, but I had not considered trying to stream the data in via gcode. You can see where I thought at one point an Mxxx script could get at comments, but executing Oxxx subroutines screws that up. Maybe 2.5 fixed that.
My code (as I was running it under 2.4) certainly allowed touch-offs and could be combined with other gcode. I even did some work on some scripts with ghostscript to turn postscript (or pdf) files into gcode with combined raster/vector operations. I suspect that got broken with the change to stat.origin (for 2.5) mentioned earlier. Perhaps in 2.5 you need to combined stat.g5x_offset and stat.g9x_offset. I assume the latter is in play when G92 is in play (which is how I did most of my random-starting-position engraving).
evokanivo wrote:For raster/engraving, the power level (laser-pwm) is constant (!!??) and the streamer module governs the on/off times for laser-final, which results in beam intensity? This doesn't seem right to me. I would expect power to be set by the laser-pwm pin like in PPI cutting, and for laser-final to be on continuously for each scan-line.
The INPUT pin can't be modulated very quickly due to the nature of the CO2 laser (at least that's my understanding). The PWM is "constant" (i.e. hopefully fast enough that it's like a constant analog voltage) in both modes of operation. The raster output is binary on/off controlled by a monochrome input (the python script takes any image input but it's transformed internally to a dithered B&W image and scaled based on the desired DPI). To do what you're describing (laser constant with full bandwidth modulation of INPUT) would require a true DAC.
For most cutting applications you should not have to vary PWM much (cutting at full power with PPI and speed control) but the limited raster speed (due to stepper pulse rate limitations) means that you will need to turn the power down to avoid engraving deeper than you want. On a professional system you would just run the laser carriage back and forth faster so it lingers less.
educa wrote:1) Where do you have home or limit switch on X axis? On the left, the right, both?
2) Is it a homing or a limit switch (or doesn't that matter, because in the end they do about the same) ?
3) Is the machine running into the homing contact and then slowly going away until contact is lost again?
It's on the left, under the gantry, contacted by an extended M5 bolt (covered by a nylon bushing) on the rear V-wheel. I believe it's exactly as depicted in the plans (though I have not looked since the makerslide plans were released).
It's a home switch. You can see in the .hal file that the "home-x" net (arbitrary name) is connected to parport.0.pin-10-in-not (that is pin 10 inverted) and to axis.0.home-sw-in. I'm pretty sure home always defaults to minimum in EMC but you can probably invert the sign of HOME_SEARCH_VEL and set HOME_OFFSET to home elsewhere.
It searches for the switch at HOME_SEARCH_VEL and then backs off and re-homes at some lower speed. I made sure my switch would trigger soon enough that the carriage does not hit the physical endstop at HOME_SEARCH_VEL.
educa wrote:4) Where do you have home or limit switches on Y axis? (If you stand in front of the machine, is it close to you or at the farthest distance?
Close (again, minumum Y) and on the right. As in the plans at the time I built.
Imagine the cutting table (and the "axis" display) as a piece of graph paper. 0,0 is in the lower left. X increases to the right, Y increases up (or away from you on the cutting table). Not to be confused with computer graphics where Y increases down.
The HAL change looks ok. M144 looks at [RASTER]AXIS (add that to the INI) so you could set that to 1, but I don't think it rotates the image. By the time I realized I couldn't make it all track [RASTER]AXIS I dropped it.
TLHarrell wrote:Having a small machine at the moment, having the ability to determine the raster axis would be cool to me. I've had several projects where I wanted to raster something along the other axis, for sake of how it looks when done, but couldn't due to the constraints of my work envelope. Not necessary, and adds unneeded complexity, but would be a nice feature.
When I implemented the raster engraving (before PPI) I thought I was making the EMC configuration more portable by sticking to existing HAL components. Thus the snooping of the X axis and the synchronization with the bitmap is done using general purpose HAL components like adders, comparators and LUTs. When I implemented PPI I had to make a new HAL component altogether. That turned out to be much easier than I realized. I could actually move the raster support into its own component and then I could get around limitations preventing a selectable axis.
By the way, regarding FILTER: The existing (commented out) filters should not be necessary. However, a new image filter could easily generate the 5 line O145 script for an image so you could use "File|Open" on an image, select some parameters, and engrave.
Modelart wrote:Theres any way to change scans direction from x to y, for non 2.x laser machines. I know how to do it inside emc2 (ie changing axis), but a parameter inside the o145 routine call would be great.
I tried to make [RASTER]AXIS set the engraving axis but there are some issues that make it difficult. The M144 script looks at that setting but the HAL doesn't. The HAL needs "xpos" changed to "ypos" in the raster section. For O145 I'd just copy it to O146 and flip X/Y.
If you want to be able to do either at runtime it would require more complex code in the HAL.
sliptonic wrote:I got rastering working yesterday. Very very cool!. I had to uncomment the appropriate lines in the [FILTER] section of the .ini file.
If that's standard procedure, you might want to add a note in the README file.
Hah! I specifically commented those out just before I pushed to github because they have nothing to do with my rastering code. If you literally used File|Open and selected an image (using the FILTER) then what you got was a program generated milling script. I guess it works because of the magic-z? Was the motion smooth?
commit b00edf842f3df55d037a2d117ff4df14b2978cdc Author: Ben Jackson <email@example.com> Date: Wed Jan 4 22:17:51 2012 -0800
Add Tkinter GUI message boxes for M144 errors
Any configuration errors will result in an error dialog. Some startup code has been cleaned up.
A new configuration [RASTER]IMAGE_PATH lets you specify where M144 should search for images. If the file cannot be found a warning dialog will be shown followed by a file selector to choose an alternate image.
commit 667dfe4c7159dcd5b7d4c95a1c205287fb484160 Author: Ben Jackson <firstname.lastname@example.org> Date: Tue Jan 3 20:56:43 2012 -0800
Modify M144 for compatibility with [TRAJ]LINEAR_UNITS=inches configs
commit be80545e16fb526a106b3d572b00214c6b9ba90d Author: Ben Jackson <email@example.com> Date: Tue Jan 3 00:10:07 2012 -0800
Loop back the tool control signals so they are a no-op and M6 does not hang EMC.
Modelart wrote:EDIT: i figure that this happens when z is negative, for z positive, doesnt fire at all, im lost....
I noticed the lines connecting your engravings and suspected the same thing. With Z < 0 the laser is firing all the time, so when you raster it makes the stripes. One of the effects of PPM is that the laser doesn't fire when it's not moving (no distance is covered so no pulses fire). So likely you have Z<0 and whenever you move you make one pulse per mm (M3 S1). That's why you have 1mm spots connecting your engravings and stripes at 1mm in the field of the engraving.
As Bill mentioned: Start emc from the command line (emc2 2x_Laser.ini) and you can see errors. I did not do much to make M144 user friendly. Possibly your image file is not found. It needs to be in the directory where you start EMC.
sliptonic wrote:But I'm still wondering whether using G1/G0 to control laser on/off wouldn't be safer, more intuitive, and more broadly compatible with different g-code generators than using the Z position.
I don't think the nature of the move (G0 vs G1) is visible at the level you're talking about. I have also seen scripts that produce only G1 moves. (And obviously there are lots of other cutting moves like G2 and G3)
sliptonic wrote:My bed is completely manual right now, but I can imagine adding a stepper to allow for automatic touch-off focusing and maybe stepping down to change the focus on multiple passes but HeeksCNC doesn't do anything beyond 3 axis control.
It's unlikely that you'd try to CAM a touch-off like that anyway. Heeks doesn't need to support U if you just drive it in a text preamble.
As for focusing: That would be easier with Z but the 2.x Laser has too much wobble for that (if you jog the table while cutting your next pass won't line up).
All that said, you can have PPI and rastering without the "magic Z" and without moving the table axis to U. You just have to modify the HAL and INI. The git repo has all of my experiments so you can find the one where I moved the table to U to see exactly what I did. Disabling magic Z is even easier. The purpose of magic Z was to make your life easier: If it makes your life harder, don't use it!
Modelart wrote:Can you tell me how PP pins 14 and 17 are connected to PSU, for your setup?
Pin 14 ("PWM") goes to "input" in your diagram (labelled "IN" on my laser PSU). On Bart's board there's a jumper to select 14 vs 15.
Pin 17 ("laser-final") goes to TH I believe. That also happens on Bart's interface board so I'd have to double check, but I think TL is only the front panel test-fire button.
You can use the pot to set power and ignore pin 14 if you want. Bill French is doing that in his configuration. With PPI 100% power will be your usual choice (just reduced PPI) but you will still want to set it lower for things like paper.
For raster engraving you will need to turn the pot down because your laser probably can't move X fast enough to engrave at 100% power. For rastering you'll pick the highest X speed your laser is capable of and then set the depth of engraving with power.
sliptonic wrote:Then I get a bogus cut on my material
Ben suggested i add a M65 P0 to the start of my gcode.
The equivalent for his magic Z issue would be to put "G0 Z0" somewhere before any "M3" in the code. The M3 master means it won't unexpectedly fire the laser at the start of the job, so you have a window for your prologue to set up. If Heeks is moving in X/Y before setting Z clearance or if it's starting the spindle (with M3) before moving to the Z clearance height that's definitely a bug. You can imagine the kinds of problems it would cause with a router or mill as well.
By the way, you can simply jog Z up from Axis before you start your job. If you used my included axisrc (which puts the table U on pg up/dn) then Z is moved to brackets [ ]
Before I fixed my nozzle alignment I tried to prove out Dirk's ideas about low PPI and ultra-low speed to avoid burning the material. This is what happened:
That was a big clue about the nozzle but I ignored it. In hindsight you can also see extra darkening around all of the cuts.
With my nozzle fixed (as described above) I can now do slow (eg F100) cuts without that terrible burning on the surface. What's more, at low enough PPI I can also cut through and merely "toast" the glue rather than burning it. It's good to have that in my arsenal for this MDF, but I had to go quite slow (< F250 at 20 pulse per mm aka ~500 PPI) to avoid blackening the wood.
On the other end of the spectrum I experimented with FSE's "continuous pulsed" mode. Based on the scope trace that Dirk linked a while ago I started with an off period of 250us. That was clearly less cutting power than CW. I kept cutting at F800 which I knew was a through cut with CW and reducing the off period. As I dropped below 100us off (2.5ms on) the cutting power seemed to increase over CW. I ended up at 50us off and I am now cutting through at F1000 and the edges are slightly nicer than the CW cut. I also think the tube itself is glowing brighter.
(note that 50us off is hard to measure without a scope because the EMC2 base period is 37ns -- my true off time is probably either 37ns or 74ns)
...success! I definitely think it was sapping power before. I have been running some full sheets of MDF and after the work above I did some test cuts and was able to run the job 60% faster and with about 25% less power (tried 2.5ms pulses instead of 3ms, which didn't seem to have any effect, and slightly backed down my PPI). Obviously 60% faster is a big win.
I'm pondering how to update Dirk's spreadsheet to take speed into account. His calculations may be true in "lens like" material such as acrylic, but speed is obviously not an independent variable from PPI in wood. As each pulse is "dragged" across the cut it doesn't actually get its full duration to dig into one spot unless the speed is slow enough. I guess you could think of it like running through the rain: The speed can probably be approximated as a slanted beam making the material appear thicker.
Also this MDF is nice and cheap but I haven't managed to get anything but a fairly charred edge out of it. Even weak (non-through) cuts are charring so it's probably just the nature of the glue.
My previous adventure with disassembling the lens had me doing lots of test firings with and without the air nozzle. I noticed that the spots fired with the nozzle were ever so slightly elliptical. With very short, low power shots into paper you would see a clean hole with a dark elliptical halo. Today I verified by removing the nozzle that the halo goes away.
To permanently eliminate the halo I did two things:
1. Finally cut a spacer ring (DXF attached) to center the lens in the holder. It's actually a slotted 18-22mm ring cut from 1/16th acrylic. It sort of snaps in past the threads and leaves a perfect 18mm opening for the lens. This is far superior to my previous attempts to center the lens! For one thing I verified that my spot moved slightly when I reassembled.
2. I zip-tied a laser pointer to a dial indicator base and set it up (parallel to the gantry, between the gantry mirror and the carriage) so that the red spot coincided with the test firing of the laser. This allowed me to test-fit the air nozzle several times. With the cheap red laser pointer there was always a "halo" effect around the spot, but I could readily see from that how well centered the spot was. I used 1/4" copper foil tape to shim the air nozzle until the red spot/halo were as centered as I could get. Trying to just aim the nozzle before tightening it didn't work because it would always register itself against one of the mating faces. It actually took quite a few layers of tape (in my case above the screw clockwise from the air input) to get it aligned.
Finally after that I shot a new test spot with the nozzle in place and it's nice and sharp with no halo. I'm curious to see if I pick up some extra cutting power as well. Attachements...
net tool-change-loop iocontrol.0.tool-change => iocontrol.0.tool-changed net tool-prepare-loop iocontrol.0.tool-prepare => iocontrol.0.tool-prepared
I've used CamBam and while it also uses tools to do cutter compensation it doesn't use G41 cutter compensation, it just offsets the paths itself. So I still use "tools" in CamBam (well, one "Laser" tool and one "Laser Kerf" tool) but I modified the post-processor settings so that tool changes don't emit anything.
(note the edit, the "prepared" loopback is also required, I had a chance to test)
Aaand one final thing: I forgot to switch the laser back to computer power (rather than knob power for the test firings) so I ruined my first sheet and thought I had a whole other beam problem again...
While doing a test run in cardboard of my first full-area "production" build things suddenly went haywire. My cuts got wobbly, the steppers were making a bad noise, and eventually despite the laser firing no beam was hitting the workpiece. Luckily it was a test run so I was right there to hit E-stop.
The root cause appears to be one loose stepper wire on the X axis. That caused huge vibration (and unreliable movement) of the X axis which backed out the thread on the final lens assembly. I had thought that the air nozzle was trapping the threaded lens holder but apparently not!
The loose wire was comparatively easy to fix once I found it. Getting my lens back into shape was much more trouble. I never got around to cutting a retaining ring for it so my first reassembly had the lens off-center and I couldn't get the beam to pass the air assist. Once I got around that (used a bit of blue tape from the bottom to hold the lens in place while I threaded it together) I found that my air assist was actually wobbly. In my efforts to keep the brass fitting close to the nozzle I threaded it in so tightly that I deformed the aluminum. You can actually see the threads from the pipe fitting telegraphing through the aluminum at the mating surface! My first few attempts to ignore that and get the nozzle back on resulted in very oblong "spots" when the laser was test fired (despite nice clean results without the air nozzle). Finally I took the nozzle to the garage and ground off the offending bump so I could get it on straight.
So now my final lens has some teflon tape to keep it from backing out and I solemnly swear I will cut the adapter ring for next time.
is notable because I drew it in Inkscape, exported as PostScript (could have equally well printed it via the Generic MS Imagesetter) and converted to a combination of raster and vector cuts with a script.
The basic formula is:
The pre-existing pstoedit gcode filter is used to convert the PostScript to vector operations. A PostScript preamble modifies the execution environment so that only lines < 0.6 point (about .2mm, or the laser spot size) are allowed through. All the fills, images, text is suppressed.
Ghostscript is then used to convert the raster parts (by way of another preamble doing the inverse of the first) into an image. (Ghostscript is also the backend of pstoedit)
A python script crops the white borders off the raster part and emits the gcode line necessary to raster the image
The main script then edits that into the beginning of the vector gcode and cleans up some other header/footer issues
There are a number of rough edges, not the least of which is that the pstoedit gcode plugin is very primitive. There's no vector sorting, no way to use things like color to influence the output, etc. It also works in inches which forced me to make all of my rastering scripts unit-aware so they work under G20 and G21. Also the raster conversion step should be able to slice the engraving steps into smaller jobs where it makes sense to split them up (and even using color to do the split and/or choose power settings).
At this point the only thing missing between hitting "print" on a desktop and having that show up as a gcode job in EMC2 is a bit of Samba configuration (a samba print server will just drop the PostScript from the client into a directory) plus invocation of axis-remote to automatically load the job into EMC2.
StigOE wrote:Isn't it recommended to start the water pump some time before you start the laser? And leave it on for a while (more than 20 seconds) after you've stopped the laser to let it cool the tube?
The water jacket is full of water all the time. If it weren't you'd have to personally supervise it to ensure it was free of large bubbles every time you started the pump. Also M3 is merely the master enable, it doesn't fire the laser. This is because EMC knows about "spindles" and if you stop a run it stops the spindle. It doesn't do anything about digital outputs.
During a cut you're at a dynamic equilibrium with the heat producing parts of the laser warming nearby parts until you reach the water cooling. So there's some gradient from hot to coolant temp. When you stop cutting the heat producing parts immediately stop getting hotter. The only reason to run the water after is to keep the parts between the heat producing elements and the water at the equilibrium temperature rather than letting them get warmer when the stagnant coolant warms up.
All that said I've never really noticed my coolant getting warmer at all...
I've been turning the laser, water pump and assist air on with a power strip since my laser was just wired for "always on". I finally got around to wiring up my light-up front panel rocker and cut a back panel to hold an outlet and the power connection. It feels so decadent to turn on the laser and have the water/assist air come on automatically when a job starts.
The water/assist air are set up to come on whenever my "master laser enable" (M3) is on and for another 20 seconds after it goes off (M5).
Currently the blower (switched by one phase of that ginormous 3-phase DIN relay) is on direct control but I will probably automate that as well. Since it's separately controllable from the other side of the outlet I feel like I should have a special, different rule for it. It probably makes sense to do roughly the same thing as the water and air. Maybe run it less after...
One thing about having a back panel is is that my suction is now so good that there's a tremendous whistling sound where the air goes around the door. I had noticed it to a lesser extent when blocking the back of the electronics bay, but now that it's really closed off it's quite loud. For now I'm using the panel on top of the electronics bay (still not secured) as a "blast gate" to let off some pressure. I might have to gasket the door or cut more air holes somewhere. I wonder if there's something I could just stuff into the T-track on the sides of the door.
One thing I miss from the Epilog I used a long time ago is the edge rails that let you quickly register 0,0. I made this one to key off of the table T slots:
I first cut the plate and the "rails" and glued them up using M5 screws to ensure alignment. Next time I'd probably put 3mm holes at the ends to ensure alignment because of the tiny kerf on the guide rails where the M5 passes through. With those glued on I installed it and did a big square cut at 0,285 (my upper left corner) thus ensuring it's perfectly aligned.
This is 1/8th acrylic, which is slightly too thick, but it actually works out fine (the plate actually "hovers" a bit). You have to be sure to focus for that when you make the final cut. Attachements...
I did a bunch of tests in 5mm plywood with varying parameters and got good results at "full" power and 0.0125mm pulses and 20 pulses/mm (so about 1/4th pulse duty) at F300. The cuts are even less charred than the ones I illustrated above.
Oddly adding more pulses per mm made the cuts shallower (when I did slices that ran up to the edge). 20 PPMM was chosen as about 500 PPI based on the recommended Epilog settings, I went so far as to try 18,19,20,21,22 and 20 was always the winner in cut depth. Cut depth increases up to about 0.125mm/pulse (making max pulses/mm 80) but not much above that.
If you go to full power (continuous wave) the through cuts are much faster -- maybe F500.
I put a scope on 24V at the 24V fan terminal. Normally you'd want to measure noise as close to the device as possible, but it's not very convenient with the board installed and given no pre-existing bulk capacitance on the board it's probably fairly accurate. After I add the cap I'm probably getting too generous a result (due to measuring right at the cap).
Here are snapshots with the stepper drivers enabled and disabled and with and without a 470u 50V cap mounted in the 24V fan power port:
bdring wrote:The main board cap is on the 5VDC line. The 5VDC power supply has short circuit protection, so it is not supposed to take down the 24VDC power supply.
Ah, I didn't realize where that cap was. I had the reverse problem: 24V short took out 5V (hence no fan, one of the obvious visible signals)
bdring wrote:The 5VDC current is quite low in the drivers and the cap is so close to the driver that I don't see it inducing ripple in caps on the driver. I think the cap that failed on your board was on the VMM (motor) line.
That's correct. I just assumed the cap was on the 24V line. It probably needs a cap on 24V (if not per driver, at least somewhere on the board). A 24V cap on the board will reduce the ripple in the cap that blew on mine and reduce its power dissipation. In fact it's possible that the 4.7u caps on the pololu modules are "sharing" between the modules and the weakest one is dissipating more power than the rest and blowing up. Survival of the fittest!
In fact, although it's not an ideal location, you could easily clamp an electrolyic cap in the 24V fan screw terminals. I'll put a scope on it tonight and see what it looks like.
(speaking of those fan terminals: Those blue screw terminals are easily the worst screw terminals in the system. My fan ground lead kept falling out even though it appeared to be clamped. The removable green terminals are nicer and the DIN rail terminals are nicer still)
Using 20 pulses/mm (about 500 PPI) vs continuous wave on 5mm plywood: Both pictures have the pulsed cut on top and the continuous cut on the bottom. One picture is with the grain and the other across it (for the surface plies). The color is more noticeable in person, with the pulsed cut being a more golden color where the continuous cut is blackened. The pulsed cut also has a much lighter smell (almost none).
Currently my pulses are 1/200th mm (5um) so that "200 ppmm" (about 5000 PPI) is continuous. This is just based on the Epilog setting. I haven't really tuned the setup. Both cuts were at full power and the pulsed cut was about 1/4th the speed of the CW cut to do single pass.
I also did some 20ppmm cuts on paper and the edge is barely browned and the kerf is noticeably smaller than the CW cuts.
I was lasing just fine last night before I shut down, but when I fired up today I had zero stepper activity. I further noted that not even the 5V fan was turning. Measuring across the 24V at the board I only saw about 2.5V. Luckily the PSU must have gone into current limiting because it seems to be fine.
I removed the PSU connector and ohmed out +24V to GND and got about 1R which means there's probably a dead short somewhere on the board.
Since I could do it without removing the whole interface board I started by pulling the Pololu drivers and sure enough the short went away. I ohmed out the VMOT to GND on each of those and found my Y axis was a dead short. I looked at it under magnification and noticed some solder balls (usually a sign of too much solder paste applied during manufacture). I ended up removing the primary capacitor because it looked iffy and sure enough it was a dead short. I replaced it with a handy junkbox .22u I had (later I measured the others at probably 4.7u -- probably doesn't matter much because Bart's mainboard cap is so close) and swapped that to the Z axis. Motion restored!
In the interest of less charring on wood and clean edges on paper I am trying to replicate the Epilog-style "frequency" in EMC2. I wasted some time trying to figure out how to piece it together with existing realtime modules and then I discovered how simple it is to write new ones. EMC2 even comes with a tool to build them an install them. My implementation of pulse-per-mm controlled by "M3 Sxxx" is a ~40 line realtime component plus 1 stanza in the HAL to hook it up.
Right now I'm using 1/5000th second laser pulses (though that's really a random selection based on "5000" being Epilog's max, but that's 5000/inch, not 5000/sec). I did a few test cuts and it does seem to reduce charring on paper, but of course it requires higher power to make the same cut. I would really love to see a scope trace on an Epilog at various settings, but really all I care to recreate are "500" and "5000" and "5000" is just "always on", so if I can nail a setting for paper/wood I'll be happy.
dwessels wrote:What DIN rail relay did you get? Where did you get it from.
I asked Bart for something that could switch a blower. He sent me that 3-phase monstronsity. It makes a hell of a clack when it turns on! If you want the model number you can probably read it off the enlarged image.
My vague plan is to split the rear outlet, switch one side with the smaller relay (for cooling and air assist) and the other side for the exhaust blower.
At the moment I have everything plugged into a power strip and no power switch on the laser at all. I have a front panel rocker for it that I need to cut a new panel for.
I had an "aha" moment about where my positioning error was coming from in my EMC2 rastering setup. I fixed it and my 500mm/s test patterns finally look great. I redid the Timbers logo on different plywood (much thicker top ply). The other stuff was very thin veneer on a balsa (?) core scrap from my Makerbot.
So this version is 600 DPI in X and 0.1mm or 254 DPI in Y at 470mm/s (vs 80mm/s before) and closer to 30W.
I should have put a bigger space behind the DIN rail. I forgot about how big the relay module Bart suggested for the blower was. I actually had to move the 24V PSU to be able to snap it onto the rail. I also pre-wired that side since it's not really accessible anymore.
I'm sure the neat freaks among you will also note I didn't re-cut the wire to fit the new layout yet. I figure when you do something like that you guarantee something will come up to make you need to move stuff around.
Out of sight behind the huge relay is a small terminal block that provides a hookup for the extended laser ground lead with a 1R sense resistor inline and two terminals to hook up a meter if I ever get a permanent one.
When I first assembled the laser I hooked up a microcontroller to drive it. That let me do vector cuts (though the ergonomics were poor because I had no UI, just serial gcode access). The big problem was that it discouraged me from hooking up a PC controller because the first step would be unhooking the working setup and being unable to use the laser for a while. Plus component arrival order and general laziness had left me without limit switches so all that would have to be fixed.
Enter my vacation! Unbelievably my wife wanted to go somewhere for part of it so I haven't been able to devote it to laser hacking like a normal person...
But I do have EMC2 working now on an old PC. Some BIOS setup to disable hyperthreading, disable onboard sound, legacy USB, power management, and all those realtime-crushing things and I can get a 37kHz BASE_PERIOD which EMC2 can turn into 37kHz steps (its special parallel port driver has an auto-reset feature that enables one pulse per tick). That gets me about 470mm/s on X (8x microstepping) and I've tested up to 7500mm/s/s acceleration with no problems.
With the BIOS tweaking (same sort of things you'd do for Mach3) and the EMC2 live CD plus the included "stepconf" I think anyone could be doing vector cuts with EMC2 very quickly. The major difference for a laser builder (as opposed to end user) between EMC2 and Mach3 is that where Mach3 has almost unlimited flexibility of the GUI, EMC2 instead has almost unlimited flexibility of the internals. Take a look at this list of realtime modules: http://linuxcnc.org/docs/html/hal_components.html . Now consider that you can hook those together in any way you want. I fully expect I can implement an equivalent functionality to the Epilog "frequency" setting just with some work in the HAL file.
What I've got working so far is rastering based on an idea from the Hacklab (Toronto) configuration. An external script processes the image and feeds the raster information to the streamer module which executes logic in the inner loop via HAL config. Their version created a paired "gmask" and gcode file to execute together. My version just generates the info on the fly (by executing a custom M-code script) and executes a gcode subroutine to produce an arbitrary raster scanning pattern.
Here's my first result in wood (300 DPI in X, scan gap of 0.125mm or about 200 DPI in Y, about 80mm/s and about 20W laser power):
Here's one letter under higher magnification (courtesy of a USB microscope by Celestron):
I finally put a meter on everything so I could plot laser power vs V IN:
It appears to have two linear regions:
From 0.5V (below which it will not fire) up to 1.0V maps linearly to 0 to 50% laser power (assuming 20mA ~ 40W)
From 1.0V to 2.9V maps linearly from 50% to 100% laser power
One note from this for new builders is to be sure you've got a meter going before you turn the knob beyond halfway (2.5V) or you risk running too much power through the tube.
On top of this if you use PWM to drive V IN (from pin 14 or 15 on the parallel connector if you use Bart's board) there will be scale error to include since the parallel port voltage is used directly (rather than having it PWM the PSU supplied 5V for example). My parallel port at 100% output produces 4.43V at V IN. More than enough, but if you assumed 5V you'd be off by 10%. Some parallel ports will probably max out at 3.3V or less.
Rather than waste 1/3rd of my PWM range (and thus 1/3rd of my resolution) I should probably at least install a divider to bring 100% down to 2.9V.
bdring wrote:Y Carrier Turn Around - I need a visual on this one.
Which part? I assume the benefits on the bottom are obvious since the wiring and tubing all wants to go to the back.
The issue on the gantry is that the X motor wire and the assist air don't want to go on the inside of the gantry plate on the front because the carriage will hit them (limiting X travel). If they simply bow out toward the front then they are pinched between the gantry plate and the front of the machine (limiting Y travel). Dirk solved this by folding the wire and tube back on itself immediately to stay under the X carriage and come out at the back of the gantry plate. My solution roughly follows the front edge of the gantry plate but angled to avoid interference. If the tubing and cables simply exited toward the rear (with reversed cable carrier) it would be no problem.
Another idea from looking at a pic of another laser: A 1/4" acrylic door would be self-supporting, simplifying the front frame and front skin. The handle would have to point up instead of forward.
Bart's post about the black washer upgrade reminded me of my list of ideas/suggestions compiled while building:
Add a hole in the right front of the laser carriage for the air hose. This would be an easy mod for people to do if they knew it would be useful, but it's tricky once you realize how the air hose can interfere with your X and Y travel.
In concert with the above, switch to a right angle fitting for the air assist barb fitting. I actually sawed off all but one barb and used a ziptie to secure the hose. Again to try to minimize the air fitting stickout leading to reduced travel.
The air assist should have a deeper pocket at the top so that the setscrews can engage the locking collar of the mirror assembly rather than grabbing the threaded lens retainer (or grabbing right between them -- it's hard to tell)
The kit should include the 18mm to 20mm spacer for the lens. I keep meaning to cut one myself. Anyone have a drawing?
Dirk has a good list of minor adjustments to improve travel, like relocating the X endstop to the front and using button head screws in a few key places. Moving the Z motor to the bottom would also help quite a bit.
The right side door stop can hit the gantry end and really wrench it if you close the door with the gantry all the way back (farther back than the usable cutting area).
The table doesn't align that well to the cutting area. I think ideally the usable cutting area would be entirely within the open space of the table so that you can use expanded honeycomb and not have to do any cutting over the frame of the table.
The table brackets are well designed to avoid binding, but it would be nice if the table were really registered in some way to ensure squareness of jigs and the like. The Epilog I used had flip-down rulers that also formed a lip to register 0,0.
If expanded aluminum tables were popular I think something like a C-channel table frame would be much easier to work with than Misumi 2020 (plus it would eliminate the corner brackets).
It would be handy if the top skin behind the door was not pinned by the door hinges. It's a little fiddly to install the door, which discourages removing that back skin that gives good access to the top of the laser and the primary mirror adjustments. Perhaps notch out the hinge area in the skin and mount the hinge itself on spacers (which could be made out of alupanel as well).
I had been waiting for my interface board so I could do some "3D" gcode to work out the best focal distance. Then I realized I could just prop a bit of cardboard on a block and make a ramp to cut a pattern of lines on. Picking the finest line gave me 73.5mm from the top of the laser carriage, or about 70.5mm from the bottom of the carriage.
I imagine this is already posted here somewhere (perhaps in re the lightobject optics kit) but this forum is difficult to search.
As mentioned above I got my aluminum honeycomb material from Morgan Haynes at HoneyCommCore. It''s 1/2 cell and .787" (20mm) thick. Here you can see me fanning it a bit with my fingertips: It's quite "soft":
1/2 ACG NP UNXP .787 X 48 X 96
This arrives as a stick just over 5' long (since it gets narrower as you expand it). Reasoning that I need under 16" for the table (in the narrow direction) I sliced off 1/3rd of it (21") with my horizontal bandsaw. I supported the cut with some wood blocks and C-clamps. The cut came out very clean. The factory ends are actually ragged (looks like every aluminum strip was cut individually).
In a further effort to expand as little as possible I then took my 21" stick and split it down the middle, trying to make one 16x96 sheet into two 16x48 sheets. This is much trickier than simply sawing off part of the stick. You've got to find the middle, open it up, hold it in place with wedges and then try to snip the right hex segments. It's tricky to follow a hex in a straight line and easy to head off on a crazy diagonal. This came out fine, though. Given that I could get 2 tables out of the 1/6th of the stick I expanded I think you could get a full 12 tables out of one $80 stick if you were so inclined. Mainly I didn't want to have to store expanded material.
Expanding is harder than I expected because I hadn't thought about how it would want to get narrower. I placed the 1/6th stick so it straddled two 2x4's and used roofing nails to tack end loops to the boards on both sides. With the back board clamped to the bench I just pulled the front 2x4 until I couldn't really expand the sheet any more without the edge and end cells popping open. THe secured ends were not usable because they didn't expand evenly, but a large central area (enough for 2 tables) was fine.
Cutting it to shape was very tedious. I used ordinary scissors which were a pain because they had to be carefully opened just enough to go into each cell for every cut. Some spring-loaded aviation snips would make it much easier. I did two straight sides and then eyeballed where to cut the other sides but it didn't work out that well because the honeycomb itself isn't even enough to use as a guide. If I were doing it again I'd just use a sharpie to mark every single cell exactly where I wanted to cut.
To support it I used some 1/2" (1/16" thick) angle aluminum from Ace Hardware. I attached it across the longer table dimension so that the table can still slide in and out of the Z lift. To secure it I used M5x12 into holes drilled diagonally into the corners of the supports. With the supports cut I just stacked them up and held them in a drill press vise. It was actually very easy and works quite well:
I have looked at your GRBL branch but not extensively. I am impressed by the GRBL code, having looked at several similarn gcode interperter firmwares targeted at 3D printers.
Right now I'm using a board I put together with an L297 + L298 stepper controller and an Atmel AVRUSBKEY development board. I happened to have the stepper parts from a long ago PCB I intended to make but never did:
Prototyped stepper controllers with AVRUSBKEY
The firmware I'm using is Teacup which is a 3D printer firmware written in C (rather than built with Arduino and compiled as C++). Having examined most of the 3D printer firmware out there, Teacup shows the most engineering rigor and best software practices by far. However, it is not widely popular as a 3D printer firmware. I think this is mainly due to the fact that the principal developer does not actually have a working 3D printer, much to my surprise.
The structure of Teacup (and lack of reliance on Arduino) made it possible to port it to the at90usb1287 on the AVRUSBKEY. Using the LUFA library the board now connects directly to a PC via USB and shows up as a serial port. In order to jump on GRBL development I would have to do a similar port or buy another AVR dev board.
Bart has just shipped my new interface board so next week sometime I should be able to hook up to that and try PC control. Ultimately I'd like to reach "laser as windows printer" levels of convenience and I don't think an AVR + GRBL can fully satisfy that, but it may be part of the solution. I expect I'll try all the options just to learn about the pros and cons. I've got an old PC and an EMC2 live CD ready to go.
I was attaching the air assist nozzle after finally getting around to cutting deeper threads and removing all but one barb from the brass fitting. I wanted to be sure I wasn't blocking the beam so I started making test spots in all 4 corners. I was able to push the Y too far back because I did it where the laser carriage didn't hit the Z plate. When I started to close the door the door stop hit the right gantry plate and torqued my Y way out of alignment (like nearly an inch). It popped at least a few of the V wheels loose of the bearings in the process. I assume it spun the pulley on the threaded rod. I had to get out the Del Monte Gantry Alignment tool again.
So mind where the gantry is when you close the door! I might look at shaving down that door stop a bit just in case.
I wired up another pin on the AVR to TH so I could have gcode control of the laser. I cut myself a vanity tag:
About 110mm wide, cut from the other side
Took several trials to learn what power to use to cut through. One early version turned to char.
I'm not sure how high you can actually set the knob for continuous cutting (i.e. how close to 5V) or whether the peak voltages are meant for pulsed operation, but there was certainly power to spare at about 1/4 turn at 500mm/min (about 20 IPM)
The other good news is that the glue in this 5mm plywood I got at home depot does not stink to high heaven like that scrap I tried before. Also, despite the fact that the random stencil font I downloaded is not really meant for true stencil work (the bridges are tiny, about 0.5mm) it came out just fine.
Here's the first thing I cut that was more substantial than paper:
I still don't have my control board so that was done by pasting gcode into a terminal window talking to an Atmel AVR dev board (similar to Arduino) driving hand built L298 half-stepping controllers. I edited the gcode to make two passes and I just hold down the "fire" button for one complete circuit in the middle.
Whatever that cheapo thin plywood is (I think I salvaged it from packing material) it leaks out a bunch of burned sap like crap when cut. I'm glad I'm cutting on a temporary flat steel sheet because I wouldn't want to have to clean that mess off the inside of my machine! I guess there's a lesson about selecting quality plywood for laser cutting!
dirktheeng wrote:I will be interested to find out how valuable the led pre-alighnment turns out.
To install my new tube I:
Loosened the bottom setscrews all the way
Removed the holders I made for the setup laser
Installed the tube by sliding it in from the right (as viewed from the front)
Held it against the upper setscrews and rocked it slightly while tightening the bottom screw to ensure I felt when it contacted
The tube is oriented so the electrodes are straight up. This puts the final water outlet up which seems to be necessary to clear bubbles from the system. This requires routing the outlet tube back and up to avoid the Z motor bracket, but everything clears.
The total of my adjustments after installing the real tube was to make a 1/16th turn of the first mirror to swing the beam out about 1.5mm at the far end of the Y travel. I made test spots everywhere but I didn't adjust anything else. After making a test spot through the final mirror I installed the lens and made a final test spot at the approximate focal length. I was shocked at how small it was after doing all the other test spots!
I haven't installed the air assist nozzle yet because I want to tap it much deeper and possibly get a different hose barb for it (or just cut the original one shorter). So I'm not sure my beam will go through the assist, but I was careful to make the unfocused beam perpendicular so I'm fairly confident.
Buildlog 2.x Laser with laser 2.x, now with more dogbone:
Also visible in the lower left is the air pump named elsewhere in the thread. Bottom center is the dead-bug/Manhattan style protoboard with L298 drivers which I originally built for my CNC Etch-a-Sketch. That's what drove the steppers in the earlier video.
I got bored waiting for my replacement tube to arrive. I 3D printed a patch to go over the broken water fitting and epoxied it on. When a pinhole leak developed through the patch I just sealed the whole thing on with more epoxy. It's not pretty, but it is water tight!
Band-aid for broken water fitting
That also illustrates how surgical tubing (in that case 5/16" which Ace had) is extremely prone to kinking even in a fixed connection like that.
On the other end I had already successfully installed the Tygon, which produces a much tidier connection:
Other end with Tygon tubing
When I attached the tubing to the pump I tried a few methods since I was no longer worried about babying the tube. What I found worked best was to stretch the tube with needle nose pliers (jam the jaws into the tube, then pull on the handles in the "opening" direction) twice (rotate 90 degrees and jam the jaws in farther). Then coat the glass and tube with dish soap. The stretching is especially important for the fittings which are much bigger than 1/4" (on mine, the ones at the rear of the tube). The tubing quickly relaxes. The soap that gets into the tubes washes out.
Here are some spots I made. The smaller ones were at the lowest power that would start the tube and for the quickest tap I could get on the "test" button on the PSU. The only thing I had connected to the control pins was the power pot.
The water pump http://www.amazon.com/EcoPlus-Submersib ... B0018X2XT4 is great. Good flow, very quiet. The fittings are far too big for 1/4" tube (in fact, the ID of the fitting accepts the OD of the tube, which is how I have it jammed together right now). I need to take the plastic fitting to the store and find something to replace it.
My air pump http://www.amazon.com/Active-Air-Commer ... B002JPM91W arrived today. I really wasn't sure how "70LPM" was going to translate to real airflow. It seems to be about right. I tested it through my 10' of 3/16" Tygon threaded through both cable carriers. It's reasonably quiet for its size and has large, squishy rubber feet (with mounting holes) that isolate it very effectively. If you use the manifold (and let it touch any hard surface) it will make far more noise than the pump. You could use it unmodified with the stub of fat tubing plus the manifold to reduce to 3/16 (and the manifold includes a ball valve on each outlet), or buy a new brass fitting to go direct to 3/16".
I'd be happy to send you the holders I made. My laser PSU arrived today so I hope to be firing it for real today. As soon as I can find the !@#$% picture I know is on this forum somewhere verifying the direction of coolant flow.
My theory goes like this: The mounting discs are 50mm (same as the tube). The aiming of the laser pointer is guided by the pinhole in the forward disc so the beam is very close to parallel to the tube mounts (less than 1mm off across the ~500mm gap, which in a linear system of mirrors I would expect to translate to a proportional error on the other legs). My primary goal is to make sure I don't have any gross errors in the system. It would have been very hard to figure out that my lens assembly was twisted with an invisible beam. I suspect that people who are hitting the inside of their air assist nozzles might have that problem.
When I swap in the real tube I am going to back off one screw entirely in each mount (if I can still get the tube in!) so that the tube will be registered against two of the screws exactly like the aiming discs were. When I tighten that screw the laser should be aligned exactly where the laser pointer was (assuming the beam leaves the center of the tube and is parallel to the tube).
It's not as fast as the post history suggests: The Misumi parts came in the second week of May and I started building when Bart's kits arrived about a week after that. After I saw how fast those parts were going to go together I ordered the laser just in time to get it for the Memorial Day weekend. Unfortunately the laser PSU didn't make it so I eased up on the build. Tonight I should be able to fire the laser and maybe even cut something (with my hacked up X-Y control). I won't be ready for Mach3 or EMC2 control until Bart's next batch of Pololu control boards turn up.
Engraving will have to wait until I build/write some kind of engraving solution.
I hooked up a L298 stepper driver (half-stepping only) just so I could drive the carriage around a bit. Here's a video!
The noise is probably due mostly to the half-stepping driver in concert with a few loose items (like the final mirror/lens assembly which is not screwed down). If Bart feels the racket will scare away potential builders I can have Youtube replace it with inspiring music.
BenJackson wrote:The red spot is visible on the bottom of the frame, but it is actually very far forward of the carriage.
The problem here was twist in the final mirror (the one on the carriage). I had not realized that the mirror holder rotated in the plate. Mine was frozen together (perhaps assembled while the parts were hot) and I ended up having to use two sets of soft jaws to get it apart. Nerve wracking because I was 99% sure it had to rotate to be square but it was darn tight.
Here is my innovative Del Monte Gantry Alignment system. The table was adjusted so the cans would rest in the T slots of the table rails:
The limit in forward "Y" movement (gantry toward user) seems to be the SHCS on the left side idler. Replacing that with a button head M5x12 would give a bit more travel. Could also notch the gantry end plate but that seems like overkill.
Here's my 3d-printed laser holder/pinhole mounted in the laser brackets. I only did very minor adjustments here (mostly on the gantry mirror) to get the laser to hit the final mirror. The red spot is visible on the bottom of the frame, but it is actually very far forward of the carriage.
One of the mirror holders has a poorly made thread on the mirror retaining ring and it can "cross thread" while being unscrewed and jam up. When you catch the threads right it's as smooth as the others but I ended up removing it from the "bridge" entirely to mess with it before I figured out what was going on.
This final shot shows how close my aiming laser is coming to the X idler. I guess it's missing it so that's good enough! I might have put that idler over too far attempting to get more travel on X without realizing where the beam would be:
I hit "buy now" and paid for the laser on May 22 with an estimated delivery of May 25-31. It arrived today (Saturday!) via USPS. Unfortunately the PSU did not arrive at the same time so I probably won't have it until Tuesday. The mailman was quite curious to know what it was and really surprised it was a laser. He asked if I was going to do light shows.
I had seen pictures of the giant delivery tube but with nothing to give you scale, so here's the tube as it arrived on top of my laser frame:
40W Laser Tube as packed by love-happyshopping of eBay fame
Last night I printed a couple of bits to help aim the laser. Two 50mm discs, one which holds a laser pointer and one with an aiming pinhole. The laser pointer will go in the rearmost laser support and the pinhole in the front to ensure it is aimed squarely:
If anyone wants to print their own I have attached the STL files... as a ZIP because it won't let me attach STL files. Attachements...
Here are the buildlog.net kits fresh from Bart (skins not shown -- the packing on those is amazing). You see the E-stop out of its bag because my wife found it and decided the button action was great. I might have to get one for her so I can have that one for the laser...
Kits and Misumi Parts
I invented my own method of gluing up the V rails. My two longest rails had enough twist that pressing one end down flat caused the other to pop up in two dimensions by several mm. In order to have enough even clamping force I put lots of rubber bands around the 2040, then slipped the V-rail under them (by sneaking down the T slot). I used some bits of cheap chopstick to prop them off the rail, sort of like you'd glue down a laminate top:
Work the rail toward the edge and tug on the rubber bands so they're not dragging the rail away from the edge. I then applied the glue (a bit too much, I went over the 4g total in the end and there was a bit of squeeze out). When the glue was ready I used one hand to pull forward on the rail and the other to pull out the chopsticks. You definitely want to practice that maneuver without glue a few times. The results were very good. After an hour I used the same rubber bands to do the other side. I cleaned up as much squeeze out as I could while wet and used acetone and Q-tips to remove the rest later. I did superglue a few rubber bands to the rail but it cleaned up fine.
What slowed me down when I decided to build the project was an actual list of what to buy and where, so I wanted to include that in my build log. I finally got around to updating it now that I'm halfway through the build:
Bill of Materials
Note I did not get the Electronic kit (but I did get some custom DIN stuff).
Notable missing items:
24V PSU. I will probably use a bench supply initially.
Electronics tray I will fab from stuff in the garage
Heatsinks for the Pololu boards. Not sure if they're required.
Microswitches -- the ones I have are too small, oops.