Quote Originally Posted by DarkAlchemist View Post
See my edits above.

After reading the docs on SF 7.7 it seems we can write, and read, the eeprom to and from the SD card so if we knew where these two bytes were we could check the number that is there via a hex editor and if >= 100 we could change it.

What we are after, and probably change, is eeprom_offsets::COOLI NG_FAN_DUTY_CYCLE

edit: Lookee what I found (btw, this is the first time I ever downloaded, or saw, SF code so this is a learning experience compared to Marlin).

It would appear that this 4k file it will write the byte to look at would be at 0x0F63. What is throwing me is that it sounds like the duty cycle has to be set in the eeprom but that can't be right since the M command has a speed setting.

Yep, looking at this eeprom file everything is where it should be and what is there but a ton of 0xFF AND right at 0x0F63 is 0x64 which is 100 in decimal. So, PWM is never used.

Thing is if COOLING_FAN_PWM is not defined when compiled then the fan will always be full force and it will take a recompile and an upload to get rid of their 7.8 to get the fan PWM back.

Ahhh, crud I think I am chasing a red herring because in the Menu.cc there is this Since we never see this then this probably means it was never defined so Qidi turned it off on purpose.


It makes sense, well your logic does, Qidis on the other hand doesn't. Why the hell would they deliberately disable fan speed control. I just don't see the reasoning behind that, you can have it on, or off, but we won't let you have anything in between??? Wtf. Assuming of course it was intentional on their part and not someone's f up.

Still, it's something we should be able to rectify, but I'm curious to know what they've been up to in their implementation before I'd start flashing anything. Or, extra motherboard on standby