Raster engraving

[Gabriel Helms]

Hi All,
Has any progress been made on being able to raster engrave with the lasersaur by anyone yet? I have some limited programming experience in C++, BASIC, and macros (just not in python or java) and would be willing to help out if I can. Since most programming languages work on similar principles, I figured it wouldn't be too hard to learn it along the way. Does anyone have an alpha or beta started?

Sincerely,
Gabriel Helms

(H): 916-750-8943
(C): 805-427-5126

[Stefan Hechenberger]

Hi Gabriel,

Raster engraving is still queued. The last wave of debugging was quite
time intensive.

Here is what I was thinking. First order of business is to make the
firmware receive raster data. This needs to be done in an efficient way.
Afaik there is no gcode recommendation for this but the following would
work and should not conflict with any other gcode stuff.

G8 P0.1
G8 X50
G8 N
G8 D<data>
G8 D<raster data encoded in ascii>
G8 N
G8 D<data>
...

G8 P0.1 sets the dimensions of one 'dot'. It's the space reserved for
one data pixel, one character in the raster data. The technical minimum
is 0.034mm (based on the minimum step distance) but for best results
this should reflect the focus diameter of the setup.

G8 X50 defines the direction of the raster data and the offset. So 'X'
means data will be interpreted as x-axis lines. The offset is necessary
to achieve constant speed during engraving. It's the distance used for
accelerating the head (and also decelerating).

G8 D<data> sends the actual data. Likewise lines will be concatenated
until a 'G8 N' arrives. Currently line length is limited to 80
characters. The actual data is encoded into the extended ascii range
([128,255]). Each character is a dot. The new raster line marker also
resets the head to the next line which is 0.1mm (or whatever was defined
with G8 Px) under the next.

Sounds good?


--
Stefan Hechenberger
studio: Nortd Labs - labs.nortd.com
resident: F.A.T. Lab - fffff.at
project: Lasersaur - labs.nortd.com/lasersaur

[jet]

G code doesn't really need "raster" -- you just set a shallow cutting
depth and etch away.

So for the lasercutter, why not set a raster level of cutting energy and
just etch lines/dots as needed? I've been thinking about this as
well, it seems like there's going to be a DPI/resolution problem with
different steppers, different focal tubes, and so on. If I have a
300dpi image but a step resolution of .1mm, it will need to be converted
or resized based on what the user wants to happen, and I suspect that'll
be done before gcode is generated.

--
J. Eric Townsend, IDSA
design <http://www.allartburns.org>
hacking <http://www.flatline.net>
fabrication <watch this space>

[rdklein]

I assume when you are building up a raster by only lines and dots it will be too slow, as the GCodes are  transfered via USB/Serial line (depends on the baud rate of course), a 300 dpi image might takt forever then. The special rsater data commands are much faster to be transmitted.
rdk

[Stefan Hechenberger]

This would work if the raster areas are homogenous. Otherwise you end up
with two gcode lines per pixel which is *a lot* of overhead. We could
probably write a gcode generator that works with the current firmware
but the maximum speed would be very slow.

On the converter side we are actually dealing with two kinds of input:
polygonal shapes in the svg and embedded images
Both can be converted to pixel raster though. For the polygonal shapes
we could also generate the outline which would probably lead to crisper
engravings.

>DPIs
These will obviously have to be converted same as color to grayscale.
Also the stepper setup shouldn't matter but the pixel dimensions and
focal diameter need to be matched. E.g. if you engrave with a thick beam
you will have to match the DPIs accordingly. At the very least the
raster line height needs to match the beam and unless you don't care
about distortion this will also define the horizontal dpi.

--
Stefan Hechenberger
studio: Nortd Labs - labs.nortd.com
resident: F.A.T. Lab - fffff.at
project: Lasersaur - labs.nortd.com/lasersaur

[jet]

On 2012-09-12 13:20, Stefan Hechenberger wrote:
>
> This would work if the raster areas are homogenous. Otherwise you end up
> with two gcode lines per pixel which is *a lot* of overhead.

I wasn't thinking per-pixel as much as per-line, that is making lines
out of rows of pixels that have the same raster value. I need to do
some testing as well to verify this, but I suspect the range of raster
values might be rather narrow. Instead of etching pixels you'd be
converting a lot of shades of a color into a single raster value, then
etching a line of that value. (Which is what you'd do with SVG line and
text anyway...)

> probably write a gcode generator that works with the current firmware
> but the maximum speed would be very slow.

That's an Arduino limit, right? I'm not saying generating a g code for
every pixel is a good idea, but I'm tempted to try it on my mill and
see what happens...

[Stefan Hechenberger]

> That's an Arduino limit, right? I'm not saying generating a g code for
> every pixel is a good idea, but I'm tempted to try it on my mill and
> see what happens...

Right.

Say you have something like the following for each pixel the atmega chip
would have quite some processing to do:

S80
G1X300.21

It first needs to parse the text then load it into the motion planer,
and then execute it.

The transfer limitation is probably not the bottleneck. With v12.08f we
bumped up the serial speed to 57600bps. This means 7200 chars per second
which would roughly translate to 450 pixels per second. At a resolution
of 0.1mm/pixel this means 45mm/sec or 2700mm/min. Effectively you would
probably get 1500mm/min raster speed.

With the optimized protocol we could easily transfer enough data for
20000mm/min.

[jet]

On 2012-09-12 13:46, Stefan Hechenberger wrote:
> S80
> G1X300.21
>
> It first needs to parse the text then load it into the motion planer,
> and then execute it.

Yeah, that's why I'd want to convert a bit map into a list of vectors.

Let's say I have this square of pixels:

********
********
********
********
********
********
********
********

I'd try and convert that into four G commands, something vaugely like:
G1X8
G1Y1
G1X-8
G1Y1
G1X8

[Gabriel Helms]

So if we wanted to do both raster etching and "3D" raster where power changes pixel to pixel, it may be more efficient to have two sets of software so that the regular etching doesn't take longer than it needs, but for 3D, its going to have to take a while to etch. 

If we incorporated the beaglebone, would that be able to do some of the work so that the atmega can work more efficient, or would it still be the bottleneck for the 3D etching?  Or could the front end do the same on the host computer?

Gabe

--
Thanks,
Gabriel Helms

Home: (916) 760-8943
Cell: (805) 427-5126

[Jeshua Lacock]

If the USB bandwidth is a constraint, perhaps the easiest solution is to use a SD card attached to the Arduino with the G-code loaded on it...

Just an idea.


Best,

Jeshua Lacock
Founder/Engineer
3DTOPO Incorporated
<http://3DTOPO.com>
Phone: 208.462.4171

[Steve Baker]

Even with a clunky USB 1.0 interface, you should be able to transmit
1.5Mbits/sec.

If we used a byte for the intensity of each pixel, we'd be able to send
180k pixels/second - if we aimed for 600 dots-per-inch of resolution,
(about what a laser printer will do) - we could raster at 300 inches per
second and still keep up.

I'm pretty sure the lasersaur can't move at anything like those speeds -
so there should be bandwidth to spare, so long as it's used intelligently.

If we expect the rastering to happen at (let's say) 30 inches/second -
then there is enough bandwidth to send around ten bytes per pixel.

-- Steve

-- Steve

[Allen S. Rout]

On 09/12/2012 04:23 PM, jet wrote:

> Let's say I have this square of pixels:
>
> ********
> ********
> ********
> ********
> ********
> ********
> ********
> ********
>
> I'd try and convert that into four G commands,

I scanned briefly over google images to communicate what I think this
would look like

http://pages.infinit.net/leware/moonEngrave.jpg

http://ak.buy.com/PI/0/500/230063500.jpg



- Allen S. Rout

[Craig Dorety]

Hey Stefan,

Let's assume for a second that the etched areas are homogeneous, could there be a vector-based fill? Like if I had a filled vector rectangle with a grey of 75/255. Could the saur just go back and forth to etch it?

btw our 'saur has a minimum power below witch it will not lase. It's around 29 or 30%. Just FYI

--Craig Dorety
415.350.9509
http://craigdorety.com

[Gabriel Helms]

I've done the vector filling before, but too much seems to crash the system. It works for small objects, but too many objects in one burn seems to cause problems. 

As for power, I think it depends on the tube. I've gone as low a 5% with etched on leather. 

Sincerely,

Gabriel Helms

(H): 916-760-8943

(C): 805-427-5126

[Jeff Nordhues]

Hi Craig, 

We create our geometry in illustrator - Vector fills do not translate to svg export (basically illustrator leaves the fill blank). Clipping mask was my next thought - the fill geometry exports to svg minus the clipping effect. Lastly we just trimmed the group of lines to fit our object this worked and allowed us to control density - but is very tedious as in illustrator there is not a "trim" tool as in cad. Next step for us is to test importing our geometry to draftsight or another free cad program to try and use the "trim" tool on a linear array of lines that again we could control the density of.

Here is our result from manually trimming -

http://www.flickr.com/photos/77171978@N02/8095710689/in/set-72157631700923972 

Jeff.

[Ray Debs]

Any progress on rasterizing? I have my Lasersaur up and cutting and would really like to be able to do rasterization.

Thanks,
Ray