Renaming Fans & Outputs / Thermals items

[yw4z]

Is your feature request related to a problem? Please describe

Hi, first thanks for all efforts on fluid. its very handy
Im using a rooted K1 with Guilouz guide. and i tried to rename fan0 and other other pins with config file but i loose many features like controls not in sync with touch screen and also i started to get errors while printing. problem is fan0 etc is hardcoded to firmware and cannot edit them

Describe the solution you'd like

simply giving custom names to outputs and thermal items will be easier to read
here is my current status

and here is edited version but i have many problems with this changes

Also "Round numbers in values" option will be nice to have

Describe alternatives you've considered

Using an input box for item names can be solution

Additional information

No response

[pedrolamas]

Hi @yw4z thank you for posting this Feature Request.

Can I ask that you upload your klipper.log please? It will include the full printer config and allow us to check it and test some of it on our side.

That will also allow us to pinpoint what control is having the rounding issue and fix that.

Regarding the renaming of the entities, we will probably wait for someone to contribute such a feature as I don't believe it is such a priority at the moment and our dev team is already quite small.

[yw4z]

Hi
i added 2 logs one with custom names and other one is stock names for fans
if you cant find issue i can send older ones too
klippy.zip

macros could be different on both files still experimenting on macros

[pedrolamas]

@yw4z any specific reason why you are using an [output_pin side_fan] instead of [generic_fan side_fan] ?

[yw4z]

actually its hardcoded to firmware as [output_pin fan2] and fan control from touch UI will not work if i use [output_pin side_fan] . so i started to use [output_pin fan2] again. thats why im asking for a renaming feature. I guess creality used fan2 in other parts in code and probably they used as [output_pin fan2]
thanks for your efforts

[pedrolamas]

I am indeed seeing what you mean on the conversion script stock config files, however one can't say it is "hard coded" when it is all just easily changeable text files! 🙂

I have found the rounding problem and will correct that, but adding some sort of alias to this will have to go on the backlog for now.

[pedrolamas]

For the record, I have now reported here what I believe to be the incorrect usage of [output_pin] instead of [fan_generic] on the stock config files

[yw4z]

i changed fan2 to side_fan in all gcodes but it was used on other places. and tracking these changes on every firmware release could be difficult for guilouz and i appricate their work

glad to see you catch one more bug :)

i guess using [output_pin] is Creality's idea instead of [generic_fan]. not related with guilouz's script

on this fork you can see [generic_fan] usage
https://github.com/alexander-cato/k1-config/blob/main/Config/fans.cfg

but again it will not compatible with touch screen UI

[sigmashig]

@yw4z How you configure LED as a switch control? I have LED as a slider disregard of states ON/OFF.

[yw4z]

@sigmashig
deleted 2 lines from it. "pwm: True" "cycle_time: 0.010" these lines causing it showing as slider. end result should be like this for creality K1

[output_pin LED]
pin: PB0
value: 1

[pedrolamas]

For the record, I have now reported here what I believe to be the incorrect usage of [output_pin] instead of [fan_generic] on the stock config files

I received a reply to the issue I opened, however, the repository admin disabled the GH Issues, so the link does not work anymore!

This is the reply I received:

Not an issue and not related to the wiki.

Creality has decided to use [output_pin] function rather than [fan_generic], it's a different approach but it works just as well.

Changing the name or function would break commands included in screen binaries whose sources are not available.

So we can't do anything about it.

My personal view from this is that Creality has once again taken a different approach as to how Klipper is supposed to be used.

Personally, I have zero inclination to support Creality work as they have proven multiple times that they have no problems with taking open-source code (eg. Klipper, Moonraker, Fluidd, Mainsail, KlipperScreen), changing it, and then using it on their printers without releasing said changes (thus breaking the open-source licenses).

[yw4z]

maybe sending an issue / bug on their repo is better but i'm sure they will ignore it because it "works"