RepRapFirmware 2.02RC4 released

[frafa]

Hello

Same problem on 2.02RC4 for me
https://forum.duet3d.com/topic/7316/firmware-2-02-release-candidate-3-now-available/70

[dc42]

@frafa said in RepRapFirmware 2.02RC4 released:

Hello

Same problem on 2.02RC4 for me
https://forum.duet3d.com/topic/7316/firmware-2-02-release-candidate-3-now-available/70

I'm sorry, I remember reading that post but somehow it didn't get added to my list of issues to investigate.

I've just reproduced that problem on my own SCARA by changing the homing file not to use the Z endstop. In my case, the reason is that I have a G1 XY move to position the arm just before the G30 move, and the firmware isn't allowing that move because the Z axis is not homed.

I will fix this in the 2.02 release. Meanwhile, a possible workaround is to use a G1 S2 XY move to set the arm positions to specified angles, instead of commanding a specified XY position.

[frafa]

Hi David,

Homing ok if i add:

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

But test move after homing return error ...

17:26:48
G28
17:25:46
M120
G91
G1 Y10 F6000
M121
Error: G1/G2/G3: intermediate position outside machine limits

[dc42]

I've implemented a fix in the source code, which will be included in 2.02RC5. Thanks for your patience.

[frafa]

Thank you
No problems David 1.21RC3 works perfectly in the meantime

[insertnamehere]

Previously I've been using M226 to pause prints by editing it into the gcode. I've just tried that on RC4 and although it paused, it also locked up and I was unable to continue the print. A power off was the only way to reset.

M600 was doing the same thing in RC3.

Anybody else experiencing this?

[dc42]

We had a report of this one or two RC versions ago, but I was unable to reproduce it. I'll test it again. Please post your pause.g file here.

[garyd9]

With RC4, DWC is still often reporting an incorrect current layer. In the attached/linked gcode file, there are 70 layers. DWC is reporting that layer 2 of 70 is currently being printed for many layers (I'm currently printing the 6th layer and it's still showing 2 of 70.)

Slicer is cura 3.6.0 and adaptive layers is turned OFF. The "LAYER:xx" comments in the gcode file are correct.

In the attached image, you can see Z is at 1.01 which corresponds to the 6th layer in the file, but DWC still thinks it's on layer 2 of 70 (search for "LAYER:5" in the gcode file (Cura layer numbers start with 0 in the gcode file.))

gcode file: (google drive link) https://drive.google.com/open?id=1O-v-Pu1YvzgWd29iQmxBT9_bVLOqXol-

[dc42]

@garyd9 said in RepRapFirmware 2.02RC4 released:

With RC4, DWC is still often reporting an incorrect current layer. In the attached/linked gcode file, there are 70 layers. DWC is reporting that layer 2 of 70 is currently being printed for many layers (I'm currently printing the 6th layer and it's still showing 2 of 70.)

I think this line, just before the "end of prime line" comment, is confusing the firmware:

G1 X34.441 Y-145.764 Z4.2 E0 F9000

Because it contains both XY movement and extrusion, the firmware classifies it as a printing move, and it therefore thinks that you have completed the print up to Z=4.2. It is waiting for an extruding move at a greater Z height before it counts another layer.

[Martin1454]

@dc42 Im trying to update my bed.g to support the latest release.

I use 3 independent lead screws, and your IR probe.

My old bed.g file was:

; bed.g
; called to perform automatic bed compensation via G32
;
; generated by RepRapFirmware Configuration Tool on Tue Jul 31 2018 15:05:50 GMT+0200 (Centraleuropæisk sommertid)
M561 ; clear any bed transform
G28 Z;
G29 S2; Clear bed height map 
; Probe the bed at 3 points
G30  P0 X0 Y160 Z-9999 ; Front Right
G30  P1 X320 Y47 Z-9999 ; Front Left
G30  P2 X320 Y280 Z-9999 S3 ; Center Rear

I can now see that a tool have to be selected, but do I also have to use 1 of the S-* parameters? If so, how?

[dc42]

I can't think of any reason why you would need to change the bed.g file for the latest release. You should not need to have a tool selected. You do need to have homed X and Y as well as Z, so you might want to change the G28 Z command to just G28.

BTW, M561 and G29 S2 do the same thing.

[Martin1454]

@dc42 Well, I get an "homing error" when the it is done probing the 3 points and returning to X0 Y0

I home in my X and Y in the homeall.g and Z in bed.g

Here is my home all:

M400; make sure everything has stopped before we make changes
M574 X1 Y1 S3		;		
M913 X30 Y30 		; XY motors to 30% current	
M915 X Y H400 S3 R0 F0	; set X and Y to sensitivity , do nothing when stall, unfiltered
 
 
; X axis home		
G91			; use relative positioning
G1 Z5 F6000 S2    ; lift Z relative to current position
G1 S1 X-405 F6000 ; move quickly to X axis endstop and stop there (first pass)
G1 X5 F6000       ; go back a few mm
G1 S1 X-405 F4000  ; move slowly to X axis endstop once more (second pass)
 
; Y axis home
G1 S1 Y-305 F6000 ; move quickly to Y axis endstop and stop there (first pass)
G1 Y5 F6000       ; go back a few mm
G1 S1 Y-305 F4000  ; move slowly to Y axis endstop once more (second pass)
G90               ; absolute positioning
M913 X100 Y100; motor currents back to 100%
 
; Z-axis
 
M561                     ; Clear any bed transform
G32                      ; Start 3-point probe sequence - Bed.g
;M375 P"bareplate.csv"    ; Load heightmap
G1 Z20.0 F6000           ; Move Z to 20
G1 X5 Y5    		 ; Move Head to front left

[resam]

@deckingman said in RepRapFirmware 2.02RC4 released:

I do still get a short "double blip" of the hot end fan when booting but it's much much shorter and the overall boot up time seems to be faster.

I think I always had this double blip - see my video (listen to the audio!)
https://www.dropbox.com/s/tz5n8j4xaparicd/fan-double-blip.mp4?dl=0
Also take a look at my reconnect time of the PanelDue.
DuetWifi 2.02RC4 + PanelDue 1.22.1

@dc42 is this normal behaviour - or do you suspect something is wrong?

[dc42]

@resam said in RepRapFirmware 2.02RC4 released:

@deckingman said in RepRapFirmware 2.02RC4 released:

I do still get a short "double blip" of the hot end fan when booting but it's much much shorter and the overall boot up time seems to be faster.

I think I always had this double blip - see my video (listen to the audio!)
https://www.dropbox.com/s/tz5n8j4xaparicd/fan-double-blip.mp4?dl=0
Also take a look at my reconnect time of the PanelDue.
DuetWifi 2.02RC4 + PanelDue 1.22.1

@dc42 is this normal behaviour - or do you suspect something is wrong?

Do the heater LEDs on the Duet flash twice too?

[resam]

@dc42 said in RepRapFirmware 2.02RC4 released:

Do the heater LEDs on the Duet flash twice too?

As long as I press the reset button on the DuetWifi, the hotend fan turns on.
When I release the reset button, the fan is still on for a second or so, before it goes off, and then turns on for a second before finally turning off.

Both LED E0 HEAT and LED E1 HEAT flash on a single time.

[sigxcpu]

My LEDs (P2) flash once, the thermostatic fan (P1) "flashes" twice. I don't hear the pump (P0) "flashing" at all.

[dc42]

@resam said in RepRapFirmware 2.02RC4 released:

@dc42 said in RepRapFirmware 2.02RC4 released:

Do the heater LEDs on the Duet flash twice too?

As long as I press the reset button on the DuetWifi, the hotend fan turns on.
When I release the reset button, the fan is still on for a second or so, before it goes off, and then turns on for a second before finally turning off.

Both LED E0 HEAT and LED E1 HEAT flash on a single time.

That's all as expected. Fan 1 is on by default, in case you reset the machine or upload firmware to it while the hot end is hot and need to be cooled. In 2.02RC5 the heater LEDs won't flash.

[MoS-tekknix]

This post is deleted!

[garyd9]

@dc42 said in RepRapFirmware 2.02RC4 released:

@garyd9 said in RepRapFirmware 2.02RC4 released:

With RC4, DWC is still often reporting an incorrect current layer.   In the attached/linked gcode file, there are 70 layers.   DWC is reporting that layer 2 of 70 is currently being printed for many layers (I'm currently printing the 6th layer and it's still showing 2 of 70.)

I think this line, just before the "end of prime line" comment, is confusing the firmware:

G1 X34.441 Y-145.764 Z4.2 E0 F9000

Because it contains both XY movement and extrusion, the firmware classifies it as a printing move, and it therefore thinks that you have completed the print up to Z=4.2. It is waiting for an extruding move at a greater Z height before it counts another layer.

How can I inform the firmware that a certain block of gcode is a preamble and should be ignored for layer calculation? While I can certainly "fix" that last line of the prime/wipe script, there's a similar line near the beginning of the script that might also cause the same issue.

Even if I start my "prime/wipe" line at 0.2mm, it sounds like it'd still confuse the firmware (but at least to a lesser degree) as it actually performs a movement while extruding.

BTW, that "prime line" script was something I copied from another person without actually examining. Looking at it now, the last several lines of it seem... odd. While there's nothing technically wrong with specifying "E0" with G1, or a G1 that "moves" to the exact same X and Y as the previous G1, I do want to clean that up.

It won't fix this problem, but at least the script would make more sense to me.

[fcwilt]

@garyd9 said in RepRapFirmware 2.02RC4 released:

How can I inform the firmware that a certain block of gcode is a preamble and should be ignored for layer calculation? While I can certainly "fix" that last line of the prime/wipe script, there's a similar line near the beginning of the script that might also cause the same issue.

I cannot see any reason to you need to be doing a move with extrusion for "prime/wipe" purposes.

What is your reasoning?

Thanks.

Frederick