RepRapFirmware 2.02RC4 released

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

insertnamehere

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

I'll try to make it happen again and see if I can give you a step by step.

M83 ; relative extruder moves
G1 E-10 F3600 ; retract 10mm of filament
G91 ; relative positioning
G1 Z3 F360 ; lift Z by 3mm
G90 ; absolute positioning
G1 X0 Y250 F6000 ; go to X=0 Y=250

garyd9

@fcwilt said in RepRapFirmware 2.02RC4 released:

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

Extruding a prime line (for prime/wipe) involves extruding filament while moving (as if printing a thick layer of filament.) The next step is to move back over the extruded filament while not extruding.

fcwilt

@garyd9 said in RepRapFirmware 2.02RC4 released:

@fcwilt said in RepRapFirmware 2.02RC4 released:

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

Extruding a prime line (for prime/wipe) involves extruding filament while moving (as if printing a thick layer of filament.) The next step is to move back over the extruded filament while not extruding.

Interesting. I've not heard of that before. The priming code I've seen just extrudes a small amount with no movement.

Thanks for the feedback.

Frederick

Danal

FWIW, I've found a "prime line" deposited on the glass, "off to one side", to be a great help in getting certain printers to succeed with the first layer, while NOT having a blob/defect on the bottom of the part (from priming "in the air" and the prime falling or being squished).

fcwilt

@danal said in RepRapFirmware 2.02RC4 released:

FWIW, I've found a "prime line" deposited on the glass, "off to one side", to be a great help in getting certain printers to succeed with the first layer, while NOT having a blob/defect on the bottom of the part (from priming "in the air" and the prime falling or being squished).

I just print a few lines of "skirt" which gives me a chance to verify that all should be well and I can tweak the Z height if needed.

Since this is handled by the slicer it doesn't cause any issues.

Frederick

Phaedrux

@garyd9 said in RepRapFirmware 2.02RC4 released:

The next step is to move back over the extruded filament while not extruding.

Is that really necessary? I get excellent results with this prime line gcode.

G90 			; Absolute positioning
G1 X1 Y270 F6000 		; Move to front left corner
M400 			; clear movement buffer
M116 			; Wait for temps
G1 Z0.3 F100		; Move Z to prime height
G91 			; Relative positioning
M83 			; Relative extrusion
G1 X40 E10 F300 	; Prime nozzle
G10			; Retract
G1 Y-1 X1 F10000 	; Wipe nozzle
; Move to first layer Z height and start skirt