[Bug]: OS Config Test returns "Failed Test" for "SPI buffer size increased"

[ghost]

Description of the bug

No matter how many times I type in my pi's password (verified to be correct!) the OS Configuration Test says it needs my password for root access.

I've also tried to manually add the SPI buffer size to the cmdline.txt file as instructed.

I've also tried disabling sudo password protection all together on my Pi.

Still same error.

Steps to reproduce

No response

What happened instead?

During OS Config Test, got an error for "SPI buffer size increased"

Plugin version

0.7.2

OctoPrint version

1.6.1

(if relevant) OctoPi version

No response

Log Files & Screenshots

octoprint.log plugin_ws281x_led_status_debug.log

Anything else?

Thank you so much for your time and effort in making this plugin and helping out the users. I really appreciate it!

[cp2004]

So from what I can see it can't read the /boot/cmdline.txt file - it looks like some logging there may be broken, since it is not saying why, but just that it can't read it. The minimum core clock line needed to be set, and I can see where the OS was reporting the password incorrect in the log file:

2021-06-24 23:21:08,475 - octoprint.plugins.ws281x_led_status.wizard - INFO - Running system command for wiz_set_core_freq_min:['sudo', '-S', 'bash', '-c', "echo 'core_freq_min=500' >> /boot/config.txt"]
2021-06-24 23:21:09,073 - octoprint.plugins.ws281x_led_status.commandline - ERROR - Command for `sudo-Sbash-cecho 'core_freq_min=500' >> /boot/config.txt` failed with return code 1
2021-06-24 23:21:09,075 - octoprint.plugins.ws281x_led_status.commandline - ERROR - STDOUT: []
2021-06-24 23:21:09,075 - octoprint.plugins.ws281x_led_status.commandline - ERROR - STDOUT: ['[sudo] password for pi: \n', 'sudo: no password was provided\n']
2021-06-24 23:21:09,081 - octoprint.plugins.ws281x_led_status.wizard - WARNING - Tried to validate {} but files were missing
2021-06-24 23:21:13,526 - octoprint.plugins.ws281x_led_status - INFO - Running OS config test (UI mode)
2021-06-24 23:21:14,142 - octoprint.plugins.ws281x_led_status.wizard - WARNING - Tried to validate {} but files were missing
2021-06-24 23:21:15,052 - octoprint.plugins.ws281x_led_status - INFO - OS config test complete. Results:
| - adduser: True
| - spi_enabled: True
| - spi_buffer_increase: False !! Reason: missing
| - set_core_freq: True
| - set_core_freq_min: False !! Reason: failed
2021-06-24 23:21:23,080 - octoprint.plugins.ws281x_led_status.wizard - INFO - Running system command for wiz_set_core_freq_min:['sudo', '-S', 'bash', '-c', "echo 'core_freq_min=500' >> /boot/config.txt"]
2021-06-24 23:21:25,798 - octoprint.plugins.ws281x_led_status.commandline - ERROR - Command for `sudo-Sbash-cecho 'core_freq_min=500' >> /boot/config.txt` failed with return code 1
2021-06-24 23:21:25,798 - octoprint.plugins.ws281x_led_status.commandline - ERROR - STDOUT: []
2021-06-24 23:21:25,799 - octoprint.plugins.ws281x_led_status.commandline - ERROR - STDOUT: ['[sudo] password for pi: Sorry, try again.\n', '[sudo] password for pi: \n', 'sudo: no password was provided\n', 'sudo: 1 incorrect password attempt\n']

Then it did finally work on the last one, and the test is passing.

If your LEDs are working and you have manually added the line to /boot/cmdline.txt as it sounds like you have, you can safely ignore the OS config test and carry on using the plugin. I'm not sure why it can't find that file, but as above the logging line seems a bit broken.

2021-06-25 05:59:09,291 - octoprint.plugins.ws281x_led_status.wizard - WARNING - Tried to validate {} but files were missing

[ghost]

Thank you so much for the prompt response cp2004. And to answer your statement, NO my LEDs are NOT working properly.

Do you have any other things you think I should try? It's really strange, because I very specifically remember the Config Test passing 100% with no problems a few weeks ago (although I had not physically wired up any LEDs at that point, I was just exploring the plugin).

I noticed that this fail happened after I tried setting up a 3.5" Kuman touchscreen for OctoPrint TouchUI. I remember it also had to do some configurations and/or updates on some SPI code...? That screen never worked either, and I saw many people online who have had similar troubles getting that screen to work via the GPIO ribbon cable output.

One last thing (and this may be the kicker) I was following the "Wiring your LEDs" instructions before I even set out on this add-on to my set up, and I had already purchased WS2811 LEDs. However, they are 12V, NOT 5V.

Is this a lost cause? I wired up a 74AHCT125 Level Shifter no problem to bring the 3.3V data signal coming from the MOSI pin (GPIO 10) up to 5V, which I thought would be enough for the LED strip to address it properly.

If the LED strip is being powered by a 12V power supply, but the DATA input to the LED strip is 5V-level-shifted from GPIO 10, is this going to work? The LEDs are lighting up like crazy, they are just not lighting coherently, and not turning all one colour using the TEST function in the plugin.

I am just trying to isolate my problem, would you guess it's something to do with SPI, or have I misinterpreted WS281x to mean "5 Volt WS281x" and that doesn't include "12 Volt WS2811"?

Thank you so much for your time!

[cp2004]

I noticed that this fail happened after I tried setting up a 3.5" Kuman touchscreen for OctoPrint TouchUI. I remember it also had to do some configurations and/or updates on some SPI code...?

GPIO touchscreens often use the same resources that this plugin does - the SPI connection. I have seen this several times with people & their LEDs not working.

12V LEDs should be OK - from what I remember they are more picky about the signal line (or it could be less picky... 🤔). The wiring guide is orientated towards 5V LEDs, but it should probably mention 5V or 12V ones.

So conclusion, more likely the SPI. Can you remember what you did to try and setup that screen, or a link to a guide on how to do so?

[ghost]

I followed this guide exactly, line by line: https://community.octoprint.org/t/steps-to-install-touchui-for-kuman-3-5/16514/9

[cp2004]

Sorry, seems I forgot to reply here... Not sure how that happened.

Anyway, it seems the touchscreen also uses SPI. I took a quick look at the driver install scripts mentioned, it seems like a likely place for conflicts to me. I'm not an SPI-Touchscreen-Expert, so I have no idea what exactly is broken.

This was in the plugin's runner log, which shows everything from the LED strip driving process:

[2021-06-25 05:55:00,412] ERROR: RuntimeError('ws2811_init failed with code -13 (Unable to initialize SPI)')
[2021-06-25 05:55:00,413] ERROR: Strip failed to initialize, no effects will be run.

However, in your log SPI was showing as enabled. This probably means that the touchscreen is already using SPI, and you can't have more than one thing at a time using it.

[ghost]

So I have spent almost 2 months trying to get this plugin to work. No exaggeration at all. Since my last post, I have imaged a completely new SD card with OctoPi and started a new OctoPrint account from scratch.

I now at least pass ALL the "OS Config Tests" which is good!

I have tried making all the wires as short as possible to rule out any noise, and make the signal as strong as possible.

I have tried every single available profile in the settings, all of them non-inverted and inverted.

I have tried using different GPIO pins, (ie. 18, 12, etc.).

I just bought a 5V led strip and power supply to rule out the 12V scenario I was attempting, and again tried all everything.

I am using an SN74HCT125N Level shifter.

I have quadruple quintuple checked the wiring.

Does anyone have any suggestions????

Thank you!

[cp2004]

From this new install of OctoPrint, could you upload the new plugin_ws281x_led_status_debug.log file? Since the last one showed that the error was something else taking up the SPI channel there was no way this plugin was going to work.

What is the issue now? Are you getting any output on the LEDs, or are you getting some flickering or wrong colours? If you could get the new log across that would be great so we can verify that at least the software side is working now.

[ghost]

The LEDs are flickering, and the changing colors all over the place with no pattern. All the of 66 LEDs on the WS2811 light up. But they just don't change colors during the Utilities "Test" or during the "Torch" feature. Maybe I am doing the set-up or testing wrong? Ive tried just clicking the "Red Test", I've tried clicking then saving. I've tried saving the settings, and I've tried resetting OctoPrint after changing all the settings mentioned in my last post.

The octoprint.log and plugin_ws281x_led_status_debug.log files are attached. octoprint.log plugin_ws281x_led_status_debug.log

[cp2004]

Flickering and incorrect colours are usually common symptoms of bad wiring - make sure all your ground connections are well secured and there is a continuous connection between the LEDs, PSU and Raspberry Pi ground pins. At least we can say we have moved on, and the software side seems to be working OK (at least, from it's perspective in the log)

[Maligators]

@cp2004 Seems like I'm having the same issue, gonna try a few things to see if I can get it working, I'll update on my progress.

Edit: I managed to get it working, here are the steps I have taken:

1. I made sure this step in the setup had been completed (I had to fix one thing).
2. I fidgeted around with the wires a bit, and then noticed that the power bank I was using wasn't actually outputting any power, so I powered off the Pi and my Printer (Artillery Hornet) and plugged a little 5v USB power supply into my wall and attached the LED strip to it, and when I powered everything back on and ran the OS Config Test there were no errors and the LED strip finally worked! (also, you might want to check the LED strip settings to verify that you have the right Strip Type and Number of LEDs selected)

Also, if you haven't already, you might want to enable ssh on your raspberry pi (make sure to change the default password of "raspberry" to something more secure) so you can debug it remotely!

I hope this can be useful to anyone having this same issue!

[github-actions[bot]]

This issue has been marked a stale because it has been open for 14 days with no activity. If there is no further activity in the next 7 days this issue will be closed.

[github-actions[bot]]

This issue has been closed as there was no activity for 21 days. If this issue is still relevant, please request a reopen or create a new issue.