Overcoming FEMM limitations

Posted on May 29, 2009

28



Just like any other software, FEMM has its limitations.

I’ve been talking a lot to David Meeker, the author, who has been extremely kind and thoughtful in guiding me not only in the program’s usage but also in general electromagnetic modeling, while trying to sort out the modeling mess I’ve put myself and my colleague into with this project. 🙂

As it stands, we have a problem: FEMM only works with a single frequency at a time. This means that permanent magnets (freq=0Hz) and electromagnets (freq>0Hz) cannot simulate together. That’s a big downer. It means we can’t draw the magnets and the coils and set a current frequency and get the corresponding torque – FEMM will ignore the permanent magnet’s fields and give us the torque from only the AC-induced field.

But perhaps this is a good thing. This “problem” is just an aspect of a greater, deeper problem: time modeling in the finite element method (f.e.m). You see, time is usually only present in f.e.m. in the shape of the sinusoidal E.M. waves: current, field, and all their related partners. There is no way to describe (let alone simulate) mechanical movement between parts of the design. I don’t know if other programs have this solved, but I can guess how difficult it would be to program it into FEMM. Anyway, it would be incorrect to expect good results even if FEMM did do the math with the DC and AC components, because a static PM is not the same as a moving PM.

So we are left without a way to simulate the magnet’s rotation around the stator, which means the machine is always static and we can’t evaluate all the other points of operation that involve speed. If we turn on the frequency, we lose the magnets and so the major source of torque; we turn it off, and we lose the core losses and the counter-electromotive force. And combining the two simulations is not correct, because there are always saturated areas where the flux cannot be summed linearly. So it looks like we can’t simulate in FEMM a brushless DC motor like this one:

pmsm-realmagnets

Or can we? David was kind enough to show me how.

We basically replace the original design of the permanent magnets in the rotor with an “equivalent alternating field source” that emulates the moving field of the magnets at the desired speed. If things are done properly, this “current sheet” in the rotor will generate the same field as the PMs (with the same amplitude and frequency) when they are rotating. The distance between 2  opposite magnetic poles corresponds to half a wave’s period. The amplitude of the current must be reverse-engineered; David suggests to run a few simulations to find out which current density in the “equivalent rotor sheet” generates the same field strength in a distant point of the machine as the magnets would. Then it’s just a question of dividing the sheet into a lot of small(ish) segments and insert the current density vector into each one. It sounds complicated, but it’s not. Take a look at the very same motor as above, modified according to this technique:

pmsm-movingmagnets

Each one of those new little segments in the rotor has a different material property, which just defines a current density vector with the same amplitude but different orientation. The values are inserted as complex coordinates:

pmsm-current-sheet-properties

The resulting field is a sinusoidal one which matches the permanent magnet’s field, as you can expect:

pmsm-current-sheet-field

This in fact simulates magnet movement. To define the rolling speed of the motor, you set the frequency of the problem. So what’s the catch?

Well, David pointed out one: this only gets you the base sinusoidal frequency. To get the contribution of the harmonics, further simulations are necessary – and you have to know which harmonics to simulate. And our motor model has loads of harmonics because of the squarish shape of the poles, which renders this technique somewhat erroneous.

And me, I’ve always liked the fact that our models are reality-accurate. Replacing real parts with “movement-equivalent” constructs gives me the chills. What if we get it wrong? Double-checking it would take a lot of effort, and we’d still need the magnets version to find out which harmonics we should look at.

Incidentally, this can be done by doing a “generator” simulation: snapshot (at zero frequency) the flux linkage of the phases in each position of the rotor, and draw up a chart with it’s time derivative (the EMF voltage):

pmsm-generator-0hz-induced-voltages-plot

Pretty far from sine waves, right?

So, third option: back to basics. Ignore the fact that FEMM can calculate AC problems in the frequency domain, and use it only for DC static “snapshots” of several rotor positions (with the real magnets), effectively calculating in the time domain outside FEMM. Put enough of these snapshots together, and you can get electromotive forces and powers and even calculate core losses by analytical methods (as suggested by David).

Hmm… decisions, decisions… We’re taking the last approach, because time is not on our side. We will build up the script system to look for the highest Torque/Current factor, and save the core losses for a later attempt.

Advertisements