UM3 frame light strips completely different colors!

[Hoffa 0]

I recently got myself a second hand (thirs hand maybe?) UM3, and after cleaning it up and doing all the calibrating, one thing still bothers me... The frame lights are completely different colours! 

The left is a very blue white, probably around 5500K and the right is a white so warm its basically a banana - Around 2300K if my well trained eye isn't mistaken. See attached picture, it's taken in overcast sunlight so pretty neutral. I can post more pictured once it's dark and the light is more visible.

Is this a result of something up with the firmware or some random customisation, or are the strips just really weird? I know you can supposedly program these in full RGB, so if I can find a fix through that, I'd be more than happy to give it a go, too! Either way, this really hurts my soul at the moment. 

 

Edited August 14, 2019 by Hoffa
removed duplicate image.

[gr5 2,210]

The lights are actually RGBW  (last one is white).  In other words there are 4 different controllable LEDs inside each of the 40 or so lights.  But there is no way to control just the right or left side.  They are all controlled together.  Maybe you could dim the blue or white component on both sides to get it more balanced.  

 

So you used to be able to change the colors with M142.  I'm not sure if that works with latest firmware.  One method is described here (post by neotko):

 

 

The more complicated way but more interactive way of trying out different colors is shown in this video (also by neotko):

 

 

[gr5 2,210]

Certainly you can also do this by messing with the firmware.

 

But if this really bothers you then consider ordering a spare set of LED strips.  Every reseller of Ultimaker has the ability to order and send you *any* part.  These parts aren't shown in their stores (there are too many) but if you email them then you can get a price quote.  For example 3dverkstan.se

 

 

[Hoffa 0]

I've got a few other mysterious issues with the printer, such as active leveling failing at the beginning of a print, but being completely fine when I access it from the menu. And I just had a print try to start below the prints surface three times in a row, but start just fine on the fourth go - this was printing over network (a new thing to me that I just wanted to try out so I have a rounded skillset...)
 

What I'm wondering is, whether it could be a firmware issue. I have what the machine claims to be the latest (5.2.11 - 2019/05/03). Can a firmware installation be corrupt in these ways without it causing a lethal fault and error message from the printer? 

[Hoffa 0]

Tried the M142 RGBW implementation into gcode but nothing changed. I tried both turning everything off and turning specific colors on, as per the video (except in gcode files I put on a USB stick and plugged into the printer). 

I hadn't even noticed before, but the top light strip is also the warm white, so it looks like the left is the odd man out being the cool white - it's also closer to the ~4000K that I'd like to look at. The previous owner said they hadn't noticed anything, but since this was in use before they got it, I'm wondering if maybe the left LED strip has been changed out at some point... 

Edited August 14, 2019 by Hoffa
spelling and clarity

[gr5 2,210]

Turn off active leveling.  I don't recommend it.  But keep in mind you need to not touch the printer during active leveling.  Stay at least a foot away.  Keep anything that radiates electromagnetic energy away from it also.  It's very sensitive.  Also the spring settings matter so make sure the bed springs aren't too tight and maybe take out the core, remove the clear top and stretch out that spring a little.  You need the core spring to be stronger than the bed spring.

 

Anyway, just turn off active leveling.  It's just a gimmick and if your bed isn't level it makes the bottom of your parts tilted (on purpose of course - it slowly recovers level over the bottom few mm).

 

For the S5 active leveling is much better as does more than just tilt correction - it corrects at each spot of potentially wavy glass.

 

Also open the print head and look inside at the part that flops down - the inside bottom of the head.  There should be 2 wires (typically red and white).  Tug on them very gently.  If either comes loose then that was your problem (that's the leveling sensor).

 

[fbrc8-erin 296]

55 minutes ago, Hoffa said:

Tried the M142 RGBW implementation into gcode but nothing changed. I tried both turning everything off and turning specific colors on, as per the video (except in gcode files I put on a USB stick and plugged into the printer). 

I hadn't even noticed before, but the top light strip is also the warm white, so it looks like the left is the odd man out being the cool white - it's also closer to the ~4000K that I'd like to look at. The previous owner said they hadn't noticed anything, but since this was in use before they got it, I'm wondering if maybe the left LED strip has been changed out at some point... 

 

It's a single LED strip set unless they've cut and soldered the wires. It's 3 sections of LEDs that (at least the OEM part) are one piece which plugs in at the board. The gel on the LEDs can discolor sometimes though which would make it more yellow.

[Hoffa 0]

1 hour ago, fbrc8-erin said:

 

It's a single LED strip set unless they've cut and soldered the wires. It's 3 sections of LEDs that (at least the OEM part) are one piece which plugs in at the board. The gel on the LEDs can discolor sometimes though which would make it more yellow.

 

Discolour slightly, sure, but exactly 2/3 yellow and 1/3 blue? When off, there is no colour difference in the LED strips or housings, so I'd say it's not that. 

 

Currently I'm stuck on why the gcode light changing doesn't work. If someone with latest firmware can confirm or deny it works for them, that would be very helpful! 

[gr5 2,210]

I think I heard a rumor they were going to turn off the feature in some version of the firmware.  I'd try it with sendgcode and if it doesn't work there then the feature is probably disabled.  Sorry.  Or possibly you need to be in developer mode for M142 to work.  Watch the video.

 

[Hoffa 0]

47 minutes ago, gr5 said:

I think I heard a rumor they were going to turn off the feature in some version of the firmware.  I'd try it with sendgcode and if it doesn't work there then the feature is probably disabled.  Sorry.  Or possibly you need to be in developer mode for M142 to work.  Watch the video.

 

Damn... If they're going to disable stuff like this, they should implement it as a feature in the UI at least! - Why have coloured lights if you can't use them? 

This is such a small thing, and it's currently occupying so much of my time, it's really silly... But this machine really won't fit into my fung shui'd workspace looking like it does. 

[Hoffa 0]

Alright, after trying a factory reset (didn't know I can't skip the whole insert filament tutorial!) and enabling developer mode, I managed to use sendgcode over ssh to achieve some results. 

 

What this clearly shows, is that all colours work fine (I ran a number of primary and secondary colours in RGB with the W turned to 0.) The light of r255g255b255w000 is sort of balanced, but as soon as W is given any value, the change becomes evident. 

 

With M124 r000g000b000w255 the situation looks as per my original picture. 

 

So, I can now confirm that the light strip in my printer is composed of 1/3 "cool white" and 2/3 "warm white" type LEDs. Why/how this is, I don't know... How much this will cost to replace, I also don't know, but I'll send in a request to my local dealer. 

[Hoffa 0]

After all those fun and games, it came time to restart the printer, and we're back to square one... This image, now that it's dark, really shows the extent of the issue. 

 

On a side note, I actually had broken sensor wires, so the bed leveling issue has maybe been resolved. I still don't plan on having it run automatically, of course, but it's a handy trick and since I technically paid for it, I want it to work as well as it can. It was a 10 minute fix, not counting another 5 minutes hunting down a lost screw... 

Edited August 14, 2019 by Hoffa

[Smithy 1,145]

2 hours ago, Hoffa said:

How much this will cost to replace

 

iGo3D sells the LED stripe for € 49,95

[Hoffa 0]

Thanks Smithy for that info, I bet it'll be similar from my local company, these prices are pretty much fixed as far as I can tell - taxes change slightly from country to country, of course. 

I need the silicone nozzle guard and possibly something else, so I might just make it a bundle... I'll try to see if my eye can get used to this colourscape for a few more days. 

[Smithy 1,145]

It would also bother me, but you can also turn off the LEDs so that they only light up when you're printing. Then it might be more bearable.

[Hoffa 0]

1 minute ago, Smithy said:

It would also bother me, but you can also turn off the LEDs so that they only light up when you're printing. Then it might be more bearable.

For now I ended up turning the lights off completely. I'll have to see about times when I want to remotely monitor the print - I guess then I can live with it. I usually keep the lights on my UM2+ off anyway, unless I want to film a timelapse or have some people over that want to see the printer. 

[gr5 2,210]

So you got it to work with sendgcode, maybe it will work now by inserting the gcode into a print job - just put it well past the comments as neotko explained in one of the links above I posted.

 

Maybe M142 works fine in gcode as long as you are in developer mode?

 

[gr5 2,210]

You can also do the sendgcode as a single line command from a good ssh client.  Something like:

 

ssh root@1.2.3.4 su ultimaker /usr/share/griffin/python3 command_util.py < echo "sendgcode M142 R255 G255 B255 W0"

 

 

[Hoffa 0]

Thanks for the tips, but a fix like that isn't solving the issue, nor is it what I feel I paid for when I opted to get Ultimaker printers. 

Once I'm done with current projects, I'll just switch out those LED strips for ones with even lighting, and I'll keep hoping UM developers decide to implement something in Cura or in the printer itself that allows me to play with the lighting colours. 

[tinkergnome 927]

5 hours ago, Hoffa said:

I'll keep hoping UM developers decide to implement something in Cura or in the printer itself that allows me to play with the lighting colours.

 

The printer-API is a big playground for those things, doesn't require developer mode and is used by Cura as well.

...and is even made by UM developers! 🙂

http://..../api/v1/printer/led

...works with HSV representation (hue, saturation, value) and gives you any color you want (after you've  repaired the hardware of course).

Those settings are volatile though, but still...

[johnse 31]

It seems that heat and age can cause this, and that some batches may be more prone to it.

 

Just a little background on LEDs https://www.digikey.com/en/articles/techzone/2011/aug/whiter-brighter-leds

 

also, a couple of threads with similar issues: 

https://linustechtips.com/main/topic/782977-cablemod-white-led-strip-turning-yellow/