I am having some WiFi issue. I just started a 2 hour print. If the WiFi goes down, will it finish the print? Is it downloaded to the GF in its entirety? Thanks.
Yup, it’s supposed to run once the job is downloaded and you lose your connection.
I’ve not ever had to test this though…
3 Likes
I’ve had the Wifi go down during a print (we’ve had a lot of construction around here and they keep screwing up the lines)…no impact on the print.
3 Likes
This is fantastic news! But hopefully, the wifi issues I’ve been having will soon be fixed with the Google Wifi. @jonnyvermont Sorry you’re having wifi issues.
1 Like
At this point in S/W development the motion plan (kind of like a print buffer) is loaded one time and the print will continue once started, independent of wifi, as long as there is not a failure at some point. For example, power failure. The buffer is big enough for a 3+ hour print.
There were early plans to reload that buffer for very, very long prints as necessary. If and when this capability is enabled it would require wifi to be reestablished to reload.
2 Likes
A better plan would be to simply compress it. It has so little entropy ZIP compresses the ruler by a factor of 27. Most of the file is do nothing for 100us. There are 8 ways that is encoded depending on the state of the direction bits. Making all of those NOPs be zero would make it compress even more.
It is trivial to implement because there are open source ZIP libraries. I don’t know why they don’t have a programmer spend a day instead of telling people sorry you have to split your design into separate operations for more than a year.
It stands to reason it will compress massively because it contains no more information that the original SVG plus the material properties apart from perhaps some randomness in the dithering.
3 Likes
It may take a little longer than a day but this what we all used to do in the old days when memory on PCs was tiny. Keep the code partition loaded and keep moving data into the data partition as needed. Not much different than how some CNC machine bring in Gcode even now.
But this would require WIFI to be up as you don’t have any other local storage. Each reload will have to bring it from the cloud.
But why go to that complication? They have a ~128 MB buffer that gives a little over 3.5 hours. If they compressed the file 27 times it could run for nearly four days.
1 Like
So you are thinking compress it on the way down and dynamically decompress it as they consume it?
Yes, the ARM CPU in the GF easily has enough power to decompress it on the fly.
The device has a 4GB MMC flash, with around 3.5GB of free storage available on the non-volatile storage partition.
Plenty of local storage…
3 Likes
Dang I did not realize that. Where are you seeing the specs?.
So I wonder why the size limitation…
Fruit of many hours peering into the recesses of the Glowforge.
It appears that they currently store the stepper ‘waveforms’ in RAM, rather than non-volatile storage. Last time I measured, there was only around 100MB* of free RAM (of 512MB total).
The ‘waveforms’ require 10,000 bytes per second. That gives a rough number of about 166 minutes (or 174, if you use 1024^2 for a megabyte).
*It may be a bit more in practice, as my console session ate up some of the available RAM.
5 Likes