3.5.0rc1: Input shaping causes layer shifts!?

[NeoDue]

@oliof 1st attempt with 16x microstepping + interpolation for the extruders: 1 layer shift - seems to be in the same range as 16x microstepping without interpolation for the extruders. I will add another print tomorrow to be sure!

... and then i am really curious if this helps @dc42 to find the issue in his code.

[oliof]

@NeoDue the most common way to run RRF is to use 16x microsteps with interpolation, but the latter should not figure into this except that maybe the driver behaves a bit differently. Going from 64x microsteps to 16x simply reduces the overall required steprate, although I didn't necessarily expect it to have a measurable effect. That it does points towards possible issues with the step pulse generation while IS munges the path for IS purposes.

[NeoDue]

@oliof thanks a lot for explaining! It was logical to me that 16x reduces the amount of steps RRF has to calculate vs. 64x, but I did not get what that might mean in respect to the current issue.

[dc42]

@NeoDue thanks for your results. Please can you share the print file that gave those layer shifts, or if you have already shared it then point me to that post. I'll see if I can reproduce it on a bench system using your files. Also please share your daemon.g file if you have one.

[NeoDue]

@dc42 the print file is still the same as shared in post #1 - I continue using it to keep the results comparable.

I will upload my daemon.g as soon as I am back home from the office!

[jay_s_uk]

@NeoDue probably a full zip file of your system folder would be best, then we can make sure theres nothing else odd going on

[NeoDue]

@jay_s_uk @dc42 here is my zipped settings folder (again, with an added ".gcode" extension to be able to upload it - if I could ask for an enhancement here in the forum, it would be to allow ".zip" as upload extension...) - please do not hesitate to let me know if you need explanations or need me to translate anything!

settings_NeoDue_J1.zip.gcode

[dc42]

@NeoDue thanks. I've mostly replicated your configuration on the bench and run your print file. The diagnostics are showing some step timing anomalies which I will investigate, but they are on the extruder drive (rather than on an axis drive, which is what I was expecting to see). Do you see any blobs on the print, that might be large enough to cause the layer shifts?

[NeoDue]

@dc42 Wow, I did not expect you to work that late! Please call it a day, I do not want to be responsible for stealing your night's rest!

But to answer your question: as safe as I can be from just sitting in front of the printer, looking and listening, there are no blobs of a size that might cause a layer shift (or rather to be precise I did not note any blobs worthy of the name at all). I know from my initial tests with my filament how loud the printer can get while it rumbles over a filament blob without getting stuck, and in addition to watching no blobs, I also do not see any.

What I did notice however is an increased rumbling noise indicating an certain unevenness of the previous layer between layer shifts at times, but that might also be caused by the lack of support caused by the layer shift.

Did you test the print more than once, and up to which height? As can be seen from my tests, the amount of layer shifts varies, therefore I guess it is something that "just about might happen" and therefore I assume it requires a little bit of bad luck to cause a visible effect.

[dc42]

@NeoDue I am not doing a real print, I am running a bench system. I've run it up to more than 4mm height and so far I have only seen anomalies in the extruder step pulse timing. These anomalies go away if I set pressure advance to zero.

Can you please re-run part of that print with pressure advance set to zero, so that I can determine whether this anomaly is indirectly causing layer shifts or is irrelevant to this issue.

[NeoDue]

@dc42 okay, I hope I can do the test print this evening when I am home. At latest, it will be tomorrow.

Please try to test up to somewhere above 5.65mm though - the layer shift and bang that occurred at that height was by far the most reliable one.

[NeoDue]

@dc42 I got home early enough and just did the test print. However it works, commenting out M572 seems to cure the layers shifts that arised due to switching to Spreadcycle, so I guess your finding is indeed part of the solution even if I still could not spot any blobs.

[dc42]

@NeoDue thanks, that's very useful to know. When I have a fix for that interaction between PA and IS, I'll ask you to run the print again.

[NeoDue]

@dc42 thanks a lot! Let's see if that layer shift at 5.5..5.65 mm will disappear then as well - that was the only one that still persisted when I just tested. I did see however this time that it was caused when the second hotend was running, so I will investigate that further after you did your magic

[gloomyandy]

@NeoDue Did you disable any pressure advance on the 2nd hot end?

[NeoDue]

@gloomyandy yes, my config.g has just one M572 command for both hotends and I commented that one out.

[oliof]

I did a bit of testing myself to see whether I can reproduce and maybe find some counter measures.

TL;DR: IS makes your machine angry, give it some oomph

I did my testing on a Ratrig V-Minion, a machine that is known for high speed capacity in its stock configuration. My changes: LDO2504 stepper motors on X and Y, and a Fly Super5 H723 board with Fly 2209 steppers.

I originally ran the motors at 1.4A each, and with those I got heavy layershifting with IS and none without running at 5k accel and 900mm/min jerk on a Squircle vase mode test print. I got repeated layer shifts at the same layer heights (0.3mm and 8ish mm), so it was pretty clearly the issue @NeoDue saw.

Then I remembered I checked with Jason from LDO the other week, and the rating on the LDO motors is in RMS, not Peak. So 1400 PEAK is 1000RMS (give or take), or just 40% of the motor performance. I gave the test print a go at 1700 PEAK and the higher layer shift went away completely and the lower layer shift was much less pronounced. At 2000 PEAK the lower shift was almost invisible.

Now, this is with a test print that is pretty benign since except for the concentric infill on the bottom layers it has no sharp corners. But if you have some current you can add to your motors do so. Note that you need to add active cooling at these higher currents.

Next test will be running with 5160s from a 3HC expansion board to see if running the motors at 2.5A PEAK resolves this issue fully or not.

[NeoDue]

@oliof thanks for that information!

I had tried running my steppers at max current but that did not help at least for the layer shifts @dc42 is working on at the moment. As soon as I get some firmware to test I surely will check if increasing the motor current again might help with the last layer shift.

What I also take from all this testing so far is that StealthChop seems to be more resistant against causing layer shifts with IS than SpreadCycle, at least in some cases.

[oliof]

@NeoDue I don't understand? I thought a) stealthchop switches to spreadcycle at speeds where IS is relevant, and b) has less torque than spreadcycle to boot.

[NeoDue]

@oliof First of all, as I have set it in my printer - unless I do the tests here for this issue - , I use Stealthchop (less noisy) but simply do not let the printer switch between modes. See here for the reason: https://forum.duet3d.com/topic/33756/rrf-3-5-0-rc1-shaking-rattling-in-stealthchop/2?_=1707412028143 . In a nutshell: Either use Spreadcycle or use Stealthchop, but do not let the controller switch.

That being said, I also had thought that StealthChop reduces torque. But as you can see from the tests above, I get much more layer shifts if I use Spreadcycle for the x and y steppers than I get using Stealthchop. This and @dc42's claim from his recent bench test that he sees only extruder faults that I assume can only cause layer shifts by causing blobs leads me to the conclusion that for some reason Stealthchop is less affected by such blobs. And this means for some reason Stealthchop must create more torque to overcome these... ¯\_(ツ)_/¯

Edit: this works fine at least for the speeds and accelerations my printer can handle - if it would work for yours however is another thing