Driver to drive?

[Bill Sloman]

On Wednesday, 10 December 2014 22:59:14 UTC+11, alb wrote:

Hi Tim, followed your suggestion I post on s.e.d. including the OP and
your reply for clarity. Please see at the bottom my answer to your
message.

<snip>

Valid point on the switching spikes! Sure we can sample when we expect
*not* to have spikes. What really drives the cutoff frequency? The
customer asked for 3KHz, but in the end I do not understand what is the
motivation.

High frequency current in the motor coils induce high frequency currents in the motor magnetic path, which warm the rotor (and decrease it's magnetic permeability) without doing anything useful.

I've never been sufficiently involved to need to run the numbers, but the different between magnetic core materials for different frequencies is that the higher bulk resistance materials are more suitable for higher frequency applications - laminated iron cores for 50/60Hz mains distribution, powder iron cores for higher frequencies, manganese-zinc ferrites for up to about 100kHz and the higher resistivity nickel-zinc ferrite for use up to about 10MHz.

The 3kHz limit could reflect the nature of the rotating component in the particular motor.

--
Bill Sloman, Sydney

 

[alb]

Hi Tim, followed your suggestion I post on s.e.d. including the OP and
your reply for clarity. Please see at the bottom my answer to your
message.

Tim Wescott <seemywebsite@myfooter.really> wrote:

On Tue, 09 Dec 2014 22:24:56 +0000, alb wrote:

Ok, here we go again with my lack of knowledge on digital control, so
pardon me if it looks I'm just waving hands in the blind (I'm not blind
but I'm italian and waving hands is pretty much a genetic feature).

I have a Controller block which provides the torque (T) value to be
applied to a BLDC motor. Now T needs to be converted into current (I)
for each of the three phases of the motor according to the actual
angular position, provided by an absolute encoder.

The chain of the Controller+Converter ia updating a new value at f KHz.
Now, within my period 1/f I need to *regulate* the current with an error
max of x% FSR and we thought about having a delta-sigma modulation
driving an half H-bridge (class D amplifier) with some lpf before goint
on the motor coil.

Now, how can I estimate the frequency for my regulation loop? and the
level of the quanitzer? Which are the parameters I need to play with?
Would I need to simulate the motor as well or can I leave with an open
loop analysis?

Any pointer is appreciated (even to books if you deem not worth
discussibg before I get a proper education on the subject!)

Al

First, this heavily intersects with analog: it would do better on s.e.d,
even if you do have to sort through political junk for your answer.

said, done.

Second, the motor has built-in low-pass filtering: it has the inductance
in the coils.

True.

The switching rate of your H-bridges should* be fast enough
that you can drive the motor coils directly. I would measure the current
in each coil and regulate it in closed loop, applying delta-sigma
modulation to the PWM duty cycle. That should work well enough -- but you
should run the numbers, and check.

That's the idea, measure current and regulate through the delta-sigma,
but can the output of the delta-sigma comparator be used directly to
drive the half H-bridge? It would be a PDM.

If for some reason you really need to knock down the switching-rate AC
going to the motor you can, but you'll seriously limit the bandwidth of
your current loop.

There are certain requirements on the amount of harmonics going onto the
motor and/or propagating through cables (related to EMI constraints).

By "estimate the frequency of my regulation loop" I assume you mean that
you want to figure out the bandwidth of your current loop?

There are two aspects:

1. should the sampling frequency simply be above Nyquist or does it need
to meet other criteria like precision?

2. Even considering a PWM (and not a PDM), what shall be the frequency
of it and what should be it's resolution?

#2 is cricital because we have an 80MHz clock going to our FPGA and we
are going to make the PWM out of it. A 40KHz PWM would only have 11bit
resolution, but wouldn't the current resolution be affected by both
parameters (frequency *and* resolution)?

Unless the
motor is really perverse, you should be able to close this at around
1/10th the switching rate to the H-bridges, assuming that you're sampling
the ADC synchronously with the H-bridges (which you want to do, so that
you can sample at a felicitous moment to avoid switching spikes).

Valid point on the switching spikes! Sure we can sample when we expect
*not* to have spikes. What really drives the cutoff frequency? The
customer asked for 3KHz, but in the end I do not understand what is the
motivation.

Al

 

[Klaus Kragelund]

On Wednesday, December 10, 2014 6:29:49 PM UTC+1, John Larkin wrote:

On 10 Dec 2014 11:59:09 GMT, al.basili@gmail.com (alb) wrote:

Hi Tim, followed your suggestion I post on s.e.d. including the OP and
your reply for clarity. Please see at the bottom my answer to your
message.

Tim Wescott <seemywebsite@myfooter.really> wrote:
On Tue, 09 Dec 2014 22:24:56 +0000, alb wrote:

Ok, here we go again with my lack of knowledge on digital control, so
pardon me if it looks I'm just waving hands in the blind (I'm not blind
but I'm italian and waving hands is pretty much a genetic feature).

I have a Controller block which provides the torque (T) value to be
applied to a BLDC motor. Now T needs to be converted into current (I)
for each of the three phases of the motor according to the actual
angular position, provided by an absolute encoder.

The chain of the Controller+Converter ia updating a new value at f KHz.
Now, within my period 1/f I need to *regulate* the current with an error
max of x% FSR and we thought about having a delta-sigma modulation
driving an half H-bridge (class D amplifier) with some lpf before goint
on the motor coil.

Now, how can I estimate the frequency for my regulation loop? and the
level of the quanitzer? Which are the parameters I need to play with?
Would I need to simulate the motor as well or can I leave with an open
loop analysis?

Any pointer is appreciated (even to books if you deem not worth
discussibg before I get a proper education on the subject!)

Al

First, this heavily intersects with analog: it would do better on s.e.d,
even if you do have to sort through political junk for your answer.

said, done.


Second, the motor has built-in low-pass filtering: it has the inductance
in the coils.

True.

The switching rate of your H-bridges should* be fast enough
that you can drive the motor coils directly. I would measure the current
in each coil and regulate it in closed loop, applying delta-sigma
modulation to the PWM duty cycle. That should work well enough -- but you
should run the numbers, and check.

That's the idea, measure current and regulate through the delta-sigma,
but can the output of the delta-sigma comparator be used directly to
drive the half H-bridge? It would be a PDM.

If for some reason you really need to knock down the switching-rate AC
going to the motor you can, but you'll seriously limit the bandwidth of
your current loop.

There are certain requirements on the amount of harmonics going onto the
motor and/or propagating through cables (related to EMI constraints).

By "estimate the frequency of my regulation loop" I assume you mean that
you want to figure out the bandwidth of your current loop?

There are two aspects:

1. should the sampling frequency simply be above Nyquist or does it need
to meet other criteria like precision?

2. Even considering a PWM (and not a PDM), what shall be the frequency
of it and what should be it's resolution?

#2 is cricital because we have an 80MHz clock going to our FPGA and we
are going to make the PWM out of it. A 40KHz PWM would only have 11bit
resolution, but wouldn't the current resolution be affected by both
parameters (frequency *and* resolution)?

Unless the
motor is really perverse, you should be able to close this at around
1/10th the switching rate to the H-bridges, assuming that you're sampling
the ADC synchronously with the H-bridges (which you want to do, so that
you can sample at a felicitous moment to avoid switching spikes).

Valid point on the switching spikes! Sure we can sample when we expect
*not* to have spikes. What really drives the cutoff frequency? The
customer asked for 3KHz, but in the end I do not understand what is the
motivation.

Al

PWM usually runs at 20KHz or above, to reduce acoustic noise from the
motor.

Delta-sigma will generally have more transitions per second than PWM,
hence higher switching losses. And d-s will have low frequency noise
components, which could cause acoustic hissing (whereas PWM has
whining) and, in a precision positioning app, maybe mechanical jitter.

Most uPs have PWM generators built-in.

Your FPGA can generate PWM or d-s. One trick is to generate PWM but
dither the LSB to increase resolution without increasing the switching
rate. That's equivalent to coarse PWM plus fine d-s.

Higher than 20kHz switching is going to add bearing currents, so you might have failures of the motor over time if you just increase the frequency

You also have more conducted EMI noise which combined with chaotic delta sigma can cause big problems when designing the EMI filter (both to high levels, but also triggering known resonances of the EMI filter/mains source)

Regards

Klaus

 

[alb]

Hi Bill,

Bill Sloman <bill.sloman@gmail.com> wrote:
[]

Valid point on the switching spikes! Sure we can sample when we expect
*not* to have spikes. What really drives the cutoff frequency? The
customer asked for 3KHz, but in the end I do not understand what is the
motivation.

High frequency current in the motor coils induce high frequency
currents in the motor magnetic path, which warm the rotor (and
decrease it's magnetic permeability) without doing anything useful.

Ok, now I understand. As long as the motor movement is still within the
3 KHz we want to cut on everything above to dump this extra effect that
only adds wear to the motor.

I've never been sufficiently involved to need to run the numbers, but
the different between magnetic core materials for different
frequencies is that the higher bulk resistance materials are more
suitable for higher frequency applications - laminated iron cores for
50/60Hz mains distribution, powder iron cores for higher frequencies,
manganese-zinc ferrites for up to about 100kHz and the higher
resistivity nickel-zinc ferrite for use up to about 10MHz.

The motor speed is 10 rad/s max and number of poles is 7 so we are not
talking about great speeds. It means ~7*1.6 electrical turns per second,
~10Hz. Why would we want to cut off that high?

The 3kHz limit could reflect the nature of the rotating component in
the particular motor.

See above. Even with margins we are a too big factor away from the
maximal speed. Am I wrong?

Al

 

[John Larkin]

On 10 Dec 2014 11:59:09 GMT, al.basili@gmail.com (alb) wrote:

Hi Tim, followed your suggestion I post on s.e.d. including the OP and
your reply for clarity. Please see at the bottom my answer to your
message.

Tim Wescott <seemywebsite@myfooter.really> wrote:
On Tue, 09 Dec 2014 22:24:56 +0000, alb wrote:

Ok, here we go again with my lack of knowledge on digital control, so
pardon me if it looks I'm just waving hands in the blind (I'm not blind
but I'm italian and waving hands is pretty much a genetic feature).

I have a Controller block which provides the torque (T) value to be
applied to a BLDC motor. Now T needs to be converted into current (I)
for each of the three phases of the motor according to the actual
angular position, provided by an absolute encoder.

The chain of the Controller+Converter ia updating a new value at f KHz.
Now, within my period 1/f I need to *regulate* the current with an error
max of x% FSR and we thought about having a delta-sigma modulation
driving an half H-bridge (class D amplifier) with some lpf before goint
on the motor coil.

Now, how can I estimate the frequency for my regulation loop? and the
level of the quanitzer? Which are the parameters I need to play with?
Would I need to simulate the motor as well or can I leave with an open
loop analysis?

Any pointer is appreciated (even to books if you deem not worth
discussibg before I get a proper education on the subject!)

Al

First, this heavily intersects with analog: it would do better on s.e.d,
even if you do have to sort through political junk for your answer.

said, done.


Second, the motor has built-in low-pass filtering: it has the inductance
in the coils.

True.

The switching rate of your H-bridges should* be fast enough
that you can drive the motor coils directly. I would measure the current
in each coil and regulate it in closed loop, applying delta-sigma
modulation to the PWM duty cycle. That should work well enough -- but you
should run the numbers, and check.

That's the idea, measure current and regulate through the delta-sigma,
but can the output of the delta-sigma comparator be used directly to
drive the half H-bridge? It would be a PDM.

If for some reason you really need to knock down the switching-rate AC
going to the motor you can, but you'll seriously limit the bandwidth of
your current loop.

There are certain requirements on the amount of harmonics going onto the
motor and/or propagating through cables (related to EMI constraints).

By "estimate the frequency of my regulation loop" I assume you mean that
you want to figure out the bandwidth of your current loop?

There are two aspects:

1. should the sampling frequency simply be above Nyquist or does it need
to meet other criteria like precision?

2. Even considering a PWM (and not a PDM), what shall be the frequency
of it and what should be it's resolution?

#2 is cricital because we have an 80MHz clock going to our FPGA and we
are going to make the PWM out of it. A 40KHz PWM would only have 11bit
resolution, but wouldn't the current resolution be affected by both
parameters (frequency *and* resolution)?

Unless the
motor is really perverse, you should be able to close this at around
1/10th the switching rate to the H-bridges, assuming that you're sampling
the ADC synchronously with the H-bridges (which you want to do, so that
you can sample at a felicitous moment to avoid switching spikes).

Valid point on the switching spikes! Sure we can sample when we expect
*not* to have spikes. What really drives the cutoff frequency? The
customer asked for 3KHz, but in the end I do not understand what is the
motivation.

Al

PWM usually runs at 20KHz or above, to reduce acoustic noise from the
motor.

Delta-sigma will generally have more transitions per second than PWM,
hence higher switching losses. And d-s will have low frequency noise
components, which could cause acoustic hissing (whereas PWM has
whining) and, in a precision positioning app, maybe mechanical jitter.

Most uPs have PWM generators built-in.

Your FPGA can generate PWM or d-s. One trick is to generate PWM but
dither the LSB to increase resolution without increasing the switching
rate. That's equivalent to coarse PWM plus fine d-s.


--

John Larkin Highland Technology, Inc
picosecond timing laser drivers and controllers

jlarkin att highlandtechnology dott com
http://www.highlandtechnology.com

 

[Tim Wescott]

On Wed, 10 Dec 2014 04:54:48 -0800, Bill Sloman wrote:

On Wednesday, 10 December 2014 22:59:14 UTC+11, alb wrote:
Hi Tim, followed your suggestion I post on s.e.d. including the OP and
your reply for clarity. Please see at the bottom my answer to your
message.

snip

Valid point on the switching spikes! Sure we can sample when we expect
*not* to have spikes. What really drives the cutoff frequency? The
customer asked for 3KHz, but in the end I do not understand what is the
motivation.

High frequency current in the motor coils induce high frequency currents
in the motor magnetic path, which warm the rotor (and decrease it's
magnetic permeability) without doing anything useful.

I've never been sufficiently involved to need to run the numbers, but
the different between magnetic core materials for different frequencies
is that the higher bulk resistance materials are more suitable for
higher frequency applications - laminated iron cores for 50/60Hz mains
distribution, powder iron cores for higher frequencies, manganese-zinc
ferrites for up to about 100kHz and the higher resistivity nickel-zinc
ferrite for use up to about 10MHz.

The 3kHz limit could reflect the nature of the rotating component in the
particular motor.

Be careful with your terminology. Does Al mean a 3kHz loop bandwidth, or
a 3kHz filter between drive and motor?

If the latter, I would expect some limitation on harmonic content, not
just something called a "cutoff".

--

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

 

[Tim Wescott]

On Wed, 10 Dec 2014 11:59:09 +0000, alb wrote:

Hi Tim, followed your suggestion I post on s.e.d. including the OP and
your reply for clarity. Please see at the bottom my answer to your
message.

Tim Wescott <seemywebsite@myfooter.really> wrote:
On Tue, 09 Dec 2014 22:24:56 +0000, alb wrote:

Ok, here we go again with my lack of knowledge on digital control, so
pardon me if it looks I'm just waving hands in the blind (I'm not
blind but I'm italian and waving hands is pretty much a genetic
feature).

I have a Controller block which provides the torque (T) value to be
applied to a BLDC motor. Now T needs to be converted into current (I)
for each of the three phases of the motor according to the actual
angular position, provided by an absolute encoder.

The chain of the Controller+Converter ia updating a new value at f
KHz. Now, within my period 1/f I need to *regulate* the current with
an error max of x% FSR and we thought about having a delta-sigma
modulation driving an half H-bridge (class D amplifier) with some lpf
before goint on the motor coil.

Now, how can I estimate the frequency for my regulation loop? and the
level of the quanitzer? Which are the parameters I need to play with?
Would I need to simulate the motor as well or can I leave with an open
loop analysis?

Any pointer is appreciated (even to books if you deem not worth
discussibg before I get a proper education on the subject!)

Al

First, this heavily intersects with analog: it would do better on
s.e.d, even if you do have to sort through political junk for your
answer.

said, done.


Second, the motor has built-in low-pass filtering: it has the
inductance in the coils.

True.

The switching rate of your H-bridges should* be fast enough that you
can drive the motor coils directly. I would measure the current in
each coil and regulate it in closed loop, applying delta-sigma
modulation to the PWM duty cycle. That should work well enough -- but
you should run the numbers, and check.

That's the idea, measure current and regulate through the delta-sigma,
but can the output of the delta-sigma comparator be used directly to
drive the half H-bridge? It would be a PDM.

Sigma-delta around the PWM command modulus, per this article. The short
story is that if the number you need to command the PWM is 23.4, you
command it with 23, 23, 25, 23, 25, repeat.

<http://www.embedded.com/design/configurable-systems/4006431/Sigma-delta-
techniques-extend-DAC-resolution>

If you've got more than 6 or 7 bits of resolution to the PWM generator,
noise in the system will probably swamp out any attempts to sigma-delta
the thing. Sometimes noise _is_ your friend.

If for some reason you really need to knock down the switching-rate AC
going to the motor you can, but you'll seriously limit the bandwidth of
your current loop.

There are certain requirements on the amount of harmonics going onto the
motor and/or propagating through cables (related to EMI constraints).

Then you need to pay attention to those. Do you just need to round off
the edges, or do you need to keep the PWM out?

By "estimate the frequency of my regulation loop" I assume you mean
that you want to figure out the bandwidth of your current loop?

There are two aspects:

1. should the sampling frequency simply be above Nyquist or does it need
to meet other criteria like precision?

If you are working on a control loop and Harry Nyquist knocks on the door,
escort him to the nearest Starbucks (or priest, given his birth date).
Then get on with your job.

You don't want to even _think_ in terms of the Nyquist limit when you're
working on control loops. Sample at least ten times faster than your
desired loop bandwidth, unless you have a superlatively well-behaved
plant. Higher precision loops need higher sampling rates.

Re-read my article on sampling:
<http://wescottdesign.com/articles/Sampling/sampling.pdf>

2. Even considering a PWM (and not a PDM), what shall be the frequency
of it and what should be it's resolution?

Over 20kHz if audible noise is an issue (over 25kHz or 30kHz if you want
to cover 99.9% of the population instead of just 99%).

Resolution should be enough that, after cleaning up the rest with sigma-
delta modulation, the residual noise does not make audible noise
(growling, hissing, or singing) and does not consume excess power.

#2 is cricital because we have an 80MHz clock going to our FPGA and we
are going to make the PWM out of it. A 40KHz PWM would only have 11bit
resolution, but wouldn't the current resolution be affected by both
parameters (frequency *and* resolution)?

If you have 11 bits of resolution into the motor, you are worrying
needlessly. The noise in your current sensing loop will swamp out the
bottom three to five bits anyway, so sigma-delta techniques would be a
waste of time (oh, if I'd read this earlier...).

Unless the motor is really perverse, you should be able to close this
at around 1/10th the switching rate to the H-bridges, assuming that
you're sampling the ADC synchronously with the H-bridges (which you
want to do, so that you can sample at a felicitous moment to avoid
switching spikes).

Valid point on the switching spikes! Sure we can sample when we expect
*not* to have spikes. What really drives the cutoff frequency? The
customer asked for 3KHz, but in the end I do not understand what is the
motivation.

Do you mean the current loop bandwidth? The driver for that is their
required control loop bandwidth, and how close they think they can push it
to the current loop bandwidth. They probably need between 300Hz and
1kHz. If they're smart they have some sort of a rider on their
specification about phase -- either a phase shift bandwidth, or a
requirement of 3kHz with a simple 1st-order response.

--

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

 

[Tim Wescott]

On Wed, 10 Dec 2014 12:28:45 -0600, Tim Wescott wrote:

On Wed, 10 Dec 2014 11:59:09 +0000, alb wrote:
Over 20kHz if audible noise is an issue (over 25kHz or 30kHz if you want
to cover 99.9% of the population instead of just 99%).

I forgot: also, it needs to be fast enough so that the triangular current
wave in the motor is small enough so that the I^2*R losses at "zero
current" (really zero average current) is acceptably small. For any
motor bigger than your big toe, 20kHz is probably enough.

As mentioned, iron losses in the motor may be a factor, but usually these
aren't an issue. If the motor mysteriously runs hot, then you can start
worrying about it.

--
www.wescottdesign.com

 

[Adrian Jansen]

On 10/12/2014 1:03 PM, moharrer@gmail.com wrote:

On Monday, July 21, 2014 10:50:45 AM UTC-7, Tim Wescott wrote:
On Mon, 21 Jul 2014 02:04:24 -0700, jrwalliker wrote:

On Monday, 25 November 1996 08:00:00 UTC, Thomas Pappano wrote:

Magnetrons are a specialized diode that operates in the influence of a
magnetic field and usually have integral resonant circuitry that
defines the frequency band they run in. They are used in pulsed
applications such as pulse radar and also in continuous wave
applications like microwave ovens.

Every microwave oven I have looked at (with an antenna and diode
detector) is pulsed. I think each pulse lasts around 100us with a
repetition rate of 100Hz (in the UK) at full power. In low-power modes
the pulse repetition rate is reduced but the peak power is unchanged.

The frequency is unstable, so as the turntable rotates with a slightly
asymmetric load the frequency drifts up and down (within the ISM band)

Can we hand out awards for most years elapsed between question and
answer? Nearly 18 years may not be a record, but it's pretty good, all
in all.

--

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

Tim,

I was going to say what you exactly said here: these answers are very interesting, damn good even after 18 years, no that the laws of physics has or the principles of K&M has changed since then. But I found them quite interesting. Thanks! I am working on a design concept and possibly an engineering spec on a magnetronic system for some special purpose heating applications. Would you know of a good reference for multi -ega Watt (dielectric) heating?

Thanks, Ali

My suspicious mind is wondering whether someone like Google is throwing
ancient threads into the newsgroups, either by accident, or design, just
to see what happens. I saw something similar on the aus.electronics
group recently too, where a query from 1996 about BWD oscilloscopes was
raised and discussed. Interesting that both that and this are from the
same year. Maybe related to the "Not Too Sure about Thunderbird" thread ?

--
Regards,

Adrian Jansen adrianjansen at internode dot on dot net
Note reply address is invalid, convert address above to machine form.

 

[Lasse Langwadt Christense]

Den onsdag den 10. december 2014 22.37.51 UTC+1 skrev Adrian Jansen:

On 10/12/2014 1:03 PM, moharrer@gmail.com wrote:
On Monday, July 21, 2014 10:50:45 AM UTC-7, Tim Wescott wrote:
On Mon, 21 Jul 2014 02:04:24 -0700, jrwalliker wrote:

On Monday, 25 November 1996 08:00:00 UTC, Thomas Pappano wrote:

Magnetrons are a specialized diode that operates in the influence of a
magnetic field and usually have integral resonant circuitry that
defines the frequency band they run in. They are used in pulsed
applications such as pulse radar and also in continuous wave
applications like microwave ovens.

Every microwave oven I have looked at (with an antenna and diode
detector) is pulsed. I think each pulse lasts around 100us with a
repetition rate of 100Hz (in the UK) at full power. In low-power modes
the pulse repetition rate is reduced but the peak power is unchanged.

The frequency is unstable, so as the turntable rotates with a slightly
asymmetric load the frequency drifts up and down (within the ISM band)

Can we hand out awards for most years elapsed between question and
answer? Nearly 18 years may not be a record, but it's pretty good, all
in all.

--

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

Tim,

I was going to say what you exactly said here: these answers are very interesting, damn good even after 18 years, no that the laws of physics has or the principles of K&M has changed since then. But I found them quite interesting. Thanks! I am working on a design concept and possibly an engineering spec on a magnetronic system for some special purpose heating applications. Would you know of a good reference for multi -ega Watt (dielectric) heating?

Thanks, Ali

My suspicious mind is wondering whether someone like Google is throwing
ancient threads into the newsgroups, either by accident, or design, just
to see what happens. I saw something similar on the aus.electronics
group recently too, where a query from 1996 about BWD oscilloscopes was
raised and discussed. Interesting that both that and this are from the
same year. Maybe related to the "Not Too Sure about Thunderbird" thread ?

not related, the thunderbird thread was a screwed up server

the ancient threads is just people that stumble over a post on google and
reply without looking at the date

-Lasse

 

[alb]

Hi Tim,

Tim Wescott <seemywebsite@myfooter.really> wrote:
[]

The 3kHz limit could reflect the nature of the rotating component in the
particular motor.

Be careful with your terminology. Does Al mean a 3kHz loop bandwidth, or
a 3kHz filter between drive and motor?

The 3KHz are on the loop bandwidth. Apologize if I wasn't clear from the
beginning.

If the latter, I would expect some limitation on harmonic content, not
just something called a "cutoff".

w.r.t. filtering the customer is specifying wants to *avoid* any source
of emission between 5KHz and 50KHz because this is where the scientific
signal will by laying.

When we talked about a 20KHz PWM in our first proposal they saw the risk
and changed the spec to impose a hard notch in that region. That is why
we are somehow obliged to go beyond that notch.

Al

 

[alb]

Hi John,

John Larkin <jlarkin@highlandtechnology.com> wrote:
[]

PWM usually runs at 20KHz or above, to reduce acoustic noise from the
motor.

acoustic noise is not a driving factor, we are flying in low earth
orbit, with 10E-5 mbar there's very little to propagate sound. Yet it is
possible that microvibrations might be effected (but is just a guess).

Delta-sigma will generally have more transitions per second than PWM,
hence higher switching losses. And d-s will have low frequency noise
components, which could cause acoustic hissing (whereas PWM has
whining) and, in a precision positioning app, maybe mechanical jitter.

I see the switching losses argument, yet I don't understand what is the
low frequency noise related to. But I believe you pretty much made it
clear that driving directly with d-s would consume more the driving
stage.

Most uPs have PWM generators built-in.

we do not have a uP. Software is banned from this system to reduce
development costs (software qualification for space equipment is a heavy
burden for this type of application).

Your FPGA can generate PWM or d-s. One trick is to generate PWM but
dither the LSB to increase resolution without increasing the switching
rate. That's equivalent to coarse PWM plus fine d-s.

If I understand correctly you mean dithering the already converted
signal, right? I guess that some level of noise would be there 'for
free', but preparing for the worse is never a bad idea.

But how do I choose the PWM frequency?

Al

 

[alb]

Hi Klaus,

Klaus Kragelund <klauskvik@hotmail.com> wrote:
[]

Higher than 20kHz switching is going to add bearing currents, so you
might have failures of the motor over time if you just increase the
frequency

But considering the requirement on EM emissions between 5KHz and 50KHz
I've no other choice (except to switch to an LDO) than going higher with
frequencies.

I've found this paper that illustrates nicely the effect:
http://www.google.com/url?sa=t&rct=j&q=bearing%20currents%20bldc&source=web&cd=5&ved=0CD0QFjAE&url=http%3A%2F%2Fwww.aemc.fr%2Fdownloads%2F200710291112-BearingCurrents.pdf&ei=klWJVPmONob4UL-fgrgH&usg=AFQjCNH96H41TKXNFo5QYwiuI0A_t8DqxA&bvm=bv.81456516,d.d24

The paper concentrates on EDM effects and mitigation techniques and it
is clear that frequency does not have an impact on the EDM effects, it's
rather the common mode voltage between rotor and stator that cause
arching and eventually bearing wearing.

You also have more conducted EMI noise which combined with chaotic
delta sigma can cause big problems when designing the EMI filter (both
to high levels, but also triggering known resonances of the EMI
filter/mains source)

Good point. For EMI reason it'd be simpler to get rid of a PWM frequency
than chasing the d-s variations.

Al

 

[John Larkin]

On 11 Dec 2014 08:23:23 GMT, al.basili@gmail.com (alb) wrote:

Hi John,

John Larkin <jlarkin@highlandtechnology.com> wrote:
[]
PWM usually runs at 20KHz or above, to reduce acoustic noise from the
motor.

acoustic noise is not a driving factor, we are flying in low earth
orbit, with 10E-5 mbar there's very little to propagate sound. Yet it is
possible that microvibrations might be effected (but is just a guess).

Delta-sigma will generally have more transitions per second than PWM,
hence higher switching losses. And d-s will have low frequency noise
components, which could cause acoustic hissing (whereas PWM has
whining) and, in a precision positioning app, maybe mechanical jitter.

I see the switching losses argument, yet I don't understand what is the
low frequency noise related to. But I believe you pretty much made it
clear that driving directly with d-s would consume more the driving
stage.


Most uPs have PWM generators built-in.

we do not have a uP. Software is banned from this system to reduce
development costs (software qualification for space equipment is a heavy
burden for this type of application).

It's really interesting that an FPGA, programmed in VHDL or Verilog,
is inherently more reliable than software programmed in, well, any
language. I've noticed that myself... far fewer bugs in FPGAs compared
to uP code. Finite state machines vs essentially infinite-state
machines. Makes sense.

Your FPGA can generate PWM or d-s. One trick is to generate PWM but
dither the LSB to increase resolution without increasing the switching
rate. That's equivalent to coarse PWM plus fine d-s.

If I understand correctly you mean dithering the already converted
signal, right? I guess that some level of noise would be there 'for
free', but preparing for the worse is never a bad idea.

But how do I choose the PWM frequency?

Al

The easiest way is to try it, and see what's most efficient. In
vacuum, you'll have cooling problems with the electronics and the
motor, so measure everything.

You can simulate the switcher in Spice, and get pretty close, but
motor losses are hard to simulate.


--

John Larkin Highland Technology, Inc
picosecond timing laser drivers and controllers

jlarkin att highlandtechnology dott com
http://www.highlandtechnology.com

 

[Klaus Kragelund]

On Thursday, December 11, 2014 9:48:52 AM UTC+1, alb wrote:

Hi Klaus,

Klaus Kragelund <klauskvik@hotmail.com> wrote:
[]

Higher than 20kHz switching is going to add bearing currents, so you
might have failures of the motor over time if you just increase the
frequency

But considering the requirement on EM emissions between 5KHz and 50KHz
I've no other choice (except to switch to an LDO) than going higher with
frequencies.

I've found this paper that illustrates nicely the effect:
http://www.google.com/url?sa=t&rct=j&q=bearing%20currents%20bldc&source=web&cd=5&ved=0CD0QFjAE&url=http%3A%2F%2Fwww.aemc.fr%2Fdownloads%2F200710291112-BearingCurrents.pdf&ei=klWJVPmONob4UL-fgrgH&usg=AFQjCNH96H41TKXNFo5QYwiuI0A_t8DqxA&bvm=bv.81456516,d.d24

The paper concentrates on EDM effects and mitigation techniques and it
is clear that frequency does not have an impact on the EDM effects, it's
rather the common mode voltage between rotor and stator that cause
arching and eventually bearing wearing.

It's the number of switching transitions to the motor that along with the size of the parasitic capacitance determines the bearing current. So yes, increasing the frequency should increase the bearing currents

The effect is multifold. One is a general charging of the rotor capacitance, which creates arching when the dielectrics break down (bearing current)

Cheers

Klaus

 

[Jan Panteltje]

On a sunny day (Thu, 11 Dec 2014 08:04:20 -0800) it happened John Larkin
<jlarkin@highlandtechnology.com> wrote in
<kpfj8at15ljjuu12fvj0sjkatoka43flbk@4ax.com>:

It's really interesting that an FPGA, programmed in VHDL or Verilog,
is inherently more reliable than software programmed in, well, any
language. I've noticed that myself... far fewer bugs in FPGAs compared
to uP code. Finite state machines vs essentially infinite-state
machines. Makes sense.

Maybe the FPGA code is simpler, or the programmer more concentrated.
I have very few reliability issues with software, if any.
It runs if it runs.
FPGAs may have timing issues, something a software writer do not normally
have to bother about as that has been taken care of by the processor vendor.

And many FPGAs have some processor core these days, so you make no sense.
What else is a processor than a state machine?

 

[John Larkin]

On Thu, 11 Dec 2014 16:41:13 GMT, Jan Panteltje <panteltje@yahoo.com>
wrote:

On a sunny day (Thu, 11 Dec 2014 08:04:20 -0800) it happened John Larkin
jlarkin@highlandtechnology.com> wrote in
kpfj8at15ljjuu12fvj0sjkatoka43flbk@4ax.com>:

It's really interesting that an FPGA, programmed in VHDL or Verilog,
is inherently more reliable than software programmed in, well, any
language. I've noticed that myself... far fewer bugs in FPGAs compared
to uP code. Finite state machines vs essentially infinite-state
machines. Makes sense.

Maybe the FPGA code is simpler, or the programmer more concentrated.
I have very few reliability issues with software, if any.
It runs if it runs.
FPGAs may have timing issues, something a software writer do not normally
have to bother about as that has been taken care of by the processor vendor.

And many FPGAs have some processor core these days, so you make no sense.
What else is a processor than a state machine?

The issue is the number of states, and specifically whether the
programmer understands and controls all the possible states. In a
sequentially executed program, the state is the bits of the program
counter concatenated with every bit of every flag and variable, which
can get to be a big number. Ironically, most programmers don't know
what "finite state machine" means. I teach them when I need to.

The number of states of even a modest program is probably more than
the number of electrons in the universe. Some of those paths will be
diabolically pathological.

In an FPGA, there are usually many small synchronous state machines
that interact in controlled ways. Usually, data does not affect
control states. States are visible and usually explicitely managed...
ALL of them. The biggest hazard in FPGA design is usually clock-domain
crossings. Pure timing problems are rare, what with modern FPGAs being
blindingly fast and the tools being pretty conservative about margins.

And FPGAs do not depend on operating systems and drivers and
undocumented peripherial controllers. Well, sometimes they do use a
mysterious PCIe block, or encrypted IP, but even those usually work.

Once you add a couple of ARM cores to an FPGA, naturally the ARMs
inherit all the bug potential of C procedural software... horrors of
interrupts, mutexes, threads, pipes, callbacks, logic mazes.

We write realtime uP software that usually has an explicit central
state machine to manage top-level operations. That seems to help.

C is a sequential, procedural language. VHDL is not. That seems to
make a lot of difference.


--

John Larkin Highland Technology, Inc
picosecond timing laser drivers and controllers

jlarkin att highlandtechnology dott com
http://www.highlandtechnology.com

 

[Jan Panteltje]

On a sunny day (Thu, 11 Dec 2014 09:28:21 -0800) it happened John Larkin
<jlarkin@highlandtechnology.com> wrote in
<8ljj8ap4qr5rpet7o64c1lanstkpe293ag@4ax.com>:

On Thu, 11 Dec 2014 16:41:13 GMT, Jan Panteltje <panteltje@yahoo.com
wrote:

On a sunny day (Thu, 11 Dec 2014 08:04:20 -0800) it happened John Larkin
jlarkin@highlandtechnology.com> wrote in
kpfj8at15ljjuu12fvj0sjkatoka43flbk@4ax.com>:

It's really interesting that an FPGA, programmed in VHDL or Verilog,
is inherently more reliable than software programmed in, well, any
language. I've noticed that myself... far fewer bugs in FPGAs compared
to uP code. Finite state machines vs essentially infinite-state
machines. Makes sense.

Maybe the FPGA code is simpler, or the programmer more concentrated.
I have very few reliability issues with software, if any.
It runs if it runs.
FPGAs may have timing issues, something a software writer do not normally
have to bother about as that has been taken care of by the processor vendor.

And many FPGAs have some processor core these days, so you make no sense.
What else is a processor than a state machine?

The issue is the number of states, and specifically whether the
programmer understands and controls all the possible states. In a
sequentially executed program, the state is the bits of the program
counter concatenated with every bit of every flag and variable, which
can get to be a big number. Ironically, most programmers don't know
what "finite state machine" means. I teach them when I need to.

The number of states of even a modest program is probably more than
the number of electrons in the universe. Some of those paths will be
diabolically pathological.

In an FPGA, there are usually many small synchronous state machines
that interact in controlled ways. Usually, data does not affect
control states. States are visible and usually explicitely managed...
ALL of them. The biggest hazard in FPGA design is usually clock-domain
crossings. Pure timing problems are rare, what with modern FPGAs being
blindingly fast and the tools being pretty conservative about margins.

And FPGAs do not depend on operating systems and drivers and
undocumented peripherial controllers. Well, sometimes they do use a
mysterious PCIe block, or encrypted IP, but even those usually work.

Once you add a couple of ARM cores to an FPGA, naturally the ARMs
inherit all the bug potential of C procedural software... horrors of
interrupts, mutexes, threads, pipes, callbacks, logic mazes.

We write realtime uP software that usually has an explicit central
state machine to manage top-level operations. That seems to help.

I run a real time DVB-S encoder on a Raspberry Pi that can do live video.
To get over the task switching delays I use a small hardware FIFO.
Does that mean it is less reliable than an FPGA?
No, it is more flexible, options can be added in minutes,
it is networked too, I can stream via from IP cameras on the LAN,
or content anywhere on earth (netcat is cool).
Does it ever crash? No, been running all day, it exited when it found an EOF on the video,
made while loop.
Sure you can make such a thing in FPGA (of course I investigated that possibility)
but your development time would go out the window, and making changes
and a net interface would require additional hardware, cost could go up exponentially,
did I mention the HDMI out, the USB facilities, etc.
And that is the reason many FPGAs now have some processor core.
If you are into those [state] machines opencores.org at one time had many simple processor cores,.
easy to make your own processor.
I dunno if opencores still is active ?
The Raspberry plus a few TTL - or whatever, interface chips, is cheaper than that FPGA board you have been advertising.
In fact there is an FPGA plug in for the Raspberry (have not used it) probably a better way to do things.
Then you can run your precious hardware thingy where it should be, and the programs on the Raspi.
http://www.bugblat.com/products/pif/

Anyways it is not one thing better than the other, you cannot compare apples and oranges.
Well you can, but does not make a lot of sense.

C is a sequential, procedural language. VHDL is not. That seems to
make a lot of difference.

Sometimes I really wonder if you did not mislay that clue.
You can write bad - and good code either way.

 

[Bill Sloman]

On Wednesday, 10 December 2014 22:59:14 UTC+11, alb wrote:

<snip>

Unless the
motor is really perverse, you should be able to close this at around
1/10th the switching rate to the H-bridges, assuming that you're sampling
the ADC synchronously with the H-bridges (which you want to do, so that
you can sample at a felicitous moment to avoid switching spikes).

Valid point on the switching spikes! Sure we can sample when we expect
*not* to have spikes. What really drives the cutoff frequency? The
customer asked for 3KHz, but in the end I do not understand what is the
motivation.

What hasn't been said so far, and probably needs to be said, is that people using PWM to drive motor coils tend to use the inductance of the motor coil to suppress the harmonic content of the pulse-width-modulated waveform.

This can be a bad idea. The parallel capacitance of motor coils tend to be quite high, so all the really high frequency content goes straight through the coil, and circulates around the leads to and from the motor - a larger radiating area than necessary.

And, as I've mentioned, the high permeability material defining the magnetic paths within the motor can have relatively high conductivity, so that the inductance of the coil can be shorted by the "shorted turn" in the magnetic path, so - once again - more high frequency current travels along the motor leads and radiates into the environment.

It's a good idea to put a passive low pass filter on the output of the PWM generating electronics. It's expensive - high current rated inductors aren't small or cheap - but it confines the high-frequency radiating components to the smallest possible area, and you can specify a high resistivity core material for the local inductor, minimising any "shorted turn" problems.

--
Bill Sloman, Sydney

 

[alb]

Hi Tim,

Tim Wescott <seemywebsite@myfooter.really> wrote:
[]

That's the idea, measure current and regulate through the delta-sigma,
but can the output of the delta-sigma comparator be used directly to
drive the half H-bridge? It would be a PDM.

Sigma-delta around the PWM command modulus, per this article. The short
story is that if the number you need to command the PWM is 23.4, you
command it with 23, 23, 25, 23, 25, repeat.

http://www.embedded.com/design/configurable-systems/4006431/Sigma-delta-
techniques-extend-DAC-resolution

So the duty cycle of a PWM would be regulated with a d-s which would
have, on average, a better resolution than just the PWM. Still I do not
see from the Fig. 6 of the above link, why a dithered DAC gives less DC
error than a straight DAC.

And still I do not see how do I relate my precision in the current
provided to the motor with the PWM frequency and the resolution of the
current sense and the d-s.

If you've got more than 6 or 7 bits of resolution to the PWM generator,
noise in the system will probably swamp out any attempts to sigma-delta
the thing. Sometimes noise _is_ your friend.

Lost you here. From the article above I understood that dithering would
help me to get a closer desired output even if the resolution of the DAC
is not extremely high. Considering that a higher resolution on my
current would potentially pick up 'free noise' from the load itself, why
would it swamp out the attempt to delta sigma the loop?

[]

There are certain requirements on the amount of harmonics going onto the
motor and/or propagating through cables (related to EMI constraints).

Then you need to pay attention to those. Do you just need to round off
the edges, or do you need to keep the PWM out?

Still don't have access to the EMI spec (due to ongoing changes!), but I
believe the notch would be so severe that the only practical solution
would be to keep the PWM out of the range 5KHz - 50 KHz. The
interferometer is measuring uV in that frequency range, the entire
scientific mission is running on that frequency range.

1. should the sampling frequency simply be above Nyquist or does it need
to meet other criteria like precision?

If you are working on a control loop and Harry Nyquist knocks on the door,
escort him to the nearest Starbucks (or priest, given his birth date).
Then get on with your job.

You don't want to even _think_ in terms of the Nyquist limit when you're
working on control loops. Sample at least ten times faster than your
desired loop bandwidth, unless you have a superlatively well-behaved
plant. Higher precision loops need higher sampling rates.

Where the factor 10 comes from? What makes me choose a higher/lower
frequency? Is it related to the 'uncertainties' of the plant that I want
to be able to *meausure* in order to control them?

Re-read my article on sampling:
http://wescottdesign.com/articles/Sampling/sampling.pdf

I like the 3500 pole order filter to get to a 40dB signal to alias
ratio, a hell of a filter Thanks for the pointer.

2. Even considering a PWM (and not a PDM), what shall be the frequency
of it and what should be it's resolution?

Over 20kHz if audible noise is an issue (over 25kHz or 30kHz if you want
to cover 99.9% of the population instead of just 99%).

audible noise may not be as important as microvibrations on the
platform.

Resolution should be enough that, after cleaning up the rest with sigma-
delta modulation, the residual noise does not make audible noise
(growling, hissing, or singing) and does not consume excess power.

Lost again. Which residual noise you're talkin about?

If you have 11 bits of resolution into the motor, you are worrying
needlessly. The noise in your current sensing loop will swamp out the
bottom three to five bits anyway, so sigma-delta techniques would be a
waste of time (oh, if I'd read this earlier...).

Is that because the noise replace our 'dithering' and therefore allows
for a increased resolution? The problem I have is that I'd like to have
a relationship between the desired precision *and* one or more
paramenters of my control loop.

Valid point on the switching spikes! Sure we can sample when we expect
*not* to have spikes. What really drives the cutoff frequency? The
customer asked for 3KHz, but in the end I do not understand what is the
motivation.

Do you mean the current loop bandwidth?

Yup.

The driver for that is their
required control loop bandwidth, and how close they think they can push it
to the current loop bandwidth.

So if the control loop bandwidth is higher than the current loop one it
would be limited by the latter, correct?

They probably need between 300Hz and
1kHz. If they're smart they have some sort of a rider on their
specification about phase -- either a phase shift bandwidth, or a
requirement of 3kHz with a simple 1st-order response.

Let's see how smart they are...new specs is coming under the Christmas
Tree, just to delight the family reunion!

Al