Universal motor control, best solution?

[NikWing]

hehe, well, I bet everything could be better if I could use more parts, but this would increase the project costs which is something I have to avoid here

The zerocrossing triggers an interrupt of the microcontroller
using the potentiometer (ADC value) I can calculate the ontime and offtime, IOW the time it takes after the ZC triggering until the triac is triggered
so right now I have a µC controlled dimmer and it's working quite good.

another problem is, that the peak from the optocoupler is quite wide.
I powered it with an old sinus generator while testing the code and it didn't work as nicely as I thought. So I tried it with 110V and up to 250V (along with the resistors of course) and the peaks looked better.

schematics are at work but I didn't chance much about them yet, but I will post an update later (I'm currently not at work)
I don't have screenshots yet, but I try to take some later

my next problem is that I can't use the code for the dimmer to control the motor because there's no feedback from the RPM counter yet.
That means I can't control the on/off-time of the triac with the potentiometer, I have to let the µC control it by comparing a defined RPM value (set with the potentiometer) and the value from the feedback counter.
I'm currently looking into the arduino PID controller library but it's totally new to me and doesn't work as expected yet :/

here's the code for the phase control:
http://playground.arduino.cc/Code/ACPhaseControl
I removed the verbose lines and altered the serial connection value input to be able to set this value using the variable resistor on the ADC port

[NikWing]

my current schematics:

[NikWing]

since my DSO is disassembled right now I have to take screenshots of my workplace DSO, using my smartphone.

sine_trigger: shows the mains/line sine and the peaks is the trigger signal for MOC3023

sine_zero1: shows mains/line sine and the H11AA1 output that's fed to the µC
you can see that the sine is not smooth (I connected a bulb to the triac for testing), without the 2µF/275VAC cap it looks wayyy worse that that, not much difference between 1µ and 2µ though ...

sine_zero2: same as sine_zero1, but zoomed in a little bit
you can see that the zero crossing trigger signal is kinda "wide"
I don't know how to reduce the width, maybe it's possible using an OPV and set a voltage threshold, no idea
a cheaper solution would be better in my case

[temmi_hoo]

Waveforms are looking nice and I like how you've made the schematic modular. Good work here. The real line voltage actually does look just that horrible.

As to why the trigger signal from zero crossing detector circuit is somewhat wide, its pretty normal. This is exactly why I suggested using some sort of phase locked loop. That can be implemented in software using just the kind of hardware you already implemented.

One possible solution that might not work all too well is just to see how well the rising edge of trigger signal (pretty analog at this point) correlates to actual zc point and just wait that amount. This wait period can also be automatically generated in software: measure the length of the trigger signal and divide that by two.

Now as individual sine periods can deviate from the mean quite a bit for many reasons, the latter method needs averaging from some reasonable amount of samples. Both methods will have problems hitting the exact zc moment of all individual cycles, as some cycles are somewhat far from the norm. Statistically these are pretty rare and both methods should turn out to have pretty good results.

Nice thing about both methods is that they require only software as you've modernly minimized the amount of analog processing and the component count is small.

This trend of pushing software outer and outer to minimal modules of barest hardware seems to be the norm and software guys are nowadays waddling knee deep in problem areas previously left to EE wizzards. I'm trying to fit in the midgård teaching software people how hardware works and hardware people how software works so they could collaborate nicely without hammers.

[NikWing]

@temmi_hoo: hmmmm, you say I shouldn't trigger using an interrupt but do it with a software timer?

I'm really not experienced with c++ or whatever Arduino IDE bases on, I'm experimenting a lot at the moment

for testing purposes I added a comparator after the H11AA1 to make the output peak "thinner", this works quite well
but the next problem that occures is the distortion of the sinus, it affects the output of the H11AA1, depending on the reference voltage of the comparator it either triggers twice or it misses a zero crossing.
Depending on the moment the triac is triggered, it either adds a second peak to the zero crossing detection or it lowers the correct peak so that the comparator doesn't see it ...

[temmi_hoo]

@temmi_hoo: hmmmm, you say I shouldn't trigger using an interrupt but do it with a software timer?

Yes, I'm saying exactly that. There are several different methods on doing this.

I'm really not experienced with c++ or whatever Arduino IDE bases on, I'm experimenting a lot at the moment

That makes it a lot harder.

You might want to try out continuing the interrupt model but adding a small variable delay in there. The correct amount of delay can then be iteratively tried out or perhaps some sort of simple averaging of the last 100 cycles data could be reasonable...

for testing purposes I added a comparator after the H11AA1 to make the output peak "thinner", this works quite well
but the next problem that occures is the distortion of the sinus, it affects the output of the H11AA1, depending on the reference voltage of the comparator it either triggers twice or it misses a zero crossing.
Depending on the moment the triac is triggered, it either adds a second peak to the zero crossing detection or it lowers the correct peak so that the comparator doesn't see it ...

I think the H11AA1 is now just perfect as it is, without adding any comparators or anything. You just need a way to find the _middle_ of its output pulse.

[NikWing]

ok, I see
with my hardware solution I currently don't switch it on full time (10000 µs), there's always a little delay right now (about 1100 µs without and 800 µs with comparator)
but like I said, the distortion of the mains sine that occurs when the triac is triggered in the area that also triggers/activates the H11AA1 can cause problems
(I don't have any screenshot handy atm)

[NikWing]

experimented some more ...
the comparator makes the signal smoother and less "jumpy"
I avoid the triac distortion close to the zero crossing by not triggering it in this area

don't know how this will affect the circuit's behavior when a motor is connected later (don't have that thing yet, so I use a bulb ... lol)

the VIPer12A seems to be a little bitchy on voltage peaks
a varistor probably will prevent that
I caused peaks with the 2µ2 cap that filters most of the triac distortion by connecting and disconnecting it (while the circuit was "hot" of course)
another 4 parts also blew up this moment ... (the 2 Zener diodes, the 10R fuse resistor and the diode right after it)

well, waiting for the motor to arrive to find out how the circuit will handle it

[granz]

I know you've made nice progress with phase angle control, and I don't know what you application is, but you might want to check this out:

http://www.eetimes.com/document.asp?doc_id=1278677&page_number=2

If you want more low-speed torque then DC->PWM is what you want over phase-angle control.  I have a bench grinder with phase-angle speed control and I also have a small vertical milling machine with DC->PWM control.  There is no torque at low speed with the phase-angle control, whereas the DC->PWM system is still usable.  The article has some nice graphs on the second page.

Just thought I'd throw that out there.

[temmi_hoo]

experimented some more ...
the comparator makes the signal smoother and less "jumpy"
I avoid the triac distortion close to the zero crossing by not triggering it in this area

You could also make the software not care about zero crossing interrupt events happening within 5ms of a zero crossing event. There are several ways to do that and here is one:

Set up a timer counter for the timing of zero crossing signals. Do not set up any interrupts on this one.

Set up the zero crossing interrupt routine to
- first check how long the timer has been running since it was last triggered
- determine if the zc interrupt is false or real
- do the normal zero crossing interrupt routine things you want
- reset the zero crossing timer and trigger its counting

Another way would be:

Set up a counter to measure dead safe time. Do not set up any interrupts on this one.

Set up the zc interrupt pretty much as you have done before, but its first act should be to determine if a safe period is set, in which case the interrupt routine should do nothing.

The triac triggering routine should set and trigger the dead time safe period timer counter.


There are still more ways, but the generic idea is that your software needs to somehow separate a zc indicator event as either a real zc event or a false one. The real events occur at pretty much 10ms intervals for 50Hz.

[temmi_hoo]

If you want more low-speed torque then DC->PWM is what you want over phase-angle control.  I have a bench grinder with phase-angle speed control and I also have a small vertical milling machine with DC->PWM control.  There is no torque at low speed with the phase-angle control, whereas the DC->PWM system is still usable.  The article has some nice graphs on the second page.

You know, this was the grand scheme I was suggesting at first intuitively, mostly because it is more familiar to me. I totally forgot that a DC middle circuit would give you more low end torque. Also it does not need any kind of feedback or sensing of zc events or anything.

The situation with controlling low end torque might be helped a lot with just mapping the control input to a logarhitmic curve or S-shaped curve or something like that, so that the triac system would appear as more linear.

Either of these _can_ be coupled to a shaft speed sensor and programmed as a PID so as to get pretty good reacting dynamics even for low speeds.

[NikWing]

hmhmmmm
alright, I'll also try the PWM method!

I just want to ask again: the motor is a 230VAC motor and I can't change this fact
if I run the PWM solution on 110V, will there be any big difference for the motor?
230VAC rectified to 325V, 110VAC rectified to 155V and the motor can handle the high DC voltage?

the PWM solution probably will be way smoother than the zc version.

[oldway]

Try the solution : triac phase-angle control + rectifier bridge to feed the motor with dc current.
This give a high torque at low speed.

[temmi_hoo]

If the motor has brushes and runs on AC, it will run just as well on DC.

[oldway]

Behaviour is far different because in ac, current is limited by impedance (resistance + inductance) and in dc, only by resistance.
For the same control angle, you will have more torque in dc than in ac.

[granz]

If you want more low-speed torque then DC->PWM is what you want over phase-angle control.  I have a bench grinder with phase-angle speed control and I also have a small vertical milling machine with DC->PWM control.  There is no torque at low speed with the phase-angle control, whereas the DC->PWM system is still usable.  The article has some nice graphs on the second page.

The situation with controlling low end torque might be helped a lot with just mapping the control input to a logarhitmic curve or S-shaped curve or something like that, so that the triac system would appear as more linear.

Either of these _can_ be coupled to a shaft speed sensor and programmed as a PID so as to get pretty good reacting dynamics even for low speeds.

I think you're exactly right about mapping the control input to a different curve to help with low-end torque.  I sort-of tried this once with a phase-angle control system, but I was never happy with the results and low-speed wasn't very important so I moved on to other things.

Implementing feedback and a PID loop would be a great idea for sure, but I'm not sure NikWing needs the extra complexity?  I've been wanting such a system on my little milling machine, but haven't ever gotten around to it because it involves tossing out the oem controller and building my own plus figuring out the best way to mount a tach etc.  It seems like it might be better to just go to a BLDC motor if all that work is involved.

[NikWing]

I tried the arduino PID lib already
maybe I set something wrong (though there's not much to set) but it didn't work as good as I thought
it did output some values when there was little to no difference between nominal and actual value
so I threw it out again and wrote a map routine that works way better than the PID

so you suggest that I use a triac also for DC? no FET?
I thought the triac switches on when it get's a pulse and switches off at the zero crossing, but there's no zero crossing in DC, is it?

but I didn't look at DC controlled schematics for a while now, will do that tomorrow I think

[temmi_hoo]

I tried the arduino PID lib already
maybe I set something wrong (though there's not much to set) but it didn't work as good as I thought
it did output some values when there was little to no difference between nominal and actual value
so I threw it out again and wrote a map routine that works way better than the PID

The PID needs speed feedback from the motor or actuator that is driven. Also, the system should work quite fine just as is without any feedback at all and the PID can basically make it from that point on more solid and have better dynamics.

Did you try about the zc-safe period trick for software? How do the waveforms look like? You could make a gpio pin indicate the safe period and track that too with the scope and see how the software's idea of when a real zc event is likely correlates with reality.

so you suggest that I use a triac also for DC? no FET?
I thought the triac switches on when it get's a pulse and switches off at the zero crossing, but there's no zero crossing in DC, is it?

but I didn't look at DC controlled schematics for a while now, will do that tomorrow I think

The DC circuit does not work with triacs at all but has a H bridge of FETS. There is another thread discussing a nice H bridge driver for fets, which would be a good read. DC control will be just driving the bridge with pwm. There are several different methods on that and discussion is lively on the other thread.

Now, you doing both of these will make you that much better a designer.

[granz]

I tried the arduino PID lib already
maybe I set something wrong (though there's not much to set) but it didn't work as good as I thought
it did output some values when there was little to no difference between nominal and actual value
so I threw it out again and wrote a map routine that works way better than the PID

so you suggest that I use a triac also for DC? no FET?
I thought the triac switches on when it get's a pulse and switches off at the zero crossing, but there's no zero crossing in DC, is it?

but I didn't look at DC controlled schematics for a while now, will do that tomorrow I think

So you have already mounted your hall sensor on the motor so that you have speed sensing (aka tach)?  If so that can really help you if you want to keep a constant speed with varying mechanical loads.

Since you already have the phase-angle solution setup, your could first try it like this: triac --> bridge rectifer --> motor, as oldway suggested.  That is one way of applying pulsed DC to your motor.  I have zero experience with that technique, but if the low-speed torque is good enough for your purposes it's definitely the simplest solution (beyond triac with no bridge rectifier).

The other option would be bridge rectifier --> filter --> PWM with MOSFET.  Typically you'd want a high enough frequency to avoid audible noise, 20 - 30 kHz.

[granz]

Now, you doing both of these will make you that much better a designer.

  It's good to try both techniques, then you know the advantages/disadvantages or both.  Sometimes there is no reason to bother with a complicated solution when a simpler solution is more than enough for your needs (and may be cheaper etc.).

[NikWing]

that's true
I'll try and see

and yes, I thought about a H-bridge, but the mention of triac puzzled me a bit, I guess I misunderstood it before

I don't have a motor yet but simulate the feedback with a signal generator

I wasn't able to try any software changes yet, I can't work every day on it ^^;

[granz]

that's true
I'll try and see

and yes, I thought about a H-bridge, but the mention of triac puzzled me a bit, I guess I misunderstood it before

I don't have a motor yet but simulate the feedback with a signal generator

I wasn't able to try any software changes yet, I can't work every day on it ^^;

Actually, if you have one of the "Universal" motors (like those found in many power tools such as Dremels), it will only spin in one direction so an H-bridge isn't needed or helpful at all.  If you want to go forward and backward you need a regular brushed DC motor (one that won't work with AC applied).  Try connecting either polarity to the universal motor and you'll see that it always goes the same way.

So, you don't need an h-bridge, just a MOSFET to ground pulling current through the motor.

After thinking about it a bit, I said before that the triac solution is simpler, but since you have a microcontroller the PWM solution might actually be simpler, because you don't have to detect the zero-cross at all, just control the duty cycle.  The triac solution is simpler if you have no uC, because you can just use a few passive components and a potentiometer for the speed control.

[NikWing]

ok
yeah, the zc is the dirty thing here
beside that it's also distorted by the triac ... it works, but it's dirty

some time ago I speed controlled a DC motor using pwm (IIRC I used a 555) and the L297/298 /drivers/controllers
but this time I have high voltage and not just 24V or something like that (and now it's not for my own use)
(and I made a fan control using mega8 and pwm and this runs with just 12V and no big power)

I guess any low RDSon mosfet that can handle the voltage will be sufficient?
and I  have to add a big supressor diode near the motor connector.
and I also need an optocoupler and a mosfet driver between µC and mosfet, right?

(like I said, I didn't yet search any schematics hehe)

[temmi_hoo]

Oh silly me oh

The motor, being an universal motor, will always turn in the same direction, so just a single fet is enough to control it.

Your DC solution would then be: AC -> rectifier bridge -> DC bus with low esr caps -> motor -> pwm fet

I'm intentionally writing it that way since everybody will be thinking about the positive side first. Using a single fet, it is much better to use a N-mosfet than P-mosfet and N-fets act better under the load than above the load.

Select a nice hefty N-type fet with low Rdson and low Qgs and then apply a gate drive circuit to actually drive it fully on, using something like this: http://cds.linear.com/docs/en/datasheet/44405fb.pdf

Of course, there are fets that are supposed to turn on with a nice logic high level but their Qgs is worse and they're not fully on at Vgs=5V, rather they're fully on at Vgs=10V or so.

Oh and do try adding a rectifier bridge and filter cap after the triac solution and please post the resulting scope shots in here, that's something I've never seen done and it seems interesting midway solution.

[oldway]

Oh and do try adding a rectifier bridge and filter cap after the triac solution and please post the resulting scope shots in here, that's something I've never seen done and it seems interesting midway solution.

Add only a rectifier bridge, without filter cap