Vectorization tool works great but for small details the gap between filling area and perimeter line is visible

[yerpj]

The problem

Hi guys,

First, thank you very much for such a great tool! It took me less than 10 minutes to learn how to use LaserGRBL.
The line filling algorithm seems to work great but some areas near the perimeter line are not burnt correctly. This problem was seen in the past by some users but it appeared that most of the time the problem was due to hardware. I think mine is really related to a limit case of the vectorization tool. On the following picture we see that on top and right of the letter shapes that some areas are not correctly filled by horizontal lines:

Please note that the letter height is around 6.7mm and the line/mm is set to 10.
For such a small text we could think that the result won't affect the final result, however with my 6W laser making 0.2mm thick lines, the result is very similar to what is shown on the preview:

I tried several combinations of lines/mm, adaptive quality and spindle power but I always experience the same result.
Is there any reason why the vectorization tool is unable to fill 100% of the inner areas?

By the way, for those who might think it could be related to hardware: The 5 lines you see above the letters are my lines drawn to calibrate the Z axis. In this specific case, I burnt those 5 lines, then I did a homing cycle, then I revert to the last position and drew the same 5 lines again on top of the existing ones. I strongly think that the problem is not related to hardware.

Thank you very much for your help!

Hardware
GRBL 1.1, custom 3-axis laser engraver

Operating system
Windows 7

[StuartB4]

Don't know if this would make a difference but have you tried using M3 instead of M4. The laser switches of at the end of a line with M4, but it has to stay on with M3 because it was originally a command for the spindle motor on a cnc machine. The spindle has to stay on or it would have to keep speeding up before every line it cuts.

[arkypita]

Hi @yerpj

What you report is a fairly known LaserGRBL problem. The problem is that the realization of vector + filling is done with the part of the filling done in raster (the vector image is rasterized and it is processed by the line2line algorithm) and not in vector too.

This causes small misalignments that are difficult to manage but I admit that I have never put my head too seriously on this problem.

One thing you can easily do is increase the line / mm resolution beyond 10, and possibly make faster passes if it turns out too dark. With a higher resolution the problem is greatly reduced.

As soon as I get some time I swear I'll try to improve it.

Another thing that could affect is the speed / acceleration of rapid movement, which could lead to your marker being less accurate in vector moving around on white. Try disabling G0 in settings -> raster import

Edit: Disabling G0 is not needed if you are sure of your hardware reliability

[arkypita]

As you can see the issue still exist, but its effect is limited, when you increase resolution.

[arkypita]

PS: this issue is already opened here #1034

[yerpj]

@StuartB4

Don't know if this would make a difference but have you tried using M3 instead of M4. The laser switches of at the end of a line with M4, but it has to stay on with M3 because it was originally a command for the spindle motor on a cnc machine. The spindle has to stay on or it would have to keep speeding up before every line it cuts.

Thank you for your help. Actually I already tried with M3 and M4. M4 is better because it won't burn too much the start of a line. For the current problem I am experiencing, both M3 and M4 give the same result.

@arkypita
Thank you very much for your explanation. I will try with greater line/mm resolution, however as far as I remember I already tried up to 20lines/mm and I still noticed this small misalignment.

Anyway, thank you for your help. I'll follow #1034 and will try to help if I can.

[arkypita]

Hi! I have made a small changes to try compensate the shift effect.
This need to be test, please download v3.8.8 and let me know

https://github.com/arkypita/LaserGRBL/releases/tag/v3.8.8

[yerpj]

Hi!

Thank you for your reactivity! It is very much appreciated!

I just gave it a try with the same parameters as previously:

The image size is slightly different because I was too quick on cropping the original image. Anyway, regarding the gap between perimeter and inner filled area, it seems not to be significantly better.
The "RAS" height is about 6.5mm, with 10lines/mm.

[yerpj]

And a quick try at 20lines/mm. The result seems better at first look but after a zoom in it appears that the gap is still the same, even if it has been burnt a bit due to an increased number of horizontal lines.

[arkypita]

Are you sure that this issue is not caused by the shaking of the machine, the belt tension or from problems resulting from too high speed and acceleration? I do a test with 10 line/mm at 1000mm/min both orizzontal and vertical and here is my result:

I also check "Disable G0" to have more accurate positioning.

[yerpj]

I disabled G0 fast skip.
I am engraving at 800mm/min (working and filling speed)
I engraved 5 vertical lines (2mm spacing), then I moved randomly the head on X and Y within an area of 300x300mm, then came back to the original position and engraved again the same 5 lines. As you can see they are completely superimposed. I don't think the problem comes from the machine itself.

Below, I just gave a try with filling speed at 400mm/min instead of 800.

In my opinion this confirms that the cnc moving speed is not the cause of the gap.

Anyway, thank you very much for trying to solve this problem.
It could be of great value to observe the results from a third user, just to know wether I need to do more tests on my CNC or if we need to focus on the vectorization tool itself

[arkypita]

I am working to improve it more

[arkypita]

just the time to make some test and I give you a pre-release :-)

[arkypita]

the results look promising

[arkypita]

Try now with https://github.com/arkypita/LaserGRBL/releases/tag/v3.8.9

[yerpj]

Well it is actually better than previously. Here below is a comparison between 3.8.8 and 3.8.9, both with 10lines/mm

And I tried with 15lines/mm. In this configuration, the gap is so small that it is barely noticeable:

Thank you so much for taking time to improve this feature. Despite the (very) small gap is still here, I think we can live with it. At least I can.

I look forward to see if this 3.8.9 pre-release also does the trick for other users that experienced the same gap issue.

Again, thank you @arkypita !

[arkypita]

Well, doing this test with plywood doesn't give you the correct response to evaluate the result.
I use a black painted white paper that allow me to see each single line.

Here is the result

The upper engraving is 6mm tall, the lower engraving is 4mm tall.
Is it possible to see that the curved "S" arcs produced in the 4mm is very loose, approximate... but to be honest it must be said that the code generated by LaserGRBL is highly precise, as shown by the preview image, which is generated on the gcode.

So, in my opinion, the fault of this result could be some approximations made by the grbl controller, that is by the firmware of the marker. What do you think?

[yerpj]

I am using GRBL 1.1. I tried with smaller heights. In my case it does not alterate the shape even in small size (down to 1mm)

In your case might it come from a position drift depending on moving direction?

[arkypita]

What is your grbl $$ configuration?

[yerpj]

[arkypita]

You have double of my resolution

[yerpj]

While being well tuned for small text symbols, now it turns out that for larger images it may not improve that much, compared to the previous version. (It may even be worse)
With 5lines/mm, here is the filling pattern I get (height is 15mm):

The actual result looks like this:

It really looks like the gap size between filling area and outer perimeter is inversely proportional to the line density.

Any idea how to get rid of this problem without increasing the line density?

[arkypita]

I know that it's not the best solution, but if you de-focus your spot a little, all those artifact disappear! :-)

[yerpj]

Yes that's probably what I am going to do.

[arkypita]

Do you want to try this new version? I think you will be surprised!
https://github.com/arkypita/LaserGRBL/releases/tag/v4.0.0

[yerpj]

Yeah, good job, there is a lot of new features in the vectorization tool ! ! !
I've just tried it out, in order to compare the old and new horizontal filling method, and to me it looks better! Still some very tiny areas where the filling is not perfect but it probably comes from my machine.

The green circled letters are fresh from v4.0.0, while the red ones are from previous version:

In the A letter with the new horizontal fill it looks like it forgot two lines but it may also come from my stepper drivers (drv8825) which are known to be bad at microstepping, even if, that said, I should have seen the same issue in the previous burns, which actually was not the case... don't know... Anyway, that is excellent, well done @arkypita !

[arkypita]

I'm still working on it, and with a lot of help from @HomineLudens I should be able to publish a version shortly that optimizes engraving times by finding the fastest filling path. I think we will have to give him a "huge thanks" and if anyone wants to make a donation for this work I will be happy to turn it over to him.

[arkypita]

https://github.com/arkypita/LaserGRBL/releases/tag/v4.0.2

the new horizontal fill it looks like it forgot two lines but it may also come from my stepper drivers

Yes i think it was hardware issue.

[yerpj]

Yes i think it was hardware issue.

I just took a picture and engraved it with old and new horizontal fill (cropped by hand, sorry, they are not exactly the same scale, but pretty close):

It seems that the missing lines does not come from my hardware, because there is absolutely no missing lines with the old horizontal filling method.

[arkypita]

Please zip and upload generated gcode, so I can check.

[yerpj]

I did not save the gcode but I opened the same picture, tried to crop it at the same location, then saved this new gcode. Here it is:

horizontal_filling_gcode.zip

[yerpj]

Well it makes me think that it could still come from my hardware:
the old horizontal method just induces Y-axis movement always in the same direction. With the new horizontal method, the Y-axis is moving back and forth. Considering even small delta in the Y-location after a round trip could lead to the result I had...
I will make a small round-trip test and let you know.

[yerpj]

Here is the gcode I just executed:

S300 F500
G0 X[left] Y[bottom] 
G1 M4 G91 X5
M5 G0 Y20
M5 G0 Y-20
G1 M4 G91 X5
M5 G90
G0 X0 Y0 Z0
M5

Basically it draws a 5mm line on X axis, then makes a round trip on Y over 20mm, then draws a second 5mm long line on X.

We see that there is a very tiny delta on Y but IMO it is not enough to induce a visible effect when filling an area.

[arkypita]

First i emulate the code you upload, it shows no problem in the generated code. The preview shown by LaserGRBL further confirms.

2021-01-08.09-49-03.mp4

So I try to do an engraving of the file with my Ortur and I had same issue as you. Also slowing down to F1000 doesn't change the result.

I think that the problem is due to the fact that it is physically impossible for the machine to reproduce some positions exactly, as the motor can only move in full steps, which approximate the position but do not reach it exactly. When this happens in a fill that flows in one direction only this has little effect, but when the direction changes multiple times it is possible for the error / approximation to accumulate. This new vectorization mode amplifies this effect.

There is a tool that allows you to set a resolution in lines / mm which is multiple of your motor step. I'm not sure right now if the new algorithm follows it correctly, but could you try to experiment with this?

NB: I'm pretty sure you need to put offset 0, 0 in the "target image size and options" window to have the correct line positioning at step multiples.

[yerpj]

There is a tool that allows you to set a resolution in lines / mm which is multiple of your motor step. I'm not sure right now if the new algorithm follows it correctly, but could you try to experiment with this?

Actually the resolution I use (10lines/mm) is already aligned with my motors steps (160steps/mm). I also always put 0,0 as target image offset.

It seems that the problem comes from elsewhere. . .

[arkypita]

FYI: the wobble lines in S contour, was due to loose belt/screw in my hardware.

[HomineLudens]

I run the same GCode in my machine with a scrap part of soft wood:

In my opinion it could be not an issue related to mechanical backslash, but more a result of different reaction of the material to the laser beam.
Let me try to explain: observing the burning of the material it looks like some of the isolated lines when burned alone produce a very thin sign in the material, while sequence of two or more passes (even if isolated) make a bigger sign, not proportional to their theoretic size respect the single segment.
The original algorithm starting from bottom to top, ensure that side by side line are burned in sequence, "spreading" the burning from the previous one and so producing a more homogeneous look.

[nistre]

Why was this closed? I don't think the referenced issue (#1034) is the same issue as this

[arkypita]

Was closed because:

1. a new release was out, with new vector+filling tools that was mathematically exact: https://github.com/arkypita/LaserGRBL/releases/tag/v4.0.5

2. any difference from what is drawn in preview, and what the machine draw, should be investigated by machine side.

With my engravers (2 commercial model + 1 DIY) I can do the vector+filling perfectly as shown in preview.

If starting from the same gcode, other engraver give less precise results, it is definitely a problem that concerns the accuracy - of these machines - to perform the required positioning with precision.