search

EricHigdon / OctoPrint-RGB_status

Adds RGB LED support to OctoPrint with the ability to choose effects based on the current status of your printer
33 stars 12 forks source link

Please support sending colors using M150 (Marlin) #14

Open coldtobi opened 5 years ago

coldtobi commented 5 years ago

My LED strip is connected on my FYSETC, so it would be cool to control that one... Of course, animations are hard there, but well, they are not that important. Thanks!

EricHigdon commented 5 years ago

@coldtobi This would be awesome. I wish I had a way to test. I may be able to do this if You or someone else can volunteer to test for me.

coldtobi commented 5 years ago

I can help testing that. Just ping me ;-)

ArmandAgopian commented 5 years ago

@EricHigdon I can test this, I am currently in the process of turning a massive print farm into LED stripped ones, this will help a lot!

JohnTRoth commented 4 years ago

I'd also be happy to test, and would also add that it would sure be nice to trigger desired effects via G-code as well. Perhaps a M150 E option.

My use case is an OctoScreen LCD display, which allows addition of buttons to trigger G-code on demand. It would sure be nice to be able to add buttons to enable different effects via the touchscreen.

JohnTRoth commented 4 years ago

I took a first stab at this, and have it supporting R, G (or U), B, P, and I parameters, but one bug I haven't been able to track down... When using I to set an individual pixel, it clears all others and I have no idea why. Upon realizing the issue, I even added code to get the pixel color first and explicitly set it to that same color - but it still turns all others off. Hard-coding to a specific color works though, so I suspect the getPixelColor call is failing. Seems like a start though.

EricHigdon commented 4 years ago

@JohnTRoth i think the issue you are seeing with the LEDs being reset every time the M150 gcode is run is because every time you start a new effect it kills the old sub process and reinitializes the whole strip in a new sub process. If you want to have some sort of update functionality without killing the last effect, you should try something similar to the progress update that I am doing using the queue. When processing M150, just put the new data in the queue to be handled by the sub process.

JohnTRoth commented 4 years ago

@EricHigdon I'm certain you're correct now that I look at the way you handle it... I'm not familiar with the queue functions though. I'll spend some time this weekend to try to integrate with it. Thanks!

EricHigdon commented 4 years ago

Putting messages in the queue is pretty simple. See line 357 of init.py.

The complication is going to be in making the queue messages more universal. Right now it is either “KILL” or a progress percentage to update the progress effect. I think we need to make it into a JSON string that contains keys for progress, and brightness.

JohnTRoth commented 4 years ago

Got everything working, but I'm not a developer so there's plenty of room for optimization. I think it would be nice if all effects blocks accepted just a json object containing all their needed parameters... but that change may be a bit beyond me.

Added fully functional M150, supporting the following: R - Red value (0-255) G or U - Green value (0-255) B - Blue value (0-255) P - Brightness (0-255) D - Delay I - LED Index (1 to # of LED's) When used in combination with Effect 9 (Solid With Brightness), specifying this will control the color/brightness of only the specified LED. Leaving this parameter out (or using a value of -1) will result in controlling all LED's E - Effect (0-9) The effect to display. Leaving out this parameter defaults to Effect 9 (Solid With Brightness) to maintain compatibility with the official M150 code.

Effects are one of: 0 = Theater Chase 1 = Solid Color 2 = Rainbow Cycle 3 = Rainbow 4 = Color Wipe 5 = Pulse 6 = Knight Rider 7 = Plasma 8 = Theater Chase Rainbow 9 = Color With Brightness