Failure to Upload to Glowforge Unit


#1

I did a screencast in case it is helpful in any way to see what was going wrong. As that includes about 4 minutes of absolutely nothing happening, I figured I would not record all subsequent attempts.

After this repeat of my failure (had failed about 5 times previous to me recording to report), I tried uploading the puzzle without the image: That worked fine, got a 30 minute approximation.

I then tried once again with just the image engrave enabled (all other steps ignored). This I had tried before, but I figured it was worth another attempt, as the entire project is not worth doing if I cannot get the image in place.

This time it DID upload and allow me to start cutting/engraving it. Only 40 minutes too, which should have tipped me off to the problem. I left it set up with 1,000 for speed. What I really want to do, and had done in the above recording, was 200 speed.

I having the 1,000 speed engrave running right now, and it looks dark enough I may stick with what I get instead of running a second pass, not sure. I will update this post with another attempt to upload the 200 speed engrave.

Best guess for why it wasn’t uploading would be that the time required was too large maybe? If it needs 40 minutes at 1,000 speed, then it should have wanted nearly 4 hours at 200 speed. Is there a limitation on total time per individual job?


#3

You can probably process that in steps.

It all loaded, so set everything but that large engrave to Ignore, process the engrave, then without touching anything on the bed or the artboard, set the completed engrave to Ignore and process all of the other steps.

As long as you do not move anything, it will come out exactly as you have laid it out, even if it looks like things are out of whack after the first engrave.

The total file size might be too large. Doing it in pieces can help if it is a borderline case.

(And I doubt very seriously that you want to use a 200 speed on an engrave. It would cut almost completely through the material. For a dark engrave, I pick a speed at or above 600. Don’t worry, it will be dark enough.)


#4

I’m getting pretty concerned about the number of times that ‘do things in pieces’ seems to be the answer to something being ‘too big’. I really hope this is not an ongoing issue. An advantage of the cloud based software is supposed to be more processing power, not less than my local workstation.


#5

Who or what removed (blanked) the number reference after “speed at or above” ?
It is there but fuzzed out. Eyebrow raiser…


#6

Jules did. try clicking on it.


#7

It’s more of a combination of things consisting of PPI, LPI, number of movements the machine has to make, and probably other things that I haven’t figured out yet.

The ultimate result is the size of the file that gets sent back down to the machine to tell it how to move. There might be a limitation on that, but since it could be any one of a number of things that push it over the top, you can’t always pinpoint what is causing it.

The easiest thing is to try to take the processing in steps. If that doesn’t cut it, for instance if you have an engrave that is physically too large, then you might either reduce the LPI, or you might need to cut it up into parts, etc.

The good news is, once you understand the requirements, you rarely hit the problem. About 90% of the issues you’re seeing here are due to first timers just getting acquainted with how to design files for it.

There are some tutorials written up in the Glowforge Tips and Tricks section here that might help if anyone is interested. :slightly_smiling_face:

Or one of the best places to Troubleshoot is to read the Troubleshooting section in the Support button of the interface. (You won’t get access to that until you take your machines, but it really does explain things very nicely. I wonder if the folks who have received their machines are aware of it.) :grinning:


#8

Oh, I did that myself. :smile: We’re not supposed to post our private settings here. Eventually this will probably get shifted to Beyond the Manual, but I figured Jacob wanted to let Support take a look at it first. (Or /i can delete the settings, whichever they prefer.)


#9

All of your feedback and advice is extraordinarily generous and helpful as usual.

This is really directed at :glowforge:, but we should not need to ‘design for it’. And we certainly should not need to do things like reduce LPI because of constraints in the software pipeline. I don’t recall ever encountering such constraints using an Epilog and their terrible Windows printer driver - it would simply take longer to process and print.

What’s scary is that we may be limited in using the full physical ability of the machine because of external software restrictions. At least without difficult to repeat manual babysitting steps.

As a baseline, I am reviewing images I engraved with the Epilog and the very smallest one is 8.8MB and the largest is 18MB. I would expect to be able to engrave these at the full bed size at max LPI without needing to do any chunking. My subject impression (I have a day 2 pro order…) is that this would currently be a problem.


#10

Yeah, I do plenty of jobs in stages. I just want to know the precise limit which I am needing to work around. Is it the total time? That is a random guess.

Your own posit of a random guess was file size to the machine, but I didn’t change the LPI, so the total file size to the machine wouldn’t change by changing the speed. So if I had made the same guess, I would have tried something else, like splitting the graphic into two parts, which I position in the file beside one another and do in different print orders.

Maybe if I had tried to upload the full job this time it would have worked fine, because the issue is something server side instead of job related…


#11

Eventually we might not have to. I expect it now though because the software is still being tweaked. :slightly_smiling_face:

I’ve seen the letter they send when they ask you if you are ready for your machine. In it, they give you the option to defer receipt until these little issues are resolved. Frankly, if I were a complete newbie to design, I would probably wait a while. If you are not a newbie to design though, there are ways to make it do everything you want it to, right now, and I just got through testing the file splitting last night - it works fine with no discernible difference that I can see.

But i do expect it to improve after they have the bulk of the units shipped out. There’s always a number of little bugs at a startup. They just need enough time to catch their breath and they can resume stomping. :grinning:


#12

LOL, wait a while for little issues. :roll_eyes: You get two options. To wait for the air filter to be ready or wait for the software to come out of beta. Who knows when that will be. You can’t opt to “wait a while.”


#13

Oh no need to fret about that any more…there are several additional options for delay being offered in the new letter. I’m sure you’ll be tickled pink when you see it.

It addresses all of your recently posted concerns quite well. :slightly_smiling_face:


#14

like what?


#15

Among others, cosmetic issues and waiting on delivery for some of the recent software tweaks to be finished. (The 1/4" alignment issues for instance, not just the ones for the passthrough.)

Sorry, but I don’t remember any of the others, and those are the only ones I remember now because of the rather phenomenal amount of concern over them lately. :slightly_smiling_face:


#16

Did they offer any rough timeline for how long those tweaks will take?


#17

Watching the screencast was like watching one of those videos of a bricked Muse.

Is the progress bar completed the entire time you wait for the error message? It seems that was an optimistic estimate on completion.

It should “Barber Pole” if the length of time is indeterminate. I actually had to check the timeline on the video a few times to see if the video had frozen.


#18

Not that I recall seeing. And i wouldn’t have expected them to. That would be asking them to foretell the future again, and too many people would probably get really upset if they missed the dates again, KWIM? :wink:


#19

If GF actually send low level motor pulse lengths it might because the acceleration and deceleration ramps get longer and constant speed plateaus get shorter. If the constant bit is expressed as a repeat then file size would go up.

How do I know this? I designed and coded gaming machines with stepper driver reels and my own 3D printers. They all involve a motor motion plan being transmitted over RS385 serial, Ethernet or USB and it does get longer for higher speeds.


#20

Also simply using a variable length encoding scheme like Huffman encoding for compression can yield larger files for bigger numbers.


#21

Honestly never noticed the progress bar. Only yesterday did I finally notice it during a cut (have a timer countdown, so never thought to look for a progress bar as well).

Doh! I was thinking in G-Code again, not Wavelengths or whatever it was that the Glowforge actually does use. So, yes, if there are real-time constant inputs, then filesize would change with job length. Thus jobtime would be exactly proportional to filesize.