Laser mis-fires ...

Added by drogon almost 10 years ago

Just when I thought it was going really well...

I've noticed for some time what looks like the occasional "scratch" on the stuff I'm engraving/cutting - put it down to using a bucket load of off-cuts until now when I'm making up a celebration plaque for a friend. I've done 2 now on brand new acrylic sheet which I inspected before hand and both have come out with what I think is a mis-fire of the laser and want to know if anyone else has seen this.

Right now, I don't know if it's a software glitch, some sort of noise on the wires or something wrong with the internals of the laser cutter itself.

See this image:

I've circled in red the laser glitches. (and there's another on-top on the 'n' - the rest is just dust under it!) They're not in the original inkscape file - and on the first cut of that, they were in a different place (different shape too)

So what now? Any clues?



Replies (23)

RE: Laser mis-fires ... - Added by depronman almost 10 years ago

Are you only getting these 'glitches' when engraving ?

I've done a lot of cutting and marking and have never seen this happening, but I have never tried engraving


RE: Laser mis-fires ... - Added by t-oster almost 10 years ago


I think those are related to engraving. I also had some of them: Are you using the latest firmware?

Maybe related to:

RE: Laser mis-fires ... - Added by drogon almost 10 years ago

Hm. I'll have a look at that issue - and re-do the Inkscape file tomorrow.

However I've just run another cut using the same SD card image - and got the glitches in exactly the same place. However the place is different in the very first version of that plaque I made - I've only shown a small part of it - but I'd made a mistake in some of the text above that photo - and the glitches were elsewhere.

As for the firmware - not using the new one released a few days ago, but the version I am using is dated 14th May 2014.


RE: Laser mis-fires ... - Added by depronman almost 10 years ago

see also the following link found in the forum - software

appears to be exactly the same issue to mu eyes


RE: Laser mis-fires ... - Added by drogon almost 10 years ago

Last try before bed... Went back into Inkscape, trying to follow the issue 58.. nothing was grouped, but I selected all & ungroup anyway, then convert to path, but I don't know how to "split paths". I'm very new to Inkscape. There is "Cut Path", and "Break Apart" options, but I can't find a "Split Path" option or anything close.

Anyway, sent it to visicut then to the laser - different glitches this time - vertical bars either end of our names...

Definitely looks like this random laser-on issue Paul's pointed to ...


RE: Laser mis-fires ... - Added by peteruithoven almost 10 years ago

I think we want to switch to github for issues, so I started a issue there and tried to assemble the relevant links.
Again help with the previewer would be appreciated.

RE: Laser mis-fires ... - Added by drogon almost 10 years ago

This github?

Would really like to get to the bottom of these glitches I'm seeing as right now it's a complete show-stopper for any sort of engraving I want to do )-:

To the point where if I can get this plaque done by Thursday when I need it, the original controller board is going to have to go back in )-:

Has anyone tried exporting from Inkscape as a different format - ie. not SVG? Would it make a difference?


RE: Laser mis-fires ... - Added by t-oster almost 10 years ago

He is talking about the issue tracker of the LAOS project in Github:

Are you sure, you are using the latest firmware version? I did not observe those glitches for a long time now, so I assumed they were fixed.

Anyway, if you need to engrave something urgently: The glitches seem to be always at the end of engraved stuff, so adding a thin frame in your engraving, which is outside your workpiece should save you, eventhough it makes the job duration much longer of cause.

If you are using VisiCut, the input file format can not matter, because visicut rasters the images internally and only gives the result to the underlying LAOS driver.

RE: Laser mis-fires ... - Added by drogon almost 10 years ago

The firmware I have is the laoslaser-14-05-2014.bin version. That's what the link on the wiki points to.

I do notice there is a slightly newer version: 22-05-2014, so I have loaded that into the cutter and am now running the cutter with the same file on the SD card and it's exactly the same - same glitches as the last run in the same place...

Masking isn't going to be possible here, but the glitches seem to move every time I change the file in Inkscape and re-run it through VisiCut, so maybe I can find a combination that puts them in a less obtrusive place. Not a long-term solution though.

I might look at the visicut viewer though - I think it would be good to isolate the issue - VisiCut or the firmware - I think it's hard to tell right now.


RE: Laser mis-fires ... Sorted - FSVO Sorted ... - Added by drogon almost 10 years ago

On a whim, I decided to take my original in Inkscape and take the bottom 3 lines - the ones in the photo above which is about 1/4 of the whole plaque and moved them to another layer (I use the layers method of specifying cut/engrave, etc. type in VisiCut). I intended to only laser cut the outline and engrave the top 3/4, then send the bottom 1/4 as a separate file, but decided to do the lot. So I selected one layer to be cut, and 2 layers to be engraved - sent it to the LAOS board and bingo. The output - on cardboard at least is perfect.

That still doesn't tell me if the issue here is with Inkscape, VisiCut or the LAOS firmware, but at least I have a workaround for now, and maybe this might help someone else with a similar issue.



RE: Laser mis-fires ... - Added by peteruithoven almost 10 years ago

Did anyone experiment with the Additional space per raster line option in Visicut? This allows you to tweak the distance the laserhead sweeps outwards beyond the width of the raster line.

RE: Laser mis-fires ... - Added by HackerspaceFFM over 9 years ago


we at Hackerspace-FFM successfully converted our China-Laser K40-III to Laos. When voting for doing the conversion with LAOS, the raster-engraving possibilities where one of the big pro-arguments for LAOS against others like Lasersaur. Unfortunately we are also facing this miss-fire issue. But hey, Laos is a great open-source project an so during last late-night journey we digged deep into the nuts'n'guts of the system and tracked this issue down to a point where it should be now easy to fix. But let's start at the beginning:

While looking closely to the issue it seems that it occurs only at the surrounding of the image to engrave. So my first attempt was to find the most easy reproducable picture to engrave and my very first idea was a direct hit: A filled triangle. So we draw a small filled triangle in Inkscape and sent it for engraving using Visicut. The first triangle drawn was without issues (right one), but from then all others (repeated print using LCD menu) showed the issue clearly:

!Laser Engrave Error.jpg!

The laser started at the top of the triangle and showed directly the miss-firing error. We ripped the LGC-file from the card and analysed it - here are the first lines of the file that alredy results in miss-fires:

201 0
202 120819
203 252078
204 300000
7 100 10000
7 101 800
0 122089 175964
9 1 160  0 0 134217728 0 0
1 108542 175964
0 108542 175879
9 1 160  0 0 48 0 0
1 122089 175879
0 122089 175794
9 1 160  0 0 201326592 0 0
1 108542 175794
0 108542 175710
9 1 160  0 0 120 0 0
1 122089 175710
0 122089 175625
9 1 160  0 0 1040187392 0 0
1 108542 175625
0 108542 175540
9 1 160  0 0 252 0 0
1 122089 175540
0 122089 175456
9 1 160  0 0 1056964608 0 0
1 108542 175456
0 108542 175371
9 1 160  0 0 510 0 0
1 122089 175371
0 122089 175286
9 1 160  0 0 2139095040 0 0
1 108542 175286

By looking at those line-bitmap-data you can clearly see that everything looks pretty correct so far. Visicut generates the bitmap data with a lead-in and lead-out area of at least 64 bits which are those double zeros in every line starting with a 9 (for bitmap transfer). Now it is clear that the issue is not on the Visicut side and also the transfer of the file is not the issue!

We digged through the firmware source code on Git-Hub and looked for parsing errors of the file. After understanding most of the parsing code for the bitmap data in LaosMotion::write(..) we came to the conclusion that everything is fine so far here, appart from one thing: There is no code that clears (=zeros) out the old bitmap data before new bitmap data is beeing received! This alone would not be an issue but we digged deeper were the bitmap data is going to be put on the laser, which is somewhere in stepper.cpp line 340 an ongoing. Here we didn't understand how that counter_l and pos_l is working but we stumbled on the following line:

*laser =  ! (bitmap[pos_l / 32] & (1 << (pos_l % 32)));

By using pos_l the next pixel to be put on the laser is retrieved, but here is no check against bitmap boundaries. So our understanding to the error is the following: If something goes wrong with the mapping between pos_l and the area over that the laser is moving - for example moving one point too far - the laser will pick bitmap data from outside the bitmap area filled prior with the last "9" command! That explains why this error only appears if in the past this bitmap data was filled with more data - here by the triangle that is getting bigger and bigger from top to bottom.
By turning off bi-directional engraving (which didn't work correctly due speed issues, but let's dig that down later...) we got the prove of our assumption: The miss-firing only occured at the END of the bitmapped line - so the error is that pos_l is counting too far (very likely just by one pixel).

As such errors are often just a +/- 1 issue, I think the quickest fix might be to clear out at least the 32-bit bitmap-entry above the last one written by the "9" command. This could be easily done by adding the following line after line 341 in LaosMotion.cpp:

bitmap[ (step-2) % BITMAP_SIZE ] = 0;

We also tried to prove our assumption by sligtly modifying the Visicut output file, by adding an additional 0 pixel, by changing lines like this:

9 1 160  0 0 134217728 0 0

to this
9 1 161  0 0 134217728 0 0 0

With this patch the issue disappeared proving the erratic behaviour of the firmware.
It would be nice if someone could fix this very annoying issue by compiling a new firmware...


Laser Engrave Error.jpg (21.4 KB) Laser Engrave Error.jpg
drei.lgc (12.8 KB) drei.lgc Small triangle showing engraving issues when engraved more than once

RE: Laser mis-fires ... - Added by peteruithoven over 9 years ago

Hi Lutz,
That's great work!
I'll try to compile with your patch, could you test it?

RE: Laser mis-fires ... - Added by HackerspaceFFM over 9 years ago

Hi Peter,
yes I can test it, if not today than within next 2 days. By uploading the drei.lgc file it should be reproduceable on any Laos laser (but you have to laser this file at least twice).

Thank you for your effort. Anyhow, can you explain me how this bitmap-thing should work? Does it use a specific length-per-pixel or does it automatically map the pixelcount over the whole length of the next line?

Regards, Lutz

RE: Laser mis-fires ... - Added by peteruithoven over 9 years ago

Build it. Please try it.
I will be able to try it on Tuesday.

laser.bin (133 KB) laser.bin

RE: Laser mis-fires ... - Added by peteruithoven over 9 years ago

I'm afraid I don't really know, that's why I wasn't able to build the preview, see:

RE: Laser mis-fires ... - Added by peter over 9 years ago

Great work for tracking this down!
As the index is calculated there might well be a +/- 1 calculation error. Zeroing the original data is indeed required.

Luz/Peter: As for the definition of the raster line: the bitmap data is mapped at equal pixel spacing between the startpoint and endpoint of the next "line" command.
So if the raster data is 1000 pixels, and we move 100mm during the next move: 1 bit equals 100mm/1000pixels = 0.1mm.
The data is grouped in 32bit DWORDS numbers. The bits are read LSB to MSB. There was a descriptive picture on the "very old" Mediawiki at one time. I think it did not get transferred to the redmine wiki. The line:

"9 1 160 0 0 134217728 0 0"

Should be read as:
9: Bitmap data
1: 1 bit per pixel (the only depth supported at the moment)
160: Number of bits. So the number of DWORDS that follow this number is 5 (160/32 = 5)
0 : 32 "OFF" pizels
0 : 32 "OFF" pixels
1040187392: 25 "OFF" pixels followed by 5 ON pixels (1040187392 decimal == 00111110 00000000 00000000 00000000 binary, note: LSB is used as first pixel)
0 : 32 "OFF" pixels
0 : 32 "OFF" pixels

As the preceding command is:
"0 122089 175964" (move to X=122.089mm and Y=175.964mm)
And the next line is "1 108542 175964" (mark/engrave to X=108.542mm and Y=175.964mm), the total length equals 122.089 - 108.542 = 13.547mm
So each pixel is spaced 13.547mm / 160pixels = 0.0846 mm apart (approx 300dpi)

Note that the line can be in any direction (you can raster diagonally).

I've written a "offline" simulator before in c# that interpreted a LGC file (code is no longer online). Can dig locally if I can find the code.

RE: Laser mis-fires ... - Added by t-oster over 9 years ago


what needs to be done in VisiCut to automatically circumvent the issue? I could update the VisiCut driver, which might be easier/faster than doing a firmware-upgrade for now. Please reply in

RE: Laser mis-fires ... - Added by peter over 9 years ago

Trying to fix this in Visicut is not the right direction (it will become a mess).
The firmware fix is trivial, and we will implement and test it.

RE: Laser mis-fires ... - Added by jaap over 9 years ago

I just tested. Without patch, the triangle makes misfires when engraved twice. With patch, the misfires are gone.

I committed the patch to GitHub:

New firmware is available as:

Thanks Lutz!

RE: Laser mis-fires ... - Added by HackerspaceFFM over 9 years ago

I will test it also in a few hours today when I am in the hackerspace. I think I've managed to set up a build environment - at least I got it so far that a firmware.bin file is beeing generated. Today I will try if it is easy possible to replace the I2C driver by MODI2C which allows non-blocking operation. This will give the possibility to make the cancel button work without the need of big reconstruction work that might came up when moving to a RTOS...

RE: Laser mis-fires ... - Added by parag0n over 9 years ago

Just installed and tested this on the Hackspace Manchester laser cutter. Works perfectly, thanks :D

RE: Laser mis-fires ... - Added by HackerspaceFFM over 9 years ago

I tested it now myself and it works with the new Firmware. Cancel button now also, but I start a new thread for that now.