c-attack

There appears to be a Lighting Wizard or lighting configuration problem in 5.14 for the Commander Core and XT. Multiple users have reported this and the wizard fails to properly detect and manual setup does not work either. The only workaround we found was to uninstall 5.14, download the old CUE 4.33 from the main website, and run the Wizard while on 4.33. Then install 5.14 back over the top of 4.33 without uninstalling. The lighting config file is preserved and this allowed several users to set up their fans and then continue on normally. This is a known error and there should be a fix in 5.15 if you prefer not to jump through hoops.

This is an XD5 Elite LCD for the CUE Link system? I have no seen anyone else post about a screen failure. Can you add in more detail? Just stays black one day at power on?

Hardware Lighting/Assignments/etc. is now "Device Memory Mode" or DMM. However, you are not the first to report this and it is a confirmed bug in this release. The RAM does not drop out of CUE in DMM/Hardware mode when the PC enters S3 sleep. The only workaround I found was to create your static black layer in DMM mode, then manually toggle the RAM into DMM mode prior to entering sleep. It will stay in DMM mode until you toggle it back off at a later time.

A few other people have reported the loss of package temp on this release, but all of them were AMD and that has been on ongoing issue for a while on some of those models. You're the first I have seen on Intel and my XD5 LCD pump will show CPU package temp for my 13900K and it is present in CUE as a data point and source. Normally I would say do a clean install, but you've already done that. Not sure why package temp is missing for you.

No, it will not damage the hardware. The RAM red triangle in CUE is a communications error. You can pull up HWinfo or something similar and you'll notice it can't read the RAM temp data either in this state.

Try reinstalling your chipset drivers and make sure you quit CUE before you do it. Usually this (red triangle) happens when CUE gets tied up on the SMBus and can’t communicate with the RAM. I don’t know why it happens. Program conflict is one, but it certainly happens without that and I’ve seen short stretches of it as well. As annoying as it is to do, a clean install of CUE may help as well if the problem is with the Corsair LLA service.

Did you recently update to CUE 5.14? This version has the new UI changes but critically for CUE Link users expands the device capacity from 14->24. This caused the fans to be renumbered and it's not going to match your previous configuration. Anyone with CUE Link gear needs to do a clean install to clean out any old config data. Make sure you export your profiles first so you can import them back later. Might need to reapply some lighting effects to specific fans or devices. https://www.corsair.com/us/en/explorer/diy-builder/blogs/addressing-over-current-protection-issues-expanding-the-icue-link-system-hub-to-24-devices/

Yeah, don't get too worked up over the CUE CPU temp reading or it's % load either. If you want detailed CPU temp info, use HWinfo. While we are talking about it, CUE's core temp numbering is incorrect for Raptor Lake and has been for a long time. I don't even leave my cores up on the dashboard anymore. You've already figured out it provides a different reading for package temp than HWinfo. Use HWinfo when trying to accurately asses core behavior, both for the temp and the frequency/VID/Voltage values you need to make sense of it. This is normal behavior these days for Intel. One core spiking is some minor task being executed and the CPU is doing what it's supposed to do -- respond rapidly. A slightly more complex issue is when all the cores respond to these minor tasks and this can sometimes happen with some manual overclocks. The CPU behavior has become very sophisticated and the brute force manual OC is not a great option. However, the temps are still fairly simple. When a core sparks up, it will warm up. No amount of pump speed, fan speed, or radiator real estate that prevent it from heating up as voltage is applied. The CPU IHS transfers the heat to the cold plate on the block, which in turn transfers to the water. The water transports heat to the radiator for dissipation. The cooling system is a waste heat removal service. It's fun to set up a massive case with yards of radiator length, but when your CPU is sitting at idle and only punching 17-23W, it doesn't make a difference whether you are running a 3x3m square external cooling system or a little 120mm radiator. The cooling system only has 20W to get rid off and all CPU temp results are voltage and conductivity alone. If we pair your motherboard and CPU with any cooling method or brand, the idle temps will be effectively the same aside from minor differences in thermal conductivity on the cold plate. It's when you load up your 600W GPU and 300W CPU that you can start showing off and blowing that heat all over the room while maintaining excellent hardware temps. If you get the mount wrong, you will see CPU temps 15-20C higher than expected. They will instantly hit that 95-100C mark when they should not. If you get the mount just a little imperfect, you might see a large disparity between core temps when at full load. However, this is no longer a reliable metric as these 8+16 CPUs all have a health 5-9C core differential between best and worst cores. Too many cores, too close together. There is some heat sharing and some of them will be better/worse for it. So a slightly imperfect mount might run just a touch higher than expected. Don't use idle temp to measure that. Use a full stress test with a linear load. I usually recommend CPU-Z "bench test" because it is under the 253W Intel power limit so you won't bang off the ceiling and downclock while providing an even load. This is a good way to test multiple things, like pump speed vs CPU temp or your heat transfer.

There is definitely something going on with fan/pump curves and the "new" Device Memory Mode as well as some glitches when running from normal software mode. There seem to be a lot of shades of this and new reports are coming in frequently for different gear. At this point I am just trying to categorize into controller type -> Does X, when I do Y. I am a little short on workarounds right now. Older devices still show a static color option under custom in DDM. My CUE Link stuff has no custom options. Presets only. I believe this to be an error as the CUE Link hub has higher hardware capabilities than most other devices and at a minimum there needs to be a static color option so you can do 0,0,0 (off).

You need to exclude Corsair internal devices like fan controllers, AIOs, and usually PSUs from HWinfo monitoring. RAM is usually OK. Both programs will get locked up trying to access the same device at the same time. I am trying to remember whether the 5000T came with a Commander Pro or Lighting Node Pro set up for the case RGB strips. Checking the CorsairLink & Asetek support option may work in certain cases, but your AIO is not Asetek and it doesn't resolve the monitoring conflict with other hardware.

Ok. So 1-3 are the QX rear temp sensor values. 36C intake air (assuming fans are on the front side of radiator) guarantees you will have coolant temp of 36-40C at idle. If intake air temp is 36C, then minimum coolant temp is also 36C. Most users float 4-7C above that value depending on unique case conditions and cpu idle power levels. So you’re within normal allowances for your intake temp. Just wanted to make sure there wasn’t a pump or flow issue.

Coolant temp? Or cpu/gpu temp?

Short Version: 1 & 3 -> Anyone with a pre-existing CUE Link hub that was set up prior to CUE 5.14 and the FW expansion to 24 devices needs to do a clean install of CUE. This has been discussed at length elsewhere, but in effect the fan enumeration changed when it went from 1-7 and 8-14 to 1-12 and 13-24. Lots of things tied to that identification. Export all your valuable profiles, clean install, then import your profile exports. Things will not work right until you do. https://www.corsair.com/us/en/explorer/diy-builder/blogs/addressing-over-current-protection-issues-expanding-the-icue-link-system-hub-to-24-devices/ 2) You should be able to save basic custom patterns like static, wave, ripple, etc. to DDM mode and the CUE Link hub and half the point of DDM is make it work like the keyboards with an active save mechanic (whether you like that or not). I’ll try and test some combinations later today. What’s your hardware? CUE Link AIO and QX fans?

Yes, unfortunately this seems to be the only option right now. There is another thread where we worked through it along with some additional issues, but if you have new fans or need to configure a Commander Core or XT, you likely need to uninstall 5.14, download 4.33 from the website, run the lighting wizard to auto detect, then reinstall CUE 5.14 over the top. There should be a correction in the next release, but for the moment this is an issue.

Yeah, unfortunately I’ve seen and reported that one as well. My tests were for the XD5 Elite, but not too surprising the CUE Link AIO does the same. I believe the hub is using CPU temp as the DDM control variable even when the custom curve specifies a native liquid temp from the AIO or XD5 Elite. So for your original issue, you create a DDM mode curve based on coolant temp (20-45C range), but it substitutes CPU temp as the sensor causing you to run at the high end of the curve at idle. If you set the actual Quiet fan preset in DDM mode, it seems to behave itself. This is probably another opportunity to remind Corsair the invisible presets don’t benefit anyone. Even if they don’t want us to be able to modify them, show the graph data “greyed out” so users can understand the behavior.