Error when PAUSE before print start

[jmceara]

Hi.
I have a warmup sequence that uses PAUSE before print actually starts. After updating my settings to use HH PAUSE/RESUME and PARK features, I'm getting this error when I try to start a new print after turning on the printer (note: this only happens when print is turned ON, after first filament load, this problem doesn't occour):

13:59:24 MMU issue detected. Print will be paused
         Reason: Runout check failed. extruder sensor does not detect filament
13:59:24 After fixing, call RESUME to continue printing (MMU_UNLOCK to restore temperature)
13:59:24   DEBUG: Job State: PRINTING -> PAUSE_LOCKED (MMU State: Encoder: Disabled, Synced: False, Paused temp: 170.0, Resume to state: printing, Position saved for: pause, pause_resume: False, Idle timeout: 72000.00s)

Some information:

• The MMU is calibrated and working as expected
• I always unload filament after all prints, so the printer started withoyt any filament loaded
• I'm using persistense level 4
• The sensors (including toolhead) are working fine
• After this error, if I do a "T0" manually. then RESUME again, everything starts to working (no more errors, including all subsequential prints).

This is my start gcode:

PRINT_WARMUP EXTRUDER=[nozzle_temperature_initial_layer] BED=[bed_temperature_initial_layer_single] CHAMBER=[chamber_temperature]


MMU_START_SETUP INITIAL_TOOL=[initial_tool] REFERENCED_TOOLS=!referenced_tools! TOOL_COLORS=!colors! TOOL_TEMPS=!temperatures! TOOL_MATERIALS=!materials! FILAMENT_NAMES=!filament_names! PURGE_VOLUMES=!purge_volumes!

MMU_START_CHECK

PRINT_START EXTRUDER=[nozzle_temperature_initial_layer] BED=[bed_temperature_initial_layer_single] CHAMBER=[chamber_temperature] MATERIAL={filament_type[current_extruder]} SIZE={first_layer_print_min[0]}_{first_layer_print_min[1]}_{first_layer_print_max[0]}_{first_layer_print_max[1]}

MMU_START_LOAD_INITIAL_TOOL

; Optionally add YOUR additional start logic (like purging) here to run just prior to start
SET_PRINT_STATS_INFO TOTAL_LAYER=[total_layer_count] ; For pause at layer functionality and better print stats

The PRINT_WARMUPP is the macro that put printers in PAUSE state while chamber heat up. After reaching the target temperature, it does a RESUME and than the actual print_start is called (attached).

Attached are print_start and log files. Descpiste the version 2.7.2 in the logs (collected a week ago more or less), the same happens in latest version (2.7.3-29).

• voron v2.4 300mm
• ERCFv2
• DangerKlipper v0.12.0-509
• HH v2.7.3-29 (logs are from previous version, but exactly the same still happening in latest version)

logs.zip

[ningpj]

Wonder if it's as simple as updating your warmup logic to call the renamed pause/resume commands instead....HH renames them to BASE_PAUSE and BASE_RESUME.

That or changing your logic to use TEMPERATURE_WAIT SENSOR=... rather than pause/resume. TEMPERATURE_WAIT doesn't have a max wait time though, only min an max temp settings.

[jmceara]

Wonder if it's as simple as updating your warmup logic to call the renamed pause/resume commands instead....HH renames them to BASE_PAUSE and BASE_RESUME.

I really don't understand your point and how this would help.
Can you explain?

BTW, here's my WARMUP macro and (attached) the heatsoak macro (source URL is in the file).

[gcode_macro PRINT_WARMUP]
description: Perform initial homing and heating tasks
gcode:
    {% set EXTRUDER_TEMP = params.EXTRUDER | default(0) | float %}
    {% set HOME_TEMP = printer["gcode_macro MACROS_VARS"].homing_temp|default(170) | float %}
    {% set BED_TEMP = params.BED | default(0) | float %}
    {% set CHAMBER_TEMP = params.CHAMBER|default(0)|int %}
    {% set FANSPD = printer["gcode_macro MACROS_VARS"].circ_fan_speed|default(0) %}

    DISPLAYTEXT TEXT="[WARMUP] Clearing pause..."
    CLEAR_PAUSE    

    DISPLAYTEXT TEXT="[WARMUP] Waiting heatebed temp..."
    SET_TEMP HEATER="heater_bed" TEMP={BED_TEMP} WAIT=0

    DISPLAYTEXT TEXT="[WARMUP] Waiting extruder temp..."
    # Always heat extruder before doing home    
    SET_TEMP HEATER="extruder" TEMP={HOME_TEMP} WAIT=1   

    DISPLAYTEXT TEXT="[warmup] Passo 0"
    
    CHOME
    G1 X150 Y150 Z60
    DISPLAYTEXT TEXT="[warmup] Passo 1"

    {% if CHAMBER_TEMP > 0 %}
      STATUS_HEATING
      SOAK_PREPARE
      DISPLAYTEXT TEXT="[warmup] Passo 2"
      DISPLAYTEXT TEXT="[WARMUP] Waiting heat soak..."
      # wait for the print bed to reach thermal equilibrium
      HEAT_SOAK HEATER='heater_bed' TARGET={BED_TEMP} SOAKER='temperature_sensor chamber' SOAK_TEMP={CHAMBER_TEMP} RATE_SMOOTH=30 HEATING_REPORT_INTERVAL=30 SOAKING_REPORT_INTERVAL=30 CANCEL='CANCEL_PRINT'
    
    {% endif %}
    DISPLAYTEXT TEXT="[warmup] Passo 3"

    DISPLAYTEXT TEXT="[WARMUP] End"
    CLEAR_BUFFER

And about loading sequence, the HH macros/config are the latest to be loaded in my printer.cfg:

(some includes...)

(in the end)
## Heatsoak should be the last
[include Macros/Printer/heatsoak.cfg-99]



################
#### ERCF ####
################
[include ../mmu/base/*.cfg]
[include ../mmu/optional/client_macros.cfg]

heatsoak.zip

[ningpj]

What part of your startup sequence is putting the printer into a pause state...HEAT_SOAK?

Sorry, didn't see the zip on my phone

[jmceara]

What part of your startup sequence is putting the printer into a pause state...HEAT_SOAK?

Sorry, didn't see the zip on my phone

Yep, PRINT_WARMUP calls HEAT_SOAK, which pauses the printer while heating up.
I may be wrong in my assumption, but it shouldn't matter if I call the modified PAUSE or original PAUSE (using BASE_PAUSE) from HEAT_SOAK macro, right?
If I'm right, PAUSE macro should work in any circunstance, despiste if if pre-printing or not.

[ningpj]

Try updating the pause / resume commands called in heat_soak in print to BASE_PAUSE and BASE_RESUME. I'm not sure if this will be enough to bypass HH checks and pause logic however.

[ningpj]

HH monitors klipper events so there is more going on than just the gcode macros and presumably assumes filament should be loaded or has an issue when pause is called in print. Just trying to suggest an option to try to workaround this.

I have a much simpler soak process, preheat extruder to soak temp and conditional chamber floor temp it needs to be above before printing.

[jmceara]

HH monitors klipper events so there is more going on than just the gcode macros and presumably assumes filament should be loaded or has an issue when pause is called in print. Just trying to suggest an option to try to workaround this.

I have a much simpler soak process, preheat extruder to soak temp and conditional chamber floor temp it needs to be above before printing.

Ok, I do unserstand now and I'll for sure try.

About heat soak, mine is a little more complex (I didin't built that, just using) and I love it....
it's cancelable and there's more things going on, like monitoring heat rate to make sure that chamber is really at the right temperature (ex: waiting for frame to expand to final temperature to get the right thermal expansion) etc etc....it's a kind of complex MACRO, but it does the job really well and I love it.

[jmceara]

For sure it's something wrong with HH logic. Calling BASE_PAUSE and PAUSE_RESUME, everything works as expected, no problem at all.
So there's something wrong with checks/logic of PAUSE/RESUME macro while print not started yet.

[ningpj]

As far as klipper and HH are concerned, your print has in fact started and would leave this workaround in place.

[jmceara]

As far as klipper and HH are concerned, your print has in fact started and would leave this workaround in place.

I don't agree. You may not change anything because of 'my problem', but the fact is that print is not started at this point, only the heating of chamber. The PRINT_START is not evern called at this point.
Again: in my opinion, the changes made by HH to PAUSE/RESUME is not handling most of cases, including a pause at begining of print.

But, like I like, I respect if you don't want to change/modify HH because of this specific case.

[ningpj]

Sorry, not implying it "wont" be looked at just to keep the workaround in place. The HH developer is focusing on getting 3.0 out the door at the moment which is a major update and beta cycle. The other point I was making is that the print starts as soon as you execute the gcode file not after you call a print_start/start_print macro. HH implements its own virtual toolhead so it can monitor klipper events (and sync steppers) so it knows when its in or out of print and can behave accordingly.

pleased the workaround worked for you

[moggieuk]

Catching up with "issues". It looks like @ningpj has provided a lot of guidance. Couple more thoughts / comments:

1. If inserting logic/macros BEFORE the Happy Hare MMU_START_SETUP then it should include:

    {% if printer.mmu.enabled %}
        # Precaution for when printing from Octoprint (but harmless if printing from virtual SD card)
        MMU_PRINT_START
    {% endif %}

The MMU_PRINT_START call is important to set the Happy Hare state machine.

2. Klipper defines two kinds of "print starts" actually. The first is the transition of "printer.idle_timeout.state" to "Printing" and this happens almost immediately when the first g-code is run. It will also happen which commands typed on the console. The second is the optional (by usual) printer.print_stats.state. This transitions to "printing" as soon as the file on the sd-card is opened. The MMU_PRINT_START call with cause HH to enter a "printing" state of its own (printer.mmu.print_state) at a precise time. If it is not called directly there will be a slight delay (about 4 gcode instructions before HH realises and corrects the state).

Hope this give you more options to fix your issue.

[github-actions]

This issue is stale because it has been open for over 30 days with no activity. It will be closed in 14 days automatically unless there is activity.

[github-actions]

This issue was closed because it has been inactive for 14 days since being marked as stale.