Posts made by paralepsis

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

@dc42 makes sense to me!

@oliof Thanks. Might make sense to have the # of objects documented with M486 also, so it isn't a surprise?

I tend to use the location of the objects in the overhead view for canceling anyway, so the errors are mostly a distraction :).

Hi,

Using PrusaSlicer and RRF flavor of object descriptions, I have a gcode file that looks like this:

...
486 S0 A"gaslands-dungeonsticks-85perc-barrier-notched.stl"
M486 S-1
M486 S1 A"gaslands-dungeonsticks-85perc-barrier-shot.stl"
M486 S-1
M486 S2 A"gaslands-dungeonsticks-85perc-barrier-whole.stl"
M486 S-1
M486 S3 A"gaslands-dungeonsticks-85perc-barrier-sloped.stl"
M486 S-1
M486 S4 A"gaslands-dungeonsticks-85perc-barrel-split.stl (Instance 1)"
M486 S-1
M486 S5 A"gaslands-dungeonsticks-85perc-barrel-split.stl (Instance 2)"
M486 S-1
M486 S6 A"gaslands-dungeonsticks-85perc-barrel-split.stl (Instance 3)"
M486 S-1
M486 S7 A"gaslands-dungeonsticks-85perc-barrel-split.stl (Instance 4)"
M486 S-1
M486 S8 A"gaslands-dungeonsticks-85perc-barrel-split.stl (Instance 5)"
M486 S-1
M486 S9 A"gaslands-dungeonsticks-85perc-barrel-split.stl (Instance 6)"
M486 S-1
M486 S10 A"gaslands-dungeonsticks-85perc-barrel-split.stl (Instance 7)"
M486 S-1
M486 S11 A"gaslands-dungeonsticks-85perc-barrel-split.stl (Instance 8)"
...

I get the following on console:

...
Error: in GCode file line 912 column 62: M486: string too long
Error: in GCode file line 914 column 62: M486: string too long
Error: in GCode file line 916 column 62: M486: string too long
Error: in GCode file line 918 column 62: M486: string too long
Error: in GCode file line 920 column 62: M486: string too long
Error: in GCode file line 922 column 62: M486: string too long
Error: in GCode file line 924 column 63: M486: string too long
Error: in GCode file line 926 column 63: M486: string too long
...

Yeah, those are long, I get it :).

I imagine there's somewhere in the docs that max. string lengths are mentioned, but not here: M486. It might be worth capturing here?

More pragmatically, it would be awesome if PrusaSlicer would truncate somehow to avoid the errors (I can rename myself in the future I guess). Is anyone here in a good position to make such a tweak?

Thanks!

Rob

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

@droftarts It depends on what happens to be in those boxes. I found I got unreasonable jerk/accel settings that really messed things up (some time ago, in my case with PrusaSlicer). Skipping steps all over the place, etc.

@Firefly yes, this is default behavior when switching to RRF in PrusaSlicer also. It's a terrible default.

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

@Sindarius sure!
heightmap.csv

@Sindarius thanks!

@Sindarius Just a ping; this odd visualization is still present in 3.5.0rc2.

probePoints.csv

01_gridProbe.gcode