Duet3D Logo

    Duet3D

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

    Jobs showing progress before starting 3.4RC2

    Beta Firmware
    5
    7
    239
    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.
    • jay_s_uk
      jay_s_uk last edited by

      On a couple of printers I am running (one Duet 6HC based and the other Fly-Super8 based - both standalone), I am seeing a varied amount of % being complete before the printer has moved.
      Here is an example
      start.g.png
      This was a very small job and I think its linked to running a start.g file but I'm not fully sure.
      Here is one of my start.g files

      M118 S"Running start.g"
      if !move.axes[0].homed || !move.axes[1].homed || !move.axes[2].homed
      	G28
      ;G29 S1
      

      Is the start.g file being counted towards job progress?

      Owns various duet boards and is the main wiki maintainer for the Teamgloomy LPC/STM32 port of RRF. Assume I'm running whatever the latest beta/stable build is

      bberger 1 Reply Last reply Reply Quote 0
      • bberger
        bberger @jay_s_uk last edited by

        @jay_s_uk I have the same on a Duet Wifi (Standalone), but it's been like that for quite a while.

        But in my case it's like 30% or sometimes even more progresss. The times and estimates are correct, but it completely screws with the percentage.

        1 Reply Last reply Reply Quote 1
        • jay_s_uk
          jay_s_uk last edited by

          or could it be linked to thumbnails in files now?
          Not sure if I saw this before RC1 or not

          Owns various duet boards and is the main wiki maintainer for the Teamgloomy LPC/STM32 port of RRF. Assume I'm running whatever the latest beta/stable build is

          oozeBot 1 Reply Last reply Reply Quote 1
          • oozeBot
            oozeBot @jay_s_uk last edited by

            @dc42 - I think Jay is right in that this is being caused by the embedded thumbnails as we never noticed this prior to enabling them. I think (guessing, really) RRF must be using file length / file position to report progress and the thumbnails are taking up 20~30% at the top of the file..

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

              @oozebot that could be the reason when printing small GCode files. To fix it we would need to scan the start of the file to see where the real GCode starts.

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

                This still occurs on 3.4.1-RC1

                Owns various duet boards and is the main wiki maintainer for the Teamgloomy LPC/STM32 port of RRF. Assume I'm running whatever the latest beta/stable build is

                Phaedrux 1 Reply Last reply Reply Quote 0
                • Phaedrux
                  Phaedrux Moderator @jay_s_uk last edited by

                  @jay_s_uk I think it's planned fix for 3.5.

                  Z-Bot CoreXY Build | Thingiverse Profile

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