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

    Simulated time turns N/A before print ends

    Scheduled Pinned Locked Moved
    General Discussion
    3
    18
    508
    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.
    • dc42undefined
      dc42 administrators @JayT
      last edited by

      @JayT I looked at the PanelDue code recently and it already tries to account for warmUpDuration:

      		if (simulatedTime > 0)
      		{
      			timesLeftText.copy(strings->simulated);
      			AppendTimeLeft(simulatedTime + jobWarmUpDuration - jobDuration);
      			++count;
      		}
      

      That's at line 1501 of https://github.com/Duet3D/PanelDueFirmware/blob/master/src/UI/UserInterface.cpp.

      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 0
      • JayTundefined
        JayT @dc42
        last edited by

        @dc42 : it accounts for WarmUp duration, but warmUpduration sometimes considers only Bed heater's time and not Extruder's time . One way I can fix it for my machine is by just including condition to start decrement of simulation time when actual printing starts.

        Can you direct me where I can include this in the code, which code?

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

          @JayT The warm-up duration is only increased while M109/M116/M190/M191 is executed so it should work for extruders as well. What's your start G-code?

          Duet software engineer

          JayTundefined 1 Reply Last reply Reply Quote 1
          • 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