Hardware pwm #442

Open
wmonzel wants to merge 2 commits from wmonzel/HardwarePWM into master

View File

@@ -25,13 +25,16 @@ from smbus2 import SMBus
from .getPiTemp import PiTemp
import struct
## Import modifications for Hardware PWM using PiGPIO
import pigpio
thijstriemstra commented 2021-11-17 16:06:31 +00:00 (Migrated from github.com)
Review

this import forces all users of this plugin to install/import pigpio, even though the majority of the users won't use it.

this import forces all users of this plugin to install/import pigpio, even though the majority of the users won't use it.
wmonzel commented 2021-11-17 18:29:40 +00:00 (Migrated from github.com)
Review

Right. This also assumes that that the only case for using hardware pwm is a fan linked to a temperature sensor. A better way to do this is change the UI (ninja2?) to have the user choose either hardware pwm or software pwm as an output type and not just pwm. I'm willing to figure out how to do that if there is enough interest,

Right. This also assumes that that the only case for using hardware pwm is a fan linked to a temperature sensor. A better way to do this is change the UI (ninja2?) to have the user choose either hardware pwm or software pwm as an output type and not just pwm. I'm willing to figure out how to do that if there is enough interest,
bilde2910 commented 2021-12-08 14:10:16 +00:00 (Migrated from github.com)
Review

I agree with @wmonzel on this one, lack of hardware PWM support is a problem for me unfortunately, and means I have to resort to a separate plugin just to run the fans, meaning I lose the benefits of controlling the fan based on temperature, which is critical for maintaining a controlled temperature for printing within the enclosure.

Personally I think adding pigpio as an optional dependency would be nice, so those that need hardware PWM can install it, while those who don't need it, don't have to install additional software on the host. If it's possible to add support for this without making pigpio a required dependency, that would be absolutely amazing.

I agree with @wmonzel on this one, lack of hardware PWM support is a problem for me unfortunately, and means I have to resort to a separate plugin just to run the fans, meaning I lose the benefits of controlling the fan based on temperature, which is critical for maintaining a controlled temperature for printing within the enclosure. Personally I think adding `pigpio` as an optional dependency would be nice, so those that need hardware PWM can install it, while those who don't need it, don't have to install additional software on the host. If it's possible to add support for this without making `pigpio` a required dependency, that would be absolutely amazing.
ByteFetch commented 2022-01-09 01:58:08 +00:00 (Migrated from github.com)
Review

I am having the same issues with a Noctua fan and also agree with @wmonzel that having a hardware PWM option would be helpful as I cannot get the current PWM option to work reliability at the moment.

I am having the same issues with a Noctua fan and also agree with @wmonzel that having a hardware PWM option would be helpful as I cannot get the current PWM option to work reliability at the moment.
shortbloke commented 2022-01-26 20:14:46 +00:00 (Migrated from github.com)
Review

I've tested with pigpio and it's quite heavyweight using a chunk of resources scanning all the GPIO pins many times per second. I'm going to try and see if a lighter weight alternative is suitable: https://github.com/Pioreactor/rpi_hardware_pwm and allow this to be configured via the UI so that only users that want to use a hardware PWM will need to install this extra module. Not sure it will work, but it might address the concerns raised in the comment on this PR.

I've tested with pigpio and it's quite heavyweight using a chunk of resources scanning all the GPIO pins many times per second. I'm going to try and see if a lighter weight alternative is suitable: https://github.com/Pioreactor/rpi_hardware_pwm and allow this to be configured via the UI so that only users that want to use a hardware PWM will need to install this extra module. Not sure it will work, but it might address the concerns raised in the comment on this PR.
shortbloke commented 2022-01-30 17:58:09 +00:00 (Migrated from github.com)
Review

@thijstriemstra @bilde2910 @wmonzel I hope you don't mind. I've implemented an alternative to this PR which I believe addresses the concerns previously raised. See #474

@thijstriemstra @bilde2910 @wmonzel I hope you don't mind. I've implemented an alternative to this PR which I believe addresses the concerns previously raised. See #474
wmonzel commented 2022-02-02 14:47:43 +00:00 (Migrated from github.com)
Review

@shortbloke @thijstriemstra @bilde2910 I really do appreciate you doing this. I'm trying to test your code and have run into issues installing rpi-hardware-pwm. The installation fails with the error:
Could not find a version that satisfies the requirement rpi-hardware-pwm (from versions: )
No matching distribution found for rpi-hardware-pwm

The installation command in Pioreactor uses pip3 (sudo pip3 install rpi-hardware-pwm) and fails with pip3: command not found.
Trying to find a fix I've discovered that installing using sudo pip install to install packages is considered risky, and the package does not appear in the pypi.org or piwheels.org indexes.
Any ideas?

@shortbloke @thijstriemstra @bilde2910 I really do appreciate you doing this. I'm trying to test your code and have run into issues installing rpi-hardware-pwm. The installation fails with the error: **Could not find a version that satisfies the requirement rpi-hardware-pwm (from versions: ) No matching distribution found for rpi-hardware-pwm** The installation command in Pioreactor uses pip3 (sudo pip3 install rpi-hardware-pwm) and fails with pip3: command not found. Trying to find a fix I've discovered that installing using sudo pip install to install packages is considered risky, and the package does not appear in the pypi.org or piwheels.org indexes. Any ideas?
shortbloke commented 2022-02-02 14:58:38 +00:00 (Migrated from github.com)
Review

@wmonzel It sounds like your system is configured to have Python 2.7 as the default version of pip. This library needs Python 3. Assuming you have Python3 installed, check you have the Python3 version installed: sudo apt-get install python3-pip and/or see if you have pip but need to update it: python3 -m pip install --upgrade pip

By installing a python package with sudo it makes it available to everything, if you have OctoPrint running inside a venv then you can activate that and just install the package without sudo.

The rpi-hardware-pwm package is on pypi.org: https://pypi.org/project/rpi-hardware-pwm/

Not sure, but you may also find it useful to be able to change the default version of Python you have using update-alternatives see: https://raspberry-valley.azurewebsites.net/Python-Default-Version/

@wmonzel It sounds like your system is configured to have Python 2.7 as the default version of pip. This library needs Python 3. Assuming you have Python3 installed, check you have the Python3 version installed: `sudo apt-get install python3-pip` and/or see if you have pip but need to update it: `python3 -m pip install --upgrade pip` By installing a python package with `sudo` it makes it available to everything, if you have OctoPrint running inside a venv then you can activate that and just install the package without `sudo`. The rpi-hardware-pwm package is on pypi.org: https://pypi.org/project/rpi-hardware-pwm/ Not sure, but you may also find it useful to be able to change the default version of Python you have using `update-alternatives` see: https://raspberry-valley.azurewebsites.net/Python-Default-Version/
wmonzel commented 2022-02-03 15:42:19 +00:00 (Migrated from github.com)
Review

@shortbloke Thanks for your help. Changing the default version of Python did allow me to install rpi-hardware-pwm. But setting update-alternatives to auto mode (with python3.7 as the default) renders the MCP9808 temperature sensor unreadable. It appears to be dependent on python2.x since manually setting to python2.x fixes the temperature sensor but breaks rpi-hardware-pwm.

I'm learning as I go...

@shortbloke Thanks for your help. Changing the default version of Python did allow me to install rpi-hardware-pwm. But setting update-alternatives to auto mode (with python3.7 as the default) renders the MCP9808 temperature sensor unreadable. It appears to be dependent on python2.x since manually setting to python2.x fixes the temperature sensor but breaks rpi-hardware-pwm. I'm learning as I go...
shortbloke commented 2022-02-03 16:23:50 +00:00 (Migrated from github.com)
Review

Looking at MCP9808.py it just uses smbus. Would be interested in what errors you get. But maybe track that in a new issue specific to python3 and that sensor.

FYI Octoprint will require Python3 as of version 1.8 - https://octoprint.org/blog/2022/01/31/octoprint-1.8.0-will-require-python-3/

Looking at MCP9808.py it just uses smbus. Would be interested in what errors you get. But maybe track that in a new issue specific to python3 and that sensor. FYI Octoprint will require Python3 as of version 1.8 - https://octoprint.org/blog/2022/01/31/octoprint-1.8.0-will-require-python-3/
wmonzel commented 2022-02-07 15:24:49 +00:00 (Migrated from github.com)
Review

@shortbloke There already is an open issue for this: #302 It appears that multiple sensors are affected. After doing some digging, I've come to the conclusion that using pigpio is a better choice for the following reasons:

  • It turns out that the CPU load issue can be fixed. If scanning inputs is not required you can add the -m option (disable sampling) to ExecStart=/usr/bin/pigpiod -1 by editing /lib/systemd/system/pigpiod.service. On my Pi4 CPU went from around 8% to 0% for pigpiod. The sampling rate can also be reduced.
  • Pigpio is currently used by the Easy Servo and HardwarePWM plugins. Using HardwarePWM in conjunction with Enclosure gives you an easy way manually override the fan speed as needed. I find this very useful.
  • Pigpio and HardwarePWM both appear to be mature and well supported. rpi-hardware-pwm is fairly new and released specifically to support the Pioreactor code.
  • Pigpio could potentially be used to fully replace rpi.gpio
This pull request needs a lot more work before it is ready for release. I'm considering closing it and lending my support to your effort instead. How do you feel about switching to pigpio?
@shortbloke There already is an open issue for this: #302 It appears that multiple sensors are affected. After doing some digging, I've come to the conclusion that using pigpio is a better choice for the following reasons: <ul> <li>It turns out that the CPU load issue can be fixed. If scanning inputs is not required you can add the -m option (disable sampling) to ExecStart=/usr/bin/pigpiod -1 by editing /lib/systemd/system/pigpiod.service. On my Pi4 CPU went from around 8% to 0% for pigpiod. The sampling rate can also be reduced. <li>Pigpio is currently used by the Easy Servo and HardwarePWM plugins. Using HardwarePWM in conjunction with Enclosure gives you an easy way manually override the fan speed as needed. I find this very useful. <li> Pigpio and HardwarePWM both appear to be mature and well supported. rpi-hardware-pwm is fairly new and released specifically to support the Pioreactor code. <li> Pigpio could potentially be used to fully replace rpi.gpio </ul> This pull request needs a lot more work before it is ready for release. I'm considering closing it and lending my support to your effort instead. How do you feel about switching to pigpio?
shortbloke commented 2022-09-17 10:22:00 +01:00 (Migrated from github.com)
Review

Sorry for the delay in responding @wmonzel I agree pigpio has its advantages. There is a disadvantage in that is requires a little bit more setup and modification to the installed service. I was aiming to keep it simple and not place any requirements on those that didn't want to use any hardware pwm.
I could look to extend my PR further and offer support for multiple hardware pwm libraries, though that would create some added complexity in the UI.
Given the lack of progress of either of our PRs, it seems demand for this support is rather low ;-)

Sorry for the delay in responding @wmonzel I agree pigpio has its advantages. There is a disadvantage in that is requires a little bit more setup and modification to the installed service. I was aiming to keep it simple and not place any requirements on those that didn't want to use any hardware pwm. I could look to extend my PR further and offer support for multiple hardware pwm libraries, though that would create some added complexity in the UI. Given the lack of progress of either of our PRs, it seems demand for this support is rather low ;-)
##
#Function that returns Boolean output state of the GPIO inputs / outputs
def PinState_Boolean(pin, ActiveLow) :
try:
state = GPIO.input(pin)
if ActiveLow and not state: return True
if not ActiveLow and state: return True
if not ActiveLow and state: return True
return False
except:
return "ERROR: Unable to read pin"
@@ -41,7 +44,7 @@ def PinState_Human(pin, ActiveLow):
PinState = PinState_Boolean(pin, ActiveLow)
if PinState == True :
return " ON "
elif PinState == False:
elif PinState == False:
return " OFF "
else:
return PinState
@@ -54,7 +57,7 @@ def CheckInputActiveLow(Input_Pull_Resistor):
return True
else:
return False
class EnclosurePlugin(octoprint.plugin.StartupPlugin, octoprint.plugin.TemplatePlugin, octoprint.plugin.SettingsPlugin,
octoprint.plugin.AssetPlugin, octoprint.plugin.BlueprintPlugin,
octoprint.plugin.EventHandlerPlugin):
@@ -73,6 +76,38 @@ class EnclosurePlugin(octoprint.plugin.StartupPlugin, octoprint.plugin.TemplateP
dummy_value = 30.0
dummy_delta = 0.5
## New stuff, Init borrowed from HardwarePWM
def __init__(self):
self.IOpin = 13
self.Freq = 25000
self.dutyCycle = 0
self.HWGPIO = pigpio.pi()
def startHWPWM(self, pin, hz, percCycle):
cycle=int(percCycle*10000)
if (self.HWGPIO.connected):
if (pin==12 or pin==13 or pin==18 or pin==19):
self.HWGPIO.set_mode(pin, pigpio.ALT5)
self.HWGPIO.hardware_PWM(pin, hz, cycle)
else:
self._logger.error(str(pin)+" is not a hardware PWM pin.")
else:
self._logger.error("Not connected to PIGPIO")
def write_hwpwm(self,gpio,pwm_value):
for gpio_out_pwm in list(filter(lambda item: item['output_type'] == 'pwm', self.rpi_outputs)):
pwm_frequency = self.to_int(gpio_out_pwm['pwm_frequency'])
for pwm in self.pwm_instances:
if gpio in pwm:
pwm_object=pwm[gpio]
old_pwm_value = pwm['duty_cycle'] if 'duty_cycle' in pwm else -1
if not self.to_int(old_pwm_value) == self.to_int(pwm_value):
pwm['duty_cycle'] = pwm_value
self.startHWPWM(gpio, pwm_frequency, pwm_value) ## Figure out what to use instead of hardcoded freq
self._logger.info("Writing PWM on pigpio: %s value %s and frequency %s", gpio, pwm_value, pwm_frequency)
self.update_ui()
##
def start_timer(self):
"""
Function to start timer that checks enclosure temperature
@@ -315,7 +350,7 @@ class EnclosurePlugin(octoprint.plugin.StartupPlugin, octoprint.plugin.TemplateP
if rpi_output['output_type'] == 'regular':
index = self.to_int(rpi_output['index_id'])
label = rpi_output['label']
pin = self.to_int(rpi_output['gpio_pin'])
pin = self.to_int(rpi_output['gpio_pin'])
ActiveLow = rpi_output['active_low']
if rpi_output['gpio_i2c_enabled']:
b = self.gpio_i2c_input(rpi_output, ActiveLow)
@@ -1284,7 +1319,7 @@ class EnclosurePlugin(octoprint.plugin.StartupPlugin, octoprint.plugin.TemplateP
else:
calculated_duty = 0
self.write_pwm(gpio_pin, self.constrain(calculated_duty, 0, 100))
self.write_hwpwm(gpio_pin, self.constrain(calculated_duty, 0, 100))
except Exception as ex:
self.log_error(ex)