RepRapFirmware 2.02RC4 released

[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
 

[garyd9]

@phaedrux said in RepRapFirmware 2.02RC4 released:

G1 Y-1 X1 F10000 ; Wipe nozzle

I don't understand how the line commented with "wipe nozzle" is wiping anything. You have a 40mm line along the X axis, and then the "wipe nozzle" commented line just moves the nozzle away from the extruded line at a 45 degree angle.

Usually, "wipe" actions push the hot nozzle through or against something else (such as slightly cooled extruded plastic.) Doing this usually cleans the nozzle as any debris on the nozzle will stick to the already extruded plastic. (Of course, if you have poor build plate adhesion, the "wipe" can result in a big glob of plastic sticking to the nozzle instead.)

As far as it being necessary... No, it's technically not. However, I do MANY things every single print that aren't strictly necessary, such as cleaning the nozzle with a wire brush, wiping it with something soft that's also heat resistant (such as leather or silicon), auto-calibrating before each print, using steel wool on my PEI sheet followed by acetone (or windex for PETG), etc.

While there are flaws in the script (such as extruding 0mm and X/Y movements that result in no movement) that might be confusing the firmware, I hope that any discussion about that script in this particular thread could be constrained to the inaccurate information displayed in DWC (and how to revise the script to work around the confusion) while retaining the function of the script.

I'd be happy to discuss the pros/cons of prime/wipe scripts (and any particular implementation) in another thread.

[dc42]

@insertnamehere said in RepRapFirmware 2.02RC4 released:

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?

I'm sorry, I can't reproduce this. I inserted five M226 commands into a GCode file, and it's working as it should.

Do you have anything unusual in your pause.g file?

[Phaedrux]

@garyd9 said in RepRapFirmware 2.02RC4 released:

I don't understand how the line commented with "wipe nozzle" is wiping anything. You have a 40mm line along the X axis, and then the "wipe nozzle" commented line just moves the nozzle away from the extruded line at a 45 degree angle.

I can post a video if you like, but basically the "wipe" part just pulls the nozzle out of the extruded line of plastic quickly, leaving whatever was attached to the nozzle attached to the line and the nozzle is clean.

By asking if it was necessary I merely meant perhaps there is another way to achieve what you're after. My example was just showing one such way.

[garyd9]

"Warning: motor phase A may be disconnected reported by driver(s) 2"

(I thought this was resolved in RC2 or RC3??):

I think it's happening during the very slow Z movements when doing G32 probing, but I can't be sure. I know it happens sometime between issuing G32 and getting the results on the paneldue console page. On this machine, I'm using the manual bed leveling assistant (that tells me how far to turn each of three leveling screws.)

I'm using a BLTouch on this printer (with probe type 5 that always worked for me, so I never changed to the BLTouch dedicated probe type.)

Here's everything in config.g related to movement or bed leveling:

M350 X16 Y16 Z16 E16:16 I1
M92 X93.91 Y93.84 Z401.0 E103.287:102.287
M566 X480 Y480 Z300 E1200:1200
M203 X12000 Y12000 Z2000 E3600:3600
M201 X750 Y750 Z150 E2000:2000
M906 X810 Y810 Z300 E810:810 I30
M558 P5 X0 Y0 Z1 H5 F100 T6000 A3 B1
G31 X-73.2 Y-0.8 Z1.17 P25
M671 X0.0:-51:48 Y-68.2:66.0:66.0 P0.5

// homeall.g

M280 P3 S160 I1 ; reset any bltouch alarm and pull up the pin
T1 P0                 ; X must be homed relative to the right nozzle.  P0 prevents any tool change macros
G91                   ; relative positioning
G1 S2 Z5 F6000        ; lower HBP relative to current position
G1 S1 X266 Y155 F6000 ; move quickly to X and Y axis endstops and stop there (first pass)
G1 S2 X-5 Y-5 F6000   ; go back a few mm on all axis
G1 S1 X266 Y155 F360  ; move slowly to X and Y axis endstops once more (second pass)
G90		; back to absolute
G92 X151 Y75	; set X and Y
G1 X73.2 Y-67.4 F6000  ; position the probe over the front/center screw adjustment point (offsetting from T1)
G91			; relative positioning
M401			; deploy the probe
G1 S1 Z-155 F6000	; quickly move Z down, stopping at the probe
G1 S2 Z5 F1200		; immediately move the nozzle 5mm away from the build plate
M401			; make sure the probe is deployed still
G30			; slowly probe at the current position and set Z to the trigger height
M402			; retract the probe

// bed.g

M561 ; clear any bed transform
G29 S2; clear any heightmaps
; Probe the bed at 3 points
M402 ; retract probe
G28 ; home
G90 ; absolute moves
G1 Z5 ; get the bed out of the way so the probe can deploy
G30 P0 X0.0 Y-68.2 Z-99999
G30 P1 X-51 Y66.0 Z-99999
G30 P2 X48 Y66.0 Z-99999 S3
M402 ; retract probe

Edit: The board is a Duet Ethernet 1.02.

[Danal]

@fcwilt said in RepRapFirmware 2.02RC4 released:

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

Skirt works when it is a choice.

Sometimes, NOT having a skirt is crucial to the "bottom to side" transition. Particularly on single-wall, zero infill, parts.

[fcwilt]

@danal said in RepRapFirmware 2.02RC4 released:

Skirt works when it is a choice.

Sometimes, NOT having a skirt is crucial to the "bottom to side" transition. Particularly on single-wall, zero infill, parts.

I have no idea what that means.

Frederick

[AlexLin]

@fcwilt maybe confusing skirt with brim....

[fcwilt]

@alexlin said in RepRapFirmware 2.02RC4 released:

@fcwilt maybe confusing skirt with brim....

That may be the case.

Thanks.

Frederick

[dc42]

@garyd9 said in RepRapFirmware 2.02RC4 released:

"Warning: motor phase A may be disconnected reported by driver(s) 2"

(I thought this was resolved in RC2 or RC3??):

I think it's happening during the very slow Z movements when doing G32 probing, but I can't be sure. I know it happens sometime between issuing G32 and getting the results on the paneldue console page. On this machine, I'm using the manual bed leveling assistant (that tells me how far to turn each of three leveling screws.)

Can you try to pin this down? In RC4 I increased the minimum motor speed below which the open-load status from the drivers is ignored; so that message shouldn't be generated at low speeds.

Also, please use M115 to double check that you are running 2.02RC4.

[Danal]

@fcwilt said in RepRapFirmware 2.02RC4 released:

@alexlin said in RepRapFirmware 2.02RC4 released:

@fcwilt maybe confusing skirt with brim....

That may be the case.

Thanks.

Frederick

Yikes, correct!!! I was confusing skirt with brim...

So, let me change it to:

If you have room for a skirt, sure, that works. There may be circumstances where there is room for a prime line, but not for a standard full skirt.

[garyd9]

@dc42 said in RepRapFirmware 2.02RC4 released:

@garyd9 said in RepRapFirmware 2.02RC4 released:

"Warning: motor phase A may be disconnected reported by driver(s) 2"

(I thought this was resolved in RC2 or RC3??):

I think it's happening during the very slow Z movements when doing G32 probing, but I can't be sure. I know it happens sometime between issuing G32 and getting the results on the paneldue console page. On this machine, I'm using the manual bed leveling assistant (that tells me how far to turn each of three leveling screws.)

Can you try to pin this down? In RC4 I increased the minimum motor speed below which the open-load status from the drivers is ignored; so that message shouldn't be generated at low speeds.

Also, please use M115 to double check that you are running 2.02RC4.

M115
FIRMWARE_NAME: RepRapFirmware for Duet 2 WiFi/Ethernet FIRMWARE_VERSION: 2.02RC4(RTOS) ELECTRONICS: Duet Ethernet 1.02 or later FIRMWARE_DATE: 2018-11-18b5

As for pinning it down, I'll try this evening (US Eastern time.) Do you have any suggestions on how I could go about doing that? Just perform manual Z movements via "G1 Zxx F100"?

It's difficult to isolate via G32, as the message doesn't appear until the bed.g is completed, so it might be happening in the very first move that G32 performs, it it might be the very last... there's no way to really tell (that I'm aware of.)

As well, it doesn't happen every time I level the bed, and I believe it's more frequent the first time I level the bed after transitioning from standby power (5VDC via USB) to full power (24VDC via VIN) using the ATX controls.