Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SuperSlicer setting Pressure Advance to 0 during toolchange unload #2934

Closed
moo00se opened this issue Jul 14, 2022 · 26 comments
Closed

SuperSlicer setting Pressure Advance to 0 during toolchange unload #2934

moo00se opened this issue Jul 14, 2022 · 26 comments
Labels
bug Something isn't working as intended fix is live in the last release Please download /build the last release and try to reproduce.

Comments

@moo00se
Copy link

moo00se commented Jul 14, 2022

What happened?

SuperSlicer setting Pressure Advance to 0 during toolchange unload.

This is what i am trying to accomplish.... https://klipper.discourse.group/t/x-in-1-out-non-mixing-extruder-config/2387

With these settings, SuperSlicer sets PA to 0 during unload.
image

When there is no wipe tower SuperSlicer does not set the PA to 0 and will change colors fine. I deactivated "ramming" and SS still set the PA to 0.
If change the flavor of firmware to Marlin from Klipper SS does not try to set the PA, but it triggers errors during printing to its not a viable alternative.

Project file & How to reproduce

cali_2-R.zip

Version

2.3 and 2.4 and the new new one

Operating system

windows 10

Printer model

ender 3 switchwire conversion

@supermerill
Copy link
Owner

supermerill commented Jul 15, 2022

Yes, for the toolchange unload for the wipe tower, it deactivate the pressure advance to avoid problem with the ramming procedure, as it can mess it up.
Recovering from it is not obvious, as it's not a setting. Did you try to re-apply it in the toolchange gcode macro ?

I can add a branch to only disable if the ramming is not empty.

@supermerill supermerill added working as intended unless you prove me wrong. problem fixed for the next version That means that you should be able to test it in the latest nightly build and removed working as intended unless you prove me wrong. labels Jul 15, 2022
@moo00se
Copy link
Author

moo00se commented Jul 18, 2022

Which is interesting that no one else has runs into this issue. My klipper doesn't know what to do when being told PA to 0. It just stops. Throws an error. While troubleshooting i disabled ramming and it still set PA to 0. I did try to reapply the tool change gcode and it still throws the error. If I delete each line by hand that says set PA to 0 the print does great. I have the PA set in each filament and SS applies it properly while creating the gcode. Just when klipper sees that set to PA to 0 it errors.

@supermerill
Copy link
Owner

My klipper doesn't know what to do when being told PA to 0. It just stops.

It's something specific to your config or klipper can't work anymore without pa?

@moo00se
Copy link
Author

moo00se commented Jul 19, 2022

I don't know where it would be in my config, i've looked and tried, what i think is everything but probably not lol. I'm going to try everything from scrath, last i tried my SS config was still there so i gotta figure out how to fully remove SS from my pc then start again.

@supermerill
Copy link
Owner

your configuration is in info-> show configuration folder

you can have a portable configuration directory if you create it next to your exe.

@moo00se
Copy link
Author

moo00se commented Jul 19, 2022

this is the error i am getting " unable to infer active extruder" and this is from klipper ...

"The Unable to infer active extruder stepper error occurs if a SET_PRESSURE_ADVANCE command is sent without an EXTRUDER parameter and Klipper can’t determine which stepper to apply the pressure settings to.

In Klipper, the pressure advance settings are applied to a stepper and not to a hotend. So, if you want to use pressure advance when “belted_extruder” is active it is necessary to issue a SET_PRESSURE_ADVANCE EXTRUDER=belted_extruder ... command.

So, it looks like you need to update the commands in your gcode file.

-Kevin"

@supermerill
Copy link
Owner

ok, will be in next nightly

@moo00se
Copy link
Author

moo00se commented Jul 26, 2022

Is this change something i can try?

@supermerill
Copy link
Owner

supermerill commented Jul 26, 2022

Yes, you can try it.
The nightly is in the actions menu.

@moo00se
Copy link
Author

moo00se commented Jul 28, 2022

Forgive my ignorance please, i dont know how to do that. lol

@supermerill
Copy link
Owner

np

@moo00se
Copy link
Author

moo00se commented Jul 29, 2022

Gave it a go, i dont know where it is getting the name for the extruder, but the output gcode, names the extruders (extruder0 & extruder1) i dont know what those names correlate with. Those are not the names that i named the extruders in printer settings.

@moo00se
Copy link
Author

moo00se commented Aug 4, 2022

got it going, i still couldn't find out how to rename the extruder, so i just did a gcode substitute. I'm curious as to why its not grabbing the name from the printer settings.

@supermerill
Copy link
Owner

I'm curious as to why its not grabbing the name from the printer settings.

Because I didn't think of it.

@supermerill supermerill added bug Something isn't working as intended and removed fixed for the next version That means that you should be able to test it in the latest nightly build problem labels Aug 5, 2022
@moo00se
Copy link
Author

moo00se commented Aug 5, 2022

Thank you so much for being on top of this!

@supermerill supermerill added the fixed for the next version That means that you should be able to test it in the latest nightly build label Aug 9, 2022
@supermerill
Copy link
Owner

now it uses the same algo as the default toolchange.
and i added a fix: you can now use {tool_name} in filament custom gcode, so you can add EXTRUDER={tool_name} to your SET_PRESSURE_ADVANCE

supermerill added a commit that referenced this issue Aug 10, 2022
Also, can now use {tool_name} and other filaments & extruder settings in filament start/end
#2934
@moo00se
Copy link
Author

moo00se commented Aug 10, 2022

works 100% as intended. good work!

supermerill added a commit that referenced this issue Aug 10, 2022
Also, can now use {tool_name} and other filaments & extruder settings in filament start/end
#2934
@zuch95701
Copy link

zuch95701 commented Aug 25, 2022

Good Morning SuperMerill,

Reading through this thread hoping it could solve my issue. Im having the opposite problem.
When the unload gcode comes up, Klipper is erroring out due to it not knowing what "extruder1,2,3 etc are".

; CP TOOLCHANGE UNLOAD
SET_PRESSURE_ADVANCE ADVANCE=0 EXTRUDER=extruder3

Klipper Error - The value 'extruder3' is not valid for EXTRUDER

I can fix it with replace gcode. Is there a more elegant solution? This is on a ERCF setup single extruder multi material.

Trying to use the extruder={tool_name} in the filament gcode causes it to blank out the extruder name since they all do not have a name per the ERCF setup instructions.

Several others are having the same issue #3073.

On SS version 2.5.59.0 build 2002-08-11 MacOS

@moo00se
Copy link
Author

moo00se commented Sep 6, 2022

@zuch95701 -- It is my understanding that while using the ERCF one would set it in a different manner. Looking over the ERCF GitHub (specifically this cfg file) you would want to put the "TOOL" number for each color, opposed to "extruder" number. I personally have not used the ERCF (YET :D) but i have looked into it while troubleshooting my issues.

@zuch95701
Copy link

That’s correct. The extruder name remains blank in ss, and we call T0,T1 etc for a filament swap. I’ve set up a post process to remove the extruder pressure advance call out during the unload.

@supermerill
Copy link
Owner

nothing to change in a hurry then?

@zuch95701
Copy link

I wouldn’t say it’s urgent, just an annoyance having to set up the gcode replacement since it’s repeated for each color, (extruder1,2,etc) six in my case. It might cause issues for people setting up mmu/ercf on klipper that aren’t as well versed in searching gcode. It may cause issues for prusa mmu profiles as well, but I don’t have one to test. It was not present in the older release, and I’m sure you have a lot on your plate as is. Thank you for developing SS.

@notching
Copy link

Also seeing "Klipper Error - The value 'extruderX' is not valid for EXTRUDER" with 2.4.58.4 and all later versions.
2.4.58.3 works fine.
IMHO would be really nice to see this one fixed rather than having to write a g-code parser to remove it.

@TravisWilder
Copy link

I have the same issue here
SET_PRESSURE_ADVANCE ADVANCE=0 EXTRUDER=extruder1
is causing The value 'extruder1' is not valid for EXTRUDER

SS 2.5.59 (Intel Mac)

@soulrazr
Copy link

I'm pretty new to this, why does Pressure Advance need to be disabled before ramming? I recently switched to SS from Prusa Slicer and before the switch I haven't noticed any issues with the toolchanges and ramming. I double checked the Gcode and it wasn't touching the pressure advance settings at all.
Also can someone explain if there's any easier way to fix this other than me learning how to write my own post processing script? As it is right now I am manually editing the Gcode to remove the lines causing the print to fail at every tool change.
SET_PRESSURE_ADVANCE ADVANCE=0 EXTRUDER=extruder1
!! The value 'extruder1' is not valid for EXTRUDER

@gordonlange
Copy link

ive been struggling with this, though it should share my experience.

pressure advance is turned off to avoid additional speed/control influence that goes beyond the limit of the microcontroller that is stepping the extruder. hence i have turned PA to 0 before unloading/loading, and turning it back to a PA=0.3(for example) after that.

the extruder1/extruderX values not being valid is a problem that you have to map your printer.cfg/associated.cfg files to address correctly. in my case i am running an X-in-1-out single heater multiple BMG bowden extruder cold ends. my extruder1 is configured as below. ender refers to a secondary-mcu named ender. my additional extruders are being managed by a secondary MCU.

[extruder_stepper extruder1]
extruder:
step_pin: ender:PB9
dir_pin: !ender:PC2
enable_pin: !ender:PC3
microsteps: 16
full_steps_per_rotation: 200
gear_ratio: 3:1
rotation_distance: 22.774

@supermerill supermerill added fix is live in the last release Please download /build the last release and try to reproduce. and removed fixed for the next version That means that you should be able to test it in the latest nightly build labels Dec 29, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working as intended fix is live in the last release Please download /build the last release and try to reproduce.
Projects
None yet
Development

No branches or pull requests

7 participants