LED_effects and Rainbow barf support

[Frix-x]

No description provided.

[Frix-x]

Ok, now I'm ready.

I've made some changes to improve it a little bit. Main one is that almost no one is changing the default colors included in Klippain AFAIK. So I moved them outside of the variables.cfg file. This way, if we want to add new colors and states in the future, we will be able to do it without a breaking change.
If an user wants to change them he can still override the new _LEDS_COLORS_DEFINITION macro to define his own like for all the other Klippain features.

As the color definition macro has another name (not in _USER_VARIABLES), it's not a breaking change in this release, but the list in the current variables.cfg user file will not be used anymore and can be safely removed.

[Frix-x]

@claudioguareschi can you review if this align with your first PR and is ok for you now ?

[claudioguareschi]

Glad to look at it as I get out of work. I also made the changes you requested. Should I continue to target main with the PR or do you want me to target develop or rather this branch (leds-rework)?

[Benoitone]

Why turning on leds on startup?
They never stop cause printer is already in idle state and so they must be manualy turn off...

[EricZimmerman]

I don't mind this but it should be a variable I'd say I'm variables.cfg

[Benoitone]

Not a variable

[Benoitone]

point here so if status_leds_enabled, at startup, the lights turn on.

[Surion79]

I don't mind this but it should be a variable I'd say I'm variables.cfg

I second this. I prefer it to stay in variables.cfg.
Especially the users don't report suddenly changed colors due to a new merge/version. So in this case i'd rather have it stay like this.
Or we get issues that changes in the variables cfg is no longer working. I don't like putting that live and discussing about invisible no longer working features.
Please let it stay in variables.cfg

[EricZimmerman]

EnableLedsOnStartup: false

By default kind of thing

[claudioguareschi]

Ok... I am using a startup effect that turns on all the leds in a rotating gradient fashion. This effect starts automatically as soon as the config is read and lasts for the time it takes to initialize the printer. This is the effect:

Printer startup effect

[led_effect cl_startup]
leds:
neopixel:caselight
autostart: true
frame_rate: 24
layers:
gradient 0.3 1 add (1.0, 0.0, 0.0),(0.0, 1.0, 0.0),(0.0, 0.0, 1.0)

The duration of this effect is variable and depends on how fast of a raspberry pi you are using and on the complexity of your config.

It may be very short in some instances. On my setup (rpi4), no ercf, led and few sensors it lasts a second or 2.

This effect needs to be turned off or switched to something else once klippain is fully initialized and ready. This is the reason why the leds were turned on at the klippain ready message. Indeed we can set a variable and decide what to do, leds on or off.
The way I would like to do following a logical workflow, you turn on the printer, it goes quickly through the rainbow things and then turns on the LED. I am looking at hooking up to the idle timer to turn off or dim the led to almost nothing when the printer stays idle for a while.

I'd love to get feedback on this.

[EricZimmerman]

How about a variable names

Led_start_effect

Default is empty
If populated it uses that led effect

[claudioguareschi]

How about a variable names

Led_start_effect

Default is empty If populated it uses that led effect

Unfortunately the way the effects are implemented, is like MCU pins. They are read at the very beginning of the initialization process. The advantage of using an effect marked as autostart is that is run at the very beginning of the config process and it can be turned off once config processing is complete. This gives a little visual cue that something is happening. You know when you turn the printer on, linux scrolls its messages on the screen and then there are a few seconds with a black screen before klipperscreen starts? Thats the time when the effect is run. Unfortunately it cannot be turned on or off with a variable, but it can certainly be eliminated. It is a little silly thing that some people would love some not care for. I agree giving a choice would be ideal but it cannot be done the way led_effects is currently implemented. I am going to try to start an effect at the very beginning of _KLIPPAIN_STARTUP and turn it off at the end, so that I dont have to use athe autostart effect, but I believe the effect would last a very very short time.

[Surion79]

Would it be possible to run this startup with minimum intensity? So it is barely visible if the implementation requires it. Since led effect is alpha state and 10 months dormant, i highly doubt that it is actively worked on. The base on the led effect is from someone else. (He is named but no repo about it was found) so i doubt there will be base reimplementation of something like this

[claudioguareschi]

Would it be possible to run this startup with minimum intensity? So it is barely visible if the implementation requires it. Since led effect is alpha state and 10 months dormant, i highly doubt that it is actively worked on. The base on the led effect is from someone else. (He is named but no repo about it was found) so i doubt there will be base reimplementation of something like this

The startup rainbow effect is not a must and it can be completely eliminated if that is what you guys desire. Then we can certainly define a variable in variable.cfg to control initial led on or off in klippain_startup. We can use a variable to decide initial led on or off regardless of the initial rainbow startup effect. It is only this effect that cannot be controlled by a variable.

PS do you think led_effects is a dead project? I would like to use for this something actively developed, but I havent found anything else suitable. The library he mentions in his docs is fastled which is a well known library used to control addressable leds in arduinos/esp32 mcus.

[claudioguareschi]

Posted a PR with startup led state controlled by a variable. Is this what you guys were looking for?

[Frix-x]

I'm closing this since it was merged inderectly by the lastest big merge in develop :)
Thank you very much for the work!

If you think it's not perfect, as stated in #419 , please open a new PR against the develop branch to start fresh from the latest version :)

[Benoitone]

@claudioguareschi
Sorry for the inconvenience on my part on your PR... Which I seem to have stolen from you without meaning to...
On the other hand I encounter an error linked to the [include ../../../macros/hardware_functions/status_leds.cfg] For example the macros SET_NOZZLE_LEDS_ON, SET_NOZZLE_LEDS_OFF or SET_LOGO_LEDS_OFF do not work do you have some idea?
And again sorry for that :(

[claudioguareschi]

@claudioguareschi Sorry for the inconvenience on my part on your PR... Which I seem to have stolen from you without meaning to... On the other hand I encounter an error linked to the [include ../../../macros/hardware_functions/status_leds.cfg] For example the macros SET_NOZZLE_LEDS_ON, SET_NOZZLE_LEDS_OFF or SET_LOGO_LEDS_OFF do not work do you have some idea? And again sorry for that :(

Yeah… I realized I cannot change the led_name variable as it is the actual name of the led chain in config. Also when effects are running, it does override any changes made using the klipper SET_LEDS macro, so for example changing the case light color from klipperscreen it doesn’t work as expected. I have a fix for the set_nozlzle… macros but I want to fix set_leds as well then I will submit a new PR toward develop.

[Benoitone]

Maybe with same led_name as non "effects" macro and by adding a new variable to check in others macros for caselight and status, like for exemple 'variable_status_leds_type: "status_leds_effects"' and 'variable_status_leds_type: "status_leds"' for status leds hardware macro. Same for caselights hardware macros?

[claudioguareschi]

I'm closing this since it was merged inderectly by the lastest big merge in develop :) Thank you very much for the work!

If you think it's not perfect, as stated in #419 , please open a new PR against the develop branch to start fresh from the latest version :)

Will do. There are a few minor fixes that needs to be done, see my response to Benoitone.

There is one thing I wanted to discuss with you, if you are interested I can implement it:

It would be a good thing to have a state machine for the different printer state I.e. states would be idle, standby, cleaning_nozzle, purging, leveling, meshing, printing, done_printing, paused, etc where for each state I can set leds color or effects, fan speeds and other stuff that may be needed for that particular state/task. This would simplify to some extent the print_start macro as it would just set the printer state to whatever it is doing ie leveling, heating etc. and the state machine will take care to set the leds, fans, knomi and other minor nuisances. This would be a good approach to prevent the start_print macro to grow disproportionately, let it focus and concern only on the printing steps required to prepare the printer for printing and let the state machine set the nuisance details.

this is not difficult to implement and I would be glad to do it. It would be a somewhat big change to your implementation and I won’t do it if it is not something you are interested in.

If you are interested let me know and maybe make a new branch based on develop I can fork and pull back to.

[claudioguareschi]

Maybe with same led_name as non "effects" macro and by adding a new variable to check in others macros for caselight and status, like for exemple 'variable_status_leds_type: "status_leds_effects"' and 'variable_status_leds_type: "status_leds"' for status leds hardware macro. Same for caselights hardware macros?

I have done just that already. I may need to extend the kipper set_leds macro to turn off any effect enabled on a particular chain if a direct call to set leds comes in for example from kipper screen

[Surion79]

Please open up a new PR as Frix mentioned if you need to fix it. I think it is not the best idea to discuss errors/improvements in a closed pr,