Convert to Engrave - Bug or Feature Request?

I was trying to figure out the engrave settings to cut through 80lb cardstock to make a stencil when I ran across what is either a bug or a feature request. All of the following was done using Inkscape 0.91. The file TestEngrave.svg is a box with a stroke of 0.2 mm, a line with a stroke of 0.5 mm and two crossed lines with a stroke of 0.5 mm and a length of 14.465 mm. The two crossed lines I converted to paths and then combined. I was hoping the GFUI would recognize the crossed lines as an engrave, it didn’t (but that is not the issue.) The straight line and the box I setup as cuts. I selected Convert to Engrave for the crossed lines. I tried increasingly powerful settings for the engrave, but when I got to speed 200, full power, 225 lpi & 1 pass I knew something was wrong: absolutely no marking of the crossed lines. The laser head acted like it was trying to engrave but as you can see from the photo it did nothing. I then made the TestEngrave2.svg file. To do this I deleted the crossed lines and replaced them with two crossed rectangles of length 14.465 mm and width of 0.5 mm: no stroke, black fill. I dialed back the engrave settings to speed 400, full power, 225 lpi and 1 pass. If you look at the photo this was too much power. Settings of 600 speed, full power, 125 lpi and 1 pass created the third stencil in the photo. I set the focus to 0.02 for cuts and engraves.

Perhaps the convert to engrave wasn’t meant to do this, but it’s clearly not doing anything for this use case. As for my stencil, the parts that needed engraving were recognized by the GFUI as engraves and I am good to go. I am not looking for an answer, just reporting this.

And my test files. TestEngrave.svg

And TestEngrave2.svg

1 Like

This question is outside our team’s scope. I’ve moved it to Beyond the Manual so the discussion can continue there.

1 Like

This is a question about an engrave being missed by the GFUI (unless I’m reading it wrong) not a question about non-proofgrade material settings. Is this outside of scope because it’s on non-proofgrade?



That’s a little worrying if any functionality is only covered for proofgrade materials. I know they don’t guarantee results on your on materials, but the software bug issues should still be addressed when on non-proofgrade materials.


It’s not a software bug. The machine refused to process an engrave on paper at speed 200, which would have been much too slow since the speed at 400 was causing it to burn.

Sounds to me like the machine saved itself from a fire situation.


It’s not a bug. You can not engrave open paths (at least not very well or predictably) and in your first SVG file the crossed lines are just straight line open paths with stroke and no fill.

You need to use the “Stroke to Path” tool in order to convert the stroke widths into their own paths. “Object to Path” is for other uses like changing a linked offset item or dynamic offset item into paths.

Here’s what the first SVG file looks like when viewed in “Outline Mode” which shows outlines of paths with no fill and no stroke widths applied to them.

No Engrave


i think this is a good example, perhaps, of support staff needing to be a little more careful and not closing threads too soon. nice to have a knowledgeable set of users around to help.


Not only that, but maybe exploring the issue a little more deeply before casting it aside.

I mean it took me what, 5 minutes or less to grab the file and find a root cause that Support is going to see a LOT.


Thinking it was more likely that support thought it was a problem with the way Inkscape was used to create the engrave. It’s a fine line of course, but support isn’t likely to provide detailed instructions beyond the tutorials on how to use Inkscape, Corel, etc.

You can disagree if you wish.


Now I’m confused, I thought the issue over the stroke versus fill was resolved when @caribis2 put the filled rectangles in place of the strokes for the second engrave. :thinking:

If he’s concerned about the machine not engraving at 200 speed/full power, I think it’s because there are built in limits in this thing to keep us from damaging anything before we figure out what’s going on. (And if there aren’t, there really should be. I really really hope there are built-in limits on these things.)

The 200 speed/full power tested is pretty close to what we are using to cut through wood. (167/full). It would have torched the paper and might have started a fire.

If the machine refused to process it, it’s a good thing. It would save some angst on behalf of the folks using it if they popped a little explanation into the interface to tell people why it won’t process, but we’ve already been told for legal reasons that they aren’t going to provide support for uncertified materials. At least they don’t let us torch it.

Half a loaf situation. We can discuss it here and try to figure out what is going on. :slightly_smiling_face:


The settings are material agnostic for non-proofgrade though, it doesn’t know if there is paper or anodized aluminum or whatever in there. if there was a material (maybe some of the engineered plastics?) that would require that type of an engrave, shouldn’t the machine do it or if that’s outside of their safe parameters, they should give a warning, not just skip an operation.

My umbrage was mainly the swift closing of a topic without a real explanation. I have a worry about supporting only proof-grade using operations, not just the guarantee.


But the machine doesnt know if you put wood, paper, or… string cheese :slight_smile: in it. Whatever the settings are, it will run them, because it’s agnostic to the actual material that’s placed inside.

The reason the engrave did not work wasnt because of settings, it was because of the artwork, and while that’s technically not Glowforge’s gig, they also didn’t explore simply because of the settings the user specified.


haha great minds think alike! :smiley:


seriously we both said agnostic? hahahaha!


Might be able to tell based on the set focal point? :slightly_smiling_face:

It might also be that there is a set limit that does not let you engrave at speeds that slow. The engraving is a function that removes a lot of material in one place, as opposed to cutting through quickly and moving on.

Don’t know. Can’t test it right now, or probably for a few days. But there might be a limit in there that we haven’t stumbled across yet. I haven’t ever tried to engrave anything that slowly. :slightly_smiling_face:

1 Like

When you match laser power and actual physical speeds, cuts, engraves and scores all become the same thing (except for cuts/scores following paths and engraves scanning left/right), and you can set engrave speed down low enough to cut through material. In fact a 200 at the current scale used to be 40/41 IPM

I messed around with these settings back when I was experimenting with the bevels, countersinks, etc.


Yeah, I’ve played with it a little bit, not to the extent that you have. :smile:

I want to get back to this in a few days, but we have got tornado warnings hitting fast and furious around here right now and i need to go pull my husband out of the garage so he doesn’t wind up pulling a Dorothy on me.

Let me get back to this later. :grinning:


I’ll take the heat over hurricanes any day, but I’m still not playing in it… I’m staying inside today…

Which gives me time to experiment with this laser stuff, so here’s an engrave at 155 speed and full power :slight_smile: I set the LPI to 10 so it looks like a series of cuts when it’s actually an engrave… clean through, just like a cut. Note that this is 25 inch per minute speed in real life, which is exactly the same speed for cutting the PG medium acrylic on the old units scale.


You go to replace a leaking drain pipe under the sink and next thing you know all of the drain pipes crumble while your topic is blowing up.

The reason I wrote this:

is so that they would know the issue wasn’t that my settings were too light. My point was that the Convert to Engrave wasn’t working as I expected/hoped. I knew my second file would work and that is what I used to figure out my settings. But the first file is easier (if only slightly.)

Thank you mpipes for your reminder:

I’ve probably read about this a dozen times and now I know what it is in practice. It would seem unlikely I’ll be the last person tripping over this as jrnelson noted and IMO I think @Rita 's team should have a stock answer ready.

While the reason I posted this in the first place was solved by mpipes, there is still this.

The GFUI allows you to select Convert to Engrave, it calculates the correct time for all of the actions and it goes through the motions without firing the laser. To me this does not seem like desirable behavior and I can think of multiple ways to go about changing it in software, so I would argue there is still a bug/enhancement here. I think this is an example of a user reporting one thing when the real bug is somewhere else.

And speaking of bugs, I know it would take some effort @dan, @Tony, but with production units shipping and the software still in beta what about a public facing, read only, bug system? I’ve only had the unit a few days so when I run across something I’m inclined to assume it’s a known issue in the queue and I’m not going to take the time to properly characterize something that is already known. While the normal user won’t comb through a bug list, the ones who can characterize an issue and provide detailed feedback would be more willing to do so if they knew it was working as designed, a known bug, in the hopper or unreported.