RepRapFirmware 3.0

[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.

[Edgars Batna]

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.

[dc42]

@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.

[dragonn]

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.

[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.

[Veti]

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.

[dc42]

@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.

[Veti]

@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

[gtj0]

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.

[Phaedrux]

@dc42

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

M552? Must mean M558.

[Catalin_RO]

@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....

[deckingman]

@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?

[dc42]

@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.

[deckingman]

@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.

[gnydick]

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

[bot]

@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.

[dc42]

@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.

[nhof]

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

[dc42]

@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.

[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?