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.
So, here’s what the problem isn’t:
- My file
- My local or outbound network
- app.glowforge.com’s inbound connectivity
- The server-side GFUI software, unless they’re A/B testing multiple different truly stanky builds over 75% of their web nodes.
If all that’s correct, all that’s left is GF’s server capacity and internal network. Hence my question.