Status LED and barf ignoring index entries for nozzle leds and logo

[EricZimmerman]

Klippain branch

• [X] I confirm using the main branch

Version

latest

Describe the bug and expected behavior

with this set in /status_leds_effects.cfg

[gcode_macro _USER_VARIABLES]
variable_status_leds_enabled: True
variable_status_leds_effects_enabled: True
variable_status_leds_logo_led_name: "status_leds"
variable_status_leds_logo_idx: '1'
variable_status_leds_nozzle_led_name: "status_leds"
variable_status_leds_nozzle_idx: '2,3'
gcode:

the entries below do not take into account of these variables, and assume standard SB led order:

#########################################################
# Define led effects for the different printer states
#########################################################
## Ready State
[led_effect sb_logo_standby]
leds:
    neopixel:status_leds (1)
autostart:              false
frame_rate:             24
layers:
    breathing  20 1 top (0.0, 0.0, 1.0)

[led_effect sb_nozzle_standby]
leds:
    neopixel:status_leds (2,3)
autostart:              false
frame_rate:             24
layers:
        breathing  20 1 top (0.0, 0.0, 1.0)
        
        ```
 IF you use SB, this will be fine, but for XOL. the order on the chain is different:
 

Neopixel leds used on the toolhead (stealthburner style)

[gcode_macro _USER_VARIABLES] variable_status_leds_enabled: True variable_status_leds_effects_enabled: True variable_status_leds_logo_idx: '2' variable_status_leds_nozzle_idx: '1,3' gcode:

which results in the left nozzle led and logo acting as nozzle led and the right nozzle led acting as the logo.

this in turn while printing, shows white for the left and logo, and a rotating color pattern for the right nozzle led.



the expected behavior is that the LED effects account for the appropriate chain positions. I think this affects every led_effect entry in klippain

### Additional information and klippy.log


https://github.com/Frix-x/klippain/blob/main/config/hardware/lights/status_leds_effects.cfg
https://github.com/Frix-x/klippain/blob/main/config/hardware/lights/status_leds_rainbow_barf_effects.cfg

[gcode_macro _USER_VARIABLES] variable_status_leds_enabled: True variable_status_leds_effects_enabled: True variable_status_leds_logo_led_name: "status_leds" variable_status_leds_logo_idx: '1' variable_status_leds_nozzle_led_name: "status_leds" variable_status_leds_nozzle_idx: '2,3' gcode:

Also include directly the leds control macros from here

[include ../../../macros/hardware_functions/status_leds.cfg] [include config_colors.cfg]

[neopixel status_leds] pin: STATUS_NEOPIXEL

The pin connected to the neopixel. This parameter must be provided.

chain_count: 3

The number of Neopixel chips that are "daisy chained" to the

provided pin. The default is 1 (which indicates only a single

Neopixel is connected to the pin).

color_order: GRBW

Set the pixel order required by the LED hardware. Options are GRB,

RGB, GRBW, or RGBW. The default is GRB.

initial_RED: 0.0 initial_GREEN: 0.0 initial_BLUE: 0.0 initial_WHITE: 0.0

Sets the initial LED color of the Neopixel. Each value should be

between 0.0 and 1.0. The WHITE option is only available on RGBW

LEDs. The default for each color is 0.#

#########################################################

Define led effects for the different printer states

#########################################################

Ready State

[led_effect sb_logo_standby] leds: neopixel:status_leds (1) autostart: false frame_rate: 24 layers: breathing 20 1 top (0.0, 0.0, 1.0)

[led_effect sb_nozzle_standby] leds: neopixel:status_leds (2,3) autostart: false frame_rate: 24 layers: breathing 20 1 top (0.0, 0.0, 1.0)

    ```

[EricZimmerman]

https://github.com/Frix-x/klippain/assets/4265254/bcb1fe3f-c48d-484d-b1f0-4926146ff7ce

[EricZimmerman]

Does this look like a light issue or did I jack something up

[Surion79]

for me is the question how the settings of the at the top of the file have any effect on the states below. i don't see any interconnect

[EricZimmerman]

If you take the stealth burner logo order where one is the LED and two and three are the nozzles and override you should be able to see that the colors and everything else are completely crazy after that and not corresponding to the index positions

I'm with you. I don't see any relationship between the index positions and actually using said index positions in the LED effects definitions themselves

[Surion79]

it is strange tho that it goes crazy if you override it. so it has an effect?

[EricZimmerman]

I think the variables must be getting set somewhere but they aren't aligning with the order on the chain itself since the LED macros use 1 for logo all the time and 2,3 for nozzle LEDs

For me 2 is the logo so the right nozzle LEDs cycles color while the other 2 are white when printing.

When I rebuild xol I'll try to use sb order and see if things then look correct.

[Surion79]

OT: why use Xol? curious :)

[EricZimmerman]

Great cooling. Lighter. Flexible options for lots of extruders and hot ends.

It's awesome.

[Surion79]

well, i miss sensor options for ercf. that is my bind :/

[EricZimmerman]

ok, so this should work to fix this issue:

https://github.com/MapleLeafMakers/klipper-virtual_leds

It's virtual led chains that let you remap things

this would do the job.

[EricZimmerman]

ugh, this wont work as is because the same name is used for both, status_leds

variable_status_leds_logo_led_name: "status_leds"

variable_status_leds_nozzle_led_name: "status_leds"

if it was switched to nozzle_leds and logo_leds then virtual_leds would work perfectly i think, leaving the default name as

[neopixel status_leds]

so you could then override like:

[virtual_leds nozzle_leds] leds: neopixel:sb_leds (2,3)

[virtual_leds logo_leds] leds: neopixel:sb_leds (1)

[github-actions[bot]]

📌 This issue has been marked as stale because it has not had activity in the past 30 days. To keep it open, please respond to this message or add new information. Otherwise, this will be closed in 14 days. Thank you for your contributions!

[github-actions[bot]]

This issue was closed due to inactivity for 14 days. Feel free to reopen it if you think it was an error or if you have new information or progress to share