RepRapFirmware 3.0 is released!

[Hornetrider]

@dc42
thx for reacting so fast.
I will check on your input.

Before my last post I run the following check...

Considering that for basic setup:
M950 F2 C"!out4" -> works
M106 P2 H3:H4 T48:60 C"MCU FAN" -> shows strange behaviour as "drivers" is influenced by "bedtemp"

I checked this by changing M106 to:
M106 P2 H4 T48:60 C"MCU FAN"

While MCUTemp stayed at ~40°C I run the bed heating to 50°C and at 48°C the fan started running....
Then I made a recheck for only "mcutemp" like:
M106 P2 H3 T38:60 C"MCU FAN"

And everything worked as supposed: as MCUtemp came below 38°C the fan turned of.

Any clues?

[dc42]

What temperature does Driver Temp show in DWC while you heat the bed?

[Hornetrider]

@dc42
0.0°C

[dc42]

@Hornetrider said in RepRapFirmware 3.0 is released!:

M106 P2 H3:H4 T48:60 C"MCU FAN"

I've just spotted the problem. You are using:

M106 P2 H3:H4 T48:60 C"MCU FAN"

but it should be:

M106 P2 H3:4 T48:60 C"MCU FAN"

Sending M106 P2 would have revealed that it was monitoring sensors 0 and 3.

[Hornetrider]

@dc42
thx!
I'll give it a try later today and get back to you.

[Hornetrider]

@dc42
now everything is like it should be... thx a lot!

[4lathe]

I have several duet 2 wifi’s on deltas and a railcore Zl and have converted the deltas to rrf3. I decided to put a maestro on a Frankenstein Ender 3 Pro that had a bltouch and v6 on it ( I first tested it with a spare duet wifi I had on hand using 2.05 and that worked perfectly). So I installed the maestro and tested using 2.05. No problems. I then upgraded to 3.0. All works perfectly except for deploy and retract probe. I added M950 S0 P”zprobe.mod” before my M558. I then changed the deployprobe.g and retractprobe.g to M280 P0 S10 and M280 P0 S90. When I went to homez, the probe didn't deploy. I tested issuing the commands in the console. Nothing. I searched here and saw that someone said they had to put the M950 command again just before the M280’s in deployprobe and retractprobe. I tried that and it works perfectly. There is no config-override file so nothing is undoing the original M950 in config.g. Any ideas on why this is happening? Thx for any help.

[DIY-O-Sphere]

That are the lines for my Maestro.
Already on RRF3.01b

M558 P9 C"zprobe.in" H5 F120 T3000
M950 S0 C"zprobe.mod"

[dc42]

@4lathe said in RepRapFirmware 3.0 is released!:

I have several duet 2 wifi’s on deltas and a railcore Zl and have converted the deltas to rrf3. I decided to put a maestro on a Frankenstein Ender 3 Pro that had a bltouch and v6 on it ( I first tested it with a spare duet wifi I had on hand using 2.05 and that worked perfectly). So I installed the maestro and tested using 2.05. No problems. I then upgraded to 3.0. All works perfectly except for deploy and retract probe. I added M950 S0 P”zprobe.mod” before my M558. I then changed the deployprobe.g and retractprobe.g to M280 P0 S10 and M280 P0 S90. When I went to homez, the probe didn't deploy. I tested issuing the commands in the console. Nothing. I searched here and saw that someone said they had to put the M950 command again just before the M280’s in deployprobe and retractprobe. I tried that and it works perfectly. There is no config-override file so nothing is undoing the original M950 in config.g. Any ideas on why this is happening? Thx for any help.

In 3.0 the Z probe defaults to using probe.in+zprobe.mod. You need to use
M558 to make the Z probe use just zprobe.in. Only then will zprobe.mod be free to use in M950.

[4lathe]

@dc42 here is my config.g
M950 S0 C”zprobe.mod”
M558 P9 C”zprobe.in” H4 F120 T2400 R0.5
So are you saying I must place the M950 after that M558?

[4lathe]

Just tried that. Works fine. Might be worth a comment somewhere to tell people that M950 has to be after the M558 since it default assigns both.

[4lathe]

On another issue, I upgraded to 3.01 no issues. I also upgraded to dwc 2.0.5 but in the system page it still shows 2.0.4.

[4lathe]

Sorry to post on this again, but used the version on chrishamm’s github page and it now shows 2.0.5.

[dc42]

@4lathe said in RepRapFirmware 3.0 is released!:

On another issue, I upgraded to 3.01 no issues. I also upgraded to dwc 2.0.5 but in the system page it still shows 2.0.4.

Thanks, I'll check which version I included in the release.

In 3.01 there is no default Z probe, so the ordering issue between M950 and M558 should not arise.

[Adryzz]

@dc42

I just updated from 2.0 to 3.0 on a corexy, I used the online configurator, but the stallguard does not work, the cart does not stop, while in 2.0 it worked perfectly.

In config,g i've put :

; Endstops
M574 X1 S3 ; configure sensorless endstop for low end on X
M574 Y1 S3 ; configure sensorless endstop for low end on Y
M574 Z1 S2 ; configure Z-probe endstop for low end on Z

and in homex.g (for example) i've put:

M915 P0:1 S0 R0 F0 H400; both motors because corexy; Sensitivity 10, don't take action, don't filter, 400steps/sec
G91 ; relative positioning
G1 H1 X-325 F1800 ; move quickly to X axis endstop and stop there (first pass)
G1 X5 F6000 ; go back a few mm
G90 ; absolute positioning

[dc42]

Try upgrading to 3.01beta. I have a CoreXY tool changer running 3.01 with stall homing working on X and Y.

Also, try running M98 P"config.g" to see if it generates any error messages.

[zerspaner_gerd]

Hello everyone
I just switched to RF3

I would have the following questions

• How can I convert M581 S-1 into RF3?

• Why does my X homing fail?
  Y, Z and homeall work?

; homeall.g
G91							; relative positioning
G1 H1 Z215 F1600			        ; move Z up stopping at the endstop
G1 H1 X-235 Y235 F4800		; move quickly to X and Y axis endstops and stop there (first pass)
G1 X5 Y-5 F6000				; go back a few mm
G1 H1 X-7.5 Y7.5 F1300		; move slowly to X and Y axis endstops once more (second pass)		
G1 Z-5.0 F1400
G1 H1 Z7.5 F800				; move Z up until the switch triggers
G90							; absolute positioning
 
; homex.g
G91					; relative positioning
G1 H1 X-232 F4800	; move quickly to X axis endstop and stop there (first pass)
G1 X5 F6000			; go back a few mm
G1 H1 X-7.5 F1300	; move slowly to X axis endstop once more (second pass)
G90					; absolute positioning
 
; homey.g
G91              ; relative positioning
G1 H1 Y235 F4800 ; move quickly to Y axis endstop and stop there (first pass)
G1 Y-5 F6000     ; go back a few mm
G1 H1 Y7.5 F1300  ; move slowly to Y axis endstop once more (second pass)
G90              ; absolute positioning
 
; homez.g
G91						; relative positioning
G1 H1 Z215 F1600		; move Z up until the switch triggers
G1 Z-5.0 F1400
G1 H1 Z7.5 F800			; move Z up until the switch triggers
G90						; absolute positioning
 
; 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 Z2 S1 P"!zstop"					; configure active-low endstop for high end on Z via pin zstop

If I write H2 in this sentence G1 X5 F6000 ; go back a few mm it works, but with Y, Z and homeall it is not necessary either?

I'm totally keen on the meta commands, but first one by one

greetings

[littlehobbyshop]

@zerspaner_gerd You need that H2 in there as you described for the move back a few mm. My config has these and was generated by the config tool.

[deckingman]

@littlehobbyshop said in RepRapFirmware 3.0 is released!:

@zerspaner_gerd You need that H2 in there as you described for the move back a few mm. My config has these and was generated by the config tool.

He shouldn't need to add that H2. If the first G1 H1 X- move works, then the axis will be flagged as being homed. So after that, he should be able to do any G1 moves without any H parameter.
I suggest the OP steps through his homex one command at a time to check that the axis gets flagged as being homed after that first move. One thing that might be a clue is that in homeall, the move is X-235 but in home X it's - 232 (I think - but I'm typing this on my phone and can't scroll up).

[zerspaner_gerd]

@deckingman said in RepRapFirmware 3.0 is released!:

@littlehobbyshop said in RepRapFirmware 3.0 is released!:

@zerspaner_gerd You need that H2 in there as you described for the move back a few mm. My config has these and was generated by the config tool.

He shouldn't need to add that H2. If the first G1 H1 X- move works, then the axis will be flagged as being homed. So after that, he should be able to do any G1 moves without any H parameter.

I agree with you. Why should it be necessary for X and not for Y, Z and homeall?

I suggest the OP steps through his homex one command at a time to check that the axis gets flagged as being homed after that first move.

The warning message disappears for the first time, so I assume that it is considered referenced.

One thing that might be a clue is that in homeall, the move is X-235 but in home X it's - 232 (I think - but I'm typing this on my phone and can't scroll up).

Well seen, I compared again and again and saw no differences.
But nothing has changed.

Since my english is not good here is a video of how the X axis behaves
https://www.dropbox.com/s/b9ms5dav5o08n24/2020-01-27 16-06-58.ts?dl=0

What I have found out is that this is completed without errors:

G91					; relative positioning
G1 H1 X-235.0 F4800	; move quickly to X axis endstop and stop there (first pass)
G1 X10.0 F6000		; go back a few mm
G1 H1 X-7.5 F1300	; move slowly to X axis endstop once more (second pass)
G90					; absolute positioning

Only the result is wrong.
It seems to me that it ignores the second H1.
Why?