3.5.0rc1: Input shaping causes layer shifts!?

NeoDue

@gloomyandy @dc42 here are the results - again, anything that is not explicitly mentioned is identical to the last config.g I posted above:

printing with 16x microsteps for the extruders as @oliof suggested actually seems to reduce the occurrence of layer shifts! I doublechecked this by doing a second - edit: and a third - print with 64x microstepping and ~~a second one~~ three with 16x microstepping, and the amount of layer shifts over the first 4.5mm is 2+1+0 with 16x microstepping versus 5+3+3 with 64x microstepping in these attempts. (x and y layer shifts counted separately here even if both happen in the same layer, otherwise the "5" would be a "4")
the other test (PanelDue disabled and unplugged, Wifi module disabled and unplugged, both filament sensors disabled in th config) did not yield a differing result however.

I will undo the hardware changes now and make a third and maybe a fourth comparison with 16x vs. 64x extruder microstepping to validate this.

(edit: added results of third comparison print)

oliof

@NeoDue next test idea I have: Enable interpolation on 16x microsteps for the Extruder.

NeoDue

@oliof okay, then this is next as soon as the current test print is done. I don't have even the faintest clue what you might be up to though

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.

Solved 3.5.0rc1: Input shaping causes layer shifts!?