Fan staying on longer after job finishes?


#1

Anybody else noticed their fan running longer after a job finishes? I just turned my :glowforge: on for the first time today, so maybe this was just updated. I ran a very simple job (it lasted about 10 seconds, tops) and the fan ran for several seconds longer than normal at the end. I didn’t see a setting for this in the app, though, so my wish for an adjustable timer for the fan must be still in the hopper.


#2

They’ve said that the length it stays on can/will vary with different :proofgrade: material selections. Also said it’s possible user control over it may someday become reality.


#3

I noticed it as well. Looked like they ran a solid 10 seconds after the job completed.


#4

I was using the same PG settings as yesterday, though. I guess my main interest was the idea that an update occurred and if anyone had noticed any other changes.


#5

It’s hard telling for sure, but they mighta upped power or something. I printed something that push fit together yesterday. Today it’s loose. I did modify the design, but not the parts that went together. Maybe they upped it due to some of the reports of not making it all the way through that have been posted lately? Still, not really sure if this is an actual change.

Also, I noticed the fan increase.


#6

That’s good to know. I’m currently working on something similar, so I’ll have to keep an eye out for that.


#7

This is why I think it is safer for me to use some manual settings for things I am repeating.
At least until the seemingly frequent changes settle down (or are better communicated).


#8

That’s crazy. How can you work with a tool that might do something different from day to day without any warning? It would drive me crazy.


#9

At this point for all I know it’s something I did. I do hope at some point down the line there is information released as updates are pushed out. In the mean time, I accept that things are in a “beta” status and I’m happy to have the tool.


#10

I see no reason why this couldn’t be done right now. It is the least I would expect from any company releasing software that has real world consequences such as wasting material and time.


#11

No wasted material in my particular case. A dab of glue took care of it. My current workflow for a batch of items will be to print one, test the fit, print the rest.

I see no reason for them holding it back other than they have prioritized it lower than other things. I think they likely know it’d be a good thing, so why would they intentionally hold it back? I’m sure that if it were high enough on their list and easy enough to implement well, it’d be done.

I prioritized accepting a machine over waiting for it to be more developed. Just gotta roll with that.


#12

They seem to hold back as much information as they can. Everything is obscured and hidden as much as possible.


#13

Hmmm… I disagree. I think the reason for them not providing more detailed information about machine updates is because it’s not easily implemented well and they have it prioritized lower than some other things. We’ll see.


#14

It doesn’t take much time to add a version number and date to a web page so you at least know it changed.

Making release notes that describe the changes adds a little time but nothing compared to making those changes. Generally it is just reviewing the source control commits and summarising in plain English in a few sentences. Having done it myself throughout my career I never found it a significant burden or time sapper.


#15

You’re telling me how it can be easy. I’m not convinced that the ease of implementing/priority combination is right to be done with this. What, specifically, would they gain from holding that back?


#16

Everything seems to be easy for a S/W developer. The hard part is keeping focus on the priorities and not the easy fixes.


#17

Sometimes release notes reveals too much about how the sausage is made and makes people more nervous than discovering changes the hard way. Especially at the beginning of a project.

At some point, the equation flips and it is less support work to have detailed notes rather than deal with questions one by one. They’re probably at that point now.

However, one bit of secret sauce that they’re relatively open about now, but may not want to be forever is PG automagic. One reason is that you might want to have it be more environmentally sensitive and compute on the fly, but only for proofgrade.

When contemplating changes like that in the future, there’s probably a lot of thinking, testing, etc. you want to do and in an ideal world, not be bound by communication expectations that you’ve set by precedent in the past.

Another reason that it might be harder than some might expect is based on design goals for the UI. It often happens that there is a tension between offering sufficient information and the users impression of complexity or simplicity. This is often where engineers like me get frustrated because it’s hard for me to understand how hiding information that I need to know can possibly make something seem simpler to anybody.

So there might be somebody (a product manager) hoping that they get stuff dialed in an settled enough that this is not something most people need or want to worry about. In my view, it’s a hope that is likely to cause more harm than good, however. And if I were on the team, and this was the discussion, I’d push for including change indicator (perhaps subtle) in the UI and promise to remove when no longer useful.


#18

My understanding was that the proofgrade settings may change in updates, but that if you use manual settings for inputs such as power, speed, and LPI, or at least check the proofgrade settings and keep a record of them to input manually if they change, that you should get the same results across updates.

Does anyone with a unit know if this is correct?


#19

Pass through and doubled side don’t look easy to me but putting a version number on a web page and proper release notes certainly are quick and easy. So is showing what has changed since the last time you logged in. It is totally unreasonable to make a laser cutter that will cut one day and not the next or with a different kerf due to a secretive change to the software.


#20

Haven’t seen any of that. Every instance of not cutting through or parts fitting differently on this machine have been operator or environmental changes. I can’t know if there have been those types of S/W changes but suspect a lot of the anecdotal comments have been just that.