Disable Heaters when probing



  • Hi there,

    other firmwares like Marlin offer an option to have the heaters (especially bed heater) disabled while the probe moves down during auto bed leveling.
    This makes sense if you use probes that are sensile for electomagnetic fields like capacitive or inductive sensors.

    Will this option be added soon?
    Thanks in advance.

    GaRv3



  • If there is a GCode command to switch a heater into standby and then back again, they can be added to the deployprobe and retractprobe scripts.



  • Where can I find these scripts?



  • You create them. (they exist in the same place as config.g, bed.g, etc.)

    The g-code for switching the bed heater into and out of "standby" is M144. I didn't see one for tool heaters.

    I kind of wish there was a parameter to explicitly turn the heater to standby or active (instead of just toggling.) Otherwise, it's difficult to use in a script that doesn't already know the current state of the heater.



  • Well, I found that I need to create these scripts.

    In deployprobe.g I could use M144 to set the bet to its standby temperature, but how do I set the standby temperature? This would have to be 0 to make this work. In DWC there is not input field for the bed standby temperature.
    Additionally I could add M140 without any parameters to set the bed to its active temperature in retractprobe.g to enable the bed again.

    So how may I set the bed standby temp? M140 sets the active temp only.

    Btw. M144 does not toggle it. It turns it to standby and M140 without parameters turns it to active with the previous temp.



  • Well, setting it back to active using M140 without parameters does not work on the Duet Wifi. The Documentations says about M144:
    "Switch the bed to its standby temperature. M140 turns it back to its active temperature; no need for any arguments for that use of M140."
    Is this a bug?

    The standby temp can be set using M140 Rnn. But this does not help, if it can't be reactivated using M140.



  • Ok, so what I found now is that deployprobe.g and retractprobe.g are not executed at all.
    Btw.: I am using an NPN capacitive sensor connected to the E0 Endstop connector with mode 4 for M558. Maybe the scripts are not executed when using this mode!?!



  • My final request would be:

    • Execute deployprobe.g and retractprobe.g when probing even when using mode 4 o M558 is set.
    • A command to disable all or specific heaters from scripts (e.g. retractprobe.g)
    • A command to enable the disabled heaters again and set them to the previous temperatures from script that does not know the temperatures (e.g. deployprobe.g).
    • Fix M144 -> M140 (setting the original temp)


  • @GaRv3:

    Well, setting it back to active using M140 without parameters does not work on the Duet Wifi. The Documentations says about M144:
    "Switch the bed to its standby temperature. M140 turns it back to its active temperature; no need for any arguments for that use of M140."
    Is this a bug?

    The standby temp can be set using M140 Rnn. But this does not help, if it can't be reactivated using M140.

    oops. I thought M144 was a toggle. My mistake. I don't use the command, but looked it up to try and help you.

    As for M140 with no args not setting it back to the active temperature, it sounds like either a bug or an error in the documentation. dc42?

    As for the other questions…

    I have no idea how you set the standby temperature, but I'd guess that it defaults to 0 (which is exactly what you want if you need to turn off the heater.)

    deploy/retract: If they aren't called, it's because of the probe type. There are g-code (m-code, actually) commands to call scripts directly, or just insert the needed commands into your script that wants to turn the heater on/off.

    (This isn't to take away from your requests... I'm just trying to help you accomplish what you need immediately.)



  • GaRv3, do you have any details on why turning off the heaters should be beneficial in terms of probe accuracy? Quite interested in this, thanks!


  • administrators

    @GaRv3:

    Ok, so what I found now is that deployprobe.g and retractprobe.g are not executed at all.
    Btw.: I am using an NPN capacitive sensor connected to the E0 Endstop connector with mode 4 for M558. Maybe the scripts are not executed when using this mode!?!

    Are you running old firmware? Firmware 1.19 and later run deployprobe.g and retractprobe.g automatically before and after probing, unless you execute M401 (which runs deployprobe.g) explicitly first.



  • No, I am at 1.20

    I added M144 to deployprobe.g which should set the bed heater to standby. It does so when I enter M144 in the console but not when doing a mesh compensation probing G29 at the beginning of a gcode file. The heater stays active all the time and keeps heating the bed.


  • administrators

    Do you have your deployprobe.g and retractprobe.g files in the correct location? They should be in /sys. You can also put M117 commands in them to check that they are being executed.



  • Ok, I had a typo in the deployprobe.g filename.

    But this is not gonna work anyway because of the following reasons.

    1. M140 (without parameters) does NOT reactivate the heater. This probably is a bug.

    2. The scripts are called at the very beginning and end of the mesh calibration. This is not what is needed for sensors of this type because the leveling will take a while and bed temperature drops quite a lot which will result in completely different offsets at the start and end. The heaters have to be turned off when the probe moves down (until it triggers) and back on, when the probe starts moving up again (right after triggering). So the bed heater would be shut off several times (at each probe position) for a second or so when the probe moves down and stay on for the rest of the time. This would keep the bed temperature relatively stable and allow precise mesh compensation.

    3. The hotend still cannot be turned off and on again.


Locked
 

Looks like your connection to Duet3D was lost, please wait while we try to reconnect.