This would help prevent situations like this from happening in the future, along with making repetitive use so much more time efficient for everyone forging.
seems like it is processing jobs ate close to ânormalâ at the moment. ( just started an 8 minute ish cut and it flowed smoothly with very little lag).
I havenât run into this problem yet but I can definitely see myself being pretty salty if I ever do. I only get a short amount of time per day to work on the GF, so if the great Cloud⢠deems that it cannot process my job because itâs queue is full⌠well then we got a problem. So the ability to âpreprocessâ jobs would be at least a partial work around for some cases. They need to look into this quite seriously if the queue full thing becomes an issue that pops up more often.
I may be wrong, but I just think itâs a dead end. Besides, it is almost never an issue, and weâre not even sure what the problem was in this case. It may have had nothing to do with actually being overloaded.
I agree. Probably wonât happen. But eventually they NEED to look at allowing offline use of the machine. One of the (admittedly many) selling points when I went to buy the GF was that they had said they were going to open source it so people could write software for it that wouldnât keep it tied to the cloud. I just donât want to wait until it becomes necessary for that to happen before it does happen. No matter how much we want to think otherwise, companies pop up and die often. And hardware that is tied to a service with those companies becomes a boat anchor (I did NOT say paperweight, people⌠I didnât. ) Just look at all of the 3rd party NEST hardware that relied on NESTâs cloud service integration. Once google bought them and got rid of that cloud service⌠POOF. Every one of those devices became a pretty decoration for people to sit on an end table and wonder where their money went. Not to mention the companies that lost revenue streams practically overnight. Things happen and we donât want to be suddenly sitting on the outside looking in, wondering if someone is going to be able to successfully hack the hardware to allow us to use GRBL or some such software.
No they donât. You want them to, but that doesnât mean they need to.
[âitâ being the firmware, not the server side processing routines, so itâs kind of not what you want] They did. Itâs on the forum. Itâs hard to search for it, but itâs out there⌠it just came up recently, Jules produced the link from the ether, I think. Hunt around if you havenât seen it.
True, but this wouldnât be GFâs problem. Companies arenât your friends, they donât owe you much of anything. If GF went out of business tomorrow, they wouldnât be on the hook for anything, they donât have a contract with us.
Some lawyer somewhere would probably take on the case and try to extract some cash out of the situation, but I wouldnât hold my breath. Youâre talking about a company that doesnât feel like it needs to provide itemized invoices on repairs, you really think theyâll get too upset if we wish we could do stuff offline in the event of their demise?
It would be incredibly smart for them to do this though.
One of the biggest stated detractors of purchasing a glowforge is the online component and the possibility of not being able to use your forge due to an outage.
This possibility is now becoming a reality after multiple instances of service being unavailable.
Not only that, but unnecessarily repeating compute intensive work is one of the biggest taboos in computing.
Providing customers with the ability to skip long waits to do their work, while simultaneously reducing queue times for others, as well as heavy compute expenditures, would be a big win for everyone.
To give a little more context my most commonly used job takes ~10 minutes to render server side. I run this back to back to back most days.
If I had the ability to cache that job, it would save them ~2hrs of compute time per day for just me. It would save me 2 hours of waiting, and reduce their queue by a fair percentage.
Saving the instructions locally and reloading the same job would seem to be a good move. But decentralizing the processing of the job is just not something they seem interested in doing.
Itâd be tricky to be sure itâll work with changing materials: say you save the job to work with proofgrade maple, but they change their supplier, now your settings are all wrong. They arenât terribly incentivized to do a lot to support non PG materials, as much as we might like itâŚ
They want it to be a âpush the button and it just worksâ kind of moment, and the more complex you make this the less it becomes that. Look at the wide array of people complaining about how itâs too complex as it is.
Again, I really do agree with you about caching, either locally or on their server, but I still wouldnât hold my breath. (if it were me, Iâd do it serverside and store a serialized array of the settings passed from the UI and a checksum of the uploaded SVG (after mods in the ui of course). Iâd compare that info to recent jobs (say the last rolling month) and if I have a match just spit out the saved processed file. But I donât work for GF soâŚ)
Oh also, this. Yeah this is a detraction for some users, but the bulk of users donât even think about it. Thatâs the best part: nothing to install, nothing to update, cross platform craziness. Thatâs a win for a huge swath of users and definitely for glowforge support.
Rando: âI have windows ME running on an overclocked atari 2600, do you have drivers for this?!â
Glowforge: âGet out of here with that driver business!â
It doesnt have to be locally saved, it can be cached server side and just redistributed to the unit that requested it.
They can just attach material type meta info to the saved job (which it will already have anyways), so if they are aware of a material change, just re-render. A couple lines of code maybe.
To a user the only difference the user should notice is that some of their renders are instant instead of taking a long time. I cant see how that breaks the âpush the button and it just worksâ.
Its not really a problem that has a huge impact on my business personally, as I have other lasers. As someone who has good visibility to a large portion of their community, not only am I in a good place to make this suggestion, but also to inform those not familiar with the workings of these services, how things in the background work, and what potential solutions could be. Furthermore, once they are aware a better solution may exist, if they put their voices behind it, they could potentially influence glowforge to move in a direction that is in the best interest of everyone.
As long as an online app fits their business model and has more benefits than negatives, there doesnât seem to be enough incentive to offer a stand-alone app that would need to be able to work on all the computing platforms that folks are using at the present moment.
I think @takitusâs solution seems reasonable, to at least be able to open stored jobs and print them locally. That seems like low overhead.
Still, I just take the online app for what it is worth. There will be issues, but it doesnât come near close enough to erase all the benefits of having an app that is lightweight and doesnât require me to do any local configuration.
But we have had this conversation before and it will go the same way at least for the short term.