BuildLog.Net - Document your builds!


Buildlog Title: Ben's 2.x Laser Build

newest first oldest first
Builder: BenJackson
Member Since: 2011-04-15
reader comment Comment from: sliptonic on Thursday, August 22nd 2013 - 9:37 PM
Today I was trying to engrave some tiny text and I didn't like the result I was getting so I started playing with LinuxCNC's path blending (G64). Even though I set the P value very small (0.0003) I was still getting bad results with linuxcnc deviating from the path a lot.

I finally figured out what was happening.
My preamble was like this:
G17 G21 G90 M3 S7 T1 M06 F1000 M68 E0 Q0.9 G64 P0.0003

Simply moving the G64 P0.0003 to a new line fixed the problem. I think what's happening is that the Q0.9 earlier in the line is being used by G64 for its Q word and activating the naive cam detector.

Just thought I'd mention it here in case anyone else has the issue.
reader comment Comment from: jv4779 on Monday, March 11th 2013 - 10:45 PM
You can use either version of laserfreq.comp with either config. You will just loose the duty cycle mode using Ben's code on my config, PPI will work the same.

Friday, March 8th 2013 - 2:34 AM

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.

add commentadd comment in the forum

reader comment Comment from: educa on Thursday, March 7th 2013 - 8:58 PM
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 ?

Thursday, March 7th 2013 - 8:54 PM

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.

add commentadd comment in the forum

reader comment Comment from: educa on Thursday, March 7th 2013 - 2:18 PM
Ben,

I see that you upgraded your github code to work on linuxcnc2.5 now.

Does that mean that it now works out of the box on 2.5 ? Or are people still experiencing problems with rastering ?


I currently use jvcc's code, but the rastering isn't very clear to me. Therefore I would like to retry your code but in the past I had problems to raster engrave 2 pictures in 1 job.

The first picture was engraved, but the second was only partly engraved or not at all.


Any ideas ? Does anyone use BJJ github setup and be able to raster engrave multiple images in 1 .ngc job run ?


Kind regards,
Bart

Thursday, January 17th 2013 - 7:32 PM

cvoinescu wrote:
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.

add commentadd comment in the forum

reader comment Comment from: cvoinescu on Thursday, January 17th 2013 - 12:04 PM
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.

Thursday, January 17th 2013 - 9:14 AM

BenJackson wrote:I hope I have this nailed down!

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.

add commentadd comment in the forum

Wednesday, January 16th 2013 - 5:26 AM

BenJackson wrote:
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!

add commentadd comment in the forum

Sunday, January 13th 2013 - 7:47 AM

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.

add commentadd comment in the forum

Sunday, January 13th 2013 - 12:06 AM

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!

add commentadd comment in the forum

Friday, January 11th 2013 - 9:39 PM

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)

add commentadd comment in the forum

reader comment Comment from: kbob on Friday, January 11th 2013 - 7:40 PM
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.

Friday, January 11th 2013 - 6:28 AM

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:
P1000325.JPG
P1000328.JPG


Endstop relocated:
P1000326.JPG


Reminder to remove the right door stop or you're gonna have a bad day:
P1000327.JPG

Attachements...
ZMotor.zip
STL of the mounting plate.
(38.13 KiB) Downloaded 152 times

add commentadd comment in the forum

Thursday, December 27th 2012 - 12:08 AM

I'm thinking about ways to refit the Z drive so that the drive pulley is not in the way of the X carriage wheel at the rearmost Y travel.

Dirk moved his to the bottom: viewtopic.php?f=16&t=514#p3442

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).

add commentadd comment in the forum

Wednesday, December 26th 2012 - 12:41 AM

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?

I'm pretty sure my module is one of these: http://dx.com/p/red-laser-module-focusa ... m-5mw-5914

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.

add commentadd comment in the forum

reader comment Comment from: kbob on Wednesday, December 26th 2012 - 12:08 AM
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. (-:

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?

Tuesday, December 25th 2012 - 10:09 PM

I have long admired http://danielbauen.com/make/index.php/l ... n-extra-m/ but it's got some annoying features for printing on a home printer (mainly a shoulder on the hinge point, but also some unnecessary bridging).

I finally re-created the upper corner of the frame in CAD well enough to produce: http://www.thingiverse.com/thing:39188

The thing has all the files and a description of how to assemble, so I'll just leave these pictures:
P1000319.JPG
P1000321.JPG

add commentadd comment in the forum

Tuesday, December 25th 2012 - 6:20 PM

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.

add commentadd comment in the forum

reader comment Comment from: jv4779 on Tuesday, December 25th 2012 - 3:54 PM
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 ?

Sunday, December 23rd 2012 - 8:32 PM

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.

add commentadd comment in the forum

reader comment Comment from: JakeS on Tuesday, November 27th 2012 - 12:43 AM
Great, thanks. I wasn't sure what 18-22mm meant, but now I do. Thanks!

Gadroc wrote:It crashes laser cad on me as well, but I can successfully import it to Corel and Alibre. It's easy to recreate inside lasercad directly.

1) Draw a 22mm circle
2) Draw an 18mm circle
3) Set X/Y coordinate on both circles to be the same
4) Draw a vertical line through one side of both circles (this makes it so you can bend the spacer into place)
reader comment Comment from: Gadroc on Tuesday, November 27th 2012 - 12:35 AM
It crashes laser cad on me as well, but I can successfully import it to Corel and Alibre. It's easy to recreate inside lasercad directly.

1) Draw a 22mm circle
2) Draw an 18mm circle
3) Set X/Y coordinate on both circles to be the same
4) Draw a vertical line through one side of both circles (this makes it so you can bend the spacer into place)
reader comment Comment from: JakeS on Monday, November 26th 2012 - 7:37 PM
I tried to cut this spacer using LaserCad 6.27 but it crashes while trying to import the DXF. Has anyone else had this problem?
Thanks
Jake


BenJackson wrote: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.
reader comment Comment from: MattyZee on Monday, October 22nd 2012 - 11:04 PM
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?

Edit: found this: http://wiki.linuxcnc.org/cgi-bin/wiki.pl?HostMot2 I need to do some more reading on how Bens PPM and raster engraving interacts with the HALstreamer and see if i can get a Mesa card to do the same. maybe using a pwm module or a general IO.
reader comment Comment from: MattyZee on Monday, October 22nd 2012 - 10:53 PM
Hi Bart,

Yes, sort of. After changing 'stat.origin' to 'stat.g5x_offset' it loaded without error and would run. Now i have the problem of the image being resized to a 1x1px image. It seems the passing of the parameters between M145 and M144 isn't working. The recv_params() in M144 always seems to return the latest pair. That is, if I have X=50,Y=50, H=100, W=100, XSCANGAP=0.04, YSCNAGAP=0.04. All of the parameters are 0.04. So when the image scaling and resizing happens it reduces to size 1,1. If i hard code the sizes within M145 it works fine, which is what i've done to successfully do my first raster engrave. I need to look into this problem some more so i can use the script properly and not have to edit M145 everytime i do an engrave.

Cheers
Matt
reader comment Comment from: educa on Monday, October 22nd 2012 - 9:09 PM
Matyzee, did you get this working allready ?

Kind regards,

Bart
reader comment Comment from: MattyZee on Thursday, October 18th 2012 - 12:00 PM
oops, i replied too soon :oops: Now that my file is at least loading i didn't notice an error in the terminal window. I had the same error as sliptonic and his fix worked!

sliptonic wrote:...
I recently upgraded to 2.5.0 linuxcnc and rastering stopped working for me. Vector cutting is still working great. I've made a bunch of changes related to the name change but I'm still getting this error in the console:

Code: Select all
Traceback (most recent call last):
  File "/home/brad/linuxcnc/configs/2x_laser/M144", line 35, in <module>
    origin = stat.origin[axis]
AttributeError: 'linuxcnc.stat' object has no attribute 'origin'
...

sliptonic wrote:According to guys on #linuxcnc IRC channel: stat.origin was split into stat.g5x_offset and stat.g9x_offset
Renamed stat.origin to stat.g5x_offset and it worked.
reader comment Comment from: MattyZee on Thursday, October 18th 2012 - 11:21 AM
ok, thanks. I thought the 145.ngc that gets called had the required M2 end-of-file command.

ANyway, after reading the G-Code overview section of http://www.linuxcnc.org/docs/2.4/html/gcode_overview.html I have put a % at the start and end of my .ngc file. Now it at least opens the .ngc file without an error. It shows a white box in the size and position defined by the O145 call. But it does nothing if i try and run the file (although the LinuxCNC window title changes from "raster-test.ngc" to "145.ngc"). Also, it does the same thing whether or not i have the image file in the folder or not. So I am still doing something wrong...
reader comment Comment from: educa on Thursday, October 18th 2012 - 10:45 AM
Have a read about the conventions of .nc files please.

It's not that I don't want to explain it to you, but I had this problem too but can't remember the 100% solution.

Somehow you have to put 1 last line of gcode in your file to tell linuxcnc that the job is over

This is a percent sign or something else, but it is documented so you should be able to find it.

Regards,

Bart
reader comment Comment from: MattyZee on Thursday, October 18th 2012 - 10:31 AM
Hey Ben,

I'm getting a error when trying to Raster Engrave. I'm not sure i'm running it correct. The error says
Code: Select all
Near line 5 of /home/laser/raster-test.ngc:
File ended with no percent sign or program end


My "raster-test.ngc" file contains only 4 lines of code
Code: Select all
M3 S1
M68 E0 Q0.2
F14000
O145 call [123] [100] [100] [100] [100] [0.04] [0.04] [15]


It doesn't seem to matter if i have an image file in the [RASTER]IMAGE_PATH or not. I just get that error.
I've customised your EMC2 configuration to match my machine (pinout changes and different base period/speeds etc) but everything else is the same.

I'm am opening the "raster-test.ngc" using file>open on the linuxcnc window.

Any ideas what i could have done wrong?
reader comment Comment from: educa on Friday, August 31st 2012 - 4:58 PM
600in/min = 10inch/sec

200DPI @ 10inch/sec = 2000 dots per second

2000 x 0.5ms on time leaves NO time for off time ???
reader comment Comment from: jv4779 on Friday, August 31st 2012 - 4:52 PM
educa wrote:JV4779 do you have any idea how long the laser is then OFF between your 0.5ms pulses ?


Unless I messed up the math, 200 DPI is .005in per dot and at 600in/min = 50ms per dot, so 49.5ms of off time.
reader comment Comment from: educa on Friday, August 31st 2012 - 4:49 PM
JV4779 do you have any idea how long the laser is then OFF between your 0.5ms pulses ?
reader comment Comment from: jv4779 on Friday, August 31st 2012 - 4:44 PM
educa wrote:On the other hand, I have the impression that your ON time of 3ms per dot is quite high. That means you can at max shoot around 300 dots per second.

If you shoot at around 200 DPI, then 300 dots means a raster engraving speed of max 1.5 Inches per second. Thats really slow.


You are correct, I rechecked my raster settings and the on-time for each dot is .5ms. It is configurable per raster and could depend on the DPI and speed being used to give best results. .5ms on time, 600in/min, 200 dpi. The machine could go faster but I never pushed it. I then verified the dot placement under a microscope and it was all dead on.

If the raster speed was fast enough and the DPI was high enough that consecutive dots were running together faster than .5ms you would end up with a stripe for them, ending the stripe .5ms after the start of the last dot.
reader comment Comment from: educa on Friday, August 31st 2012 - 4:15 PM
It is ALSO that article, but I have seen that graph somewhere in a bigger resolution too.

As you can read there by dirk, a 3ms was a nice cutting timing. 2 ms did cut paper very thin and 1ms didn't cut through (but it did cut)

The stuff dirk made was/is working, but as far as I know he uses mach and only created some hardware to do the PPI pulsing.

My purpose it to not need a pc at all.

I'll write PC software which is able to layout gcode and raster engravings on a workpiece, but the effective work is then saved onto a SDHC card. You walk with the card to the lasercutter, put it in, set your zero-point and press START.

Thats all.

To get it speedy enough I will hardcode some stuff in my software. For example 1 step of a stepper in X or Y is 0.02mm, so I have 1270 steps per inch on my machine.

In cutting mode my speed aim is around 27 inches per second max speed and in raster engraving that'll go to 39 inches per second.

PPI setting is dynamic (very heavily based on the system Dirk used) and pulse length will be possible to set from 0ms to +- 30ms in 0.001ms increments

Laser power will also be settable in gcode of course (pwm channel) and I hope that the system is fast enough to try to raster 8-bits greyscale. Most of the buildlog projects only do 1 bit (black or white) engraving. The only thing you need to do greyscale is SPEED. But... I'm not sure about that one since I believe that is one of the key differences between our cheap (yeah, they tend to call them cheap) co2 tubes with the pro rf lasers.

It is a challenge :)

I did it allready with a 0.7Watt 445nm Bluray diode laser at much lower speed. http://www.youtube.com/watch?v=xfhDgUTKdb4 (smurfette at the end of that movie is in greyscale)
reader comment Comment from: kbob on Friday, August 31st 2012 - 3:48 PM
In other posts where dirktheeng discusses PPI, There is somewhere a graph which shows the intensity of a laser pulse over time.
In that graph you can see that the pulse is allready at maximum after only 0.3 to 0.5 ms. Dirk choose to have 3ms pulses for cutting purposes, but I guess you should be able to burn dots at 0.3 to 0.5 ms and that would speedup a lot.


Is this the post you mean?

http://www.buildlog.net/blog/2011/12/ge ... er-system/

There's a lot of chewy information in that article, and I am still masticating it.
reader comment Comment from: educa on Friday, August 31st 2012 - 3:28 PM
Rastering with dots makes -> dots

Rastering the other way makes stripes.


I can personally also not imagine that stripes would look better then dots.

On the other hand, I have the impression that your ON time of 3ms per dot is quite high. That means you can at max shoot around 300 dots per second.

If you shoot at around 200 DPI, then 300 dots means a raster engraving speed of max 1.5 Inches per second. Thats really slow.

My goal is to create the controler on dedicated hardware. I know I could do it with emc2, but honestly I tried about 20 different pc combinations and almost no combination was able to give me a decent latency.
And even the PC's that had quite low latency tended to give errors now and then.

So the primary choice was the arduino platform.
This would MAYBE be possible, but you would have very little cpuspace left on a 16MHz 8 bits controller.

On the other hand, since a few months there is the very nice 32 bits MicroChip PIC32 and this chip is certainly capable.



In other posts where dirktheeng discusses PPI, There is somewhere a graph which shows the intensity of a laser pulse over time.
In that graph you can see that the pulse is allready at maximum after only 0.3 to 0.5 ms. Dirk choose to have 3ms pulses for cutting purposes, but I guess you should be able to burn dots at 0.3 to 0.5 ms and that would speedup a lot.

Time will tell... its a lot of software writing, but I have to, because not a single emc configuration was able to provide me with good results.
Cutting with PPI was not a problem, but the rastering isn't what I expected. Its even strange, but when I run a cutting job with 2 or 3 small raster subjobs in it, then mostly the first raster engraving works, but stuff after that fails at random places. I don't know why, but its certainly not helping me out.
reader comment Comment from: jv4779 on Friday, August 31st 2012 - 3:15 PM
I implemented my raster engraving as distinct dots. Really only because of speculation that low DPI engraving would look smeared by the much more bold horizontal lines vs the vertical spacing. At .005in laser spot size you start to get overlapping dots at greater than 200 DPI, so that was the DPI I got my best results with. The code uses the same type of logic as PPI where a dot is just firing the beam for 3ms.

It would be interesting to see the difference between rasters done using distinct dots vs. connecting adjacent pixels.

Wednesday, August 29th 2012 - 5:36 PM

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.

add commentadd comment in the forum

reader comment Comment from: jv4779 on Wednesday, August 29th 2012 - 4:44 PM
The main idea was to allow an inkscape plug-in to export raster and vector in the same file in one shot and make it work like any other gcode file in LinuxCNC. I never actually got around to doing that any of that and have just been using VCarve Pro to do the vector cutting gcode generation and what little raster fill I do is just a very fast raster pocket operation. I was also kinda nervous that halstreamer would always be fast enough to keep the buffer full ahead of the running raster, my PC is kinda slow and likes to slow way down at times on the user process side.

I thought I would do alot more raster engraving when I was coding this and building my laser. I ended up not doing much raster engraving at all and 99.9% vector. So the raster solution is stuck in a half finished state on the front end gcode generation.

The other changes were do make the PPI code non-float in the base thread and add duty cycle (which I have been very happy with and have not used PPI since putting it in).

Jeremy

Tuesday, August 28th 2012 - 11:08 PM

jv4779 wrote:Take a look at my modifications to Ben's linuxcnc configs.

https://github.com/jv4779/2x_laser

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).

add commentadd comment in the forum

reader comment Comment from: educa on Tuesday, August 28th 2012 - 11:07 PM
Any idea Ben at what speed you can aproximately switch on and off a co2 laser tube during raster engraving ?

Tuesday, August 28th 2012 - 10:42 PM

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.

add commentadd comment in the forum

reader comment Comment from: evokanivo on Wednesday, August 15th 2012 - 2:08 AM
I have been looking through Ben's hal file and laserfreq module. I hope someone might confirm or correct what I think is going on:

  • The configuration defines only two physical pin outputs for laser control - "laser-pwm" and "laser-final".
  • Laser-final connects to the laser power supply's TH (enable when ~5V ?) and laser-pwm to INPUT. For cutting (PPI), INPUT will be be a continuous PWM signal, while TH will be pushed high in 3ms bursts, with the interval between bursts being ppmm/velocity.
  • A PPI rate that is high enough will result in continuous PWM (3ms is longer than time interval between bursts).
  • 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.

Anyway, it's pretty cool that engraving can be done with EMC. I didn't know that until I read this thread.
reader comment Comment from: jv4779 on Wednesday, August 1st 2012 - 8:50 PM
The Z axis doesn't home. The limit switches are there to protect the machine if you try and jog it past the limits. When you tell LinuxCNC to "Home All" the Z axis (labeled U in Ben's 2.x config) will be set to zero in its current location and not move. Page up/down will then move it. The actual position numbers for this axis don't mean anything, you just move it up and down to a fixed focus distance from your work piece.
reader comment Comment from: evokanivo on Wednesday, August 1st 2012 - 8:21 PM
BenJackson wrote:
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.


Any idea why the Z axis has switches on the top and bottom, but X and Y have them only on one side? I figured homing the Z axis would be done in the same manner as X and Y.
reader comment Comment from: jv4779 on Monday, July 16th 2012 - 9:56 PM
I would assume the output of both raster systems would be identical. Both are laying down dots at an accuracy equal to the step size.

I like the pure gcode because the file can be touched off. I also hated having to manage 2 files. My scripts don't support this right now, but pure gcode also allows vector and raster to be included in the same file (maybe an inkscape plugin). And just in general there isn't any way to make the O<sub> style with kstreamer any more user friendly. My system should be a little easier on the controlling computer since it uses no floating point and doesn't have to do the stepgen position update at servo thread speeds.

I talked about duty cycle here http://www.buildlog.net/forum/viewtopic.php?f=4&t=1303.

I have been using duty cycle for awhile now and I find it easier to dial in a new material because to cut deeper, just go slower. I have since learned some interesting things about duty cycle and the magic 3ms laser pulse. When the duty cycle goes over 50% and the off time is under 3ms the laser cuts less deep, which I am assuming because the power burst you get from the ppi starts to drop when the power supply isnt' off long enough. In effect for thicker material the range of duty cycle is 0-50% and only goes over 50 when doing paper that needs a very fast feed rate and also a high duty cycle or you get perforations. Paper seems to like PPI better, wood and acrylic like duty cycle better.
reader comment Comment from: educa on Monday, July 16th 2012 - 5:55 PM
Thanks jv4779,

I must say that currently it looks like I can solve the problems I had.

The line that seems to hang my gcode execution is the M3S0 , but I simply don't use that one anymore.


I understand why you might want to change the raster engraving to solething using PURE gcode, but is there any difference in the engraved result between Bens' method and yours? I must say the output of Bens system looks very nice.


Also, I looked at your githuband discovered that you have a M4 function for laser duty cycle setting???
I know about PPI and studied all Dirktheengs' postsand videos , but is M4 used for some kind of other technique? Could you tell a little more about that one?

Kind regards and thanks,
Bart (not BDring ;-). )
reader comment Comment from: jv4779 on Monday, July 16th 2012 - 2:35 PM
Take a look at my modifications to Ben's linuxcnc configs.

https://github.com/jv4779/2x_laser

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.
reader comment Comment from: educa on Saturday, July 14th 2012 - 8:35 PM
Hi,

I managed to setup a machine with the correct settings for working with the emc2 config files of Ben.
I can cut with ppi, set laser power,....

There is just 1 thing that doesn't seem to work somehow.

When I want to engrave a picture and then cut it out in the same action, then I would normally say one would use the following commands

G90
G21
M3 S1
M68 E0 Q0.2
F30000
O145 call [1111] [47.3] [145.0] [105.4] [90.0] [0.10] [0.10] [25]
M3 S0
G1 X25 Y25 F600
G1 Z-0.01 F40000
M3 S20
G1 X175 Y25 F600
G1 X175 Y175 F600
G1 X25 Y175 F600
G1 X25 Y25 F600
M3 S0
M2


The problem is that this script does show up perfectly in axis and it also engraves the picture I want , but then it stops. The line after the O145 call is never executed.

I have tried to find a solution myself and I found in the files 144.ngc and 145.ngc a command M2 which I removed (M2 = program end so I expected this to be the solution)

However, even after removing these 2 M2 commands, I still cannot run any command after the engraving action.


Is there anyone else having the same problem? Possibly a solution ?

Kind regards,

Bart Libert



EDIT: When I change the .nc file and put 2 times O145 call [1111] [47.3] [145.0] [105.4] [90.0] [0.10] [0.10] [25] each on their own line, then the emc2 does engrave both. Even if they both have a different image, location and width height. Its just other regular gcode that doesn't seem to be working.
reader comment Comment from: sliptonic on Tuesday, May 1st 2012 - 8:37 PM
According to guys on #linuxcnc IRC channel: stat.origin was split into stat.g5x_offset and stat.g9x_offset

Renamed stat.origin to stat.g5x_offset and it worked.
reader comment Comment from: sliptonic on Monday, April 30th 2012 - 7:51 PM
Hi Ben,
I recently upgraded to 2.5.0 linuxcnc and rastering stopped working for me. Vector cutting is still working great. I've made a bunch of changes related to the name change but I'm still getting this error in the console:

Code: Select all
Traceback (most recent call last):
  File "/home/brad/linuxcnc/configs/2x_laser/M144", line 35, in <module>
    origin = stat.origin[axis]
AttributeError: 'linuxcnc.stat' object has no attribute 'origin'


Any idea what else I need to change?
reader comment Comment from: educa on Tuesday, April 24th 2012 - 9:01 PM
oops

I understand your coordinate system, but in my emc setup (which looked like it was exactly your setup) the homing sequence seems to go to the upper right corner of the computer screen in axis.

Something wrong?

I suppose in your setup it should go to the lower left corner on the computer screen ?

Tuesday, April 24th 2012 - 8:43 PM

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.

add commentadd comment in the forum

reader comment Comment from: educa on Tuesday, April 24th 2012 - 12:40 PM
Ben,

I'm almost at the point that I can connect my hardware to emc , but I still have a few important questions.
I configured emc like you did, but when I run without atached electronica, the axis display shows me a "homing?"" sequence to the upper right of the screen.

Can I please ask you.


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?

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?


Judging on what emc shows I have to guess that you have 2 homing switches which are both in the upper right corner of the machine if you would take a picture of it standing in front of the machine. Right on X and top on Y. Correct?

Kind regards,

Bart
reader comment Comment from: educa on Tuesday, February 28th 2012 - 8:30 AM
@dirktheeng did you manage to get emc working fine with PPI and raster engraving ?

I hooked up my steppers to emc yesterday and must say I'm impressed with the basic steps to get movement.

Now tonight I'll install ubuntu instead of using the live cd.

I allready tried to do the PPI using an arduino, but discovered a few days ago that arduino is VERY VERY bad at precize timing. An assembly programmed atmega on the other hand is very accurate.

But since I have a very speedy PC here with less then 4200 jitter emc2 kindly reports it should be capable of sending upto 50000Hz signals to my machine? Thats 1 meter per second speed with 0.02mm resolution (0.000787")

The nice stuff about emc is that it looks like I'll be able to build custom frontends for this + apart from the 50Khz signal emc can make you still have a huge processing power available for other logic.
reader comment Comment from: Modelart on Thursday, February 16th 2012 - 11:22 AM
someone saw Bill?, I suspect that in another jaw dropping project...
regards
rick
reader comment Comment from: dirktheeng on Sunday, January 15th 2012 - 7:41 PM
Ben,

I'm going to give EMC a go and see if I can make some progress with what I want to do through linux/emc/fpga.

I'm downloading the ISO now. Is there any reason why the 10.04 ubuntu version will not work? I think most people use the 8.04 version right? Anyhow, I'll give that a shot and see if I can't make it work.

Edit: nevermind... I just read all the documentation on Ben's github (wow! what a great tool he has developed) and saw that his install is based on the 10.04 live cd
reader comment Comment from: Modelart on Friday, January 13th 2012 - 4:36 PM
BenJackson wrote:
Modelart wrote:AXIS = 1
an error apears (too late at night to find why)

Needs axis=int(axis) because the config is a string. Never tested that.

Dont test this, i will.

Modelart wrote:
BenJackson wrote:The only minor drawback is that the image is flipped (EDIT: mirrored) around x axis.

Look for image.resize in M144 and see this Python document for things you can do. You probably need some kind of image.transpose() to flip it the right way.


You make it look easy. Its done, i have the files if any want,
i have too much questions about programming!
Thanks and Regards
Rick

Friday, January 6th 2012 - 3:53 AM

Modelart wrote:AXIS = 1
an error apears (too late at night to find why)

Needs axis=int(axis) because the config is a string. Never tested that.

Modelart wrote:The only minor drawback is that the image is flipped (EDIT: mirrored) around x axis.

Look for image.resize in M144 and see this Python document for things you can do. You probably need some kind of image.transpose() to flip it the right way.

add commentadd comment in the forum

reader comment Comment from: Modelart on Friday, January 6th 2012 - 1:51 AM
BenJackson wrote: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.


i have put .ini file
[RASTER]
IMAGE_PATH = /home/my path
AXIS = 1
an error apears (too late at night to find why)

but editing m144 line 28 to axis = 1, the posted .hal, and o146 do the trick.
The only minor drawback is that the image is flipped (EDIT: mirrored) around x axis.
Thanks for the reply Ben
Regards
Rick

Thursday, January 5th 2012 - 10:55 PM

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.

add commentadd comment in the forum

reader comment Comment from: Modelart on Thursday, January 5th 2012 - 10:47 PM
BenJackson wrote: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.



o146 with flipped x/y change raster scans to y, but changes in the hal (also has to change axis.0 to 1) doesnt fire the laser at all.
Is coded in another place, or i doing it wrong?

attached my hal file and o146

regards
Rick
Attachements...
146.txt
146.ngc
(655 Bytes) Downloaded 172 times
2x_Laser Scans on Y.txt
.hal file
(8.17 KiB) Downloaded 342 times

Thursday, January 5th 2012 - 10:23 PM

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.

add commentadd comment in the forum

reader comment Comment from: Modelart on Thursday, January 5th 2012 - 10:10 PM
bill.french wrote:I didn't have to uncomment that section to get it to work.

Also, concerning x vs. y -- why would you want it to be y? Isn't x always the faster axis?


I proposed it for non 2x_machines, like mine :oops:

regads
rick
reader comment Comment from: TLHarrell on Thursday, January 5th 2012 - 9:29 PM
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.
reader comment Comment from: bill.french on Thursday, January 5th 2012 - 8:46 PM
I didn't have to uncomment that section to get it to work.

Also, concerning x vs. y -- why would you want it to be y? Isn't x always the faster axis?
reader comment Comment from: sliptonic on Thursday, January 5th 2012 - 7:34 PM
BenJackson wrote:
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?


I didn't do File|Open. I used your sample code from the README. It was giving me the 'unknown M code' error which I assumed was because it didn't associate .py with python. When I uncommented those lines, it worked great. Very smooth.

Thursday, January 5th 2012 - 5:42 PM

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?

add commentadd comment in the forum

reader comment Comment from: sliptonic on Thursday, January 5th 2012 - 1:54 PM
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.
reader comment Comment from: Modelart on Thursday, January 5th 2012 - 11:47 AM
well, has to do again apt-get install / comp --install and it work flawlessly. I suppose something goes wrong first time.
I have this setup in an old pc, and have some memory problems on large images (ubuntu 8.04 lts), will try to stop axis backplot with (AXIS, stop) after work.
I still marvel how well PPI an raster implementation goes.
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.
Thanks to all.
Regards
Rick

Thursday, January 5th 2012 - 6:22 AM

I have pushed changes to github reflecting the issues people encountered:

Code: Select all
commit b00edf842f3df55d037a2d117ff4df14b2978cdc
Author: Ben Jackson <ben@ben.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 <ben@ben.com>
Date:   Tue Jan 3 20:56:43 2012 -0800

    Modify M144 for compatibility with [TRAJ]LINEAR_UNITS=inches configs

commit be80545e16fb526a106b3d572b00214c6b9ba90d
Author: Ben Jackson <ben@ben.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.

add commentadd comment in the forum

reader comment Comment from: bill.french on Thursday, January 5th 2012 - 2:50 AM
Modelart wrote:It needs to be in the directory where you start EMC

Actually i think it needs to be in the same folder as the M144/M145 files. Or maybe that's where i coincidentally started emc from... :-/

Thursday, January 5th 2012 - 1:57 AM

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.

Modelart wrote:yeah, thats strange, genterate actual.png file, 1x1px blank(empty file) aprox 73bytes. I surelly missed something

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.

add commentadd comment in the forum

reader comment Comment from: Modelart on Thursday, January 5th 2012 - 1:23 AM
bill.french wrote:
Modelart wrote:i made a bad png file?, have you some png file to test?


It should genreate an "actual.png" file... look for that. It should be B&W and is what's actually engraved.


yeah, thats strange, genterate actual.png file, 1x1px blank(empty file) aprox 73bytes. I surelly missed something
thanks for come in Bill.
Regards
Rick
reader comment Comment from: bill.french on Thursday, January 5th 2012 - 12:36 AM
Modelart wrote:i made a bad png file?, have you some png file to test?


It should genreate an "actual.png" file... look for that. It should be B&W and is what's actually engraved.
reader comment Comment from: Modelart on Thursday, January 5th 2012 - 12:24 AM
BenJackson wrote:
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.


Thanks Ben, is clear, i only have to change some values on hal and ini files to make it run for cutting, i think ppi made less charring and cut more fast in my setup! great thing, congrats for that.
Cant figure out why on raster engraving i only get some nice bar codes (with exact dimensions).... run emc from command line and i see it could load the image, wondering what could be... i made a bad png file?, have you some png file to test?, any clue about will be welcome!
EDIT: i figure that this happens when z is negative, for z positive, doesnt fire at all, im lost....
regards
Rick
Attachements...
bar code.jpg

Wednesday, January 4th 2012 - 9:35 PM

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! :)

add commentadd comment in the forum

reader comment Comment from: sliptonic on Wednesday, January 4th 2012 - 7:52 PM
BenJackson wrote:...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 [ ]


I can think of a couple ways to both work around and actually fix the bug in the Heeks post processor. That needs to be done regardless. 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.

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.

If there's a reason to do a G1 without the laser being on (and I can't think of one), it can be done by preceding it with a M5 to turn off the spindle.

Wednesday, January 4th 2012 - 5:19 PM

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.

add commentadd comment in the forum

Wednesday, January 4th 2012 - 5:12 PM

bill.french wrote:
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 [ ]

add commentadd comment in the forum

reader comment Comment from: bill.french on Wednesday, January 4th 2012 - 4:38 PM
sliptonic wrote:Then I get a bogus cut on my material

Ben suggested i add a M65 P0 to the start of my gcode.
reader comment Comment from: sliptonic on Wednesday, January 4th 2012 - 4:29 PM
I noticed an undesired side-effect of "magic Z" control. My job runs fine unless I interrupt it and restart it. Then I get a bogus cut on my material. I found that my HeeksCNC post processor is doing a G0 move to the starting location before moving to the safe height. That should certainly be fixed in HeeksCNC and I'm working it. But it raises the question why one would ever want the laser on during a G0 move (or off during a G1).

I'm not sure how much time it takes to move down from 0 to .01mm at very fast plunge rate, but it must take some time and during that time the beam is on.

Instead of using 'magic Z', would it make sense to tie the laser on/off directly to G1/G0 respectively? That would have the side benefit of letting me return the Z axis to table height control.
reader comment Comment from: Modelart on Wednesday, January 4th 2012 - 1:32 PM
Hi Ben:
I came across your ppi config for emc2, (I think it's great!). I want to test raster engraving.
Looking in the hal appears that the laser is fired through pin14 (pwm), and pin17 (laser final).
Actually i setup my laser psu like this (custom config - magic z ) :

pwm to PSU pin 2 (ttl high)

PSU pin 2 shorted to pin 4 (wp to ground)

Pot between ground (oin 4) and +5V (pin 6), and whiper to Input(pin 5) to set power to max. 18ma (40w tube, pwm 100% duty)

th | tl | wp | ground | input | +5V
1 | 2 | 3 | 4 | 5 | 6

Surelly is connected the bad way....

Can you tell me how PP pins 14 and 17 are connected to PSU, for your setup?
Thank for your time
Regards
Rick
reader comment Comment from: educa on Wednesday, January 4th 2012 - 9:38 AM
What is F100 ? 100mm/min?

Also could you take a picture of cut quality (cut edge) for the different settings ?

Most cuts on that pic look quite nice

Wednesday, January 4th 2012 - 6:02 AM

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:
P1000176.JPG


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)

add commentadd comment in the forum

Tuesday, January 3rd 2012 - 8:57 AM

...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.

add commentadd comment in the forum

Tuesday, January 3rd 2012 - 6:29 AM

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...
lens-spacer.zip
(425 Bytes) Downloaded 217 times

add commentadd comment in the forum

Monday, January 2nd 2012 - 8:16 PM

I took out the manual toolchange module because it had a nag at startup and didn't seem very useful. It's likely that there are two HAL pins that need to be tied together to short-circuit :

Code: Select all
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)

add commentadd comment in the forum

reader comment Comment from: sliptonic on Monday, January 2nd 2012 - 3:37 PM
BenJackson wrote:I've pushed my git repo to github
...
I'm sure it's incomplete, so please ask questions and I will improve it.
...


Well, I'm still fighting with my power supply issue and I haven't tried rastering yet but otherwise I've have great success with your config. I only had one small struggle: I'm generating my g-code from HeeksCNC with the emc2b simplified post-processor. When I'd run the g-code through your config, EMC2 would appear to lock up for a long time and then be incredibly sluggish when it came back. I finally realized that it's because your config has the manual tool change hal component disabled and Heeks was putting in an M6.

HeeksCNC uses the tool diameter to account for the kerf when calculating the tool path and the profile operations are configured to cut on one side of the line or the other (or on the line if you choose). Without tools, are you using EMC2 cutter compensation or accounting for the kerf in your design?

Very nice work, btw. Thanks again.

Sunday, January 1st 2012 - 11:56 PM

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...

add commentadd comment in the forum

Sunday, January 1st 2012 - 6:24 AM

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.

add commentadd comment in the forum

reader comment Comment from: sliptonic on Friday, December 30th 2011 - 6:59 AM
Wonderful. Thanks Ben!

Thursday, December 29th 2011 - 7:25 AM

I've pushed my git repo to github:

https://github.com/bjj/2x_laser

I just wrote a README (which github formats nicely) which tries to document what I've done. I'm sure it's incomplete, so please ask questions and I will improve it.

This includes all the rastering support if you insert a few lines of gcode for it, but not the other work I was doing to try to automate the creation of gcode with rastering from a print job.

add commentadd comment in the forum

reader comment Comment from: sliptonic on Thursday, December 29th 2011 - 4:40 AM
I finally got my power supply and hope to be burning in the next couple days. With all the chat about PPI, I'm anxious to try reproducing your success with EMC2. Any more details about your custom HAL component and your configuration are greatly appreciated.
reader comment Comment from: sliptonic on Tuesday, December 20th 2011 - 2:33 PM
Thanks. I'm still waiting on my power supply but hoping to have it over the Christmas break. I've been reading the forum messages about PPI and I'm curious how your pure EMC2 implementation compares.

And if it's easier to just zip up the emc2 config and email it, that's fine with me. Thanks again.

Saturday, December 3rd 2011 - 7:22 AM

I will try to put something up soon. My wife has planned activities for me this weekend and I'm also quite distracted by aichallenge.org.

add commentadd comment in the forum

reader comment Comment from: sliptonic on Saturday, December 3rd 2011 - 12:47 AM
Ben,
Just finished reading through your log. Great stuff.

I'm in the process of converting an old ULS-25A and I'm using Bart's interface/pololu driver controlled by EMC2. I'm not as far along as you but I'm really interested in what you've done with EMC2. Do you think I can get a copy of your configuration?

If you're willing to share it and have a git repo, put it there. Perhaps we can get a stock machine configuration included in EMC2.

I'm also interested in writing a custom post-processor for HeeksCNC but that'll have to wait until I'm actually cutting.
reader comment Comment from: naPS on Sunday, September 25th 2011 - 3:52 PM
Sweet! That's awesome!

Sunday, September 25th 2011 - 2:55 AM

This boring and sort of wobbly star:
P1000125.JPG


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:

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.

add commentadd comment in the forum

Wednesday, September 21st 2011 - 6:45 PM

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...

add commentadd comment in the forum

reader comment Comment from: StigOE on Wednesday, September 21st 2011 - 7:24 AM
BenJackson wrote: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).

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?
BenJackson wrote: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.

I believe it should be possible to use one of the Misumi slot covers, but I don't know which type would be best, the foam type or the plastic type.

Wednesday, September 21st 2011 - 6:05 AM

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.

add commentadd comment in the forum

Saturday, September 17th 2011 - 11:31 PM

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:
P1000123.JPG


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...
zero-fixture.zip
(2.27 KiB) Downloaded 306 times

add commentadd comment in the forum

reader comment Comment from: dirktheeng on Saturday, September 17th 2011 - 12:36 PM
Wow,

I think this could be some of the reason why my stepper drivers humm too. I'm going to go get a cap and put it on mine and see what happens

Wednesday, September 14th 2011 - 7:07 AM

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.

add commentadd comment in the forum

Wednesday, September 14th 2011 - 2:49 AM

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:
24v_cap.png


Capacitor installed:
P1000121.JPG

add commentadd comment in the forum

Tuesday, September 13th 2011 - 9:52 PM

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)

add commentadd comment in the forum

reader comment Comment from: bdring on Tuesday, September 13th 2011 - 9:07 PM
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.

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.


On my first use of Pololus, I was having issues where the laser could trigger a step, or some kind of jump in the motors. I tried to address everything that could cause that. The big caps were added as local storage in case something was causing the 5VDC supply to droop and cause a reset on the Pololus. That probably was not the cause, but it seemed like a good idea.

Tuesday, September 13th 2011 - 4:05 PM

bdring wrote:I had a Pololu driver fail in dead short recently. I did not do an autopsy, but I still have it. Fortunately the 24VDC P/S handled it well.


If you have soldering tweezers or a couple of irons I'd like to know if removing the main cap makes the short go away.

If so the ESR on your mainboard cap may be too high, leading to too much ripple in the small ceramic causing it to overheat.

add commentadd comment in the forum

reader comment Comment from: bdring on Tuesday, September 13th 2011 - 2:46 PM
zero stepper activity


I had a Pololu driver fail in dead short recently. I did not do an autopsy, but I still have it. Fortunately the 24VDC P/S handled it well.

Tuesday, September 13th 2011 - 8:14 AM

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.

Image35.jpg
Image36.jpg

add commentadd comment in the forum

Tuesday, September 13th 2011 - 5:02 AM

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!

add commentadd comment in the forum

Monday, September 12th 2011 - 6:44 AM

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.

add commentadd comment in the forum

Monday, September 12th 2011 - 6:37 AM

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.

add commentadd comment in the forum

reader comment Comment from: dwessels on Monday, September 12th 2011 - 6:20 AM
BenJackson wrote: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.

Hi Ben,

What DIN rail relay did you get? Where did you get it from.

Thanks

Monday, September 12th 2011 - 12:21 AM

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.

Image31.jpg
Image32.jpg

add commentadd comment in the forum

Saturday, September 10th 2011 - 11:53 PM

My laser finally cut its own electronics tray:

P1000099.JPG


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.

add commentadd comment in the forum

Thursday, September 8th 2011 - 6:35 AM

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):
P1000098.JPG


Here's one letter under higher magnification (courtesy of a USB microscope by Celestron):
Image28.jpg
Image27.jpg

add commentadd comment in the forum

Tuesday, August 30th 2011 - 10:03 PM

I finally put a meter on everything so I could plot laser power vs V IN:

Untitled 1 - OpenOffice.org Calc 8302011 24142 PM.bmp.jpg


It appears to have two linear regions:

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.

add commentadd comment in the forum

reader comment Comment from: bdring on Saturday, July 9th 2011 - 12:43 PM
Sorry, I got the cable issue. I was thinking about something else. I agree and will be doing that soon.

I like the way the door works now. I'll implement your suggestion of making the rear top cover more easily removable. I will slot the front holes, so you loosen them and slide it out. The slots will be hidden by the hinge.

new_rear_top.JPG

Saturday, July 9th 2011 - 7:18 AM

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.

add commentadd comment in the forum

reader comment Comment from: bdring on Wednesday, July 6th 2011 - 11:37 PM
Thanks for the list....

Carriage Hole - That sounds like a good idea. Have you done this on yours? I can add it to the drawing and get it with the next buy. I have about 25 left.
Right angle fitting - I'll give that a look when I work on the ideal hose hole location
Nozzle Deeper Pocket. - Sounds like a good idea. I have about 40 nozzles in stock though.
Lens adapter. - I have been meaning to try that. I really does not fit with the current kits, so it could be a separate item.
Dirk's Travel Log - I will addressing travel tweaks when Makerslide is ready.
Door Stop Issue - I might just switch to a single door stop.
Table Cutting Area - It sounds doable. Once all the travel issues have been worked out, I will look into it.
Table Squareness - The 2.x was never meant to have true 3 axis perfection. I had an upgrade for the original laser for this. Makerslide might give a simple solution.
More Honeycomb compatible. - I'll look into it. Misumi has a lot of options that would help.
Top Skin Removal - That sounds doable. Maybe open ended slots facing towards the door would allow the that skin to slide out when loosened. The hinges might hide the slots.
Y Carrier Turn Around - I need a visual on this one.

Wednesday, July 6th 2011 - 8:46 PM

One more suggestion I forgot about:

The Y cable carrier should be turned around (so that the loop is at the front):

I measured at one point and I think the current attach point would still work.

add commentadd comment in the forum

Wednesday, July 6th 2011 - 5:02 AM

Bart's post about the black washer upgrade reminded me of my list of ideas/suggestions compiled while building:

add commentadd comment in the forum

reader comment Comment from: dirktheeng on Tuesday, June 28th 2011 - 11:46 PM
Ben,

How do you propose doing all the calcs and generating pulse trains with the mini ITX? Custom software? Do you have something in mind for open source to start from? I'm interested as I am only so-so impressed with grbl and would like something better.

Let me know.

Tuesday, June 28th 2011 - 6:31 AM

Curved side up.

add commentadd comment in the forum

reader comment Comment from: naPS on Tuesday, June 28th 2011 - 6:11 AM
Which direction is your lens facing?

Tuesday, June 28th 2011 - 4:36 AM

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.

add commentadd comment in the forum

Sunday, June 26th 2011 - 11:11 PM

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":
IMG_0612.JPG
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:
IMG_0613.JPG

add commentadd comment in the forum

reader comment Comment from: dirktheeng on Sunday, June 26th 2011 - 1:47 AM
BenJackson wrote:Drik,

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:
IMG_0555.JPG


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.


GRBL is a decent code... it isn't really awesome, but it's ok. It's a messy code and has some hangups, but I'm working through all of them and fixing a lot of poor programming. My goal is to have a solid all purpose g-code controller that I can run with my computer, but doesnt' have to. It will also run off of USB so I can use my laptop. It's going to take a while, but I hope to write a PC based program to communicate and display information and have a user interface much like MACH 3.
reader comment Comment from: tylerv on Saturday, June 25th 2011 - 11:32 PM
I'm using GRBL in the early stages of getting motion working on my laser, but I like the idea of the "laser as a printer" and will probably try to get there eventually.

Bart pointed me to LAOS Laser as another open source project to have a laser cutter act like a printer. It's worth at least a quick look, though I don't remember if they have any production code available yet. Just FYI.

Saturday, June 25th 2011 - 7:01 PM

Drik,

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:
IMG_0555.JPG
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.

add commentadd comment in the forum

reader comment Comment from: dirktheeng on Saturday, June 25th 2011 - 3:00 PM
Ben,

Hey, check out the code I am developing on github. I could really use a partner to make this work well and speed up the development. GRBL works, but it has holes that need to be fixed and is missing several options that would be very useful for operating a CNC and specifically a laser CNC. I've made several upgrades already and tested them on the laser. I have a development plan put together in the readme file.

https://github.com/dirktheeng/grbl

Do you think we can work together? What code are you using?
reader comment Comment from: dirktheeng on Saturday, June 25th 2011 - 2:37 PM
BenJackson wrote: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 took that door stop off... we don't need one on both sides fo the door. On my mods to maximize the y azis travel, the right side door stop hit the right side gantry plate, so I took it off. The door holds up just fine with only the left side door stop. Now if the gantry hits anything it is the z axis bearing holder and I set those so that they hit at the same time and dont' rack the axis.
reader comment Comment from: bdring on Saturday, June 25th 2011 - 3:51 AM
Seems like a bit of a design flaw. We have to look for a way to prevent that.

Saturday, June 25th 2011 - 2:41 AM

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.

add commentadd comment in the forum

Wednesday, June 22nd 2011 - 5:23 AM

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:
IMG_0610.JPG
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.

add commentadd comment in the forum

Tuesday, June 21st 2011 - 12:38 AM

Here's the first thing I cut that was more substantial than paper:
IMG_0609.JPG


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!

add commentadd comment in the forum

Monday, June 20th 2011 - 7:24 PM

dirktheeng wrote:I will be interested to find out how valuable the led pre-alighnment turns out.

To install my new tube I:
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.

add commentadd comment in the forum

Tuesday, June 14th 2011 - 6:49 AM

Buildlog 2.x Laser with laser 2.x, now with more dogbone:
IMG_0608[1].JPG


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.

add commentadd comment in the forum

reader comment Comment from: dirktheeng on Monday, June 13th 2011 - 9:18 PM
that's pretty cool ben... I may have to build a 3d printer myself!
reader comment Comment from: naPS on Sunday, June 12th 2011 - 9:15 PM
The easiest way to get the tygon to push onto the tubes is to heat it up in some nearly boiling water for a few seconds. Once you do that, it slips right on. At least, it did for me. After it cools, it returns to it's original rigidity, which produced a water tight seal for me.

Sunday, June 12th 2011 - 8:28 PM

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!
IMG_0605[1].JPG
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:
IMG_0606[1].JPG
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.
IMG_0607[1].JPG
Zot!


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.

add commentadd comment in the forum

reader comment Comment from: twehr on Thursday, June 2nd 2011 - 11:24 AM
[quote="BenJackson"]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".[/quote]

That is the one I am using and it does extremely well. I tried using the manifold with a single outlet from it. But those outlets are too small. I went with a single line from a new brass fitting. Works great.

Thursday, June 2nd 2011 - 2:37 AM

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".

add commentadd comment in the forum

reader comment Comment from: LeonS on Wednesday, June 1st 2011 - 11:48 AM
Bummer.

You may be able to fix the break since the CO2 seal was not broken. If the break was clean, a good epoxy might do the trick.

Regards and sympathies,
Leon

Wednesday, June 1st 2011 - 5:31 AM

I don't think this needs much explanation:
IMG_0599.JPG


The other end (rear) had a much fatter fitting that required much more force to get on and came out fine...

add commentadd comment in the forum

Wednesday, June 1st 2011 - 4:03 AM

Dirk,

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).

add commentadd comment in the forum

reader comment Comment from: dirktheeng on Wednesday, June 1st 2011 - 3:32 AM
Ben,

I will be interested to find out how valuable the led pre-alighnment turns out. I've thought about doing this myself, but I can't help but think that there is no way to make sure that the pen laser is on the exact same axis of the CO2 laser once you swap them out. I mean, they will be close, but I would dare say it would be just dumb luck if one got the CO2 laser put in there and it was aligned to a good focus right off the bat. My question is whether or not it is worth the time/expense/effort for a guy (mainly me) without any CNC stuff available here to try to use a red LED laser to align the stuff given that I am relatively certain I am going to have to do it again after taking out the red laser and putting in the CO2. Is the idea that one is just getting the CO2 laser close enought that it hits the mirrors and such without bouncing around dangerously or are you expecting to get a true alignment out of it? Just curious if you've thought about it and what your stratagy is. I have been seriously thinking of asking bart or one of the fab shops to make me something simmilar, but I'm not sure what I will gain. I don't mean to sound at all accusatory by my comments/questions, I am trying to make up my mind and playing a bit of devils advocate as well as hoping you have a really good strategy to address these concerns as the alignment part of this project scares me some (if there's a chance for me to get hurt it would be here... through the years as a scientist I have seen some aweful laser accidents).

Dirk

Tuesday, May 31st 2011 - 11:19 PM

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. :)

add commentadd comment in the forum

reader comment Comment from: dirktheeng on Tuesday, May 31st 2011 - 10:06 PM
Wow Ben, this came together quickly! I may just be slow, but I've been working on this for a few weeks and haven't tested the motors yet. However, I am just about ready to. Once I get the arduino's here, I can run GRBL to get teh motors moving. That will be an exciting day!

Looks good! keep up the good work!

Tuesday, May 31st 2011 - 5:19 AM

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. ;-)

add commentadd comment in the forum

Tuesday, May 31st 2011 - 12:28 AM

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.

add commentadd comment in the forum

Monday, May 30th 2011 - 11:20 PM

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:
IMG_0591.JPG

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.
IMG_0592.JPG

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:
IMG_0595.JPG

add commentadd comment in the forum

Saturday, May 28th 2011 - 6:49 PM

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:
IMG_0587[1].JPG
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:
IMG_0588[1].JPG


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...
LaserHolder.zip
(44.54 KiB) Downloaded 457 times

add commentadd comment in the forum

Friday, May 27th 2011 - 5:51 AM

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...
IMG_0582[1].JPG
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:
IMG_0586[1].JPG

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.

add commentadd comment in the forum

Friday, May 27th 2011 - 5:40 AM

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:

bom.jpg
Bill of Materials


Note I did not get the Electronic kit (but I did get some custom DIN stuff).

Notable missing items:

add commentadd comment in the forum

About Us | Contact | 2010 BuildLog.Net