RepRapFirmware 3.01-RC3 released

[droftarts]

@imrj said in RepRapFirmware 3.01-RC3 released:

bossa crashes on my Mac running Movaje

See https://forum.duet3d.com/topic/11445/flashing-firmware-on-mac-os-x

Ian

[dc42]

@DaBit said in RepRapFirmware 3.01-RC3 released:

How do we prevent the daemon task from taking away too much processing from the main G-code pipe? Is an endless while() harmful?

If using your own loop, then I recommend that you include at least one G4 command in it with a reasonable length of delay.

[dc42]

@imrj said in RepRapFirmware 3.01-RC3 released:

I tried the file "Duet3_SDiap_MB6HC.bin" that someone posted the link for but it still wont take, it says soemthing about in-app error (i notices is a really small file of 55k vs. the usual 550k or so).....I dunno this shouldnt be that difficult....help!!

That's the new IAP file, used by RRF 3.0 and later to upgrade the firmware. It is not the firmware file itself, but it needs to be present in /sys when you want to upgrade the firmware using DWC or M997.

[imrj]

I understand, but even with it present and the firmware file, still does nothing, it says is updating the firmware, but it remains the same in M115 afterwards, stuck at 3.0B12

[Phaedrux]

@imrj Try updating to 3.0 first, with the zip file from that release. Then try updating to this release.

[imrj]

i was able to finally get it done with the DuetPI and using the virtual SD card, so its all good now...but this needs to be simplied a bit, too hard for just a firmware update
now I have another issue but opened a new post for that one....thanks everyone

[droftarts]

@imrj Did you see my post about fixing bossa on Mac OS? https://forum.duet3d.com/topic/11445/flashing-firmware-on-mac-os-x

Ian

[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:

1. i made a alternative config folder M505 P"experimental". which is in /sys/experimental/ and worked with it
2. i stepped back to the normal /sys config
3. reset of the board only, no reboot of the sbc
4. I changed some values in /sys/bed.g
5. 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?