Toolhead RGB's no longer working (because I messed up!)

[7milesup]

Hey guys.  Well, I did it again... made more work for myself.

I ordered the ChaoticLab CNC tap and was finally able to install it.  I have the awesome chamber LED lights VoronManiac, which I would highly recommend.  I had the power on to the printer with everything powered up and used the chamber lights to help my old-ish eyes see the bits and bobs.  When I was tightening down the two-piece board on the print head, my hex driver hit one of the contacts.  Instant spark and the printer basically shut down - sort of.  I unplugged the printer and powered it back up, and it seemed to work just fine, except for the print head LEDs.    I have done a continuity check on the wiring and carefully looked over both the print head board along with the Octopus and found no apparent smoked components or traces.

I am assuming I did something to the Octo board (Octopus 1.1).  I am trying to understand how the LEDs work.  The signal wire coming from Octo board seems to send a very small +v when I command it through Mainsail (when checked with a DMM).  I tried another LED light I had here (12v) and it did not work, but then again, I am unclear if I had tested it correctly.

Can I move that Neopixel signal wire to another port on the Octo board? 

How do these LEDs work?  Are they getting all of the power from the + and - on the tool head, and the signal just tells the RGB what color to output?    I have no idea how these RGB LEDs work, so it is rather foreign to me. 

Did I fry the LEDs?  Or did I damage the Octo board?

I should point out that the printer seems fully functional, minus the LEDs.  It would be nice to have them so I can see what the snozzle is doing during a print.

Thanks for your help.

[VoronManiac]

Bummer.  The chamber lights are pretty addictive as a work light.  On my todo list to add an external 24V adapter/jack to run the lights w/o powering up the printer.

Either the driver on the MCU is blown or most likely the first LED in the chain is fried.  I assume you don't have a scope or have anyway to detect pulses.

The MCU PCB sends out a serial pulse stream to configure the LED's.  When the LED signal is low for an extended period, the serial interface is in reset. The MCU sends out a new pulse train every time a new set of colors or intensity is required.  I assume you are not running Rainbow LEDs. 

You want to make sure you have +5V measured against the GND on the Toolhead.

If you have an extra LED, remove the LED connector at the MCU and wire the new LED directly into the MCU and see if you can control it.  More painful, but you could unsolder the 2nd or 3rd (end) LED in the chain at the tool head and connect it directly to the MCU (+5, GND, LED).

There is a 74LVC1G125 voltage translator driver on the MCU that could be blown so it is theoretically repairable, but first do the experiment of driving the LED directly.

 

 

 

[zogzogzog]

You can drive these LEDs through different pin outputs.

On my BTT Octo Pro, I run the chamber LEDs off of the PB0 output (I think this is the one labeled for NEO pixel style LEDs on the PCB) and run the SB LEDs off of PB6 (one of the pins labeled for the BLTouch and the like).  Works fine.

If you blew the output pin for the LEDs you've been using, you can try another free pin.

I'm betting the LEDs are fine - if other 5V things from the controller boar are working, I'll be they are fine as well.  The procedure that @VoronManiacmentioned is pretty good - I'd start just checking 5V and if it's good, moving the controller side to a different pin, and seeing what happens.  @VoronManiacmay be correct that you blew the first LED and the others in the chain are OK.

 

Naughty, naughty for doing that with the juice on...

[7milesup]

@VoronManiac  Thank you for that info.  I will dig further into it and see what I come up with. 

 

39 minutes ago, zogzogzog said:

You can drive these LEDs through different pin outputs.

On my BTT Octo Pro, I run the chamber LEDs off of the PB0 output (I think this is the one labeled for NEO pixel style LEDs on the PCB) and run the SB LEDs off of PB6 (one of the pins labeled for the BLTouch and the like).  Works fine.

If you blew the output pin for the LEDs you've been using, you can try another free pin.

I'm betting the LEDs are fine - if other 5V things from the controller boar are working, I'll be they are fine as well.  The procedure that @VoronManiacmentioned is pretty good - I'd start just checking 5V and if it's good, moving the controller side to a different pin, and seeing what happens.  @VoronManiacmay be correct that you blew the first LED and the others in the chain are OK.

Naughty, naughty for doing that with the juice on...

Trying a different pin is exactly what I was wondering.  I will check into that and see how it goes. 

 

As far as the naughty, naughty... yes, guilty.  I literally forgot I had the power on.  The fans were off so no audible clues.  A lot of times I use an LED worklight when I am doing this stuff and believe that my brain was saying "worklight" even though that was not the case. 

 

[VoronManiac]

@zogzogzog PB0 is the input to the 74LVC1G125. 

@7milesup you could try a different "non-LED" output, but the output voltage would only be 3.3V.  Min guaranteed logic "1" level is 0.7*VDD so 3.5V, but it might work.

Edited January 15 by VoronManiac

[zogzogzog]

33 minutes ago, VoronManiac said:

but the output voltage would only be 3.3V.

I just mentioned PB0 and PB6 as an example of both using the Octopus (Pro in my case) "recommended" LED pin and another I/O pin - both simultaneously.

That's a solid point regarding the output voltage of other pins - I didn't even check for that when I went to grab the BLTouch output (running out of outputs) - I assumed it was a 5V compatible output since the BLTouch is a 5V device and that's the servo output but I didn't actually check (been a long time since I did that and the BLTouch doc is sort of vague on some of the details but the Klipper config is pretty definitive).  I've been reliable for the tool head LED outputs on PB6 so I never looked back.

 

[VoronManiac]

I also found a 120ohm series termination resistor at the MCU produced a pretty clean waveform with no overshoot at the LED's.  If you use PB6 as @zogzogzog mentioned, it shows a 10k pullup to 3.3V (on the schematic I downloaded).  Guessing the drive strength of the PB6 processor IO pad will be different from the '125 driver, so may need to tweak the series R value.

[7milesup]

6 hours ago, VoronManiac said:

I also found a 120ohm series termination resistor at the MCU produced a pretty clean waveform with no overshoot at the LED's.  If you use PB6 as @zogzogzog mentioned, it shows a 10k pullup to 3.3V (on the schematic I downloaded).  Guessing the drive strength of the PB6 processor IO pad will be different from the '125 driver, so may need to tweak the series R value.

Swoosh.  What?  LOL.  Yeah, that went over my head. 

How do I tweak the R value, and more importantly, what is the R value.

[claudermilk]

The BL Touch port works on the regular Octopus v1.1. My SB toolhead is hooked to the NeoPixel port, and my 2812B case strips are hooked to the BL Touch port. I think (and hope) it could be the first LED got fried. My understanding is the power is provided by the %v and GND, the signal tells each LED what color & intensity to output; there's a chip on each one that grabs the first (last?) data bit for itself, strips it off, and passes the rest on the the next LED to repeat the process. So there is a tiny, simple logic chip at each LED.

[7milesup]

Ok, that makes some sense.  Thanks for explaining it.  I had no idea that each LED had a logic chip. 

I think that order of operations would be 1). Determine if the voltage exists at the head, which I think it does. 2.) Move signal to a different Octopus pin.  3). Order new lights or a new Octopus board.

[zogzogzog]

12 hours ago, claudermilk said:

the signal tells each LED what color & intensity to output; there's a chip on each one that grabs the first (last?) data bit for itself

I like to think of it as a bucket brigade when I explain it - each 24 bits is 8 bits for each color.  When an LED gets a set of 24 bits, it lights the LEDs as such and when it gets the next 24 bits, it passes the previous 24 bits on to the next and lights according to the last set of bits.  @7milesup that way the wiring stays the same for an essentially unlimited number of LEDs - 5V and ground get passed along with the DI (Data In) for the first LED coming from the controller and the DO (Data Out) connected to the DI on the next LED.

The last LED only sees it's colors while the first LED saw them all but passed all but the last along with each LED lighting in accordance to the last pattern it received - super simple and elegant way to connect them.

I think your plan is spot on.

Edited January 16 by zogzogzog

[7milesup]

Following up on this thread. 

I tested the voltage output to the tool head, and that checked out.  I also checked the signal wire, and even though I do not have an oscilloscope, there seemed to be a slight change in signal (+v), so I felt that was working too.  I ordered a Linneo toolhead LED harness and I am back in business! 

Thank you again, guys, for your help and the learning experience.

[VoronManiac]

Glad to hear you are back up and running.  From the sound of it, the failure was a blown LED?

Using a volt meter, you will see a slight change in the signal voltage if there is a continuous stream of commands being set to the LED's like for continuously changing special effects.  I have an older set of macros that only send out a command when a new setting is commanded.

Short of a cheap scope, something else that might be handy is  a 24V tolerant logic probe to detect signal pulses.

Back to root cause, I am thinking about adding a secondary 24V wall wart adapter plug to get lighting when the printer is safely powered off. Not a recommendation and  haven't tried it yet, but something like this:  https://www.amazon.com/QTEATAK-Adapter-Connector-Dustproof-Waterproof/dp/B07VTZX2RK