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

    Simulated time turns N/A before print ends

    Scheduled Pinned Locked Moved
    General Discussion
    3
    18
    507
    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.
    • JayTundefined
      JayT @chrishamm
      last edited by

      @chrishamm :
      Thank you for reply.
      Starting part of the Gcode is as follows.


      ;FLAVOR:RepRap
      ;TIME:10417
      ;Filament used: 12.9333m, 17.0185m
      ;Layer height: 0.3
      ;MINX:227.3
      ;MINY:241.8
      ;MINZ:0.3
      ;MAXX:357.798
      ;MAXY:358.2
      ;MAXZ:16
      ;Generated with Cura_SteamEngine 5.0.0
      T0
      M190 S60
      M104 S190
      M104 T1 S190
      M109 S190
      M109 T1 S190
      M82 ;absolute extrusion mode
      G1 Z15.0 F6000 ;Move the platform down 15mm
      ;Prime the extruder
      G92 E0
      G1 F200 E3
      G92 E0
      M83 ;relative extrusion mode
      G1 F1200 E-1
      ;LAYER_COUNT:50
      ;LAYER:0
      M107

      Do you find any problem in above code?

      Observation: Generally the time when simulated time = N/A , print runs for 4-7 mins more.

      What do you suggest ?600_dual file_2h53m_90g.gcode

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

        @JayT do you still think the problem is what the estimate calculated from simulating doesn't take account of heating time?

        What should happen is that while the printer is heating up, the estimated time left calculated from the simulation should stop counting down until heating is complete. Is this what you observe?

        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

        JayTundefined 1 Reply Last reply Reply Quote 1
        • JayTundefined
          JayT @dc42
          last edited by

          @dc42 : Yes for latter point.

          1. When I connect DWC warm up time = bed heating time. IT does not account extruder heating time. so instead of >3mins, I get warmupduration = 30-40s

          2. Since simulation count down starts as soon as print is clicked, extruder (that takes 3-4 mins)-heatingtime is lost. So at the end, when 3-4 mins of printing is pending, simulation time displays = N/A.

          So As you stated, either in the code we have to stop counting down until extruder is heated up. OR Account warm up duration of extruder.

          As per Gcode above, do you see reason why extruder time is not accounted?

          I want to fix this by stopping simulation time count down until extruder heats up. how to do that? (which code file to check)?

          chrishammundefined 1 Reply Last reply Reply Quote 0
          • chrishammundefined
            chrishamm administrators @JayT
            last edited by

            @JayT Thanks, I could reproduce and fix this problem. You can work-around it by replacing

            M109 T1 S190
            

            with

            G10 P1 S190
            M116
            

            Duet software engineer

            JayTundefined 1 Reply Last reply Reply Quote 1
            • JayTundefined
              JayT @chrishamm
              last edited by JayT

              @chrishamm :
              Thank you.
              So you are suggesting to modify this in Gcode each time?

              What if I don't want USER to each time modify this in Gcode? Can we do some setting in CURA to generate like this?

              OR Update something in code?

              P.S.: I will try this and let you know if this fix works at my end too. but looking for a solution where-in USER need not modify Gcode each time.

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

                @JayT we've fixed this in RRF 3.5.0-beta3 which we hope to release later today. I have also back-ported the fix ready for the 3.4.6 release.

                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

                JayTundefined 1 Reply Last reply Reply Quote 1
                • JayTundefined
                  JayT @dc42
                  last edited by

                  @dc42 : Thanks David.

                  I will wait for it.
                  But my problem is for one customer I need to fix this on urgent basis. 😞 Can you share the fix from Github branch for me to incorporate quickly ?

                  Also can you suggest what all things we need to align in Slicer, to get simulated time = slicer time?

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

                    @JayT the commit to the 3.4-dev branch is this one https://github.com/Duet3D/RepRapFirmware/commit/5a5976a0e87fb6b2b05feaf8028b38229caf3459. It's not tested in 3.4.x yet.

                    The closest correspondence I have seen between simulated and slicer-estimated time was when the slicer was n8bot's fork of PrusaSlicer, with firmware set to RepRapFirmware and the machine parameters fetched from the Duet over the network. Last time I checked, the associated PR hadn't been accepted by Prusa yet.

                    0 chrishamm committed to Duet3D/RepRapFirmware
                    Fixed warm-up counter during M109

                    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

                    JayTundefined 1 Reply Last reply Reply Quote 1
                    • JayTundefined
                      JayT @dc42
                      last edited by JayT

                      @dc42 @chrishamm :

                      Thanks. I would try that.
                      However, with this fix, do I have to fix the Gcode each time to include M116 as Chris stated above?

                      Still sometimes I see job duration time != (simulation + heating time). what can be the cause for this?

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

                        @JayT changing the M109 command to M104 followed by M116 is a workaround for the bug. The fix to the RRF source code removes the need for the workaround.

                        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 2
                        • First post
                          Last post
                        Unless otherwise noted, all forum content is licensed under CC-BY-SA