Unit is engraving all of this right now.
Here is the file I created. I try to pull it into Vcarve Pro and it goes crazy with the image so I am not sure how glowforge interpreted it correctly twice and then wrong the 3rd time. Looks fine in inkscape though any assistance with what I have done wrong or what is going on would be helpful. Thanks in advance.
Pier 509 Design Wood Card.zip (34.1 KB)
This response is unofficial and maybe the machine is busted, dunno.
But usually these anomalies are coding issues and not the machine going into an alternate universe. So I examined it from that angle.
Something is going on there and I suspect it has to do with the UI SVG interpretation fighting against some artifact of the SVG file from the program that saved it.
Opened it in Corel and it is a mess. This usually happens if someone uses Inkscape and does not save it as a native SVG.
When saved as ‘Inkscape SVG’ it adds artifacts that are useful to the program apparently, but are not regulation SVG protocol.
Remember that a protocol means it must have ‘at least this’. Lots of companies add extra coding on top of a protocol to aide their native programs, and it is allowed because they have the ‘at least this’ included.
My fix for that is to load it into Inkscape and re-save as either a native SVG or a PDF.
I did that with this file. Saved it from Inkscape as a PDF and loaded it into Corel.
It showed crisp. When blown apart and examined I saw nothing around that P that should have caused an issue.
TL:DR Try saving the file as a PDF from whatever you drew it in and maybe prevent the Glowforge UI from mis-interpolating whatever artifact of extra coding caused your issue.
I don’t usually save in anything but plain svg in Inkscape as i can’t pull into Vcarve any other way as far as I have found(I could have and didn’t notice though wouldn’t be the first time). I did find a few issues with the design that I didn’t see at first and have since fixed as well as simplifying some of the images that had a lot of extra nodes in them.
My main issue is that i pulled in a single image, used the Glowforge UI to copy and paste the other 2, and the GUI interpreted 2 of them just fine and engraved them perfect and then decided to put a line on the third. If all three had put the line on them that would be understandable, but when it does 2 of them correct and 1 wrong that is a glitch somewhere from the time it is rendered to the time it is actually engraved. That is what I am trying to get across here. I have it working but in the end it doesn’t make sense for it to do what it does over the long term.
Other thing – I assume you’ve checked – as usual is unclosed path(s). GF will close them and not in nice ways. But odd for it to happen only once.
it will? i haven’t had that happen. any straight line is an unclosed path. i’ve used many paths that weren’t closed and haven’t had an issue with it not working.
If you try to engrave an open path, it will attempt to close it to satisfy an engraving boundary.
ah, ok. good point. i was thinking more of cutting/scoring. an engrave has to be an enclosed object.
I fully understand what all of you are saying and yes I fixed my design. What I am getting at is the GUI should either do it correct all three time(preferred) or incorrect all three times. The fact that it engraved all three at the same time in the same run and only had an issue with one dosnt seem right to me.
Completely agree. If it’s not due to a bad copy in the source file (I’ve had those) but are because of a bad copy in the GFUI or even just erroneously handling one of multiple copies coming from the design file then that’s a GF error to fix.
Oh my file had issues. But with those issues in the file it ran it good 2 of the three. So it interpreted it good 2 of 3. All I did was pull in a single file and then copy paste twice. And then hit print. So maybe the copies changed something and the original was the bad one not sure.
Maybe but that ought not happen either 
The GFUI needs to be consistent in how it treats a file & its objects.
If you can give them a date + time stamp + time zone - with that heads up I imagine they can dig into the actual data sent and see where this line came from.
All we can do is produce ‘what ifs’.
Seeing the actual data sent to the machine would give a concrete answer as to where it gronked, and if it is in the duplication phase, then they also can task their coders to figure out why.
When numbers are stored using floating point adding an offset to translate a copy can cause a reduction in precision. The set of numbers floats can represent are not evenly spaced on the line of real numbers. The further away from the origin the wider they are spaced.
So it is possible for an edge case to come and go when coordinates are translated. For example two points very close can merge to the same value when translated away from the origin. So a marginally open shape can close when translated.
Thanks for letting us know about this. I’m sorry about your print and I’m glad you were able to adjust your design.
We are seeing this too and we’re looking into the issue. If you rasterize the parts of your design that you want to engrave, that will consistently prevent the extra line from appearing. I’m sorry for the inconvenience.
If you see this again or if you have another question, please post a new topic.
