Navigation

    Duet3D Logo

    Duet3D

    • Register
    • Login
    • Search
    • Categories
    • Tags
    • Documentation
    • Order

    [Poll] Time estimates on PanelDue 5"/7"

    PanelDue
    13
    23
    298
    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.
    • wilriker
      wilriker Moderator last edited by wilriker

      Since there are repeated and scattered requests to bring slicer time as an estimate to PanelDue and we only have limited space to show this information, I want to start a poll about opinions of what users want to see. Below you'll find a poll for larger-resolution screens of 5" and 7" PanelDue and a second for the smaller 4.3" variant here. I ask you to vote only for the screen you have or plan to get.

      These polls will run until 2021-03-14. Each user has up to three votes.

      Manuel
      Duet 3 6HC (v0.6) with RPi 4B on a custom Cartesian
      with probably always latest firmware/DWC (incl. betas or self-compiled)
      My Tool Collection

      nikscha Stephen6309 2 Replies Last reply Reply Quote 0
      • nikscha
        nikscha last edited by

        Maybe clarify how these times are calculated?

        • Layer time predicts based on previous layer times and the amount of remaining layers, right?
        • File time looks at the remaining lines in the file and the average time to process a line?
        • Filament time, no clue...
        • Slicer time, magic probably,
        • Simulated time; I see that for the first time to be honest

        To me filament time is the "least meaningful" so I am going to vote that out

        dc42 1 Reply Last reply Reply Quote 0
        • nikscha
          nikscha @wilriker last edited by

          @wilriker Are we supposed to vote for a single item or multiple?

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

            @nikscha said in [Poll] Time estimates on PanelDue 5"/7":

            To me filament time is the "least meaningful" so I am going to vote that out

            Out of layer time, file time and filament time, filament time tends to be the most accurate. I look at simulated time if available, otherwise filament time. Layer time is typically the least accurate, and I wouldn't miss it if it went.

            Filament time looks at the total filament needed for the job (as reported by the slicer), the amount of filament consumed so far, and how long it took to consume that filament. It tends to over-estimate the time at the very start of the print because the first layer is usually printed at a lower speed.

            The layer-based estimate is next to useless IMO.

            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

            zapta 1 Reply Last reply Reply Quote 1
            • T3P3Tony
              T3P3Tony administrators last edited by

              To muddy the water could it possible to have a hierarchy of times:

              "simulated time" is likely to be the most accurate - but only useful if the print has been simulated. If that's not available then slicer time (if the printer parameters are configured correctly in the slicer) is probably the second best bet. After that then filament/file time?

              Duet Hardware Designer
              www.duet3d.com

              wilriker 1 Reply Last reply Reply Quote 0
              • wilriker
                wilriker Moderator @T3P3Tony last edited by

                @T3P3Tony Basically everything is possible for up to three times. Hierarchies are no problem.

                @nikscha

                • Layer time uses the average of previous layers and applies it to the remaining amount of layers.
                • File time just looks at bytes processed vs. remaining bytes (no lines/instructions, just pure file size)
                • Filament time is based on what the slicer puts into the file as amount of required filament vs. amount of filament already extruded.

                The above three are all calculated within RRF and provided to PanelDue

                • Slicer time is what the slicer calculated it will take - this can vary wildly based on how accurate you can represent your printer configuration withing your slicer
                • Simulated time is what RRF simulated (optionally) it will take - since this is accurately based on your settings this is the most accurate it can get.

                The above tow are precalculated at some point in time and would simply be counted down. Main disadvantage is that they do no contain heating times and will be very inaccurate for very short jobs but this will even out for longer jobs.

                Manuel
                Duet 3 6HC (v0.6) with RPi 4B on a custom Cartesian
                with probably always latest firmware/DWC (incl. betas or self-compiled)
                My Tool Collection

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

                  Also worth mentioning is that when DAA or more general forms of input shaping are used, the slicer time will be less accurate, because the slicer doesn't know what input shaping your machine is using. Simulated time should continue to be accurate.

                  OTOH the slicer does know about things like the first layer being printed slower than the rest, and the last layers being printed slower if a minimum layer time is in effect. Filament-based time estimates take a while to catch up with print speed changes caused by those features.

                  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
                  • garyd9
                    garyd9 last edited by garyd9

                    While only 3 can be displayed at a time, if the "simulated" time is one of those included, the firmware should display an alternative time if/when the simulated time isn't available.

                    For example, it might display the slicer time when simulated isn't available, and some other time if neither simulated nor slicer times are available. That implies that parsing for all types of times is available in the firmware, so perhaps a better poll would be: What would be the priority order for displaying the times?

                    It might be important to note that the only time that is ALWAYS going to be available is the "file" estimate. The others all depend on RRF being able to parse certain information out of the gcode file (or a simulation having been run.)

                    "I'm not saying that you are wrong - I'm just trying to fit it into my real world simulated experience."

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

                      @garyd9 said in [Poll] Time estimates on PanelDue 5"/7":

                      While only 3 can be displayed at a time, if the "simulated" time is one of those included, the firmware should display an alternative time if/when the simulated time isn't available.

                      For example, it might display the slicer time when simulated isn't available, and some other time if neither simulated nor slicer times are available.

                      I agree. if a simulated time is available then I'd like to see that. If not, then perhaps slicer time (if available) and filament-based time (which is nearly always available for 3D prints, but not of course for CNC jobs).

                      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 1
                      • stevenwm
                        stevenwm last edited by

                        Adding my 2 cents, I would also prefer to see the slicer time if it is available. At least for all my machines that I use RRF/PanelDue on, the slicer time is and has always been more accurate than the others provided. I've never seen it off more than the warm-up time.

                        1 Reply Last reply Reply Quote 0
                        • resam
                          resam last edited by

                          Why not make it configurable so we can choose whatever we want or feel works best for our printers?

                          e.g.., in config.g introduce a new M-code for PanelDue config:
                          M996 P"filament,layer,simulation" to set it, and a plain M996 to retrieve the list of keys (which PanelDue needs to query during start-up). With the correct object model keys from https://github.com/Duet3D/PanelDueFirmware/blob/09397d29fd9c521c307b6a5679209b892d1c0a2a/src/PanelDue.cpp#L465-L467

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

                            @dc42 said in [Poll] Time estimates on PanelDue 5"/7":

                            Layer time is typically the least accurate, and I wouldn't miss it if it went.

                            Do we need more than one reasonable time estimation?

                            As for layer and filament consumption/progress, if needed, they can be reported in layer or meter units rather than translated to time unit.

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

                              Having more than one estimate is useful to me because the closer they agree, the more confidence I have in them. Also, if I have adjusted the speed during the print, then the slicer and simulation estimates will no longer be accurate.

                              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

                              zapta 1 Reply Last reply Reply Quote 1
                              • dc42
                                dc42 administrators last edited by

                                Would anyone miss print time estimations based on layer times if I removed it? It's rarely accurate, the implementation is complex, and as slicers get more sophisticated (e.g. supporting variable layer height), it breaks more often.

                                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

                                oozeBot garyd9 2 Replies Last reply Reply Quote 3
                                • fcwilt
                                  fcwilt last edited by

                                  I pay no attention to any of the estimates.

                                  My "research" shows conclusively that the print will finish when it is done.

                                  The only thing I watch is the current layer\total layers numbers.

                                  Frederick

                                  Printers: A FT-5 with the 713 upgrade bits. A custom MarkForged style. A small Utilmaker style and a CoreXY from kits. Various hotends. Using Duets (2 and 3) running 3.4.1

                                  1 Reply Last reply Reply Quote 0
                                  • Stephen6309
                                    Stephen6309 @wilriker last edited by

                                    @wilriker Simulated time. Now if that would be added to the file in SBC mode would be great.

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

                                      @dc42 said in [Poll] Time estimates on PanelDue 5"/7":

                                      Would anyone miss print time estimations based on layer times if I removed it? It's rarely accurate, the implementation is complex, and as slicers get more sophisticated (e.g. supporting variable layer height), it breaks more often.

                                      I sure wouldn't miss it.

                                      My vote would be Simulated time if available, followed by Slicer time.

                                      While we are here, why aren't actual print times stored after a print completes successfully? Why couldn't it be Actual/Simulated where either or populates the value?

                                      1 Reply Last reply Reply Quote 1
                                      • zapta
                                        zapta @dc42 last edited by

                                        @dc42 said in [Poll] Time estimates on PanelDue 5"/7":

                                        Having more than one estimate is useful to me because the closer they agree, the more confidence I have in them.

                                        On the other hand, when they don't agree, we need to guess which is is accurate, and question the duet for providing such an off the mark estimation.

                                        Also, if I have adjusted the speed during the print, then the slicer and simulation estimates will no longer be accurate.

                                        Can't this be done with the slicer info, since it provides a better linearization of the work time than file size or layer?

                                        For example, the duet can start with providing actual estimated time and as the print progresses give higher weight to a (1 - fraction_done) * time_so_far style estimation where fraction_done is derived from the slicer's minute and percent markers.

                                        Just a thought.

                                        BTW, another interesting time estimation is to the next user event. If I define a pause at level x to perform an operation (e.g. inserting a captive magnet), the slicer also shows the time to that operation. I am not sure if it's propagated in the gcode.

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

                                          @dc42 said in [Poll] Time estimates on PanelDue 5"/7":

                                          Would anyone miss print time estimations based on layer times if I removed it? It's rarely accurate, the implementation is complex, and as slicers get more sophisticated (e.g. supporting variable layer height), it breaks more often.

                                          I certainly would not miss the layer time estimate.

                                          "I'm not saying that you are wrong - I'm just trying to fit it into my real world simulated experience."

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

                                            Taking account of the feedback so far, I propose to remove the estimate based on counting layers, and add an estimate based on the time that the slicer provided, supplemented by M73 commands in the file if they are present.

                                            RRF will still provide a layer number in the OM for DWC and PanelDue to display, however it will be derived from comments inserted by the slicer instead of RRF trying to work it out from changes in Z height. So if the slicer doesn't provide layer comments that RRF recognises, then current layer number will not be available.

                                            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
                                            • ZipZap
                                              ZipZap @wilriker last edited by ZipZap

                                              @wilriker said in [Poll] Time estimates on PanelDue 5"/7":

                                              • Slicer time is what the slicer calculated it will take - this can vary wildly based on how accurate you can represent your printer configuration withing your slicer

                                              That is quite right. For slicers like S3D its a huge problem, because you can't apply acceleration and jerk into the calculation of the time (not without post-processing). In my case, a file from S3D takes about 20-25% longer than estimated.
                                              The most accurate for me is also the filament-time after a few layers (like DC42 explained), to tell when the print is finished.

                                              /Julien

                                              Most important guide -> Triffid Hunter's Calibration Guide
                                              HyperCube EVO (derivate) in 250x250x300 - enclosed for ABS - Duet2WiFi - custom watercooling

                                              1 Reply Last reply Reply Quote 0
                                              • Surgikill
                                                Surgikill last edited by

                                                Layer time needs to go. It's useless if you have gcode set up in your slicer to move the z axis at the end of a print. Filament time is the most accurate so far.

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

                                                  We have removed the estimate from layer times in RRF 3.3beta2. It took up a significant amount of code space, didn't work at all in some cases, and was usually inaccurate even when it did work.

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