Hello,

I am attempting to query the machinePosition of one of my axes, specifically axis 7 (Duet 2 Wifi + Duet X5) on an E3D Toolchanger. This is the toolhead axis, C, that locks and unlocks tools; it is set to driver 7 in the config.

M584 X0 Y1 Z2 C7 E3:4:5:6 									; Apply custom drive mapping

However when querying the position using

move.axes[7].machinePosition

The following error appears:

M98 P"0:/macros/SIMUL_HOME_TEST"
Error: in file macro line 49 column 4: meta command: array index out of bounds.

Is there a specific indexing for the Duet X5 drivers?

Hello,

I recently found that input shaping is not available on expansion boards and was shocked. I've been thinking about using closed-loop for XY on a printer (mostly because why not? I love the idea of closed-loop).

Is there a timeline for adding this functionality? Also curious what is the thing preventing input-shaping from being available on expansion boards from a software standpoint.

Thanks!

Hello,

I've been setting up some tools on my Toolchanger and tuning the offsets (especially if you're changing nozzles often) can be a pain. The values are close but require baby-stepping to tune perfectly.

It would be nice to have a "Save Tool Offset" button under Z-Babystepping that would change the G10 tool offsets in Z in config.g (or perhaps have another parameter to specify a system file or macro that contains the offsets). It would then set the Babystepping value to zero so the Babystepping value wouldn't affect other tools.

Thoughts?

Hello,

I know there is a boolean variable for each axis to determine if it has been homed or not, just cannot find the syntax after searching online.

Something like axis[n].homed (for n being a integer indexed at 0) or similar.

Trying to make simultaneous axes homing for completely independent axes on an E3D Toolchanger (toolhead and XY) which i think requires conditional statements as something like:

G1 H1 Y-400 C-500 F5000			; SIMULTANEOUS HOME Y AND C

terminates the homing movement program as soon as one axis homes (both use stall detection). Therefore I think conditional if/else statements need to be used.

Ex
if (y is homed){
continue homing C
begin homing X
}

else {
continue homing Y and run macro to return C to unlocked position (not sure if this can be done simultaneously)
}

I realize the time to home is much much smaller than the time to heat up the printer but still thought it would be fun to optimize a bit.

@T3P3Tony this is for the case where I'm waiting for the actual hotend that is going to be used. For instance if I'm just using T0 for the print (no toolchanging).

1. T0 starts at 250C as I just finished a print, or had to stop it for some reason, whatever it is--the tool is hot.
2. Start code waits for T0 to reach 180C, which is it's standby temperature (as well as other hotends if used, and bed).
3. Homing
4. Toolhead goes to pickup T0
5. Printer waits for T0 to heat back up to 250C

It would be nice if it was possible to recognize if the tool was already at or above the standby temperature so it didn't wait to cooldown just to heat back up again.

I'm going to try using conditional gcode for this, but it would be nice if it was just an alternative parameter in the M116 gcode.

@Phaedrux slicer retraction.

@OwenD I'm not sure if putting it in the start code will help. I want the process to look like the following:

Prime nozzle -> retract -> move to print starting coordinates -> deretract -> start the print.

The start gcode ends after the retract stage.

@Phaedrux it is an actual retraction, I do a prime, then retract for the move to the printing start point, however, the slicer doesn't have the retract undone before the actual print starts.

Hello,

The E3D Toolchanger uses three macros for toolchanges, the tfreex.g, tpostx.g, and tprex.g. In which I have retractions, extrudes (undoing retractions), and other macros, such as initial purge, retract, and brush.

I'd like to keep these macros as they work well but I notice that the start of my print usually has a few mm before any plastic is extruded because of the retraction at the end of the tool picking so the hotend doesn't ooze anything on it's travel between the brushing area and the start of the print. Is there a way to get the printer (or slicer to have the printer) undo that final retraction and then actually start printing?

I'm not sure if this was a question for Duet or PrusaSlicer so I'm posting in both.

Thanks!

@Exerqtor awesome thanks!!

@Phaedrux yup I did! I just like seeing multiple ways of doing the same thing if I want to take something from another method to incorporate it. I am a fan of Frankensteining things together

@Exerqtor can you share the link when you get a chance?

@Phaedrux while possible for a Voron 2.4, they recommend doing a mesh for every print regardless. I guess for different bed temperatures and expansion/warping.

If done adaptively it really doesn't add much time to the total print startup, even non-adaptive is a fairly small amount of time.

Hello,

I've recently been building out a Voron printer that runs Klipper and came across a community add-on/script that allows the printer to adaptively change the bed mesh to fit the parts being printed. This saves time and gathers more important (and granular) data about the bed where it's needed. There is also another script for adaptive purge lines that is print-dependent.

Is there a community-developed script for this already in existence? If not it would be an incredible development for RRF if it was natively supported.

Here is a link to the GitHub for both the bed meshing and purging for reference.

Thanks!

Hello,

I've recently been printing a large part that takes up most of my printer's bed. I've noticed that the bed mesh (due to a rather uneven, unadjustable bed) causes fast print moves (200mm/s) with sudden stop-starts along its trajectory, most likely as the z-motor cannot keep up with the requirement for the mesh bed.

It would be nice to have the option to turn on the mesh bed in a print with a smooth mesh bed which will calculate the maximum speed a move can be made and adjust the requested speed accordingly so the motion will be smooth instead of jerky.

This could either be implemented as a separate command (G29 S5) or have the mesh bed compensation updated to use this. My concern for implementation is the required computation of such calculations and if they'd be substantial enough to exceed the capabilities of the processor (for reference I am running a Duet 2 Wifi).

I understand using something like glass or a MIC6 bed would essentially solve this problem, but that can be expensive.

Thoughts?