My default profile has bulging corners but almost no visible ringing, but I'm happy to run some tests for you with more aggressive settings. (Looking forward to the new motion planner!)

Can you give me a table of test values you'd like to see? For reference, I'm on a CoreXY with a default profile of 180 jerk, 3600 accel, 60mm/s external perimeters. With these values, I have no observable ringing on the X-axis, and (if I squint hard and use a flashlight) 0.6mm wavelength on the Y for an 0.01s period, assuming it was up to speed at that point.

On 2.0RC6, DWC 1.21.1, I'm seeing the same thing as @zerspaner_gerd . When filament is loaded, I can click "Tool 0" to get a dropdown and select "Unload Filament". Once that's processed and the filament is unloaded, the menu is gone. If I click "Tool 0" at that time, it just cycles Active/Standby/Off.

M701 S"..."from the gcode console works fine, and once the new filament is loaded the menu re-appears.

With the RTOS port I assume it's now easier to add additional background tasks to the firmware. When a print starts, could the firmware also start running a simulation in the background, and when complete that simulation time could be fed back to DWC/PanelDue for an additional (and presumably more accurate) print time estimate?

With the RTOS port I assume it's now easier to add additional background tasks to the firmware. When a print starts, could the firmware also start running a simulation in the background, and when complete that simulation time could be fed back to DWC/PanelDue for an additional (and presumably more accurate) print time estimate?

Are there any plans for adding Windows network printer support to Duet RRF? If not, what is the appetite for an outsider to look into writing this? It looks like what's needed is a subset of WSPrint 2.0 support. (Notably: "You do not need to perform SOAP validation and processing. You can instead use string detection and replacement.")

https://docs.microsoft.com/en-us/windows-hardware/drivers/3dprint/enabling-wsprint-on-a-device

If this feature is implemented, it should take into consideration that G1 S2 moves on delta and corexy command individual motors to move, rather than moving in XYZ-space.

<edit>I see this has already been implemented, and there has already been a bug fix for this.</edit>

@dc42 Confirmed.

I scripted up a test print that linearly increases the acceleration with Z-height from "0" (60) up to 9000. Ringing indeed becomes prominent as the acceleration time falls down towards and below the ringing period.

My default profile has bulging corners but almost no visible ringing, but I'm happy to run some tests for you with more aggressive settings. (Looking forward to the new motion planner!)

Can you give me a table of test values you'd like to see? For reference, I'm on a CoreXY with a default profile of 180 jerk, 3600 accel, 60mm/s external perimeters. With these values, I have no observable ringing on the X-axis, and (if I squint hard and use a flashlight) 0.6mm wavelength on the Y for an 0.01s period, assuming it was up to speed at that point.

Yep, that's the behavior I see. I just didn't expect the tpost file to be required, based on the docs. Cheers!

True about the listed M116--I wasn't expecting that one to wait, I was just including it in the quoted command sequence for completeness. What I was expecting was for the T0 command to perform an implicit M116 based on this:

T Select Tool

The sequence followed is:

1. Set the current tool to its standby temperatures specified by G10 (see above),
2. Set the new tool to its operating temperatures specified by G10 and wait for all temperatures to stabilise,
3. Apply any X, Y, Z offset for the new tool specified by G10,
4. Use the new tool.

Running 2.0, I'm configuring a new profile for S3D. I've modified the S3D "firmware configuration" to use G10 and M116 rather than M104 and M109 for setting tool temperatures, so it doesn't stomp over my "standby" temperatures. (Side note: could M104 and M109 be made to control only the active temperature and not the standby temperature?)

According to the docs, T0 should wait for temperatures to stabilize since I do not have tfree/tpre/tpost scripts configured, but this code sequence does not wait, and instead charges on printing cold:

T-1
G10 P0 S210
M116 P0
T0

I'm able to work around this by adding a tpost0.g containing an M116 P0.

Is this user error, doc error, or a bug?

On 2.0RC6, DWC 1.21.1, I'm seeing the same thing as @zerspaner_gerd . When filament is loaded, I can click "Tool 0" to get a dropdown and select "Unload Filament". Once that's processed and the filament is unloaded, the menu is gone. If I click "Tool 0" at that time, it just cycles Active/Standby/Off.

M701 S"..."from the gcode console works fine, and once the new filament is loaded the menu re-appears.

@dc42 There were ~70. Half of those are test macros and related subroutines that maybe shouldn't be in there. (The entry-point macros are in /macros but I didn't want the subroutines to show up on the "macros" DWC UI menu.) The other half are config.g, but factored apart such that reusable parameters were in one place.

https://github.com/daveidmx/VORON/tree/feature/config/Firmware/DuetWifi/V2/daveidmx

For example, here are my homex.g and homeall.g, written such that the actual Z-hop moves and X/Y/Z probe moves are in their own files. They are re-usable and only need to be changed in one place.

; homex.g
M98 P"homing_zhop_up.g"
M98 P"homing_probe_x.g"
M98 P"homing_zhop_down.g"

; homeall.g is a slightly optimized XYZ homing script that probes X, Y, and Z together without an intervening Z-hop between each axis
M98 P"homing_zhop_up.g"
M98 P"homing_probe_x.g"
M98 P"homing_probe_y.g"
M98 P"homing_probe_z.g"
M98 P"moveto_center_xyz.g"

Maybe these should be shipped off to /macros?