After 44 minutes of being off, I turned it on and nothing (stuck on centering).
Off, moved the head manually.
On, nothing.
Off, moved the head again.
On: Head moved up to the camera line, the head did not swing over to the camera.
I’m really convincing myself that it isn’t a hardware issue. I think it’s a network issue near the GF servers. And with so many people making stuff for the holidays, I was lucky enough to get a packet in.
There are no issues on the GF status page…
You’ve been around enough to know everything to check. The only thing I can suggest is to try powering on with the lid open, then closing when you get the Lid Open message.
Good suggestion. Just tried that. Focusing, clicks, arm moves to the camera line, but head doesn’t move. Back fan spins up fine. Tiny fan in the head is clean as a whistle. And sliding the head and arm without any power is really smooth.
I don’t think it’s a dust issue (photos attached).
Just tried the “power on with lid open” experiment a second time. No movement at all. (Clicks, fan, but no head movement.)
Lid-open experiment #4: Hey! both the arm and head moved! It almost got under the camera (a little off center). Normally it scans, re-adjusts, and finishes centering. But it’s just hanging before the final “move the head a little more” adjustment.
As a long-time computer networking person, it really looks like someone is dropping critical packets. Does GF use TCP or UDP? (I haven’t hooked up a sniffer to check.) If it’s UDP, that would really explain this.
The status.glowforge.com page will only list outages, not dropped packets.
I’ll try again this evening, after most of the day-laser crowd goes to sleep. If that causes it to work, then it’s a server overload issue.
It will also only list what they publish to it. I believe the statuses are manually updated by humans.
If this is your main contact with staff, instead of sending them an email - post here but:
Besides the cleaning, checking the 5 ribbon cable connections, moving the head, power-on with lid open, and multiple reboots… I also tried 2 other access points. I configured one that was the only AP on it’s channel and physically located less than 5 feet from the GF. I measured -37dB at the GF and the wifi AP measured full strength from the GF. So it does not appear to be a wifi issue.
And since (1) it cut once right before these problems and stopped immediately after, and (2) twice with the “power on with lid open” test, the head moved, I don’t think it is a hardware issue.
I suspect that it might be related to the Dec 3rd firmware update that was explicitly related to connectivity. https://glowforge.com/latest-improvements/improving-connectivity-and-planned-downtime In particular, the GF did the “just got an update” fan hiccup earlier today. But they should be able to check that in the logs.
So not packet loss…
Minor correct to your statement: not packet loss on my end. Does GF use UDP and if so, could it be packet drops at the server? (If it’s only TCP, then this wouldn’t be it.)
No idea, but that’s never come up as an issue in the last ~3 years, so I’m guessing it’s not.
Pretty sure it’s all HTTP (websockets).
I mean, you could have discovered some obscure server-side issue that’s somehow affecting only your machine, but Occam’s razor suggests otherwise.
Another update: 2019-12-08 @ 8:46 AM (Mountain).
Turned it on and it almost immediately did the “received an update” hiccup. After a few minutes, I power cycled it with the lid open. After a few minutes, I was about to power cycle it again when it moved the arm to the camera line.
After another minute (while I’m writing this), the head moved under the camera. I’ve never seen centering take minutes between steps.
I’m just going to leave it on. If it finishes centering or powers itself down, then I’ll update.
26 minutes later: Hey! It finished centering! (There’s a problem if it takes this long.) Just told it to manually focus on the material in the bed. Head moved immediately to the correct location, but now it’s just hanging.
10 minutes later: it just moved the head back to home (far left corner). But it still says Focusing.
Another 10 minutes and it is “Ready”. I hit “Print” and it is just as fast as usual. Engrave, score, and cut look fine.
Well, that’s weird. The GF finished the final cut and returned home. Yet the web UI still says it has 2 minutes to go and it’s still counting down.
Retried it again this morning.
8:57 - power on, focusing, centering
9:03 - powered itself into the low-power sleep mode
9:10 - restarted with lid open, when it reported “lid open”, I closed the lid. focusing, centering
9:11 - arm moved
9:12 - head moved under camera, but did not align with the “G” symbol
9:16 - head moved “G” under camera
9:21 - head moved to left, still “Centering”
9:27 - refreshed web up; now it says “Homing” (before refresh, it said “Centering”). Not sure why the web UI didn’t refresh.
9:29 - GF entered power-save mode, head still at camera line but on left.
9:50 - No movement on the GF, but just noticed that the UI switched to “Scanning”.
9:58 - restarted
10:21 - head hasn’t moved since last restart
Still haven’t heard from Support.
Meanwhile, I just retried the ping test.
Ping to app.glowforge.com works fine. Fast, no packet loss.
Out of curiosity, I decided to ping the GF on the local network:
$ ping 192.168.1.201
PING 192.168.1.201 (192.168.1.201): 56 data bytes
64 bytes from 192.168.1.201: icmp_seq=0 ttl=64 time=70.938 ms
64 bytes from 192.168.1.201: icmp_seq=1 ttl=64 time=30.809 ms
64 bytes from 192.168.1.201: icmp_seq=2 ttl=64 time=27.870 ms
64 bytes from 192.168.1.201: icmp_seq=3 ttl=64 time=43.063 ms
64 bytes from 192.168.1.201: icmp_seq=4 ttl=64 time=4.182 ms
64 bytes from 192.168.1.201: icmp_seq=5 ttl=64 time=241.079 ms
64 bytes from 192.168.1.201: icmp_seq=6 ttl=64 time=92.158 ms
64 bytes from 192.168.1.201: icmp_seq=7 ttl=64 time=108.783 ms
64 bytes from 192.168.1.201: icmp_seq=8 ttl=64 time=123.143 ms
64 bytes from 192.168.1.201: icmp_seq=9 ttl=64 time=6.916 ms
64 bytes from 192.168.1.201: icmp_seq=10 ttl=64 time=99.031 ms
64 bytes from 192.168.1.201: icmp_seq=11 ttl=64 time=50.747 ms
64 bytes from 192.168.1.201: icmp_seq=12 ttl=64 time=110.118 ms
64 bytes from 192.168.1.201: icmp_seq=13 ttl=64 time=10.233 ms
64 bytes from 192.168.1.201: icmp_seq=14 ttl=64 time=13.137 ms
^C
— 192.168.1.201 ping statistics —
15 packets transmitted, 15 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 4.182/68.814/241.079/61.125 ms
No packet loss, but that’s a HUGE amount of variation for a system on the local network. Pinging other systems on the same wifi have a consistent return time of 4-16ms. I don’t know why the GF is so inconsistent.
Can someone ping their own GF and see whether slow and variable time is expected or odd?
ping another machine on your network and see if you see the same variation. It could just be network congestion if something else is active.
Hi @kanati,
Tried that. I pinged 4 other devices on the same wifi ap. Very little variation: 4-16sm.
Does your GF have the same wide variation?
Add: The other systems are effectively idle right now. And the logs on the wifi ap say that nothing else is reaching out to the internet.
Update: Just tried my tablet. It’s consistently 100-150ms when in sleep mode, and 2ms to 400ms when active. So maybe variability is the GF’s active state.
I do see quite a bit of variation in the pings from the GF… But I also have some variation on another device despite having sub 1ms pings on another… I would have to guess without further information that it’s normal.
Support seems to be asking people to check the ribbon cables. (But they haven’t asked me yet.) Attached are my photos.
This may sound dumb, but I have found that refreshing the browser solves the issue with being stuck on “Scanning”. I had already rebooted the GF and tried all sorts of power cycling, lid open/close, etc. to no avail. After refreshing the browser, it showed “Ready”. I haven’t had a recent stuck on “Centering” to test whether this works.
Hi @lazurin,
I’ve tried logging out, flushing the browser (cache and cookies), restarting the computer, logging back in, with no success. I even tried these individually: logout/in, restart browser, flush cache, etc.
It’s a good suggestion, but not having any impact here.
