LAOS Laser

Gordon,
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

Paul

Hi,

I think those are related to engraving. I also had some of them: http://redmine.laoslaser.org/issues/47. Are you using the latest firmware?

Maybe related to: http://redmine.laoslaser.org/issues/58

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.

-Gordon

see also the following link http://redmine.laoslaser.org/boards/3/topics/680 found in the forum - software

appears to be exactly the same issue to mu eyes

Paul

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 ...

-Gordon

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.
https://github.com/LaosLaser/Firmware/issues/28

This github? https://github.com/peteruithoven/SimpleCodePreviewer

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?

-Gordon

He is talking about the issue tracker of the LAOS project in Github: https://github.com/LaosLaser/Firmware/issues

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.

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.

-Gordon

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.

Cheers,

-Gordon

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.

Hi,

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)));

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

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...

Regards,
Lutz

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

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

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

I'm afraid I don't really know, that's why I wasn't able to build the preview, see:
http://redmine.laoslaser.org/boards/3/topics/640

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.

Hi,

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 https://github.com/LaosLaser/Firmware/issues/28

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.

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

I committed the patch to GitHub: https://github.com/LaosLaser/Firmware/commit/1169800fd306cc3cb0225feb42ab2a09c9789b0d

New firmware is available as: https://github.com/LaosLaser/Firmware/blob/master/laoslaser-26-10-2014.bin

Thanks Lutz!

Hi,
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...

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

Hi,
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.