Ben's 2.x Laser Build

Post your build logs here

Re: Ben's 2.x Laser Build

Postby educa » Mon Jul 16, 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 ;-). )
educa
 
Posts: 229
Joined: Thu Dec 22, 2011 9:13 pm

Re: Ben's 2.x Laser Build

Postby jv4779 » Mon Jul 16, 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.
jv4779
 
Posts: 37
Joined: Fri Dec 09, 2011 10:54 pm

Re: Ben's 2.x Laser Build

Postby evokanivo » Wed Aug 01, 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.
evokanivo
 
Posts: 61
Joined: Mon May 31, 2010 1:18 am
Location: Renton, WA

Re: Ben's 2.x Laser Build

Postby jv4779 » Wed Aug 01, 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.
jv4779
 
Posts: 37
Joined: Fri Dec 09, 2011 10:54 pm

Re: Ben's 2.x Laser Build

Postby evokanivo » Wed Aug 15, 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.
evokanivo
 
Posts: 61
Joined: Mon May 31, 2010 1:18 am
Location: Renton, WA

Re: Ben's 2.x Laser Build

Postby BenJackson » Tue Aug 28, 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.
BenJackson
 
Posts: 494
Joined: Fri Apr 15, 2011 6:13 pm

Re: Ben's 2.x Laser Build

Postby educa » Tue Aug 28, 2012 11:07 pm

Any idea Ben at what speed you can aproximately switch on and off a co2 laser tube during raster engraving ?
educa
 
Posts: 229
Joined: Thu Dec 22, 2011 9:13 pm

Re: Ben's 2.x Laser Build

Postby BenJackson » Tue Aug 28, 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).
BenJackson
 
Posts: 494
Joined: Fri Apr 15, 2011 6:13 pm

Re: Ben's 2.x Laser Build

Postby jv4779 » Wed Aug 29, 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
jv4779
 
Posts: 37
Joined: Fri Dec 09, 2011 10:54 pm

Re: Ben's 2.x Laser Build

Postby BenJackson » Wed Aug 29, 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.
BenJackson
 
Posts: 494
Joined: Fri Apr 15, 2011 6:13 pm

PreviousNext

Return to Build Logs

Who is online

Users browsing this forum: No registered users and 2 guests