RepRapFirmware 3.0
-
@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 -
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.
-
-
@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....
-
@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?
-
@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 -
@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.
-
@dc42 would it be possible to write a utility to migrate from 2.x to 3.x?
-
@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.
-
@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.
-
@dc42 Will this allow for more inputs to be defined? For example, using pins other than end-stop connectors for
M577orM581commands? -
@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
M577orM581commands?Yes.
-
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?
-
As someone with is a lite bit familiar with microcontroller programming I dislike it. I much more prefer using some numbers.
This is special the case when using some outputs on the 40 pin header when not having Duex board. Those are just generic pins names and a heater pin isn't any different to a fan pin on it.But I understand that for some users it maybe more user friendly.
-
@dragonn, thanks for your feedback.
As someone with is a lite bit familiar with microcontroller programming I dislike it. I much more prefer using some numbers.
This is special the case when using some outputs on the 40 pin header when not having Duex board. Those are just generic pins names and a heater pin isn't any different to a fan pin on it.The expansion connector pins are named on the underside of the board. I was intending to use those names, possibly prefixed by "exp". Would you find that acceptable? Or possibly "exp_nn" where nn is the pin number on the connector.
-
Yeah, that would be nice. exp_nn woulde be perfect.
-
@dc42 Here is my twopence worth as a mechanical engineer (retired) and not someone who spends a great deal of time looking at lines of code.
Using port names rather than pin numbers might help - it certainly won't do any harm. But I tend to fit boards into enclosures before I start wiring them up, so labels on the underside wouldn't be legible. I'd probably just print hard copy of an image of the board showing the labels and keep this in a handy folder (much as I do now).
I like the idea of stripping out underscores and making port names case insensitive. In my file naming and when I use OpenScad and such like, I have become used to using a format such as "bedHeat" so presumably that would work just as well as "bed_heat".
On the subject of stripping out characters, would it be possible to have the option of using "Port" instead of "P"? What I means by that is only the "P" is significant and the "ort" would be stripped out. Likewise "Heater0" instead of "H0" and "Fan1" instead of "F1". I appreciate that writers of code like to cut down on the amount of typing required, but as a non-writer of code, it would make files much more readable - especially when revisiting them in say 6 months time.
For me, something like M950 Heater1 Port"bedHeat" is much more meaningful than M950 H1 P"bed_heat".
Just a thought but if it's too much work then I can live with it.........
-
@dc42 IIRC we had a discussion a while back about being able to use the silkscreened identifiers for configuration and I think the consensus was that it was better than using logical pin numbers. But two concerns... (well one and a suggestion) What happens if/when the silkscreened names diverge between board generations? I.E. A pin is named differently on the Duet2 Wifi than the Duet3. Would you need to use the different names or would you keep a synonym table in RRF? If you need to use different names, then it might make it difficult to use the same config on multiple printers if they were otherwise the same just with different boards.
Suggestion: Use "!" for the invert character. It's more generally accepted for negation.
-
David
I like it it and can see that all of this will help down the line. Personally I don't use the configurator (maybe because it wasn't around when I first started with RRF back in the 0.9x period) I think that it can make people lazy and then they start shouting when things don't go exactly right for them but that is not the point here. The flexibility this approach will give will be immense.
I say go for it
Doug
-
I like it. Far less abstract than just numbers. I think that would be more user friendly.
