@dc42 Finally got around to re-routing the cable, can confirm that fixed this problem. Just thought I'd post in case someone finds this thread relevant. Thanks again!

@chrishamm FWIW, working fine on my RailCore with PA and IS. Printed 10-15 hours so far. Heightmap when skipping points still looks funny :).

Edit: I'm running standalone mode.

@Phaedrux Hi, this printer was originally mine, and we debugged it.

The issue turned out to be that the crash had left the front-left corner of the plate much higher than the center of the bed (three Z steppers on a D-Bot, front left and right on same controller, not tied together with a single belt (obviously)). The macro would probe center of bed first to establish a "zero", then build the height map. Because the plate was so askew, on deploy the probe would hit the plate immediately in that front left corner, causing the fail.

While the root issue was the corner being too high, the fail could be avoided by moving to Z=10 after the first probe, leaving room for the probe to deploy. So that was added to the macro.

@dc42 said in Software bundle 3.5.0rc.4 now available:

We would like as many users as possible to test this release, so in order to simplify installation for users of Duet in standalone mode I have included a release zip for this version.

Initial prints on my (standalone mode) Railcore with IS and PA enabled have been all good.

@Phaedrux Yes. There's a small region in the front left and a small region in the back right (maybe 50x20mm) that I simply cannot go to at Z < 4. I think you get it.

Thanks for the clarifications. I think if I were going to go the heightmap route, what I would need to do is save multiple heightmaps, combine them manually, and then reload, right?

Too bad. I'll probably just do the work for the bigger bed.

Thanks again for all the attention today; I appreciate it!

Ok, I can confirm that this (in the input channel gcode):

; Set dummy filament diameter and then load filament settings
M200 D1.75 
M703

; report filament diameter?
M200

Does get me into volumetric extrusion mode, and that the M703 does result in a change in the filament diameter. Somewhat bogus way to have to do things, but this does solve my problem for me.

Thanks for the discussion, it helped.

@DocTrucker PrusaSlicer is your best bet if you're already accustomed to / resigned to the quirky UI of Slic3r. Alternatives worth mentioning include:

• SuperSlicer (mentioned elsewhere in the thread) has a similar UI and is nice, but hasn't gotten a lot of attention lately.
• OrcaSlicer (https://github.com/SoftFever/OrcaSlicer/releases/) is attempting to take the best of PrusaSlicer and Bambu's UI, as I understand it. I'm keeping an eye on it but sticking with PS for now.
• Cura is super powerful, also very popular, but will take some commitment to make the leap over to it in terms of re-learning how to configure and control what's going on.

Hacked up something to cover the missing regions, stitched together by hand. Probably not interpolation. Thanks again.

@paralepsis

[ I also tweaked the probe Z height in here, which is obvious when comparing the two heightmaps. ]

@dc42 Pressing two buttons worked great, was able to flash from web UI. Thanks all!

@fcwilt I'm assuming that the code is all that is needed, but maybe the thing to do is to wait for another answer?

@droftarts thanks for responding, sure. This all looks ok I think.

SD card summary:

M39
SD card in slot 0: capacity 31.91GB, partition size 31.90GB, free space 31.61GB, speed 25.00MBytes/sec, cluster size 32kB

M122 diagnostics:

M122
=== Diagnostics ===
RepRapFirmware for Duet 3 MB6HC version 3.5.2 (2024-06-11 17:13:58) running on Duet 3 MB6HC v1.01 (standalone mode)
Board ID: 08DJM-956BA-NA3TN-6J1FL-3S86T-9TBUS
Used output buffers: 3 of 40 (40 max)

...

=== Storage ===
Free file entries: 20
SD card 0 detected, interface speed: 25.0MBytes/sec
SD card longest read time 3.9ms, write time 123.8ms, max retries 0

...

=== Network ===
Slowest loop: 226.79ms; fastest: 0.03ms
Responder states: MQTT(0) HTTP(0) HTTP(0) HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0) Telnet(0)
HTTP sessions: 1 of 8
= Ethernet =
Interface state: active
Error counts: 0 0 5 1 0 0
Socket states: 5 5 2 2 2 0 0 0
=== Multicast handler ===
Responder is inactive, messages received 0, responses 0

SD card test (text reordered from console for readability):

M122 P104 S32
Testing SD card write speed...
SD write speed for 32.0MByte file was 5.98MBytes/sec
Testing SD card read speed...
SD read speed for 32.0MByte file was 1.99MBytes/sec

I'm fairly regularly getting stuck in a "connecting loop" (for lack of a better term) when I come back to my browser that was previously connected to my Duet 3 (see screenshot below). What you cannot see in the screenshot is that the green connecting box will be replaced with an orange "connection interrupted" box for a split second before the green box returns.

This is new behavior for 3.5.2, I'm seeing it in Firefox on two different OSX platforms, and I do not think I ever saw this prior to 3.5.2, certainly not with the 3.5.0 prereleases or 3.5.1. Printing does not appear to be impacted.

Typically re-loading the page will fix this, so it's not a showstopper. If I can help debug, I'm happy to.

@Simon-4 I think there are three different things going on to mention, here:

1. As stated above, retraction settings are sort of a special case and relate only to firmware retraction. Slicers doing (non-firmware) retraction just reverse the extruder stepper a certain amount via gcode commands, without the firmware knowing that retraction is occurring.
2. For things like maximum movement, acceleration, jerk, yes those config.g settings can be thought of as upper limits for correct operation.
3. That said, the slicer can emit gcode that overrides those. In fact there's a default in PrusaSlicer under Printer Settings -> Machine Limits -> How to apply limits that will promptly overwrite the values for many of these settings (you probably want that parameter set to "Use for time estimate").

Hope this helps.

Your settings should be in config.g.

@dlc60 Hey! Glad you got something working.

Re: G30, that does a single probe and sets Z coordinate to probe trigger height -- it's the equivalent of homing Z using that XY coordinate as the point at which to home.

I don't have a separate Z axis endstop, so this is how I "home" prior to doing the mesh probe. I guess you do have a separate Z axis endstop, otherwise I'm not sure that G30 S-1 is meaningful?

@dlc60 Ok. I'm not sure if this will help, but here's precisely what I do to set up my height map.

G1 X102 Y60 F2400 ; move to a consistent spot for probing
G29 S2                ; clear mesh
G30                   ; probe once

G91  ; relative positioning
G1 Z5
G90  ; absolute positioning

M557 X6.75:288 Y40:298.75 P10:10 
G29 S4 P"/sys/probePoints10x10all.csv"; load probePoints10x10all.csv to skip points

G29 S0 ; probe and enable mesh
M376 H5 ; taper over first 5mm (ought to be more than enough)

Obviously X and Y must be homed prior to this. You can ignore the G29 S4; that's for working around magnets. I won't say this is the "right" way to do things, but it certainly works consistently for me, and I get very small discrepancies in height map (as one would hope!).

Rob

@dlc60 So if you just boot up, home X and Y, home Z, and then move to Z=0, how far is the nozzle from the bed, in reality? Couple of mm away?

@dlc60 I'm not sure I'll be able to answer all your questions, but here are a couple of things:

• The range you've selected in M557 (start, spacing of 20 in X and Y) has mesh points at Y=190, which is not reachable according to the combination of Ymax (210) and probe Y offset (-21) that you've chosen. You could get rid of those warnings by tweaking the M557 parameters (e.g., Y4:189).
• The height map looks like it would be decent if not for a ~2mm discrepancy in offset. Sounds like you're probing separately to figure out what the Z offset should be, but you then need to account for that in the G31 Z parameter. A larger Z parameter will bring the nozzle closer to the bed.
• I would suggest concentrating on getting Z=0 to be in the right place first, and then worry about the height map.

Hope this helps.

@dc42 said in Software bundle 3.5.0rc.4 now available:

We would like as many users as possible to test this release, so in order to simplify installation for users of Duet in standalone mode I have included a release zip for this version.

Initial prints on my (standalone mode) Railcore with IS and PA enabled have been all good.

@Exerqtor M204 is leveraged by PrusaSlicer for feature-based acceleration control, is useful to have around.