Cannot find the issue with this SVG

I am working with @classicsmiley on a project relating to a LEGO club and a historic train depot.

We are trying to get the file to print quicker, but combining components just gets us an error when hitting print (the generic non-descript error).

Here is the SVG:

OrnamentLayout_Half_TextToPath

In case it doesn’t upload properly
OrnamentLayout_Half_TextToPath.zip (963.3 KB)

EDIT: Here is the original (each ornament as separate engrave) where the top row won’t print at all and selecting more that 2 rows at a time doesn’t generate an error, just crashes the dialogue screen.OrnamentLayout_TextToPath

Zip file:
Nuts bigger than 10000000 bytes

5 Likes

I stopped reading after Lego Club!!! :star_struck:

Edit - Sorry I’m not of help

1 Like

That link isn’t working for me.

The SVG image or the ZIP file?

1 Like

Nm, I got it now.

This is what I see when I open it. I’m trying to figure out the weird grouping of the text nodes.
The bottom pic is the wireframe view.

?

2 Likes

My first suggestion would be to eliminate the empty space around your image.

Oddly enough, when I tell the GF :glowforge: to ignore the engrave (of the picture), it is have with the text engrave and cut.

When I only select the picture engrave, that is where I get the generic error message.

A little history, the original job has 4 row of images (each show its own engrave listing in the left column), but I can only load 2 rows without the Uploading Design dialog just disappearing (without any warning) with rows 3 and/or 4 selected.

The top row had to be inverted (to not cut off the hanger tab), but none of it will print (individually or in any size group) and I get the generic error page when printing the inverted (rotated 180 degrees in Inkscape) top row.

I am suspect that Inkscape is doing something with the image (either the inverted ones) or taking the bottom two rows, exported to PNG, opened new in Inkscape, bringing in the PNG and then placing the text and cut components into place. The text is ignored until the cut is done and I manually flip each item over (in their cut holes) and then tell the GF to ignore the image engrave and cut (thus placing the text on the back of the ornament).

When I open your file in Inkscape I see the images, but I cannot grab them in any way. The images layer is acting like it is empty. Combined with your second message, me thinks this is where the source of your troubles lies.

Not sure what you might be referring to. If it refers to the space above, that can be doable. Just created a workspace that is 11x19 to fit within the laserable area for maximum ornaments (22) per piece of raw material.

The space above is so that after doing the first 11, I rotate the material to produce the next 11. It is more for getting a visual alignment (plus magent space to keep the material flat).

Does anyone get the same generic error when tring to get to the Printing box (with the time estimate)?

What I am seeing is that the SVG upload only has one side, the “EST. 1924”, and is missing the depot image.
the zipped file has both sides.

Side one + cut wants to take 25 minutes

Side two errors out.
One version of the engrave for side two wants to take 13 minutes.

Hmmmm… It is weird that the Glowforge sees it as an engrave area.

I did a select all and deleted the cut and text engrave (above one of the images). Once I could click on the image, the entire 11x19 page was highlighted. I will try cropping the above white area out to see if that helps.

Last night I had a file that the GFUI insisted had duplicate images in it. Inkscape swore there was only one set. I set the duplicates to ignore and went ahead as I don’t ever plan on cutting that file again so I don’t know what went wrong there.

1 Like

That is where I am trying to treat all 11 images as a single engrave to make use of an entire left-right and right-left pass to lower the aggregated print time because the laser would skip the white spaces and continue the movement without doing each area 11 separate times.

I know that @PrintToLaser made a bunch of tokens (per page), but I am hoping to lower the time down to less than 2 hours and 20 minutes per 11 ornaments. The train depot has asked for at least 75

I am looking at the file and the first thing I noticed is the ellipses, aka the cutout holes, are not converted to curves for the glowforge to recognize as cuts.

Edit. You might also just have too many because each one is pretty complicated in itself.

Will correct that (for cleanliness), but that part cuts without issue.

As @jbv has notice, there is something strange with the image. I corrected the attached SVG (to be visible), but that is when I noticed no picture (but the Glowforge does see it :face_with_raised_eyebrow: )

Did you just copy that single unit and paste info a new document? Or did you additional transformation steps that you needed to do before uploading? Also, is it an SVG you up loaded or strictly an image?

Playing with it more and that single image for all of them might be making the glowforge choke.
Maybe do a single ornament, unless you did that already, and if that prints copy/paste from the original and repeat.
When I was doing some coasters last week it would only do 4 at a time, doing 6 made it cry.

1 Like

Yes, that is what I mean. I’m wondering if the whole large image bug thing might include the empty space somehow. This is outline view.

1 Like

That’s what happened to me last weekend. I could get 84 (I think) coins/tokens on a page in the SVG but the GF would only do 21 when I finally got it working (delete half, try, error, delete half of what’s left, try, error :slightly_smiling_face: ). It took 10 minutes to render 21 and forever to render & error the 42 & 84 count versions.

I ended up doing one and then extrapolating how long it would take for the full & half sheets and came out at way more than 3 hrs (the quarter sheet was 2 hours 10 minutes). But even more than 21 but trying to add just another half dozen did not reliably work - when it did it fit within 3 hrs but other attempts and it errored out. 21 it would do reliably so even the 3hr runtime heuristic can be incorrect.

2 Likes