No idea but remember this was designed more than two years ago so 1GB wasn’t as cheap then. Also the concept was to use a cheap controller and do the work in the cloud so it could be quite a small micro.
It really shouldn’t be hard to send a buffer, run it and then pause while downloading the next next one. But it wasn’t long ago that the machine couldn’t pause for cooling and pausing when you press the button is in the hopper.
Just curious if anyone would post an image of what you guys are trying to do that takes so long?
Not your actual file, just wanna see what wild things are taking so long.
Thank you for the feedback. I’ve passed on the request for grouping engraves.
Would you mind sharing one of the relatively simple files that you’re having trouble with, either here or at support@glowforge.com so that we can have a look? Also, it sounds like the error primarily occurs after you hit print, not while uploading. Is that correct?
Is it normal to wait so long for a design to be processed? I’m really surprised to hear people talking about 20 minute waits. Even 5 minutes is hard to imagine.
I don’t know about lasers, but in 3D printing, some models can take that length of time to be processed and sliced.
There are a few cloud-side bugs we’re working on that collectively account for this. The onboard memory can hold about 3 hours worth of printing so that’s unlikely to be your problem.
Thanks for confirming Dan, the conspiracy theories run wild around these parts. 
Proper error messages would avoid the need for theories as to why a particular design won’t render.
Pshh do you know how mature a bit of software has to be before anyone concerns themselves with verbose errors? 
Should be in from the beginning. It makes it much easier to debug and get reports from the field. I have made devices with tiny 8 bit PIC MCUs with better error messages coming out in LED flashes than GF’s cloud produces.
That sounds like fancy city coding, GF coders are in the back with screwdrivers putting machines together. hahaha.
Although 3 hours seems a long time it would be very easy to exceed that with large area engrave at high LPI.
At 340 LPI and a max speed of 335"/min it is going to take about 1 minute per square inch. So you can do 180 square inches so say 18" x 10", which is most of the bed.
If you select 1355 LPI then it would 1/4 of the area so 9"x 5". If you select a lower speed then of course the maximum area gets smaller again. You probably don’t want to do that but it would be nice if the error message said “operation exceeds current 3 hour limit”.
I think best practice is to start with good error reporting :-p Doing so after the is kinda like washing your hands after you eat!
Maybe they have good error reporting on the backend and just use a simple catch with a generic error for the users?
Quite likely but they shouldn’t hide them from the user who is trying to get their design rendered and printed. It just makes for a totally frustrating experience.
Yes that’s correct. I’ve only had one instance where it was on upload.
I came awfully close to 3 hours on one job. 9"x18" engrave.
But, let’s face it, time isn’t the measure of what can fit in memory. I mean, I can run a simple job at a very slow speed and I don’t think that’d fill up memory.
If they store the job as waveforms as Dan has always said then without compression the file would be like a sound wav file. The length would be just the time multiplied by the sample rate. Seeing as he quoted three hours perhaps that is the case.
well now I want to hear what a job sounds like.