failure of pulse width modulation

[Lakei69]

Hello! I am a simple octoprint user that is installed on a raspberry pi 3b. I use pin 12 for pwm to dim the backlight. However, there is a problem. If the pwm value> 0 and <100 I see periodic flickering (pwm frequency> 100) I connected the oscilloscope to pin 12 and saw that the pwm signal periodically changes its value for a fraction of a second and then returns to the set frames again.

[RoboMagus]

Since you have an oscilloscope, could you check if other pins / other settings work for you?

And could you share some more information about how this backlight is wired up and if other Software is also used to control it?

My first guess since it briefly works and then reverts to its previous state is that something else is controlling that pin as well, and taking back control as soon as you set your values through this plugin.

[Lakei69]

Unfortunately, I have no way to check the situation on all gpio. I tested it on gpio 6, 12, 17, 23, 37. The situation is the same on all pins. The wiring diagram of my backlight doesn't matter. I am connecting an oscilloscope to a gpio raspberry. I'm not good at linux, but it seems to me that some higher priority periodic process is interrupting the pwm.

[Lakei69]

yes, I have other applications installed, but they do not affect the work of the specified gpio (I draw this conclusion based on the application settings)

[Lakei69]

Another important point. When pwm is 0% and 100% there is no problem. Problems are observed only between these values.

[RoboMagus]

I'm not good at linux, but it seems to me that some higher priority periodic process is interrupting the pwm.

The way you describe your problem I'm tempted to draw the same conclusion, but as I do not have access to your configuration that is hard for me to verify.

Looking at your list of plugins, there is quite a few that deal with GPIO. Even when they're not configured to interact with the pins you specify, they may somehow interact with the pins behavior. I cannot reproduce this issue you're describing and all I can do is look at the code of the other plugins in your screenshot to see if somehow they could interact in an unexpected manner.

Have you taken a look at Octoprints logfile when trying to set the Lights dutycycle to see if something shows up? And could you check for me what is the gpio behavior when disabling the PWM for that pin and toggling it on and off? Will it then also revert to its previous state, or retain the set value?

[Lakei69]

Hello. I tried turning pwm on and off. The pwm value is not saved after that. I also found one feature, I can change the pwm value with a linear slider, but when changed digitally, pwm does not change. I removed all applications that might possibly affect gpio. So far I have not achieved any result. octoprint.log

[Lakei69]

It may be off-topic, but I've removed apps like lights out. However, I can see them in the log. What is the reason for this, I do not understand.

[Lakei69]

[RoboMagus]

Thanks for providing the logfile. That'll provide some usefull information for when I have some more time to get into it.

A brief look suggests that each plugin that uses GPIO sets their own 'Mode', which does affect the state of GPIO for the other plugins. For me this is quite unexpected, but I can rework my plugin a bit to be more compatible.

There's a number of different GPIO related errors. Perhaps after I patch this plugin that'll be reduced, however some of the other plugins also seem to have GPIO issues.

Related to your last question. It seems that your octoprint refuses to correctly shutdown and restart again, looking at the log:

2022-01-10 20:04:40,661 - octoprint.server.api.system - INFO - Performing command for core:reboot: sudo shutdown -r now
2022-01-10 20:04:40,948 - octoprint.server - INFO - Shutting down...
2022-01-10 20:04:40,965 - octoprint.server.api.system - WARNING - Command for core:reboot failed with return code -15:
! STDOUT: 
! STDERR: 
2022-01-10 20:04:41,150 - octoprint.server - INFO - Calling on_shutdown on plugins
2022-01-10 20:04:41,151 - octoprint.events - INFO - Processing shutdown event, this will be our last event
2022-01-10 20:04:41,156 - octoprint.events - INFO - Event loop shut down
2022-01-10 20:04:41,212 - octoprint.plugins.HeaterTimeout - INFO - Shutting down...
2022-01-10 20:04:41,268 - octoprint.server - INFO - Goodbye!

No clue what causes this though, but it does explain why the plugins are still there after they should be uninstalled.

[Lakei69]

Thanks for the information! To reboot, I'll just power off the raspberry.

[RoboMagus]

I've made some changes to the plugin that should improve compatibility with other plugins that also use RPi.GPIO. These changes have been pushed to the CompatBranch branch.

The changes work in my setup, but before making a new release I would like to ask you to test if it works on your system too. You can install this version of the plugin through the plugin manager, by either entering it in the ... from URL box, or downloading it manually and selecting that ZIP file in the ... from an uploaded file box.

Please let me know your findings, and if possible share your log as you did before.

[RoboMagus]

By the way, after rebooting your Pi, were the other plugins removed succesfully?

When you re-install them, take a look at the logs in case some errors pop up. When browsing other plugins looking for a solution I have noticed quite a lot of plugins using RPi.GPIO that set the mode (Board or BCM) fixed to their likings. That would cause the same incompatibilities as that are hopefully fixed for this plugin.

[Lakei69]

I reinstalled lightcontrols from the archive you suggested. Unfortunately, this did not change anything. I am attaching a log. I don't want to offend anyone, but maybe you are not organizing pwm quite right? In your application settings, I can install pwm on almost any gpio, although the hardware pwm function is only available on gpio 12, 13, 18, 19. I found this information here https://www.electronicwings.com/raspberry-pi/raspberry-pi-pwm-generation-using-python-and-c octoprint(1).log

[RoboMagus]

RPi.GPIO does not use the hardware PWM peripheral at all. It just uses Soft-PWM for any GPIO pin you configure, so that's not an issue.

Looking at your log you might have to re configure your pin setting for LightControls. The pin is not configured after re-installing the plugin. Please re-configure and share your findings again.

On a positive note, the big bunch of GPIO related errors you had before now are no longer visible.

Also FYI, the shutdown / restart still seems to cause an error on your system. It might be a good idea to fix that or reboot your system anyway to avoid any unexpected behavior with modules not being correctly reloaded.

[Lakei69]

You may not have looked at the log file to the end. At first I really set the wrong pin, but later I corrected the settings and the backlight started working, but it still twitches.

[Lakei69]

https://user-images.githubusercontent.com/96955782/149386019-9c8d323e-c242-4ef6-bc15-3856cac400a5.mp4

[Lakei69]

I think that the pwm jerking problem cannot be solved if the concept is not changed. This video clearly shows the difference between software pwm and hardware pwm. https://www.youtube.com/watch?v=MIwiyn24cko

[RoboMagus]

It is indeed a known issue that soft PWM can cause flickering in lightstrips that are not smoothed out by e.g. a sufficiently large capacitor. Though I've never seen it act out as severely as you've shown in your video. Usually it's just some minor jitters.

These flashes, especially since they seem to occur on quite a fixed period would suggest something else is going on.

I'm not planning on handling the differnces between softPWM or hardware PWM capable pins any time soon though...

[Lakei69]

It's a pity. Then you should describe your application in more detail and let users know that you are using legjumps. In addition, I inform you that using a capacitor to fix the pwm situation is absolutely harmful. If the capacitor smoothes the gate or base pulses (depending on the type of transistor), then the transistor will operate in a linear mode and will generate a significant amount of heat. If the capacitor is at the output, then without a resistor in series connection, it will not work. Otherwise, the resistor will heat up. Your only way to fix the error is to use a hardware pwm. In any case, thanks for your work, but unfortunately in this form it is useless.