RepRapFirmware 3.0

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.

dc42

@bearer said in RepRapFirmware 3.0:

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?

The current plan is 30V or perhaps 36V. It's difficult to find 5V buck regulator chips that accept higher than 40V input.

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

I have a build for the Maestro but it is completely untested at present.

brunofporto

I would like to suggest a migration tool. Some "simple" software or web app that reads your current configuration files and points out things that need attention or change.

dc42

@brunofporto said in RepRapFirmware 3.0:

I would like to suggest a migration tool. Some "simple" software or web app that reads your current configuration files and points out things that need attention or change.

Sadly that would probably be a never-ending project. There are just too many configurations. So I've concentrated on making the common configurations easy to migrate.

OTOH a "sanity checker" that looks for obviously missing or obsolete parameters on GCode commands in config.g would be possible.

brunofporto

@dc42 said in RepRapFirmware 3.0:

OTOH a "sanity checker" that looks for obviously missing or obsolete parameters on GCode commands in config.g would be possible.

This should be enough Thanks!

gtj0

@dc42 said in RepRapFirmware 3.0:

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

@bearer said in RepRapFirmware 3.0:

Now this is getting interesting...

Interesting indeed! As long as it's configurable by endstop.

RRF 3 supports multiple endstop switches on axes (one per motor) natively. You no longer need to split axes during homing.

This would imply that if you have only 1 motor you can't have 2 endstops (maybe a min and a max). Just curious why.

dc42

@gtj0 said in RepRapFirmware 3.0:

This would imply that if you have only 1 motor you can't have 2 endstops (maybe a min and a max). Just curious why.

No, you can have multiple axis endstops even if there is just one motor. There is currently no way to tell the firmware that you have separate min and max endstops; but I might add this later.

gtj0

@dc42 said in RepRapFirmware 3.0:

@gtj0 said in RepRapFirmware 3.0:

This would imply that if you have only 1 motor you can't have 2 endstops (maybe a min and a max). Just curious why.

No, you can have multiple axis endstops even if there is just one motor. There is currently no way to tell the firmware that you have separate min and max endstops; but I might add this later.

That would be welcomed (since that's what I have)

X and Y have 2 motors per axis and each have min and max endstops.
Z has 3 motors, 3 max endstops and a piezo probe.

Veti

@dc42 said in RepRapFirmware 3.0:

The current plan is 30V or perhaps 36V. It's difficult to find 5V buck regulator chips that accept higher than 40V input.

why not says that for input above 30V the 5V line has to be supplied via the ext 5V?

dc42

The expansion board doesn't have an ext 5V input.

A Former User

This post is deleted!

dc42

I have made new builds of RepRapFirmware 3 available:

Duet WiFi/Ethernet: https://www.dropbox.com/s/fyvibzm0zl92hiy/Duet2CombinedFirmware.bin?dl=0
Duet Maestro: https://www.dropbox.com/s/m0r3ldy424mxf4v/DuetMaestroFirmware.bin?dl=0

As before, use these with caution! In particular, test your endstops and Z probe before relying on them. See https://duet3d.dozuki.com/Wiki/RepRapFirmware_3_overview for required configuration changes.

The Duet Maestro build also has some improvements to the menu system:

Fan speeds, print speed modifier and extrusion rate modifier have '%' displayed after them automatically
New item 534 is the current IP address in one go (to replace items 530, 531, 532 and 533)
New item 535 is the percentage of the current SD card file completed
New item 536 is the estimated print time remaining, based on the percentage of the file that has been completed

Catalin_RO

@dc42 said in RepRapFirmware 3.0:

@catalin_ro said in RepRapFirmware 3.0:

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?

Well, trying to achieve such a precision (0.09mm) when positioning the homing switch is really tricky, at least with classical mechanical switches. There are some cylindrical ones, similar to the NPN/PNP sensors and those can be indeed positioned very precisely. On the other hand, I'm on the same wave length with you - it is not worth making something really special for just few users as long as the solution already exists and it requires just a few extra lines in a macro. Things get significantly simpler by having to do the split, precise tune and recombine of the axis only for the alignment difference.

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.

The idea to specially handle the homing/limit switches is the best from my point of view. If it would trigger a macro, if present, instead of the emergency stop, it would be even better. There might be situations when hitting an endstop requires special action or, on the contrary, none at all (I have messed up myself quite a few jobs by mistakenly touching one of the endstops!) - after all the spindle end everything else could be stopped through the macro and the user could be asked for possible actions through some messages.

The special handling of the endstops also simplifies the homing scripts because of the no longer required M581 commands!