Firmware 2.02RC5 now available

dc42

I've just released this at https://github.com/dc42/RepRapFirmware/releases/tag/2.02RC5. It includes changes for CNC users, improvements to the 12864 display system on the Duet Maestro, other minor changes, and bug fixes. As always, read the upgrade notes before you install it.

I hope this will be the last RC before the 2.02 release.

Feedback:

If you try this release and it works well for you and/or fixes problems that you encountered with previous releases, please report that in this thread.
If you find any problems with this release and you have already read the upgrade notes and made any necessary changes to other files, please create a new thread with a title of the form "Release 2.02RC5 issue: " followed by a summary of the issue in a few words. It's hard for me to track multiple issues from different users in a single thread

appjaws

No problems with coreXYUV printer.
Thank you David for all your hard work

Phaedrux

No issues noted thus far.

3dmntbighker

Seemed to work last night.

zzing

9:45:28 PM
Finished printing file 20mm_cube.gcode, print time was 0h 34m
9:44:42 PM
Error: Internal Error in Read at ../src/Storage/FileStore.cpp(281)
Error: Internal Error in Close at ../src/Storage/FileStore.cpp(148)
9:11:28 PM
M290 S-0.05
9:11:05 PM
M32 "20mm_cube.gcode"
File 20mm_cube.gcode selected for printing

This is the only issue I have noticed with RC5.

dc42

@zzing said in Firmware 2.02RC5 now available:

9:45:28 PM
Finished printing file 20mm_cube.gcode, print time was 0h 34m
9:44:42 PM
Error: Internal Error in Read at ../src/Storage/FileStore.cpp(281)
Error: Internal Error in Close at ../src/Storage/FileStore.cpp(148)
9:11:28 PM
M290 S-0.05
9:11:05 PM
M32 "20mm_cube.gcode"
File 20mm_cube.gcode selected for printing

This is the only issue I have noticed with RC5.

Have you any idea what provoked the Internal Error messages? I presume you didn't remove the SD card before the print finished?

frafa

Hi David
Test 2.02RC5 on my Scara
Homing ok --> oup's ko

But after homnig absolute movement return error
possible move just on relative movement ...
Move on G90 impossible ...

G90 ; absolute movement
G1 Y0 X0 F1000
Error: G1/G2/G3: intermediate position outside machine limits

UPGRADE ...

David if i remove G1 S2 X1 Y-1; on my homeall.g before G0 I always have the same error as on the versionn 2.02RC4 brief G30 does not work and homig is wrong ...

; Home Z ir-probe
G91; Add test ...
G1 S2 X1 Y-1; Add test ...
G90; absolute movement
G30; Single Z-Probe

In short on scara I have the same concerns as on version 2.02RC4

giostark

Hi,
I'm still facing the perfect ,or more possible accurate ,calibration. And in the meanwhile I discovered a bug.
If I use the microstep 0.05 from the WC by pressing the Z-Baby stepping button, before or after a manual extrusion always from the WC ,the printer replicate the same extrusion as an other manual input (see picture ) . If this happen when the filament is near the nozzle occur the muse bite because the gears run faster the capability of the nozzle to release the material . (this because the manual extrusion for load the filament is done fast - my printer have near 15cm between the nozzle and the extruder gear)
I can reproduce this as many time I want.

k3lag

Working fine on my dual idex bigbox

dc42

@giostark said in Firmware 2.02RC5 now available:

If I use the microstep 0.05 from the WC by pressing the Z-Baby stepping button, before or after a manual extrusion always from the WC ,the printer replicate the same extrusion as an other manual input (see picture ) .

Thanks for reporting this, it's on my list to investigate.

Gone2Far

Working fine on homebrew kossel.

zzing

@dc42 correct, no pulling of SD. There really wasn't anything I was doing directly, except for being in proximity to it.

dc42

@frafa said in Firmware 2.02RC5 now available:

Error: G1/G2/G3: intermediate position outside machine limits

Are you certain that X0 Y0 is accessible in a straight line from the initial position? What happens if you use G0 instead of G1?

This is the homeall.g file on my SCARA:

; Home All file for Robotdigg SCARA arm printer
M561			; cancel bed compensation
G91

G1 S2 Z28 F1000		; raise Z to keep nozzle clear of base frame

G1 S1 X200 Y200 F1000	; home proximal and distal arms
G1 S2 X-5 Y-5 F1000	; back off
G1 S1 X10 Y10 F200	; repeat the homing more slowly

G90
G1 X-75 Y75 F3000	; move to a position that correspond to one of the M557 grid points
G30			; home Z
G1 Z28 F1000		; move to safe height again

G29 S1			; load height map

dc42

@dc42 said in Firmware 2.02RC5 now available:

@giostark said in Firmware 2.02RC5 now available:

If I use the microstep 0.05 from the WC by pressing the Z-Baby stepping button, before or after a manual extrusion always from the WC ,the printer replicate the same extrusion as an other manual input (see picture ) .

Thanks for reporting this, it's on my list to investigate.

I confirm this issue. It will be fixed in 2.02RC6.

Danal

Installed and working on a Larg-ish delta (600mm x 600mm). No issues found so far. Have done a couple of prints, one of them about six hours.

And... this did clean up the HTTP line ends (reported in a separate thread, now marked resolved).

resam

Some odd behaviour during pause & resume:
I have this in my resume.g:

G1 R1 X0 Y0 Z3 F6000     ; return to point previously paused at (but above it)
G1 R1 X0 Y0 Z0 F180      ; return to point previously paused at (lower nozzle)

G1 R1 X0 Y0 Z3 actually moves to X0 and Y0 - instead of the "last saved point".
Then it move 3mm down.
Then it seems to continue to the correct "last saved point" location (not sure if this is still from with resume.g or already the next commanded move from my print code).
Now it obviously crashes because the nozzle is too low.

This is repeatable. Print something for a few minutes. Pause. (I usually do a filament change or clear a heat-creep and command some manual extrusion to prime the nozzle). The Resume. Then crash (if I'm not quick enough with the E-stop).

I might have tweaked my config - but I don't see anything obvious in my version-controlled config files...
@dc42 Should G0 R1 X0 Y0 behave the same as G1 R1 X0 Y0?

edit: I just flashed RC4 again - and the problem is gone. So this is a regression in RC5.

frafa

@David

I have exactly the same problems as with version 2.02RC3
https://forum.duet3d.com/topic/7316/firmware-2-02-release-candidate-3-now-available/70

tested with your homing.all file adapted to my config, the same errors ...

Downgrade 1.21RC3 waiting ...

dc42

@resam said in Firmware 2.02RC5 now available:

Some odd behaviour during pause & resume:
I have this in my resume.g:
G1 R1 X0 Y0 Z3 F6000     ; return to point previously paused at (but above it)
G1 R1 X0 Y0 Z0 F180      ; return to point previously paused at (lower nozzle)
G1 R1 X0 Y0 Z3 actually moves to X0 and Y0 - instead of the "last saved point".
Then it move 3mm down.
Then it seems to continue to the correct "last saved point" location (not sure if this is still from with resume.g or already the next commanded move from my print code).
Now it obviously crashes because the nozzle is too low.

This is repeatable. Print something for a few minutes. Pause. (I usually do a filament change or clear a heat-creep and command some manual extrusion to prime the nozzle). The Resume. Then crash (if I'm not quick enough with the E-stop).

I might have tweaked my config - but I don't see anything obvious in my version-controlled config files...
@dc42 Should G0 R1 X0 Y0 behave the same as G1 R1 X0 Y0?

edit: I just flashed RC4 again - and the problem is gone. So this is a regression in RC5.

Strange, nobody else has reported this and I have similar lines in resume.g. I will test it again.

RRF restores the last print position automatically immediately before resuming. Using G1 R1 commands is optional, and allows you to control how it is done. G0 R1 should behave the same as G1 R1 except that on some machines (e.g. SCARA) the movement may not be linear.

resam

@dc42 I have a corexy. With RC4 it works as expected. RC5 moves to the wrong position.

I suspect the G53&G54 changes might have introduced a bug?

dc42

@resam said in Firmware 2.02RC5 now available:

@dc42 I have a corexy. With RC4 it works as expected. RC5 moves to the wrong position.

I suspect the G53&G54 changes might have introduced a bug?

Were you using workplace coordinate offsets when this happened?