AC dimmer software development question

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
I have a dimmer that I'm working on using a Z8 microcontroller. The question
is: What is the best way to go about using one timer to control two separate
light circuits? I have a negitive crossing interrupt, and a down counter
timer that triggers an interrupt. I want the timer to control the firing
angle of both dimmers. I general concept would be helpful. thanks.

Las



Re: AC dimmer software development question
On Sun, 15 Feb 2004 05:39:57 -0500, the renowned "Las"

Quoted text here. Click to load it

One possibility, if you don't need too many brightness levels, is to
trigger an interrupt every, say 100 microseconds, then decide whether
to switch each output on within the ISR. I have no idea whether the
Z-8 is fast enough to make that feasible.

Best regards,
Spehro Pefhany
--
"it's the network..."                          "The Journey is the reward"
snipped-for-privacy@interlog.com             Info for manufacturers: http://www.trexon.com
We've slightly trimmed the long signature. Click to see the full one.
Re: AC dimmer software development question
Quoted text here. Click to load it

You can set the timer, at the zero crossing, for the first dimmer to
turn on (presumably for the brighter setting).  When you turn it on, set
the timer for the delta t between the first and second turn on.  

Thad

Re: AC dimmer software development question

Quoted text here. Click to load it
question
separate

Thanks Thad,

I finally figured out how to do it by picking up bits and pieces from around
the net.  As you suggested, I start the first timer from the first zero
crossing, but only after I sort which dimmer value is less than the other.
This way the timer will time out on the shortest value first then, with a
minor calculation, the timer will time-out for the second triac firing. The
second half of the AC cycle is software controlled by the timer calling
itself and repeating the values a few more minor calculations. The micro
only has two timers so I need to be able to keep one of them free for UART
communications. I should be a dimmer expert by the end of the project!
Thanks again for responding.

Eric



Re: AC dimmer software development question
You will be surprised to find how sensitive the eye is to detecting
flickering coming from the light as your interrupts vary.  If one
light stays the same value and the other is dimming past the point
where they exchange first/second values and also when receiving
serial data may both be noticable.
Steve

--
Steven D. Letkeman BSc.
President - Zanthic Technologies Inc.
We've slightly trimmed the long signature. Click to see the full one.
Re: AC dimmer software development question
On Mon, 16 Feb 2004 19:04:39 GMT, "Steve Letkeman"

Quoted text here. Click to load it

A problem with using a zero-crossing interrupt is that noise on the AC
line near the zero-crossing produces visible flickering. Turning on or
off a fan or fluorescent light on the same circuit is likely to glitch
the interrupt timing, and if you don't have sufficient hysteresis in
the interrupt input, you will get extra interrupts as well.
-- Jim McGinnis

Re: AC dimmer software development question
Quoted text here. Click to load it

I would take a different approach, because I consider continuously
resetting the timer interval to be a royal pain and a lovely place
for bugs to breed.  Set the timer for some suitable resolution.
Create a small stack, whose content is two fields:

  1.  ticks to next firing.
  2.  which device or devices to fire.

Now the only thing the interrupt has to do is decrement the tick
count on the top of stack.  When it hits zero, delete the stack
top item and execute the appropriate operations.

The stack need only be large enough to cover the next set of
scheduled operations.  It can be implemented out of parallel
arrays and an indexing stack pointer (you may need two, for stack
top and stack bottom, advancing modulo stacksize).  When a new
event needs to be scheduled things are very simple if it always
comes after already scheduled events, when its timer value needs
to be decremented by all the values earlier in the stack, and the
result placed at the end.  If it needs to fit between other events
some entries may have to be moved.

The system is easily expanded to handle other timed events.
Notice that no lock is now needed between the two dimmers, they
remain totally independant.

In your case item 2 above may be device/turnon or device/turnoff,
making it control 4 effective devices.

--
Chuck F ( snipped-for-privacy@yahoo.com) ( snipped-for-privacy@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
We've slightly trimmed the long signature. Click to see the full one.
Re: AC dimmer software development question

Quoted text here. Click to load it

A matter of taste. Personally, I consider it as good a method as any,
at least "a priori".

Quoted text here. Click to load it

What about the tick counts of the other items in the stack?

Quoted text here. Click to load it

When the top item expires, how many ticks till the new stack top is
supposed to go off? You have to account for the time since it was
placed on the stack.

Why not simply record the actual expiry tick count for each entry when
it's placed in the list? Just increment the tick counter in the
interrupt routine and compare to the first list item. You'll need to
deal with rollover, of course, but that's trivial enough.

Quoted text here. Click to load it

That's not a stack - it's an ordered circular list implemented as a
vector. A stack is a FIFO structure, where items can only be accessed
from one end, and it's almost certainly the wrong data structure for
this purpose.

Quoted text here. Click to load it

But that's not a legal operation for a stack. It's potentially slow,
as well, and you'll need to disable tick interrupts for the duration.

Quoted text here. Click to load it

Yep - it's a true list, and would probably be best implemented using
pointer chains, to avoid the overhead of shuffling a vector.

And, unless you have some rather exotic requirements, I believe it's
normally easier and more efficient to schedule events based on
absolute time rather than delta time.

--
  Max

Re: AC dimmer software development question
Quoted text here. Click to load it
... snip ...
Quoted text here. Click to load it

You are right about what it is - it evolved as I was typing :-)
The point of maintaining the deltas is that one expects timer
interrupts to be considerably more frequent than actions, and the
delta decrement requires no action most of the time.  If things
were based on actual time the interrupt would have to maintain a
timer on each tick, and then perform a comparison.  A safety
measure is that the decrement test can be <= 0, thus healing some
sort of nebulous fault.  The deltas may even be single bytes,
valuable in minimized embedded systems.

If the vector never holds more than 4 or 5 items, the shuffle cost
is negligible.  For the 2 channel dimmer, it should never hold
more than two, i.e. next action on each channel.

--
Chuck F ( snipped-for-privacy@yahoo.com) ( snipped-for-privacy@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
We've slightly trimmed the long signature. Click to see the full one.
Re: AC dimmer software development question

Quoted text here. Click to load it

I know how that goes ;o)

Quoted text here. Click to load it

For just two or three channels, it's not really even worth trying to
order the list - just decrement and test each delta value in turn. No
extra overhead, and easily accurate enough for phase-dimming of lamps.
I've used this technique with 8 channels quite succesfully, on
slooooow old 12-bit instruction PICs - incandescent lamps are
definitely not precision items, after all.


Incidentally, if you're continuously turning lamps on and off with
such a system (a stage light rig, for example), then you'll get vastly
better bulb life if you keep all lamps "pre-heated" at a low
duty-cycle rather than turning on from cold. Controlling the effective
slew-rate can also help in that respect. Both features are easy enough
to implement in an MCU, of course.

--
  Max

Re: AC dimmer software development question
Quoted text here. Click to load it

If a counter can be read while running, isn't it even
simpler to just start/reset it on the zero-crossing
and when the count gets to the desired value, trigger
the circuit?

Quoted text here. Click to load it

Re: AC dimmer software development question

Quoted text here. Click to load it

Yes, but:

1) That implies not using a clock tick interrupt, but a simple
infinite loop instead. That can lead to difficulties when, say,
reading commands from a serial port, since that inevitably leads to
timing irregularities that ca cause noticeable flickering.

2) On many MCUs, a "decrement and skip" or similar is a single
instruction, while a compare requires a subtraction followed by a
conditional test - two instructions. On a PIC (14-bit), for instance,
the tick code for 3 lamps would look something like:

 movlw b'111
 decfsz phase0
 andlw b'110
 decfsz phase1
 andlw b'101
 decfsz phase0
 andlw b'011
 movwf portb

--
  Max

Re: AC dimmer software development question

Quoted text here. Click to load it

Doh! Should be:
 decfsz phase2

Quoted text here. Click to load it

--
  Max

Re: AC dimmer software development question
Quoted text here. Click to load it
... snip ...
Quoted text here. Click to load it

Reset it to what?  What delays ensued between the arrival at zero
and the actual handling in the interrupt?  Most counter systems
can be set up to self recycle, while raising an interrupt, so that
no errors accumulate.  Even adding a delta value to the present
content has various possibilities of error.  I have been bitten by
this sort of thing long long ago, and found means of avoidance.

--
Chuck F ( snipped-for-privacy@yahoo.com) ( snipped-for-privacy@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
We've slightly trimmed the long signature. Click to see the full one.
Re: AC dimmer software development question
Quoted text here. Click to load it

How would I know?  The problem statement is a little
skimpy on details...

Quoted text here. Click to load it

Again, details are missing...

On this one, I'd presume the latency to be nearly constant,
whatever it is.

Quoted text here. Click to load it

What errors can accumulate when synched to the power line?
You're starting anew with each cycle or half-cycle.

Quoted text here. Click to load it

Like the RTC on PC's?

Re: AC dimmer software development question

Quoted text here. Click to load it

So instead of taking 4 timer interrupts per mains cycle you take say 200 to
get only 100 (non-linear) brightness steps.

I have done dual channel PWM generation at 400Hz with 1 in 2500 resolution
on a 12MHz 8051. The only problems are a few us of jitter from interrupt
latencies and the inability to have edges on both channels closer together
than about 20us. If it had been important the almost coincident edges
problem could have been detected and handled with a delay loop in the
interrupt handler.



Re: AC dimmer software development question
Quoted text here. Click to load it

All you have done is to move the timer from hardware into software, and
made it more complex.  Unless you suspect you have a problem in the
hardware with changing the timer setting, why would you want to
complicate things this way?  


BTW, if EMI is an issue, rather than use a timer at all, the dimmers
should be controlled by turning them on *and* off at zero crossings.
You can select how many half cycles you wish to have them on vs. off to
control the dimming.  Of course you will need an interrupt at both
negative and positive zero crossings :)  Otherwise you will have to
count full cycles rather than halves.  

The advantage of this is that your circuit switches the current when it
is nearly zero anyway.  So there is much less EMI generated.  

--

Rick "rickman" Collins

snipped-for-privacy@XYarius.com
We've slightly trimmed the long signature. Click to see the full one.
Re: AC dimmer software development question
Quoted text here. Click to load it

That is not an option. At 50Hz/60Hz there's no way that will work without
significant flicker. Moreover the filter needed to alleviated the EMI
concerns is small and straighforward

Cheers

Klaus



Re: AC dimmer software development question
Quoted text here. Click to load it
... snip ...
Quoted text here. Click to load it

Drive things from unfiltered FW rectified AC, i.e. pulses, through
SCRs.  Now the thing to control is the turn-on point with respect
to the AC input zero crossings.  The SCRs automatically turn off
at zero current (which may not be the zero crossing input point
for inductive loads).  I have built model train controllers around
this, using the back EMF during the off cycle for feedback, and
could run things at an extremely slow rate with no cogging.
Nothing gets hot either.

--
Chuck F ( snipped-for-privacy@yahoo.com) ( snipped-for-privacy@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
We've slightly trimmed the long signature. Click to see the full one.
Re: AC dimmer software development question
Quoted text here. Click to load it

A lamp is excited by 120 Hz, not 60 (power waveform vs. voltage) and the
filament of a typical light bulb does not go out during cycles.  So
there is considerable room for pulsing half cycles.  The brightness of
an incandescent lamp is not linearly proportional to the power that is
applied, so you need fine adjustment, but not all the way to zero
power.  Instead if you experiment, you will find that you can provide
full range dimming with a much smaller range of power.  

I have seen dimmers implemented this way when minimum RFI is important.  

--

Rick "rickman" Collins

snipped-for-privacy@XYarius.com
We've slightly trimmed the long signature. Click to see the full one.

Site Timeline