Dimming 2 AC loads independently

Is it possible to dim 2 ac loads connected to a 2 channel AC dimmer module using 1 Arduino uno? Are there any libraries available besides RBDimmer.h to control multiple AC loads using TRIACS? Because it only allows one channel dimming. Everytime i try to dim my AC fan, my AC light goes haywire and startsflickering.

Everytime i try to dim my AC fan, my AC light goes haywire and startsflickering.

Please post a schematic of you project that exhibits this behaviour and the code that you are using

Is it possible to dim 2 ac loads connected to a 2 channel AC dimmer module using 1 Arduino uno ?

yes this is possible, but i don't know about any libraries that take care of the job for you. The process to dim an AC-load is not hugely complex though.
You detect zero-cross and depending on the system that you use you switch channel that needs to be dimmed on (or off) for the period of time that you want it within a 100hz cycle. If you have 2 channels you will need to decide beforehand which channel is going to be switched first.

The following is my code:

#include <RBDdimmer.h>                  //Dimmer Library
#include <AltSoftSerial.h>

AltSoftSerial BTSerial(8, 9); // RX, TX
/*****************INPUTS AND OUTPUTS************************/
#define zerocross  2 // for boards with CHANGEBLE input pins
#define PIR_Sensor 3
#define Fan 5
#define Light  6

dimmerLamp dimmer(Fan);
dimmerLamp dimmer1(Light);
unsigned int receiver;
boolean manual = false;
boolean Auto = false;
boolean PIR_State = false;
int outVal = 0;

void setup()
{
  BTSerial.begin(9600);
  Serial.begin(9600);
  dimmer.begin(TOGGLE_MODE, ON);
  dimmer1.begin(TOGGLE_MODE, ON); //dimmer initialisation: name.begin(MODE, STATE)
  dimmer1.setState(OFF);
  dimmer.setState(OFF);
}

void loop()
{

  if (BTSerial.available() > 0)
  {
    receiver = BTSerial.read();
    Serial.println(receiver);
    if (receiver == 'A')
    {
      manual = false;
      Auto = true;
    }
    else if (receiver == 'M')
    {
      Auto = false;
      manual = true;
    }
  }
  Manual();
}

void Manual ()
{
  if (manual == true)
  {
      outVal = map(receiver, 5, 225, 3, 75);
      if (outVal >= 30)
      {
        dimmer1.setState(ON);
        dimmer1.setPower(outVal); // name.setPower(0%-100%)
      }
      else
      {
        dimmer1.setState(OFF);

      }
      if(receiver==1)
      {
        dimmer.setState(ON);
        dimmer.setPower(50); //FAN at Half speed
      }
  }
}

the Robotdyn library can dim 50 dimmers and is written for many dimmers. it has timer interrupt every 12 microseconds (yes micros) to handle them

the TriacDimmer library can handle two dimmers with reasonable use of interrupts.

#include <AltSoftSerial.h>You can not use any swSerial in combination with zero-x detection, the disturbance to the detection interrupt is just to severe.
Personally i use a system where dimming values are received on hwSerial, then sorted in the background, and a timer interrupt firing every 16us. The more often you fire the interrupt the bigger the stress on the CPU, which leaves less time for any of the other stuff, but the more dimming levels you will have. I dim up to 14 pins, sorting takes about 300us if nothing else happens, copying sorted values takes a lot less time and happens just after zero-x detection.

Thank you. I'll try your suggestion. But i have two loads which may or may not operate at same levels. They require seperate firing angles.

But i have two loads which may or may not operate at same levels. They require seperate firing angles.

Yes of course, if it is only 2 you can probably just check both within the timer ISR.

"Everytime i try to dim my AC fan. . ."

Not a solution to your dilemma, but how has your fan control operation proven out - with RBdimmer.h (or however)?

Juraj:
the Robotdyn library can dim 50 dimmers and is written for many dimmers. it has timer interrupt every 12 microseconds (yes micros) to handle them

Right, so performance of the processor in other tasks you're trying to do at the same time may not be satisfactory.

Right, so performance of the processor in other tasks you're trying to do at the same time may not be satisfactory.

AC dimming is quite CPU intensive in general, even just the dependency on the interrupt driven zero-x detection is a limitation. The timer interrupt usually doesn't do much more than up the counter and compare it to the next moment to wait for. Not many other tasks can be performed, but a timer interrupt is the best solution. You can of course increase the time in between at the expense of resolution, if you want to do more in the Foreground, so to speak.

Deva_Rishi:
AC dimming is quite CPU intensive in general, even just the dependency on the interrupt driven zero-x detection is a limitation. The timer interrupt usually doesn’t do much more than up the counter and compare it to the next moment to wait for. Not many other tasks can be performed, but a timer interrupt is the best solution. You can of course increase the time in between at the expense of resolution, if you want to do more in the Foreground, so to speak.

12 microseconds timer interrupt occurs 833 times in one 50 Hz AC half wave (10 miiliseconds)

12 microseconds timer interrupt occurs 833 times in one 50 Hz AC half wave (10 miiliseconds)

Your math checks out, and given that during a part of that wave (say 10%) the voltage is so low that it is not going to matter much, that creates an active resolution of about 750. That will be quite smooth for most bulbs. As i said i use 16us so i have more CPU left over for other tasks, i tried bigger steps, but also since not all that much else needs to happen, whatever i had left may as well be used as resolution. Using a timer interrupt to fire check if the 'on' phase should start and the zero-x to reset the counter. That means that the level may fluctuate as much as it's length. If for instance you would be dimming LED's one should consider that the frequency is quite low and at very low dimming levels is visible. Most LED bulb's contain capacitors though which present a different problem, and even the bulbs that are dimmable with analog dimmers, tend to have a smaller 'active' range, which is quite bulb specific. I Had 8-bit input resolution and i wanted that as a minimum, and compromised at a 16us timer. 12us seems excessive, as far as i remember i came to find that 8us was beyond the limit. Then all that was happening was the ISR being fired all the time.

Deva_Rishi:
Your math checks out, and given that during a part of that wave (say 10%) the voltage is so low that it is not going to matter much, that creates an active resolution of about 750. That will be quite smooth for most bulbs. As i said i use 16us so i have more CPU left over for other tasks, i tried bigger steps, but also since not all that much else needs to happen, whatever i had left may as well be used as resolution. Using a timer interrupt to fire check if the 'on' phase should start and the zero-x to reset the counter. That means that the level may fluctuate as much as it's length. If for instance you would be dimming LED's one should consider that the frequency is quite low and at very low dimming levels is visible. Most LED bulb's contain capacitors though which present a different problem, and even the bulbs that are dimmable with analog dimmers, tend to have a smaller 'active' range, which is quite bulb specific. I Had 8-bit input resolution and i wanted that as a minimum, and compromised at a 16us timer. 12us seems excessive, as far as i remember i came to find that 8us was beyond the limit. Then all that was happening was the ISR being fired all the time.

how many dimmers do you control?

it is enough to set the next interrupt for the time of the next pulse.

how many dimmers do you control?

it is enough to set the next interrupt for the time of the next pulse.

I actually control 12 dimmers (nearly all the pins i had left after the hwSerial (0 & 1), the zero-x (pin 2) so pin 3 - 12, leave 13 for the LED, in theory i could use 16 pins), but you have to keep in mind that some of these dimmers may be at the same level, and setting up a timer interrupt takes time, and can not be done from inside the ISR. There is no need to over complicate the code to try and save CPU power for other tasks, when there are hardly any other tasks to perform.