RepRapFirmware 3.0

bot

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

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

dragonn

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.

dc42

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

dragonn

Yeah, that would be nice. exp_nn woulde be perfect.

deckingman

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

gtj0

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

Dougal1957

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

Phaedrux

I like it. Far less abstract than just numbers. I think that would be more user friendly.

dc42

@gtj0, thanks for your feedback. Duet 3 will have completely different pin naming from Duet 2 and will need a different config.g file for other reasons. I'll consider your suggestion to use ! instead of /.

Alexander Mundy

Another vote for ! given I'm used to it's meaning.

dc42

RepRapFirmware 3.0beta1 is alive! Pin numbers have been replaced by pin names, multiple homing switches per axis are supported natively, and any device can be mapped to any available pin within reason, except for dedicated pins such as those controlling stepper motors.

The brave amongst you can try the Duet WiFi/Ethernet firmware binary at https://www.dropbox.com/s/fyvibzm0zl92hiy/Duet2CombinedFirmware.bin?dl=0. To assist with backwards compatibility and novice users, I have kept the default heater, fan and XYZ endstop pin allocations for the Duet main board. So some printers (including my delta) can use this new firmware without any configuration changes. However, many printers will need configuration changes, which are described (with examples) at https://duet3d.dozuki.com/Wiki/RepRapFirmware_3_overview.

This is not an official beta. So use it with caution - for example, keep an eye on temperatures, test the Z probe and endstop switches before you rely on them, and reduce the motor currents until you are sure that they are working properly.

Note: M581 triggers are not supported in this beta.

Catalin_RO

@dc42 Minor typo on the wiki page, in the M453 section, the new format shows M452.

I will try to have a quick test one of these days as I'm most interested in seeing how the automatic squaring of the gantry of my WorkBee will work. With current firmware, while the dual axis are split for homing, I also apply a small correction on one of them due to the difficulty to precisely position the homing switches and, even for perfectly positioned switches, the minor mechanical differences between them. Right now my homey.g file looks something like this:

M581 Y U S-1 T0 C0        ; disable trigger for endstops Y and U
M584 Y1 U3 P4             ; separate Y and U axis for aligning them independently
G91                       ; relative positioning
G1 S1 Y-1500 U-1500 F1000 ; move quickly to Y and U axis endstops and stop there (first pass)
G0 Y5 U5                  ; go back a few mm
G1 S1 Y-10 U-10 F100      ; move slowly to Y axis endstop once more (second pass)
G0 Y0.09                  ; fully align gantry
M584 Y1:3 U9 P3           ; combine again the master and slave Y axis
G0 Y1                     ; go back a few mm
G90                       ; absolute positioning
G92 Y0                    ; reset the Y coordinate
M581 Y U S1 T0 C0         ; enable trigger for endstops Y and U

Even with the new firmware I would have to separate the two axis for the G0 Y0.09 command that compensates for the difference in switches positions. It would be nice to have, maybe only during homing and only while in relative mode, the possibility to issue a command like G0 Yaaa:bbb (the final retract, after the slow speed pass, a single G0 Y1.09:1.00 would handle the situation, combining the precise gantry alignment with the small retract). Alternatively, a solution for specifying a per axis alignment offset would be equally good, with immediate compensation through applying the corresponding number of steps.

In my dual Y axis setup I have also installed limit switches (connected in series to the homing ones) to handle possible configuration problems and missed steps. If an axis has multiple steppers and multiple homing switches, will the M581 defined triggers handle them properly?

fma

About pin names vs pin numbers, is it not possible to have both available? I think it could be handled by a simple internal table in RRF code...

dc42

@fma said in RepRapFirmware 3.0:

About pin names vs pin numbers, is it not possible to have both available? I think it could be handled by a simple internal table in RRF code...

IMO it is bad design to provide multiple ways of doing the same thing. It confuses users and increases demand for support.

dc42

@catalin_ro said in RepRapFirmware 3.0:

@dc42 Minor typo on the wiki page, in the M453 section, the new format shows M452.

Thanks, I fixed that and a couple of others.

Even with the new firmware I would have to separate the two axis for the G0 Y0.09 command that compensates for the difference in switches positions. It would be nice to have, maybe only during homing and only while in relative mode, the possibility to issue a command like G0 Yaaa:bbb (the final retract, after the slow speed pass, a single G0 Y1.09:1.00 would handle the situation, combining the precise gantry alignment with the small retract). Alternatively, a solution for specifying a per axis alignment offset would be equally good, with immediate compensation through applying the corresponding number of steps.

That could be done, but it's a lot of work to do for just one or two users. It is really that difficult to adjust one of the endstop positions or add a shim to get them both to trigger at the same point?

In my dual Y axis setup I have also installed limit switches (connected in series to the homing ones) to handle possible configuration problems and missed steps. If an axis has multiple steppers and multiple homing switches, will the M581 defined triggers handle them properly?

RRF 3 doesn't yet implement M581. I intend to change M581 to work with a single input, also I will add a facility to cause an emergency stop if any axis endstops are triggered unexpectedly.

A Former User

@dc42 said in RepRapFirmware 3.0:

multiple homing switches per axis are supported natively,

@dc42 said in RepRapFirmware 3.0:

I will add a facility to cause an emergency stop if any axis endstops are triggered unexpectedly.

Now this is getting interesting for use with CNC. However my router currently runs off 48V, what voltages can we expect for the Duet 3?

No build for Maestro boards yet? I'll happily test when that is available.