search

MarlinFirmware / Marlin

Marlin is an optimized firmware for RepRap 3D printers based on the Arduino platform. Many commercial 3D printers come with Marlin installed. Check with your vendor if you need source code for your specific machine.
https://marlinfw.org
GNU General Public License v3.0
16.18k stars 19.22k forks source link

[FR] Allow AUTO POWER OFF Features without AUTO_POWER_CONTROL #22423

Open gpread opened 3 years ago

gpread commented 3 years ago

Is your feature request related to a problem? Please describe.

Currently I have not found a way to have a configuration where I manually turn on power and allow software power off with a delay (to allow fans to cool things) and/or have the printer shutdown if its idle for a period of time.

By using the PS_ON to trigger a SSR and having a momentary switch across the SSR output you can achieve Manual ON with Software OFF (LCD and/or M81). That is the approach that DUET uses btw.

Are you looking for hardware support?

No response

Describe the feature you want

I would like to use the POWER_OFF_DELAY and POWER_TIMEOUT features but these are only available with AUTO_POWER_CONTROL (which includes and requires AUTOPOWER_XXX features that turn ON Power).

If AUTO_POWER_CONTROL is enabled with such a physical configuration as mine then either POWER dies (because no item is triggering POWER ON), or POWER cannot be turned off with M81 or by POWER_TIMEOUT, because an AUTO_POWER_xxx is requiring POWER to still be supplied.

The current approach assumes/requires that Marlin is always powered and PS_ON is only being used for an ancillary supply. In this emerging ECO world It seems to me that its preferable to not have to permanently power Marlin.

I can see two potential solutions, a static item for AUTO_POWER_CONTROL which defaults POWER to ON and is ignored when validating POWER OFF request (TIMEOUT or M81), or dispense with AUTO_POWER_CONTROL and simply make each AUTO_POWER_XXX config item atomic as an ON or OFF.

Additional context

No response

ellensp commented 3 years ago

use G4 then M42: Set pin state at the end of your gcode. to wait then turn off.

gpread commented 3 years ago

use G4 then M42: Set pin state at the end of your gcode. to wait then turn off.

This could work for simulating POWER_OFF_DELAY but I (and others I imagine) would prefer not to have to implement/re-implement POWER_OFF_DELAY as commands in print g-code or using g-code scripts for this scenario.

I wanted to use LCD menu entry and/or send just M81 for POWER OFF and the delay be implicitly applied (just as it would be if the Power on had been triggered by an AUTO_POWER_XXX config).

Also that approach can't work at all for getting the POWER OFF as the result of a period of idle.

Maybe its just me but I don't see a logical reason for AUTO POWER OFF features/behaviours to require /expect that there was an AUTO POWER ON feature that triggered POWER ON in the first place.

There are surely many alternative configurations or scenarios where people would want to be able to use AUTO ON or OFF features independently ?

Also configuration would be simpler if an AUTO_POWER_XXX (on) or AUTO_POWER_YYY (off) implicitly initiated the code to check and/or action them without requiring AUTO_POWER_CONTROL to also be used/configured. I think such an approach would also make it config backwards compatible (AUTO_POWER_CONTROL is just ignored/redundant.

I can understand that the current config structure of Marlin was intended to help group things together. However, with something that gets complex (which Marlin is at this point for sure) I believe it becomes messy and more complicated to maintain for both developers and users.

I have experience with other highly configurable and complex software systems which use config files and the best solution I have seen is to use scope and/or hierarchy to achieve the same with other benefits.

So for example have a parent such as PSU_CONTROL with children such as PSU_NAME, in which case setting PSU_CONTROL.PSU_NAME "Power Supply" would configure the name and implicitly enable PSU_CONTROL. Similarly for AUTO_POWER_XXX (on) or AUTO_POWER_YYY (off) you would have AUTO_POWER as a parent and the others as children. Such a mechanism also allows for instances to be naturally grouped and have global setting which can be overridden e.g. SERIAL.PORT.1 "1", SERIAL.PORT.2 "2", SERIAL.PORT.BAUD "115200, to make SERIAL PORT 1 a different BAUD you would just add SERIAL.PORT.1.BAUD "250000".

Another beauty of that type of approach is that the order of entries is not significant/relevant, which is easy for users and logical for developers (specific code section/routine) looks through the config for all the relevant parents and children to determine what it should do.

Perhaps something worth considering for a future major release (since it would affect all the code, and users would need to migrate their configs manually or a script could be produced to convert them to new format) ?