3.5.0rc1: Input shaping causes layer shifts!?

[gloomyandy]

@NeoDue said in 3.5.0rc1: Input shaping causes layer shifts!?:

dit: Just a correction in case someone stumbles over this sometime later: according to https://docs.duet3d.com/en/User_manual/Connecting_hardware/Motors_tuning the M915 T parameter defines TCOOLTHRS, not COOLCONF where the text above belongs.

I think you are correct.

@droftarts I think the documentation may need to change. The gcode dictionary for M915:

Tnnn (optional) Coolstep control register, 16-bit unsigned integer

Does not seem to be correct and likewise the following:

coolStep is configured using the T parameter of M915. This sets the coolStep control register, with a 16-bit unsigned integer. See the stepper driver documentation for sensible values. As coolStep needs to use the motor loads to dynamically adjust the motor current, stallGuard needs to be set up and tuned first. See Stall Detection and Sensorless Homing.

in https://docs.duet3d.com/en/User_manual/Connecting_hardware/Motors_tuning#configuring-coolstep seems wrong to me.

As to what setting M915 T actually does this is my take on it...

Because by default coolstep is disabled by RRF ( the coolstep control register is set to zero as I posted earlier) I think in this case the only impact TCOOLTHRS will have is on stall detection so this part of the 5160 datasheet applies:

TCOOLTHRS ≥ TSTEP
- Stop on stall is enabled, if configured
- Stall output signal (DIAG0/1) is enabled, if configured

However I'm not totally sure what values of TCOOLTHRS actually make sense to use because from the datasheet TSTEP is defined as:

Microstep velocity time reference t for velocities: TSTEP = fCLK / fSTEP

So it is not a simple value to select.

[gloomyandy]

@NeoDue said in 3.5.0rc1: Input shaping causes layer shifts!?:

@oliof @gloomyandy I was lucky and just had the chance to redo the test with increased currents - this time really shifted to the maximum (again no other parameters set, Spreadcycle and Input shaping active).

Result: again layer shifts, starting around 2.5mm. I stopped the print at about 4mm.

So just to take a step back with spreadcycle enabled and a higher current setting you are now getting a layer shift at 2.5mm? But previously you did not get a shift there, it was higher in the print, is that correct?

Can you also confirm that the gcode file in the very first post of this thread is the one you are currently using for the tests? If so I'll try and take a closer look at it.

[NeoDue]

@gloomyandy first of all (a little offtopic), thanks for forwarding that M915 topic to droftarts! I am actually quite curious what that value means - and how to use it. Maybe an example in the documentation would help there... I suspected you might need to convert the binary or hex value that you can get from the datasheet to a decimal value - but I could not find any confirmation about this, not even here in the forum.

But back to topic: the layer shift is almost exactly in the same area as it was with the original current settings and Spreadcycle enabled. Thus, with this new finding, I suspect that it is the same as noted initially with the tests with RC2 and StealthChop - layer shifts happen, but not in 100% of the cases. Thus, I deem the layer shift not happening at that lower height with the currents slightly risen just a lucky coincidence.

To sum up the results so far as I see them (anything you might read from the M122 reports above not included):

• Stealthchop and Input shaping enabled gives a "bang" and a significant mechanical impulse in y direction at 5.5...5.65mm height, sometimes resulting in a y axis layer shift. The gcode shows quite increased short motions there.
• Spreadcycle and Input shaping results often (but not always) in x layer shifts starting at about 2.5mm - without any obvious reason from the gcode. As might be expected, x axis layer shifts of one hotend do not affect the second one, therefore a miscalculation somewhere can be excluded. Until now, every part printed with that setup up that height showed a y layer shift at 5.5...5.65mm. Higher currents do not seem to reliably change this.
• as soon as Input shaping is deactivated, the part is printed fine, both with StealthChop and Spreadcycle.

The test part I print is indeed the gcode file attached to the first post. y direction is along the longer side of the part, x direction is along the shorter side. (edit: I might need to slightly change the temperatures specified in there soon however since the original filament rolls I used for that file are getting empty now...)

(2nd edit: remark about x layer shift not affecting 2nd hotend added, impulse accompanying bang added)

[dc42]

@NeoDue thanks for your report. Do you still get a bang at the point of the layer shift when running in spreadcycle mode?

[NeoDue]

@dc42 Yes, I still get that sound with Spreadcycle (edit) and Input shaping enabled (/edit) (noted above in the post about the first test with Spreadcycle) but I indeed forgot to mention that in the summary. It seems in relation to the printing noise more silent though. (On the other hand, the printer is quite noisy with Spreadcycle so that might the cause for the observation)

[dc42]

@NeoDue thanks, a bang that isn't related to stealthchop could mean that something is wrong with the step pulse train. However, your M122 reports all show the maximum late steps as 1, so it's not caused by steps being scheduled for times after the move is supposed to finish.

[gloomyandy]

@NeoDue Just to confirm, when you get the layer shift at 2.5mm in spreadcycle, do you hear a bang then or is that only at the layer shift at 5.5mm?

I had a look at the gcode and I could not see anything that was out of the ordinary around the 2.5mm layer height. Could you provide some information about your printer and the print? It looks like it may be an idex of some sort? With your test print I think you use both tools, but looking at the gcode it looks like the first layer shift at 2.5mm happens before the second tool is used, is that correct?

[gloomyandy]

@NeoDue Also what input shaper settings are you currently using when running this test?

[dc42]

@NeoDue I've tried printing your file twice on my E3D toolchanger and didn't get any layer shifts or hear any bangs up to 6mm height, which is where I stopped it. However the adhesion between the top part and the bed wasn't sufficient so that part broke away. I saw it curling up a little before it broke away.

I wasn't using the same config.g settings as you are, so I'll try again with those settings. Please provide your up to date config.g file including the input shaping setting you are using.

[NeoDue]

@gloomyandy Sorry! I forget that you have a lot of communications here and therefore probably do not remember previous discussions

The printer is a Snapmaker J1 (an IDEX printer indeed) where I replaced the original Marlin controller with the Duet. Apart from that, it is mostly as delivered from the factory - exceptions are parts of the hotends and the filament sensors, all not relevant in our case.
The steppers are from a company called Mocotech. You cannot find much about those since they do not seem to sell them separately, but I managed to dig out a datasheet for the y stepper:

Looks pretty standard to me...

The print is a battery box that was sliced in Prusaslicer. Black is printed with hotend 1, green with hotend 2. I did not choose this part deliberately, it simply was the first part I printed after activating Input shaping.

I have tested both of the two Input shaping settings noted in my config.pro, both behave identical in terms of the issue. The bang only happens at the 5.5...5.65mm y axis layer shift, but due to the construction of the printer (classic cartesian XY head printer, just a second printhead added), Y has a signifcantly higher mass which ends up in a much higher impulse than such an effect would have if it occurred on the X axis.

[NeoDue]

@dc42 did you use the config.pro from the post https://forum.duet3d.com/post/332000 ?

Both M593 Input shaping commands are included there and one is active. (There are two since the results from the plugin suggest these two produce identical results and I want to choose the one that creates better results in reality).

[NeoDue]

@dc42 said in 3.5.0rc1: Input shaping causes layer shifts!?:

thanks, a bang that isn't related to stealthchop could mean that something is wrong with the step pulse train. However, your M122 reports all show the maximum late steps as 1, so it's not caused by steps being scheduled for times after the move is supposed to finish.

@dc42 thanks for that information. If I translate "step pulse train" correctly, something like this is what I would suspect, judging from what I see. Are there any thinkable cases where such a delayed step might happen without showing up in M122?

I also have an oscilloscope here which is however limited to 10MHz / 1MHz for single shots due to its age (it is an old Tek222). If it helps, I could try to measure something - stepper currents or such, but I am afraid my rusty electronics knowledge needs advice on what might be appropriate or what might be harmful (well, apart from the obvious risk of creating a short circuit... maybe some effects of the capacity of the probe or such ...?

[NeoDue]

@gloomyandy just an update on the M915 T topic: the current rc3 changelog makes it clear: "[Duet 3 MB6HC] [Duet 3 EXP3HC] [Duet 3 EXP1HCL] If you were using the T parameter of the M915 command, this value was incorrectly being written to the stall sensitivity register in previous releases. It is now written to the correct register (COOLCONF)."

This means your initial thought was right after all and the documentation at https://docs.duet3d.com/en/User_manual/Connecting_hardware/Motors_tuning#configuring-coolstep is wrong

[gloomyandy]

@NeoDue Yes we had a discussion about this offline @droftarts I think this section (which mentions using M915 T) may need reviewing: https://docs.duet3d.com/en/User_manual/Connecting_hardware/Motors_tuning#stealthchop-tuning

@NeoDue I thinik that this section is now correct: https://docs.duet3d.com/en/User_manual/Connecting_hardware/Motors_tuning#configuring-coolstep

[droftarts]

@gloomyandy Sorry, haven't had a chance to update it yet!

Ian

[NeoDue]

@droftarts May I ask you to move the latest posts regarding M915 in this thread to the thread I just created? https://forum.duet3d.com/topic/34802/how-to-use-m915-t-parameter

That might help others to find that information more easily.

[dc42]

All, if you have been getting layer shifts associated with enabling input shaping when using 3.5 beta and RC versions, please try the binaries at https://www.dropbox.com/scl/fo/p0136wx04h8xf6ejwdnn9/h?rlkey=efrfwyb6o5tqid11gustz3uvy&dl=0. I found and fixed a possible cause of these, but as I can't reproduce the problem I don't know whether the issue is fixed or not.

[NeoDue]

@dc42 thanks a lot for your detective work! I will upgrade and test this weekend!

[adrian]

@dc42 I think I’m suffering from the same issue. This new version didn’t fix my layer shift issue.

[dc42]

@adrian please provide a M122 report taken after the layer shifts occur. Note, if you run M122 more than once, then only the first M122 report after the layer shifts contains the data that I am interested in.