Turn off Neopixel LEDs on power-down?

General Discussion
1

Basic Information:

Printer Model: VzBot235
MCU / Printerboard: Arduino Nano
No log since there’s nothing to log

My current setup is this:

  • Raspberry Pi 3B on a seperate 5V supply
  • Relay switching 220V to the rest of the printer (mainboard, 24V power supply, bed power) via Raspberry GPIO
  • BTT Mini12864 display connected to an Arduino Nano running Klipper, connected to the Pi’s USB port.

The problem is that the Neopixel backlight/button light remains on/in it’s last state when the printer is shut off, since it gets powered by the Raspberry’s USB port. This is pretty annoying at night especially.

Is there any way, via macro, through moonraker or some addon, to tell Klipper to set the Neopixel LEDs to 0.0/off when either an error occurs (such as the loss of the main MCU due to power down), or when the power button in Fluidd is pressed?

Using the gcode_macro klipper device in Moonraker doesn’t allow me to turn on the printer when there’s no connection to the MCU.

2

You know the klippy.log is more than just a log?

1 Like
3

Yes.
What good does a log do with a printer that isn’t set up for anything at all that I am asking about?

Anyways:
klippy(1).log (177.2 KB)

4

Because the klippy.log includes the printer.cfg and so your neopixel settings.

1 Like
5

You can easily turn off your button’s neopixel to off

[gcode_macro LIGHTSOUT]
gcode:
  SET_LED LED=display_status RED=0 GREEN=0 BLUE=0 WHITE=0

or just include the SET_LED line in your SHUTDOWN macro

The display screen is currently a bit more tricky because although it is theoreticaly possible, klipper does not currently allow you to set the display contrast on the fly.
What we need is an equivalent to SET_FAN_SPEED such as
SET_DISPLAY_CONTRAST DISPLAY=display CONTRAST=0
This may not work on all displays but I believe for most rp2040 based designs, the contrast parameter is actually a merge of brightness and contrast bits so setting to 0, is zero brightness as well as contrast. If you feel this is useful you could put in a feature request.

Having said all that, for now, you can simply switch off the USB port.
Firstly you will need uhubctl. This allows you to turn the Pi’s internal USB hub off/on
You may already have this if your printer cfg includes

[mcu]
restart_method: rpi_usb

Then you will need the gcode_command_shell addon.
Once you have both of these you can call uhubctrl directly from a macro such as SHUTDOWN

[gcode_command_shell KILL_USB]
command: uhubctl -l 1-1 -p 2 -a 2

The parameters above are just an example so you may need to change them.

Before it will run though, you will also need to set Linux USB permissions as per the ubhubctl ReadMe, otherwise you will need to run as sudo.

6

The problem is, I specifically don’t want to run a shutdown macro. Cause if I do that, I have to run the macro off a seperate button and can’t use the convenient power button in the top right in Fluidd (and presumably Mainsail).
However, you gave me the idea to run this on the host OS itself, by detecting the drop of the mainboard’s USB and turning off the USB port’s power… I’ll have to dig into that.
Thanks.

7

Glad to be of service.

8

Nope… no good… ubhubctl doesn’t just disable power, but the actual port, so once it was killed, it can’t be restarted by an “add” rule.

9

That’s strange. It works on mine

sudo uhubctl -l 1-1 -p 2 -a 0
sudo uhubctl -l 1-1 -p 2 -a 1

I had to have a few goes to get the syntax right as it wants things in the correct order. I found the website a bit confusing myself but maybe I am just getting old.

Maybe you need to put in a feature request as above

What we need is an equivalent to SET_FAN_SPEED such as
SET_DISPLAY_CONTRAST DISPLAY=display CONTRAST=0

[edit] Just had a thought. Maybe your Arduino has a large capacitor and needs quite a delay before you try to switch it on again? It might fail if it thinks it has had a power glitch rather than proper power down/up.

10

I can turn it on and off all day manually with uhubctl, but not in an udev rule/script, since the powered off USB ports will not recognize the mainboard being plugged back in (by powering up).

The arduino never loses power at all, which is why it keeps the display powered (since they’re powered by the Pi).

I did put in a feature request with Fluidd to allow different settings for the power on and power off function of the power switch on the dash… that would allow the printer to be turned on via GPIO through moonraker normally, but run a macro first before shutting down.

1 Like
11

Sorry, I misunderstood your configuration. Maybe I am still misunderstanding but If the display is powered from the Pi, why can’t you run uhubctl on that. That’s what I do since my display is on one of my RasPi USB ports. The only problem I have is that sometimes the Pi seems to fail to recognise the display so I need to to [Firmware Restart] followed by [Restart].

12

Because I can’t auto-re-enable the USB ports when I power up. The SKR 3 is not recognized until I manually power the ports again.

13

Are you saying you can’t even re-enable USB power as soon as the display has gone dark? Normally once the display has been rebooted, it stays dark until it is re-activated by a command from Klipper. That’s why I have to [Restart] (and sometimes FWRestart, Restart) to get the display working again. I have never deliberately shutdown after using uhubctl to depower ports without repowering again first.

14

I can re-enable the USB power manually. What I can’t do is turn on the printer power, which powers the SKR3, so it would normally create an USB connection at this time, and use that trigger to re-enable the USB port power, since even though the SKR3 is not powered via USB, the USB ports will not recognize any device while they are in power down mode.

15

I thought you said that your power was controlled by relay from the RasPi. If that is the case you can do the same as mine (actually Voron V0 but with externally powered Pi as host).

See How to Use a Switch to Turn On and Off the Raspberry Pi - Circuit Basics for adding a soft-power button. It is unfortunate that you have to use GPIO3 (you lose the ability to use I2C) but it is one of the few pins which is pulled up internally while the Pi is in standby and it needs this to detect the dropping edge to perform the restart. In fact it may be the only pin in which dt-overlay awakens the pi from an edge detection.

I actually used one of these illuminated momentary-N.O. buttons so that I know when the rest of the printer is powered.

There is also useful info at How to add a power off button but the GPIOs for this project don’t allow repower.

[EDIT] Forgot to say for the help of any Voron Zero users that the pushbutton above fits perfectly through the hexagon holes in the lower skirt so you don’t need to drill any holes and if you want to remove later it looks pristine.

16

You’re mixing things up… the Pi controls a relay that powers the rest of the printer. The Pi is always powered and never shut down.

What I am trying to do:

  • Turn off the relay, cuts power to the mainboard. Display is powered by the Pi and remains lit. I want the display off. So when the mainboard drops off the USB port due to power down, turn off the Pi USB power → display turns off. This part works.

  • Turn on the relay, mainboard gets power. However, due to the USB ports being shut down, the system doesn’t see the mainboard even when it is powered again, therefore can’t trigger an udev rule to turn them back on.

17

I think that is what I understood. What I was saying is that having switched off the the relay, uhubctl can repower the USB port (and therefore the display) but the display will not light up until the relay restores power and you invoke klipper to send a message to the display.

My bit about the momentary switch is to also put the Pi into standby and save even more power. If you use GPIO3 on the Pi for the switch, it will wake the pi up again on the next push of the button.

Or… are you trying to create a system where you have an instant restart of the printer because you kept the Pi runnning. Even then, as long as you use uhubctl to turn the USBports on BEFORE the relay is operated, everything should work as normal. Although you might need to wait a few millisecs between those 2 events if there are any problems.

You system sounds fairly close to mine and it just works, although I do need to wait for the Pi to reboot after the button press before everything comes up as normal. Its just the same as depowering the entire system at the wall without having to reach under the desk and I must put my hand on heart and say yes it is not totally environmentally friendly because the Pi and its PSU still consumes several milliwatts while it is sleeping.

Sorry but I am not sure what else to suggest.

18

That works, manually. But I want to automate this, otherwise I may as well just manually turn off the neopixel LEDs of the display before power down instead.
The idea was to use the usb plugging in/plugging out of the SKR3 (due to the relay switching) as an udev trigger to turn the USB ports on and off, but since the ports won’t see the SKR3 in the off state, this isn’t possible.

19

Sorry but I seem to be missing something here.

  1. I had assumed that you are running Mainsail, Klipper etc on a RasPi which controls a relay through which power is fed to you printer (with embedded SKR3 and other electronics) except that the printers display is fed power directly from the RasPi USB port.
  2. I also assumed that the only automation was that when the print finishes, the Pi drops the relay to turn off the printer thus saving power when the printer is idle, but you are annoyed by the Display screen and its neopixel in the pushbutton still being illuminated.
  3. When you want to print something else you use a browser on your PC to open Mainsail on the Pi and tell the PI to switch on the power relay.
  4. Your original complaint is that the display, being powered by USB, doesn’t go off with the rest of the printer and you are annoyed by the lights remaining on during the night.

Have I understood so far?

My further assumption is that you have a script on the Pi which you run to turn on a GPIO port which controls the relay. You may have a second script or the first script takes parameters to flip that GPIO in order to turn the relay back on.

20

No script on the Pi (except for the udev rules, which don’t work properly cause it can’t detect the SKR3 being powered back up by the relais). I’m using Moonraker’s built in Power module, which switches a GPIO pin. I use the “power” button in Fluidd to turn the printer on and off.