Input Shaping On / Off Switch

dc42

@ccs86 I think disabling input shaping during non-solid infill is a good idea. I'd need to introduce another parameter to M593 to allow IS to be enabled/disabled without affecting the parameters.

Alternatively, some slicers label what they are doing with comments. RRF could parse those comments and enable/disable IS automatically. For PrusaSlicer I think it would be appropriate to disable IS only on sections labelled "TYPE:Internal infill" and to all travel moves.

CCS86

@dc42 said in Input Shaping On / Off Switch:

@ccs86 I think disabling input shaping during non-solid infill is a good idea. I'd need to introduce another parameter to M593 to allow IS to be enabled/disabled without affecting the parameters.

Alternatively, some slicers label what they are doing with comments. RRF could parse those comments and enable/disable IS automatically. For PrusaSlicer I think it would be appropriate to disable IS only on sections labelled "TYPE:Internal infill" and to all travel moves.

Awesome, I'm glad to hear you see some validity in this request!

Automatic on/off would be very slick.

I think leaving it off for solid infill could be useful as well. It could help prevent over-extrusion during the reversal between passes.

Travel moves are more tricky because you travel to and between perimeters, where IS would be very helpful in improving surface finish.

dc42

@ccs86 I meant to say that IS should be enabled on all travel moves. This is because Prusa Slicer appears to label a section after the travel move that precedes it.

CCS86

@dc42 said in Input Shaping On / Off Switch:

@ccs86 I meant to say that IS should be enabled on all travel moves. This is because Prusa Slicer appears to label a section after the travel move that precedes it.

Which is a shame, because there is likely a bunch of time to gain with IS disabled during infill travel.

Prusa Slicer devs may be open to moving the label to before that initial travel move, if there is a nice functional reason like this.

gloomyandy

@ccs86 Since to get this to work I assume you will need to increase the acceleration used when doing the infill (and reduce it for perimeters), what happens if you just do that? I know that IS may not work as well with higher accelerations but does it actually slow things down or cause other problems?

CCS86

@gloomyandy said in Input Shaping On / Off Switch:

@ccs86 Since to get this to work I assume you will need to increase the acceleration used when doing the infill (and reduce it for perimeters), what happens if you just do that? I know that IS may not work as well with higher accelerations but does it actually slow things down or cause other problems?

I think the issue with that logic is that setting higher accelerations with IS on and cancelling a frequency around 50Hz, is that effective acceleration is capped and doesn't increase.

@dc42 can speak more precisely about that.

gloomyandy

@ccs86 That's interesting. What sort of caps have you seen to acceleration when using IS? I've not noticed any in my own tests. But perhaps you are running much higher rates.

CCS86

@gloomyandy said in Input Shaping On / Off Switch:

@ccs86 That's interesting. What sort of caps have you seen to acceleration when using IS? I've not noticed any in my own tests. But perhaps you are running much higher rates.

That is how IS functions, by intelligently limiting acceleration. The lower the frequency you specify, the more aggressive this is.

Try making a print with and without IS on and see the difference in total print time.

o_lampe

@CCS86
Interesting thread.
Isn't IS only avoiding acceleration around the resonance frequence, but can accelerate faster than that?
IMHO it should work smoothly above resonance frequency until you hit double/quad frequency again.

dc42

@o_lampe said in Input Shaping On / Off Switch:

@CCS86
Interesting thread.
Isn't IS only avoiding acceleration around the resonance frequence, but can accelerate faster than that?
IMHO it should work smoothly above resonance frequency until you hit double/quad frequency again.

No. Any change in acceleration will excite resonances. IS breaks the acceleration phase up into multiple phases with different accelerations so that the multiple changes in acceleration excite the resonances in ways that cancel out.

dc42

@CCS86 said in Input Shaping On / Off Switch:

Well, for infill, I can't think of why I would want input shaping on.

Indeed, I can see that you might want to turn IS off during infill. However, when it finishes the infill and switches to perimeters, the last infill move (or the last several infill moves if they are short) will excite resonances that will affect that perimeter. So you would need to re-enable IS for the last few infill moves. If you can produce a slicer that can do that, I will gladly add an input shaping on/off command.

CCS86

@dc42 said in Input Shaping On / Off Switch:

@CCS86 said in Input Shaping On / Off Switch:

Well, for infill, I can't think of why I would want input shaping on.

Indeed, I can see that you might want to turn IS off during infill. However, when it finishes the infill and switches to perimeters, the last infill move (or the last several infill moves if they are short) will excite resonances that will affect that perimeter. So you would need to re-enable IS for the last few infill moves. If you can produce a slicer that can do that, I will gladly add an input shaping on/off command.

That is a good point!

What if... instead of an on/off switch, IS could have a "perimeters only" flag that would parse extrusion roles in the read-ahead buffer:

;TYPE:External perimeter
;TYPE:Internal perimeter
;TYPE:Internal infill

and intelligently utilize IS when needed?

dc42

@CCS86 yes I thought of that too. Same problem: we would need to turn on IS a few moves before the perimeter starts. That may be possible if we use the second file reader in RRF3.5 to read a few lines ahead.

o_lampe

@dc42 For those users, who print infill with a second extruder, it would be cool to define a tsoon.g macro.
The second gcode reader would set a flag in OM when a toolchange is ahead.
tsoon.g would then be triggered and could restart IS and the perimeter hotend.

That would also work for all users with only one extruder: they just have to setup their printer and slicer "as if" they had a second extruder.

//edit. Maybe call it tahead.g to make it's usecase clearer

CCS86

@dc42 said in Input Shaping On / Off Switch:

@CCS86 yes I thought of that too. Same problem: we would need to turn on IS a few moves before the perimeter starts. That may be possible if we use the second file reader in RRF3.5 to read a few lines ahead.

Yes. Ideal (if practical to implement) would be to look at the "distance to perimeter" as a trigger to enable IS, with this distance adjustable via IS definition call.