Like several other folks, I’ve been fighting all afternoon with the GFUI getting stuck at various steps of the setup and print process.
This smells like a capacity issue. Is it? If so, can we get info on the nature of the problem so that we can modify our own behavior for better outcomes?
I know it’s not a file issue because it has happened when I was trying to print the same two-node line twice in a row without opening the lid or reloading the file. The file had already printed once. I don’t have reason to believe it’s my own network or ISP, since I am on the same wifi as my GF and have good outbound connectivity.
Over several reboots and print attempts, the UI has gotten stuck at many different points:
Refreshing bed image, either automatically or via the cog menu
“Scanning” in main UI (even when nothing has happened that should trigger a refresh)
Attempting to start calibration (an error message requests a reboot)
Calibrating (the word “calibrating” appears in upper right)
Scanning your Material (in print popup)
Sometimes it recovers and I get to print something … mostly, it just sits there. Sometimes the head moves as you’d expect, sometimes it does nothing. It’s utterly inconsistent. If this was a GFUI software issue, I’d expect problems to be somewhat reproducible.
Pings to app.glowforge.com are consistent with very few dropped packets. On the assumption that any supporting GFUI services are located on the same network, I haven’t bothered to pick apart the traffic more than that.
How did you try the repeat? If you hit the print button too quickly after the previous job finishes it will hang.
Print, get the job finished and cooldown prompts. Wait for the cooldown status in the upper right change to Ready. Wait 30 seconds - the button on the GF should flash once. Now you can hit the Print button for the next job & it shouldn’t hang.
I don’t recall the timing in detail, because I didn’t understand that there was an ongoing issue until I attempted the reprint. But IIRC, the print button was never enabled again after the first print. It went something like:
During cooldown, drag the artwork into new position.
While I moved the artwork, GFUI decided it wanted a new bed image.
Bed image was never refreshed; print button in UI was never enabled
In the ensuing 2 hours, I re-uploaded the art, rebooted the machine 2 or 3 times, and watched a heck of a lot of stuck status messages. Then, after 9pm ET, I had a print go through almost completely normally.
I had a bunch of issues last night - stopping in the middle of a job that caused me to do a cancel (via another session) a couple of times, once kicked me all the way out in between jobs and a few calibrating/scanning delays (that resolved in a few minutes). It wasn’t a smooth night - I finally went to bed around 11:30 EST about 2/3rds of the way through the project (I’m doing 3 dozen flat pack Christmas trees for my wife’s faculty lunch at school this week). Hoping to finish up tonight.
The stops were ones where it just froze in place but at least stopped lasing. The motors and exhaust were still running so I didn’t notice that it was frozen (these were 1 hr jobs). I’ve had the Redsail freeze like that once in awhile but it would continue to lase creating a big hole - at least the GF stopped burning.
stopping in the middle of a job that caused me to do a cancel
Man, now I’m almost grateful that I simply couldn’t even get it to start.
I would think cut instructions should be sent from the site to the machine as a discrete and relatively small file, even for a 1-hour job. I’m speaking from a position of total ignorance, but why on earth should the machine try to phone home in the middle of a job, on pain of failure??? That’s how you get an expensive pile of ruined materials.(Another poster says it does not phone home mid-print.)
3 dozen flat pack Christmas trees for my wife’s faculty lunch
Which is exactly the kind of thing that everybody’s probably doing, starting right after Thanksgiving. And – similar to “why is it phoning home mid-job” – you’d think “repeat same pattern in same position” shouldn’t require a completely new transaction with the GFUI backend.
I’ve had the Redsail freeze like that once in awhile but it would continue to lase creating a big hole
Hooooooly cow, no pun intended. That is not a desirable failure mode!
Could be cooling issue (not likely) or it could be a hiccup in the downloaded file (maybe) or it’s just GF magic
The file was an engrave (Merry Christmas message), a bunch of ornaments being cut from the tree shape, the slots (4 slots in 3 pieces of the tree), 3 tree shapes and then an outer box for the flat-pack (in that order).
It almost always died on either the tree shape cutouts or the final box that surrounds the whole thing. So it would be 20-30 minutes into the job when it stopped. After killing the job that hung I would turn off everything but the cuts that hadn’t made it and hit the Print again. Usually that was fine (once it stopped in the trees and then again after doing one of the 4 final outline cuts).
It is very easy actually. I tried zipping a puls waveform file for the ruler and because it is so repetitive it compressed by a factor of 27! So the buffer is big enough for about 81 hours if they simple use a Zip library and there are several open source ones.
Very astute - in fact it was a capacity issue… and I was suffering along with you as it took my kids forever to print a sign for their school project.
This weekend, we saw our highest number of active users ever - more than 30% higher than ever before. That revealed a shortcoming in our ability to scale up rapidly, and another shortcoming in our alerting that failed to notify us of the problem.
Our apologies - we put a short-term fix in place now, and are working on a permanent fix for the long term.