[Pause/Resume] [Runout Sensor] [M600] The toolhead moves to the printed object after a pause+park

[FromtonRouge]

There is a bug in the Pause/Resume feature where the toolhead moves to the printed object after the pause.

I saw the bug 3 times with the runout sensor (pause_on_runout: True). I don't have the klippy.log for this case.

But the bug happens when using M600 and appears on the first filament change only. My M600 is implemented like the one in sample-macros.cfg with a park and retraction after the PAUSE.

I did a test with 2 filament changes in the same object. On the first change the toolhead goes back to the printed object (100% reproducible). On the second change the toolhead stays in the park position, it works as expected.

There is a video of this test : https://youtu.be/zezf7FuA7Es The first filament change is at 2:11 the second at 5:53

In attachment the klippy.log of this test

klippy.log gcode and stl files.zip

[Arksine]

What version of octoprint are you using? This is the type of behavior you get when Octoprint isn't expecting acknowledgment for "unknown commands". The result is that it sends an extra move after Klipper has initiated a pause.

This should be fixed in the latest version of Octoprint, but perhaps there is still an issue.

[FromtonRouge]

It's OctoPrint 1.3.11

[KevinOConnor]

Any further updates on this?

-Kevin

[Arksine]

Unfortunately I am unable to consistently reproduce this. I attempted to print the exact gcode on my Voron and it didn't exhibit the awkward behavior. I was able to reproduce something similar once on my Ender 2, in which Octoprint didn't correctly track acknowledgements. I have since performed a system upgrade, and I haven't been able to reproduce again.

My suggestion for anyone experiencing this particular issue would be to flash a clean version of Octopi and see if the issue persists. I don't believe it is a problem with Klipper's pause_resume module.

[FromtonRouge]

I did not mention this but it was a fresh install. I flashed Octopi the day before (4th august) and have 2 plugins installed (OctoKlipper 0.2.5 and Prusameshmap Plugin 0.3.0).

I can try to reproduce the bug without those plugins and also without the camera stream. If the bug is still there I'll try to flash Octopi again.

For the record my Raspberry Pi is the model 3B+

[FromtonRouge]

Ok I still have the bug without the 2 plugins and without the camera.

But I found a workaround : Just print the file from the virtual SD Card It works either from the lcd screen or from OctoPrint with the filter "Only show files stored from SD"

Now my problem with this workaround is that sometimes I can't cancel the print from OctoPrint

[UPDATE] @Arksine I have flashed again Octopi 0.16.0 + OctoPrint 1.3.10 then immediately upgraded to OctoPrint 1.3.11 and reinstalled Klipper by following instructions here https://www.klipper3d.org/Installation.html and still have the bug (except if I print from the virtual SD card)

[KevinOConnor]

FYI, there was a recent change (commit 49779f13) to the filament switch sensor. Not sure if that changes things.

-Kevin

[FromtonRouge]

Thanks I'll try next week

[FromtonRouge]

I updated my klipper and tried the new pause_delay option in the [filament_switch_sensor] section.

Unfortunately the bug is still here (I tried the following values for the pause_delay option : 0.5, 2.5 and 10.5)

[Arksine]

Try removing the calls to SAVE_GCODE_STATE and RESTORE_GCODE_STATE in your M600 and PARK macros. The pause_resume module handles this for you, and nesting them this way could lead to unexpected results.

Considering it works with VSD it still sounds as if Octoprint isn't properly tracking acknowledgements, but perhaps the above suggestion will help.

[FromtonRouge]

I removed SAVE_GCODE_STATE and RESTORE_GCODE_STATE from M600 and PARK and it didn't help :(

[ochm]

I have probably the same problem, but IMHO the core is such situation: When arrives M600, everything is OK, and after resume print continues well. But when in M600 state (paused and moved head somewhere for filament change) i remove the filament, the filament runout is detected, and the macro calls again M600. Normaly when filament runout is detected during printing it looks OK, but when is detcted in M600 state, it is problem (in consequence with M600).

[Arksine]

@FromtonRouge Ok. Unfortunately your issue is not likely with Klipper but with Octoprint, so there isn't much I can do to fix it. I can however provide a workaround. You will need break your M600 macro down into two macros, something like the following:

[gcode_macro CHANGE_FILAMENT]
variable_enabled: 0
gcode:
    {% if printer["gcode_macro CHANGE_FILAMENT"].enabled %}
        PAUSE
        PARK
        G91
        G1 E-100 F1000
        M117 Change Filament
        PLAY_ANNOYING_BEEPS
    {% endif %}
    SET_GCODE_VARIABLE MACRO=CHANGE_FILAMENT VARIABLE=enabled VALUE=0

[gcode_macro M600]
gcode:
    SET_GCODE_VARIABLE MACRO=CHANGE_FILAMENT VARIABLE=enabled VALUE=1
    {% if printer.virtual_sdcard.progress %}
        CHANGE_FILAMENT
    {% else %}
        {printer.gcode.action_respond_info("action:pause")}
    {% endif %}

You then need to go into Octoprint's settings and add CHANGE_FILAMENT to the after print job is paused gcode script. This gets around the issue of Octoprint not properly tracking acknowledgements by allowing Octoprint to send the macro itself.

Note that for this to work properly with the filament sensor, you need to disable pause on runout. This is due to the way Octoprint works, it won't execute the CHANGE_FILAMENT script if the filament sensor pauses it first. I also recommend a very short pause_delay:

[filament_switch_sensor sensor]
pause_on_runout: False
pause_delay: .0001

@ochm Your issue is not related to the above. You have two options. The first is to make sure that you wait until all motors (including the extruder) stop moving before pulling the filament out past the switch. The runout gcode wont trigger if motors aren't moving. The second is to use the SET_FILAMENT_SENSOR SENSOR=<sensor> ENABLE=<0|1> gcode to disable the sensor in your unload macro and then re-enable it an a macro for resuming.

[FromtonRouge]

Everything works with your gcode scripts! Both M600 and the runout sensor (after adding M600 in the runout_gcode).

Big Thank You! Maybe it could be usefull to add your CHANGE_FILAMENT and M600 in the FAQ or the sample-macros.cfg

I was wondering, are Octoprint developpers aware of this acknowledgement bug ?

[ochm]

Nice idea with turned off filament sensor,

but if i do in terminal Send: SET_FILAMENT_SENSOR sensor=fsensor enabled=0 Recv: ok

and i do insert filament, printer does action defined in macro (two beeps and text on display and terminal).

[filament_switch_sensor fsensor] pause_on_runout: False event_delay: 3.0 switch_pin: !PK0 runout_gcode: M117 Filament Runout Detected M118 Filament Runout Detected M600 insert_gcode: M117 Filament inserted M300 S125 M300 S125 M117 Use menu to load filament M118 Use menu to load filament

I'm sure handling correct fsensor, because without filament i see:

Send: QUERY_FILAMENT_SENSOR sensor=fsensor Recv: // Switch Sensor: filament not detected

and with filament: Send: QUERY_FILAMENT_SENSOR sensor=fsensor Recv: // Switch Sensor: filament detected

It doesn't matter if the sensor is set to enable=0 or enable=1, each time detects filament runout.

My firmware is Send: M115 Recv: ok FIRMWARE_VERSION:v0.6.0-1593-g36eabdc2 FIRMWARE_NAME:Klipper

Doing something wrong, or there is a bug in Klipper?

Thank you for answer

-- Martin

From: "Eric Callahan" notifications@github.com To: "KevinOConnor/klipper" klipper@noreply.github.com Cc: "ochm" 3d@och.cz, "Mention" mention@noreply.github.com Sent: Saturday, September 21, 2019 1:59:43 PM Subject: Re: [KevinOConnor/klipper] [Pause/Resume] [Runout Sensor] [M600] The toolhead moves to the printed object after a pause+park (#1863)

[ https://github.com/FromtonRouge | @FromtonRouge ] Ok. Unfortunately your issue is not likely with Klipper but with Octoprint, so there isn't much I can do to fix it. I can however provide a workaround. You will need break your M600 macro down into two macros, something like the following: [gcode_macro CHANGE_FILAMENT] variable_enabled: 0 gcode: {% if printer["gcode_macro CHANGE_FILAMENT"].enabled %} PAUSE PARK G91 G1 E-100 F1000 M117 Change Filament PLAY_ANNOYING_BEEPS {% endif %} SET_GCODE_VARIABLE MACRO=CHANGE_FILAMENT VARIABLE=enabled VALUE=0

[gcode_macro M600] gcode: SET_GCODE_VARIABLE MACRO=CHANGE_FILAMENT VARIABLE=enabled VALUE=1 {% if printer.virtual_sdcard.progress %} CHANGE_FILAMENT {% else %} {printer.gcode.action_respond_info("action:pause")} {% endif %}

You then need to go into Octoprint's settings and add CHANGE_FILAMENT to the after print job is paused gcode script. This gets around the issue of Octoprint not properly tracking acknowledgements by allowing Octoprint to send the macro itself.

Note that for this to work properly with the filament sensor, you need to disable pause on runout. This is due to the way Octoprint works, it won't execute the CHANGE_FILAMENT script if the filament sensor pauses it first. I also recommend a very short pause_delay: [filament_switch_sensor sensor] pause_on_runout: False pause_delay: .0001

[ https://github.com/ochm | @ochm ] Your issue is not related to the above. You have two options. The first is to make sure that you wait until all motors (including the extruder) stop moving before pulling the filament out past the switch. The sensor wont trigger if motors aren't moving. The second is to use the SET_FILAMENT_SENSOR SENSOR= ENABLE=<0|1> gcode to disable the sensor if your unload macro and then re-enable it an a macro for resuming.

— You are receiving this because you were mentioned. Reply to this email directly, [ https://github.com/KevinOConnor/klipper/issues/1863?email_source=notifications&email_token=ALLGXVTKJ3AO4QHW5TWJBPLQKYEC7A5CNFSM4IJPEUHKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD7IQNKA#issuecomment-533792424 | view it on GitHub ] , or [ https://github.com/notifications/unsubscribe-auth/ALLGXVTBZKDDUF6IAS2OUSDQKYEC7ANCNFSM4IJPEUHA | mute the thread ] .

[Arksine]

The correct usage of SET_FILAMENT_SENSOR is as below:

 SET_FILAMENT_SENSOR SENSOR=fsensor ENABLE=0

The option to set is "ENABLE", not "ENABLED"

[ochm]

Hi Eric,

yes, my bad, but answer OK to incorrect command is little bit confusing :)

Sensor behaves as expected.

Thank you for your help.

​​-- Martin

From: "Eric Callahan" notifications@github.com To: "KevinOConnor" klipper@noreply.github.com Cc: "ochm" 3d@och.cz, "Mention" mention@noreply.github.com Sent: Wednesday, September 25, 2019 12:27:18 PM Subject: Re: [KevinOConnor/klipper] [Pause/Resume] [Runout Sensor] [M600] The toolhead moves to the printed object after a pause+park (#1863)

The correct usage of SET_FILAMENT_SENSOR is as below: SET_FILAMENT_SENSOR SENSOR=fsensor ENABLE=0

The option to set is "ENABLE", not "ENABLED"

— You are receiving this because you were mentioned. Reply to this email directly, [ https://github.com/KevinOConnor/klipper/issues/1863?email_source=notifications&email_token=ALLGXVSGLRUT3BJ4VDJYXDDQLM4INA5CNFSM4IJPEUHKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD7RNDRY#issuecomment-534958535 | view it on GitHub ] , or [ https://github.com/notifications/unsubscribe-auth/ALLGXVVFUXZVJVW73SS4YTDQLM4INANCNFSM4IJPEUHA | mute the thread ] .

[KevinOConnor]

Okay, I'm going to close this as it looks like a solution was found for the original issue.

-Kevin