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

    RepRapFirmware 3.0

    Scheduled Pinned Locked Moved
    General Discussion
    35
    176
    30.6k
    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
      last edited by dc42

      I have been working on flexible pin allocation in RepRapFirmware. This is essential for Duet 3 because of its flexibility and expandability, and will also bring benefits to Duet 2.

      Implementing this has turned out to have much wider implications than I envisaged at first. Maintaining backwards compatibility with RRF 2.x would be complicated to implement, and hard for users to understand if they were trying to use any of the new features. So I think it best to implement these features in a new firmware series, which I am provisionally calling RepRapFirmware 3.

      I have documented my current proposal at https://duet3d.dozuki.com/Wiki/RepRapFirmware_3_overview. Much of this is already implemented - for example, heater and fan port allocation, and support for multiple independent motors and endstops on an axis without needing to create new axes for homing. But it's not frozen yet, and some parts remain to be implemented.

      So I would be grateful if experienced users of RepRapFirmware could take a look think of this proposal, and reply in this thread with their thoughts and any suggestions.

      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

      deckingmanundefined gnydickundefined 2 Replies Last reply Reply Quote 8
      • Edgars Batnaundefined
        Edgars Batna
        last edited by

        I do not consider myself an expert, but, since there are quite a lot of users of 1.x and 2.x now, perhaps a tool that upgrades the configuration automatically or semi-automatically would be useful? It could be embedded somewhere in the online configuration tool.

        dc42undefined 1 Reply Last reply Reply Quote 1
        • dc42undefined
          dc42 administrators @Edgars Batna
          last edited by

          @edgars-batna said in RepRapRirmware 3.0:

          I do not consider myself an expert, but, since there are quite a lot of users of 1.x and 2.x now, perhaps a tool that upgrades the configuration automatically or semi-automatically would be useful? It could be embedded somewhere in the online configuration tool.

          We will certainly have the online configtool take a config.json file that you saved earlier and generate a new config.g file for RRF 3 from it.

          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

          botundefined 1 Reply Last reply Reply Quote 2
          • dragonnundefined
            dragonn
            last edited by

            Looks like a lot of work but I like that idea, it will more clear to define everything. Some time ago I run into issue when assigning a new fan on a extra heater output, after some hours of debugging I found out that config-override.g PID settings where assigning my output back to a heater. As far I understand this would complete avoid such situation.

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

              @dragonn, yes it would avoid that situation. The present arrangement - whereby almost all pins are assigned to a function, so you have to disable that function to use the pin for something else - is a kludge.

              Many users could replicate the existing default functionality by adding some boilerplate commands at the start of config.g:

              M950 H0 P0
              M950 H1 P1
              M950 H2 P2
              M950 F0 P20
              M950 F1 P21
              M951 F2 P22
              M574 X1 P40
              M574 Y1 P41
              M574 Z1 P42
              

              But this wouldn't handle the following cases:

              • BLTouch: you need to allocate a servo pin using M950 and reference that pin in the M280 commands.
              • Filament monitors: you need to use logical pin numbers, not endstop numbers.
              • M585: if using a custom endstop, you need to configure a Z probe that uses it.
              • M281 triggers (which I haven't covered in the wiki page yet).
              • M577 (which I haven't covered yet).
              • Endstops for additional axes.
              • Anyone using a DueX expansion board.

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

                i think its a good idea to not always consider backwards compatibility.

                i have a suggestion for M584. Maybe it would be a good idea to insist on having to declare all driver mappings to make accidental double assignment impossible.

                dc42undefined 1 Reply Last reply Reply Quote 2
                • dc42undefined
                  dc42 administrators @Veti
                  last edited by

                  @veti said in RepRapRirmware 3.0:

                  i think its a good idea to not always consider backwards compatibility.

                  i have a suggestion for M584. Maybe it would be a good idea to insist on having to declare all driver mappings to make accidental double assignment impossible.

                  Good point, I hadn't considered making it compulsory to declare axis/extruder to driver mappings. We'll definitely want to do that on Duet 3, so perhaps we should on Duet 2 as well.

                  Very occasionally, users want to assign a motor as both an axis and an extruder. That's why we don't automatically undo an existing assignment to a driver when it is assigned to something.

                  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

                  Catalin_ROundefined 1 Reply Last reply Reply Quote 1
                  • Vetiundefined
                    Veti
                    last edited by

                    @dc42 said in RepRapFirmware 3.0:

                    Very occasionally, users want to assign a motor as both an axis and an extruder. That's why we don't automatically undo an existing assignment to a driver when it is assigned to something.

                    i am not saying that it should be prevented. you should still be allowed to assign them explicitly e.g.
                    M584 X0 Y1 Z2:3 E4:5:6 U4

                    1 Reply Last reply Reply Quote 0
                    • gtj0undefined
                      gtj0
                      last edited by

                      On the whole I like the idea and nothing jumped out at me that would be an issue. I think moving to a 2 step process and not being backwards compatible are perfectly acceptable tradeoffs to get the flexibility.

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

                        @dc42

                        Endstop and Z-probe ports are assigned in the M574 and M552 commands.

                        M552? Must mean M558.

                        Z-Bot CoreXY Build | Thingiverse Profile

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

                          @dc42 If I were you, I would forget about backwards compatibility! As things evolve, at some point a bold decision must be made and a clean sheet approach must be considered. As you mention, in the end, only changes to the config.g file, in order to properly configure things as they were in firmware versions 1 and 2, this is not a major problem.

                          In the end, based on my own experience with similar situations, with or without the full backwards compatibility roughly the same amount of support issues will appear on the forum.

                          I personally vote for this significantly improved flexibility in using the I/O capabilities of the boards. And, in the end, it might have the desirable side effect of removing some of the support issues related strictly to improperly configured or connected I/O pins (like the rather odd mapping of the homing/limit sensors). By having no default assignment and having to define everything in config.g would actually make things a lot easier to follow and some mistakes could easily be avoided. As such, I would make mandatory even the M584 command, not defining any default axis or extruders at all if it is not there!

                          On the issue of multiple steppers on the same axis, a solution similar to what I did for WorkBee should also be allowed. When squaring a CNC a known offset for a specific stepper on an axis might be required (try positioning a homing switch with 0.01mm accuracy!). But this can be discussed when time comes....

                          1 Reply Last reply Reply Quote 3
                          • deckingmanundefined
                            deckingman @dc42
                            last edited by

                            @dc42 Ref expansion boards, will the main board be considered as board 0 and expansion board numbers be from 1 onwards? Also, will the existing Duex2 and Duex 5 expansion boards be treated as such? e.g. at the moment pin numbers 23 to 27 are fans on the Duex boards so will pin 23 be referred to as pin 1.0 for example?

                            Ian
                            https://somei3deas.wordpress.com/
                            https://www.youtube.com/@deckingman

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

                              @deckingman said in RepRapFirmware 3.0:

                              @dc42 Ref expansion boards, will the main board be considered as board 0 and expansion board numbers be from 1 onwards?

                              Yes.

                              Also, will the existing Duex2 and Duex 5 expansion boards be treated as such? e.g. at the moment pin numbers 23 to 27 are fans on the Duex boards so will pin 23 be referred to as pin 1.0 for example?

                              I haven't decided that yet.

                              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

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

                                @dc42 said in RepRapFirmware 3.0:

                                Also, will the existing Duex2 and Duex 5 expansion boards be treated as such? e.g. at the moment pin numbers 23 to 27 are fans on the Duex boards so will pin 23 be referred to as pin 1.0 for example?

                                I haven't decided that yet.

                                Yes that could be a damned if you do, damned if you don't scenario. Current users of Duex might get upset if they have to change things, but future users will appreciate the consistency that all expansion boards are treated the same way. On the other hand, anyone upgrading to RRF 3.0 will have to make changes to their configuration files in any case, including those who use Duex expansion boards, so I wouldn't have thought that changing pin references would be a big deal. As a current user, I'd be happy with either approach but obviously that's just my own opinion.

                                Ian
                                https://somei3deas.wordpress.com/
                                https://www.youtube.com/@deckingman

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

                                  @dc42 would it be possible to write a utility to migrate from 2.x to 3.x?

                                  dc42undefined 1 Reply Last reply Reply Quote 0
                                  • botundefined
                                    bot @dc42
                                    last edited by

                                    @gnydick said in RepRapFirmware 3.0:

                                    @dc42 would it be possible to write a utility to migrate from 2.x to 3.x?

                                    @dc42 said in RepRapFirmware 3.0:

                                    @edgars-batna said in RepRapRirmware 3.0:

                                    I do not consider myself an expert, but, since there are quite a lot of users of 1.x and 2.x now, perhaps a tool that upgrades the configuration automatically or semi-automatically would be useful? It could be embedded somewhere in the online configuration tool.

                                    We will certainly have the online configtool take a config.json file that you saved earlier and generate a new config.g file for RRF 3 from it.

                                    *not actually a robot

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

                                      @gnydick said in RepRapFirmware 3.0:

                                      @dc42 would it be possible to write a utility to migrate from 2.x to 3.x?

                                      Writing one that always gets it right would not be practical. Besides, users who currently create additional temporary axes to home multiple axis motors with separate endstop will want to change to the new simper system, which handles multiple endstops per axis automatically.

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

                                        @dc42 Will this allow for more inputs to be defined? For example, using pins other than end-stop connectors for M577 or M581 commands?

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

                                          @nhof said in RepRapFirmware 3.0:

                                          @dc42 Will this allow for more inputs to be defined? For example, using pins other than end-stop connectors for M577 or M581 commands?

                                          Yes.

                                          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
                                          • dc42undefined
                                            dc42 administrators
                                            last edited by dc42

                                            I've had some further thoughts. Logical pin numbers are becoming a pain to allocate/administer/remember. So why not use port names instead? Here are some examples of a possible syntax, using Duet WiFi port names:

                                            ; Swap heaters 0 and 1
                                            M950 H0 P"nil"        ; detach heater 0 from BED_HEAT port
                                            M950 H1 P"bed_heat"   ; assign heater 1 to BED_HEAT port (implicitly detaches it from E0_HEAT)
                                            M950 H0 P"e0_heat"    ; assign bed heater to E0_HEAT port
                                            
                                            ; Use E1_HEAT for Fan0
                                            M950 H2 P"nil"        ; free up E1_HEAT
                                            M950 F0 P"e1_heat"
                                            
                                            ; Attach Fan 3 to the Fan0 output port + tacho input
                                            M950 F3 P"exp_pb6+fan0" ; note tacho port comes first because it is an input
                                            
                                            ; Assign 2 endstop switch inputs to the Y axis
                                            M574 Y1 P"y_stp+e0_stp"
                                            

                                            Provisional rules:

                                            • Port names correspond to the labels printed on the PCB next to the corresponding connectors
                                            • Port names are case-insensitive
                                            • Underscore and dash characters are stripped from port names before looking them up, so you can include them or omit them, your choice
                                            • Where multiple pins are permitted, use the + character to separate the pin names as in M574 example above
                                            • Where a command can use both an input and an output pin (e.g. Z probe, fan with tacho) then you can either use a port name that has both an input and an output, or you can use 2 ports separated by the + character with the input port first
                                            • Where a port provides both an input and an output, you can refer to just the input part by suffixing its name with _in, or just the output part by suffixing its name with _out
                                            • You can invert the sense of a port by prefixing its name with / (so we no longer need I0/I1 parameters)
                                            • On Duet 3, the names of ports on expansion boards shall be prefixed by the expansion board number and a period, for example "1.out0"

                                            Like it? Hate it? Suggestions for improvement?

                                            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