Input Shaping On / Off Switch

Norder

Doesn't pressure advance have a different value when input shaping is disabled or enabled ?

You should determine the pressure-advance value again if you have activated input-shaping !?

So in that case you have to have two PA values and then add them to the IS On & Off commands.
, if you have activated PA.

Google Translate
----- Original Text -----

Hat Pressure-Advance nicht einen anderen Wert wenn das Input-Shaping deaktiviert bzw aktiviert ist ?

Man soll den Pressure-Advance Wert doch neu ermitteln wenn man Input-Shaping aktiviert hat !?

In dem Fall muss man also zwei PA Werte haben und diese dann zu den IS An & Aus Befehlen hinzufügen.
, falls man PA aktiviert hat.

dc42

@ccs86 said in Input Shaping On / Off Switch:

@dc42 said in Input Shaping On / Off Switch:

@ccs86 I suggest you create a couple of macros to turn IS off and on, then call those macros from the slicer-generated code.

Would the type and frequency the. Have to be managed in the macro? I'd really like to keep my settings managed in config.g

You can define the input shaping parameters in config.g using global variables and have the shaping-on macro refer to them.

Out of curiosity, when do you need to turn input shaping off?

CCS86

@dc42 said in Input Shaping On / Off Switch:

@ccs86 said in Input Shaping On / Off Switch:

@dc42 said in Input Shaping On / Off Switch:

@ccs86 I suggest you create a couple of macros to turn IS off and on, then call those macros from the slicer-generated code.

Would the type and frequency the. Have to be managed in the macro? I'd really like to keep my settings managed in config.g

You can define the input shaping parameters in config.g using global variables and have the shaping-on macro refer to them.

Out of curiosity, when do you need to turn input shaping off?

I'll look into that, thanks.

Well, for infill, I can't think of why I would want input shaping on. It creates a pretty large reduction in acceleration. This slows the print down and causes you to lean more heavily on PA to keep extrusion constant. It's a fine trade on perimeters, but for infill I don't see the benefit.

CCS86

@dc42

Something like this?

global IS_freq=37					   ; Input Shaping Frequency
global IS_type="MZV"					   ; Input Shaping Type
M593 P{global.IS_type} F{global.IS_freq}		   ; Input Shaping

CCS86

The other likely issue here is that with the current method of turning input shaping on and off, there is a perceptible pause when the commands are issued. Having this at the beginning and end of perimeters will likely worsen print quality.

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.