Just curious… Does anyone know how the handshaking takes place between the GFUI and GF, once cutting has started? I’ve noticed that the countdown timer isn’t always accurate if the glow Forge is paused and then restarted.
As i understand it the gfui sends the file then everything is controlled by the machine except the remote cancel from the browser would give a stop command.
So the countdown timer is not synchronized with the at all, gf during the cut?
I don’t think so. i’ve never had mine be off like you are saying tho. I remember it being discussed in the forum before but cant recall what came from that conversation.
I may be wrong but it goes from gfui to cloud for process to machine and then they don’t talk unless there is an issue like the machine overheats or some other error.
Thanks. Over on the Facebook group someone said their GFUI said the job was finished but it was still cutting. They had used the pause button. It reminded me that had happened to me once too. But It’s hard to imagine there isn’t some kind of update being sent back to the client, otherwise on long print jobs ( and especially if pause is used).the GFUI timer could would be way off.
I wonder if when it was paused the internet connection was weak and it wasnt able to send the fact the job was paused back to the gfui. That would throw the time off
Just for fun I think I might try monitoring the connection & see what happens once the gf starts up.
for sure. One thing to watch out for is you might see a good connection on your router end but that wont tell you the signal strength that the glowforge has back to the router as it broadcasts. a lot of issues stem from there. one way to kinda check if that is the problem for people who are having symptoms of a bad connection is to use their phone or tablet as a personal hotspot and connect to their forge.
Yes, but I meant actually monitor the tcp communication between the GFUI client and whatever servers it talks to.
1 Like
Ah yes i understand, my bad for assuming.
1 Like
This is fairly well known as a concept. The timer is just a dumb javascript, it predates the hardware pause and has never been updated.
Things like this have come up before:
Tbh I never get cooling or overheating errors so I have no idea if this was ever updated in those cases, but it doesn’t surprise me to hear the pause button causes the timer to be out of sync.
1 Like
In case anyone is interested (probably only a few nerds like me) I did run a couple of experiments while monitoring the network traffic between the GFUI and the GF server(s). It turns out that there is communication between the GFUI and the server during printing. Messages contain among other things, the remaining print duration and current status (printing, user_paused, canceled, waiting, etc). This appears to be “read only”, i.e. the server doesn’t ask for anything back. I assume this is what is used to update the GFUI.
Under ordinary circumstances, the time remaining timer on the UI should be accurate. Not sure why sometimes pressing pause at the GF causes that to be incorrect, since the instant the pause button is pressed a message is sent to the GF client, and when it is pressed again to resume, another message is sent with the updated time remaining. For what it’s worth…
3 Likes
Awesome. Got logs of the traffic for the technical peeps on the forum? I’d be curious to see what the data looks like.
I didn’t capture any, but I can run it again. I saw two primary messages, both JSON format. At the beginning of the session a message is sent to the server with a bunch of information such as locations of bed images (stored on google servers), coordinates of objects, user info, All kinds of interesting stuff. The status messages include the stuff I mentioned in my last post. But next time I get a chance I’ll grab them.
Ah, yeah JSON is a natural choice. Cool.
This topic was automatically closed 32 days after the last reply. New replies are no longer allowed.