8bit engraving with a CO2 laser

I am in the need to do some engravings on marble but the customer is insisting that a rasterized bitmap would not look good enough.
After quite some test runs and using different programs I am slowly getting to the point where I have to say proper greyscale engraving with a powerful CO2 laser is only possible by using expensive software.
That is also a point that is slowing me down for some time now as for example Picengrave won't offer me any button to generate a g-code for testing purposes.
Same for an older version of Piclaser light, accepts the images, shows the demo watermark but there is no way to test it on the machine.

With all the other plugins, server applets and programs I am running into snags because they either have no way to produce usable G-code or the power is only set through the pixel values.
For a CO2 machine (at least in my setup running Marlin) on power level 6 you see a little bit of burning, at level 11 you already go through the first layer of a plywood sheet.
That leaves 5 power settings for 256 different levels of grey - not working unless the power is compensated by movement speed.

Is there anything capable of producing proper g-code for 8bit engraving on a CO2 machine or just for low power laser diodes?
Might be just running in circles and missed the most obvious solution, so I had to ask

Looks like you have to write a post processing script, that changes speed according to the greyscale.
Then you can rescale the power level too.

I tried engraving "out off focus" to reduce the dotty outcome of a raster engraving. Sort of overlapping dots. That would also require more power/dot, so you can spread the power scale too.

-Olaf

Edited 1 time(s). Last edit at 02/08/2016 12:31AM by o_lampe.

That is something I tried with Photovcarve but had no luck.
Similar story, due my bad coding skills, to make some simple changes in this regards to the Turnkey laser plugin for Inkscape.
I found some python scripts that claim to assign the power level to the brightness of a pixel but that would need to be matched for the few percent of playroom on a CO2 machine - plus the addition to "fill" the missing power levels with speed changes.
For GRBL there are some interesting projects to do proper 8bit engravings although what I found was mostly for low power diode lasers.

In theory it sounds too easy:
Add another setting in the Inkscape plugin for 8bit engraving,
read the pixel values and set speed and power levels according to some table that can be modified from within the plugin settings,
generate the gcode as for normal pulsed operation but adjust the speed and power to the calculations from before.

Guess I am finally too old to get my head around proper python programming LOL
Bur with all the chinese CO2 mods out there for several years now I was hoping someone already did that but forgot to let Google know about it

Edited 1 time(s). Last edit at 02/08/2016 01:48AM by Downunder35m.

... I'm developing a "pixel-engraver" for stereotypes, but this is under NDA's, so no disclosures

For common mode 'rasterizing' you can look how inkjet- or laser-printers works

---

Viktor
--------
Aufruf zum Projekt "Müll-freie Meere" - [reprap.org] -- Deutsche Facebook-Gruppe - [www.facebook.com]

Call for the project "garbage-free seas" - [reprap.org]

Quote

In theory it sounds too easy:

It's never easy...
Even if you got it right in theory, there is stepper acceleration too.
-Olaf

... For testing with 'high-speed-rastering' I've refurbished the mechanics from an old NEC-CP24 needle-printer, as it has a nice NEMA-23 stepper for moving the head and pretty high resolution for the drum.

Her is a video from testing without the laser running - [vimeo.com]

This is the max speed it can run without lossing steps ... but with my paste-bot I can run as fast as 400mm/s (some CO2-laser-engravers move the head with 750mm/s), so will repeat this with an attached laser too.

The pixel data is as raw hex-file on a SD-card and with every motor-step of the head-stepper the next byte of the pixel will be read and interpeted to set the power for a pulse.

So the acceleration is no problem and the amount of pixels in the image neither ...

Edited 1 time(s). Last edit at 02/09/2016 04:24AM by VDX.

---

Viktor
--------
Aufruf zum Projekt "Müll-freie Meere" - [reprap.org] -- Deutsche Facebook-Gruppe - [www.facebook.com]

Call for the project "garbage-free seas" - [reprap.org]

Like the good old professor Fransworth would say: "Good news everybody!"
I was able to dissect the Marlin code responsible for the PWM control of the laser.
So far my tests with some LED's seem to indicate that not only it works now but also that my previous info found on the web was wrong.
In the original Turnkey Tyranny release the laser power is not changable between 0 and 255 but only between 0 and 100 - reflecting 0-100%.
Which also explains why the damn thing always burnt so much on "low" power levels LOL

Anyway, I will now implement the changes into the machine and do some tests.
Going from less than 7bit PWM resolution to now almost 10bit should give enough available signal for proper engraving.
Well, if not I can always go for the full 12bit, 16 I will avoid due to timing issues.

Here are some images of the first engravings done with the modded firmware:

The white spots in the images ( below cheek ) seem to be related to "register overflow"
I assume they should be deep black in original?

You are correct, they should have been black, but this is the first image where it happens in such a noticable way.
Does not happen with all settings but in several cases it does.
Well, it is a work in progress but I am quite happy with the outcome so far.

... looks good

How fast can you engrave?

---

Viktor
--------
Aufruf zum Projekt "Müll-freie Meere" - [reprap.org] -- Deutsche Facebook-Gruppe - [www.facebook.com]

Call for the project "garbage-free seas" - [reprap.org]

LOL I knew this question would come...
The image above is 60x73mm and takes about 40 min no matter how high I crank the speed.
It is limited by the way the buffering works for single commands.
Have to convince Bryan or Leo to make an option to combine all movements without laser power changes into a single line instead of single dots from the image.
After that it would be no problem to manually hang the power commands onto the movement commands to shrink the code even further.
But so far I am quite impressed by Image2Gcode, was exactly what I was looking for although I had to mod my firmware to get it working.
Anyone who said 8bit engraving can't be done on a CO2 machine is proven wrong LOL
Guess I could even do 16bit engravings but see no real benefit in it as noone looks at those things with a magnifying glass.
And since the final resolution equals to the smallest focal point you can keep you would need quite big engravings to see difference between 8 and 16 bit.
One day I have to get a WiFi SD and try this standalone thing, but unlike many I have no problems at all with my USB connections even with the webcam active, several attached USB devices and the CPU flatout converting videos from my phone.
Will edit here soon to upload an image of the last glass engraving for today.
As with 3D printing it is just a matter of dialing into the right settings for a job




Edited 1 time(s). Last edit at 02/27/2016 09:46PM by Downunder35m.

Quote

It is limited by the way the buffering works for single commands.

That's exactly where I'm stuck ATM.
Would it help to go 32bit or is it SD-card related?

... I've changed to ArduinoDue for the needed speed to read a single Byte from SD and set the power per pixel with analogWrite(value).

So I've got rougly 100kHz max 'pixel-speed' with reading the Bytes of a raw (HEX-coded) pixel image.

Depending on the pixel size (in my setup 30 or 6.35 microns) this can be as fast as 3m/s (30µ) or 635mm/s (6,35µ) line speed ... too fast for the cartesian bot, but a good speed for a XY-galvo-scanner ...

---

Viktor
--------
Aufruf zum Projekt "Müll-freie Meere" - [reprap.org] -- Deutsche Facebook-Gruppe - [www.facebook.com]

Call for the project "garbage-free seas" - [reprap.org]

Quote
o_lampe
That's exactly where I'm stuck ATM.
Would it help to go 32bit or is it SD-card related?

What you mean by stuck?
I noticed in Image2Gcode that depending on the resolution setting the code sometimes changes massively without any onbvious reason - could be just a bug.
For example generating code for a big and complex image of 22x17cm causes memory issues in Pronterface when 0.10mm resolution is set.
Not only is the file huge but there is an endless amount of G1 moves between power changes.
To overcome the memory issue I had to go up to 0.2mm resolution and there I noticed that only a few commands are between the power commands.
This could not explained by the decreased resolution alone, so I tested with smaller images further.
In some cases, mostly around 0.12-0.14mm the code messes up completely with about 30 y-axis moves under laser power for no reason, after that the code is almost usable.
If I got to 0.15mm which is giving me the best look on plywood the code often shrinks with only 2 or 3 G1's between the power commands.
So instead of all single pixels suddenly lines are created - which speeds things up massively and if not careful you need to engrave again as the sudden speed jump is no longer good enough for the kind of engraving you wanted.

I also noticed that for engravings the jerk and acceleration can be set much, much higher than for normal cutting or raster jobs.
When I get some time I will do a test by combining all G1 commands into a single command that also includes the power and speed settings.
I am assuming that this should solve the speed issues to a great degree but not sure if or how the guys can implement this.
Might work a Notepadd++ script for this in the meantime so I can try it on bigger engravings.

I'm stuck, because I'm Frankensteining a 700x700mm Laser engraver and I had doubts about the print speed. ( Whether it is CPU or SD related )

Right now, I have to reduce LD current so much to get good gray scaling, I think only a faster CPU would help. Compressing the code, like you mentioned is another step in the right direction.

But I wouldn't do it with a postprocessing script, but try to implement it in the original code. That could help against memory issues as well.

Do you only have issues with engravings or is the speed bad during cuts or raster works as well?
With my tiny motors the limit is at around 400mm/s if I pus it, but usually I stay well below this to get better overall results.
Just don't see the point of maxing and stressing the hardware for the sake of saving a few minutes.
A faster CPU will help of course but I don't see the CPU as the culprit here as GRBL does fine and faster with just an tiny UNO powering it all.
With the current way of engraving through Image2Gcode there are several factors:
a) too many commands that are not needed.
b) the S commands are not included into the movements (due to being designed for a different system).
c) the buffer is constantly being flooded because of a and b.
d) the host software is in no way optimised to deal with this type of code and high speeds.

A dedicated G-code sender will certainly help a lot but I have not found one working properly with my setup.
Compiling Pronterface with just the pure basics and the better memory management for the Gcode should help but I have not the time and mood in the moment to install all the crap needed for compiling it directly for 64Bit.

When cutting, I have to print slow, but with "full power".
When engraving I can't print faster and have to reduce LD current to match the CPU speed.
That's the annoying part, dialing in the current every time.

I haven't tried GRBL yet, I was happy to have the LD mounted on my Prusa and run it with Marlin.
The big LD plotter will be Laser_only, so I'll give GRBL a try before ordering a 32bit controller.

When I said" integrate the compressing code in the main program" I meant the extension of inkscape.

... for my PasteBot-development I've modified Pronterface for the 'special needs' while editing (teaching) and importing different formats - it's meant for driving an inkjet-dispenser, but the output is the same as for my laser-engraver.

Here is a snapshot of the program with a file, I've previously exported for the lasercutter in HPGL format -- it would be happy too to laser the red lines, instead of printing droplets of glue



Edited 1 time(s). Last edit at 03/02/2016 03:15AM by VDX.

---

Viktor
--------
Aufruf zum Projekt "Müll-freie Meere" - [reprap.org] -- Deutsche Facebook-Gruppe - [www.facebook.com]

Call for the project "garbage-free seas" - [reprap.org]

I have now everything covered I need.
Raster engravings, vactor cuts and 8bit engravings, if I have to fine enough to do it on a sheet of paper.
All with freeware and less than 50 bucks in replacement hardware.
Now I wait until the tube gives up LOL

I like your modded Pronterface!
Some changes in Image2Gcode and compiling it in Visual Studio I managed but getting a working enviroment to compile (or run from the source) Pronterface is above me.
Would like to get rid of some of the stuff noone needs on a laser and customize the skin a bit to simplify everything.
After all I basically need it only as a gcode sender.
But now working fulltime again means my fun time is limited to the weekends, making averything going slow LOL

... Pronterface reads G-code files -- so my importers for HPGL or Gerber (and later DXF) are small stand-alone EXE's (programmed by my wife in C#), started from Pronterface with exchanging some basic data (XYZ-coordinates for offset, file-names, ...).

And to generate the raw pixel-image data for laser-engraving stereotypes I've written a script for Gimp, which converts a RGB-image into Grey, then reads the pixel lines and exports them as Byte data into a file. Then it's as simple as reading the head to get the line length (image width), and then -- read a byte, set laser power, fire a pulse, read next Byte, ... and so on ...

---

Viktor
--------
Aufruf zum Projekt "Müll-freie Meere" - [reprap.org] -- Deutsche Facebook-Gruppe - [www.facebook.com]

Call for the project "garbage-free seas" - [reprap.org]

@ o_lampe :
I had to do some work to get my display AND SD card working properly.
I am now able to engrave at 2400mm/m with no issues so far.
What hardware/firmware are you using?
I increased acceleration and jerk quite massively and now all works fine, maybe you need to check them as well as the motor currents?

I have the TurnkeyTyranny's code in the latest Marlin running on both Mega and Due.
Mega runs G7 at about 2500 mm/min same as you get with default (from Inkscape) 270 dpi.
Due does it with 30000 mm/min (0.5 m/second), it is really fast.
I am slowly switching over to Due, the 3.3V can be a problem, turns out to be a problem
with the Co2 power supply in fact.
Due's pwm-capable pins are 2-13, but don't use 6-9 because of incompatibilities with analogWrite(),
the other should be safe to use to use, I use pin 5.
And if you use M42 Px to e.g. switch on the relay to feed air to the laser nozzle, you will be
surprised to learn that M42 is executed asynchronously. Use m400 just in front of such a M42
to have the M42 execute where it is supposed to.

Thanks falwty99 for sharing your Due experience.
Now it's clear to me it is not the SD-card which is the bottleneck.

Which adapterboard are you using with the Due?

... for my paste-dispensers I'm using the RADDS shield with only 3.3V anaogue output -- but my company developed a "comercial" shield and driver boards for the Due with adjustable (0-5V, 0-10V) analog outputs and singal In-/Outputs with 24V.

---

Viktor
--------
Aufruf zum Projekt "Müll-freie Meere" - [reprap.org] -- Deutsche Facebook-Gruppe - [www.facebook.com]

Call for the project "garbage-free seas" - [reprap.org]

For the laserdiod engraver I use classic Mega and RAMPS 1.4, for the Co2 laser I use Due and RAMPS_FD.
The laserdiod is driven by a real PWM signal, but my Co2 power supply needs a pwm signal where
both the duty cycle and amplitude are important. The PWM high level need to be at around 5V for full power.
There are other laser power supplies which I think use a pure pwm signal where it probably would
work with 3.3V level.
My 3D printer use Due with RADDS board and I kind of like that one, small, compact and works well.

For the Mega I think it is possible to get around 3000 mm/min if the LCD is removed. But that is right
up there at the max steps/sec the Mega/Marlin can do. You can always try to reduce the
microstepping from 1/32 to 1/16 or whatever it happens to be, at the expense of a bit lost precision.

VDX, may I ask which company you refer to? I probably make a fool of myself now, I see you have
over 8000 posts and I should know... I am new to this group, that is my excuse

Considering that it is impossible to get the V2 of the Ramps-FS and that I don't like the endless fixing work on the V1.4....
Despite the additional coding from scratch for the laser stuff I would prefer a BBP board (and for my next printer a BBP 1S).
Touchscreen, WiFi, ultra fast, just not for laser yet.
And after quite some searching I could not find any local supplier for the Radds board, not even on Ebay
Considering what I do with the machine I think I will save the money for now and stick to the Mage/Ramps combo for now.
But having a printer with 3 extruders running at over 400mm/s would be a nice thing with the BBP

Quote
falwty99
VDX, may I ask which company you refer to?

... I'm working at/for gie-tec - [gie-tec.de]

But the links/infos related to the paste-dispenser aren't online yet ... should be there until end April ...

---

Viktor
--------
Aufruf zum Projekt "Müll-freie Meere" - [reprap.org] -- Deutsche Facebook-Gruppe - [www.facebook.com]

Call for the project "garbage-free seas" - [reprap.org]

It seems this time I am finally on the right track
After cleaning up a few FLOAT operations in favour of INT things moved a bit faster.
But the two real culprits in the Turnkey Firmware are the base64 library and the way the raster power is recalculated.
The library needed some mods to be able to handle interger values instead of the 8bit CHAR values.
The power calculations as performed in the original firmware work perfect on paper on a standard calculator, but not within an Arduino!
Despite best attempts to find another source of the raster problem the remapping only worked after changing the entire routine in favour of the MAP function.
With the map function I was able to get almost all levels correctly converted just pure black still plays up in some case, for now I "fixed" that by limiting the input values slightly.
So instead of 255 shades of grey I only get 253 - still enough for now.

I left the PWM on the standard 8kHz, did not change any buffers or default settings.
The only problem is a slight buffer hick up, mostly when changing from right to left.
This causes some slight pinhole burns along the right side of an image.
Right now I am only testing on paper as it gives the best contrast, so on wood the effect might not be as bad.
Engraving speeds of up to 4200mm/min were tested so far, above this the thing is starting to stutter.

I always try to place my engraving pictures in a white frame. This way I don't see any marks or burnt holes at the left/right turning points.