Local Cloud / Server-side software download

One of the points I believe @SolesUrsa brought up was that different versions of the cloud-based motion planning and layout might result in different results from one version to another, as Glowforge evolves everything.

[feature request] Would it be feasible to allow customers to choose the version trunk of the cloud software they use, tied to their accounts? Similar to allowing users to choose whether or not to go with the git master trunk, the nightly release, or the last stable version? They could pick it in their account preferences when they sign into the cloud.

That was talked about here.

The make magazine article discussed at Make Magazine review of Glowforge had a great image for me to illustrate my point with a couple of edits.

For a hobbyist example, lets say you are making a waterfall as part of a larger design and you ran a couple tests on the spare part of your board getting the result on the left. You finish the rest of the design, but during that time the cloud team installed their upgrade and the board you had carefully picked out for your engraved art ends up with the waterfall on the right. No ‘mist’ at the bottom.

In an example with the spirit of the Glowforge paying for itself, how about making signs for a local bakery’s display case? You make an engraved mahogany sign for each of the products – from bear claws and danishes to quiches and cookies. The bakery forgot to mention their croissants, so you tell the bakery it will be a simple 30 mintues of labor and $10 of additional material. You load up your template, change the text, and hit go. Instead of the top example, you get the second one without the q-tip look. You can redo your template to trying to match the other 12 signs, but you’d need to get one sign back from the bakery for reference and most likely you would never get a perfect match - you probably have to reprint all of the signs and either take a loss or explain a very surprising bill to the bakery (and the next time they need a sign they’ll get the full set remade again – by someone else).

As the Make article said, “The good news is that these are all software problems that the team can fix while they are still building your unit.” In other words the best intentions would be behind the software update, yet the whole point of the updates is to change how the Glowforge works. That is, the software team is changing every user’s production line without consultation. There’s no way the users could go back or even know how far they would need to go back.

Obviously I’ve though a bit about it all. Before launch, it might be good to make sure each recorded job includes which version of the cloud was used to produce it. Later, on the user interface side, let a user group jobs. There’s two goals: be as consistent as possible(historic software), or to be as close to the design as the Glowforge can acheive(latest software). If they add a job to the group and the current software is different from previous jobs in the group, offer the user the latest software or the software that was used for the other jobs in the group.

There are a couple remaining problems though. If the user tries the latest sofware at different times there could ultimately be many forks to pick from – realistically it narrows the list of possibilities but in theory they could have produced a job from the group during every single version of the software to have ever existed. Possibly offer three: the first used version, the most used version, and the latest version.

Another remaining problem is safety – if a version of the software is unsafe for the forge or the user, can you still offer it? In this case maybe the oldest software you offer is the oldest safety update. Maybe you offer the original version with a disclaimer and end user agreement to expose their forge or self to the dangers (and in the case it makes sense maybe void the warranty). In the latter case the list of options gets up to 4: the first version used by jobs in the job group(may or may not require disclaimer), the most used version(may or may not require disclaimer), the oldest safe version, or the latest version.

I think if any user uploads the exact same design, they expect a machine to produce the exact same result. I’m not going to request a refund over it – I do prefer 0.3 from 0.1+0.2 instead of 0.30000000000000004, but if something works for me I’d like to be able to make sure it will always work.

5 Likes

It’s my understanding that issues like fine tuning the focus with the camera lens, engraving, etc. are going to be finalized before the production units ship. So that part isn’t going to change after the production units go out.

The Make Magazine article was written based on testing of one of the Pre-Release units. The changes to the software are being made now, before the production units ship, so yeah, there are going to be differences between those and what they will see once they get their personal units.

Unless you signed up for Beta testing and are trying to use one of the Pre-Release units for a business enterprise, it shouldn’t be an issue.

Makergear sends a letter to each of the Pre-Release testers that they select, explaining exactly what the model that they receive can and can’t do yet. So they tell you if it’s limited in some way.

They will be taking the Pre-Release units back and replacing them with Production units when they are ready to be shipped. :relaxed:

1 Like

This is a recurring issue in software. While not common, you’ll see comments in code like, “the following is a workaround for the blah, blah issue in v1.2.1 of something.” If that issue is ever fixed you may need to update the code by deleting the workaround. Same thing when a library is updated and backwards compatibility is not properly maintained or is simply abandoned. Having a single version in the cloud versus multiple forked version has its trade-offs, but I’d still go with the single version for the glowforge. Which is not normal for me. When presented the choice between living with the bugs I know and upgrading to the bugs I have yet to find, I almost always go with the former. For the super users, as long as the release notes are detailed you’ll be able to catch this issue before it ruins any material. Unless of course they fixed a bug that you thought was a feature - then you’ll be surprised.

As regards your concerns about safety, I don’t think it is reasonable to expect that Glowforge would leave a safety bug in the software just so some feature(s) would remain available. The advantage to a cloud based system is that if a safety problem is discovered you can immediately roll everyone back to the last safe version. If there is no known safe version you can brick every machine until the safety issue is corrected.

2 Likes

What evidence do you have of that, or is it just conjecture? I’m highly skeptical that will be the case.

Oh it’s pure conjecture. Because it wouldn’t make a whole lot of sense to go in and change something that works, and they strike me as being sensible people.

And…given the fact that they’ve delayed a couple of times now in order to make sure it works before sending it out, i don’t see them releasing something that they consider sub-standard in the first place.

So you can call it logical conjecture. :wink:

4 Likes

That assumes they get everything working. But what if they bump up against the limitations of what’s really practical for a mass produced product? Imagine the last update before shipping: “Well we didn’t quite manage to achieve all our goals before shipping, but you’re going to love this product anyway…”

Truly yours, devil’s advocate.

5 Likes

Quit it, you little devil! :smiling_imp: :wink:

They’ve already told us that IF something like that were to happen, they are going to tell us about it up front before it ships and give us a chance to get a refund, or wait for delivery until later when they have it worked out.

(I personally don’t see that there is any need to get ourselves too terribly worked up over hypothetical situations that haven’t even happened, but i have been reliably informed that some people actually enjoy the banter, so I try not to jump into the fray too often now.)

If I’m wrong, and it turns out that they can’t deliver on every single thing they promised at the time of delivery…I’ll decide when I get the shipping notice whether or not the functionality they will not be able to provide at that time is a deal-breaker for me.

I can already tell you that it won’t be, because what I’ve seen from the machine so far is actually more than what I paid for.

It’s not an all or nothing thing for me. I expect to get GREAT value for what i paid, and I’ve already seen it.

But each person has to make that decision for themselves. :relaxed:

9 Likes

I totally agree with you. I couldn’t have said it better. :grin:

4 Likes

Long ago I was working on an early version of CICS BMS - the software didn’t match the doc in a bunch of ways. So we built the application to be consistent with the behavior we observed. Next release the software changed - to match the documentation. Who does that? No one built software matching the doc. It wouldn’t work. We all had to change our apps because they chose the doc over real life. Sheesh. IBM.

:slightly_smiling_face:

6 Likes

I don’t mean to be argumentative. It’s just a knee-jerk reaction to conjecture being presented as fact!

3 Likes

I used a Motorola micro controller where the silicon was initially correct but didn’t match the documentation, which was wrong. They changed the silicon!

The Glowforge software is so far behind the advertised pro features that I am 100% sure it will either not ship in July, or it will ship with most features unfinished. You only have to look at features finished at Dec 16 and compare the time left with the time spent already. That is unless there is a huge increase is software productivity at the end of the project, which is the exact opposite of what happens in my experience. The last 10% of a project takes 90% of the time.

7 Likes

In general, I agree that the Glowforge team appears to be sensible people and they do not want to implement a change to software that would alter the results we get from our Glowforges. However, they may not always have much of a choice, or they may do something that inadvertantly alters functionality for certain designs.

Choosing not to update or at least having the ability to delay the update has been the case we are all accostomed to when not talking about multiplayer games or websites. Are you all fighting to lose that ability when it comes to the Glowforge?

@palmercr: Although the famous rule is that 20% of the project takes 80% of the time, I agree that in software it is worse.

@Jules: I am glad to hear you feel that you’re getting even more than we were all promised and a totally great value for our money. Super awesome, and I agree as far as I can without having actually used a Glowforge. I just have some experience in electronics/robotics, and plenty of experience in software. It looks like Glowforge is doing a great job and I expect far fewer changes in the first year than some of the 3d printers, but I do expect changes. The team will be shifting away from any sense of ‘get it shipped and working’ at the same time that they start getting feedback from thousands of machines. There will be discoveries, and the fastest way to resolve the problem if possible is a software update which you may not need or want in your situation.

@caribis2: I agree that safety to humans is probably ‘Done.’ with a considerable margin of error. I disagree with the idea that only the waste of materials matters or that the release notes will always indicate every consequence. A release note of “Better path prediction” could, for safety to the forge reasons, stop the Glowforge from accepting a design you had previously run many times. My point is you have no way to go back to the software that could run the design.

How does path prediction stop a design from working? The max engrave area (which may currently be hard-set but might currently or in the future be maximized by calculations of the required space) is smaller than the max cut area because the head moves so quickly during engraving, you’re not supposed to go too close to the walls so that the space by the wall can be used to slow the head down before it smacks full-speed into a wall. Optimizing the paths used may change the speed and direction of the head at a part of your design near the edge, and it could in fact move the edge of workable area inwords. The guy optimizing the paths may have had not predicted how the print area is changed, and it may have not been changed on test prints even if it was changed When the design has a particular eliptical curve at the edge or some other special case.

Also, they might find with thousands of units out there that the engrave area, a particular speed, or some focus setting is not always safe for all units. I doubt it as there’s probably a substantial margin of error on their settings, but these things happen because we are taking about a combination of software and hardware – it is less binary than “the following line is a workaround for issue #1338 and can be removed when that is resolved.”

Consider the environment for example. I’m sure it is not worth the cost to HP, Epson, and other makers of cheap little inkjet printers to thoroughly ground stuff just for the sake of a few dry environments, so those companies ship thousands of printers to dry regions ignoring the predictable static buildup – the printers with touch interfaces and no ground pin on the power cord pretty regularly register ghost touches on the control panel, ghosts that are even more likely to show up during a print job when the printer start charging capacitors, running motors, and dragging pieces of paper around. The rubber drive belts and rubber wheels on metal axles could practically be used to make a primative tesla coil. If you run the belts more slowly or give pauses then static buildup has more time to bleed off, therefore consistently high speeds may need to be cut back for the safety of all Glowforges in dry places and you’ll be stuck with it even if you’re in the pacific northwest.

5 Likes

It’s a new product under development, there are definitely going to be changes and additions for the first few years.

We can’t refuse the software updates, they happen at Glowforge. If a person’s business model is going to be disrupted by an occasional update, then he/she might want to choose a different laser.

There are plenty of established lasers out there that do not make changes to the software on a regular basis. This one is going to be in a condition of flux for a while after delivery.

Birthing pains you know. :slight_smile:

6 Likes

Never thought about static electricity buildup in things until I saw The Hunt for Red October and the transfer from chopper to sub. I do know there was a lot of discussion on badly grounded K40s. Lots to think about.

4 Likes

It appears that is the way it works now on pre-production machines.

I do hope once machines are in production that we will be given the option to accept an update, or roll back to a previous version if we find it causes us problems.

2 Likes

People never expect their software enhancements to cause problems in working units, but it happens all the time. Its ok to expect it not to, but the concern is a real one.

4 Likes

Exactly. I think we should be able to, and I started this thread to ask about one way we could refuse the updates.

Since the solution in my opening post to this thread would require a fair amount of open-sourcing, and the make review clearly indicated what I talked about in that opening post, I thought about writing up an alternative that keeps source-code control on the Glowforge side while providing control of the software version to users.

I have zero knowledge of Glowforge’s hosting setup, but modern cloud hosting is rarely like ‘one server instance runs the same code for each and every person.’ Instead, you may get what is essentially a dedicated server for your connection based on the clone of a skeleton – by picking a different skeleton as the base of the server that will run your glowforge job, your job will be running the version of the software from that skeleton’s time. It is reasonably likely that even if the Glowforge hosting is not that exact style, it is set up in a way that can produce a similar functionality for the use case I am proposing. Hence:

That is one way we could ‘refuse’ the software updates on a case-by-case basis and hopefully eliminate these kinds of birthing pains for the users.

3 Likes

Frankly?

It’s obvious that they decided to go a different route with it, since you did just exactly the right thing and asked about it early enough in the development, that something could have been considered if it had not been too disruptive.

They chose not to though, which means it was either judged to be not enough of a priority, or it might have thrown the schedule off too much. And it’s too late now to change it - they’re not going to want to make any changes to the model now.

If you believe you can write a solution that can be implemented down the road to add the ability for people to refuse the updates, and if enough people are interested in the option, then you should probably be looking to work with GF on it as a future improvement.

(Did you check their job openings recently? They do change once in a while when they get past certain stages of the development.)

It might still be a little bit too soon for this, but down the road, it might be something they will consider.

3 Likes