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