3.5.0rc1: Input shaping causes layer shifts!?

NeoDue

@oliof Sure, will do!

But I am also curious what @dc42 might have changed between rc2+ and rc3+. If anything, whatever has been done seems to have increased the issue rather than made it better, at least as this one print so far can tell me. In all the previous tests here, I never had a (small, but nevertheless there) Y shift combined with an X shift, and also the amount of layer shifts seems to have increased.

Apart from that I still wonder what it might be that just us few users have this issue. What is there that makes our setup different? Is it the combination of higher-than-average speed on a non-CoreXY with a 6HC? Is it the new 6HC Wifi module (I should have one if the very first batch that was shipped) combined with a PanelDue? Is it some obscure crosstalk caused by the temperature sensors using preamplifiers (connection done as suggested by dc42 here)?
If you think freely and happen to find anything hardware or settings-related that has even a remote chance of causing such an issue, please let me know and I will test it. The only thing I cannot do much about for now is the steppers. Especially the y stepper is quite custom.

gloomyandy

@NeoDue Your setup is rather different to most other people so it could be something to do with that. You could try disabling the Panel Due and perhaps the two filament sensors to see if that makes any difference. I suppose you could also disable the WiFi module (using M552 s0) after you have started the print. That should all be possible without making any changes to your hardware and might provide some extra data points.

What is special about your Y stepper or any of the steppers in your configuration?

NeoDue

@gloomyandy thanks! Then I will do two prints now:

the print @oliof asked for with 16x microstepping for the extruders
and while that prints, I will search for a LAN cable that is long enough and then do a second print with PanelDue, Wifi module and both filament sensors disconnected - physically and in the config to be really sure.

Let's see what that might do.

The stepper is different since it has a very long customised shaft on both ends. Just a mechanical annoyance and nothing that could not be solved with a good saw and some hours at the lathe, but it makes inserting another stepper a one-way-only task that takes a bit longer

gloomyandy

@NeoDue If you are going to change the extruder microstepping you may need to adjust the steps/mm. At the moment you have that set with:

M92 X80 U80 Y80 Z1600 E138.58:138.58 S16

The S16 is telling RRF to assume that 16 microsteps are being used when calculating things. I'm not sure how that will have been interacting with the

M350 E64:64 Z16 I0

you have been using. It may all be fine, but just be aware!

NeoDue

@gloomyandy that should work fine - S16 tells the duet only that the steps/mm are calculated for 16 Microsteps - see here. I was quite happy when this feature was introduced since I was fiddling with my old "Duet-ised" GRR Neo back then and constantly had to switch microstepping settings between 16 and 256 while testing.

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.

Solved 3.5.0rc1: Input shaping causes layer shifts!?