I have tried the following:
-restarted the GF,
-relaunched the GFUI
50% of the time I get the super useful “something went wrong” error
and the other half of the time I get no error but the GFUI just closes the prep window as if I didn’t request a print in the first place.
The software has a known bug that has it choking on rasters that are too complex and large for it but this seems to not be that bad as you say so I don’t know.
I would tray converting as much as I can to vectors with fills and see if it responds better.
I have this happen about 50% of the time. For example, I just ran a raster .png and it ran great. Then I tried to run it again and I have been waiting 10 min so far before it scans the material.
As the above has said, large engraves are a problem right now. Doesn’t matter the complexity as much as the size. This one is at least 6"x9". Reducing the number of lines per inch, reducing the size of the image or breaking up the number of coasters and doing maybe a few at a time will allow it to process. The issue has been around for a while but have reasonable confidence that it will be fixed.
Modifying the file like this seems to workaround whatever rabbit hole the GF software is going down. I made it by saving all the images/engrave as a single png and then importing it and sending it to the bottom: Only lets you engrave them all as one step this way though. They’re all separate scores though.
Yeah, that file has a tremendous amount of data in it. I broke apart one of the medallions, and what you have in there is an engrave on top of an engrave in each case.
If you combine the engraves and rasterize them, you’ll have a much quicker load. Currently the interface is treating each of those parts separately, which means it’s going to go in and engrave the grayscale triangles for one medallion, then start over and engrave the lacy overlay, then move on to the next one and do the same thing, then the next, etc. It will take a very long time to do it that way.
If you want to reduce the amount of data for the machine to have to buffer, ungroup everything, group the red cutlines and hide them, select each pair of engraves and combine it into a single raster (engrave) image. Unhide the red cutlines. (When you save the file, remember to Embed the images. )
Then in the GFUI, you will be given six separate engraves, and one set of cutlines. Use Manual settings to set the LPI to 195 on each of the six separate engraves. Set three of the engraves on the same row to Ignore. Also set the Cutlines to Ignore. Print (Engrave) the remaining three active images.
When those are done, without moving anything on the bed or the screen, set them to Ignore, set the other 3 images to engrave, and set the cutlines to cut.
Gradients are a lot of data, and those are a lot of gradients, over a large surface area. Breaking it up will let it load and process faster.
Actually, that one was a lot harder to figure out how to get the interface to take it than I expected. Those gradients must be really high resolution. I tried to combine everything into one raster image first, and couldn’t load it.
This file has 12 bitmap/raster images in it and the GFUI does choke up from time to time if there are a large number of bitmaps in a file that it has to process, even if the bitmaps are not particularly large files.
For every bitmap image within a file, the GFUI creates another operation step.
12 individual engrave operations means the motion control program is getting longer, time-wise, and currently there is roughly a 3 hour time/buffer limit for jobs. The way this file is setup might be pushing that limit. That’s why the recommendations have been to lower the LPI setting, because that is less time needed in the buffer.
Each medallion has two bitmap images. If you turn each of those into one bitmap instead, you instantly cut your project time (and data buffer) in half. Plus it greatly simplifies file setup in the GFUI.
If you’re working at 600dpi resolution within AI to create the bitmap, yes that’s going to get out of hand in a hurry with a 5700x3900 pixel image. New computers don’t have an issue with that but the GFUI doesnt like really big bitmaps for sure.
Not sure what the original images were, I only saved them as 300 dpi when I combined the images, so that might be something I should have mentioned. Thanks!
The original bitmaps were 1188x1188 pixels per each medallion or roughly 400dpi based on their overall size, so not too bad really, but will compound quickly with 12 of them in the file. I would target 300dpi too, as a way to maintain decent resolution without having an excessive amount.
24-bit RGB files of identical pixel sizes will be exactly the same file size regardless of numbers of colors because every pixel contains 24 bits of color info. That means an 1188x1188 pixel image is 4.2MB in size in a non-compressed format.
I’m back working again so time is split. The car is priority but I’m not getting as much done as I’d like simply because right now there is a lot of tiny details to work through for legalization. I havent lasered much at all but what I have done has been stuff for the car, like the corner reflectors and a layout jig for making aluminum bus bars for electrical systems.
An alternative is to set it up as @jules notes but with only one coaster. You’ll have one operation thumbnail for the engrave and another for the cut. Then in the GFUI select all (Ctrl+A) and copy/paste. Slide the copy to the right. Do it again. Give it a shot. After the first half run, select all again and just arrow keys them upwards. There’s your next three.
This way you only have to specify the settings once, not once for each coaster.
I wonder how much extra time it takes to engrave 6 individually vs. all at once. Presumably most of the difference would come from the acceleration and deceleration near the edges, but there’s going to be a lot of that. My Glowforge is off, or I’d try an experiment: 6 plain circles ought to do, since engrave time is based on the limits and not the content.
It’s been a little while since I’ve seen any replies on this thread so I’m going to close it. If you still need help with this please either start a new thread or email support@glowforge.com.
New computers don’t have an issue with that but the GFUI doesnt like really big bitmaps for sure.