Apologies fi this has been asked before, didn’t come up in immediate search.
When printing multi-part jobs, I routinely set up the print and material settings when I first upload the job to app.glowforge.com and when I usually have all of the data in front of me to drive the artistic or technical choices behind the print.
It could be hours or days ahead of when I actually plan to run the print if I’m remote or not near the printer (99% of the time).
When it comes time to print, I usually have to “ignore” certain parts of the run so I can print in stages and verify the results. This effectively wipes out all of my setup and research that went into preparing the initial print. I’m also often on a different computer (one at the printer station) when I actually run the print so my actual notes and research may not be close at hand.
There really should be an ability to ignore a part of the print temporarily without wiping out the current settings.
Bonus(#1) - We should have a way of setting up default print settings that we can return to if things get really messed up during experimentation, or if we just have to do a touch up pass.
Bonus(#2) - We should have the ability to step back through previous setups, particularly for those that we’ve actually committed to a print previously.
The “ignore” request is to have this be more of a toggle than it’s own distinct print configuration as switching to ignore wipes out the current print settings in place. While there is a need for a permanent ignore for non-printable artifacts, it’s far more common for me to use this during printing to run individual parts of a print job.
As for saving custom print settings, I know my print settings get saved when I edit them in app.glowforge.com. However, these get wiped out by ignore. So if there is a different way to save print settings, then I guess I just don’t know how to do that and I don’t see anything special in the interface on how to do this.
Honestly, what I’d love for this issue isn’t exactly the same as what’s requested here. The real reason I (and apparently a few others) want to switch steps between Ignore and (insert other settings here) is because we do multiple printing phases out of the same design/file — for alignment between flips on a two-sided design, for removing an area of masking material before engraving, etc.
So it seems like the best way for the GF web app to address that need might be for the Steps UI to offer a way to group steps. Then each step would keep its settings always, and you could set entire groups to be ignored. (Something like this might also make it easier to share designs that involve techniques like two-sided engraving.)
Hi @barney_mattox My name is Mercedes and I’m part of the Technical team here at Glowforge.
That’s a great idea for a feature - thanks for the suggestion! We haven’t announced anything like that yet, but I’m going to send it to our team with a note that it came from a customer request!
I suspect we’re now looking at three different, but interrelated feature requests based on the discussions here:
1} Refactor the Ignore feature into a toggle state that doesn’t overwrite other print settings.
Make saving/overwriting the print settings for a design deterministic/persistent. So changes made during a particular session can be ignored or reverted to prior saved settings. This allows for risk free experimentation or one off specialy prints without destroying the original/default design setup.
3} Ability to save multiple print configurations per a design (labeled for future reference) to allow for different steps, print order, ignore states, material settings. This allows for a} single design file to support multiple scenaros, b} maintain utility tasks like when you need that one extra cut pass to get through a stubborn piece of leather, and c} ability to persist interesting experimental sessions for future use/reference. And all of this without constantly destroying your default setup or polluting your dashboard with dozens of replicas of the same file trying to work around these issues.
There are also some other comments in here on particular usage scenarios that may factor into how {3} might be implemented or used that go beyond my specific experience.
These could all be incrementally supported to relieve the immediate pain points, but are also stand alone features that serve specific needs. So believe al three are worth considering and insuring they interoperate together.
Hope this captures and summarizes the thread well.