I seem to be having the same “stuck on centering” problem that everyone else has.
In my case, I did one acrylic cut and it worked fine. I removed the acrylic and I got the dreaded “Scanning”. I’ve found that we when that happens, I just need to open the lid mid-way about 5 seconds. Then I close the list and it scans.
This time? Nothing.
I power-cycled the GF, and that’s when it focuses, but then hangs on centering. The head doesn’t move at all. It clicks during focusing, but doesn’t move during centering.
Things I’ve tried:
I powered off the network (modem, router, and GF), waited a minute, then powered it on.
Reset the network connection twice. (Hold down until the light turns green, select wifi, etc.)
I checked the network signal. Nice and strong. The wifi router reports that the GF has 4 (out of 5) bars.
If I open the lid, the web-based UI immediately says “lid open”.
If I close the lid, then it goes back to “centering”.
Can GF check the logs and see what is going on?
Since the router is working and the lid generates network traffic (e.g. lid open) immediately, I don’t think it’s a hardware/cable problem.
I’ve been seeing an increasing number of people reporting issues with stuck on centering and stuck on scanning. Does GF have a networking issue on the server side? If not, how do I fix this on my side?
After 44 minutes of being off, I turned it on and nothing (stuck on centering).
Off, moved the head manually.
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.
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).
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.
If this is your main contact with staff, instead of sending them an email - post here but:
Run the test
Mac: Open Finder/Applications/Utilities/Terminal, then type the following command, and press the return key: ping -c 50 app.glowforge.com
Windows: Open the Windows Run dialog box by pressing the Windows key + R
In the dialog box, type “cmd”, then “Run” or “OK”
Type the following command, then press the return key:ping -n 50 app.glowforge.com
Allow the test to finish. When it is complete you will see results under a “ping statistics” header.
Take a screenshot of the results
Mac: Press Shift-Command-4 and click and drag a box around your image. You’ll find the screenshot file saved on your desktop.
Windows: Click on the Start Menu and type “snipping tool”. Open the Snipping Tool > New then click and drag a box around your image. Click the Save icon and name and save your file.
Reply to this email with the following:
The file you saved in Step 3.
A description of what’s happening, what you’ve tried, and what results you’ve seen so far.
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.
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.
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
— 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?
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.
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.