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
@ihermit2, @takitus, this is why I’d like to see more information on what the internal buffer can hold - to determine if it’s something I can work with (or around) so I don’t have to babysit a paused print job while waiting for the WAN connection to restore. Every once in a while (remember Murphy’s Law), I can experience hours of downtime, and can’t walk away from the system until it’s done cutting.
I can just wait (that’s yet another thread!) and figure it out once the machine arrives, but I’d appreciate being able to start thinking now about what sort of jobs fit or don’t fit in the buffer.
Well unfortunately I cant be of much help there, but definitely understand your want to be prepared! Theyve laid out everything about the way the machine works and the role the cloud processing plays in it, but no numbers really. You could probably grab some motor waveforms that have been generated elsewhere and compress those down using standard compression methods to get an idea on filesize, but that wont do much good unless you know how big the internal memory is, and how they handle their jobs. They could chunk them to keep as much information stored in memory as compressed as possible, and only uncompress them when it gets to that part of the job. As I mentioned before a vector cut is going to take up a lot less space than a raster cut, so if you were to get an answer to that question or more than likely would have to be a list of sample jobs detailing which parts of the jobs were what size so you could get an idea of whats going on. I dont really think they are going to be able to provide an accurate estimate until they get everything nailed down for production, and even then I bet there will still be a lot of optimizations made once they are able to start gathering mass data and feedback.
1 Like
I’m not so much trying to get an accurate estimate, as just any kind of estimate at all. I’ve been struggling with ambiguous language like “most projects fit in the buffer” - that worries me, because flash memory is so cheap (for example, 16GB microSD cards are under $5 now) that I don’t follow why pause and resume during data connection loss is even being discussed.