Duet3D Logo Duet3D
    • Tags
    • Documentation
    • Order
    • Register
    • Login

    RRF 3.3b2 - triggered Pause - printer resumes automatically?

    Scheduled Pinned Locked Moved Solved
    Beta Firmware
    4
    20
    1.0k
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • Argoundefined
      Argo
      last edited by

      @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?

      1 Reply Last reply Reply Quote 0
      • DocTruckerundefined
        DocTrucker @Argo
        last edited by

        @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!

        Running 3 P3Steel with Duet 2. Duet 3 on the shelf looking for a suitable machine. One first generation Duet in a Logo/Turtle style robot!

        1 Reply Last reply Reply Quote 0
        • gloomyandyundefined
          gloomyandy
          last edited by

          @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?

          Argoundefined 1 Reply Last reply Reply Quote 0
          • Argoundefined
            Argo @gloomyandy
            last edited by

            @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.

            1 Reply Last reply Reply Quote 0
            • gloomyandyundefined
              gloomyandy
              last edited by

              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.

              Argoundefined 1 Reply Last reply Reply Quote 0
              • Argoundefined
                Argo @gloomyandy
                last edited by

                @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 🙂

                1 Reply Last reply Reply Quote 0
                • Argoundefined
                  Argo
                  last edited by 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.

                  1 Reply Last reply Reply Quote 0
                  • gloomyandyundefined
                    gloomyandy
                    last edited by

                    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.

                    Argoundefined 1 Reply Last reply Reply Quote 1
                    • Argoundefined
                      Argo @gloomyandy
                      last edited by

                      @gloomyandy

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

                      1 Reply Last reply Reply Quote 0
                      • Argoundefined
                        Argo
                        last edited by

                        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"
                        
                        dc42undefined 1 Reply Last reply Reply Quote 0
                        • dc42undefined
                          dc42 administrators @Argo
                          last edited by 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.

                          Duet WiFi hardware designer and firmware engineer
                          Please do not ask me for Duet support via PM or email, use the forum
                          http://www.escher3d.com, https://miscsolutions.wordpress.com

                          dc42undefined 1 Reply Last reply Reply Quote 0
                          • dc42undefined
                            dc42 administrators @dc42
                            last edited by

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

                            Duet WiFi hardware designer and firmware engineer
                            Please do not ask me for Duet support via PM or email, use the forum
                            http://www.escher3d.com, https://miscsolutions.wordpress.com

                            Argoundefined 1 Reply Last reply Reply Quote 0
                            • Argoundefined
                              Argo @dc42
                              last edited by 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.

                              dc42undefined 1 Reply Last reply Reply Quote 0
                              • dc42undefined
                                dc42 administrators @Argo
                                last edited by

                                @argo thanks for confirming this.

                                Duet WiFi hardware designer and firmware engineer
                                Please do not ask me for Duet support via PM or email, use the forum
                                http://www.escher3d.com, https://miscsolutions.wordpress.com

                                1 Reply Last reply Reply Quote 0
                                • First post
                                  Last post
                                Unless otherwise noted, all forum content is licensed under CC-BY-SA