[FR]: Use hardware PWM using rpi_hardware_pwm

[svenstaro]

Is your feature request related to a problem? Please describe.

Currently, this plugin is using software PWM which leads to flickering in LEDs.

Describe the solution you'd like

A simple solution to this problems exists in using rpi_hardware_pwm which allows for easy access to hardware PWM.

Describe alternatives you've considered

There is pigpio but it's inconvenient in comparison.

Additional context

#2.

[RoboMagus]

Adding support for HW PWM is somewhere on the ToDo list for this plugin, but I'm currently not actively developing new features at the moment.

Thanks for the link to the rpi_hardware_pwm module. This indeed looks much more easy to integrate into the current codebase than switching over to pigpio. Perhaps in the comming months I might be able to take a look...

In the meantime I'm open to PRs, should you wish to add the feature yourself 😉

[pawelsky]

Hi, any update on adding the HW PWM?

[RoboMagus]

Apologies for the delay. I no longer have a working setup using a Raspberry PI so my development efforts on implementing Hardware PWM stalled some time ago.

I've published the changes I made back then and drafted an RC release for you to check out.
Note that I have not been able to test these changes myself!

Feel free to check out these changes by switching release channels to Development and report back to me.
If you do, please keep an eye on your logs. If there are any issues creating a HW PWM channel it'll report an error and fallback to the software based PWM controls.

[svenstaro]

Out of interest and somewhat offtopic, what do you use nowadays instead of the RPi setup?

EDIT: I will definitely test the branch, thanks.

[RoboMagus]

what do you use nowadays instead of the RPi setup?

I run Octoprint as a Docker container with a bunch of other services on a single mini server (basically a Nuc).

[pawelsky]

I've installed the dev version but unfortunately the LEDs are still flickering. The version still shows up as 0.4.2 and keeps asking for update, but I believe that is because the version has not been updated in setup.py. Judging from the log the installed version is in fact 0.4.3rc1.

2023-06-21 12:04:12,939 - octoprint.plugins.softwareupdate - INFO - Starting update of LightControls to 0.4.3rc1...
2023-06-21 12:04:28,345 - octoprint.plugins.softwareupdate - INFO - Update of LightControls to 0.4.3rc1 successful!

I have configured PWM on pin 12 in RasPi's config file and I don't see any errors in the log, so I'm assuming the HW PWM is actually enabled.

2023-06-22 00:17:31,814 - octoprint.plugins.LightControls - DEBUG - LightControls settings initialized: '[{'frequency': '100', 'inverted': False, 'ispwm': True, 'name': 'Prusa Lights', 'onConnectValue': '25', 'onDisconnectValue': '0', 'onOctoprintStartValue': '10', 'onPrintEndValue': '25', 'onPrintPausedValue': '50', 'onPrintResumedValue': '100', 'onPrintStartValue': '100', 'pin': 12}]'
2023-06-22 00:17:31,815 - octoprint.plugins.LightControls - DEBUG - Running RPi.GPIO version 0.7.0
2023-06-22 00:17:31,815 - octoprint.plugins.LightControls - DEBUG - LightControls gpio_startup, pin: 12, settings: {'frequency': '100', 'inverted': False, 'ispwm': True, 'name': 'Prusa Lights', 'onConnectValue': '25', 'onDisconnectValue': '0', 'onOctoprintStartValue': '10', 'onPrintEndValue': '25', 'onPrintPausedValue': '50', 'onPrintResumedValue': '100', 'onPrintStartValue': '100', 'pin': 12}
2023-06-22 00:17:31,816 - octoprint.plugins.LightControls - DEBUG - LightControls pruned settings after initialize: '[{'frequency': '100', 'inverted': False, 'ispwm': True, 'name': 'Prusa Lights', 'onConnectValue': '25', 'onDisconnectValue': '0', 'onOctoprintStartValue': '10', 'onPrintEndValue': '25', 'onPrintPausedValue': '50', 'onPrintResumedValue': '100', 'onPrintStartValue': '100', 'pin': 12}]'
|  LightControls (0.4.2) = /home/pi/oprint/lib/python3.7/site-packages/octoprint_LightControls
2023-06-22 20:38:15,856 - octoprint.plugins.LightControls - DEBUG - Running RPi.GPIO version 0.7.0
2023-06-22 20:38:15,859 - octoprint.plugins.LightControls - DEBUG - LightControls gpio_startup, pin: 12, settings: {'frequency': '100', 'inverted': False, 'ispwm': True, 'name': 'Prusa Lights', 'onConnectValue': '25', 'onDisconnectValue': '0', 'onOctoprintStartValue': '10', 'onPrintEndValue': '25', 'onPrintPausedValue': '50', 'onPrintResumedValue': '100', 'onPrintStartValue': '100', 'pin': 12}
2023-06-22 20:38:15,859 - octoprint.plugins.LightControls - DEBUG - LightControls gpio_cleanup, pin: 12
2023-06-22 20:38:15,860 - octoprint.plugins.LightControls - DEBUG - LightControls pin(12).setValue(10), inverted: False
2023-06-22 20:38:38,363 - octoprint.plugins.LightControls - DEBUG - LightControls pin(12).setValue(25), inverted: False
2023-06-22 20:39:22,575 - octoprint.plugins.LightControls - DEBUG - SendingLightValues
2023-06-22 20:39:25,148 - octoprint.plugins.LightControls - DEBUG - LightControls pin(12).setValue(25), inverted: False

I'll try to measure pin 12 PWM output the signal analyzer to exclude any potential issue with my MOSEFT module used to control the LEDs and report back.

[RoboMagus]

Ah damn, forgot to bump the version number. That should be fixed in RC2.

[svenstaro]

So I tested this. I added dtoverlay=pwm,pin=12,func=4 to /boot/config.txt. This breaks my previous LED behavior completely and I don't see any lights coming up compared to software PWM. Also, there are no errors in the logs. This tells me that it's using hardware PWM for sure.

When I play with the light controls and I monitor watch cat /sys/class/pwm/pwmchip0/pwm0/duty_cycle, I do see a change happening there in the value. That tells me it's interacting with the hardware PWM driver.

I did play around with the frequency quite a bit but I do not see my lights coming back though the sysfs tells me something is definitely happening. Any ideas?

[svenstaro]

I debugged further using sysfs as documented here and for some reason I can't get any output at all using hardware PWM even though all the values look good. I also looked up that I actually have a clock running to drive the PWM:

vcgencmd measure_clock pwm
frequency(25)=99997560

However, on the bright side, it seems this plugin uses the hardware PWM correctly. Not sure where to go from here.

Some further research: The pin is definitely not "broken" as gpio -g write 12 1 works just fine. I'd also like to note that if I use gpio -g mode 12 pwm and then gpio -g pwm 12 500, I get a very nice and steady like and gpio readall shows the pin to be in ALT0 mode.

EDIT: As it turns out, when I set gpio -g mode 12 pwm it works just fine, that's all I have to do. Sadly the pin mode gets overridden and reset by LightControls when I save the settings, I'll continue investigating. However, it definitely is the case that something doesn't set the pin to be in PWM mode.

From a quick glance, it doesn't appear like RPi.GPIO even supports setting a pin mode other than IN and OUT.

[svenstaro]

I'm proposing #7 to fix my findings.

[svenstaro]

@RoboMagus What do you think?

[RoboMagus]

Thanks for the PR!
I've bumped the RC release to include your changes.

[pawelsky]

@RoboMagus Looks like the version in setup.py has not been updated...

Other that that it works without flickering with one corner case - when you switch the light from non-PWM mode to PWM mode in LightControls settings without restarting the OctoPrint, the light will not work.

Thanks @svenstaro, @RoboMagus!

[svenstaro]

Other that that it works without flickering with one corner case - when you switch the light from non-PWM mode to PWM mode in LightControls settings without restarting the OctoPrint, the light will not work.

The reason is that the pin then gets set into a wrong mode and won't be reset to the ALT0 mode that it needs to be in. This can be verified via gpio readall.