Best posts made by Kiolia

This may already be on the RRF development radar, but I'd like to request that Pressure Advance be extended with the option of a smoothing factor like Klipper's pa smooth time that takes the edge off extrusion rate slams under accel/decel.

So far as I can tell, RRF PA commands instant E feedrate changes that can be quite large, and speed caps printing if E jerk can't meet those. However, E jerk is very hardware-intensive with gear reductions involved, and that makes it quite challenging to spec a workable extruder for high accel on any length of bowden.

(For context, I have been working on a couple of extruder designs for short, medium, and long bowdens on my 6WD delta (Duet 3 6HC + 3HC toolboard), and generally finding good success with getting high extrusion quality and reasonable PA values, but the E jerk demands just get untenable with PA enabled into 5 figure accel ranges. Given that I've hit the same wall with every commercial extruder I've run before now in bowden configuration, I'm coming to the conclusion that this is not a fully hardware-solvable challenge and hoping RRF can gain more levers to pull so printing accel doesn't have to be capped by E jerk limits.)

I want to chime in and report that the 3.6.0 5+1 alpha has been working well for me. I have not run any long prints, and I don't probe or tool change, but I changed over from 3.5.1 because I was hitting suspicious layer shifts at well below expected accelerations for printing moves only (not for travels) in speedboat testing. I have run 25 prints since changing over Sept 3rd, along with various non-printing tuning and tests, at accelerations from 50-200k and in-print speeds up to 900mm/s, on a 6WD delta at 400 steps/mm (6HC with a 3HC running a 2WD extruder), as I've been working into the three-minute range on regulation boats. (Yes, it's not a particularly useful pastime, but my machine is finally finished and I've gotta do it once -- plus I'm hoping it's a useful stress test of the new motion stuff in 3.6.0.) The new IS melts down print crispness at these accels, but after some deep breathing I've concluded that's not a bad thing -- if you want crispy prints, the answer is to print in the accel range that's sane for your machine, anyway.

Part of my testing has been aimed at stress testing the delta segmentation change -- I've tested from 100 to 400 seg/s with 0.1 to 0.2mm segment length, as well as accidentally 0.1seg/sec and 400mm min length, and apart from the latter booboo there is little observable difference in quality at high speeds and no difference I've yet found in terms of speed ceiling. I have found that high speeds with high-poly models are causing reports of underruns in the first array slot and, sometimes, very small numbers of LaErrors -- e.g., a 67-layer test vase print with a portion that is a 200-segment, 10mm-diameter circle, sliced at 350 x 100k x 20 jerk consistently reports back underruns [800+,0,0] -- but I don't have comparison data from before I updated, so I don't know if this has anything to do with the alpha. I do know that the circle in that stress test print shows evidence of slowdowns starting at about the same segment count as the move queue length, and that extending the queue length with M595 causes proportionately more reported underruns. (I changed SD cards, just to see if the originally-supplied card with its 4kb clusters was an issue, but a new 32GB card with 32kb clusters did not change anything.) For my foolishly-fast speedboat runs, I've dodged the issue by enabling Arc Welder, which seems to work just fine.

To date I have yet to see a single reported hiccup, regardless of LaError or underrun counts.

I hope the above is useful!

@gloomyandy I do wonder about the Klipper implementation and how it may slide the start of pressure build forward. Physically, there must be some delay between the start of an E move and extrusion actually starting, so presumably if smoothing is correct this would be right. However, that gap would be disconnected from the smoothing time required solely for the extruder's sake. If klipper users are complaining about accuracy issues with high smooth time, perhaps that is partly because of moving that buildup too early?

-- And this toward what I mentioned before about smoothing time papering over extrusion system inadequacies: if you have to set a high smooth time because you're trying to run bowden PA with a 4:1 Mobius (for example), the smooth time isn't helping your extrusion quality, it's compensating for that poor stepper trying to deliver 4x the E demand. That's why I think it's worth being critical of complaints about smooth time in Klipper from users who may not be setting themselves up for success from the hardware perspective. It's still a fudge factor (probably), but outcomes depend a lot on how much you're trying to fudge

@gloomyandy 3.6.0 5+1.

Hello, I've been trying to get M309 working on my Delta (6HC with 3HC controlling E and T0), but I could not see any difference in heater PWM behavior with feedforward enabled or disabled.

I inquired on Discord and gloomyandy stated that RemoteHeater.h currently says feedforward is not supported on remote heaters "yet" (in the SetExtrusionFeedForward declaration). However, this is not listed as a known limitation for CANboards in the online docs. I wonder if this just fell off the radar?

Could this be added as a known issue and ideally slated for fixing in a future release? It seems like a significant gap to have unsupported heater control functionality for such a common hardware case.

@Notepad I have run into something similar to this, but I can't reproduce it yet... detailed my experience at the bottom of the earlier 3.6.0 alpha build thread.

@Mr-Crispin I have a 6HC with 3HC toolboard, standalone mode. I have had almost the same exact experience twice, once when going from 3.4.x to 3.5.1 and once when going from 3.6.0-alpha5+1 to 3.6.0-beta.1. Somehow I was able to avoid it when going from 3.5.1 to the 3.6.0-alpha. I believe it helped to have my CANBoard unplugged when I updated the mainboard, but I will have to verify this next time I update.

The first time it happened, I had attempted to update mainboard and toolboard together; the second time it happened, I had tried to update the mainboard by itself, but still had the CANBoard plugged in. Both times were terrifying and made me think I'd bricked my 6HC.

As supplemental info, I got this message both times this happened to me, but it never appeared in the console log:

After this, the printer posted no further updates for 15-20 minutes, whereupon I restarted it, and from there the PanelDue would show the usual control screen, except with 0's in all values (as if it had not loaded config.g), and was completely nonresponsive on the console as well as inaccessible via DWC. I had to go through Bossa to reflash in both cases.

@droftarts @dc42 I hate to be a bother, but it seems related -- would it be possible for you to check the code that compensates for tool cooling based on the second K term set by M307? I have a growing suspicion that this isn't working, either.

Source/testing: I was hoping to use second K manipulation as a backdoor patch for missing feedforward, but after 30 minutes of testing, I can't see any difference in the temp drops or PWM reactions to a range of second K's from .05 to .485. In each test case, without moving the head (from 1mm Z), the application of full CPAP knocked temps down by the same amount (+/-5%), ramp to the new PWM level took about the same amount of time, recovery of the hot end to commanded temp took about the same amount of time, and stability of the temps after regaining commanded temp looked about the same.

I started doing diagnostics like sending M307 H1 to check the actual applied tuning values, then realized this was a little too similar to my last round of feedforward testing and figured I'd better ask.

One thing I did not test was un-selecting the tool and re-selecting it between M307's, if that matters.

The range of values I tested went from fairly lower than ideal to fairly higher. Most recent tune value, done tonight at the same toolhead location, was M307 H1 R3.181 K0.424:0.185 D4.11 E1.35 S1.00 B0. I have not changed my machine setup or firmware version since that described in the original post above. (Edit: and yes, the hotend is that efficient and windproofed. I've invested a lot of effort in optimizing thermal efficiency.)

EDIT 2: this testing was done in 3.6.0-beta.1. I cannot say for certain if it was working or not in -alpha.5+1. I believe it was working in 3.5.1, but at the time I wasn't running as aggressive of cooling profiles in any print tests, so it's hard to say. I've been having difficulties with updates, so I'd prefer not to roll back to verify behavior.

EDIT 3: I will also note that I did my testing with fan setting via the DWC fan controls, not by sending Gcode commands, if that matters.