Open CoryCharlton opened 1 year ago
Started looking at the code and I saw this commit which is the root cause. It appears to be the intended behavior at this point.
That said I'll look at the code more to see if I can send over a PR to improve this. At first glance I think the correct solution for an odd numbered strip is to start from both ends and "share" the left over LED between both sides.
It was intended behaviour originally, because I wanted to make the effect symmetrical & using an odd number of LEDs resulted in confusing behaviour where the last few steps of the progress weren't represented properly if I remember right. Thinking about it now (it was a long time ago that I added the effect) the middle LED could be shared on an odd setup without impacting the progress steps.
Yup, that's what I did in my PR #211. The middle pixel is shared between both segments. I've been running it through multiple prints since I submitted the PR and it's working great.
I'll play with that once I am back with my development setup later this week - thank you for the PR!
Solution is implemented in PR #212
Description of the bug
The
Both Ends
progress effect skips the last LED if the strip has an odd number of LEDs.My test strip is weird because I borrowed it from a nightlight I'm building for my daughter while checking out the plugin. In these screenshots LED 1 is in the upper right and LED 63 is in the bottom left and each row alternates data direction.
Like this:
These screenshots are of the
Printing Progess
set toBoth Ends
and you can see that LED 1 is lit but LED 63 is not.I toggled torch mode just to show that the LED is working correctly.
Steps to reproduce
Both Ends
What happened instead?
The last LED does not light and progress begins from the last even numbered LED
Plugin version
0.8.1
OctoPrint version
1.8.6
(if relevant) OctoPi version
1.0.0 RC3
Log Files & Screenshots
No response
Anything else?
No response