TRIAC controlled fan output on furnace control board not working

[geppa.dee]

At board power-on, the fan output connector has mains (230V AC) voltage without the fan connected, that drops to ~2V AC with the fan connected.

At power-on, on the attached display, the board shows a message error code that means "insufficient fan speed". From this, I deduce that the fan is supposed to be starting immediately but it doesn't.

As far as I can understand it, the output is controlled by an ATMEGA micro-controller, through an ULN2003 Darlington array, through an MOC3063 opto-coupled, zero-cross TRIAC driver and finally a BT136 TRIAC. It includes what I believe is a snubber circuit comprising 3 resistors and a capacitor and also a motor (start or run) capacitor.

I have determined the motor (and its external capacitor) to work by connecting it directly to mains. It rotates vigorously.

The motor also has cables (that go to another part of the control board) for an internal speed sensing mechanism that takes +5VDC (and GND) and outputs ~4.3VDC at certain rotor angles that I have also determined to function correctly.

I have changed the TRIAC and the TRIAC driver on the board with new parts to exactly no change in behavior.

What information should I add to this question?

What further steps can I take to try and fix this issue?

Thank you very much in advance for any help.

(I'm cross-posting this on electronics.stackexchange.com. I apologize if this prohibited)

[inse]

As you have already mapped the entire control chain of the fan, you can check now where the signal is lost.
Fan - TRIAC - Triac driver - ULN - micro controller.
Any kind of fuse for the fan involved?
The open load voltage present at the fan connector could also be generated by a snubber network or the zero crossing driver.

[geppa.dee]

I took both the MOC3063 and the BT136 out of the board and still see the main voltage at the fan connector without the fan connected. Am I right in assuming this is leakage from the snubber?
Should shorting the gate and one of the terminals (T1?) of the TRIAC, under power, prove that the TRIAC is working fine, assuming it makes the fan work?

[inse]

TRIAC and driver can be ruled out, so I propose to make sure everything downstream of the TRIAC works by shorting both anodes.
The investigate upstream of the driver: is it controlled on?
We don’t know what kind of filter or EMC circuit is involved, might also be stray voltage picked up by the high impedance input of your meter.

[geppa.dee]

TRIAC and driver can be ruled out, so I propose to make sure everything downstream of the TRIAC works by shorting both anodes.

Did that just now. The motor turns vigurosly.

The investigate upstream of the driver: is it controlled on?

For some reason, I thought yes. But now I've tried to measure the DC voltage on the LED side of the optocoupler (that I've put back on the board) and it fluctuates between 0.2VDC and 0.6VDC. I'll try to hook the scope and see if it is pulsed.

I'm not sure how to check the inputs and outputs of the Darlington if I discard the optocoupler though.

We don’t know what kind of filter or EMC circuit is involved, might also be stray voltage picked up by the high impedance input of your meter.

Would that show steady, unchanging mains AC voltage?

[inse]

It would be best to probe everything with a scope, I guess the fan had speed control and thus is driven by some kind of PWM.
With stray voltages on high impedance inputs you never know but I would expect no stable readings.

[geppa.dee]

Hi Inse, sorry for the delay. Saturday night the forum was a bit unresponsive.

I've ended up soldering some "probing tails" to certain ponts of the board as my scope probes were inadequate.


This is a screenshot probing the input and output of the Darlington, that's involved in the fan control. Green is input (from the ATMEGA), blue is output (which goes to the optocoupler, through a 360Ω resistor).


Am I right in assuming that the output level (almost 1VDC) is too low to properly trigger the optocoupler?

[inse]

I am confused by your measurement screenshot.
The ULN is a open collector driver, so I would expect the inverted input signal on the output .
Check the entire chain ULN/driver/resistor/supply.

[geppa.dee]

The root cause of that confusion is, maybe, assuming that I know what I'm doing. Sadly, that's not really the case.
That screenshot comes from measurements where I connected (only one probe's) ground clip to what the ULN's datasheet (page 3) calls "Pin 8, E, Common emitter shared by all channels (typically tied to ground)"

When I tried the same measurement but connecting the ground clip to "Pin 9, COM, Common cathode node for flyback diodes (required for inductive loads)", I did see an inverted signal (on the output pin):


Also, if I connect the ground clip to the anode of the optocoupler input:

[inse]

The signal at the optocoupler does not look like what I expect.
The LED has a forward voltage of ~1.2V, so the 100mV you are showing make no sense to me.
The 500mV hum you are picking up is raising concerns.
I think there is no supply at the coupler, maybe the current limiting resistor is open or there is an interruption in the traces.

[geppa.dee]

The resistor that sits between the ULN output and the MOC input cathode has has "361" written on it and I measured it at 360Ω. I assume that means it's OK.
The optocoupler's anode goes to the AREF pin of the ATMEGA64A. It goes through a resistor that's marked "104" and that I measure at 99kΩ. Not sure about this one. 99 seems close to 104 but I can't apply the same reasoning as with the other resistor. Three orders of magnitude would need to be implied here. OTOH, other resistors marked "104" on this board measure roughly the same so...
I've checked continuity on all traces involved.

I was advised elsewhere to change all the aluminum caps on the board (3 of them) on suspicion that power to the micro-controller not being up to par. Will do that later today. Do you think that might make a difference.

Thank you very much for your help, Inse and sorry for the ocasional confusion. I'm far more at home debugging software than electronics.

[Ian.M]

Errr . . . the third digit of three digit SMD resistor codes is the multiplier, i.e. the number of zeros to append to the first two digits, so '104' is 10 0000 ohms, i.e. 100K, and '361' is indeed 360 ohms.  Similarly for four digit codes, append the zeros to the first three digits.

Codes with letters are different - R in the middle of a numeric code is the decimal point for small resistances, and there is no multiplier digit.  A trailing letter indicates an EIA-96 code.  The first two digits index into the list of EIA-96 preferred values and the letter gives the multiplier.  See http://www.marsport.org.uk/smd/res.htm

[geppa.dee]

Thank you Ian. Got it. My resistors are fine then. (I don't trust my measurement instruments/technique to less than 1%)

[inse]

If the anode of the optocoupler is really connected to 5V via 100k, you would never get sufficient drive current to light the LED.
The 360 Ohms would allow ca. 10mA through the diode at 5V, so the anode has to be tied to the supply directly.
Is 5V present at pin 1 of the MOC?
Is pin 2 of MOC connected to the resistor „361“?
Is the resistor connected to according pin of ULN?
Is pin 8 of ULN connected to GND?
This way we will figure out…

[geppa.dee]

Inse, thank you again for all the help. It definitely pushed me in the right direction.
I have now changed all electrolytics on the board and my fan motor works. I'll now mount it in the furnace and see what, if anything else, errs out.

Is 5V present at pin 1 of the MOC?

Now, referenced to the ATMEGA's ground, no. It's at 3V. Referenced to pin 8 of the ULN, yes.

Is pin 2 of MOC connected to the resistor „361“?

Yes.

Is the resistor connected to according pin of ULN?

Yes.

Is pin 8 of ULN connected to GND?

Not sure. It doesn't ring continuity with the ATEMA's pin 63 (GND) as seen in the datasheet. Also, see the answer above to the MOC pin 1.

[inse]

3.3V is also OK for the MOC, it would be around 5mA then which is what the datasheet recommends.
But the microcontroller and the ULN need to have a common ground.