M150 commands not controlling LEDs

[xstrex]

So I'm having some issues with the LEDStripControl plugin.

I've built a power control module for a LED strip, tested everything, and it works. From the pi (as the pi user), I can execute "pigs p 17 255" from the command line, and it works as expected, turning the (green) LEDs on. I've tried the other colors, and they work as well.

Because of this, the pi user is in the gpio group:

# groups
pi dialout video gpio

I've installed the LEDStripControl plugin, specified the GPIO pins, saved, and restarted the octopi server. I've also ensured that pigpiod is running, at boot (which allowed me to exec the color change commands above).

When I enter a M150 command, on the terminal in octoprint, I get:

Send: M150 R U B
Recv: ok
[...]
Send: M150 R255
Recv: ok
[...]

But the LEDs never turn on, change color, or what not.

To make matters more interesting, here's what I get in the octoprint.log for the above commands:

2017-03-31 19:23:27,880 - octoprint.util.comm - ERROR - Error while processing hook LEDStripControl for phase queuing and command M150 R U B:
Traceback (most recent call last):
  File "/home/pi/oprint/local/lib/python2.7/site-packages/OctoPrint-1.3.2-py2.7.egg/octoprint/util/comm.py", line 2138, in _process_command_phase
    hook_result = hook(self, phase, command, command_type, gcode)
  File "/home/pi/oprint/local/lib/python2.7/site-packages/octoprint_LEDStripControl/__init__.py", line 93, in HandleM150
    self._leds[l].ChangeDutyCycle(dutycycles[l])
AttributeError: 'NoneType' object has no attribute 'ChangeDutyCycle'
2017-03-31 19:23:33,162 - octoprint.util.comm - ERROR - Error while processing hook LEDStripControl for phase queuing and command M150 R255:
Traceback (most recent call last):
  File "/home/pi/oprint/local/lib/python2.7/site-packages/OctoPrint-1.3.2-py2.7.egg/octoprint/util/comm.py", line 2138, in _process_command_phase
    hook_result = hook(self, phase, command, command_type, gcode)
  File "/home/pi/oprint/local/lib/python2.7/site-packages/octoprint_LEDStripControl/__init__.py", line 93, in HandleM150
    self._leds[l].ChangeDutyCycle(dutycycles[l])
AttributeError: 'NoneType' object has no attribute 'ChangeDutyCycle'

Any suggestions?

[xstrex]

Same result after reinstalling the plugin.

[precision]

Did you configure the GPIOs under the Octoprint Settings Menu?

[precision]

Sorry, I missed where you said that you did configure the strips. Can you paste the Plugins section from ~pi/.octoprint/config.yaml? It should look something like..

plugins: LEDStripControl: _config_version: 1 b: '15' g: '11' r: '13'

I saw you used pigs? The plugin uses RPi.GPIO not pigs, so you might have to stop pigpiod as well.

[precision]

Hrm, I just tested here and having pigpio running doesn't seem to make a difference. So far the only way I can reproduce the same error is if the plugin itself hadn't been configured.

[xstrex]

Here's the plugins section in config.yaml: plugins: LEDStripControl: _config_version: 1 b: '27' g: '22' r: '17'

[precision]

Those don't look like the physical pin numbers, according to my sheet pin 27 is SDA.0 and 17 is a 3.3v pin. The plugin wants the physical pins.

[xstrex]

I'm not sure what you mean by "physical pins", from the command line, the following command works: pigs p 17 255 && pigs p 22 255 && pigs p 27 255

So wouldn't 17, 22 & 27 be the physical pings? Am I missing something here?

[precision]

Try this, red: 11, green: 15, blue: 13. I think those are the physical pins for the GPIO pin numbers that pigs is using in your config.

[xstrex]

I've currently got something printing, should I still be able to enter M150 commands on the Terminal tab, and have them run ok? I've tried 11, 15, 13, (after adding them to the config, and saving), but M150 R255 didn't do anything, but I also didn't see anything in the octoprint.log file either.

[xstrex]

If the issue is that the pins are wrong in the config, I can take a closer look at them a bit later (after my current print is done), and report back what I find.

[precision]

I think this it is just the way the pins are specified. Some applications want BCM pin numbering (pretty sure pigs uses this), some (this plugin) wants the physical pin numbers.

See http://elinux.org/RPi_Low-level_peripherals#General_Purpose_Input.2FOutput_.28GPIO.29 And http://blog.mcmelectronics.com/image.axd?picture=%2F2016%2F03%2FGPIO-Chart2.jpg

I'd wait until your print finishes before messing with it, I don't know iif Octoprint fires the on_settings_save() while it is printing, or if it'll get fired afterwards.

[xstrex]

Alright, thanks. I'll investigate further and get back to ya on what I find. Thanks for the help.

[xstrex]

So changing the pin number to 11, 15, 13 in the LEDStripCrontrol settings page, fixed my problem. Thanks for all the help!

[precision]

Awesome, great to hear!

[wapiti59]

I've got a similar, yet at the same time different issue. I built and set up a standard hobby servo to deploy a brush over the print bed, with the intent that when the extruder heats up, it makes a few passes over the brush to clean itself off before starting a print. The challenge I had, that I THOUGHT I had beat, is that the motherboard in my printer (Geeetech A30) has absolutely NO way to connect a servo to it to control it from the printer. So, after a few months of pondering and looking, I came across a Sparkfun Servo Trigger that handles the actual control and powering of the servo. It simply relies on a switch state also connected to it to control if it moves the servo to position A, or position B. So, I independently powered the Servo Trigger from it's own 5V power source, and then am using the RGB LED Light control plugin to control it. I connected I think it was physical pin 7 on the Pi's GPIO header to the input side, and ground on the Pi GPIO header to the other side. I configured the plugin to only know about that pin, making it think it's controlling the Red LED's So, issuing an M150 R0 (full off) command from the terminal homes the brush out of the way of the extruder and clear of the print bed, and M150 R255 (full on) deploys the brush out over the print bed ready for the cleaning passes. It runs beautifully from the terminal. So, I built the following command sequence into the print starting scripts of Simplify 3D thinking I had this licked, keyed to execute after the extruder has heated to temperature:

G1 Z30; (raise the extruder to the right height for cleaning) M150 R255; (deploy the brush) G1 X335; (first pass over the brush) G1 X300; (second pass over the brush) G1 X335; (third pass over the brush) G1 X300; (fourth pass over the brush) M150 R0; (home the brush out of the way)

In theory, it should work great, but it doesn't. All of the G commands get passed, but none of the M150 commands are executing. So, I thought OK, until I can figure this out (ya, right), I'll just monitor the printer and when it starts the cleaning cycle, I'll just issue the M150 commands from the terminal. Ya, no such luck. Nothing passes. What am I missing here? Help???

[precision]

@wapiti59 ingenious use of this plugin. Let me see if I'm following this correctly: Executing M150 R255 from the terminal deploys the brush fine when no print is running Putting M150 R255 into your GCODE doesn't execute while printing though?

If that is what is happening, I'm kinda at a loss as to what could be causing it.

First I'd enable debug logging for the plugin to see if it is even being called.. Try adding the following to ~/.octoprint/logging.yaml on your Pi and restarting Octoprint. This should give you quite a bit of log information to ~/.octoprint/logs/octoprint.log

loggers:
  octoprint.plugins.LEDStripControl:
    level: DEBUG

[wapiti59]

Thank you! Your summary is correct, nor will it allow me to manually enter them from the Gcode terminal in Octoprint while a print is running. I will do that as soon as this print finishes in a bit. I suspect they are passing, but not executing because Octoprint is passing them to the print buffer in the printer in the Gcode stream, which has no idea what to do with them so it blows by them. Chris Riley has suggested adding an M500 after the servo commands, but if what I suspect is happening is true, that will only lock up the printer for something that's not going to happen. Another user in another forum has suggested I use a different plugin (Gcode System Commands) with a couple of simple python scripts that deploy and then home the brush. He said that's what he uses to do things "Pi side" during a print.

[precision]

Hrm, that shouldn't be possible if LEDStripControl is loaded and active. You can see here where it is hijaacking the M150 command as it passes through the buffer.

[wapiti59]

Finally, Finally, Finally got it all working. The problem traced to the M150 commands were passing at machine speed, which was too fast for the servo trigger to get a state reading from. Inserting a G4 P500 command after each solved the problem as it gave the servo trigger time to read the switch state. Posting the entire thing, with instructions to Thingiverse. Will post the link here once it's up.

[precision]

Great to hear!

[wapiti59]

https://www.thingiverse.com/thing:4056192