I noticed some updates to the UI since I last cut things a couple of months ago, but I’m having some problems with uploading an SVG that it refuses to process. Previously, I uploaded similar large SVGs (not that big or complex really, just lots of little cuts) and it would take a long time to process but would import them… however it seems to puke on this relatively simple pattern.
I’m looking for some guidance from Glowforge on this as to why I can’t cut this relatively simple pattern? I realize there’s lots of tiny paths for the cuts, but I cut this stuff on a Universal all the time, and it’s never been a problem. Please advise.
Is the perforated portion supposed to be engraved or cut?
Simple is kind of a relative term. There are some fundamental differences between the file that you can open and can’t open.
The primary one being that in the file you can’t open/won’t process, each of those little perforation marks is an expanded shape (basically, a rounded rectangle) that is .0028" tall. In the one that you can open, each of those perforations are set up properly as just line segments.
The one you can’t open has 53,000 some odd anchor points, vs about 16,500 on the one you can open.
I’m also not 100% sure, but I wonder if the (lack of) decimal precision could be an issue here as well.
There are some fundamental differences in how the different systems also look at and interpret the files. My understanding is that the print driver will rasterize these little tiny closed shapes for you when you send it to the printer spool. Whereas the GF software is recreating the SVG internally and accepting it all in vector format.
If these little green circular rectangles are meant to be engraved, I would probably just rasterize that one big group and be done with it.
ah sorry. I have so many versions of these files it’s hard to keep track.
basically I want to cut perforations but the Glowforge has abysmal strength control for cutting equality when it comes to paper; so the ends of line segments get burned through significantly while midsections are done to “correct” settings. I desperately hope this is repaired in some future updates but for now I have to make lots of workarounds.
So I had taken dashed lines, converted them to individual line segments, but then made them into rounded shapes - because just blasting a straight line segment doesn’t quite give a large enough perf. I had tried doing line segments and defocusing to get a broader cut, but that just caught things on fire
Right now I’ve modified the design and am testing lower speeds with just dashed line segments, if I slow it down to 100 I can get relatively accurate cuts and deeper burn-through (normally unwanted but useful for bigger perforations). it just takes 10x as long as it would at 500.
When you can afford the time, engraving paper gives you delicate control with no endpoint burning. It’s VERY slow compared to cut or score, but the results are fantastic.
Hi Tim - I know that the engraving option works very well for clean results, but it’s something like using the google maps walking instructions instead of driving - one gets you there in say, 12 minutes, the other one takes two hours… while they are both viable options, one is a lot more practical than the other
I know this kind of laser control IS possible, as I use it on other laser systems that aren’t massively expensive, and I do hope the GF gets there at some point. I found that slowing down the laser head on the GF helps but you have to want to burn through at that point, as even the lowest setting can scorch through thinner paper.
All in all they’ve made great strides, I just have really specific use cases for what I want to do with the laser (complex computational origami patterns) so I’m always trying to get it to do what I need, vs what it can actually do.
I guess we can close this ticket and I’ll accept that the GF can’t handle complex patterns and will resort to using the real lasers to process that stuff. hopefully the GF catches up one day.
Thanks for the answer @jbmanning5, that’s right. There is a problem with our software in handling very complex files, and it looks like that’s what’s happening here. In this case, the complexity refers to the number of individual nodes present in the design. I’m going to close this thread. I apologize for the inconvenience, and thanks for letting us know about this!
