My #1 feature request is an option to sort the gcode filenames by date. 99% of the time I want to print the file I just uploaded.
Scrolling thru all the files, while trying to remember what I just uploaded is pretty annoying. I end up with a lot of gcode files that look like aaaaaaSomeobject.gcode with the aaaaaaa to get it to sort at least to the first page. Obviously this isn’t a very good workaround.
I have a machine with 1Z cantilever bed. I'm using a Stepper Online 10:1 precision planetary gearmotor for Z.
I'm measuring a backlash of 0.044mm. (which is about 80% of the datasheet max backlash). 22% of a standard 0.2mm layer height
With a M425 Z0.044 S1
There's too much lag in compensating the backlash to make bed mesh really useful.
Ideally i'd like it taken up as fast as the stepper motor driver can take the steps on the reversal. Can we have an option for that? Like -S0 says do the backlash comp as soon as is possible?
I got significantly better layer stacking with my Delta with LDO steppers when i upgraded from OMC (same as ones linked above).
LDO datasheeet: https://cdn.shopify.com/s/files/1/0239/9287/files/LDO-42STH47-1684MAC_RevA_9f61050a-7275-4b98-a6c5-9f28bd0cb2b7.pdf?172
Filastruder carries them.
@arhi said in PanelDue Improvement Tips:
TBH it is easier to make slicer name file with YYMMDDHHmm prefix
Unfortunately PanelDue sorts A-Z so the most recent files are at the bottom, requiring scrolling.
Would be really nice if PanelDue allowed you to set the sort order.
The current RRF documentation for M593 indicates that there's a single frequency selectable for the input shapers. Will this be changed to support independent frequencies and shapers per axis? Machines are far from iso-resonant, so choosing one frequency and shaper for both axis will yield a sub optimal result.
Bedflingers in particular have radically different resonant frequencies.
On my crossed gantry 500x330 printer, one axis is best served by a 46hz ZV and the other by 68hz MZV shaper (according to klipper recommendations).
@dc42 if ram is a constraint, then that's an acceptable reason for duet2. But, i'd prefer if some other features were limited (like the LPC port does) to free up ram to support it.
If there isn't 2 axis input shaping in rrf3, I will await the klipper port to duet3. Duet3 mini port has been completed.
Input shaping is THE killer feature. And 2 axis is essential for it to work well.