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

RepRapFirmware 3.2 planned improvements

Scheduled Pinned Locked Moved
General Discussion
28
99
6.3k
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.
  • undefined
    dc42 administrators
    last edited by 13 May 2020, 13:42

    It's on the list for implementation, but IMO it's pointless as long as jerk or junction deviation is needed at corners. The first-order motion components need to be made continuous before or at the same time as worrying about third and high order components.

    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

    undefined undefined 2 Replies Last reply 13 May 2020, 15:27 Reply Quote 0
    • undefined
      Nuramori
      last edited by 13 May 2020, 14:13

      This post is deleted!
      1 Reply Last reply Reply Quote 0
      • undefined
        bot @dc42
        last edited by bot 13 May 2020, 15:27

        @dc42 Is there anything that a slicer could output to make improved motion planning easier for the firmware?

        I've been playing around with IceSL, which requires a LUA script to process the sliced model and generate gcode output. And therefore, we have an opportunity to use the raw, non-truncated, slice geometry data before it is turned to gcode and calculate anything we wish and format it alongside the gcode in any way we wish.

        Unfortunately, the underlying slicer does not generate curves. But, we can calculate angles, segment lengths, extrusion rates, etc. in the slicer and offload that from the FW.

        I'm currently making a RRF-specific printer profile for IceSL, which is basically just implementing all the features duet users expect, and producing gcode compatible with RRF.

        Long story short, we have the possibility now to do high-precision pre-processing of the gcode at the same time that we slice it.

        *not actually a robot

        1 Reply Last reply Reply Quote 1
        • undefined
          Bipotronic
          last edited by 13 May 2020, 18:36

          Implementation of Variables of GCode Meta Comments would be useful. Or is this function already implemented?

          1 Reply Last reply Reply Quote 0
          • undefined
            zapta @dc42
            last edited by 14 May 2020, 01:11

            @dc42 said in RepRapFirmware 3.02 planned improvements:

            Do you mean the M73 command?

            Yes, M73. This is what I got from in a 22minutes (estimated) gcode file:

            M73 P0 R22
            M73 P0 R22
            M73 P4 R21
            M73 P9 R20
            M73 P13 R19
            M73 P18 R18
            M73 P22 R17
            M73 P27 R16
            M73 P31 R15
            M73 P36 R14
            M73 P40 R13
            M73 P45 R12
            M73 P49 R11
            M73 P54 R10
            M73 P58 R9
            M73 P63 R8
            M73 P67 R7
            M73 P72 R6
            M73 P76 R5
            M73 P81 R4
            M73 P85 R3
            M73 P90 R2
            M73 P94 R1
            M73 P99 R0
            M73 P100 R0
            

            In the early phases of the print probably the remaining time R is more useful for the estimation and in later phase probably the percentage P and actual time so far will give a better estimation.

            The markers seem to be in (estimated) 1 minute intervals.

            1 Reply Last reply Reply Quote 0
            • undefined
              dc42 administrators
              last edited by 14 May 2020, 09:43

              I've added M73 to the list for consideration.

              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

              undefined 2 Replies Last reply 14 May 2020, 15:06 Reply Quote 0
              • undefined
                zapta @dc42
                last edited by 14 May 2020, 15:06

                @dc42 said in RepRapFirmware 3.02 planned improvements:

                I've added M73 to the list for consideration.

                Thanks.

                1 Reply Last reply Reply Quote 0
                • undefined
                  CCS86 @dc42
                  last edited by 15 May 2020, 04:15

                  @dc42 said in RepRapFirmware 3.02 planned improvements:

                  It's on the list for implementation, but IMO it's pointless as long as jerk or junction deviation is needed at corners. The first-order motion components need to be made continuous before or at the same time as worrying about third and high order components.

                  What is causing that dependance?

                  1 Reply Last reply Reply Quote 0
                  • undefined
                    zapta @dc42
                    last edited by 16 May 2020, 05:37

                    @dc42, FYI, I run a small experiment correlating the M73 markers with actual prints (replaced them with G10 and M140 that propagated the values to standby fields in the json). Results look very good, both for linearity and absolute time values.

                    My slicer has default setting, without any calibration for the max speed, acceleration and jerk of my printer.

                    You can probably run tests much faster using simulator mode.

                    8dc1b42b-0963-4e2a-b0d7-d4b0cb1c656d-image.png

                    5d9ac3fb-8df1-431a-89e6-2d215f0f9439-image.png

                    1 Reply Last reply Reply Quote 0
                    • undefined
                      copystring
                      last edited by 17 May 2020, 10:30

                      Please add inverted M80/M81 for meanwell PSUs.
                      I know. I'm inpatient. Is it a lot of work to implement this?

                      undefined 1 Reply Last reply 17 May 2020, 11:37 Reply Quote 1
                      • undefined
                        SpoonUnit
                        last edited by 17 May 2020, 10:59

                        Could the option be added to set the min limit for behaviours similar to that controlled my M190. A default of 41 seems fine, but ultimately arbitrary, and having the option to hand control of this value to the operator would be nice. M143 sets max limits, perhaps it could be overloaded to support specifying min limits also?

                        1 Reply Last reply Reply Quote 0
                        • undefined
                          droftarts administrators @dc42
                          last edited by 17 May 2020, 11:02

                          @dc42 really looking forward to playing with G5 Bezier curves!

                          Ian

                          Bed-slinger - Mini5+ WiFi/1LC | RRP Fisher v1 - D2 WiFi | Polargraph - D2 WiFi | TronXY X5S - 6HC/Roto | CNC router - 6HC | Tractus3D T1250 - D2 Eth

                          1 Reply Last reply Reply Quote 0
                          • undefined
                            dc42 administrators @copystring
                            last edited by 17 May 2020, 11:37

                            @copystring said in RepRapFirmware 3.02 planned improvements:

                            Please add inverted M80/M81 for meanwell PSUs.
                            I know. I'm inpatient. Is it a lot of work to implement this?

                            This is included in the planned work to make the PS_ON pin configurable.

                            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
                            • arhiundefined
                              arhi @dc42
                              last edited by arhi 17 May 2020, 13:47

                              @dc42

                              Support G5

                              Does this involve maybe also G15 / G16 ? (I don't know if any slicer know how to use them, I only used them when I wrote code manually on my old milling machine)

                              1 Reply Last reply Reply Quote 0
                              • undefined
                                DaveA
                                last edited by 17 May 2020, 14:16

                                Maybe I'm just more confused than normal but I don't understand the versioning system.
                                Is 3.1.0, soon to be 3.1.1, not the latest stable release? If so, why is the next version going to be 3.02?

                                ? undefined 2 Replies Last reply 17 May 2020, 14:36 Reply Quote 0
                                • ?
                                  A Former User @DaveA
                                  last edited by A Former User 17 May 2020, 14:36

                                  @DaveA understandable confusion; the current 3.1.0 was supposed to be 3.01 until about the day it was released, presumably what would be 3.02 will be 3.2.0.

                                  1 Reply Last reply Reply Quote 0
                                  • undefined
                                    dc42 administrators @DaveA
                                    last edited by dc42 17 May 2020, 15:08

                                    @DaveA said in RepRapFirmware 3.02 planned improvements:

                                    Maybe I'm just more confused than normal but I don't understand the versioning system.
                                    Is 3.1.0, soon to be 3.1.1, not the latest stable release? If so, why is the next version going to be 3.02?

                                    The next stable release, not counting patch releases such as 3.1.1, will now be called be 3.2.0. I have changed the title of this thread.

                                    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
                                    • undefined
                                      garyd9
                                      last edited by 18 May 2020, 16:13

                                      I'm hoping requests for 3.2 will also be entertained: Extend M409 to allow multiple keys to be requested.

                                      For example, assume something embedded that wants to determine how much time is probably left in a print (using the simulated time) would need to request job.file.simulatedTime as well as job.duration. Having to request the entire 'job' key to 3 levels deep can result in a large buffer. Having to make 2 M409 requests doubles the time needed to get the information.

                                      On the other hand, if M409 supported multiple keys, the request and response could be simplified:

                                      M409 K"job.duration","job.file.simulatedTime"

                                      (For discussion, I've also started a new thread: https://forum.duet3d.com/topic/16450/m409-multiple-keys-at-once)

                                      "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
                                      • oliofundefined
                                        oliof
                                        last edited by 18 May 2020, 23:08

                                        Regarding line item 48: According to Marlin docs, UBL does support loading an existing mesh and applying 3-point or grid based tilt adjustment.

                                        <>RatRig V-Minion Fly Super5Pro RRF<> V-Core 3.1 IDEX k*****r <> RatRig V-Minion SKR 2 Marlin<>

                                        1 Reply Last reply Reply Quote 0
                                        • jay_s_ukundefined
                                          jay_s_uk
                                          last edited by 14 Sept 2020, 15:12

                                          Is the spreadsheet in the first post still being maintained?
                                          Does the equivalent exist for 3.3?

                                          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

                                          undefined 1 Reply Last reply 14 Sept 2020, 15:45 Reply Quote 0
                                          • First post
                                            Last post
                                          Unless otherwise noted, all forum content is licensed under CC-BY-SA