Engraving Raster Images

[laser team]

Hello gentlemen,,
     hope that this mail finds you all well .. 

I was wondering if it is possible to use LasaurApp in engraving raster images .. 

Thanks in advance ..

Regards ..
Ragy Samy ..

[Steve Baker]

Not yet - but people are working on it. AFAIK, the hardware is capable of
it - it's really just a matter of software.

-- Steve

laser team wrote:
> *Hello gentlemen,,
> hope that this mail finds you all well .. *
> *
> *
> *I was wondering if it is possible to use LasaurApp in engraving raster
> images .. *
> *
> *
> *Thanks in advance ..*
> *Regards ..
> Ragy Samy ..*
>


-- Steve

[laser team]

it's gonna be great .. looking forward to use it .. 

thnx man .. 

[Jeshua Lacock]

On Dec 3, 2012, at 1:53 PM, Steve Baker wrote:

> Not yet - but people are working on it. AFAIK, the hardware is capable of
> it - it's really just a matter of software.

I am not sure if this might be helpful, but I looked into how it is best done using LinuxCNC.

Instead of G-Code commands for every pixel, it only commands motion from the beginning of the row coordinate to the end of the row coordinate. This ensures a steady velocity across the row (versus stop/go).

Then the only thing changed during that row is the laser intensity. Someone wrote a python script to do this as LinuxCNC as the controller. More info is here:

http://wiki.linuxcnc.org/cgi-bin/wiki.pl?Rastering_With_A_Laser


Best,

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

[Stefan Hechenberger]

Thanks for the link. I didn't know emc2 stops after each line of gcode.
The plan-ahead motion control of the lasersaur firmware feels very
sophisticated now ;)

We have actually a pretty good idea how to implement the raster feature,
just haven't gotten around doing it yet:
https://groups.google.com/d/msg/lasersaur/iMAmfvawSTo/vdN_8iwY4toJ

In addition we also need to add the functionality to the svg importer.
Volunteers, please contact me?

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

[Jeshua Lacock]

On Dec 6, 2012, at 9:18 PM, Stefan Hechenberger wrote:

> Thanks for the link. I didn't know emc2 stops after each line of gcode. The plan-ahead motion control of the lasersaur firmware feels very sophisticated now ;)

Cheers.

Linuxcnc does trajectory planning too, but some people on the list mentioned that having positions for each coordinate could cause jittery motion compared to a single start and end position.

> We have actually a pretty good idea how to implement the raster feature, just haven't gotten around doing it yet:
> https://groups.google.com/d/msg/lasersaur/iMAmfvawSTo/vdN_8iwY4toJ

Nice. I was thinking Lasersaur might benefit from the Graster code for generating the g-code from raster images.

> In addition we also need to add the functionality to the svg importer. Volunteers, please contact me?

Sounds interesting, I wish I had a couple less projects!

[Andy Dingley]

On Monday, December 3, 2012 8:53:41 PM UTC, SteveBaker wrote

> AFAIK, the hardware is capable of
> it - it's really just a matter of software.

I'm not so sure. The effective raster engravers that I've seen take a completely different approach to engraving that they do to vector cutting. There's a linear encoder, the head is scanned back and forth, and the encoder pulses (mapped through the image density) are what then controls the laser firing. On my Epilog 36EXT there are actually two encoders: a linear that's only used for this engraving and a rotary used for vectoring. Most of this is about mechanical inertia – it allows the head to scan back and forth at constant speed, without worrying about acceleration effects in the middle. So long as tube power is adequate, this allows faster engraving.

I can't imagine how any G code based system, or any system based on movement commands and laser switching, is going to work for engraving. You'd be there for years.

[Jeshua Lacock]

Grant it, this is the most impressive laser raster work, but should prove it is at least possible:

http://www.youtube.com/watch?v=2mGvAUUDuH0

[Jeshua Lacock]

On Dec 7, 2012, at 4:15 AM, Jeshua Lacock wrote:

> Grant it, this is the most impressive laser raster work, but should prove it is at least possible:

Oops, I meant it *isn't* the most impressive….

[Martin Bogomolni]

the Universal Laser PLS that we have at ATX Hackerspace has no such quad or linear encoder .. and it rasters just fine.

[Ward Elder]

My Lasersaur running a Testra controller does raster beautifully. Does it fast too.

Ward M. Elder
(204) 791-7754
Eldersoft Ind.
42 Appleton St.
Winnipeg, MB
R2G1K5

[Steve Baker]

I wonder - is it better to modulate the power of the laser or the speed?

In pure abstract theory, you'd get faster rastering by running the laser
at high power all the time and altering the speed of the head because you
wouldn't be wasting a bunch of time moving the laser slowly over the
lighter areas.

I understand that in practice, the inertia of the head limits how fast
you can change speed...which in turn would limit how rapidly you could go
from a white pixel to a black one...so maybe this theoretical idea isn't
practical.

But it's worth a thought. Perhaps a hybrid system where you accelerated
the head to a speed appropriate to the average brightness of the next
centimeter or so of the image and used laser power modulation to
compensate for the error due to inertia?

-- Steve

>> for vectoring. Most of this is about mechanical inertia – it allows

>> the head to scan back and forth at constant speed, without worrying
>> about acceleration effects in the middle. So long as tube power is
>> adequate, this allows faster engraving.
>>
>> I can't imagine how any G code based system, or any system based on
>> movement commands and laser switching, is going to work for engraving.
>> You'd be there for years.
>

-- Steve

[Andy Dingley]

On Friday, December 7, 2012 5:02:11 PM UTC, SteveBaker wrote:

I wonder - is it better to modulate the power of the laser or the speed?

Power. Laser power is optics and electronics, both of which run faster than mechanics.   My laser pulses at up to 5kHz.

[Stefan Hechenberger]

Hey Ray, for raster engraving we need two additions to the
app_svgreader.js. One is for vector fills and the other for embedded
bitmap images. I personally would prioritize vector fills and start with
this (also because Inkscape can vectorize bitmaps).

Converting Vector Fills to Raster Data
--------------------------------------
Let's start by only supporting solid fills, no gradients. Also to get
started let us assume there is no overlapping geometry. The first order
of business is to calculate horizontal scan lines (actually segments).
Once we have the segments converting them to our raster data format will
be trivial.

Calculating scan lines for a rectangle is simple. For more complex
geometry we have to first convert to convex sub-geometries which we can
then intersect with horizontal scan lines. From this we get the segments.

Sounds like a good starting point?
Let me know if you also need a quick intro in how the svg reader deals
with different svg elements.

Feel free to continue this discussion off-list.

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

On 12/06/2012 09:30 PM, Ray Debs wrote:
> I volunteer. I am very interested in getting the raster capability working.
>
> How can I help?
>
> BTW, I found a problem importing the attached .svg files. They import
> without error, but nothingis displayed.
>
> Thank you,
> Ray

>
>
> -----Original Message-----
> From: Stefan Hechenberger <ste...@nortd.com>
> To: lasersaur <lase...@googlegroups.com>
> Sent: Thu, Dec 6, 2012 8:23 pm
> Subject: Re: [lasersaur] Engraving Raster Images
>
>

[Stefan Hechenberger]

right, just looked at them, they only contain embedded bitmap data.

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

On 12/07/2012 09:36 AM, Ray Debs wrote:
> Brain fart...
> Never mind about the SVG files I attached. I hadn't finished them yet.
> Ray
>
> Sent from my iPad
>
> On Dec 6, 2012, at 8:30 PM, Ray Debs <ray...@aol.com

> <mailto:ray...@aol.com>> wrote:
>
>> I volunteer. I am very interested in getting the raster capability
>> working.
>>
>> How can I help?
>>
>> BTW, I found a problem importing the attached .svg files. They import
>> without error, but nothingis displayed.
>>
>> Thank you,
>> Ray
>>
>>
>> -----Original Message-----
>> From: Stefan Hechenberger <ste...@nortd.com <mailto:ste...@nortd.com>>
>> To: lasersaur <lase...@googlegroups.com
>> <mailto:lase...@googlegroups.com>>
>> Sent: Thu, Dec 6, 2012 8:23 pm
>> Subject: Re: [lasersaur] Engraving Raster Images
>>
>>

>> Thanks for the link. I didn't know emc2 stops after each line of gcode.
>> The plan-ahead motion control of the lasersaur firmware feels very
>> sophisticated now ;)
>>
>> We have actually a pretty good idea how to implement the raster feature,
>> just haven't gotten around doing it yet:
>> https://groups.google.com/d/msg/lasersaur/iMAmfvawSTo/vdN_8iwY4toJ
>>
>> In addition we also need to add the functionality to the svg importer.
>> Volunteers, please contact me?
>>
>> --
>> Stefan Hechenberger

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

>>
>> On 12/04/2012 04:32 PM, Jeshua Lacock wrote:
>> >
>> > On Dec 3, 2012, at 1:53 PM, Steve Baker wrote:
>> >
>> >> Not yet - but people are working on it. AFAIK, the hardware is capable of
>> >> it - it's really just a matter of software.
>> >
>> > I am not sure if this might be helpful, but I looked into how it is best done
>> using LinuxCNC.
>> >
>> > Instead of G-Code commands for every pixel, it only commands motion from the
>> beginning of the row coordinate to the end of the row coordinate. This ensures a
>> steady velocity across the row (versus stop/go).
>> >
>> > Then the only thing changed during that row is the laser intensity. Someone
>> wrote a python script to do this as LinuxCNC as the controller. More info is
>> here:
>> >
>> >http://wiki.linuxcnc.org/cgi-bin/wiki.pl?Rastering_With_A_Laser
>> >
>> >
>> > Best,
>> >
>> > Jeshua Lacock
>> > Founder/Engineer
>> > 3DTOPO Incorporated
>> > <http://3DTOPO.com>
>> > Phone: 208.462.4171
>> >
>> >

>> <ChristmasTree3D.svg>
>> <Lighthouse.svg>

[Jaap Vermaas]

On 12/08/2012 06:41 PM, Stefan Hechenberger wrote:
>
> Hey Ray, for raster engraving we need two additions to the
> app_svgreader.js. One is for vector fills and the other for embedded
> bitmap images. I personally would prioritize vector fills and start with
> this (also because Inkscape can vectorize bitmaps).
>
> Converting Vector Fills to Raster Data
> --------------------------------------
> Let's start by only supporting solid fills, no gradients. Also to get
> started let us assume there is no overlapping geometry. The first order
> of business is to calculate horizontal scan lines (actually segments).
> Once we have the segments converting them to our raster data format will
> be trivial.
>
> Calculating scan lines for a rectangle is simple. For more complex
> geometry we have to first convert to convex sub-geometries which we can
> then intersect with horizontal scan lines. From this we get the segments.
>
> Sounds like a good starting point?
> Let me know if you also need a quick intro in how the svg reader deals
> with different svg elements.
>
> Feel free to continue this discussion off-list.
>

Both LaOS and Visicut support raster engraving (at a very basic level,
but it's a start).

Since both are open source, feel free to recycle our code for Lasersaur.

The relevant code:
pstoedit plugin (c++) that converts postscript to raster engraving
https://github.com/LaosLaser/pstoedit
visicut (java) imports SVG, EPS, DXF and outputs to raster engraving
https://amedeo.informatik.rwth-aachen.de/groups/visicut/

The raster implementation in the LaOS firmware consists of:
* a "move" command to the start position of the raster line
* a "data" line containing:
** number of pixels in the line
** number of bits per pixel
** the actual data
* a "line" command to the end position of the raster line

Given this implementation, rastering can be optimized in the client
program, so the firmware doesn't have to do too many calculations.

Jaap Vermaas
LaOS laser project

[Ray Debs]

Thanks!  I'll take a look.

Ray

[dave]

Hey folks!

I'm looking at buying/building a 100W lasersaurs kit for our hackerspace (tcmaker.org) in Minneapolis, but want to know when this feature will be included, as I know a bunch of folks that do laser etching of photos, etc on our small 40W unit.

Is there a code path or development path for this so I can bring it back to my board and tell them if this will be in the next version?  (Also wondering about the Z table setup, but I'll dig in the forums before I ask this one).

Thanks!

-David

[Kevin]

Same question as Dave. It would be a great addition to the platform.

A rough estimation would be good enough. Basicly, is anyone working on this (or planning to)/making any progress.

I would jump in if I had enough programming skills to do this, but for now I could only help out on the front-end side of things.

[Stefan Hechenberger]

We have some ideas on how to go about it. Just created a page to keep
track of them:

http://labs.nortd.com/lasersaur/manual/raster_engraving

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

On 02/20/2013 12:42 PM, Kevin wrote:
> Same question as Dave. It would be a great addition to the platform.
> A rough estimation would be good enough. Basicly, is anyone working on

> this(or planning to)/making any progress.

> I would jump in if I had enough programming skills to do this, but for
> now I could only help out on the front-end side of things.
>
>
> On Friday, January 4, 2013 9:32:34 PM UTC+1, dave wrote:
>
> Hey folks!
>
> I'm looking at buying/building a 100W lasersaurs kit for our

> hackerspace (tcmaker.org <http://tcmaker.org>) in Minneapolis, but

> https://github.com/LaosLaser/pstoedit <https://github.com/LaosLaser/pstoedit>

> visicut (java) imports SVG, EPS, DXF and outputs to raster engraving

> https://amedeo.informatik.rwth-aachen.de/groups/visicut/ <https://amedeo.informatik.rwth-aachen.de/groups/visicut/>

>
> The raster implementation in the LaOS firmware consists of:
> * a "move" command to the start position of the raster line
> * a "data" line containing:
> ** number of pixels in the line
> ** number of bits per pixel
> ** the actual data
> * a "line" command to the end position of the raster line
>
> Given this implementation, rastering can be optimized in the client
> program, so the firmware doesn't have to do too many calculations.
>
> Jaap Vermaas
> LaOS laser project
> >
> >
> > --
> > Stefan Hechenberger

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

> > On 12/06/2012 09:30 PM, Ray Debs wrote:
> >> I volunteer. I am very interested in getting the raster capability
> >> working.
> >>
> >> How can I help?
> >>
> >> BTW, I found a problem importing the attached .svg files. They import
> >> without error, but nothingis displayed.
> >>
> >> Thank you,
> >> Ray
> >>
> >>
> >> -----Original Message-----
> >> From: Stefan Hechenberger <ste...@nortd.com>
> >> To: lasersaur <lase...@googlegroups.com>
> >> Sent: Thu, Dec 6, 2012 8:23 pm
> >> Subject: Re: [lasersaur] Engraving Raster Images
> >>
> >>
> >> Thanks for the link. I didn't know emc2 stops after each line of gcode.
> >> The plan-ahead motion control of the lasersaur firmware feels very
> >> sophisticated now ;)
> >>
> >> We have actually a pretty good idea how to implement the raster feature,
> >> just haven't gotten around doing it yet:

> >>https://groups.google.com/d/msg/lasersaur/iMAmfvawSTo/vdN_8iwY4toJ <https://groups.google.com/d/msg/lasersaur/iMAmfvawSTo/vdN_8iwY4toJ>

> >>
> >> In addition we also need to add the functionality to the svg importer.
> >> Volunteers, please contact me?
> >>
> >> --
> >> Stefan Hechenberger

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

> >> On 12/04/2012 04:32 PM, Jeshua Lacock wrote:
> >>>
> >>> On Dec 3, 2012, at 1:53 PM, Steve Baker wrote:
> >>>
> >>>> Not yet - but people are working on it. AFAIK, the hardware is
> >>>> capable of
> >>>> it - it's really just a matter of software.
> >>>
> >>> I am not sure if this might be helpful, but I looked into how it is
> >>> best done
> >> using LinuxCNC.
> >>>
> >>> Instead of G-Code commands for every pixel, it only commands motion
> >>> from the
> >> beginning of the row coordinate to the end of the row coordinate. This
> >> ensures a
> >> steady velocity across the row (versus stop/go).
> >>>
> >>> Then the only thing changed during that row is the laser intensity.
> >>> Someone
> >> wrote a python script to do this as LinuxCNC as the controller. More
> >> info is
> >> here:
> >>>

> >>>http://wiki.linuxcnc.org/cgi-bin/wiki.pl?Rastering_With_A_Laser <http://wiki.linuxcnc.org/cgi-bin/wiki.pl?Rastering_With_A_Laser>

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

> --
> You received this message because you are subscribed to the Google
> Groups "lasersaur" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to lasersaur+...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

[Steve Baker]

I dislike that the protocol doesn't make it easy to skip over 'white'
pixels at the start of a scanline quickly. For most sorts of
non-photographic raster art, you have spectacular time-savings if you can
do that.

Imagine a picture of Tux the Penguin - about 50% of a square image of him
is the white-space surrounding him. If you start each scan line at the
first non-white pixel and end it at the last - then it'll raster in about
half the time compared to moving the head the full length of every scan
line. Since rastering is abysmally slow on even the fastest machines,
this is a useful optimization.

I guess that could be done in the low level firmware - but you'd still be
sending a heck of a lot of redundant "G8 D 0" data. With the present
definition, I guess I can chop off the white space to the right of the
image by sending a "G8 N" code after the last non-white pixel - but I
don't have a way to chop off the white pixels at the left-hand ends of the
scanline.

Perhaps, rather than sending the data pixel-by-pixel, it would be better
to do "run length encoding"...at least as an option for non-photographic
images.

Also, I think it's a bad idea to send the brightness data in "extended
ASCII". I'd use base64 or something instead. G-code files are usually
plain ASCII and there is a risk of some kind of problem with third party
G-code parsers and doing things like editing G-code data by hand in a text
editor.

-- Steve

-- Steve

[Stefan Hechenberger]

Here is an idea. Simple raster engraving would be possible without any
firmware changes. Specifically mapping single color vector fill from the
SVG file to g-code would be very useful and fairly easy to do, a low
hanging fruit.

The basic approach would be to convert SVG fills to scan lines. The code
is in backend/filereaders/svg_tag_reader.py and svg_attibute_reader.py.
It already looks for all the geometry that can have fills: path, rect,
circle, ellipse, polygon. If these have a fill attribute then
intersecting with horizontal lines over the entire bounding box should
result in the actual engraving lines.

https://github.com/stefanix/LasaurApp/blob/master/backend/filereaders/svg_tag_reader.py

Here is the SVG spec for fills:
http://www.w3.org/TR/SVG11/painting.html

Anybody wants to give it a try. I am kind of busy the next one or two
weeks so won't have time to tackle this right away.

Let me know,

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

[Steve Baker]

It would be possible to do this with an offline tool - take an SVG file
and write something that replaces filled shapes with lots of close-packed
horizontal lines at some specified density and then write it back out as
another SVG. That would work without touching the lasersaur code base at
all and could presumably be integrated into the lasersaur stuff later on
if desired.

SVG fills are kinda painful to get right for things other than circles and
rectangles and such because filled "path" shapes don't have to be
perfectly connected, they can be self-intersecting (like an infinity
symbol), they can have interior "holes" and some shapes can make it
challenging to decide what's inside and what's outside of the shape. It's
tempting to ignore those cases - but they come up all the time with things
like text and paths that a raster-to-vector tool might have made.

I wonder whether any of the OpenSourced code that generates renderings of
SVG files (eg in Firefox or Inkscape) would help with this?

-- Steve

[Gabriel Helms]

I've been doing something like that in Inkscape with an EggBot extension for hatching. It works for small jobs, about 10x10 cm, but any larger runs into problems with processing and I get a bunch of timeout errors. I would prefer a better solution that would also give us an ability to produce pictures where shades of gray determine laser intensity so we can create 3D images. (Such as from http://www.gantryco.com/)

Gabriel 
Sent from my iPhone

[JNordhues]

I have been using draftsight to linear array a line, then trim with my imported shape as the boundary. If my memory serves me right I also tried but was not able to get a custom hatch/fill in draftsight to work correctly once exporting back to svg. That method would be ideal as it is easy to make different hatch densities. Also scale did some funny stuff but I was able to figure it out. Sorry to be so vague, I have not been able to work with my saur the past month.

Jeff

Sent from my iPhone

[Stefan Hechenberger]

If the "fill-rule" is "evenodd" (see SVG specs) than that's fairly
simple to do. Basically you intersect a line with the polygon. First
intersection point is is your g0, second is your g1, third is a g0,
fourth a g1, and so on. When I did a couple of examples on paper this
worked with very complex self-intersecting polygons that have holes.

With the "nonzero" rule it's a bit more difficult because the direction
of the line segment that is being crossed matters.

When I looked at text glyphs the should all pretty much work with the
evenodd rule even if they are defined with the "nonzero" rule in the SVG.

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

[Steve Baker]

That timeout thing when you import into the browser isn't an error - just
tell it to continue and it'll eventually finish. You may have to say
"Continue" more than once. I get this all the time on complex jobs (most
of my cuts take over an hour - the slowest ones take four hours) - you
just have to be patient as it loads.

-- Steve

[Steve Baker]

What kills you is the special cases - such as when one of the sides of the
polygon runs *almost* precisely along your scanline...tiny roundoff errors
can easily mess things up. I've seen that in one of my designs that looks
great in 32 bit Firefox but goes horribly wrong in 64 bit and paints most
of the image black. Moving one of the vertices by a gazillionth of a
millimeter in any direction fixes it!

[taylor1076]

Hi, 

I'm new to the group - I've come from a slightly different route, in that I have converted one of the cheap 40W Chinese lasers into a workable machine. 

(http://www.artaylor.co.uk/laser_conversion.html)

Although it isn't a Lasersaur, I really liked the features offered through the web based setup, so I am using a derivative of the LasaurGrbl Firmware and a vanilla back end. 

I really wanted to keep raster engraving on my machine, so I knocked up an implementation of the GCode example that Stefan put here: http://labs.nortd.com/lasersaur/manual/raster_engraving.

(My code, including an Image --> Gcode Python script, is here: https://github.com/art103/LasaurGrbl)

Review comments welcome ;)

I am currently working out how to get the image data through the webapp and backend code, and need to bypass the paths (I think) and go straight to GCode, or maybe add another intermediate data block e.g.: [x, y, pitch, data].

If anyone has a good knowledge of the backend, and how best to achieve this goal, I would really appreciate some help getting this into a great end-to-end workflow. 

At the moment, I'm loading the raster GCode (generated with my raster.py script), then running a second job to do the cut.

I look forward to feeding something back into the Lasersaur...

[Stefan Hechenberger]

Hi Richard, Thanks for posting this. I just started taking a closer look
at your code and have few question. Since your code/hardware is quite
different I can't simply merge your fork but need to figure out what
parts are reusable.

Can you confirm and augment the following ...

gcode.c
-------
- parse G8 raster commands
- subcommand P sets dot size
- subcommand D added to the raster buffer
- subcommand X/Y/X defines the raster direction and offset
- stored in "vector"
- subcommand N, take the raster buffer, create a block command,
and delegate it to the planner.

planner.c
---------
- create raster line
- move to starting point
- acceleration line segment
- actual raster line (type BLOCK_TYPE_RASTER_LINE)
- decelleration line
- move to beginning (isn't this redundant?)

stepper.c
---------
- questions
- How does "case BLOCK_TYPE_RASTER_LINE:" work?
Can you explain how you use the line motion code and then
modulate the laser intensity.
- Is it that the BLOCK_TYPE_RASTER_LINE modulates the laser
intensity and then runs (switch fallthrough?) the BLOCK_TYPE_LINE
code?

One more question: It seems you are doing binary images. Any technical
reason not to use gray values instead?

Thanks, this is a great contribution,

--
Stefan Hechenberger
studio: Nortd Labs - labs.nortd.com

work: Institut f�r Experimentelle Architektur, UIBK

resident: F.A.T. Lab - fffff.at
project: Lasersaur - labs.nortd.com/lasersaur

On 05/15/2013 02:03 AM, taylor1076 wrote:
> Hi,
> I'm new to the group - I've come from a slightly different route, in
> that I have converted one of the cheap 40W Chinese lasers into a
> workable machine.
> (http://www.artaylor.co.uk/laser_conversion.html)
>
> Although it isn't a Lasersaur, I really liked the features offered
> through the web based setup, so I am using a derivative of the
> LasaurGrbl Firmware and a vanilla back end.
> I really wanted to keep raster engraving on my machine, so I knocked up
> an implementation of the GCode example that Stefan put here:
> http://labs.nortd.com/lasersaur/manual/raster_engraving

> <http://labs.nortd.com/lasersaur/manual/raster_engraving>.

> > studio: Nortd Labs - labs.nortd.com <http://labs.nortd.com>

> > resident: F.A.T. Lab - fffff.at <http://fffff.at>
> > project: Lasersaur - labs.nortd.com/lasersaur
> <http://labs.nortd.com/lasersaur>
> >

> >>> studio: Nortd Labs - labs.nortd.com <http://labs.nortd.com>

> >>> resident: F.A.T. Lab - fffff.at <http://fffff.at>
> >>> project: Lasersaur - labs.nortd.com/lasersaur
> <http://labs.nortd.com/lasersaur>
> >>>

> >>> On 02/22/2013 04:15 PM, Stefan Hechenberger wrote:
> >>>>
> >>>> We have some ideas on how to go about it. Just created a page
> to keep
> >>>> track of them:
> >>>>
> >>>> http://labs.nortd.com/lasersaur/manual/raster_engraving
> <http://labs.nortd.com/lasersaur/manual/raster_engraving>
> >>>>
> >>>> --
> >>>> Stefan Hechenberger

> >>>> studio: Nortd Labs - labs.nortd.com <http://labs.nortd.com>

> >>>> resident: F.A.T. Lab - fffff.at <http://fffff.at>
> >>>> project: Lasersaur - labs.nortd.com/lasersaur
> <http://labs.nortd.com/lasersaur>
> >>>>

> >>>>> <http://labs.nortd.com/lasersaur

> >>>>> <http://labs.nortd.com>
> >>>>> >> resident: F.A.T. Lab -fffff.at <http://fffff.at>
> <http://fffff.at>
> >>>>> >> project: Lasersaur -labs.nortd.com/lasersaur
> <http://labs.nortd.com/lasersaur>

> >>>>> <http://labs.nortd.com/lasersaur

> <https://groups.google.com/groups/opt_out>.

> >>>>>
> >>>>>
> >>>>
> >>>
> >>> --
> >>> You received this message because you are subscribed to the Google
> >>> Groups
> >>> "lasersaur" group.
> >>> To unsubscribe from this group and stop receiving emails from
> it, send
> >>> an
> >>> email to lasersaur+...@googlegroups.com.
> >>> For more options, visit
> https://groups.google.com/groups/opt_out

> <https://groups.google.com/groups/opt_out>.

> >>>
> >>>
> >>>
> >>
> >>
> >> -- Steve
> >>
> >
> > --
> > You received this message because you are subscribed to the
> Google Groups
> > "lasersaur" group.
> > To unsubscribe from this group and stop receiving emails from it,
> send an
> > email to lasersaur+...@googlegroups.com.
> > For more options, visit https://groups.google.com/groups/opt_out

> <https://groups.google.com/groups/opt_out>.

[Richard Taylor]

Hi Stefan,

One of the things I wanted to do was to apply the changes to a clean (your) code base.
Free time hasn't been on my side though!

Ok, I've done a quick merge:
https://github.com/art103/LasaurGrbl/tree/stefanix-master
There will be compilation errors (I don't have a build environment for your firmware), but the majority of the code should be in place.

I had to do a bit or re-factoring as I was getting conflicts with variables in the BSP for my board. It makes things look more drastic than they are :)
There is also a lot around configurable acceleration, using a joystick, temperature control and a crude task manager to run them all.

gcode.c:
The P, D and N are fairly straight forward additions.
The X/Y/Z needed a tweak due to the offset / absolute setting of target[] normally done (not wanted for G8).
I modified this so it didn't update the position when there was a raster, and added a generic "vector[]" to set the direction and offset (could also be used for other commands if required).
Note that currently, only +'ve X is supported - this needs extending to support +/- and X/Y as you've documented (in planner.c).

planner.c:
Your analysis is correct.
This is really hacky. It relies on the returned block in the queue not being executed before I update the raster parameters.
It also populates the raster buffer with a single buffer - if this is done without synchronization, it will get corrupted.
If you look at the git log, I previously used a much cleaner implementation, but it used far too much CPU power, making for variable speed rastering.
The move to beginning is required, because I am synchronising the steppers. It then takes a relatively long time for the next buffer to be processed.
Without the return to beginning at this point, you sit waiting (stationary) for the next buffer to be processed.
Ideally, the next command would be processed in parallel, if there is enough RAM, another 1K buffer would be good.
If this is done properly, the return to beginning would be removed.
I also see this as the place to skip any pre/proceeding zeros to make the raster line variable length, saving time.
(The first implementation did this and it worked well - it also did +/- X/Y).

stepper.c:
Yes, it is the fall through that does it.
This relies on the fact that once you are out of the accelerate loop (this should be immediately), the adjust_speed() function is not called within the BLOCK_TYPE_LINE case.
This means that I am free to override the laser intensity before that case (in BLOCK_TYPE_RASTER_LINE) without it being overridden.
I saw it as the best balance of clarity vs. maintainability. Moving the "line" case into a function would be another alternative, but I didn't want to mess with the ISR too much.

There are two reasons that I didn't use gray scale levels:
 - I don't have PWM hooked up to my PSU yet! (it is a work in progress)
 - The front end does not handle the extended ASCII range well.

I was using my .py script and minicom at one point to send 0-255 for each data bit in the 'D' Gcode line , but in the end dropped back to '0' and '1' for ease of development.
I would very much like to have gray support in there, but saw that was secondary to having working raster support.
Even something like 0-F to give 16-bit gray scale would be better than binary (and simple enough to implement).

Kind regards,
Richard.

work: Institut für Experimentelle Architektur, UIBK

[taylor1076]

Ok, this should be another step towards a working solution. 

I have updated the frontend to parse the <image> tags in .svg and convert them to GCode. 

I have also updated the GCode Reader / Writer to understand the new format. 

Seems to work well in my limited use cases!

Code:

https://github.com/art103/LasaurApp.git

It needs the python-image library (PIL).

Photo (at the bottom):

http://www2.artaylor.co.uk/laser_conversion.html

[Dimitri Titov]

Ward,

With the testra controller, how do you cut material?  Does it cut based on the thickness of the vector? I.e. the Epilogue we have here uses a 0.001 vector thickness for cutting, and anything else for raster.  

How much did the controller cost and how easy was it to set up?  I'd consider upgrading this machine to use this instead of the lasersaur app if it meant adding raster.

Thanks,

Dimitri

[Ward Elder]

Hello Dimitri:

 

My laser has been down for some time now.  Work has taken me away from many of my pleasures.  The Testra controller uses a proprietary software to create and manage jobs.  It does support imports of DXF (Autocad) files with layers.  Each layer can be assigned a power/speed setting.  This is for vector cutting.  For raster cutting you install a Windows “print” driver.  I used CorelDraw to do the raster engraving.  The print driver does all the heavy lifting.  For prices look at the Testra website: http://www.testra.com/   I have the SS-4544 controller.

 

 

Thank you,

 

 

Ward M. Elder

ElderSoft

42 Appleton St.

Winnipeg, MB

R2G1K5

(204) 791-7754   (Cell)

 

wa...@eldersoft.ca

--

You received this message because you are subscribed to the Google Groups "lasersaur" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lasersaur+...@googlegroups.com.

To post to this group, send email to lase...@googlegroups.com.
Visit this group at https://groups.google.com/group/lasersaur.
To view this discussion on the web visit https://groups.google.com/d/msgid/lasersaur/6d1b4f29-72e6-4a19-96f3-c467dd8a0b08%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Steve Baker]

The laser cutter I used at our local hackerspace is like that - but it's a
real pain having to set a particular line width in the CAD tool because on
large designs, the 0.001 line width is almost invisible on the screen.

I much prefer to be able to design with any line width and have the laser
cutter ignore that. If I want to raster something, I put it into an
image file instead.

>> <javascript:>> wrote:
>>
>> >
>> >
>> > On Monday, December 3, 2012 8:53:41 PM UTC, SteveBaker wrote
>> > > AFAIK, the hardware is capable of
>> > > it - it's really just a matter of software.
>> >
>> > I'm not so sure. The effective raster engravers that I've seen take a
>> completely different approach to engraving that they do to vector
>> cutting.
>> There's a linear encoder, the head is scanned back and forth, and the
>> encoder pulses (mapped through the image density) are what then controls
>> the laser firing. On my Epilog 36EXT there are actually two encoders: a
>> linear that's only used for this engraving and a rotary used for
>> vectoring.

>> Most of this is about mechanical inertia – it allows the head to scan

>> back
>> and forth at constant speed, without worrying about acceleration effects
>> in
>> the middle. So long as tube power is adequate, this allows faster
>> engraving.
>> >
>> > I can't imagine how any G code based system, or any system based on
>> movement commands and laser switching, is going to work for engraving.
>> You'd be there for years.
>>
>

> --
> You received this message because you are subscribed to the Google Groups
> "lasersaur" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to lasersaur+...@googlegroups.com.
> To post to this group, send email to lase...@googlegroups.com.
> Visit this group at https://groups.google.com/group/lasersaur.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/lasersaur/6d1b4f29-72e6-4a19-96f3-c467dd8a0b08%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- Steve

[Peter van der Walt (Gmail)]

Checkout my raster work on openhardwarecoza.github.io/LaserWeb2  as well.   And do follow the Google Plus community,  busy adding layered CAM today to the new branch

To view this discussion on the web visit https://groups.google.com/d/msgid/lasersaur/466124a90a2bb208c9ed8c9c497469c2.squirrel%40webmail.sjbaker.org.

[Torsten Martinsen]

On 06/16/2016 09:46 AM, Dimitri Titov wrote:
> Ward,
>
> With the testra controller, how do you cut material? Does it cut
> based on the thickness of the vector? I.e. the Epilogue we have here
> uses a 0.001 vector thickness for cutting, and anything else for raster.
>
> How much did the controller cost and how easy was it to set up? I'd
> consider upgrading this machine to use this instead of the lasersaur
> app if it meant adding raster.

An alternative open-source route is

1) Upgrade your machine to a Smoothieboard
2) Use the Smoothieware firmware together with LaserWeb.

I have not used LaserWeb myself yet, but the project seems to have a lot
more progress than LasaurApp.

-Torsten

[Peter van der Walt (Gmail)]

Thanks for the Shoutout! 

Just throwing it out there,  but i am willing to collaborate on a Smoothieware based Lasersaur controller PCB (i'll design it if Stefan wants to sell it,  free of charge for the sake of the community) 

We can still talk serial from the bbb,  still the same IO,  i have a few different smoothieware based boards coming to the US market in the next few weeks.   One is a drop in upgrade for those chinese K40 machines.   Its commodity level these days (32bit  smoothieware beats the shit out of anything else we had so far) 

Smoothieware is awesome,  and what inspired me to start working on LaserWeb in the first place (it's my project if you didnt know).

LaserWeb1 actually had Lasaurgrbl support.  In LaserWeb2 i tried using serialPortJsonserver as backend bridge,  but i wasnt happy.  Since about 10 days ago,  serious work has started on LaserWeb v3 (github.com/openhardwarecoza/LaserWeb3)  -  only Smoothieware supported so far. 

I am rewriting the cam (we are already a factor of x65 faster than laserweb1  was)   and doing a top down comms revamp in v3 -  far from done,  but please do keep an eye on it.   Very active google+ community  over on https://plus.google.com/communities/115879488566665599508 and also where i am posting dev updates for normal people (aka people who dont read git commit logs for fun) 

Peter

--
You received this message because you are subscribed to the Google Groups "lasersaur" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lasersaur+...@googlegroups.com.
To post to this group, send email to lase...@googlegroups.com.
Visit this group at https://groups.google.com/group/lasersaur.

To view this discussion on the web visit https://groups.google.com/d/msgid/lasersaur/5762D199.6070407%40bullestock.net.

[Torsten Martinsen]

On 06/16/2016 07:22 PM, Peter van der Walt (Gmail) wrote:
>
> Thanks for the Shoutout!
>
> Just throwing it out there, but i am willing to collaborate on a
> Smoothieware based Lasersaur controller PCB (i'll design it if Stefan
> wants to sell it, free of charge for the sake of the community)
>

Already in progress:
https://github.com/bullestock/lasersaur/tree/master/pcb/lpcsaur

-Torsten

[Peter van der Walt (Gmail)]

Excellent

--
You received this message because you are subscribed to the Google Groups "lasersaur" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lasersaur+...@googlegroups.com.
To post to this group, send email to lase...@googlegroups.com.
Visit this group at https://groups.google.com/group/lasersaur.

To view this discussion on the web visit https://groups.google.com/d/msgid/lasersaur/5763183C.1040604%40bullestock.net.

[Dimitri Titov]

Thanks a lot, i'll have a look!

--
You received this message because you are subscribed to the Google Groups "lasersaur" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lasersaur+...@googlegroups.com.
To post to this group, send email to lase...@googlegroups.com.
Visit this group at https://groups.google.com/group/lasersaur.

To view this discussion on the web visit https://groups.google.com/d/msgid/lasersaur/5762D199.6070407%40bullestock.net.

[Dimitri Titov]

Yeah but if you use a monitor that's at least 1080p and at least in illustrator or any vector program I typically see the line fine - I do understand the difficulty to see such a small line but I haven't had issues.  In fact I would argue that this way is superior - at least the ease of use - all I can compare is the epilogue as it is my only laser other than the lasersaur that I've cut things on.

It seems to me deciding what gets cut and what doesn't in Illustrator via line weight (.001 cut and anything else raster) is a very good idea.  Its incredibly easy, and intuitive - you can set all parameters as long as you know how to use your vector program - which are all relatively easy to use.  You can also have them separated by layers (cut and raster) - helps you with organized files.

If I knew how to program I'd help with making this software :)

To view this discussion on the web visit https://groups.google.com/d/msgid/lasersaur/466124a90a2bb208c9ed8c9c497469c2.squirrel%40webmail.sjbaker.org.

[Steve Baker]

I do my design work on a pair of 1600x1200 monitors - so my effective
resolution is 3200x1200. Higher screen resolution is really needed to get
my large/complex designs to where I can see enough of them at one
time...but as you increase the resolution, the visibility of a sub-pixel
line gets worse...so, ironically, the higher the screen resolution, the
worse it gets.

Look - we use color to distinguish cut and etch - so if you want to raster
objects made of vectors - why not set it up to use color to select raster
mode too...use grey-scales for "raster", blue for "vector-etch" and red
for "cut".

I've worked on systems that work both ways, and the systems that used line
width for choosing whether to raster or not drove me crazy! You make the
slightest error in line width in your design - or you convert your design
between different CAD programs or change units and the roundoff error
converts a handful of your lines from vector to raster and you have one
heck of a nasty product that can take you ages do "debug" as you try to
figure out where your 100,000 vector design has a couple of bad vectors in
it.

Using color to do it eliminates those problems pretty much instantly.

Another joy of using color (with a lasersaur-like interface) is that you
can choose between raster and vector approaches at production time with
the existing color mapping system.

When I was using the ULS laser cutter (with CorelDraw drivers) - it would
continually drive me crazy and waste hours of laser cutter time. In the
end, I wrote a piece of software that took my color-based designs and
mapped them into line widths as I exported them to Corel for the ULS
system...life got much better after that!

I'd never want to work on a line-width based approach again - it's beyond
stupid.

-- Steve

>> >> Most of this is about mechanical inertia – it allows the head

> https://groups.google.com/d/msgid/lasersaur/CADHAvTrb8SstZxaeD3nAEWc8ws9z6YgmPnA6o-%2BoFGc7VtXD7A%40mail.gmail.com.

[j. eric townsend]

On 6/16/16 09:36, Steve Baker wrote:
> The laser cutter I used at our local hackerspace is like that - but it's a
> real pain having to set a particular line width in the CAD tool because on
> large designs, the 0.001 line width is almost invisible on the screen.

That's been my experience with several commercial cutters, you have to
use the narrowest width possible.

--
J. Eric Townsend, IDSA
design <http://www.allartburns.org>
hacking <http://www.flatline.net>
consulting <http://www.functionalprototype.com>

[Dimitri Titov]

To be honest, I think the solution could be using a 0.1 or even 0.25" as the cutting line then everything larger is raster..  There has to be a sweet spot.

That way you can still see it and the raster is really thin...  OR you could set the parameters separate.  One file is for cutting and another for raster.  So you end up importing two files.

Not sure,  maybe Steve's suggestion is better,  I don't know.

--
You received this message because you are subscribed to the Google Groups "lasersaur" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lasersaur+...@googlegroups.com.
To post to this group, send email to lase...@googlegroups.com.
Visit this group at https://groups.google.com/group/lasersaur.

To view this discussion on the web visit https://groups.google.com/d/msgid/lasersaur/811c8eff-c3f9-330b-f38c-a9262724f326%40allartburns.org.

[Dimitri Titov]

Peter, thanks for all that info,  I'll look into it. I plan on building my own laser cutter at some point for my shop but for now it'll have to be for someone who has money lol.

To view this discussion on the web visit https://groups.google.com/d/msgid/lasersaur/CAJjaewFmM1a5PKN7%3DZzOsCJLDnW_O7EPZ76-f5KN%3D0LuvUanzw%40mail.gmail.com.