SSR with PWM vs Digital Pot

I am trying to determine the best hardware solution to use to control a 220V 20A circuit. The control needs to be a variable control as I will seldom want full power. The two solutions I have come up with are: 1) Using a 220V 40A SSR with DC control that accepts 3.3V (most seem to be 3V-38V). Then use PWM to control the circuit. My concern with this approach is that my house lights will flicker due to the rapid on/off firing of the PWM. 2) Use a power controller (PSR-25) or variable SSR (Fotek SSR-40VA). Then instead of using PWM I would use a digital potentiometer to control the PSR-25/SSR-40VA. This seems a little more elegant but I haven't seen it talked about so I'm concerned I am missing something. This approach is also slightly more expensive but this is for personal use not a production run so I am not too concerned about that. Since I am brand new to hardware design I am looking for any advice on how to tackle this problem.

1) Using a 220V 40A SSR with DC control that accepts 3.3V (most seem to be 3V-38V). Then use PWM to control the circuit. My concern with this approach is that my house lights will flicker due to the rapid on/off firing of the PWM.

With the PWM frequency high enough (kHz range) the flickering will not be noticeable.

Thanks CW2. I was hoping that would be true but I have gotten some advice to the contrary. I will give a go with the SSR and PWM. I was also having trouble sourcing 220V digital pots. So I think that idea might not even work.

1) PWM is not used for controlling power mains loads because of the amount of power involved. It is much easier (and nearly universal) to use phase-angle control. That is, for example, how every light dimmer on the planet works. 2) Unfortunately for phase-angle control, virtually ALL solid-state relays (SSR) have built-in zero-crossing circuits in them which prevents phase-angle control (and PWM, for that matter). Your Fotek SSR-40VA, for example, has built-in zero-crossing switching. Now, switching at the zero-crossing is a VERY DESIRABLE trait for 98% of all SSR applications because it results in very "clean" operation with no switching hash. But it completely prevents fine-grain proportional control. Unless you are talking about something like a heating element, etc. There, you can simply control the proportion in steps of 16.667ms (for 60HZ) or 20ms (for 50Hz). But, as you say, NOT appropriate for light dimming, whether incandescent or LED or fluorescent, or whatever.

This particular application is to control a heater. I ordered an SSR and am testing it with a light bulb as a load. My testing is not going very well and I need some help.

I followed your advice and am controlling in increments of 16.7 ms. So I am passing a duration in 10 increments of 16.7 ms and the period is set to 167 ms. When I use my pot to increment from 1-10 I get totally random progressions. Some increments act as full power, some of the lower increments are higher than the upper increments. It all seems to be totally random. However, each increment does behave the same way each time.

I have tried many different multiples and the closest I got was using 200 ms period and 20 ms increments for the duration. But that gave me a nice progression for increments 0-5 (0 off and 5 full power) but then repeated the same thing for increments 6-10. That just doesn't make any sense to me.

I've pulled the relevant code out and put it below. Any guidance on how get predictable results is very much appreciated.

public class Program
{
static PWM heater = new PWM(Pins.GPIO_PIN_D6);
static AnalogInput mypot = new AnalogInput(Pins.GPIO_PIN_A0);

mypot.SetRange(0, 10);
Thread potthread = new Thread(new ThreadStart(PotThread));
potthread.Start();

private static void PotThread()
{
while (true)
{
const uint period = 166 * 1000 * 1000;
uint duration = (uint)(16.6 * mypot.Read() * 1000 * 1000);
heater.SetPulse(period, duration);
//heater.SetDutyCycle(100);
mylcd.Write(3, mypot.Read().ToString());
Debug.Print(duration.ToString() + "," + period.ToString());
Thread.Sleep(250);
}
}
}

This particular application is to control a heater. I ordered an SSR and am testing it with a light bulb as a load. My testing is not going very well and I need some help.

I followed your advice and am controlling in increments of 16.7 ms. So I am passing a duration in 10 increments of 16.7 ms and the period is set to 167 ms. When I use my pot to increment from 1-10 I get totally random progressions. Some increments act as full power, some of the lower increments are higher than the upper increments. It all seems to be totally random. However, each increment does behave the same way each time.

I have tried many different multiples and the closest I got was using 200 ms period and 20 ms increments for the duration. But that gave me a nice progression for increments 0-5 (0 off and 5 full power) but then repeated the same thing for increments 6-10. That just doesn't make any sense to me.

I've pulled the relevant code out and put it below. Any guidance on how get predictable results is very much appreciated.

public class Program
{
static PWM heater = new PWM(Pins.GPIO_PIN_D6);
static AnalogInput mypot = new AnalogInput(Pins.GPIO_PIN_A0);

mypot.SetRange(0, 10);
Thread potthread = new Thread(new ThreadStart(PotThread));
potthread.Start();

private static void PotThread()
{
while (true)
{
const uint period = 166 * 1000 * 1000;
uint duration = (uint)(16.6 * mypot.Read() * 1000 * 1000);
heater.SetPulse(period, duration);
//heater.SetDutyCycle(100);
mylcd.Write(3, mypot.Read().ToString());
Debug.Print(duration.ToString() + "," + period.ToString());
Thread.Sleep(250);
}
}
}

I'm probably totally wrong about how PWM works, but I think you would want to define the following lines before the while, and only update the LCD inside the while loop? Otherwise, I could see the PWM starting, the loop sleeping for 250ms, and then restarting itself, causing what may look like random behavior. Again, I haven't looked at this stuff yet, so I'm not sure if that is what is happening, just a guess.

const uint period = 166 * 1000 * 1000;
uint duration = (uint)(16.6 * mypot.Read() * 1000 * 1000);
heater.SetPulse(period, duration);
//heater.SetDutyCycle(100);

I've been doing more testing and I am fairly certain that either the Netduino or the SRR are not behaving to design. When I send a period of 10,000,000 and a duration of 100,000 I get almost full power (very slight light flicker). Then when I change the duration to 200,00 I get closer to 20% power. Then I send duration of 300,000 and I get full power (zero flicker and full brightness). I have changed my thread.sleep to 10000ms to avoid stomping on my own settings. The only way, that I know of, to determine the issue would be an oscilloscope, which I don't have. I have tried this on the following firmware: 4.1.0 (Update 6) RC2 4.1.1 ALPHA 7 I would like to try and the latest official firmware but can't find where to download it. Is anyone with an oscilloscope able to try this out and check readings? Has anyone else controlled PWM with this long of a period?

TriangeIL, Your post came in while I am typing up my latest investigations. The goal of the project is to take the input from the pot and have it control the duration of the pulse. So I need the constant readings and adjustment to the pulse duration. You are right I could pull the period constant out side of the while loop since there isn't much value in repetitively setting a constant. It would be great just to be able to set the PWM clock to 1 sec and then use duty cycle to control the percentage. Did the clock rates ever get exposed?

Edited by acetate, 27 February 2011 - 04:24 PM.

It would be great just to be able to set the PWM clock to 1 sec and then use duty cycle to control the percentage. Did the clock rates ever get exposed?

Microsoft is working up a new "common PWM object model" for .NET MF 4.2. We're planning on incorporating it into the v4.1.2 firmware and also exposing the ability to set the core PWM clock speed.

Chris

P.S.

I think what you actually want to do is set the PWM clock to something like 10us and control the duty cycle from there. If you set the clock speed to ~1MHz, you'd get <=1 pulses per second total.

BTW, have you tried to just use the DutyCycle parameter instead?

Chris

Any ideas why the above code is behaving so erratically? Seems like some conflict is happening in the clock.

Just in case their are others trying to get SSRs working with the Netduino. I talked with Chris and he helped me figure things out. The PWM clock in the Netduino is 16 bit. This means the longest allowed period is ~650 ms. I went back to basing short periods and started with 16.6 ms. That gave odd results. So I went with 17 ms period and that seems to work perfect. Not quite sure as SSRs have delays but it is working now so I am a happy camper. I linked above to the SSR I am using (Fotek SSR60-DA). They are only ~$25 on ebay for a 60A relay. Hopefully this helps out someone else as this was way more effort than I expected. But most things are. (I'm horrible at dev estimates). Important code snip is below: mypot.SetRange(0, 10); const uint period = (uint)(17 * 1000); // 17 ms uint duration = (uint)(mypot.Read() * 1.7 * 1000); //0-10 * 1.7ms heater.SetPulse(period, duration); Thanks for the help Chris!