Draft score punching through proofgrade cherry hardwood

I was scoring a rather intricate design on proofgrade cherry hardwood and found that there was blow-through in some spots.

Any reason why a draft score operation should go through the material.

Here’s a closeup of the corresponding “good side”


Only reason I can think of is too much power, or too slow. The solution is to dial back the power a bit, like 10 numbers.
After choosing which method, you can click on ‘manual’ and see what settings were populated.

The proof grade settings are helpful for people like me when first using a laser, but over time I have found that I usually work in ‘manual’ with the supplied settings as a starting point in my tests - with the exception of cuts to proof grade. I always use those.


Without seeing the file I’d guess you have multiple lines laying on top of each other. The GF would see those lines/arcs separately and make multiple passes to cause the blow-thru areas.

It’s easy enough to have that happen based on my experiences.


Also, in general scores can punch through pretty easily in places where the head comes to a stop.

1 Like

I think the blow through spots are mostly the corners of all the little rectangles on the design. I don’t think there are any duplicate vectors. But shouldn’t the laser drop the power as it stops and changes directions to avoid blowing through?

Plus, as much as I am fine with adjusting things for non proofgrade materials, the whole business case of the proofgrade is that it just works without adjusting settings, and having the blow through doesn’t count as working in my book.


Probably, but not yet. Nor does it do looping corners as an alternative solution.

Any chance it looks interesting backlit? (looking for a silver lining…)

That is correct. I have seen one or maybe two cases of people receiving machines that were “over powered” and they had to be returned.

The most likely cause is as hansepe said, there are multiple boxes where there should only be one. More than one experienced Inkscape/AI user has had this or similar bite them. If you can post the svg (in a zip file) it usually attracts the attention of the forum members who like a good vector graphic debug. If you send it to support, they will presumably try and recreate your issue and figure out where to go.

If you cannot post the file, try running it again on something less expensive and carefully watch the print head to see if it covers the same area twice. Note that it probably won’t score a box and then score it again. If there are overlapping boxes, the algorithm will score it once, go do a bunch of other things and then come back and score it a second time.


sample blow through.zip (23.6 KB)

I’m pretty sure that there are not duplicate vectors, but that the laser power remains constant when going around a corner - stops in X for example, then speeds up in Y. All the blow through seems to be at corners in the design. If it were an issue with duplicate vectors, it should be whole lines that are blown through. That being said, here is the artwork. I had used proograde cherry hardwood and chosen a proofgrade “draft score”.

This seems like an accel/decel power modulation case; you have a fairly complex design (which in itself isn’t much of an issue) combined with a pretty small area. How the algorithms are modulating power during the accel/decel could be an issue, because you really don’t have a lot of space in most of the design before the head has to accel or decel. Lots of components in the design are .02-.05" before a direction change occurs.

A good example of this is in picture where it looks like the straight lines created perforations. I think those are actually the boxes that are contained between two parallel lines. The boxes are about .05" wide and .03" tall.

I’m thinking they need some work on the ramp up/slow down algorithms.

1 Like

One other thing that I’d be interested in experimenting with (if I had any Proofgrade laying around lol) - is if closing the paths would make any difference. None of the paths are closed. They are very close, but not actually closed. I wonder if that makes a difference in determining accel/decel, or anything else.

1 Like

Correct, this is a known thing - you’re corners are crispier when scoring and cutting. It is why the serious paper-crafters here will engrave through the paper rather than cut. It takes longer, but it comes out perfect (once dialed in.)

While the corners will be a little deeper, they should not be burning all the way through with a single pass. If you are going to get any burn through, whether a single pass, or multiple passes, you’d expect burn through at the points the head changes direction. I was trying to cut through 0.27" African mahogany last week, and the corners were about the only places the laser went all the way through.

1 Like

That’s funny. When I look at the vectors in VCarve Pro before exporting them, I choose the “Selection->Select all open vectors” menu item and it says - no open vectors in design! I wonder if that’s not getting communicated when it exports as SVG?


Interesting… looking at it through a microscope, basically (64,000%), the points are basically laying on top of one other, the shapes just aren’t actually closed. I’ve never investigated the actual SVG-code difference between open/closed paths/shapes… if there is a difference, I wonder if there is something in the algorithm that differs since it knows that it’s coming up on a point that is closing the shape. Anyways, that’s all speculation and pondering.

Sounds like a good one for @chris1 to test :slight_smile:

Since it treats each path as a separate draw operation (just as overlayed filled shapes will engrave both), even with perfect corner compensation the laser is going to score each path fully. Thus the ends where the paths overlap are getting a full 200% power.

I don’t know anything about VCarve Pro, but it is known that conversions to SVG by many programs cause various problems. For example, some export curves using a few path points and Bézier curve parameters, and some export them as very short lines.

For controlling a CNC milling operation, dwell time at a corner doesn’t matter, nor does returning to a previously cut spot. So it may be that their export doesn’t bother to convert those to full paths.

Maybe running the output through SVGOMG might help. I haven’t used it but perhaps this is one of the things it can handle?


In Inkscape it looks like this:

Every object I’ve looked at has one corner where two nodes are overlapping. A selected single node (without a node beneath it) is a yellow square. A selected node with one directly underneath is a blue square inside a white one. If you delete one of the overlapping nodes the segment it anchors goes away. At this point you could join the two endpoints to get the square back. I deleted a single node just to show the difference.

Looking at the back of what you scored, I’m not convinced and I’m also not not-convinced this is the issue. If I have any proofgrade cherry hardwood I may try some experiments this weekend.


Overlayed filled vector shapes actually minus out the two, don’t they? For example, we’ve seen numerous times text converted to outlines that create a void where two components cross.

So the code is definitely different, since SVG has a “close path” command.

I selected one of the itty bitty boxes on the left side of this design. The pertinent code for the original, unclosed path is:

<path d=“M723.861,435.91507v-2.97153h-3.7144v2.97153h3.7144”

The pertinent code for the path that I closed:
<path d=“M723.861,435.91507v-2.97153h-3.7144v2.97153Z”

The “Z” at the end of the closed path code instructs it to render a line back to the first point, to close the shape.

The unclosed path code simply says draw a horizontal line with these parameters.

The question is whether the motion planning acts any differently for an absolute closed path command where it knows that it’s going to be butting right up against another point.

1 Like

I took the vertical row of small boxes, copied and pasted it. In the pasted copy I closed everything with Inkscape. So the file has one set of boxes with overlapping end points and one with closed end points. If someone wants to test the attached file it would tell us either, yup that is the problem, or inconclusive.
blow through test.zip (4.9 KB)

1 Like

Entirely depends on how they are done. Concentric circles just placed on top of each other, each engraved at 10%, would create a target effect where each ring I’d 10% more engraved than the previous.

If they were all part of a single path, and the winding directions alternated, the fill-rule:nonzero should kick in to make alternating circles blank.

For un-engraved text to show up in an engraved field, it needs to be subtracted from the field, thus producing holes and islands in the field shape being engraved.

In this case, the paths are considered by the motion planner to be zero-width. They are scored with a width of the kerf of the laser, but the motion planner does not seem to be accounting for that when dealing with path ends that are overlapped—even if they are part of the same path. Corner optimization is not being applied at the start and end of the path.

After seeing @caribis2’s comments, and looking closely at the photos, it would appear the overburn is worse at the start/end, but not limited to there. I think their settings may be optimized for larger features.

This may be a case where rasterizing might be a better technique.

1 Like

For those who are just interested in avoiding this problem, note that you can use the HD score setting and it won’t happen.

For everyone else who’s interested in the details…

At this time, the power doesn’t change during acceleration/deceleration. Line start/ends and corners can cause the laser to slow or stop momentarily which causes a deep divot.

I believe this is correct - so you’re getting double divots, which are punching through.