Solved: Fan control doesn't work correctly in RRF 3.3

Gixxerfast

@achrn No, I wish I had an oscilloscope though.

Yeah, the inclination of the curve is possibly correct but It's been shifted in x it seems to me.

In the object model the frequency is set to 250 though the config is correct, It should be 25000 I guess. Also I checked the fan controller code on giyhub and it has been been rewritten a lot in 3.4 so it might be a firmware issue in 3.3. Maybe people don't run four or three wire fans so much.

Gixxerfast

I had a look in LocalFan.cpp for 3.3 and it was pretty obvious that the old code was not correct and this has been changed in 3.4.

I therefore installed 3.4 beta 5 and yes, now the thermostatic control of a fan scales correctly to the interval that's configured.

However it's still strange that you have no fan rpm below 55% duty cycle and the difference between 99% and 100% duty cycle is 2700 rpm which is half of the max speed. It should IMO scale like the speed characteristics diagram above. Something should be corrected or explained here.

achrn

@gixxerfast said in Fan control doesn't work correctly in RRF 3.3 and and 3.4:

However it's still strange that you have no fan rpm below 55% duty cycle and the difference between 99% and 100% duty cycle is 2700 rpm which is half of the max speed. It should IMO scale like the speed characteristics diagram above. Something should be corrected or explained here.

That still sounds like a hardware fault to me - if something is stopping the signal pulling up fast enough (if pullup is too weak) it would happen like that, I think.

I think it's unlikely that so few people are using 4-pin fans that no-one else has noticed a catastrophic bug in the firmware..

As a data point, my delta (runing 3.3 firmware) has two 4-pin fans (Noctua Redux 1800) and they work as expected:

This is rpm v. duty, stepping from 0.1 duty up to 1.0 and back down to 0.0, in steps of 0.05, sampling the rpm ten times at 2 second intervals at each duty value each direction. There's one erratic data point at 0.25 duty on the way up, one at 0.75 on the way down. There's an interesting step (and some uncertainty) at 0.4 duty.

The raw data is here, the columns being time, requested duty, actual duty, rpm. fan4.txt

Gixxerfast

@achrn OK, thanks. How does you fan config look like? Do you have a pullup on the tacho signal ? Should that matter?

achrn

@gixxerfast said in Fan control doesn't work correctly in RRF 3.3 and and 3.4:

@achrn OK, thanks. How does you fan config look like? Do you have a pullup on the tacho signal ? Should that matter?

My config looks the same as yours: M950 F4 C"!out5+out5.tach" Q25000 (for purpose of this test, at least)

I don't have any hardware mods - just four-pin fan connector plugged onto four-pin fan header. That is, take fan out of manufacturers packaging, plug it in to duet. Mine is a MB6HC.

Adding pullup to the tacho shouldn't be relevant, I think. That won't affect how fast the fan spins. (Unless you think your fan is actually spinning as fast as it should be, and it's just reporting low while spinning at the correct speed, but that wasn't the impression I got).

Pullup on the PWM might help. I hesitate to suggest a value (because I don't want to be responsible for frying your board or your fan) but maybe someone who is more confident about the circuits will chip in - https://forum.duet3d.com/post/251107 suggests an additional pullup of 10k to 5V. (If the fan is following the usual Intel spec 5V is the correct level - the Intel spec says 5.25V max).

dc42

@gixxerfast there appear to be three issues here:

The bug with fan temperature control over an interval, which has been fixed in RRF 3,4beta.
The object model browser in DWC always reports the fan PWM frequency as 250. This is because RRF does not report the PWM frequency. It appears that in the absence of receiving the frequency, DWC is displaying the default value instead of not displaying a value. I will change RRF to report the PWM frequency in the next beta.
Your fans do not provide a speed that scales linearly with the commanded PWM. This could be just the way your fans behave, or it could be an issue with PWM generation. To investigate the possibility of incorrect PWM generation, I connected a Noctua PWM fan to OUT3 on a Diet 3 Mini, configured it using m950 f5 c"!out3+out3.tach" q25000 and tried various fan settings. I also checked the PWM frequency, which was 24.999kHz according to my oscilloscope. The RPMs I read are:

20% 470
40% 1600
60% 2730
80% 3730
100% 5020

So it appear to me to be working correctly. This was with firmware 3.4.0beta5.

dc42

PS - it's occurred to me that depending on the input circuit of your fan, you may be able to improve the response by connecting a pullup resistor between the PWM input and +5V. 10K would be a good starting point.

Gixxerfast

@dc42 OK, but the control pulse voltage is already 5V from the Duet? What would a pullup resistor do in this case?

I'm unfortunately a bit lacking in my knowledge of electronics.

dc42

@gixxerfast the output is open drain so it relies on there being a pullup resistor in the fan.

Gixxerfast

@dc42
Yes, that was (sorry for choice of words) bloody perfect. I added a pullup resistor as you said 10K and now they scale very well I have no gap between 99 - 100 % It won't run until 15% but that's sort of expected and not a problem.

Btw, I had 4.87V without the pullup between V- and control.

It's crimping time.

I hope I can take the 5v from here without any worries.

Big thanks to @dc42 and @achrn

dc42

@gixxerfast thanks for confirming that.

The Intel specification for PWM fans says in section 2.1.4:

The following requirements are measured at the PWM (control) pin of the fan cable connector see Figure 7 and Table 1:
PWM Frequency: Target frequency 25 kHz, acceptable operational range 21 kHz to 28 kHz
Maximum voltage for logic low: VIL = 0.8 V
Absolute maximum current sourced: Imax = 5 mA (short circuit current)
Absolute maximum voltage level: VMax = 5.25 V (open circuit voltage)
This signal must be pulled up to a maximum of 5.25V within the fan.
Note:New fan designs are strongly encouraged to implement a 3.3V pull up for compatibility with buffer design limits on Hardware Monitor Devices e.g. Super IO devices.

So the specification requires there to be a pullup resistor inside the fan, although it doesn't specify a maximum value for it (the maximum current sourced implies a minimum value of about 1K). My guess is that your fans have a pullup resistor with a very high value, so that in conjunction with the capacitance of the cable, it slows down the rise time of the PWM signal excessively. If the fan cable is long, that would make this more of a problem, due to the increased capacitance.

achrn

@gixxerfast said in Solved: Fan control doesn't work correctly in RRF 3.3:

@dc42
It won't run until 15% but that's sort of expected and not a problem.

The Intel spec says behaviour below 20% is undefined. Some fans stop, and some run at a not-very-predictable rate, and some run at the same rpm for all duty values below 20%. Sometimes a manufacturer specifies what a particular fan does in this region, but not always.

Gixxerfast

@achrn Yes, and the fan speed is so low it doesn't really matter if they are on on or not. It makes no difference. Estoy muy contento