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

PSU Control via Raspberry Pi GPIO #3833

Closed
Cortexian opened this issue Jan 24, 2021 · 10 comments
Closed

PSU Control via Raspberry Pi GPIO #3833

Cortexian opened this issue Jan 24, 2021 · 10 comments

Comments

@Cortexian
Copy link

Foreword: I'm super new to 3D printing, Raspberry Pi's, Linux, etc. Please explain like I'm 5, I will not be upset. I know enough to be dangerous, but probably not enough to come up with this solution on my own.

My Setup:
Raspberry Pi 4 - Fluidd, Moonraker, Klipper (Linux process MCU)
Creality Ender 5 Plus - Klipper firmware

My Background:
I just recently switched to Klipper and Fluidd web UI as an alternative to Creality firmware and Octoprint. I was running into issues with Octoprint creating little tumor blobs all over my prints, and my research led me to believe that it was due to the way Octoprint pipes date to the printer. Essentially it wasn't fast enough. I tried Octoklipper, but since the plugin is depreciated I decided to give Fluidd a go. Love it, nice and lightweight and web ui works well on both my PCs and mobile devices.

I just succeeded in getting a secondary MCU configured on my Raspberry Pi to allow me to use the Creality filament runout sensor that I've hooked up to the Raspberry Pi GPIO pins rather than the Creality main board.

My Goal/Request:
I had purchased a 1 Channel 5V relay with the intent to set it up in Octoprint using the PSU Control plugin. I wanted to make sure I had a more robust failsafe to protect against thermal runaway.

Since I now have the secondary MCU setup and I can utilize my Raspberry Pi GPIO pins in Klipper/Fluidd, I would like to setup a power shutdown fail safe using this relay, but I'm not sure where to begin. Any help would be appreciated!

I'd like to be able to use the already defined max extruder and bed temperature values to trigger the relay and kill power to the machine if those values are exceeded. I have no idea where to begin. Please help!

Log provided purely to appease the bot. Not needed or relevant to request.
klippy.log

@Cortexian
Copy link
Author

Thanks for the link @Hywelmartin !

Perusing that bit of code, I'm understanding some of the syntax and what's going on. It looks to be exactly what I want. Unfortunately there appears to be zero documentation about that Moonraker Plugin. Any help there?

I see the information about discussing these things on Discord as well. I will join the Klipper Discord and ask around.

Thanks!

@Sergey1560
Copy link
Contributor

I have the same question. I want to control the power relay of the 3d printer using the raspberry gpio.
I configured the raspberry pin control:

[mcu]
serial: /dev/ttyUSB0
restart_method: command

[mcu rpi]
serial: /tmp/klipper_host_mcu

[output_pin mks_pwc]
pin: rpi:gpio20
pwm: False
value: 1
shutdown_value: 0

The control works if both mcu work. If printer board is turned off, then it is impossible ("// Printer is not ready") to control the raspberry gpio, to power up printer board.

@nforceroh
Copy link

I have the same question. I want to control the power relay of the 3d printer using the raspberry gpio.
I configured the raspberry pin control:

[mcu]
serial: /dev/ttyUSB0
restart_method: command

[mcu rpi]
serial: /tmp/klipper_host_mcu

[output_pin mks_pwc]
pin: rpi:gpio20
pwm: False
value: 1
shutdown_value: 0

The control works if both mcu work. If printer board is turned off, then it is impossible ("// Printer is not ready") to control the raspberry gpio, to power up printer board.

You can do it 2 ways, the klipper controls the pins using linux mcu or have moonraker control the pin. and you can also have linux_mcu and moonraker control the pins as long as they are not defined in both... Personally, I run linux_mcu and moonraker with separate IO pins defined. I use linux_mcu to query a HTU21D chamber sensor. I prefer it this way. I use a server PSU that supplies 12V via VSB to the RPi and I control the enable pins on the PSU via a 5v relay. When I turn on the relay, it powers up my SKR boards in my Voron. Here's how I do it:

in printer.cfg (follow instructions from https://www.klipper3d.org/RPi_microcontroller.html#why-use-rpi-as-a-secondary-mcu)
[mcu host]
serial: /tmp/klipper_host_mcu

[temperature_sensor chamber]
sensor_type: HTU21D
i2c_mcu: host
i2c_bus: i2c.1
htu21d_hold_master: true
htu21d_report_time: 10

[gcode_macro QUERY_HTU21D]
default_parameter_SENSOR: htu21d chamber
gcode:
{action_respond_info(
"Temperature: %.2f C\n"
"Humidity: %.2f%%" % (
printer[SENSOR].temperature,
printer[SENSOR].humidity))}

in moonraker.cfg
[power printer]
type: gpio
pin: !gpiochip0/gpio22
off_when_shutdown: True
restart_klipper_when_powered: true
initial_state: off

Moonraker will give you a toggle on gpio22 on the RPI that your relay is attached to. It looks like this in mainsail
image

@Sergey1560
Copy link
Contributor

You can do it 2 ways, the klipper controls the pins using linux mcu or have moonraker control the pin. and you can also have linux_mcu and moonraker control the pins as long as they are not defined in both... Personally, I run linux_mcu and moonraker with separate IO pins defined. I use linux_mcu to query a HTU21D chamber sensor. I prefer it this way. I use a server PSU that supplies 12V via VSB to the RPi and I control the enable pins on the PSU via a 5v relay. When I turn on the relay, it powers up my SKR boards in my Voron. Here's how I do it:

Thanks! Your way with moonraker worked. Is there any way to send a command to moonraker from the klipper? For example, for automatically emergency shutdown or shutdown after the end of printing (from gcode)?

The "linux_mcu" method doesn't work. As I said, if the printer board is not connected, klipper does not allow you send command for host mcu.

[mcu]
serial: /dev/ttyUSB0
restart_method: command

[mcu host]
serial: /tmp/klipper_host_mcu

[output_pin mks_pwc]
pin: host:gpio20
pwm: False
value: 1
shutdown_value: 0

If printer mcu is off:

$ SET_PIN PIN=mks_pwc VALUE=1
// Printer is not ready
// The klippy host software is attempting to connect. Please
// retry in a few moments.
!! Printer is not ready

If printer mcu is on, rapspberry gpio works fine.

@github-actions
Copy link

github-actions bot commented Mar 3, 2021

Hello,

It looks like there hasn't been any recent updates on this
Klipper github issue. If you created this issue and no
longer consider it open, then please login to github and
close the issue. Otherwise, if there is no further activity
on this thread then it will be automatically closed in a few
days.

Best regards,

~ Your friendly GitIssueBot

PS: I'm just an automated script, not a human being.

@github-actions github-actions bot added the Stale label Mar 3, 2021
@CharlieTemplar
Copy link

Just started with Klipper after 5 years using various marlin versions on RAMPS the SKR 32 bit. I've always used a server PSU for all my power needs. The raspi is on 5v standby power so is always on and the standby enable is done on raspi gpio.
The toggle PSU plugin grounds the standby enable and everything powers up.
But Klipper is never ready... Always have to do firmware restart manually if I can connect to the board that is, otherwise have to restart klipper service on the raspi.
I think this is generally the same thing described by the OP. So what can I do? do I have to put the firmware_restart in the PSU plugin config someplace? Should I be shutting down the printer board more gracefully? Is thee a wiki guide on this? couldn't find anything with the same setup.

@github-actions github-actions bot removed the Stale label Mar 5, 2021
@KevinOConnor
Copy link
Collaborator

Given our updated policy on github tickets (see https://www.klipper3d.org/Contact.html ) I am closing this ticket.

-Kevin

@aschor
Copy link

aschor commented Mar 30, 2021

You can do it 2 ways, the klipper controls the pins using linux mcu or have moonraker control the pin. and you can also have linux_mcu and moonraker control the pins as long as they are not defined in both... Personally, I run linux_mcu and moonraker with separate IO pins defined. I use linux_mcu to query a HTU21D chamber sensor. I prefer it this way. I use a server PSU that supplies 12V via VSB to the RPi and I control the enable pins on the PSU via a 5v relay. When I turn on the relay, it powers up my SKR boards in my Voron. Here's how I do it:

Thanks! Your way with moonraker worked. Is there any way to send a command to moonraker from the klipper? For example, for automatically emergency shutdown or shutdown after the end of printing (from gcode)?

The "linux_mcu" method doesn't work. As I said, if the printer board is not connected, klipper does not allow you send command for host mcu.

[mcu]
serial: /dev/ttyUSB0
restart_method: command

[mcu host]
serial: /tmp/klipper_host_mcu

[output_pin mks_pwc]
pin: host:gpio20
pwm: False
value: 1
shutdown_value: 0

If printer mcu is off:

$ SET_PIN PIN=mks_pwc VALUE=1
// Printer is not ready
// The klippy host software is attempting to connect. Please
// retry in a few moments.
!! Printer is not ready

If printer mcu is on, rapspberry gpio works fine.

Hi, I'm not sure WHY Kevin closed this, that's a little abrupt.

anyways, I'm in the process of migrating to moonraker/fluidd, and I found an answer to your question in moonraker documentation :

# printer.cfg
[gcode_macro POWER_OFF_PRINTER]
gcode:
  {action_call_remote_method("set_device_power",
                             device="printer",
                             state="off")}

so I'm happy with that, as I have a relay on the bed's power just for safety, that is for now toggled via gcode->respond->octoprint action plugin->script to toggle the gpio .... seems I'll be able to symplify it !

@Aasikki
Copy link

Aasikki commented Oct 2, 2021

Given our updated policy on github tickets (see https://www.klipper3d.org/Contact.html ) I am closing this ticket.

-Kevin

Bruh moment

@github-actions github-actions bot locked and limited conversation to collaborators Apr 1, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

8 participants