RepRapFirmware 3.01-RC3 released

imrj

@droftarts yea i did thanks, but by then i had already setup the DuetPi and got it working....but yea i will do this to my Macbook, but interestingly enough I did have brew already installed and using it for other things

droftarts

@imrj it's not just brew, you need to 'brew install wxwidgets'.

Ian

TurtlePrint

When sending the M112 command the printer turns off and then starts the hot end fan "fan1" at full speed. I'm hoping to use the new daemon.g file to monitor a rotor stuck alarm wire on the hot end fan and send an M112 if its detected. So the fan continuing to spin after M112 is problematic if it's in a known stuck position.

Printer is running:
Duet2Wifi w/Duex5 running RRF RC3

config.g snippet

; Fans
M950 F0 C"Fan0"						;Define the Parts Blower Fan connected to Fan0
M106 P0 S0 C"Parts Blower" H-1 		;Name the fan, turn off thermistic control and turn the fan off if it was running
M950 F1 C"Fan1"						;Define the Tool Fan connected to Fan1
M106 P1 T40 H1						;Enable Thermostatic Control to turn fan on 40 degrees

Edit: After some experimentation it appears that any fan with thermostatic control enabled is set to 100% after an M112 command. Is this the intended behavior?

imrj

@droftarts ah ok got it, will do that

JuKu

M203 is set by mm/min, but reported back in mm/sec. (not a problem and as documented, just a bit odd. ?.)

dc42

@TurtlePrint said in RepRapFirmware 3.01-RC3 released:

Edit: After some experimentation it appears that any fan with thermostatic control enabled is set to 100% after an M112 command. Is this the intended behavior?

If readings from the sensor that control the thermostatic fan are not available, the firmware assumes that whatever it is supposed to cool might be hot, so it turns the fan on.

dc42

There is a bug in the 3.01-RC3 firmware on Tool Boards. The symptom of this bug is that the motor doesn't move and M122 reports a large number of timeouts for Driver 0. I have put a fixed version of Duet3Firmware-TOOL1LC.bin at https://www.dropbox.com/sh/3azy1njy3ayjsbp/AACquxr2m00eV568RZg5QG5wa?dl=0. Tool board users, please use this version until I release 3.01-RC4.

arhi

so far so good, duet2eth, one 6h print done flawlesly, second is 4h-38% in doing ok another 60% and change to go

c310

@Danal said in RepRapFirmware 3.01-RC3 released:

emergency stop

on duetwifi i have upgraded from 3.0 and emergency stop now does not work at all (was buggy in 3.0: printer stopped but did not reload itself, i was cycling power off-on to finish emergency stop cycle

current config

M950 J1 C"e1stop"
M581 P"e1stop" T0 C0

3.0 config was

M581 P"e1stop" T0

what should i fix ?

dc42

https://duet3d.dozuki.com/Wiki/Gcode#Section_M581_RepRapFirmware_3_01RC2_and_later

P is now the GPin pin number, so 1 in your case

tobias_munich

strange behaviour with M505 alternative configuration folder

DUET3, SBC & RRF3 last release:

i made a alternative config folder M505 P"experimental". which is in /sys/experimental/ and worked with it
i stepped back to the normal /sys config
reset of the board only, no reboot of the sbc
I changed some values in /sys/bed.g
wondering because it didn't took the new values, the board uses still the file /sys/experimental/bed.g

is it necessary rebooting the sbc or restarting de DSF processes after changing the config path?

Schmart

Hi @dc42, I upgraded my firmware from 2.05 to 3.0 to 3.01-RC3 yesterday without any issues. The breaking changes are fortunately very manageable for me and I think this major update makes the configuration concept much more logical and consistent. Thanks for the huge effort you're putting in! I did notice though, that increasing the speed factor (e.g. M220 S150 or increasing the 'speed factor' slider in DWC) no longer works properly. After a few moves have passed, the speed seems to only change briefly (for one move if I have to guess) and intermittently; sometimes there's no observable change at all. It seems that the speed changes back nearly immediately to 100% again.

Phaedrux

@Schmart As of 3.01 RC2:

The speed factor (M220) is no longer applied to extruder-only moves or to movement commands in system or user macro files

Is that perhaps what you're seeing?

Schmart

Hi @Phaedrux, I indeed saw that comment in the release notes as well, and now wondering what 'extruder-only moves' actually constitutes. I'd expect that this would not include regular print moves such as G1 X3 Y3 E0.8 F1800 but retraction or derectract moves such as G10/G11 or G1 E-0.5. I'm definitely seeing this with regular print moves as well. I also noticed that when I set the speed factor to 150%, a reset to 100% slows the print speed down to 50-60% for one move only. I guess something's not adding up with the changes made to M220 recently.

dc42

@Schmart said in RepRapFirmware 3.01-RC3 released:

Hi @dc42, I upgraded my firmware from 2.05 to 3.0 to 3.01-RC3 yesterday without any issues. The breaking changes are fortunately very manageable for me and I think this major update makes the configuration concept much more logical and consistent. Thanks for the huge effort you're putting in! I did notice though, that increasing the speed factor (e.g. M220 S150 or increasing the 'speed factor' slider in DWC) no longer works properly. After a few moves have passed, the speed seems to only change briefly (for one move if I have to guess) and intermittently; sometimes there's no observable change at all. It seems that the speed changes back nearly immediately to 100% again.

Seem odd. I ran several prints yesterday with the speed factor set at 50% or 65% and it was definitely working. But I set the speed factor with PanelDue, not DWC.

If you run into this again, send M220 without parameters to see what speed factor is reported.

Having thought about it, one instance where I think there is a problem is if the F parameter for a printing move just happens to match the F parameter for the preceding extruder-only move, and the slicer notices that and leave it out. In other words, if the slicer generated this:

G1 E-5 F3000
G1 X50 Y60 F3000 E1.0

but the slicer noticed that the feed rate was the same for both moves and left out the F3000 on the second move, then the speed factor won't get applied to the second move. I'll fix this in RC4. You might like to check your GCode file to see if this situation is occurring.

c310

@dc42 said in RepRapFirmware 3.01-RC3 released:

P is now the GPin pin number, so 1 in your case

i have tried for my emergency mushroom button

M581 P1 T0 C0

..no luck... what should exact string be?

dc42

@c310 said in RepRapFirmware 3.01-RC3 released:

@dc42 said in RepRapFirmware 3.01-RC3 released:

P is now the GPin pin number, so 1 in your case

i have tried for my emergency mushroom button
M581 P1 T0 C0
..no luck... what should exact string be?

That should work, provided that you still have this command before the M581:

M950 J1 C"e1stop"

The S0 or S1 option is still available in the M581 command.

Schmart

@dc42 said in RepRapFirmware 3.01-RC3 released:

Having thought about it, one instance where I think there is a problem is if the F parameter for a printing move just happens to match the F parameter for the preceding extruder-only move, and the slicer notices that and leave it out. In other words, if the slicer generated this:

G1 E-5 F3000
G1 X50 Y60 F3000 E1.0

but the slicer noticed that the feed rate was the same for both moves and left out the F3000 on the second move, then the speed factor won't get applied to the second move. I'll fix this in RC4. You might like to check your GCode file to see if this situation is occurring.

Hi @dc42, I've included the gcode of a full single layer of a test cube I've been printing. My slicer (both Supermerill's Slic3r++ and PrusaSlicer) generate code such as the following:

; Layer 6 at 1.4mm
G10 ; retract
G1 Z1.400 F9000.000
; printing object Shape-Box id:0 copy 0
G1 X15.500 Y27.775
G11 ; unretract
G1 F1800.000
G1 X3.225 Y27.775 E0.39472
G1 X3.225 Y3.225 E0.78944
G1 X27.775 Y3.225 E0.78944
G1 X27.775 Y27.775 E0.78944
G1 X15.560 Y27.775 E0.39279

I'm doing print quality experiments with PETG and all print speeds consistently at 30mm/s. I don't know if the latter is a factor, but the slicer indeed decides to set a default feedrate for print moves and does not specify feed rates explicitly on every single G1. So I guess this fully corresponds with the scenario you've described where M220 wouldn't work properly yet?

I'll also try to print something today and see what M220 is reporting back when I set a speed factor. Thanks!

dc42

Thanks @Schmart, that explains it. I've made a change in RC4 that should fix it.

Schmart

@dc42 excellent, thank you! Looking forward to RC4 and I’ll be sure to put M220 through its paces once it’s released.