Uploading DFX regularly gets “too complex” error. SVG is a hit-or-miss and is generally very slow.
I know there had been several forum threads about this already with staff involvement, but I still do not see the option to upload my own g-code in the app.
Allowing g-code would save Glowforge the cloud computing power, too, since basically no computation is needed; and I imagine whatever the cloud service sends to the GF is already some form of instructions similar to g-code.
Simply put, you can’t. Glowforge processing is cloud-based only.
That hasn’t been my experience. Since there’s no option to generate and upload your own g-code, I would recommend figuring out a workflow for reliably producing compatible SVGs instead, and you’ll be golden.
By upload if you mean sending code to the GF unit for processing you can’t. The GF unit doesn’t use a high level code or anything similar. It’s far more simplistic than g-code. More like sending digital waveforms. Telling individual stepper motors to move, sending power levels, etc. The commands don’t tell the unit to move from here to there like g-code does.
If you mean uploading to the cloud then you can’t because all processing of an SVG, DXF or PDF is done in the cloud by proprietary S/W.
Slow is relative, way faster than nothing, If what you have is G-code then there are many conversions I would expect that there would be a lot of info in G-code that would not work on a laser, or be correct for a Glowforge, even if working on a different laser.
But that’s the thing: there is no processing needed for g-code. g-code can be translated almost 1-to-1 to motor control signal, things like “move up 3mm, fire laser at 20% power for 100ms, move left 2mm”, etc.), and can be run by a simple 8-bit microcontroller (I know this because I installed a custom controller in my previous laser and that was an Arduino-based RAMPS.)
That is interesting. I wonder why they do that - putting a powerful CPU running Linux inside the GF and then don’t use it, whereas gcode can be run by most 8-bit microcontrollers.
I wonder if there’s a feature-request page or something I can use for this, since it can’t be that hard for the GF team to implement, since g-code-to-whatever-GF-motor-waveform can’t be that hard to implement.
Well, nobody would want to convert g-code to anything, since it’s the final exported form, commands to send to a laser; converting backward to SVG would make no sense and would generally not work as you would expect. And g-code should work on any laser that use X-Y stepper motors, since it is designed for those. I have used cheap Chinese K40 lasers, expensive Chinese 60W lasers, Epilog lasers, and basically any custom laser control boards out there, and they all accept g-code as the basic format. Higher level formats, like SVG or DXF, are generally not even supported since there would be too much processing needed for a small microcontroller typically installed in those Chinese lasers.
My problem is exactly that: the wait time for uploading and processing of my DXF and SVG files can be minutes, with random failures not known until the end of the upload/wait/process cycle, which slows down prototyping quite a bit.
That is interesting. I wonder why they do that - putting a powerful CPU running Linux inside the GF and then don’t use it, whereas gcode can be run by most 8-bit microcontrollers.
I wonder if there’s a feature-request page or something I can use for this, since it can’t be that hard for the GF team to implement, since g-code-to-whatever-GF-motor-waveform can’t be that hard to implement.
It would be kinda sad if I have to ditch my shiny new GF and go back to my (supposedly more clunky) K40 just because of this…
How long does the actual print take once it’s loaded on the machine? A few minute’s wait for processing for a job that will then take an hour or more to print can’t possibly make a measurable difference in your daily productivity. If it’s taking minutes to process a print that only takes minutes to print, then I could see why you’d be frustrated.
I’ve been using my GF for years now and the cloud processing has never been an issue. And that’s without paying GF their “priority” processing premium.
Also, I’ve never had a SVG rejected by the GF. If you’re getting errors you may want to take a look at what’s generating your SVGs.
Not all of them. The Epilogs I have experience with do not use g-code, they use HP PCL/GL, which is, frankly, bananas. But that’s beside the point… Glowforge definitely doesn’t support it.
You’re not the first person who has requested this, and this thread will soon be closed by GF support with a friendly message that they’ll take note of your suggestion, but I don’t believe there’s any chance of it ever being implemented. Not because I don’t think it’s a good idea. But because my observations from owning a Glowforge purchased on day 0, spending a lot of time on this forum, and building up a pretty good feeling for what the thing is designed to do, lead me to believe that it just isn’t in the cards.
They built a business around processing SVGs in the cloud and sending down opaque instructions to the machine. And they seem to be doing pretty well with it. The list of requests “in the hopper” is miles long, and if I were a betting man, I’d expect what we see over the next year is more premium design tools, not stuff for people who want to run their machines off old-school paper tape. And I say this as someone who desperately wants an ASR-33 teletype for his birthday.
and, FWIW, they’ve been very open and direct about this being “cloud-based and that’s their model” since they launched the crowdfunding in 2015. there’s not much financial incentive for them to generate a whole different way to push code to the GF right now. maybe in a second generation, but i honestly wouldn’t count on it. if cloud-based and uploading vector files (not just SVG or DXF, you can also upload PDFs and copy/paste from illustrator (or even MS office, if you really wanted to)) isn’t the model you want to use, the GF is (and always has been) a bad fit.
I’m guessing (given your mention of DXF and “too complex” errors) that your files contain a lot of separate line segments, particularly to approximate curves. (A lot of CAD software can’t output curves and instead uses thousands of short line segments instead. For example, a bezier curve is often approximated by a POLYLINE in a DXF file.)
The Glowforge software doesn’t handle huge numbers of nodes well. It’s better off dealing with Bezier curves. If you open your DXF file in Inkscape or Illustrator, use the command to simplify paths, and then save as an SVG or PDF you may experience much better performance with the Glowforge software.
@hoangduyud, I’m sorry that you ran into trouble while uploading DXF files. @tim1724 's suggestion that it might be related to the DXF containing a high number of individual line segments and nodes might be correct. If you’d like, I’d be happy to take a look at your DXF file to see if this is the case.
The best way to solve this depends on your design. As tim1724 suggested, you may be able to simplify the design with design software. Inkscape and Adobe Illustrator both have options to simplify strokes. Another option might be to convert the portion of your design which is to be engraved to a bitmap by rasterizing it. Here are two support pages on these topics which might be helpful:
Please let me know if this information helps. Also, if you’d like me to take a look at your DXF, I’ll be happy to do so. You can post it here or, if you’d like to share it privately, please email it to my attention at support@glowforge.com
Thanks ivan. Can you see what’s wrong with this dxf?
I am using QCad as part of my workflow for these, and the opensource version does not have SVG export, but I do have a plugin that can output g-code for the RAMPS board (which is what I used earlier).
tITX.dxf (166.5 KB)
The height placement on your parts exceeds the available bed size on that file. It opened, but if you move the parts slightly closer together so that the total height is under 10.95" it will probably process without issue.
(The 11" height requirement is slightly rounded up from the actual. I find that using 10.95" as an overall limit allows jobs to load without error.)
Here’s your file at 10.808" total height.
Wait, this is weird, it opens now, whereas it threw a “design too complicated” error for me before. I checked, and the file modification timestamp was still back in 2017. Perhaps GF updated something on their side. Anyway, thanks!
What @jules mentioned regarding the height of the design is correct. When I opened the DXF in Illustrator, the height was 11.016". I’m glad that you were able to get up and printing with this design!
I’m going to close this thread. If you run into trouble again, or have any other questions for us, please post a new topic here on the forum or email us at support@glowforge.com and we’ll be happy to help.
