RepRapFirmware 3.01-RC3 released

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.

tobias_munich

homeall.g issues:

some times my homeall.g is not working correctly. its straight forward (see below).
it does the 1st line (homex.g) correctly and sometimes it goes directly to the last line homez.g without executing the 2nd line (homey.g)

no problem if i run each script separately .

M98 P"homex.g"
M98 P"homey.g"
M98 P"homez.g"

similar issue reported here
https://forum.duet3d.com/topic/14854/homing-inconsistent-duet-3

@dc42 together with the "hanging" problem (see link below) of the RPi the DUET3+SBC setup is less reliable then before. But its stable if the DUET3 is running in standalone mode.

https://forum.duet3d.com/topic/14565/d3-pi-hangs-and-sometimes-won-t-reset?_=1583875893095

insertnamehere

I'm using conditional code to optimized bed leveling.

On occasions when the 2 points used are equal I get an initial deviation of NAN.

3/10/2020, 11:10:16 AM Leadscrew adjustments made: -0.001 -0.001, points used 2, (mean, deviation) before (-0.001, nan) after (0.000, 0.000)

I would expect that when 2 points are the same that the standard deviation for those points would be 0. If I'm wrong, how can I test for NAN in the conditional code?

dc42

@insertnamehere said in RepRapFirmware 3.01-RC3 released:

I would expect that when 2 points are the same that the standard deviation for those points would be 0. If I'm wrong, how can I test for NAN in the conditional code?

I will fix that. Meanwhile you can use the built-in isnan function:

11/03/2020, 08:05:07 	echo isnan(sqrt(-1))
true

c310

@TurtlePrint said in RepRapFirmware 3.01-RC3 released:

When sending the M112 command the printer turns off and then starts the hot end fan "fan1" at full speed

i have the same issue too. after M112 (or hardware mushroom button) printer stops, starts reboot and stucks with the cooling fan at 100% speed.

After it it is only possible to reload it by cycling power. when switching to reprap web interface - it gives a bit more diagnostics: "The firmware still reports to be halted after an emergency stop. Would you like to reset your board now?"
waiting for any long does not help either.

what can it be?

dc42

@c310 said in RepRapFirmware 3.01-RC3 released:

@TurtlePrint said in RepRapFirmware 3.01-RC3 released:

When sending the M112 command the printer turns off and then starts the hot end fan "fan1" at full speed

i have the same issue too. after M112 (or hardware mushroom button) printer stops, starts reboot and stucks with the cooling fan at 100% speed.

M112 has always done that. The printer should still respond to M999.

c310

@dc42 thanks, m999 works however to do so i need to use /reprap UI, DWC remains "blocked" untill power cycle.

in old good times of 2.x firmware mushroom button not only stopped operations, but also made
web interface responsive after reset (that does not happen in 3.01-RC3 )

what is a way to link m999 to emergency stop button (instead of triggering m112) without macros ?
or what can be done to run m999 after m112 generated by mushroom button ?

dc42

@insertnamehere said in RepRapFirmware 3.01-RC3 released:

I'm using conditional code to optimized bed leveling.

On occasions when the 2 points used are equal I get an initial deviation of NAN.

3/10/2020, 11:10:16 AM Leadscrew adjustments made: -0.001 -0.001, points used 2, (mean, deviation) before (-0.001, nan) after (0.000, 0.000)

I would expect that when 2 points are the same that the standard deviation for those points would be 0. If I'm wrong, how can I test for NAN in the conditional code?

The NaNs should be gone in the internal build at https://www.dropbox.com/sh/3azy1njy3ayjsbp/AACquxr2m00eV568RZg5QG5wa?dl=0.

mundsen

When do you plan to release RC4?

Danal

I may be off track here, but the reset problem described (here and in several other threads)... I believe the fix for that is having DuetControlServer restart itself as the last action when processing an M999.

I've built a version that does that, and opened a pull request on Github in chrishamm/DuetControlServer repository.

Meanwhile, if anyone is willing to try the 1.2.4.0 version of DuetControlServer with this fix, download this file:

http://danalspub.com/wp-content/uploads/2020/03/DuetControlServer.zip

Unzip, and place the two files inside in /opt/dsf/bin

The 'DuetControlServer' file should have attributes of -rwxr-xr-x. If for some reason it does not, run chmod 755 DuetControlServer

After the copies:
sudo systemctl stop duetcontrolserver
sudo systemctl start duetcontrolserver

If you decide to go back, run:

sudo apt-get reinstall duetcontrolserver

or

sudo apt-get reinstall duetcontrolserver=specific version number you wish

You can find all available versions via:
apt-cache policy duetcontrolserver

gtj0

@Danal I'll test it later today. Thanks!

gtj0

@Danal Had to recompile with your pull request because I use a 64 bit distro but it seemed to work OK.

Danal

@gtj0 said in RepRapFirmware 3.01-RC3 released:

@Danal Had to recompile with your pull request because I use a 64 bit distro but it seemed to work OK.

Yeah, I compile for 32 because the Duet distro is Debian.

Thanks for checking it!! It was a one line change... "systemctl" restarts it.

tobias_munich

DUET3-SBC/DSF Wrong print process percentage on PI/DSF

Hi guys.
My Pi shows a wrong percentage of the print progress.
PanalDue shows it right.

Is this a known error?

I will reboot and reset the system and start a new print and check it again.

insertnamehere

@dc42 said in RepRapFirmware 3.01-RC3 released:

@insertnamehere said in RepRapFirmware 3.01-RC3 released:

I'm using conditional code to optimized bed leveling.

On occasions when the 2 points used are equal I get an initial deviation of NAN.

3/10/2020, 11:10:16 AM Leadscrew adjustments made: -0.001 -0.001, points used 2, (mean, deviation) before (-0.001, nan) after (0.000, 0.000)

I would expect that when 2 points are the same that the standard deviation for those points would be 0. If I'm wrong, how can I test for NAN in the conditional code?

The NaNs should be gone in the internal build at https://www.dropbox.com/sh/3azy1njy3ayjsbp/AACquxr2m00eV568RZg5QG5wa?dl=0.

Thanks @dc42, it works correctly now.

3/14/2020, 11:17:11 AM Leadscrew adjustments made: 0.000 0.000, points used 2, (mean, deviation) before (0.000, 0.000) after (-0.000, 0.000)
BED LEVELLING COMPLETED
Final Deviation 0.000mm

appjaws

I have been using3.01- RC3 since it was released. I have discovered what could be a bug in the way the load filament works.
The extruder runs backwards, I also have a macro to load which also runs backward.
When printing the extruder works as expected and also the extrude button on DWC works correctly.
This is my filament load:-

; Load filament Real light blue
M98 P"0:/macros/Set LED Red"
if heat.heaters[1].current <190
M291 P"Please wait while the nozzle is being heated up" R"Auto Filament Load" S1 T0
M104 S195 ; Set current tool temperature to 195C
M116 S5 ; waiting for nozzle to reach temperature
M291 P"Feed Real light blue filament into the extruder by hand and click OK" R"Auto Filament Load" S3
M291 P"Loading Real-light blue filament" S1 T0 ; Display new message
G1 E10 F600 ; Feed 10mm of filament at 600mm/min
G1 E250 F3000 ; Feed 210mm of filament at 3000mm/min
G1 E20 F300 ; Feed 20mm of filament at 300mm/min
G4 S1 ; Wait one second
G1 E-3 F1800 ; Retract 10mm of filament at 1800mm/min
M400 ; Wait for the moves to finish
M104 S0 ; Set the temperature to zero
M98 P"0:/macros/Set LED Green"
M291 P"Real light blue filament Loaded" R"Auto Filament Load" S1 T0

I have only noticed this since RC3, I'm sure RC2 worked properly.

dc42

Might you be in absolute extrusion mode when you run that macro? Try putting M83 at the start of it.