RepRapFirmware 2.03RC4 available

[Phaedrux]

@bravojul said in RepRapFirmware 2.03RC4 available:

I have tried 2.03RC3 with new PrusaSlicer 2.0.

But have you tried 2.03RC4?

[oliof]

I can confirm that PrusaSlicer filament length is recognized by RC4

[dc42]

@bravojul said in RepRapFirmware 2.03RC4 available:

I have tried 2.03RC3 with new PrusaSlicer 2.0. Filament used is not recognized. PrusaSlicer now output:

; filament used [mm] = 3363.4
; filament used [cm3] = 7.9

It works if I edit the file before sending it to the printer. I change to :

; filament used = 3363.4mm
; filament used [cm3] = 7.9

As @Phaedrux says, please test again using 2.03RC4.

[Bravojul]

yes it works with RC4. Thanks

[wilriker]

Print successful but there was something strange when it entered stop.g. It seems as if the motors were reduced to idle current. They sounded vastly different and the Y motor even stalled (it needs slightly more than idle current to move properly). Upping the idle current and trying again let the motors move normal.

[dc42]

RRF sets the motors to idle current when a print from SD card terminates. I don't remember whether it does this before or after stop.g is run. I will check tomorrow.

[wilriker]

@dc42 Thanks.
Just to clarify: this behavior is new with RC4 so probably when fixing the issue with M0 H1 something got switched in the order of execution.

[dc42]

@wilriker said in RepRapFirmware 2.03RC4 available:

@dc42 Thanks.
Just to clarify: this behavior is new with RC4 so probably when fixing the issue with M0 H1 something got switched in the order of execution.

I just checked the code. The motors are set to idle current after stop.g has been run. So no change there.

Of course, if the machine has been idle for more than the idle time when stop.g is run or within stop.g (perhaps because of a command to wait for something to cool down), then ordinary idle current reduction will kick in. But as soon as you move a motor, normal current should be restored.

Edit: I've realised what might be happening, and I will fix it in the 2.03 release. Meanwhile, as a workaround, try adding a M400 command at the end of stop.g.

[wilriker]

@dc42 Thanks. I'll try that - and I think I also how have a clue what's happening.

[Caveman]

Bed mesh level still the same issue as before. Z0 is all over the place. 2.02 works perfectly???

[dc42]

@caveman said in RepRapFirmware 2.03RC4 available:

Bed mesh level still the same issue as before. Z0 is all over the place. 2.02 works perfectly???

Is this with 2.03RC4 ? Are you getting any warning messages on the console?

Please provide a sequence that reproduces this issue for you, along with all the files needed to reproduce this (config,g, homing files, bed.g if used, and a very short GCode file to print if printing a file has to be part of the sequence).

[Caveman]

Whenever I have a wrong Z0 I get the message that the map has a substantial Z offset.....

Sometimes I have a proper Z0

[Phaedrux]

@caveman How are you homing Z and how are you establishing Z0 before running the mesh compensation routine?

[Gone2Far]

Had some odd leveling behavior on my delta.

Had a quite hard time getting G32 to converge on a particular height, but finally did. Then noticed several aborted probing points when running G29, followed by reports of 4.x mm max height error. After increasing the force needed by the smart effector from default to 128, got a kinda good height map. Now I have to edit the deflection setting in config.g--I had to add +0.15 mm baby step to get first layer correct. Everything was working quite well prior to upgrade.

[wilriker]

@dc42 said in RepRapFirmware 2.03RC4 available:

Meanwhile, as a workaround, try adding a M400 command at the end of stop.g.

I can now confirm that this solves the issue.

[Caveman]

Homing z happens by pressing home all. Establishing z0 happens by a papercheck.

[Phaedrux]

@caveman said in RepRapFirmware 2.03RC4 available:

Homing z happens by pressing home all. Establishing z0 happens by a papercheck.

Can you post your homeall and config files?

[dc42]

@wilriker said in RepRapFirmware 2.03RC4 available:

@dc42 said in RepRapFirmware 2.03RC4 available:

Meanwhile, as a workaround, try adding a M400 command at the end of stop.g.

I can now confirm that this solves the issue.

Thanks. This should be fixed in 2.03RC5, which I have just released.

[T3P3Tony]

Topic locked as RC5 is released:

https://forum.duet3d.com/topic/10786/firmware-2-03rc5-1-24rc5-released