It’s important to also note that cloud-based software will be almost entirely platform independent. of the big 3 laser manufacturers (trotec, epilog, ULS) only epilog supports macOS (and only recently) and the others have no intention of doing so. For designers having to maintain a windows environment alongside your mac just so you can send a job to a printer is patently stupid (not to mention more expensive on top of already expensive laser hardware), and why I never bought my own laser before GF. Capability-wise GF does have some limitations in terms of focus length and bed depth against other lasers, but you have to accept those limitations because the cost of entry is so good. The software experience is what has been missing from the other manufacturers, and if GF is successful with their first version hardware I expect they’ll continue to innovate on the software experience while building higher-end, more capable hardware. At any rate, the fact that I don’t have to invest in a windows PC and all the extra workflow steps that come with it is the greatest selling-point GF offers me.
what JLabs said 
Cloud based software can be cross-platform, but that is not automatic, any more than a desktop client could be. Yes, most web based applications are, but anyone who used Microsoft Exchange’s web client prior to the latest version of Exchange is painfully aware that this is in fact not so. You are referring to the fact that when one makes a HTML-based client you can more easily make it work on many browsers more easily than a native client can, which is more a feature of whatever framework you use to build your application. The “cloud” is just a computer (or group of them in reality). You can run proprietary software (heck one of my most data intensive cloud applications uses a telnet interface [really a socket - but obeys telnet when required] because of the super low latency over HTTP!) or you can make them web based as GF seems to be doing. The servers GF is running on could be running windows, linux or any other OS, which you won’t care since you only see the client.
The issue that you faced with your other devices is they chose some windows based (i am assuming it was windows) driver architecture and a native windows client, which is very expensive to port between OSs unless you use some multi-OS based framework.
If the Epilog guys for instance had made their application generic for a web server and used a web front end, as GF is going, you could run that on the web server on your mac, linux box or windows box. We do this with our applications, and it moves cleanly between Mac, windows and linux and runs locally (and of course it uses a UI javascript based framework to deal with the browser insanity because 2015…)
Absolutely Henry. I am working on the assumption that GF is using modern technology and so will be mostly cross-platform based on what I’ve read and seen. Obviously there are limitation that could be in place due to technology choices, and of course I say mostly because if your browser is too old you may not be able to use GF’s web apps. I’ve designed through a transition from a windows only client app through a .net/activeX web app stack to a modern Jquery/JS/HTML stack and seen how frustrating it can be for end-users. I think Glowforge made a very smart choice using web-based cloud apps. They eliminate a huge amount of work for themselves and a huge amount of potential frustration for end-users.
My point here is that your solution didn’t need “the cloud” (god how I hate that word). You needed a computer to run the web/application server of which your local computer was more than capable of being the server for (except for performance/reliability/etc).
For demos I run Tomcat on my mac laptop and mysql to do demos, but of course we don’t run multiple hospitals off a 5 year old laptop, we run off a big RHEL server farm (but if someone tomorrow said Windows Server farm, sure, move the files over and start it up); the application and user are unaware of this. The point is a well designed web application can run anywhere, so you could run it on a cloud or servers to give scalability or reliability, run it on an in-house server(s) if internet is an issue or run it on your local machine. And while in the past that would be hard, with Docker as a technology now, installing whole functioning server apps is trivial, and doesn’t require any serious local knowledge.
Ahh I see what you’re saying, and yeah, that makes a lot of sense. As long as GF could encapsulate the environment to ensure ease of set-up (good UX is clearly important to them) most modern hardware should be more than capable of the processing required to drive a single laser. You lose the benefit of centralized, on-time bug fixes and updates, and potentially complicate firmware update delivery, but the scheduled and/or user managed update patterns are well established. My concern with that is that so few people run their updaters. Additionally, being dependent on the health of the users PC environment to run your laser adds to support overheard for GF. Support people hate supporting users home computers just so they can support their software, it’s the bane of IT help everywhere.
I do agree that the option to self install should be considered in the future, but for the mid-term future it probably costs more than it’s worth. Since most people have internet connections, and considering the market for GF is (at least initially) makers and hobbyist who aren’t doing 10 hour production runs, cloud based is the best choice for simplicity and management. As GF grows and decides what their next product will be (and I would be floored if they weren’t already thinking about it) I would assume they’ll revisit the client-install potential.
First off, this is an awesome thread - why did it go quiet after last November?
I read several mentions of the notion of centralized bug fixes/updates. That’s not always a good thing - software updates have been known to travel in pairs: the original update followed by a quick patch to repair the damage. Would centralizing the updates enable a single-point failure that takes down every GF? - talk about drama…
Is it possible the updates might change the appearance or behavior of a particular cutting or engraving job? How does someone running an engraving service for expensive laptop PCs know if the next job they run will turn out like the last one?
I hope, but don’t know, if the GF operator will have the option to freeze a recipe for a particular production run, or at least know when and how a control algorithm gets tweaked.
Edit: (I seem to type slower than @spike.) Most of your questions are answered in this very recent video. https://www.youtube.com/watch?v=PacXfucVWBc Sorry I can’t remember where though I know it’s after 7:30 minutes in. In short, Firmware updates will be rolled out to volunteer Beta testers of the firmware for just that reason, then another batch, and another, until everyone who wants the updates gets them. Along the way the acceptability of the update is measured.
Just as a point of clarity, we have that capability, but how it works out in practice is ultimately TBD based on the intersection of what people want, what people seem to use, how it works in practice, and how time gets allocated to actual development. For example, we think opting out of a motion plan update for existing designs is cool, but it’s in the feature hopper and not something that we’ve committed to do (let alone a schedule for it).
And @gdmccormack, as to why the thread went quiet, I assume that’s because the question is primarily academic because not only has that ship sailed but it has landed, offloaded it’s cargo, and then pressed into duty as a riverboat casino. 
@dan, thanks for the clarification. So if I understood it correctly, the current plan of record says that after going through a staged rollout, motion plan updates will be compulsory for all GF owners. I’m hoping the GF operator will at least know before pushing the button if anything changed since the previous job.
I understand the architecture of the GF has sailed, however not everyone’s acceptance of cloud-based motion plan computation has sailed alongside. That’s what made this thread interesting, as many good points were raised, which is useful for current and/or prospective owners to consider.
Snort!
Now this ship may have sailed, but let me tell you I was stuck unable to do work during the last 2 days for periods as the cloud was being funky since I do my cad mostly in OnShape which is cloud based. For the last 2 days there have been periods during the day when something was going wrong. Not sure what the issue has been, but others are noting these issues on their forum. The problem is going to be 24x7x365 availability is tricky. When verizon’s fiber went down the other day (and the backup fiber too - so assuming some street related issue) while OnShape wasn’t working, my other software certainly was because it is local to either my machine or my network at least. My 3D printing or CNC would work fine as they are local network, and the glowforge is a personal toy, so less worried for my needs, but for a business having everything on but just sitting there because something 10000mi away is busted would be a huge drag. The challenge is going to also be debugging the issue. Since it is wifi based (ugh) you won’t know if it is lots of local interference, wifi basestation segmented off from the network, edge router down, internet line down, CO level problem or cloud side issue, oh and then you have the client that is sending up to the cloud having all the same (but potentially different sets of) that equipment.
It is what it is, so I’ve been trying to formulate how to work with (around?) GF’s cloud-driven control system:
- Look for software that can measure the complexity of a CAD file in the context of laser cutting: things like surface area, number of vectors, etc.
- Figure out how “big” the GF’s buffer is by running test prints on cheap paper or cardboard.
- Adjust my designs to fit in the GF’s buffer - for all I know, a small simplification could make a big difference.
- If required, break the design into separable sections that could be completed consecutively, with each section staying within the buffer capacity.
- From what @dan has stated in these forums, the GF will complete the job if it fully resides in the buffer, even if the WAN connection is down.
- Do a “dry run” on cheap material and break the WAN connection after cutting has started, to confirm invulnerability.
- Perform any appropriate luck-enhancing rituals, and go live with the real target material. From what I’ve seen of the workflow, I can upload the job and press the go button on the GF anytime after its says it’s ready - maybe even the next day - so I can get the machine plan computations done independently from when it’s convenient to actually start and monitor the job.
The overarching principle is to allow for on-again/off-again WAN connectivity and don’t let it jeopardize the “print” run.
Over time, 1-5 should become second-nature and disappear into the design process. I experienced the same effect when 3D FDM printing limitations eventually shaped how I formulate and design mechanical objects. Step 6 would only be done if the object going in has high value, such as laptops, phones, jewelry, etc.
Hopefully none of that’s necessary: if your connection goes down mid-print, even if it didn’t fit in the buffer, it will resume when the connection is restored - even if that is meaningfully later.
–dan
@dan: it’s understood about the resume feature, which is cool (and essential).
This is just me, but I think I’d go nuts if an expensive cutting job unexpectedly stopped mid-print. What if it stopped right in the middle of a particulary important engraving cut - will resuming leave a mark? If the print suddenly stops or pauses, why? - is that normal, or is it a code fault, a hardware fault, a broken WiFi connection, a broken WAN connection, or a broken server? I’m thinking my only debug tool is the app, as the GF itself has no indicators beyond either working or not. So all the while I’m debugging and waiting for the job to resume, I have to protect the stability of the material - no bumping the table! And what if it doesn’t resume until 3am - I’d need to stay up as long as it takes to monitor the print until it finishes.
So that’s why I’d prefer to work within the margins of the machine’s capability, and insulate important projects from events outside my control. I recognize it’s a paranoid plan, but I think @dan confirmed it’s viable, albeit probably “unnecessary”. I post it here simply as a suggestion for others that may also share my concerns.
I’m reaffirming what has already been said by others.
My concern about cloud only is being locked out of using the Glowforge because of slow and inconsistent internet. I live in Seattle, in Capitol Hill, and my internet is terribly inconsistent and slow. If I’m trying to create on a timeline, cloud only capabilities are going to slow my production down to a nearly unuseable level. While the internet I can’t rely on, I do have a good PC I could plug it into and run things from there. So I’m also throwing in a big vote for Glowforge to please provide a way to use home PCs.
Actually, it’s a rare job that requires additional cloud access once the job has started, so it might not be the issue you fear. I lost internet while I had a job running in the Glowforge and it completed just fine. I think the entire job was downloaded to the machine in one slug.
Also, actual creation is done in other software. This is a big printer that uses the cloud to spool the job.
what I find to be of major concern is the whole upload to the internet… we’re assuming Google and Glowforge won’t be sharing our work, privacy please…
“Print” feature of thousands of printers has been accomplished quite successfully, why not Glowforge?
also of major concern is the requirement for online networking in an office environment with reasonably tight internet access… not uncommon for desktop computers to have wifi but not external access to the internet… makes the Glowforge a waste of time and expense