what are the object limits of the ui, several times now I have bounced in failures for some of my larger plans
in this case i was just trying to get run time so i can plan my day tomorow but couldnt even get the tim estimator. it also took 25min or more just to load the file into the UI and assigning the the engrave/score/cut also was not fun
When I’ve seen that error in the past, it’s because my file was larger than the printable area.
ya I had some objects outside the print area deleted them
it took 20 min just to delete them but everything is in the zone right now
I get this error message more than I like :-/ It’s hit or miss if I’m able to figure out what it is. I often find that if I just keep trying, it will magically work at some point without me changing anything in the files. It is very frustrating though as I’ve wasted a lot of time getting things to load.
Guess the UI doesnt like really complex stuff.
Break it up into multiple jobs by assigning more colors so you can set different parts to ignore. This lets you feed the UI smaller chunks while also not moving artwork around and trying to maintain alignment to keep the pattern as it should be.
I’ve only had this problem when I had some bad pathings… Like a few extra thousand unnecessary path nodes due to a spline circle or an improper bitmap trace.
Or try doing half of those at a time. That would take hours to engrave, because it spans the entire sheet.
I’d try breaking it into smaller jobs, which has the added benefit of giving you time to take a potty break once in a while.
edit: you also need to remove the four rectangles that you are using for placement of the design that run all the way to the edge of the bed.
I had a similar issue last night. Nothing I tried worked with a design I’m making. I did it as vector art but realize that it has a boatload of complexity so wasn’t surprised. Turned it into a PDF and a PNG and neither worked either (using both the add artwork in the bed image view and the drag & drop in the catalog view) - it would prepare the design after I hit the print button and 5 minutes or so later just kick me back to the bed view with the error. The PNG was a 2MB grayscale file so I really expected that one to work.
I did use the time waiting on it to load to break it into 5 different iterative jobs to try tonight but now it’s beginning to feel a lot like the Redsail 
Ya once into the ui I delete those elements as they afe only needed in inkscpe to compensate placement for our limited bed space
I also don’t like the idea of having to run chunks of the same job over and over as placement shifts everytime the image refreshes. Really I should be able run a bed size job with out a problem and what ever issues they are having due to ‘things being to complex’ is a cop out and they need to fix it
I tried deleting all but one of the lizards, and it opened in the interface, but it opened waaaay off of the bed. And that wasn’t where I placed it.
Whatever you’ve got going on in the file, it has to do with placement and sizing of the overall file I think.
This might be a units problem. (Inches versus mm) or conversion of some sort.
No, the placement doesn’t shift at all, but the camera view of it does. If you do not touch the material and run the second part of the job…even if it looks like it has shifted half an inch, it will cut in exactly the place it is supposed to.
It’s something that usually takes folks a while to realize. Just go for part two without shifting the images on the screen. It works. 
Od it opens spot on perfect placement for me no adjustments needed at all
Ugh sounds like major problems still to be worked out
Did you save it as a Plain SVG or an Inkscape SVG? Because my opening it in Illustrator to test it might have introduced the conversion error. (One reason why I don’t like to switch between programs to try to trouble-shoot.)
Just try deleting all of those rectangles out of the file before you save the SVG. Don’t try to wait until you get it into the GFUI to delete them. There are actually several overlapping rectangles running across the top of that file, and the overlapping paths might be what is holding it up.
You have more patience than me; I wouldn’t wait 25 minutes for sure!
Awesomely, due to an extremely generous forum user, I can now at least access the UI and load files to experiment and see what they look like.
The file is incredibly complex because none of the pathing that could be connected is connected. For example, the cut line defining the shape of the lizard is comprised of almost 60 separate paths when it could be just one single path. Every single direction change in a path creates a new path in the document. Just a few minutes of clean-up and I was able to reduce the document from 33,151 paths to 7,020. Not only does this process a ton faster but it should cut faster and cut better.
I also received some weird warnings related to Inkscape after I had modified the file:
error on line 16 at column 105: Namespace prefix inkscape for connector-curvature on path is not defined
Inkscape definitely adds a lot of stuff to an Inkscape SVG file and it doesn’t seem to play nice once edited anywhere else. Eek. That’s a mess. No idea how the Glowforge interprets those commands, or, if they ignore the Inkscape-related XML, the file isn’t able to parse correctly…
I copied the items over to a new document and saved them as a completely fresh SVG and it was no problem. Anyways - I know that doesn’t answer your question as to what the object limits are… but, just some ideas on how to clean up the file and get better performance.
It was a freeley available svg that I color coded and tiled.
If somone could tell me how to join the paths that would be great because inkscape is a pain
Believe in the Jules…I was one of these people and it’s a very difficult concept to grasp.
Yep it’s true, this totally works.
Just yesterday, I was trying to cut through 0.42" thick bamboo and after 12 passes at full power I gave up… but every cut was nuts on accurate on top of the previous one.
This should help:
It’s NOT fun but it only takes a few minutes to run through a file and do. And you should ultimately have a file that processes faster and cleaner. By cleaner, I mean that it’s only going to cut one time around your lizard, rather than starting and stopping at every path that currently exists - it should make a cleaner cut.
