RepRapFirmware 3.0 is released!

Alexander Mundy

Not before Beta 12, at least that I could find.

A Former User

@Alexander-Mundy said in RepRapFirmware 3.0 is released!:

Not before Beta 12, at least that I could find.

there is only beta 11 between, which has some notes in the release post
https://github.com/dc42/RepRapFirmware/releases/tag/3.0beta11

Alexander Mundy

Thank you. I lost track of 3 beta after I got it working for one of my printers that needed the remapping features because it worked and I didn't need more. But now that stable is out I figure time to upgrade because future release will be based from this one.

Shotfire

I've upgraded to 3.0
Duet Wifi 2,

Have everything working, at least I think, except for my Precision Piezo Z-Probe.
X and Y are homing correctly
Z probe is acting odd.

Old Code - that worked fine:
M558 P8 R0.4 H5 I1 F1200 T6000

New Code - Not Working
M558 P8 C"^zprobe.in" R0.04 H5 F1200 T6000

The Dashboard shows Z-Probe "1000" when I tap on it, it immediately goes to "0" then back to "1000"
If I remove the Invert Character "^" the dashboard right after connecting shows "1000".
When I tap on it, it will go to "0" and stays there for about 10 seconds and then goes back to "1000"

Any Ideas?

dc42

@Shotfire said in RepRapFirmware 3.0 is released!:

Old Code - that worked fine:
M558 P8 R0.4 H5 I1 F1200 T6000
New Code - Not Working
M558 P8 C"^zprobe.in" R0.04 H5 F1200 T6000
The Dashboard shows Z-Probe "1000" when I tap on it, it immediately goes to "0" then back to "1000"
If I remove the Invert Character "^" the dashboard right after connecting shows "1000".
When I tap on it, it will go to "0" and stays there for about 10 seconds and then goes back to "1000"
Any Ideas?

You used I1 in your old M558 command, therefore you need to use pin name "!zprobe.in" in the new command. If the probe needs a pullup resistor (as appears to be the case), you will need to use "^!zprobe.in".

Shotfire

@dc42 Thanks I will try that.

DaBit

Took the plunge and moved to RRF3.0. Sooner or later I will have to move anyway if I ever want to use conditional G-code, and it seems wiser to move before honing in the toolchange procedures.

Some weirdness. The X/Y endstop switches. These are normally open active low NPN proximity sensors. Configured in RRF2 like this:

; Endstops
M574 X1 Y2 S0                                   ; set active low and disabled endstops
M574 Z1 S2                                      ; set endstops controlled by probe

The RRF config tool generates this code:

; Endstops
M574 X1 S0 P"xstop"                                    ; configure active-low endstop for low end on X via pin xstop
M574 Y2 S0 P"ystop"                                    ; configure active-low endstop for high end on Y via pin ystop
M574 Z1 S2                                             ; configure Z-probe endstop for low end on Z

Which is not correct; according to the M574 documentation the S parameter should be 1 (microswitch-type endstop), and I suppose I need to do the inversion on the pins. Which seems to work:
(I also enabled the pullups)

; Endstops
M574 X1 S1 P"^!xstop"                                    ; configure active-low endstop for low end on X via pin xstop
M574 Y2 S1 P"^!ystop"                                    ; configure active-low endstop for high end on Y via pin ystop
M574 Z1 S2                                             ; configure Z-probe endstop for low end on Z

Next is Z homing. My RRF3 homez.g script, taken from the configurator and adjusted coordinates:

G91                ; relative positioning
G1 H2 Z5 F6000     ; lift Z relative to current position
G90                ; absolute positioning
G1 H2 X115 Y115 F6000 ; go to first probe point
G30                ; home Z by probing the bed

; Uncomment the following lines to lift Z after probing
G91               ; relative positioning
G1 H2 Z5 F100     ; lift Z relative to current position
G90               ; absolute positioning

The G1 H2 X115 Y115 fails, and actually moves to X115 Y0? I suppose it moves the CoreXY motors independently. Removing the H2 does not work; you cannot move axes that are not homed yet.

I hacked it with a pair of M564 commands:

G91                ; relative positioning
M564 S1 H0
G1 Z5 F6000     ; lift Z relative to current position
G90                ; absolute positioning
G1 X115 Y115 F6000 ; go to first probe point
G30                ; home Z by probing the bed

; Uncomment the following lines to lift Z after probing
G91               ; relative positioning
G1 H2 Z5 F100     ; lift Z relative to current position
G90               ; absolute positioning
M564 S1 H1

This works, but it is probably not how I am supposed to do that?

mihaitintea

I have a custom built delta printer with the latest Duet2Wifi board avec Duex5, running the latest RRF 2.x.

I use the latest Cura 4 for slicing.

If I do the RRF2 -> RRF3 upgrade for these boards (Duet2Wifi avec Duex5) , will the GCode generatedf by Cura 4 still work on my delta printer, or do I have to look for another slicing software ?

Danal

@mihaitintea said in RepRapFirmware 3.0 is released!:

I have a custom built delta printer with the latest Duet2Wifi board avec Duex5, running the latest RRF 2.x.

I use the latest Cura 4 for slicing.

If I do the RRF2 -> RRF3 upgrade for these boards (Duet2Wifi avec Duex5) , will the GCode generatedf by Cura 4 still work on my delta printer, or do I have to look for another slicing software ?

Should be no change to the slicer at all. There MIGHT be something in the start G-Code to adjust... but I really doubt it.

Do be aware that your config.g will require quite a bit of change. Look at all the guides for the Duet3.

dc42

@DaBit said in RepRapFirmware 3.0 is released!:

The RRF config tool generates this code:
; Endstops
M574 X1 S0 P"xstop"                                    ; configure active-low endstop for low end on X via pin xstop
M574 Y2 S0 P"ystop"                                    ; configure active-low endstop for high end on Y via pin ystop
M574 Z1 S2                                             ; configure Z-probe endstop for low end on Z
Which is not correct; according to the M574 documentation the S parameter should be 1 (microswitch-type endstop), and I suppose I need to do the inversion on the pins. Which seems to work:

You are correct. We'll get configtool fixed.

Next is Z homing. My RRF3 homez.g script, taken from the configurator and adjusted coordinates:
...
The G1 H2 X115 Y115 fails, and actually moves to X115 Y0? I suppose it moves the CoreXY motors independently. Removing the H2 does not work; you cannot move axes that are not homed yet.

The H2 should be removed. Surely X and Y have been homed by that point? It doesn't make sense to try to home Z using a Z probe if you can't set the XY coordinates.

DaBit

X and Y have been homed before Z.
I tested by accidentally removing the H2 at the first Z-lift too, my bad.

This works:

; homez.g
; called to home the Z axis

G91                ; relative positioning
G1 H2 Z5 F6000     ; lift Z relative to current position
G90                ; absolute positioning
G1 X115 Y115 F6000 ; go to first probe point
G30                ; home Z by probing the bed
G91                ; relative positioning
G1 Z5 F6000        ; lift Z relative to current position
G90                ; absolute positioning

Anyway, the RRF configurator is generating (imho) wrong code for this too; it produces a H2 for both the lift-Z and X/Y positioning moves.

RRF config tool generated homez.g:

; homez.g
; called to home the Z axis
;
; generated by RepRapFirmware Configuration Tool v2.1.4 on Sun Jan 05 2020 10:48:15 GMT+0100 (Midden-Europese standaardtijd)
G91                ; relative positioning
G1 H2 Z5 F6000     ; lift Z relative to current position
G90                ; absolute positioning
G1 H2 X19 Y1 F6000 ; go to first probe point
G30                ; home Z by probing the bed

; Uncomment the following lines to lift Z after probing
;G91               ; relative positioning
;G1 H2 Z5 F100     ; lift Z relative to current position
;G90               ; absolute positioning

Alexander Mundy

FYI for anyone else moving from early beta (before 11) I had to do the following:
Define heaters and associated temp sensors
Use M308 instead of M305
Activate the pullup resistors for endstops and z probe if needed since they are not active by default
I had remapped the bed heat and part cooling fans previously and had M950 H0 C"nil" and M950 H2 C"nil" but removed them since heaters are no longer automatically assigned.

wilriker

@tobias_munich said in RepRapFirmware 3.0 is released!:

Is the the paneldue running on the DUET3 with this release yet?
saw that IO_0 should be reserved for this.

Yes, it does. Connect it to IO_0 and it will work. If you are using Duet3 + SBC then everything related to job files and macros will not work on PanelDue because it cannot see those (maybe also contents of /sys, haven't checked that).

Hornetrider

Hi

I am not sure if this is off topic in this thread...sorry...

The symbols (double arrows) for Baby-Steps in the Print menu on Paneldue in combination with Duet3 and RRF3.0RC2 look different from RRF2.05 and are kind of missleading to me...
Could there be an option to change them to something simpler like before?

I am having real fun using the Duet3 and RRF3.0. Damn good job!

dc42

@Hornetrider said in RepRapFirmware 3.0 is released!:

The symbols (double arrows) for Baby-Steps in the Print menu on Paneldue in combination with Duet3 and RRF3.0RC2 look different from RRF2.05 and are kind of missleading to me...

They used to show up and down arrows, but users complained about this because on machines that move the bed in Z, the arrows pointed in the opposite direction to the resulting bed movement. So now they show the gap between the nozzle and bed increasing or decreasing.

Danal

@dc42 said in RepRapFirmware 3.0 is released!:

they show the gap between the nozzle and bed increasing or decreasing

FWIW:

As someone who has both kinds of printers, those that move bed, and those that move nozzle, I could never figure out the old icons. The new "squeeze or separate" make it much more clear for all cases.

Hornetrider

Yeah, I got it.

Didn't think about it, regarding the Z axis as moving bed...

Thin I will get used to it as soon as I have updated my second printer to RRF3.0...

supernovae

Thanks for all your hard work @dc42! Love this update! Converted my HyperCube evo over and all is well (corexy)

kraegar

Just wanted to chime in that 3.0 is running on several RailCore's with both Duet 2's and Duet3's now with no reported troubles. Thanks for the great work @dc42 !

dc42

@kraegar, thanks for the feedback.

Do you have an application for conditional GCode on the RailCore?