Blocks coded with md5 checksum maybe.
Hopefully this is the right thread to post this question on, or someone will guide me to a closer match.
How will the GF respond to fits and starts in the connection to the server? And Iām talking minutes, not milliseconds - Iāve been known to have to power-cycle my router to resolve throughput issues. So hopefully the GF can stop indefinitely and resume without having to throw out what could be expensive material being cut, like engraving the case of a $2K laptop.
Layer 7, since the info is going to the google cloud, then back down to your GF.
For the most part, your entire job will be downloaded to the buffer, unless it is large and complex. If it does stop due to internet connection, it will wait until it gets reestablished and download the next part into the buffer and start up again. I wouldnāt recommend moving the part if this happens, just in case it doesnāt realign after lost connection.
1 Like
@joe, can you point me to the technical discourse on how the GFās cloud interaction works - has GF published this, or do you have inside information on the control system architecture?
In this video dan discusses at some length the basics of the Cloud interaction. Between 7:25 and 13:00 minutes is all about the Glowforge, how it works with the Cloud S/W and S/W update process. https://www.youtube.com/watch?v=PacXfucVWBc
1 Like
@rpegg, thanks, just checked it out.
I suppose it may not have been nailed down yet, but I anticipate that 3D engraving will involve a more data than simple vector cuts, perhaps more than the local buffer can hold - standard engineering answer isā¦ it depends. Knowing when Iāve crossed that line before starting the job would be really handy.
One key point in the video, is the ability to retain previous cloud-based code bases for the GF control, so a particular job can be repeated without the GF behavior shifting around - .
Putting the GF on a UPS supply seems prudent.
I believe I saw something about it in the video @rpegg already provided, and it was stated somewhere in the forum as well. I did a quick search and couldnāt find it. But I didnāt look very hard right now.
I donāt have any inside information on the control system architecture, either. Or do I 
!!! ā¦ No, I donāt.
Thereās a local buffer on the GF for your projects. Most projects fit in the buffer so it can finish if you lose connectivity. If itās a large file and you lose connectivity, it will pause and then restart.
1 Like
Yea. if it restarts, that is a bummer. continue from where it paused or āresume from currentā would be great. I have large format printers at work and restart is a PITA.
@dan just said it wrong. He already said in the past that it will pick up where it left off.
Kind of like when my sister-in-law says I am going to de-thaw this. When I know what she meansā¦
I love ādethawā! That is some intricate meaning behind those words.
1 Like
I know right!
Let me dethaw my previous statement: it will pause and then restart its continuation.
Hope thatās clear now.
4 Likes
Now that is funny.
Dethaw = Freeze?
Imagine a police coming up and say ādethawā (gonna sound like a crow)
k i digress.
Thx for the input. continuation is awesome.
1 Like
Could someone at GF post images of jobs that fit inside the GFās local data buffer? Iām hoping theyāre more complex than key fobs and luggage tags 
If you want that sort of information you should probably also ask how they expect the job to be effected by a pause for the network and resume. I believe their design goal is to make fitting in the buffer vs not irrelevant.
Its going to depend on whether its vector or raster from what I recall. A fairly complex vector print could be much smaller than a small raster print
2 Likes