RRF 3.3b2 - triggered Pause - printer resumes automatically?

gloomyandy

I'm a bit confused what do you have attached to e0stop? The code seems to be creating a sensor of type P0 which is none on it?

Argo

@gloomyandy
Sorry for the confusion. Looking at it, it seems to be a unnecessary line of code in the ActivateAutoload and Unload Filament macros. But I have to test if it works without that line.
All the macros are there to mimic the typical Prusa filament autoload and runout behaviour as you can't use trigger2 and runout detection at the same time.

But I'm not sure if this can cause the printer to automatically resume a paused print (triggered by runout detection) and be in a state where it can't be paused anymore?

DocTrucker

@Argo right, gotcha. I've been having a fair bit of fun trying to get triggerx.g files to behave recently and missed the M591.

For fault finding I would recommend writting it all into one trigger file and setting the run out to be detected from a switch input. Set temps in a file to 0, allow cold extrusion, and unload the filament before print. Runwith thay before going live build again.

Fried brain abit today, will look again tomorrow!

gloomyandy

@Argo If what you want to do is to delete the filament sensor from an extruder then from looking at the code just specifying M591 D0 P0 (assuming the monitor is on extruder 0) should do the job.

You may want to try removing the M291 calls (just temporarily) to see if that changes the way things operate.

Oh and is this code running stand alone or on an SBC setup?

Argo

@gloomyandy

I’ll try the macros without the message box tomorrow.

Then again I’m asking myself why the macro runs fine up to the message and then resumes printing without the printer knowing that it’s printing again.
I don’t think there should be a gcode that can do this?

I run the Duet 3 Mini in standalone mode.

gloomyandy

I'm not saying there is not a problem. The more information you can provide the more likely it is that someone will be able to fix the problem (if there is one). At the moment you have a fairly complicated setup that involves a lot of macros. This is tricky for anyone trying to help to reproduce. So if you can simplify the setup or identify what element of your setup is triggering the problem it will be easier either for you to work around or for someone to investigate further.

Argo

@gloomyandy

I understand what you mean.
My hope was that it may be a already known issue with the setup I’m having or that something obvious is wrong.
The config I‘m using was ported and modified two times. First Duet 2, then SKR 1.4 and now Duet 3 Mini.

I also recall it working with RRF3.2.2 but can’t say for sure as I’m always fine tuning the macros for reliability. So there might be something new that causes the issue.

I‘m switching myself to „debugging“ tomorrow and enable the macros step by step.
First I’m just using the sensor only as filament runout and see what happens when it pauses. When it’s not resuming automatically after the triggered pause, I’ll enable auto unload and so on to circle it down. I‘ll report back then

Argo

Good morning

So I did some testing today and honestly the results made no sense to me.

In pause.g I commented out:

if sensors.filamentMonitors[0].status == "noFilament"
	M98 P"0:/macros/2.1 Unload Filament"

Pause does work then and does not resume automatically.
After the message "extruder 0 reported no filament" I then manually started my "2.1 Unload Filament" macro to unload filament and the printer still does not resume automatically.
So I can rule out that something in my "2.1 Unload Filament" macro causes a print to resume.

I could try to do a workaround now by putting something like this in daemon.g:

if state.status == "paused" && #sensors.filamentMonitors>0 && sensors.filamentMonitors[0].status == "noFilament"
    M98 P"0:/macros/2.1 Unload Filament"

Edit: yep, the idea generally works with daemon.g.
It looks like pause.g does not like having external macros otherwise the printer just resumes without knowing.

gloomyandy

Did you ever try your original setup with the M291 lines commented out?

I have a feeling that the internal handling of the M291 and pause may be getting mixed up. But I could be wrong, haven't looked at the code, just something I seem to remember from another thread.

Argo

@gloomyandy

Just tested it and you're right.
Without M291 it does work.

Argo

I've recently built a new printer (Voron 2.4) and forgot that this problem exists.
Result with RRF 3.3 b3 was that the conditional gcode in pause.g caused the printer (after the filament sensor triggered) to be in a state where it was still in pause but tried to continue the print without filament.
Only emergency stop does end the print then. BUT what was new this time: config.g and config.g.bak were deleted from the SD card. Because the printer was still in a setup phase I stupidly had no backup which I usually only do until it's a stable working config. Lesson learned....
I then recovered the deleted files with a FAT32 recovery tool

So in order to reproduce it (with RRF 3.3b3):

; pause.g
; called when a print from SD card is paused
;

M83            ; relative extruder moves
if sensors.gpIn[4].value == 1
	G1 E-3 F3000  ; retract 3mm of filament
G91 ; Relative Positioning
G1 Z10 F360; Raise Z
G90 ; Absolute Values
G1 X10 Y0 F6000 ; Parking Position
M300 S80 P8000 ; play beep sound


if sensors.gpIn[4].value == 0
         M98 P"0:/macros/Unload Filament"

The conditional gcode at the end is enough to automatically resume the print. I do not think that this is a expected behaviour?
My work around for this at the moment is to use daemon.g:

if state.status == "paused" && #sensors.filamentMonitors>0 && sensors.filamentMonitors[0].status == "noFilament"
    M98 P"0:/macros/Unload Filament"

dc42

@argo does your Unload Filament macro use M291 to display a message and wait for a response?

EDIT: yes it does, you posted it earlier. As far as I am aware, it is only M291 that causes this behaviour.

dc42

@argo please try the new 3.3RC2+3 binary at https://www.dropbox.com/sh/duc057ejldxhl48/AADiuF-oiz9EmkFX6HCeodxTa?dl=0.

Argo

@dc42

Thanks, I can confirm the bug is not present anymore.
Used conditional gcode and also M291 in my paus.g file. The printer stays in pause as it's expected.

dc42

@argo thanks for confirming this.