RepRapFirmware 2.02RC4 released
-
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.
-
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-
-
@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.
-
@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?
-
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.
-
@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
-
@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?
-
@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?
-
@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
andLED E1 HEAT
flash on a single time. -
My LEDs (P2) flash once, the thermostatic fan (P1) "flashes" twice. I don't hear the pump (P0) "flashing" at all.
-
@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
andLED 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.
-
This post is deleted! -
@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.
-
@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
-
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 -
@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.
-
@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
-
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).
-
@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
-
@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