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.
@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
@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.
@dan , I think you mean pause then continue.
Restart would suck…
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.
I know right!
Let me dethaw my previous statement: it will pause and then restart its continuation.
Hope that’s clear now.
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.
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