Heater timeout

A Former User

maybe the adittion of an idle.g file could be a feature request, with a configurable timeout to allow more than just motor current to be reduced when left idle.

jckray

@deckingman @Phaedrux

Yes, this is intended for an end user who is likely not messing with the config.

The idea is that it would configurable via gcode. Maybe added to M143. We could have a T parameter. Default would be T0 (no timeout), T10 would turn off the printer after 10 minutes if not printing etc. It would have to be written into the firmware since conditional gcode is not supported.

This could cause some issues with pausing prints so the firmware would have to return previous printing temps before resuming a print if paused for more than the heater timeout time.

The Prusa firmware does something like this and I think it is a great feature. It would be great to have that option in RRF.

deckingman

@jckray But if it is configurable via gcode, then of necessity it means making changes to the configuration file - especially if the default is no timeout.

jckray

@deckingman I should explain. My company manufactures a 3D printer that uses the Duet. It would be configured this way from the factory. Yes, the user could go in and change it if they wanted to/knew what they are doing. I'm talking about a user base that is not writing or messing with the configuration for the most part themselves. We also push configuration updates in the form of zip files, so updating config etc, is essentially like flashing firmware from the user perspective.

I also think the hobby community that is building their own machines would benefit from the option of having a heater time out. It's just a nice feature to help keep the heaters from running when they don't need to be.

deckingman

@jckray OK. You didn't make the case that you are an OEM in your OP. I dare say David will look at this for you. I can't see any objections as long as users can choose to use the feature or not.
Edit. What is the usage case where one of your end users could turn on a heater without printing? I can only think of loading filament, which is best done with a macro that would turn the heaters off at the end.

A Former User

Even in a change filament macro the user could get interrupted and forget about the printer.

A new mode to M291 with a blocking timeout or a more generic idle.g file could be used for this and other functions, pending conditional g-code.

jckray

@dc42 Any thoughts on the possibility of implementing an optional heater time out?

On a semi-related note, is there a way of calling restoring the print temp when resuming a print? For example, if the temp was set to something else during a pause, then resuming would restore the printing temp. Essentially, is there any way to call the previous printing temp?

zapta

@deckingman said in Heater timeout:

Edit. What is the usage case where one of your end users could turn on a heater without printing? I can only think of loading filament, which is best done with a macro that would turn the heaters off at the end.

For example, to change or clean the nozzle. Turning heaters on can be done directly in the UI and there is no enforcement that it's done in a macro.

dc42

@jckray said in Heater timeout:

@dc42 Any thoughts on the possibility of implementing an optional heater time out?

I will add this to the firmware wishlist. Perhaps it should be a global timeout that turns the whole printer off?

On a semi-related note, is there a way of calling restoring the print temp when resuming a print? For example, if the temp was set to something else during a pause, then resuming would restore the printing temp. Essentially, is there any way to call the previous printing temp?

You could set up a standby temperature for the tool (or for all tools), then you can use T-1 in pause.g to deselect the tool (although that would be inconvenient if you want to do any extrusion or filament loading while it is paused). Then do T R1 in resume.g to restore the active tool at the time of the pause.

egmrudd

@dc42 Has this been implemented, and if so how. My company is also using duets in our in-house built machines. We do R&D research for multiple customers and are often changing the configuration of our machines to perform specific tasks. So it is not feasible to war game out every single user error case that can occur, therefore having generic safe guards in place such as enabling a heater to time out when the machine is idle would be beneficial.

Global time out could be an option but im not a fan of that because shutting off the power would also kill power to my cooling systems, which would be a problem if the machine was in a hot state.

dc42

Can you use the daemon.g file to do this?

semi55

@dc42 I would also be interested in such a feature for safety reasons for our customers.

gregsaun

@dc42 We are very interested to have this feature as well . This is not only a security feature but also reduce chances for people to have their hotend clogging, avoid some part like shroud deforming because there is no airflow or simply reduce energy consumption. Even for an advanced user there will always be a day where you forgot about it.

If not possible, could you give us a little bit more details on how to implement this with daemon.g?

OwenD

Perhaps you could use the idle hold timer (M84 Sxxc) in conjunction with daemon.g
So if there was no movement for specified time, turn off heaters.

So something like this in daemon.g

If {(move.axes[0].current < "YourIdleThreshold") && (heat.heaters[1].state ="active")}
    Code to turn off heater(s)

gregsaun

@owend thanks for your help. Any reason why you want to get the current instead of machine position like with move.axes[].machinePosition ?

OwenD

@gregsaun
I wasn't actually looking at the position, but at the current that the motor is set at.
However it may actually be that you would look at move.axes[0].percentCurrent
After the timeout set in M84, your motor(s) will be set to a lower current.
I just tried to check on this, but the object model doesn't change for either move.axes[0].percentCurrent or move.axes[0].current after M84 is issued despite the axis being marked as unhomed.
Perhaps @dc42 can comment.

gregsaun

@owend Sorry for my late answer, thanks I better understand now

petriheino

Hi, did anybody actually get this working with daemon.g or other means?