RepRapFirmware 2.02RC4 released

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

[dc42]

@garyd9 said in RepRapFirmware 2.02RC4 released:

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

No, if it happens at the end then it's the leadscrew adjustment move that is causing it, or possibly a command at the end of your bed.g file.

• Do you have any movement commands after the last G30 command in bed.g?
• How long does the leadscrew adjustment move take, in the worst case?
• Do you change the motor currents in bed.g? Sprious open-load reports are more likely at low motor currents.

[garyd9]

@dc42 said in RepRapFirmware 2.02RC4 released:

@garyd9 said in RepRapFirmware 2.02RC4 released:

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

No, if it happens at the end then it's the leadscrew adjustment move that is causing it, or possibly a command at the end of your bed.g file.

I think that I might be causing a misunderstanding: I read the "console" messages from the paneldue. When I start the "manual bed leveling assistant" from the paneldue, there is no console output (on the paneldue) until the entire process is completed. At that point, I might get 3-4 messages all appended to each other. For example, I might get a "Warning: motor phase A may be disconnected reported by driver(s) 2" message with a warning appended about an inconsistent probe, and append to that I get the output from the leveling assistant (that tells me which screws to turn and by how much.)

• How long does the leadscrew adjustment move take, in the worst case?

Your phrase "leadscrew adjustment" is confusing me. The only leadscrew in my printer is my Z axis (bed moves in Z.) I don't adjust that. I use three (manual) adjustment screws and manually adjust them as suggested by the duet after running the manual leveling assistant.

If you're referring to the Z-axis movement when probing, then it's perhaps 5 seconds worst case.

• Do you have any movement commands after the last G30 command in bed.g?
• Do you change the motor currents in bed.g? Sprious open-load reports are more likely at low motor currents.

I've posted the entire bed.g file above. The only thing after the last G30 is a M402 and no current adjustments (or things that would impact current.)

However, my Z axis stepper motor (with the leadscrew) is a low power stepper and configured for 300 milliamps. (from config.g: M906 X810 Y810 Z300 E810:810 I30)

[3dmntbighker]

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

I saw this message once with RC3. I wasn't sure what it meant, but the print had completed.

[garyd9]

@dc42 - an example of what I meant by:

@garyd9 said in RepRapFirmware 2.02RC4 released:

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 you can see by the message at 0m05, multiple messages are combined into a single entry, so I'm not sure where in the bed leveling assistant that the warning occurs.

[dc42]

What is your Z steps/mm and VIV voltage? It's just occurred to me that if the driver can't maintain the requested current due to the motor inductance being high, motor speed being high, and supply voltage being low, that too would give rise to an open load report.

[fcwilt]

Hi,

I would first fix the heater issues and the power supply issue.

Then see how things go.

Frederick

[garyd9]

@dc42 said in RepRapFirmware 2.02RC4 released:

What is your Z steps/mm and VIV voltage? It's just occurred to me that if the driver can't maintain the requested current due to the motor inductance being high, motor speed being high, and supply voltage being low, that too would give rise to an open load report.

M350 Z16 I1
M92 Z401.0

VIN is 24VDC.

Again, I want to point out that this doesn't seem to cause any harm, and it only seems to happen once in a while: usually the first time I run the leveling assistant after turning on the 24V PSU (via M80.) I can (and often do) run the manual bed leveling assistant 3 or 4 times before printing and it will only happen the first time.

If I run the assistant again before the PSU is powered down, I usually won't see the warning. However, if the PSU powers down (via M81 S1), it will usually happen again once I power it back on, heat up the build plate, and run the assistant again.

[dc42]

After turning on the power with M80, do you have any sort of delay before you run the bed probing command? You mentioned waiting for the heaters - do you always do that?

[garyd9]

@dc42 said in RepRapFirmware 2.02RC4 released:

After turning on the power with M80, do you have any sort of delay before you run the bed probing command? You mentioned waiting for the heaters - do you always do that?

Yes. My procedure is to run a macro (from paneldue) that turns on the 24V PSU via a SSR (and also turns on LEDs attached to one of the always-on fan headers.) I then prep my build surface and begin heating the bed. I don't start the manual leveling assistant after until the build area has reached 65C (PLA) or 90C (PETG/ABS/ePC) and settled.

I also often heat the nozzle I'll be using to a standby temperature while heating the build plate (130C or 160C depending on material.)

All of this is initiated on the PanelDue. For this machine, I rarely use DWC for anything besides remote monitoring.