Firmware 2.02RC5 now available

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?

resam

@dc42 said in Firmware 2.02RC5 now available:

Were you using workplace coordinate offsets when this happened?

No - I'm running in a simple plain FFF mode as 3D printer.
I do not have any G53 or G54 codes in my sys/ or macros/ files.

dc42

@resam said in Firmware 2.02RC5 now available:

@dc42 said in Firmware 2.02RC5 now available:

Were you using workplace coordinate offsets when this happened?

No - I'm running in a simple plain FFF mode as 3D printer.
I do not have any G53 or G54 codes in my sys/ or macros/ files.

Thanks. Are you using any G10 tool offsets?

EDIT: or M206 offsets?

resam

@dc42 said in Firmware 2.02RC5 now available:

Thanks. Are you using any G10 tool offsets?

The only G10's I have are hotend temperature and retract commands:
G10 10 P0 S0 R0, G10 S175 and similar.

EDIT: or M206 offsets?

No.

I do have a M208 with a negative Y minima - which I use as a pause position - maybe this is causing a weird edge case ("out of workspace"?)

My pause.g:

M83                      ; relative extruder moves
G1 E-2 F1200             ; retract
G91                      ; relative moves
G1 Z3                    ; raise nozzle
G90                      ; absolute moves
G0 X230 Y-5 F6000        ; move head out of the way of the print and clear nozzle
M106 S0                  ; fan off

My resume.g:

G0 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)
M83                      ; relative extruder moves
G1 E2 F1200              ; undo the retraction
M106 R1                  ; restore fan speed
T R1                     ; restore tool selection

I based these scripts on https://duet3d.dozuki.com/Wiki/ConfiguringRepRapFirmwareCartesianPrinter#Section_Pause_resume_and_cancel_files - but it seems some of it is redundant now because RRF already does the same steps before/after calling resume.g

dc42

Even though the G0 R1 and G1 R1 lines are not strictly needed, they should still work, at least if you are not using workplace coordinate offsets or tool offsets. As you are not using either of those, I don't know why they are not working properly. The negative Y coordinate is OK. I tested pause/resume in 2.02RC5 using this resume.g file:

; Resume macro file
G1 R1 X0 Y0 Z2 F5000 ; move to 2mm above resume point
G1 R1 X0 Y0 Z0 ; lower nozzle to resume point
M83 ; relative extruder moves
G1 E4 F2500 ; undo the retraction

resam

I flashed RC5 again - the bug is repeatable.

I added beeps to my resume.g to check when the faulty moves are made:
The G1 R1 ... commands in resume.g are not correctly executed. The head seems to be moved to (0,0) in absolute coordinates (front left corner).

The following similar moves in the firmware seem to be correct.

With RC4 this works as expected.
So this bug seems to happen somewhere during/before the execution of resume.g, because once we enter the resuming_1 state, it behaves correctly.
HandleMCode for case 24 is pretty simple - so I suspect DoFileMacro again...

resam

@dc42 I think I got a reasonable outline of what is happening:

When we call resume.g, DoFileMacro sets useMachineCoordinatesSticky = true.
https://github.com/dc42/RepRapFirmware/commit/6e457735157a8cb452cc244f866fb1c083c7b48b#diff-4982d99e6381f0b210c46336de3818d4R123 introduced a UsingG54() which now also becomes true.
https://github.com/dc42/RepRapFirmware/commit/6e457735157a8cb452cc244f866fb1c083c7b48b#diff-6418fd0d517411c266a27fb33b10ad76R2523 now uses UsingG54(), therefore we enter the first if-block, instead of the block for handling a resume-point.

0

dc42 committed to dc42/RepRapFirmware

Version 2.02RC5

Shortened M591 filament monitor reports
Added filament detection state to M591 report for simple filament sensor
Tool offsets are no longer applied when G54 is in effect
M500 saves workplace coordinates
Implemented M851 for Marlin compatibility
Added check for NaNs when computing derivatives during auto calibration
Scara printers can now xo XY moves before Z has been homed
Don't allow M291 to create messatge popups that can never time out or be dismissed

0

dc42 committed to dc42/RepRapFirmware

Version 2.02RC5

Shortened M591 filament monitor reports
Added filament detection state to M591 report for simple filament sensor
Tool offsets are no longer applied when G54 is in effect
M500 saves workplace coordinates
Implemented M851 for Marlin compatibility
Added check for NaNs when computing derivatives during auto calibration
Scara printers can now xo XY moves before Z has been homed
Don't allow M291 to create messatge popups that can never time out or be dismissed

dc42

@resam, thanks for your analysis, that looks like the explanation. The odd thing is that I ran pause/resume tests on my delta, and I didn't see a problem.

I'll fix this and run tests on multiple printers. Also I'll rename UsingG54, it's related to to G53 not G54.

dc42

@frafa said in Firmware 2.02RC5 now available:

@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 ...

Please can you try again, but this time:

Verify that firmware 2.02RC5 is definitely installed (send M115 to check)
Check that you don't have a deployprobe.g or retractprobe.g file in /sys on the SD card, unless you are using BLTouch
If the problem still occurs, send the commands in your homing file one by one to establish which command is failing.

My SCARA is working fine on 2.02RC5 with just G30 for Z homing, provided that I home prox+distal first. I am using an IR sensor, so I don't have deployprobe.g or retractprobe.g files.

garyd9

@dc42 said in Firmware 2.02RC5 now available:

@resam, thanks for your analysis, that looks like the explanation. The odd thing is that I ran pause/resume tests on my delta, and I didn't see a problem.

I believe that I've encountered this same issue a few times. My resume.g is identical the one posted by @resam , though mine also contains a M906 to reset the idle current for the stepper motors (I set the idle current to 100% in my filament-change.g)

In my case, the nozzle crashing against the print has, I believe, caused physical damage when the part fan duct was shoved against the side of the print, and pressed hard against the wires from my heater and Pt1000 thermistor. (Apparently, smashing the side of a PT1000 where the wires come out can be bad for the PT1000.)

Note: I'm not trying to make any claim for the destroyed thermistor. I completely recognize that I'm using RC firmware and that's one of the risks I take. On the other hand, I'm hoping that @dc42 can get a fix for this particular issue out more quickly considering that it can cause physical damage.