Vertical printing is off

Is anyone else having this problem? I’ve finally been able to test and confirm this. I have a side of a very precise box that has to have exact measurements for the joints and gears to fit. But recently they’ve not been fitting. Same design I’ve used for months. The vertical printing is shortened. It’s 93 mm wide but when turned 90 it’s only 90 mm. But then the 102 mm height becomes 99. I wasted about 4 hours with their help desk, only to run their alignment tests and have them say it’s work!!!

That could happen if the laser arm isn’t square to the rails

1 Like

If you highlight the piece it will give you the overall dimensions. You may find that those have changed. It is very easy to scale a piece that you intended to move and if you don’t notice, then the size will be off. I have done this many times and now double check before hitting the Go button.

Good idea and I did that.
In the Inscape software I created 5 squares, 4 nested inside the other. They measured 4", 3",2", 1, .5" exact squares in Inkscape. The Glowforge measurements were 3.955", 2.995",1.995", .995", .498" also exact squares and acceptable. But what printed were 4.066X3.999, 3.045X2.992, 2.025X1.990, 1.005X.987, .497X.489 rectangles. There’s the problem. This may not sound like an issue but when you are dealing with 40 joints on one side of a box, being off just a little is an issue.

I did that, and it didn’t make any difference.

There is something amiss in how you are exporting from Inkscape. It’s not a hardware problem if the UI is indicating a different size from what you are specifying in Inkscape.

I just created a file with 4 squares, 4x4", 3x3", 2x2", 1x1". They import into the interface at those precise dimensions and print to within the expected kerf width of my material (plain chipboard), around 20-25 thousands of an inch in both directions.

Suggest you share a sample file that is not printing correctly and someone here can check the dimensions in the file.

Have you set Inkscape to ignore stroke (line) width in its size calculations? You do that in the Preferences (Ctrl+Shift+P) and clicking on the Tools heading in the left column. In the right you should see something like this:
image

Make sure the Geometric bounding box option is selected. That ignores the width of the stroke in your object’s reported size. So if you’ve got a 2 pixel stroke width, the Geometric option will ignore the 2 pixels of the line in calculating the size. If Visual is on, then your box will include the 2 pixels of each line. But the GF doesn’t know anything about stroke width and uses the center of the lines to determine the size. So if you have Visual bounding box, GF’s reported size will be smaller based on how thick your lines are in Inkscape. Switch to Geometric and the GF will see the same size as Inkscape does.

That’s a good one to keep in mind, but surely that wouldn’t only reduce vertical dimensions when an object is rotated?

That’s part 2 of the problem. Part 1 was them coming into GF smaller than defined in Inkscape (but still square).

After that’s resolved I think there’s an issue with either kerf or measurement. Getting 3 digits of precision measurement out of most calipers is a tricky business with materials like wood/paper/cardboard.

Also need to look into why the designs used to work but have changed (update to Inkscape & DPI change?). Again though, I’d take it one step at a time starting back with the source file setup, then the files themselves and then the GF.

Thank you for all the tips. I change the bounding box setting. This will help in my designing but being off 5 thousands of an inch to start isn’t a big issue if it’s consistent. Efylyguy is correct it’s that the vertical size changes when I print. As of today Glowforge help is saying they can’t help and it “sucks to be you”.

1 Like

Here is the file I’m testing.
square test

jamesdhatch, thank you for the inscape Geometric setting. Now my inkscape measurements match the glowforge measure measurements 3.955", 2.995",1.995", .995", .498. But didn’t resolve the problem of the vertical box sizes getting bigger. I agree caliper measurements aren’t 100 % accurate to 3 digits. That’s why I printed nesting boxes. If they print correctly you should be able to rotate the interior
square test
boxes with no problem.

1 Like

All of those squares are 0.005 undersize when opened in Inkscape, except for the 1/2 square which is 0.002 undersize in both Inkscape and the GF UI. So if you are designing them to be 4/3/2/1/.5, something is wrong with how they are being exported from Inkscape.

That doesn’t explain why it would be significantly differed vertically when cut.

elfyguy, you’re right they are off and I’m ok with that, thanks to jamesdhatch tip for inkscape I can correct that. But yes the vertical cut shouldn’t change. I’ve only noticed this happening within the last couple of weeks. I bounce from one project to the other so I can’t pinpoint an exact time. But up to a month or so ago this wasn’t an issue. And nothing has changed on my side. Machine hasn’t moved, using the same material I’ve used for over a year… So I’m stumped. Apparently so is glowforge support.

1 Like

Correct. That is almost certainly a mechanical issue.

If you document that in photos and send in an email to Support I believe they can fix that from there. There are many adjustments they can do per individual computer from Seattle. That is one of the bigger advantages of working from the cloud.

The measurements are from the printer cuts. As for at support, I’ve been emailing and chatting with them for a week. Their finally answer was ask in the community!!

1 Like

I am surprised they did not make the change earlier, though there is a need to not cover up a different problem that will rear its head again after. I have had them adjust what the power numbers mean if they were set to low, but you do not want to clean a dirty lens and find it suddenly cutting too hot for example.

I’m surprised they gave up on solving this problem. That’s something @emilyhuh might want to know about since customer relations are linked to support experiences. It’s a useful data point for her efforts in identifying trends and potential solutions/programs.

1 Like

Thanks for bringing this up @jamesdhatch. I’ll let the team know!

1 Like