# VFD, FOC, DTC - back to the basics



## stickytechnology (Sep 19, 2010)

Hi,

I've often wondered exactly this myself. I haven't tried what you are describing, so I don't have any empirical data to back up what I am about to say, so I hope that you do try it and share with us the result.

My best guess as to why FOC and DTC are preferred over closed loop V/Hz is because the torque vs. slip curve you often see published is a steady state approximation. Induction motors have a time constant to them that determines how fast they can build up rotor current and thus torque in response to slip. DTC and FOC are then built to optimize control as mich as possible-- you get the torque you want as soon as possible after asking for it. With automotive applications, though, it seems like people are used to a little lag when they ask for torque- it's often almost a second between pressing the pedal and getting full torque. In fact, I think some DC controllers have to slow down the control loop to avoid broken drivetrains and so on.

So, as long as your closed loop control is slow enough, I don't see why what you're proposing won't work, but like I've said before, that's an armchair opinion. I'm still hoping to get a DTC system working because the elegance is appealing, but I think Stiive will beat me to it


----------



## adeyo (Jun 6, 2012)

What they said


----------



## Stiive (Nov 22, 2008)

I'm in the same boat as sticky here as i haven't finished my controller, and so I will base my answer purely on the theory.

The main and biggest advantage with vector control is the ability to control the current producing vectors independently. This allows you to effectively decouple the torque and flux of the machine.
Fluxing an induction motor quickly takes a lot of current, therefore at stall a vector controller will flux the motor while producing 0 torque. This means when a torque command is received, all the current available can be used to produce shaft torque and therefore you can get full torque from 0 RPM.
Another advantage is applying advanced flux maps to make the motor run more efficiently or provide more performance (such as MTPA -maximum torque per ampere). Again, this can be controlled independently of the torque.

Apart from the advantages, yes you can control torque from slip, and yes your right the simplified equivalent circuit model of induction motor is piss to understand. But if your chasing efficiency, which is a big deal in a large motor/controller combo running from a finite energy source (batteries), then you need to work out the most efficient way to delivering that torque. If you want to stay away from out of space vectors and dead-guy transforms, then you will need to use an equivalent motor mathematical model which requires ALL the motor parameters AND speed feedback. But still you can only control voltage/current and frequency to effect your slip/flux/PF in unison (still no decoupled control).

Another problem arises with how much torque are you actually producing? Increasing the slip doesn't always produce an increase in torque, and any increase in torque isn't going to be linear and is dependent on a whole range of factors. Again you could use your complex mathematical motor model to determine torque from voltage/current/slip/flux/PF.

So in the end, to get a decent system going, you need voltage sensors, current sensors, speed feedback and complex mathematical algorithms - and STILL it is an inferior control system.... The complete control will be highly sensitive to motor parameters and hence heating of the windings/ambient temp/age etc.


If you want to understand vector control, sure you need to be pretty good with maths, and the devil IS in the detail (somewhere). How they work is explained in the maths, and there's no getting around that, and its obviously based on how the motor really works and lots of advanced theory - it takes a lot of reading to get your head around.
However, if you want to simply just implement vector control, there are plenty of application notes (from microchip for example), that have all the code there ready for you ready to load.

End result of vector control is you get much better/advanced control of the motor, must better transient response time, better efficiency, less parameter sensitivity, and the code ends up being a lot smaller. THEN you can even start implementing advanced features such as sensorless, parameterless etc, the fun never stops! 

All that being said though, I think you can still have a decent advanced V/hz slip control. PSTechPaul has some good idea's for this aswel. I just think, if its starting to get too advanced, why not move to vector control and be done with it

Hope this helps


----------



## Siwastaja (Aug 1, 2012)

Thanks for your opinions so far; it has been helpful. And Stiive, I've been reading about your controller project. Nice work, keep going!

But theoretically, this is a somewhat funny case. Due to my work, I read many academic papers and have written some to be published in scientific journals. And the very typical abstract goes like this:

"Traditionally, A is done like this. However, it poses a problem of B. Hence, we propose a new approach C that improves parameter X by Y%"

or for later work,

"Traditionally, A was done like this. Implementing it in way C solved problem B and increased parameter X by Y%, but posed a new problem D. Our proposal further increases parameter X by Z%"

It is funny how I just couldn't find any informal or formal arguments for FOC/DTC versus "traditional". Now at least I have your claims that it increases efficiency! This is a very good start and I'm not going to ask "by how much", because this is just software and implementing it only takes time, and in a hobby project, time is free. _Any_ improvement in efficiency is very welcome in a battery-powered system.

Car as a load is an easy one; you usually do not need full torque at the start. Due to air drag increasing in the square of velocity, if you want a vehicle that can go highway speeds, you will have so much power (and torque) in the motor that starting up from zero is definitely not a problem (by other words; if you have ANY acceleration left between 100 km/h and 120 km/h, you will have enough acceleration at lower speeds). 

However, as we will be having somewhat undersized motor, zero-speed torque might still be a consideration. And in any case, highest efficiency is a must.

It seems that there's no simple way out; the algorithms are complex to understand. DTC seems very elegant but I'm a little bit skeptical about high-speed, high-accuracy analog measurements in a noisy environment. It could be fun to try out with very high speed ADCs and an FPGA. Something like 100 MSamples/s and FPGA with a clock rate of 300-400 MHz. You really could go much below microsecond timing.

For FOC, I'm a bit worried about how much time and testing it will take to fine-tune the parameters. It's not a problem for a matched controller and motor, but when both controller and motor are DIY . . .

So, maybe I just need to implement both slip control and vector control and then compare them. But I think we need to start from the basics to get anything done. That's why slip control is a good starting point, and so much more usable than open-loop V/f with little more complexity.

What do you feel, are (correctly tuned) FOC and (correctly implemented) DTC comparable in resulting performance with each other?


----------



## PStechPaul (May 1, 2012)

I don't really understand DTC and FOC either, although I took a course with Microchip in 2005 and much of it seemed to make sense. But it did involve math which is not my strong point, and I just accepted their conclusions that this was a better approach. This was not specifically for vehicular motor control and I think that is where the DTC comes into play.

But I don't have much experience with VFDs. Around 2005 I rewound a small AC motor for three phase and more poles and lower voltage, and I got it to run quite nicely with a PIC18F2331 and six MOSFETs and a rectangular waveform. It ran directly on a 12V battery. But I did not take much care with current measurement and voltage spikes and I drove the MOSFETs directly from the PIC, so it eventually burned up while I was demonstrating it to the folks at a motor rewind shop. Here is an excerpt from sci.electronics.design which goes into my saga:
http://sci.tech-archive.net/Archive/sci.electronics.design/2005-07/msg01591.html

Now I have a commercial Fuji/GE 2HP VFD that I'm using on my tractor project, and it seems to work nicely, but I'm not at the point where I need DTC. But there are many settings for the controller and all sorts of delays and limits and torque boost and motor profiles. And there is also provision for implementing an external PID loop by reading the torque as computed by the drive and comparing that to a throttle position sensor and it should then be a trivial task to make the motor respond nicely to the demands of the operator. 

I have my doubts about the increased efficiency of fancy control electronics and algorithms. A motor is really a rather simple device and because of its electrical inductance and the mass of the rotor and drive train components, I don't see how microsecond corrections of applied voltage will make any percievable difference to the motor and its performance. When the source of the control is the operator's foot and the feedback is his sensation of acceleration and the desire to control speed, that sets a rather low frequency limit for the PID loop. 

Of course the motor must be driven with a PWM signal with enough resolution to adjust the torque and speed finely enough, and to avoid mechanical and audible noise. But these can be adjusted as well, and the specifications for my drive show efficiencies of 90-97%. The motor efficiency itself is usually not quite as good. I suppose it's important to try for a couple percent more efficiency, but I think that is more a function of how the vehicle is driven and other factors such as weight, speed, wind resistance, tires, road surface, etc.

I also don't understand the reason for measuring phase voltage by reading the bus voltage during the time that the voltage is being applied by the IGBTs. The voltage drop of the devices is considerable and variable depending on many factors, such as current and temperature, and also the motor leads contribute a lot of inductance and voltage drop, so if accuracy is important, I would think a separate set of leads connected directly at the motor would be much more accurate. And it is very easy and inexpensive to do with instrumentation amplifiers and properly compensated voltage dividers (like scope probes).

Also, it seems that it is popular to read the bus current and calculate the phase angle vectors mathematically based on rotor position, which requires an accurate encoder or some tricky "sensorless" measurements. I think it's better to read the current in each leg of the bridge to detect desaturation and overcurrent, using low side shunts, and direct reading of each motor lead using an isolated Hall effect current sensor.

But if you know the motor's characteristics you should be able to just read the average DC current of the bus, which should be proportional to torque. It is not even very important to know the actual torque very precisely, because the operator simply asks for more or less torque depending on driving needs. And the motor controller simply needs to apply a PWM voltage according to a sine table at a frequency which provides the speed needed to achieve the desired torque. There is probably a "sweet spot" where you get the maximum output just under breakdown torque, but I think this can be readily sensed, especially if you have a shaft speed sensor as a "reality check".

What I think might be worth investigating is recreating a relatively pure sine wave to apply to the motor, rather than the direct PWM drive. The motor has a lot of capacitance and inductance and the the fast waveform transitions create losses through the cables to the motor and also cause stress on insulation and probably core losses as well. I propose adding LC filters to the motor leads to clean up the signal by removing the high frequency harmonics. I simulated this very crudely, and have not tried it on an actual motor, but I think it holds promise to increase efficiency, reduce EMI emissions, and other benefits such as longer motor life.


----------



## gunnarhs (Apr 24, 2012)

Hi,

I have been working on U/f and DTC for a while now. I have both been on the practical side and in the theory and fortunately I had some practical experience with electric motors (AC, DC-series, DC-Sep-EX), before dealing with the theoretical models. At the moment I am working in my free time on the control software expanding an AC-Induction-controller which has been used for Photovoltaic Water pumps into a traction controller for EV.
I think you are totally on the right way starting by implementing a closed loop U/f. It will help you create the frame for your motor control. 
(U voltage, f= frequency)
You can start as you mention by implementing the pedal giving a certain torque (U/f proportion increase by pressing the pedal) and measure the DC-Bus voltage and actual speed to calculate the slip which you need to give the U/f proprtion increase. As long as you keep the working point in the constant power region of the motor curve you will get quite good efficiency (80%+). The constant torque region (torque and current maximal) producess heat losses and in the high speed region (field weakinening when max voltage is arrived) you have iron losses.
Be aware that the constant power curve changes due to applied voltage (shifts to left when voltage decreases and right when Voltage increases seen on a torque/ f -diagram). 
To be sure to be always in the "best" working point you need motor knowledge either from saved working states or from a motor model

And therefore now to DTC (which is a subset of FOC). As you say you often get bad attitude, from academics especially I assume, if you say you do use U/f- instead of DTC. 
Believe me, most of it comes of old or bad knowledge. If you are implementing a practical DTC it is basicly an advanced U/f with Space-vector Modulation (SVM). The advance implementation comes in three ways
1) You measure U-DC-Bus and the current of 2 or 3 AC-phases. 
Instead of measuring only the motor-speed you measure the position also (with digital-encoder). 
2) Instead of working from saved motor-curves-states you work from known motor parameters (stator induction, resistance and motor-inertia)
You use the Clarke-Transformation to transfer the 3-Phase AC-curent system into a two phase current system, where one current reflects the stator current and the other the armature current. This model is similar to a practical DC-Sep-Ex motor with one current in the seperate field inductor and the other current in the armature. From the 2 currents and the known resistive parameters you calculate the stator voltages for modulation and the torque. You have two ways of adjusting the torque/speed, one by changing the slip, the other by changing the stator voltages. 
3) You could also make an time-invariant model of 2) with the Park-transformation which is in fact the classic FOC but today you can use fast ADC instead of coordinate transformation so I recomend skipping that and use a processor with fast ADC and model-calculation of momentan values instead. 

Siwastaja








Junior Member


----------



## circuit (Jan 16, 2012)

Interesting topic, subscribing.

Please note that I am not a professional in motor control and all I say below may be not correct, this is as I understand it.
About the vectors from outer the space. Actually it does not have much in common with FOC. It is just the algorithm of switching power electronics to lower amplitude of PWM carrier harmonics. I mean, if you have all three channels switching off at the same time and then switching on at their corresponding duty cycle, you will get quite high EMI at the moment all three bridges switch. The buzz about space-vector-PWM is that it is center-aligned and no power switch goes up or down at the same time other does. Here is a picture from atmel's motor drive MCU datasheet:








This can also be observed from sound - standard PWM emmits a constant frequency sound and the SVPWM humms in wide frequency spectrum.
Or at least I have observed so.


I have a motor controller project myself. Started it in 2009:
https://www.youtube.com/watch?v=aKtDlISbxlw
Since its my hobby on spare time which I don't really have, it moves really slow. I mean like Mega Slow. I've gotten almost nowhere since then.

Anyway I am more interested in efficient/silent/cogless drive of an permanent magnet motors than induction ones. Have some ideas on waveform and BEMF shape matching, but never got to testing them.


----------



## PStechPaul (May 1, 2012)

Interesting videos on your youtube channel. I'd like to see more details of your motor experiment. I plan to do more with my SR motor soon, and there is a separate thread on that project. The drive electronics are a bit more complex, but the principles are rather simple, and the results are promising. However, for most DIY projects, the ACIM is probably most practical because they are so ubiquitous and easy and cheap to obtain, and the technology is well proven. I am not convinced that the complex measurements and control algorithms are really necessary, and I think the gains of efficiency and other factors may be minimal. But yet there must be some reason why there has been so much attention on these drives.


----------



## gunnarhs (Apr 24, 2012)

Hi circuit and PStechPaul,

I think we aggree on most points here but please let me clarify for the topic starter why we should (or should not) use "fancy" control.

@PStechPaul
"But these can be adjusted as well, and the specifications for my drive show efficiencies of 90-97%"

I assume you are talking about the efficiency of your Inverter? There is a great difference in 90% and 97%. If you are working for example with a 100kW inverter 90% efficiency means you have to get rid off 10 kW heat , the 97% means you have to get away 3kW of released heat.
By using an advanced control, you are trying to keep the inverter over 95% efficient, most of the time over 97%. In a car with limited space and resources you have to minimize the cooling system so we are fighting for a few percentage here.

@PStechPaul
It is worth investigating is recreating a relatively pure sine wave to apply to the motor, rather than the direct PWM drive...
I propose adding LC filters to the motor leads to clean up the signal by removing the high frequency harmonics...

Yes this makes a great difference for the motor. But this is a feature added after the inverter stage to "smooth" the signal for the motor.

@circuit
"Actually it does not have much in common with FOC. It is just the algorithm of switching power electronics to lower amplitude of PWM carrier harmonics"

I assume you are talking about reducing the harmonic distortion by eliminating the outer switching states [000, 111] ? This is actually one part of the problem, the main problem is still the right modulation of amplitude and frequency of the output phases due to optimize the torque/speed relation in the specific voltage-space. This could mean for example the usage of more than one vektor during a sample period, an additional consideration of dead-time or any other correction.


----------



## jhuebner (Apr 30, 2010)

I'm very thankful for this thread 

I too have not found a single paper on "closed loop slip control".
The only thing you ever get is "closed loop speed control based on V/f". All stating how "in a car controlling the speed with the throttle pedal is unpractical"... no shit, Sherlock?

I do believe that FOC is very powerful but I just can't wrap my head around it. Same goes for DTC even though it seems more universal.

So here's what I did:
- Implement the sine core just like Siwastaja but on an STM32
- Add the fancy space vector modulation (which is three f..ckn lines of code) for better bus voltage usage
- Saw some teeth in my shaft coupler:









and let them run through a light barrier:









costs almost nothing and gives me the rotors current speed.
- Map the throttle signal to a slip frequency (e.g. when rotor speed is 50Hz and throttle is at 100% output a frequency of 60Hz)
- At low speeds the rotor speed measurement is too slow so I just map the throttle to 0-5Hz and gently move over to slip control above that speed. Before I did this the motor/the car started very jerky, sometimes even the over-current limit of the IGBTs was hit.

I admit it does not work perfectly: It's hard to slow down, the motor pushes against the breaks. But I will eventually figure out solutions for that and I will actually know what I have done to fix a problem. No miracles, no vectors.

It's not too far off, this is closed loop slip control driving my car:
http://youtu.be/xkuDTby8pQw

I want to say it again: FOC and DTC are amazing pieces of science and they allow (as I've read) very precise control of the motor. But do we need this?
- Does your ICE car start smoothly from 0 speed? Mine doesn't it actually needs a clutch...
- Is the throttle response of your ICE linear and reproducable? That of my turbo diesel certainly isn't
- is that a problem? not to me

Now effeciency is often another argument for advanced control methods. But heres the deal with an ACIM: it isn't advanced, it follows simple rules: Too much slip because of too little flux -> you waste energy. Too much flux and hardly any slip -> you waste energy.
Interestingly the flux current set point in many FOC VFDs is set to a constant in which case FOC is hardly any more efficient than closed loop V/f. You can set "economy modes" which reduce the flux current. But that too isn't really what you'd call "advanced".

You can optimize slip and flux with V/f as well. It will take a lot of experimenting but thats what engineering is to me.

As opposed to the effiency of the motor, the effiency of the inverter is unaffected by the control algorithm. It is determined by the gate drivers, the switching frequency and the switching pattern. E.g. the SVPWM at full throttle will save 1/3 of the switching losses. Just look at it on a scope.

All this might not apply to performance conversions. I certainly believe it applies to commuters and town-runabouts.


----------



## gunnarhs (Apr 24, 2012)

jhuebner
Nice work here on your car, I see you are on the track.
By using a slip- AND a voltage control you have a simple DTC 
(you can control speed and torque seperately)
You only need to balance it out by trying to minimize the slip by increasing the voltage if possible (try to keep the slip 2%-10% over most range)

Do not even try to do the "full torque at 0 rpm", it does not work with large motors under load. Torque-control starts to work at 10 Hz

@jhuebner
"Interestingly the flux current set point in many FOC VFDs is set to a constant in which case FOC is hardly any more efficient than closed loop V/f. You can set "economy modes" which reduce the flux current. But that too isn't really what you'd call "advanced"."

It is not so advanced indeed. But efficient use of "Field weakening" is what makes one of our car range 200 km instead of the proposed 150 km. And that with a simple SepEx-Motor, we are still building the AC-car which should perform even better.

@jhuebner
"You can optimize slip and flux with V/f as well. It will take a lot of experimenting but thats what engineering is to me."

Yes you can But if you know motor parameters you can make the experiementing easier.

@jhuebner
"As opposed to the effiency of the motor, the effiency of the inverter is unaffected by the control algorithm. It is determined by the gate drivers, the switching frequency and the switching pattern. E.g. the SVPWM at full throttle will save 1/3 of the switching losses. Just look at it on a scope."

Two different things: 
1) Efficiency of the inverter - drives under optimal cirumstances (usually 95% plus) by sophisticated design and by using the SVPWM to eliminate unwanted switching states. 
2) The main purpose of the control though is to minimize the current drawn under heavy load. If you can increase the voltage (instead of increasing the slip by slowing the frequence for more torque) you do that. More current in IGBT's means more heat, which means more losses. By using SVPWM you have the perfect tool to adjust that. So you are doing both motor and inverter a favour.


----------



## jhuebner (Apr 30, 2010)

Hey Gunnar,

do you dynamically weaken the field? thats a large increase indeed.

Interesting that I'm already close to DTC without even knowing  and without any feedback but the speed.

BTW the source code is part of the tumanako project and can be found here. Not very pretty as of yet:
http://tumanako.svn.sourceforge.net/viewvc/tumanako/trunk/inverter/fw/motor_control/src/sine/
_
"Yes you can But if you know motor parameters you can make the experiementing easier."_
Well call it "educated experimenting" then 

No the full torque at 0 rpm is not a goal.

When I see an automatic commissioning machine race to a specific shelf stop right in front of it, take its payload, race to a different shelf, stop.... I know what 0 rpm torque and transient response is all about.

But if a car ever encounters a transient it will be the last one it ever sees


----------



## Stiive (Nov 22, 2008)

jhuebner said:
 

> I admit it does not work perfectly: It's hard to slow down, the motor pushes against the breaks. But I will eventually figure out solutions for that and I will actually know what I have done to fix a problem. No miracles, no vectors.


Easy, just command a frequency that's less than the current rotor speed frequency. Be prepared for the DC bus voltage to rise as you are effectively regen'ing.




gunnarhs said:


> jhuebner
> By using a slip- AND a voltage control you have a simple DTC
> (you can control speed and torque seperately)


Gunnarhs, I think you are confused with the decoupling of torque and flux.
Changing slip AND voltage = changing frequency and voltage = v/f control = slip control. 




jhuebner said:


> do you dynamically weaken the field? thats a large increase indeed.


Field weakening allows you to overspeed the motor. i.e. when you have run out of voltage to give to the motor in your linear v/f fashion, you can still increase the frequency. As the flux is proportional to v/f, you are therefore weakening the field as you can no longer maintain the ratio.



jhuebner said:


> Interesting that I'm already close to DTC without even knowing  and without any feedback but the speed.


You definitely need current feedback from the phases! It will be very unsafe to push that much power without any form of current protection. I'm assuming you already have this though, along with the previously mentioned DC voltage sensing. Therefore you have more feedback than is required for vector control. You don't even need an encoder with sensorless vector control.


I don't know why people are so adverse to vector control. Why not get the FOC STM code from the Kiwi guys and be done with it? The code is professionally written, it works well, and most importantly its safe. Don't want unpredictable torque of slip control to rear end the guy in front of you in stop-start traffic.

I'm not trying to discourage you, i think your doing a great job and I'm pleased to see more people doing AC conversions. Slip control works, everyone knows this, but it is mainly used as a very primitive speed control to bring a motor up to speed (to limit inrush etc), which is designed to then run at a fixed line frequency. You cannot get torque vs current bang for buck, nor will you get optimum efficiency (without 5x the complexity of code and feedback of vector control), and your control over the motor will be crude. 
Look it doesn't cost any more to put on vector:
-Rather than spend extra money on battery energy, make your motor control more efficient
-Rather than spend extra money on battery and silicon (mosfet/igbt) power, make your motor control more efficiently powerful (current bang for buck)
-Rather than crashing your car, wearing out your brakes against a motor still producing positive torque, and using trial-and-error experiments to get decent torque control, DOWNLOAD FOC! 

haha

Bit exaggerated, but IMO, if your going to run v/f control, you'd be better off with brushed DC in terms of efficiency and performance.


----------



## Siwastaja (Aug 1, 2012)

Stiive said:


> I don't know why people are so adverse to vector control. Why not get the FOC STM code from the Kiwi guys and be done with it?


I think you misread us. We just want to understand what is going on. I suggest you read my opening post again to understand what is a "closed-loop slip control". Closed-loop slip control is VERY VERY VERY close to FOC, just 2...3 magnitudes more simple as an algorithm. I _know_ that the difference is in details. I also _know_ that details are important. I just want to _know_ these _details_, instead of being told something I know is complete misinformation.

*Open-loop* V/f (very typical, I think you are talking about this):

Input: 
f: frequency (as defined by the user; e.g., 1-100 Hz)

Algorithm: 
*Phase_voltage_multiplier := constant * f;
*_(constant is selected so that motor nameplate voltage is reached at the nameplate frequency.)_
*Frequency_for_all_phases := f;
U_offset = 0 deg;
V_offset = 120 deg;
W_offset = 240 deg;
*
Output:
Let the SVPWM or traditional sawtooth/triangle wave / sine wave modulator do its job with those parameters.

Notes:
Practically useless in a car for the reasons you stated in your post.

*Closed loop slip control* (this is what I'm talking about):

Input:
t: torque (for example, from -100% to +100%)
f_measured: Feedback from encoder (rpm multiplied with a constant to transform it to a frequency reading)

Algorithm:
*Frequency_for_all_phases := f_measured + t*constant; *
_(constant is selected so that maximum torque instruction does not cause the breakdown torque to be exceeded in any situation, but is near to it to give maximum torque available from the motor. Note: negative torque instruction causes negative slip, i.e., lower frequency than the actual turning speed, that causes regeneration.)
_*Phase_voltage_multiplier := constant * Frequency_for_all_phases; *_(constant is selected so that motor nameplate voltage is reached at the nameplate frequency.)_
*U_offset = 0 deg;
V_offset = 120 deg;
W_offset = 240 deg;
*
Output:
Let the SVPWM or traditional sawtooth/triangle wave / sine wave modulator do its job with those parameters.

Notes: 

Simple: boils down to just ONE line with ONE + operation. Has feedback sensor and one additional + operation compared to open-loop V/f. Has torque input instead of "rpm" input; suitable for car.

Can simply be equipped with some extra control for non-linear voltage control, e.g. a tad more voltage for starting torque.

Can simply be equipped with current feedback (from phase or battery current) to control power, this would linearize the response if needed.

*FOC*:

Algorithm:
Some fancy stuff .

---

But in the end, I'm more a realist than an idealist, so I probably end up just implementing the FOC using readily available code as a reference, even if I didn't understand what I'm doing. Then I could compare the results to gain real knowledge about the differences. Still, it would be nice to really understand what is going on. On a very fundamental level.

It seems you understand it, yes? Say, what does FOC do at the waveform level compared to closed-loop slip control with SVPWM? Does it advance some of the phases to cause a phase shift in order to control the fluxing? Or does it just control the voltage so it differs from the constant V/f ratio?



> Don't want unpredictable torque of slip control to rear end the guy in front of you in stop-start traffic.


Can you elaborate a bit -- why it is unpredictable?



> Slip control works, everyone knows this, but it is mainly used as a very primitive speed control to bring a motor up to speed (to limit inrush etc), which is designed to then run at a fixed line frequency.


I think you are mistaking slip control for open-loop V/f, which is completely different. Open-loop V/f is typically used for the purposes you describe, by ramping up V and f. Slip control, by the very definition of its name, uses encoder feedback from the shaft to drive the motor at exactly known point on its speed/torque curve. (The limitation here is that the curve is not linear.) Current feedback, OTOH, would allow to regulate power to linearize it and remove any variations, automatically.



> nor will you get optimum efficiency


Where is that energy lost? What is the mechanism? 



> and your control over the motor will be crude.


Why? Due to nonlinearity of the slip/torque curve part we are using?

I'm just trying to understand. I really appreciate your help. But it appears that you are just repeating the same "open loop V/f versus FOC" marketing arguments I'm so tired hearing because I know they are false because we are not talking about open loop V/f at all. Rather, I really believe there are some efficiency and max torque differences in certain operating regions, and that's exactly what I want to understand more in detail.

This is also about safety. If I have an algorithm in 1 line which in 1 plus calculation causes negative torque instruction to cause lower-than-measured drive frequency, this will very surely regenerate and slow down. The other option seems to trusting a long algorithm written by other hobbyists without me understanding it. That algorithm does not DIRECTLY cause regeneration, but does it through a number of mathematical operations, so the risk is higher. Not really a problem, it's been tested, I'm not paranoid, and I can analyze and test it, but just saying...


----------



## Stiive (Nov 22, 2008)

Firstly, i've only studied and written code for DTC (as well as advanced slip control), so i will respond in terms of comparison with DTC.



Siwastaja said:


> Closed-loop slip control is VERY VERY VERY close to FOC, just 2...3 magnitudes more simple as an algorithm.


I wouldnt say the algorithm was very very very close, maybe could be classified as close? The outputs will look similar.
In terms of DTC, my DTC code is much simpler (in code terms) and smaller than my slip control code. The understanding of the control, and therefore debugging is however harder

*


Siwastaja said:



FOC

Click to expand...

*


Siwastaja said:


> :
> 
> Algorithm:
> Some fancy stuff .


LOL.. Yeh FOC has some annoying maths in it.





Siwastaja said:


> Still, it would be nice to really understand what is going on. On a very fundamental level.


Such is life, most people don't ask "why is Pi 3.142" or "why does F=IBL", you just use the equations and get on with it 
Bad examples i know. haha



Siwastaja said:


> It seems you understand it, yes? Say, what does FOC do at the waveform level compared to closed-loop slip control with SVPWM? Does it advance some of the phases to cause a phase shift in order to control the fluxing? Or does it just control the voltage so it differs from the constant V/f ratio?


No i don't actually haha. 
In terms of DTC, I understand the theory insofar as how to replicate it. Being an engineer, I understand transforms and space vectors, and I understand how we can add different vectors to produce voltages at phases that are required by the motor. Once transformed from 3-phase to 2-axis (torque and flux), it is easy to then add on vectors to either increase/decrease the torque or flux independently. 
As to why do particular transforms translate into d-q axis, or alpha-beta torque and flux axes, i'm not sure, and TBH it doesn't really concern me - but they have been proven and i can replicate the result, that's all that matters to me. 
I coded my DTC algorithm purely from a white paper explaining just the theory (no pre-made code examples), and it worked (only on a simulation thus far), then i even went beyond the papers theory and included some more calculations to decrease torque ripple. After all this i feel i have a fairly good understanding of how it works, maybe not so much as 'why' it works. Do i understand the fundamental principal of every equation? No. But I can also say, neither do you in slip control.



Siwastaja said:


> Can you elaborate a bit -- why it is unpredictable?


jhuebner said his motor was fighting his brakes. Also, torque produced by slip is not linear.




Siwastaja said:


> (The limitation here is that the curve is not linear.) Current feedback, OTOH, would allow to regulate power to linearize it and remove any variations, automatically.


Not automatically, you need many calculations. To produce reliable torque from motor you need:
Voltage, freq, currents, speed + ALL motor parameters.
DTC by comparison can have just voltage,currents+1 motor parameter
FOC needs a few more parameters (i think 3-4)




Siwastaja said:


> Where is that energy lost? What is the mechanism?


Low power factor mainly, you push all this current in but it doesn't produce any torque. Sure you dont lose energy per se, but the extra currents still heat your copper and cause higher switching losses.



Siwastaja said:


> Why? Due to nonlinearity of the slip/torque curve part we are using?


Yes, and the inability to decouple torque and flux. You cannot get full torque out of a motor without vector control, this may lead to oversizing the motor, controller and batteries to get the desired performance. An oversized motor is inefficient at light loads.
30kW will keep most cars at 100kph, you need torque to accelerate and to get the car moving. Full torque from 0 RPM is a desirable feature and allows you to have a smaller motor whilst not struggling at the lights.



Siwastaja said:


> I'm just trying to understand. I really appreciate your help. But it appears that you are just repeating the same "open loop V/f versus FOC" marketing arguments I'm so tired hearing because I know they are false because we are not talking about open loop V/f at all.


Okay, as an example i have 2 control methods. Firstly I created a slip control because that's what we learn't in school, it was very easy, took only a few hours. I wasn't happy with the results though so i added more and more maths to increase the accuracy of my torque estimation. In the end, I can control the motor fairly accurately by torque - I enter a torque value, the motor tries to reach that value without saturating. Nothing i could do about low end torque or efficiency, both were horrible.
I then started learning DTC and of course it took me awhile but i eventually got a working model. Half the code, very very accurate torque control, could push the motor a lot harder with the same current, full torque from 0RPM, and much better efficiency below nominal speed. DTC only pulled out further and further ahead as my model got more complex, adding in heating of the windings, power loss over IGBTs and dead-time compensation. 
Im coding my controller as we speak (so to say), and I'm not even gonna bother try implement slip control first. A) it'll take longer as the code is more complex and B) It would only waste my time

I wish i had some decent result graphs to articulate the differences, once you see the improvements, its a no-brainer. I'm thinking of making a video on my DTC controller build, maybe ill add something in that.


----------



## Siwastaja (Aug 1, 2012)

OK - thanks for your insight! Practice is what matters over theory.

I will promise you, I won't go into great lengths to fine-tune the "closed-loop slip control" algorithm. As I stated, it must be simple, otherwise there's no point. The idea is not to let the slip increase too much which would cause poor efficiency. This decision probably leads to a situation where all torque cannot be realized, just the nameplate value plus maybe 20-30%, unless efficiency is sacrified by going near breakdown torque.

If I then want more torque from the motor -- which will probably be the case as we are using a relatively small motor --, we'll just implement FOC or DTC rather than fine-tune slip control to more than 10 lines of code.

The good thing here is, the inputs and outputs are same for both so it's easy to change the algorithm.


----------



## stickytechnology (Sep 19, 2010)

There is one advantage to the closed-loop slip idea over DTC, which is you don't need accurate current sensing at all. IGBT desat should be enough overcurrent protection. It was almost enough seeing jhuebner's car to get me to try it, as the problem I'm having with my system is that my current sensing is not accurate enough for DTC. But, Stiive's pep talk has put me back on the righteous path . Might take me a while to fix my current sensing, though.


----------



## Stiive (Nov 22, 2008)

stickytechnology said:


> There is one advantage to the closed-loop slip idea over DTC, which is you don't need accurate current sensing at all. IGBT desat should be enough overcurrent protection. It was almost enough seeing jhuebner's car to get me to try it, as the problem I'm having with my system is that my current sensing is not accurate enough for DTC. But, Stiive's pep talk has put me back on the righteous path . Might take me a while to fix my current sensing, though.


Yeh that's true. I'm working on my current sensing right this instant... well, if i could get the triple simultaneous ADC mode working that is...


----------



## Arlo (Dec 27, 2009)

Subscribing. Very good reading here.


----------



## jhuebner (Apr 30, 2010)

What are your issues with current sensing?

What effiency figures are we talking?

In some ABB paper (http://www.hv-engineering.de/pdf/pdf_anleitungen/TechnischeAnleitungNr1.pdf page 21) It says you potentially save 10% @ 25% load and 2% @ 50% load.
It makes a difference for sure. But be aware there is no open source inverter as of yet. If the first one is supposed to be ultra-efficient there won't be one for a long time unless Stiive is a prodigy.

Slip control is crude, but its not a no-go (well nobody said that).

I've had the slip control do regen. Actually on the video it does regen when coming back down the slope.
I tried to get the car to coast when throttle=0 (without completely disabling the PWM). After that code change it simply stayed around 0 slip still feeding some torque to the brake disks.


----------



## gunnarhs (Apr 24, 2012)

Originally Posted by *gunnarhs*  
_jhuebner
By using a slip- AND a voltage control you have a simple DTC 
(you can control speed and torque seperately)_

@Stive
"Gunnarhs, I think you are confused with the decoupling of torque and flux.
Changing slip AND voltage = changing frequency and voltage = v/f control = slip control."

No I am not. Because I (and jHuebner also it seems) have the information about the currents from the phases for the SVPWM which allows us og controlling the Torque and Speed seperately. 
(we could also use a motor model for prediction but as we have speed feedback and in my case also feedback of rotor-position, we use the info directly)

You have too look at the closed U/f loop as the outer loop of your system and (speed control) and just add a inner loop for the "correction" of the SVPWM which gives you the balanced Torque-speed-control but also the possibility to control it independently.

In the practical case it meens to adjust slip (torque) AND Voltage (speed), you can do it independantly up to certain limits (meening you cannot exceed 20% slip and you can not make more Voltage than the Battery supplies)
You say you like the theoretical implementation so here you are:
http://ljs.academicdirect.org/A18/027_044.htm
Pay attention to formula (8)-(10)
By actually applying a good slip-control you can minimize the torque-ripple and this actually works well


----------



## gunnarhs (Apr 24, 2012)

@jhuebner
"do you dynamically weaken the field? thats a large increase indeed."

Yes when the motor exceeds base speed and the car is "cruising"

@jhuebner
"Interesting that I'm already close to DTC without even knowing  and without any feedback but the speed."
Add the feedback of the current-measurement to "correct" your SVPWM and the you have it

@jhuebner
"BTW the source code is part of the tumanako project and can be found here. Not very pretty as of yet:"

I can give you the Siemens/Infineon code if you like (but it goes on a different processor, XC878. That is a modified U/f (with feedback, SVPWM, and current-feedback) and it works actually fine.

@jhuebner
"Well call it "educated experimenting" then "

Ha,ha I will, actually we did this once with a open loop (constant) V/f for water pumps, in that case it worked quite well. Had a total efficiency with our Inverter of 97% and totally outperformed Siemens Simovert with FOC. But only for this special case.

@jhuebner
"But if a car ever encounters a transient it will be the last one it ever sees" 
Agree with you, full torque at 0 rpm sounds more like a stepper motor application


----------



## circuit (Jan 16, 2012)

gunnarhs said:


> I can give you the Siemens/Infineon code if you like (but it goes on a different processor, XC878. That is a modified U/f (with feedback, SVPWM, and current-feedback) and it works actually fine.


I am building my BLDC controller for some time now. Coding is not my strong side, but I would be very interested in the code. Can you share it with me?


----------



## gunnarhs (Apr 24, 2012)

circuit said:


> I am building my BLDC controller for some time now. Coding is not my strong side, but I would be very interested in the code. Can you share it with me?


Hi, I hope this is ok for the webadmin and the topic-starter to add this as zip-attachments here . The FOC-code is for Brushless-DC, the U_f for Induction-Motor. The code has been generated with Dave-tool from Infineon for SDCC - compiler. More info on www.infinion.com (use search)


----------



## Stiive (Nov 22, 2008)

gunnarhs said:


> No I am not. Because I (and jHuebner also it seems) have the information about the currents from the phases for the SVPWM which allows us og controlling the Torque and Speed seperately.
> (we could also use a motor model for prediction but as we have speed feedback and in my case also feedback of rotor-position, we use the info directly)


But DTC by definition is a vector control algorithm which decouples torque and flux. Not torque and speed. The algorithm you describe is not DTC. Although DTC stands for "direct torque control", it is a specific type of control, just because you can control torque does not mean you have implemented DTC. 

What you and jhuebner describe is slip control with a torque input.
I admit, the naming of the algorithm is misleading because it is not the only method of controlling the torque of a motor.


----------



## stickytechnology (Sep 19, 2010)

jhuebner said:


> What are your issues with current sensing?


I'm using a power stage from an industrial motor drive, and the current transducers output +/- 15V. I designed a circuit to convert to 0-3.3V for my ADC, but the offsets and nonlinearities and noise were too much to bear. Makes me appreciate the difficulty of doing good analog design


----------



## PStechPaul (May 1, 2012)

I am using a simple design to shift a +/- 2.5V signal to 0-2.5V for the ADC input of a PIC. The bipolar signal goes to two 3.0k resistors in series to the 2.50V reference. Thus at -2.5V the signal is zero, at zero it is 1.25V, and at 2.5V it is 2.5V. I'm measuring 60Hz true RMS AC current through a shunt, and I am able to get accuracy of 0.25% or better. 

The actual input from the shunt is processed by an INA129 Instrumentation amplifier and then a multiple gain amplifier using an LT1112, with 8 ranges in a 1-2-5 configuration so with a 1000A/100mV shunt I can read currents as low as 50 amps to a precision of 0.1A and as high as 10,000 amps.


----------



## circuit (Jan 16, 2012)

gunnarhs said:


> The FOC-code is for Brushless-DC, the U_f for Induction-Motor. The code has been generated with Dave-tool from Infineon for SDCC - compiler. More info on www.infinion.com (use search)


Thanks, will take a look at it.


----------



## gunnarhs (Apr 24, 2012)

Stiive said:


> But DTC by definition is a vector control algorithm which decouples torque and flux. Not torque and speed. The algorithm you describe is not DTC. Although DTC stands for "direct torque control", it is a specific type of control, just because you can control torque does not mean you have implemented DTC.
> 
> What you and jhuebner describe is slip control with a torque input.
> I admit, the naming of the algorithm is misleading because it is not the only method of controlling the torque of a motor.


Huebner describes a slip control with speed input, at the moment he controlles the slip/torque only with speed feedback. To be able to seperately control torque and speed (which is an essential part of vector control) you need to decouple the stator flux from the rotors and you do that with the current feedback and Clarke-Transformation which gives you 2 Phases, one stator Phase and one rotor Phase . As he has already measured the currents and implemented SVPWM this is an easy addon
Did you read the article I refered to? You see the two Phases there
at figure 11. (they are described as d and q but are really alpha and beta in the sense of FOC). 
FOC and DTC can both be implemented with and without speed feedback but with speed feedback they are much more accurate. And current feedback with stator and rotor seperation is neccesary to call it a vector control we seem to agree on this points. But in the end the point is to be able to control the V/F proportion which gives us the Torque under certain speed. The only thing the vector control does is calculating the stator and rotor phases (Clarke) and Park transformation does nothing but make it time invariant (which is not always good by the way, you create dead time, it costs 70% of the cpu in the case i have tested). When not using feedback, slip is estmated, when using feedback, slip is calculated.


----------



## gunnarhs (Apr 24, 2012)

PStechPaul said:


> The actual input from the shunt is processed by an INA129 Instrumentation amplifier and then a multiple gain amplifier using an LT1112, with 8 ranges in a 1-2-5 configuration so with a 1000A/100mV shunt I can read currents as low as 50 amps to a precision of 0.1A and as high as 10,000 amps.


Ok that is quite impressive


----------



## Siwastaja (Aug 1, 2012)

By the way, https://www.youtube.com/watch?v=jnp2wOWdOXc shows what we have now. This is however a simple V/f drive. It does generate sine with 3rd harmonic, just like SVPWM does to better utilize DC bus. The PWM frequency goes along with the base frequency but takes one-octave steps in order to stay at the allowed limits, hence the sound. The sound is similar to some early VFDs which were apparently done in the same way.

I feel that we are starting to grasp the concepts of FOC and DTC finally, piece by piece. I have to say that all information is quite obfuscated in their nature; and, it is really crucial to understand how the ACIM actually works on a level that is not explained, for example, in Wikipedia at all.

I have a question to any motor gurus here. Is this the correct explanation of what *basic task* both FOC and DTC try to achieve in order to increase *efficiency and power factor*:

All electric motors have two magnetic fields, and they produce torque by having these fields oppose & attract each other, think two magnets. Now, in order to use their magnetic fields fully for this purpose, these fields must be at a *90 degree angle* relative to each other. In a series DC motor, this happens automatically by mechanically connecting the brushes. In a PMAC/"BLDC" motor, this happens by using a position sensor. However, in an induction motor, we can't exactly know this angle. It is not related to the actual rotor angle, nor it is _exactly_ related to slip.

Now, it is important to understand that the _rotor-generated magnetic field_ is _synchronous_ to the stator-generated magnetic field. Hence, they both rotate at the same speed. And _here_ we need the same *90 degree angle* as in brush-DC and PMAC/BLDC motors between these fields that are _stationary_ with regards to each other.

So, in normal nameplate conditions (speed, load, power), the ACIM tends to stabilize to a slip, voltage and current situation where the angle between the two stationary fields is the desired 90 degrees. If it isn't 90 degrees, all energy is not converted to torque; instead, it is bounced back to electricity, but with some losses which is mostly seen as dropping power factor. Also, this limits the maximum power available.

In ACIM, the process is of course self-regulating; if the angle between the fields is 0 degrees, it generates no torque and the angle increases when torque is needed. Therefore, the angle is _closely related_ to slip (speed difference between rotor physical speed and rotor field speed, later of which is same as stator field speed). Still, it's not the same thing.

Hence, the better solution than the _slip control_ proposed by me in my first post, might be to keep the slip at optimum slip point (as in nameplate) and vary voltage and current instead. Like this: if there is too much slip, the angle is likely to be more than 90 degrees --> increase voltage to strengthen the fields to reduce slip. If there is too little slip, the angle is more likely less than 90 degrees (a low power factor is seen, like with unloaded ACIM driven from the mains); decrease the voltage to weaken the fields and increase slip.

However, I also understand that the angle difference between the fields is not _100% directly_ related to _only_ the slip. Here comes the FOC -- the purpose of which is to _approximate the angle _taking all parameters into account, and _set it to exactly 90 degrees_, and _in addition_ allowing the used to adjust the _magnitude_ of rotor and stator fields, the directions of which have been taken care of by the algorithm.

Am I right here? Any comments? Any missing points?


----------



## gunnarhs (Apr 24, 2012)

Siwastaja said:


> Am I right here? Any comments? Any missing points?


Yes you have got it right. Now it is just about the implementation. Here some user cases:
1) BLDC/PMSM. Here FOC is very desireable because these are synchronous machines and you have a stationary magnet for example in the rotor. For a small motor with little load and/or little dynamic change requirements you can also skip the speed/position sensor. You only have to control the (decoupled) stator flux amplitude until you reach the base speed (rotor flux remains constant in this case). Lets stop here with PM-machines

2)ACIM. Here FOC WITH current/speed/position-feedback is the best universal control but not necessary the best for each special case. It depends on the dynamic-response requirements. That is the reason for the implementation of DTC which uses the first step of FOC at least ( Clarke 3->2 conv). 
In this case to make a good torque-control, slip has to be taken into account when adjusting the decoupled torque-components (T, rotor current and stator-current ) AND motor parameters when adjusting the speed (w) resulting the power (P), P = T x w. 
If rotor and stator field are only coreccted in respect of amplitude as in classic FOC it will correct the slip but with high torque ripple. 
The DTC will have less torque ripple with speed/position/current - feedback but needs good sensors and accurate motor model otherwise it has low power factor due to "overslipping".
I have referred to http://ljs.academicdirect.org/A18/027_044.htm for better understanding how to relate slip to torque-control (Equation 10).
Figure 5 shows the d/q frame with the projection of the stator/rotor vektors with slip-correction and Figure 11 shows the time-variant (!) stator and rotor currents from the Clarke-Transformation.
So the question is what are your requirements, universality (FOC) or high dynamic response (DTC with application specific modification)?
I assume the DTC because we are in an electric car thread...


----------



## stickytechnology (Sep 19, 2010)

Siwastaja said:


> All electric motors have two magnetic fields, and they produce torque by having these fields oppose & attract each other, think two magnets. Now, in order to use their magnetic fields fully for this purpose, these fields must be at a *90 degree angle* relative to each other. In a series DC motor, this happens automatically by mechanically connecting the brushes. In a PMAC/"BLDC" motor, this happens by using a position sensor. However, in an induction motor, we can't exactly know this angle. It is not related to the actual rotor angle, nor it is _exactly_ related to slip.


This isn't quite right. There's only one magnetic field in the air gap (the flux linkage vector). True, it has components from both rotor and stator, but it's better to think of it another way: 
The torque in an electric motor is produced by a current flowing in a magnetic field (Lorentz force). The torque is proportional to the cross product of the current vector and the flux linkage vector. This is why series DC motors produce torque in proportion to the square of current- the current increases the field strength via the field windings, and is itself the armature current, and the angle between the two is 90 degrees, as you've pointed out.

The way DTC estimates the torque of an ACIM is by taking the cross product of the flux linkage vector, which is just the integral of the voltage applied to the motor, with the current vector, which is measures at the phase terminals. The rest of DTC is just a way to regulate both the torque and the flux magnitude by choosing appropriate switch states.

I could have misconceptions also, so please point them out


----------



## jhuebner (Apr 30, 2010)

I want to add some of my findings, even though this thread is rather old..

My current inverter firmware is growing around V/Hz and uses an encoder to do slip control. I also modify the voltage for fewer losses at low slip (=torque) commands. It works well but has accumulated a considerable amount of parameters to be tuned until the throttle response works well.

So, after reading 50+ papers on FOC all covering the same details with hideous formulars, I finally found a source that explained FOC to me in an understandable manner: http://focus.ti.com/docs/training/catalog/events/event.jhtml?sku=OLT111008

Its a video that explains e.g. the Parke transformation as "jumping on a spinning carousel". No fancy math, no greek symbols. I like that.

After watching it I implemented the FOC algorithm in around 4h and it turns out it is less code than slip control + V/f. In the simulation environment it works well, will test it on the inverter these days.


----------



## Stiive (Nov 22, 2008)

Stiive said:


> So in the end, to get a decent [V/f] system going, you need voltage sensors, current sensors, speed feedback and complex mathematical algorithms - and STILL it is an inferior control system.





jhuebner said:


> My current inverter firmware is growing around V/Hz and uses an encoder to do slip control. I also modify the voltage for fewer losses at low slip (=torque) commands. It works well but has accumulated a considerable amount of parameters to be tuned until the throttle response works well.





Stiive said:


> End result of vector control is you get much better/advanced control of the motor ......and the code ends up being a lot smaller.





jhuebner said:


> After watching it I implemented the FOC algorithm in around 4h and it turns out it is less code than slip control + V/f.



Hate to say it, but I told you so  
I wasted too much time on an advanced slip control - I guess its the necessary learning curve though.

Glad to hear your still working on the controller


----------



## Siwastaja (Aug 1, 2012)

Again -- this video is so last season, I've seen it over and over again. It's about permanent magnet FOC which is a _completely different_ beast.

There's nothing difficult in Parke-Clarke-Einstein-Space-2000-Transformations (it's the part common with PMAC and ACIM FOC -- the trivial part), they are just obfuscated coordinate transformations and you don't need to think about those too deeply, yes, you can just pick the code that does the job.

The problem is that the ACIM FOC has many black boxes, most importantly, the rotor flux estimation (the problem skipped in PMAC FOC the video is about). This part is also sensitive to adjusting all the parameters. According to Wikipedia, at least rotor inductance and rotor resistance, which greatly varies with temperature. You can find that FOC is sensitive to temperature variations and I've seen no open-source implementation of exact algorithm that does the rotor flux estimation. It seems you are missing this part completely, while it is the "meat" of the ACIM FOC.

Generally, physical modeling can lead to best results, but the model needs to be very accurate, otherwise, small errors can cause large mistakes. Simply put, you need to have BOTH the model AND the input (both physical parameters and measurements) just right.

The beauty of simple slip control is that it doesn't rely on the complex model in order to create optimal slip; it directly does it, the slip is given as a parameter. While without modeling we cannot have 100% optimal slip (because we don't know what's perfectly optimal), it should be near to it, and what's best, a small modeling error or temperature shift won't wreck havoc.

How do you tune FOC parameters? Do you know that there are complete books on the subject? Indeed, FOC tuning is a crucial part of FOC algorithm, again, always omitted when talking about how "FOC is so easy, just do the math transformations". Without it there is no usable FOC. There seems to be reasons why some people prefer DTC instead; it tries to be self-tuning at the runtime.

At least I understand what "slip" is and I can easily increase or decrease it.

Stiive, have you really implemented ACIM FOC that really works and gives better results than simple slip control?

If this is a "it just works" type of thing as you claim, then please cut the BS and show the code!


----------



## jhuebner (Apr 30, 2010)

The video might be last season but still contains valid information. But you're right, for an ACIM its not that simple. 

For a PMSM with some sort of shaft sensor you can run foc without any motor parameters. That was new to me.

I was rather disappointed when I learned that this is not true for asynchronous motors.

So that said, maybe there is a point to run slip control after all.

In the tumanako repository there is an implementation of a simple slip estimator. It works with a fixed rotor time constant. I don't know which is better: foc with errornous time constant or slip control?

https://github.com/tumanako/tumanak...ol/blob/master/src/slip_estimator/SlipAngle.c


----------



## gunnarhs (Apr 24, 2012)

jhuebner said:


> The video might be last season but still contains valid information. But you're right, for an ACIM its not that simple.
> 
> For a PMSM with some sort of shaft sensor you can run foc without any motor parameters. That was new to me.
> 
> ...


FOC for PMSM always needs current feedback (at least 2 phases for a 3 phase motor) and the same can be done with induction motor to force a constant slip (fixed torque, variable speed application for example).
Unfortunately in the vehicle we need variable torque (and also controlled speed for more efficiency) and this complicates the matter. 
As I have previous mentioned you always need to take slip into account to "correct" your FOC for induction motor if you want better efficiency.
I would not trust the fixed rotor time constant in the code above but rely more on slip measuring if I had to choose. 
Myself I have used a V/f with current and speed feedback (and recently encoder postion to to make use of Space Vector Modulation). This has worked very well for all standard induction motors but I have had problems with the Siemens Motor 1PV5135 which has very high inertia and anothers members (Stiive) inverter which uses basic DTC (as far as I know) seems to handle it much better in terms of speeding it up.


----------



## Siwastaja (Aug 1, 2012)

gunnarhs said:


> and the same can be done with induction motor to force a constant slip (fixed torque, variable speed application for example).


Excellent! I was waiting for someone to say this out loud. If I may reiterate;

1) FOC just adjusts slip. FOC parameters and motor model affect the amount of slip.
2) "Simple" FOC with simple flux estimation and fixed parameters *just creates constant slip*. So...

Why bother with all the FOC stuff (~100-200 lines of pseudo code, a lot of calculation) when you can do *exactly*, bit by bit the same result with just 5-6 lines and 1/100th of the calculation -- just apply the constant slip?

FOC is advanced and relies on the motor modeling algorithm and parameters. "Simple FOC" is exactly slip control, but in a much complex representation. FOC makes sense when this extra complexity is _needed_.

(And yes, it is probably needed in a car, but FOC stops being "easy" and "just about mathematical transformations" in that case.)

Stiive is always comparing "simple FOC" to a "complex slip-control" but they do different things. Complex slip control does a lot better than a simple FOC, which is identical to _simple slip control_ in its result.


----------



## jhuebner (Apr 30, 2010)

Siwastaja said:


> Excellent! I was waiting for someone to say this out loud. If I may reiterate;
> 
> 1) FOC just adjusts slip. FOC parameters and motor model affect the amount of slip.
> 2) "Simple" FOC with simple flux estimation and fixed parameters *just creates constant slip*. So...


But what does the mysterious q-current do? The slip can't be the same at 10A as it is at 100A? The q-current creates torque, slip creates torque. What am I missing?



Siwastaja said:


> Why bother with all the FOC stuff (~100-200 lines of pseudo code, a lot of calculation) when you can do *exactly*, bit by bit the same result with just 5-6 lines and 1/100th of the calculation -- just apply the constant slip?


Some days ago I would have agreed. "The FOC stuff" in my case is:


```
void foc_step(FOC_DATA *fd)
{
   s16fp sin = SineLookup(fd->angle);
   s16fp cos = CosineLookup(fd->angle);
   //Clarke transformation
   fd->ia = fd->il1;
   fd->ib = FP_MUL(sqrt3inv1, fd->il1) + FP_MUL(sqrt3inv2, fd->il2);
   //Park transformation
   fd->id = FP_MUL(sqrt32, (FP_MUL(cos, fd->ia) - FP_MUL(sin, fd->ib)));
   fd->iq = FP_MUL(sqrt32, (FP_MUL(sin, fd->ia) + FP_MUL(cos, fd->ib)));
   //PID controller
   s32fp newid = CalcPID(fd->id - fd->id_spnt, &fd->ctl_d);
   s32fp newiq = CalcPID(fd->iq - fd->iq_spnt, &fd->ctl_q);
   //Inverse Park transformation
   s32fp newia = FP_MUL(sqrt32, (FP_MUL(cos, newid) + FP_MUL(sin, newiq)));
   s32fp newib = FP_MUL(sqrt32, (-FP_MUL(sin, newid) + FP_MUL(cos, newiq)));
   //Inverse Clarke transformation
   int32_t ul1 = newia;
   int32_t ul2 = FP_MUL(-FP_FROMFLT(0.5), newia) + FP_MUL(sqrt3ov2, newib);
   int32_t ul3 = FP_MUL(-FP_FROMFLT(0.5), newia) - FP_MUL(sqrt3ov2, newib);

   int32_t ofs = CalcSVPWMOffset(ul1, ul2, ul3);

   fd->dc[0] = ul1 - ofs;
   fd->dc[1] = ul2 - ofs;
   fd->dc[2] = ul3 - ofs;
}
```
I count 17 lines of code for:
1. transformation from 3-phase quantities to 2-phase quantities
2. transformation from rotating to stationary reference frame
3. PID control (ok, thats in another function)
4 and 5. back transformation
6. Space vector modulation (the function that is called has 3 lines of code)
There is only fixed point multiplication and addition, nothing that gets a modern micro sweating.
The simple slip angle estimator is another 6 lines of code.

My F/U + slip control implementation has slightly more lines of code, has no current control loop and more ifs and thens. E.g. below certain revs (turned out to be 80 rpm for my motor) the slip control loop becomes unstable and a fixed frequency must be output instead.



Siwastaja said:


> FOC is advanced and relies on the motor modeling algorithm and parameters. "Simple FOC" is exactly slip control, but in a much complex representation. FOC makes sense when this extra complexity is _needed_.


Do you still think the above code is overly complex?



Siwastaja said:


> (And yes, it is probably needed in a car, but FOC stops being "easy" and "just about mathematical transformations" in that case.)
> 
> Stiive is always comparing "simple FOC" to a "complex slip-control" but they do different things. Complex slip control does a lot better than a simple FOC, which is identical to _simple slip control_ in its result.


Ok, that might not be just. But those little transformation might actually make things easier, couldn't that be?


----------



## gunnarhs (Apr 24, 2012)

jhuebner said:


> But what does the mysterious q-current do? The slip can't be the same at 10A as it is at 100A? The q-current creates torque, slip creates torque. What am I missing?


Not missing much, only remember that the torque T) is actually created by 
T ~ Iq x Id (or Iq*Id*sin(angle))
Before Parke T is time dependant, after Parke T is timeinvariant.

So if Id is constant, yes then Iq is the torque determining component.
The problem with the induction motor is that iq depends on id. This is defined through mutual inductance in the motor model and is experineced in the slip for example. 
If you try to hold the slip constant and only increase/decrese Voltage and frequency you can have 4 main cases
V= stator voltage, f = frequency of stator , n = freuency of rotor (load)
id = stator current, iq = rotor current

1) V increases, f is constant and n is constant, slip (f-n/f) is constant
Here you are adding torque without changing the speed by adding voltage.
Id and iq increase both equally in magnitude. Angle is constant
This done more smooth by using FOC than by pure slip control if you use SVM for moduling voltages. 
This is the case you maintain constant speed under different load circumstances. 

2) V increases f increases and n increases, slip is constant. 
Here you are adding speed without changing the torque. 
iq is kept "constant", id is increased. Angle is kept constant.
This is the case you icrease speed under same load circumstances

3) You can do the opposite of 2) and 3 by decreasing the voltage and playing with id and iq. The limit comes when Voltage can not beeing increased (field weakening) and frequence can not beeing decreased (very little rotor current iq calculating becomes crap). Also remember that the motor model provided by FOC is an ideal model which has been linearized near the ideal point of the motor. It does not include saturation nor magnetisation process, only control of a stabilized motor.

4) Overspeed, low frequency or overslipping , iq and id can not be determined clearly. 
Here you are stuck with classic U/f and slip control (you do not want unexpected regen).. 

Also remember that in 1)- 3) the current angle must follow the slip angle. Then we come to the next step, why and when do the Park Transformation


----------



## gunnarhs (Apr 24, 2012)

Next step is looking at the code ( by the way one of the most readable codes I have seen for FOC , nice job here, mine is more messy )
But I will allow me one change, please let me know if you want to try it out or if you think this is no use for you

```
//important this comes from the same interrupt
 
extern SlipAngle(double ia, double ib, double sPWM, double tRotor);
extern PWM_FREQU; // for example 50 Hz for 3000 rpm for 2 pole motor
extern ROTOR_FREQU; //the measured load frequency
 
void foc_step(FOC_DATA *fd)
{
    //Clarke transformation gives us 2 phases which are in the ideal model
    //stator and rotor components, two sinus currents with 90 degree shift
   
   fd->ia = fd->il1;
   fd->ib = FP_MUL(sqrt3inv1, fd->il1) + FP_MUL(sqrt3inv2, fd->il2);
 
   //Slip correction
 
   //SlipAngle = Stator Angle + deltaSlip due to new PWM_FREQU
   
   fd->Angle = SlipAngle(fd->ia, fd->ib, PWM_FREQU, ROTOR_FREQU);
   
   //assuming ia is our stator reference and ib our rotor reference
   temp_ia = fd->ia;
   fd->ia =  fd->ia + temp_ia * cos(fd->Angle);
   fd->ib =  fd->ib + temp_ia * sin(fd->Angle);
 
   //No Park transformation it delays the slip info and sensor info
    
   //Maybe additional correction by allowing more slip, could reduce ripple
   //see [URL]http://ljs.academicdirect.org/A18/027_044.htm[/URL]
 
   //PID controller
   s32fp newia = CalcPID(fd->ia - fd->ia_spnt, &fd->ctl_a);
   s32fp newib = CalcPID(fd->ib - fd->ib_spnt, &fd->ctl_b);
 
   //Inverse Clarke transformation
   int32_t ul1 = newia;
   int32_t ul2 = FP_MUL(-FP_FROMFLT(0.5), newia) + FP_MUL(sqrt3ov2, newib);
   int32_t ul3 = FP_MUL(-FP_FROMFLT(0.5), newia) - FP_MUL(sqrt3ov2, newib);
 
   int32_t ofs = CalcSVPWMOffset(ul1, ul2, ul3);
 
   fd->dc[0] = ul1 - ofs;
   fd->dc[1] = ul2 - ofs;
   fd->dc[2] = ul3 - ofs;
}
```
 This is an even shorter code but may be need correction.


----------



## Siwastaja (Aug 1, 2012)

Our super duper simple slip control is working perfectly fine. Absolutely nothing to complain about at this point. (We need to build the proper motor mount however!)

It gives very nice throttle response, full torque from zero, and easy control of speed even at very low speeds. Efficiency cannot be so poor; the controller has passive cooling with no fans and it is only warm to touch after 4-5 km of test drives. Motor does not have any cooling either and it's just barely warmish.

Regen is able to stop the car completely. It was very aggressive so we limited it quite a bit.

See the videos:

http://www.youtube.com/watch?v=daYXNsyvWhg

http://www.youtube.com/watch?v=KaCTVe_FCYg

We are currently very limited in voltage due to budget reasons. We designed the motor (rewound motor) for 320V, and even that did not include any leeway for momentary acceleration at higher speeds, and now we are at 96V minus sag. This limits the electrical power to about 10 kW and top speed to about 50 km/h. So we haven't yet been able to demonstrate how the motor performs during the "real deal", which is overclocking to 150Hz, producing 25-30 kW out of a 7.5 kW industrial motor. But the control algorithm clearly works - and what's best, it indeed is very simple, about two orders of magnitude simpler than a proper FOC.









Constants shown are the actual values used in the video. Numerical ranges are examples of "typical" values. Constant multiplicants (mostly bit shifting) omitted from the picture.


----------



## Stiive (Nov 22, 2008)

Hehe, at the end of the 3rd person video you can still hear the controller going through the octaves.

Congrats though - very cool 
Better make the brake lights come on with regen.

AND your school reminds me of what earth will look like after the zombie apocalypse


----------



## Siwastaja (Aug 1, 2012)

Hi Stiive,

Yes, you have it exactly right! There indeed was a zombie apocalypse here, but don't worry, I'm with the zombies now.

How is your dead-scientist-named complex vector hyperspace 3D sci-fi driive doing by the way? 

(Our secret ingredients are actually cable ties and tape, so it's pretty simple.)


----------



## PStechPaul (May 1, 2012)

That's very encouraging. It just makes sense that an ACIM will have a slip frequency that is proportional to torque, although the maximum slip may depend somewhat on speed (locked rotor torque vs breakaway torque). As long as the slip stays within those limits, the motor should perform efficiently. At higher levels of slip it will probably resemble the acceleration of an ACIM on a fixed voltage and normal line frequency, which is pretty much how all motors were started until 20 years ago or so when VFDs became prevalent. There were also some reduced voltage motor starters that used SCRs or other means to reduce start-up current, but it's not going to hurt anything (other than efficiency) to apply full voltage at rated frequency without regard for speed. 

It seems simple enough to have a basic fixed V/F but also allow a higher voltage or reduced frequency to allow torque boost or field weakening. The only inconvenience to the controller as you show it is the need for speed measurement using some sort of sensor. But I think it may be possible to control the motor without sensors simply by knowing the driving frequency and measuring the current to derive the slip, and so the actual speed would be drive speed - slip (where slip could be positive or negative). This would only work when the current is within normal limits of torque, of course, but if the controller and motor got out of sync it should be possible to adjust the drive until the current returned to normal (or zero for synchronous speed). 

Thus you could even just read the DC link current for torque, and the RMS value of the motor voltage, as the only inputs to the controller other than the operator throttle setting. And that could be based on torque for acceleration as well as speed (for "cruise control"). Can it really be that simple?


----------



## Stiive (Nov 22, 2008)

Siwastaja said:


> Hi Stiive,
> 
> Yes, you have it exactly right! There indeed was a zombie apocalypse here, but don't worry, I'm with the zombies now.


lol



Siwastaja said:


> How is your dead-scientist-named complex vector hyperspace 3D sci-fi driive doing by the way?


It's actually going really well.... Final revision (I hope) is in the mail as we speak. 

Testing in a 38 seater bus will begin in the next few weeks. 


If it doesn't work, the plan is to learn to how to raise the dead to ask the zombie scientist support team - unless they're there with you already?


----------



## Siwastaja (Aug 1, 2012)

PStechPaul said:


> That's very encouraging. It just makes sense that an ACIM will have a slip frequency that is proportional to torque, although the maximum slip may depend somewhat on speed (locked rotor torque vs breakaway torque). As long as the slip stays within those limits, the motor should perform efficiently.


No - that is incorrect. What you describe is how it works when driven from the wall or in V/f mode, and it's exactly the reason why it is inefficient. That should be avoided, and that's the whole purpose of the proper slip control which controls VOLTAGE and keeps slip constant (at the optimum point; which is not exactly constant, but we come to it later). It is also much easier to do it right as we show:

The slip is kept at single optimum point, which in our case is the nameplate value (1440 rpm -> 2 Hz slip). VOLTAGE is varied to control torque, not slip. You can see this happening in so called "field weakening". So, slip is always either 2 Hz (acceleration) or -2 Hz (regeneration). There is no problem in changing the sign suddenly, as the voltage goes through 0.

As shown, slip may be increased if more torque is requested than the battery pack can supply, as it is the only option to force more current into the motor. This is a kludge that is not needed in a properly designed system (enough voltage).

What FOC and DTC add here is that they automagically determine the optimum slip. Contrary to what I state above, unfortunately, the optimum slip is NOT a constant, but depends on the rotor temperature which is hard to measure, and FOC/DTC can work it out without measuring it. Our slip control cannot. Maybe we add some sort of crude compensation, maybe not. We have not yet been able to make the motor heat up enough to see any problems.

About the rotor speed, it is so easy to add an encoder that you really should. It is much easier to work with a reliable direct measurement instead of any kind of algorithm that tries to deduce it somehow. Many FOC/DTC implementation apparently use encoders anyway. Rotor temperature is much harder to measure exactly!

[Disclaimer: I'm still not 100% sure about everything. I'm just stating what it looks like to me currently.]


----------



## subcooledheatpump (Mar 5, 2012)

*







*​ 

I found this table in a guide for using VFDs with induction motors. ​

So it seems you are correct. My findings also support your ideas. I've done tests on various induction motors and for the most part, more voltage means more torque. ​ 
What is interesting to me, as you say, increasing slip can help to a point but if the slip is too great the current only increases without an increase in torque. More voltage, even 4 times rated voltage produces more torque but yet lower currents than a slip frequency which is too high.​


----------



## Siwastaja (Aug 1, 2012)

That table is useless for this discussion because it is a constant frequency case and shows the slip changing. Hence, most of the effects shown are actually resulting from the changing slip, not from the changing voltage. Slip control keeps slip constant and only changes the voltage.


----------



## Siwastaja (Aug 1, 2012)

stickytechnology said:


> There is one advantage to the closed-loop slip idea over DTC, which is you don't need accurate current sensing at all. IGBT desat should be enough overcurrent protection.


I was rereading through the thread (oh, I'm feeling nostalgic), and have to quote this because this is a very good point. Our 150A IGBTs are still feeling well, and no faults from the desat detection yet.

Highest currents we have seen on the DC bus with a typical cheap clamp meter has been around 140-150A.

The "math" is so simple (as it explicitly includes the V/f relationship) that it's easy to understand nothing destructive should happen. Motor inductance keeps things pretty clean.

We have the current and DC bus voltage measurement HW ready to go but not in use as of yet.

But we are having fun with a REALLY minimalistic setup: IGBT half-bridge modules, a few capacitors, a bit of copper and off-the-shelf IGBT gate driver ICs with small simple PCB's (as per application notes). And an off-the-shelf FPGA development board. Many MCU dev boards would work too. (But not Arduino .)


Also when rereading the thread, it looked like many people have tried some kind of "slip control" but failed to get really usable results. Now it seems obvious that they have done something really wrong. Then, not believing in the simplicity of the subject, they have most likely tried to come up with remedies to fight those problems, thus creating "complex slip controls" that work better than their first versions but still not quite well because the underlying problem was not fixed. (It's easy to say it now...)

Some ideas what might have gone wrong (based on "been there, done that"):

- Trying to control torque by controlling slip instead of voltage ("slip control" - do not touch the slip - not the most descriptive name out there)
- Using relative slip (%, multiplication) instead of absolute (Hz, addition) (and slips are often given as %; again confusing!)
- Setting wrong slip
- Failing to get correct RPM readings from encoder (for example, at low RPM)
- Lack of any voltage boost (constant addition to the voltage command)


----------



## subcooledheatpump (Mar 5, 2012)

Siwastaja said:


> That table is useless for this discussion because it is a constant frequency case and shows the slip changing. Hence, most of the effects shown are actually resulting from the changing slip, not from the changing voltage. Slip control keeps slip constant and only changes the voltage.


Yes it is for constant frequency, but it still shows how the voltage controls torque, which should be good for any frequency. 

It also shows the relationship between voltage and slip, even if at constant frequency. Don't you think the same effect would happen at lower frequencies?

Instead of a percent of nameplate voltage, it should be a percent of the voltage according to the set V/F ratio. 

Just an example if an industrial induction motor were say, 240 volt at 60 Hz, then it should run at 120 volts at 30 Hz 

So doesn't increasing the voltage at 30 Hz still have the same effect as increasing at 60 Hz? 

More interestingly, it still shows how slip is related to voltage, which as you describe is essentially slip control, using voltage to control slip. Which again, isn't that valid for any frequency? If the voltage is increased relative to the V/F ratio then shouldn't the slip fall regardless?

Sorry I'm just thinking out loud here


----------



## PStechPaul (May 1, 2012)

I don't think it is correct to keep the slip at a constant (rated) value, because it seems that the rated slip only applies at the rated RPM and torque. I found some information that seems to confirm this:
http://www.engineeringtoolbox.com/electrical-motor-slip-d_652.html









So, for a constant torque, the slip will remain constant over a wide range of RPM (as long as a VFD is used and V/F remains approximately constant). But at a given speed, under a range of load (as in an EV with cruise control), the slip will vary between the limits of breakdown torque, both positive or negative (although I'm assuming the curve is symmetrical about synchronous speed).

As far as efficiency is concerned, it is dependent upon the total losses and the actual power produced by the motor. As slip and torque increase, the current increases and the losses are mostly resistive (and increase with temperature), and efficiency drops because the power increases linearly with torque or current, while losses increase according to the square of current. Thus it seems that efficiency should increase below rated torque, although only up to a point, since there are other losses due to friction, windage, magnetizing current, and core losses. Friction, windage and core losses increase with frequency, while I think magnetizing current may be constant with a fixed V/F, since it is a function of inductance. But it is not exactly linear and is subject to saturation as well as the magnetic gap of rotor to stator.

But I agree that an RPM sensor may be well worth the cost and added complexity, especially for larger motors as used in full size EVs.


----------



## subcooledheatpump (Mar 5, 2012)

But if you are using cruise control then the speed of the motor should be constant right? so then naturally the frequency would stay constant and so would the slip. 

If the torque requirement would go up to maintain speed (IE hill climb), just increase the voltage to maintain the slip

The graph is just for direct on line starting. The torque curve is different for a VFD

I get what you're saying but the constant slip-variable voltage control does seem to be very simple


----------



## PStechPaul (May 1, 2012)

If the speed of the motor (and vehicle) is held constant, then the frequency (and slip) must change to meet the changing load caused by going up and down hills and from wind. If you hold the frequency constant the motor speed will change up to the maximum slip at breakaway torque.

You may be able to hold slip constant at a given speed by changing the voltage, but I don't think it's a good idea. This will just cause more current to flow in order to maintain the torque, so the efficiency will be reduced, and this violates the V/F parameter and causes field weakening.

The right side of the graph applies to a motor running at a fixed frequency and rated voltage at that frequency, and shows what happens when torque changes as a result of load variation. A VFD will normally try to obtain the best operating efficiency by reducing slip. It should be possible to calculate the efficiency by using the characteristic motor curve. The input power can be determined easily by the product of DC voltage and current. The output power can be calculated by determining the torque and shaft RPM, which involves knowing the slip and reading the output torque from the curve. 

This may be where the shaft speed sensor is important so the actual slip may be measured, and then torque can be read from the curve. I'm not sure you can estimate the torque accurately enough from the current and drive frequency, because there may be many combinations that will result in the same calculated value of slip. But then again, the current curve implies that it has a specific relationship to % synchronous speed, and thus a unique value of slip (assuming a fixed voltage and frequency).


----------



## subcooledheatpump (Mar 5, 2012)

This seems a little silly, but I think somewhat related 

http://industrial-embedded.com/articles/the-versus-field-oriented-control/

EDIT: I do understand what you're saying. There is a slip for maximum torque and a slip for maximum efficiency. But it is also true that increasing voltage does increase torque, and sometimes increases efficiency. Refer back to the table I posted.

Yes it's true increasing the voltage does increase current, I agree. Increasing slip also increases current. Isn't current what controls torque anyway?


----------



## Siwastaja (Aug 1, 2012)

Subcooledheatpump;

No, voltage does not control slip, slip is controlled in closed loop to artifically keep it constant *by controlling frequency*. This is the easiest way from the very definition of slip.

Paul:

The graph you show describes how induction motor gives torque _*when driven from a fixed frequency*_. It describes a real-world phenomenon, it is not a graph to show "how to drive the motor optimally".

Yes, ACIM gives different torques with varying slip, but with POOR EFFICIENCY. You can find similar images that plot efficiency and power factor. That is *exactly* the reason why FOC/DTC/etc. (and constant slip control) do exist. You don't want to imitate the "fixed frequency torque control" because it gives bad results.

For example, if you reduce torque by reducing slip driving near synchronous frequency (called "no-load" when driven from fixed supply), the power factor is horrible, there is unnecessary energy transfer back and forth. It causes extra losses. This is why you reduce voltage in this case, which increases slip so that it is again at optimum point - no power factor issue anymore. But now, it doesn't make sense to do it with so much difficulty, as you can control slip directly by controlling frequency. 

Gas pedal = voltage, and automatic adjustment of frequency to force the optimum slip does everything automagically.


--

You still seem to be under the same wrong impression I was in my first post. I won't try to force it more than this. You either get it or then you don't. If you don't, good luck with trying to understand FOC or DTC...


----------



## Siwastaja (Aug 1, 2012)

subcooledheatpump said:


> This seems a little silly, but I think somewhat related
> 
> http://industrial-embedded.com/articles/the-versus-field-oriented-control/


A _great _article, thanks! Clearly, the subject has been debated on coffee discussions.

To sum it up:

FOC, DTC and slip control provide very similar results in many cases. They practically do the same.

But, FOC and DTC are more advanced and give some extra benefits with the cost of increased complexity.

If you can get the motor parameters right, FOC/DTC provides:
- Automatic compensation of rotor temperature
- Possibility to increase the transient response at the expense of efficiency, if you need it.

FOC/DTC does NOT automatically give both increased efficiency AND transient response. Instead, it gives you the choice dynamically. Slip control leans towards good efficiency and worse transient response. So if you run your system with some kind of default settings, a slip control probably has _better_ efficiency than FOC. FOC uses more parameters, and usually people seem to want it to have good transient response.

And finally, if I may repeat, if you find that your slip control needs kludges and add-ons that make it almost as complex as FOC to work, you have just done something wrong on the very basic level.

-----


*Implementing the slip control has been fun and has been a very educational experience. It truly helps to understand what's really going on in FOC.* It was not a "kludge" in any way, but a very basic and traditional control scheme which clearly demonstrates the control properties of an ACIM, which makes understanding the more advanced schemes a lot easier.


----------



## subcooledheatpump (Mar 5, 2012)

I think I get what you're saying. 

Of course voltage doesn't control slip directly, but if for example, the torque load is too great and the voltage is too low the slip will increase and eventually the motor will stall. (and of course the closed loop control tries to correct this) I just speculate that you don't want to stray too far from the original V/F pattern under full load, and of course then turn down the voltage under light load.

Just trying to wrap my head around what the CPU/DSP is actually telling the power stages to do at various speeds and torques. 

Still learning so please keep posting.......


----------



## PStechPaul (May 1, 2012)

Perhaps another way of looking at motor control is that the only parameters you can control directly are voltage and frequency. Current, phase angle, power factor, torque, speed, slip, power, losses, and efficiency, are all a result of the drive parameters interacting with the motor and the load.

So at a given speed and load, there are several ways that the motor can be driven, and the idea is to do so in the most efficient way possible. One may assume that the maximum efficiency of the motor will be at rated torque and rated voltage, at which the rated slip will occur. If you increase the voltage, without changing frequency, more current will flow, resulting in more torque, and in an EV this will result in acceleration to a higher shaft speed. Thus the slip will decrease. This is illustrated in the chart for applied voltages 10% high or low. The same graph shows an increase and decrease in efficiency but this may also be a result of the increase and decrease of power.

What the chart does not show is the performance with a true constant torque load. The constant torque would be equivalent to maintaining a fixed speed on a fixed slope, where the operator (or cruise control device) adjusts the motor parameters to hold speed (and torque) constant. This corresponds to various combinations of voltage and frequency, and thus modification of the V/F parameter, which will affect slip. The question is if a higher value of V/F (and lower slip) results in greater efficiency. The chart indicates that torque is proportional to the square of the voltage, while the slip appears to be close to an inverse square. So a 10% increase in voltage produces 21% more torque and 17% less slip.

But the chart shows 7% lower current at 10% higher voltage at full load, and this is where there seems to be a discrepancy. Under a constant torque load, the current would be expected to remain constant and the increased voltage would just result in a lower power factor. It does not make sense that the actual torque would increase, but there may be more available torque because of the lower slip. 

If current is actually proportional to torque over a range of voltages, then the only parameters that will change are power factor and slip. But since the inductance of the motor is subject to saturation, the current may increase with higher voltage and a fixed torque load, which may decrease efficiency.

Going the other way, decreasing the voltage, results in a larger value of slip and perhaps less saturation and magnetizing current, as well as a higher (better) power factor, so this may result in better efficiency. It should be possible to monitor the actual efficiency of the motor under various combinations of V/F and speeds and torque (and power), and make adjustments "on the fly" to optimize efficiency. It may be difficult to measure efficiency by direct power measurement, especially for high efficiencies of 95% or more are expected, because a 1% error can show efficiency of 94% to 96%. Perhaps a better method is to read the losses, which can be determined by temperature rise over a period of time. There will be a great deal of difference for losses of 6% and 4%. 

I think it would be worthwhile to run some tests to determine parameters for best efficiency. But I also think less complex controls with simpler sensors may have their own merits even if they are slightly less efficient. And I would also like to examine the relative efficiency of using a larger or smaller motor for the same power output, and the pros and cons of rewinding and overclocking and using higher grade/thinner laminations. And then there is the point where perhaps a SRM design may be better in all respects once you get into rewinding and custom builds anyway.


----------



## Siwastaja (Aug 1, 2012)

subcooledheatpump said:


> Of course voltage doesn't control slip directly, but if for example, the torque load is too great and the voltage is too low the slip will increase and eventually the motor will stall.


No it won't, because the frequency will be lowered to keep the slip constant all the time. Then, the speed will slow down as a consequence.


This results in exactly TORQUE control, not speed control. But torque control is what we want.

There is NO single P, PI or PID controller or anything like that. There is no internal state in the control.

(We of course placed a filter in the pedal value signal that removes sudden spikes and smooths the transitions. But it can be kept totally outside of the algorithm.)



> and of course then turn down the voltage under light load.


You do it by rising your right foot off the accelerator. If you don't, you won't have "light load", and the car will accelerate as a consequence.


--

The problem here is that people are thinking in the terms of industrial motor control, which means controlling the speed and maybe having random physical loads coming and going (not really, but it's marketed that way).

In a car, YOU create both the load and the torque by pressing or releasing the pedal, and speed is what results in. If the road gets steeper, you just lose speed if you don't press the pedal further. This is how it works in a gasoline car, all OEM electric cars and all off-the-shelf DIY motor controllers, DC or AC.

Current = torque.

You decide the torque, controller controls current via the voltage. Just like a DC controller works.

Slip control = Normal DC motor control + one extra line of code.


The slip doesn't change as it is always controlled _directly_. It is not about "trying". It is about controlling it. It is ONE single f***ing line of code:

f_out = f_in + slip, where f_in is the measured rotational frequency of the rotor using an encoder.




> Just trying to wrap my head around what the CPU/DSP is actually telling the power stages to do at various speeds and torques.


See the figure I posted.


----------



## subcooledheatpump (Mar 5, 2012)

Yeah I get what you mean. In an industrial application there isn't any compensation, then the motor would stall. But of course with a closed loop system it wouldn't, that's the whole point of it anyway. 

That is quite impressive, one line of code. 

I assume that is just for slip control though.. and there is a whole lot more for the rest of the parameters

How hard is it to get a simple (8 bit?)microprocessor to run an induction motor with the needed parameters? I'd like to try it but I'm afraid I may not have enough information on the subject to make it work properly...


----------



## Siwastaja (Aug 1, 2012)

PStechPaul said:


> Perhaps another way of looking at motor control is that the only parameters you can control directly are voltage and frequency. Current, phase angle, power factor, torque, speed, *slip*, power, losses, and efficiency, are all a result of the drive parameters interacting with the motor and the load.


No you are TOTALLY wrong here (so I don't even bother looking at your post further).

Slip is nothing that "results in", you can always control it directly. That's the whole point of the slip control. Only the resolution of the encoder (and how often the actual sine-wave generation unit can change its frequency) affects the response time and accuracy of the control*

Make sure you understand this.

*EDIT: Yes, at aggressive throttle setting, we do see an effect that when we suddenly press pedal to the metal at zero speed, the car cannot utilize the full acceleration speed, because the frequency cannot be updated quickly enough due to only 8 slots per rev in our encoder and wave generation module updating frequency only once per full cycle (e.g., 4 times per second at 4Hz) . This means the slip decreases for a very short time, motor approaching synchronous speed. In practice, this reduces 0-anything time by about 0.5 seconds under full acceleration.


----------



## Siwastaja (Aug 1, 2012)

subcooledheatpump said:


> How hard is it to get a simple (8 bit?)microprocessor to run an induction motor with the needed parameters? I'd like to try it but I'm afraid I may not have enough information on the subject to make it work properly...


The three-phase wave generation needs some HW resources. At least Microchip has a series of PIC controllers that have three PWM generators that can be synced and deadtime generation.

And to be fair, our FPGA code has become a bit complicated in the wave generation part. At least when compared to the slip control algorithm.

Slip control algorithm itself is so simple that the wave generation (from frequency and voltage commands) is one order of magnitude more complex.

We use the traditional way of an up-down counter that is compared to a lookup table of sine values.

A 3-phase PWM capable microcontroller implements that "up down counter" part in HW, and you just need to store the sine wave table and input new sine values.

Or you can use the space vector blah blah algorithm if you want to. The result is the same.


----------



## Siwastaja (Aug 1, 2012)

Siwastaja said:


> The three-phase wave generation needs some HW resources.


Okay, here you are; simulation waveforms that show exactly how our wave generation works (deadtime included). It's easiest to describe just showing the waveforms. Then you can implement it in any way you want to.

(This doesn't show how the voltage is controlled -- it is maxed out here. But just scale the sine value by multiplying it with the voltage and that's it. At zero voltage, you have PWM with 50% duty cycle in all phases. A motor emits faint noise but doesn't take any relevant current.)


----------



## Siwastaja (Aug 1, 2012)

And hey, this project and codes will be openly published pretty soon (I'm not saying "opensourced"; some limits may apply) so just buy a small FPGA board and get the codes from me and you get a motor running .

I have THIS: http://www.ebay.com/itm/Altera-Cycl...913?pt=LH_DefaultDomain_0&hash=item3a6cf2ba59 (needs also a programmer cable, see: http://www.ebay.com/itm/USB-Blaster...851?pt=LH_DefaultDomain_0&hash=item2ec6a1fe93 ) and I'm running a V/f two-phase controller based on the same code on it to run a 16mm film projector at variable speeds. Works.

Our car is using a much bigger Altera/Terasic DE2 development board but the whole design should (at least now) fit pretty well to that small Chinese board. No guarantee given anyhow.


----------



## subcooledheatpump (Mar 5, 2012)

Thank you very much. 

I'm looking at a microchip and TI development kit for induction motors. 

has the microcontroller with preloaded code, a programmer, debugger and power stage. The Microchip board says it uses FOC and the TI board says it uses SVM

Not sure if I want to buy yet but I'm considering it.


----------



## Siwastaja (Aug 1, 2012)

Well, probably the next step for us is to implement FOC on FPGA by looking at some Microchip/etc. Application Notes that implement the FOC in C. Or DTC...

Could have done this in the beginning, but didn't understand the FOC well enough at that point. (Read: had no f***ing idea. Now we at least understand _most_ of it.) Now we have found out that it's common knowledge that slip control is a usable and much used torque control scheme (not comparable to V/f at all), but it's so trivial that nobody writes about it; and FOC is a "high-end" version which does the same, but when done right, can do a lot more.


----------



## PStechPaul (May 1, 2012)

Quote:
Originally Posted by *PStechPaul*  
_Perhaps another way of looking at motor control is that the only parameters you can control directly are voltage and frequency. Current, phase angle, power factor, torque, speed, *slip*, power, losses, and efficiency, are all a result of the drive parameters interacting with the motor and the load._



Siwastaja said:


> No you are TOTALLY wrong here (so I don't even bother looking at your post further).
> 
> Slip is nothing that "results in", you can always control it directly. That's the whole point of the slip control. Only the resolution of the encoder (and how often the actual sine-wave generation unit can change its frequency) affects the response time and accuracy of the control*
> 
> Make sure you understand this.


What I am saying is that the only way to operate a motor and change what it does is by supplying more or less voltage, and a higher or lower frequency. PERIOD. You cannot build a "slip generator" and feed it to a motor. It is all about what you can feed it, and anything else requires measurement of something that may be able to produce a certain amount of slip, but that would be determined by a voltage and a frequency. You can diddle with the PWM carrier frequency to obtain changes in performance, but that is only because PWM is far more practical and efficient compared to something like a linear amplifier that would create a pure sine wave. Or you can introduce harmonics by distorting the waveforms and maybe get a little better performance, but that is still really just introducing another frequency component to the voltage. 

If you would bother to read the rest of my post, you will see how I explain what I am trying to say, and perhaps it will help someone gain some understanding of this subject. I certainly don't claim to have all the answers. But I sure do know that "slip" is a parameter that must be based on a measurement, or at least on a known motor characteristic that is obtained at a certain voltage and frequency. Of course it also depends on the mechanical load applied to the motor, if you want to consider it as an input. And also, of course, there may be a signal from the operator to set or maintain a certain torque or speed.


----------



## Siwastaja (Aug 1, 2012)

PStechPaul said:


> What I am saying is that the only way to operate a motor and change what it does is by supplying more or less voltage, and a higher or lower *frequency*.


Now, check what the definition of slip is.... It is a frequency. You can control it directly, by controlling, tadah, frequency!



> It is all about what you can feed it, and anything else requires measurement of something that may be able to produce a certain amount of slip,


No, this is wrong, you are totally off. It is not analogous to driving voltage to cause a current. You don't measure "something". The definition of the slip includes two frequencies, you measure the other and set the other.

It is not as it is when driven from the 3-phase wall.

You don't drive anything and expect it to cause a certain slip. You DIRECTLY drive the frequency, and it DIRECTLY causes the exact slip, because you set it, by the very definition of what slip is. (Of course, you need to know the rotor rpm.) Simple isn't it!

Slip is not determined by voltage or anything else in the slip control. Of course, the slip TRIES to change all the time because of the laws you show, but you keep it in control all the time, which causes OTHER things to change; things that we want to change (such as the speed of the car).

(And it is not even a P controller. P controller would be a controller that controls something else with a certain multiplier term, and expects certain result. For example, control heater power and hope for correct temperature.)

Of course, due to limitations of the real world, the slip may not be 100% exactly what you set it at. But nothing is. Not voltage nor frequency. In practice, the slip can be updated only when you have a "fresh" measurement from the encoder, at which point you can update the output frequency to keep the slip. But our study has shown that this is not a problem in practice; we do have mere 8 encoder slots and our wavegen module updates values only once per full cycle; yet it works just fine. It would be no problem to update to, for example, 64 slots per rev and several updates per cycle.

Slip control is analogous to you setting a price for a product, to get, say, $20 profit. You buy for $100, add $20 and sell for $120. It works directly, not through any other mechanism. You just need to know ("measure") the price you buy it for, and you can only decide the price you ask for it (it wouldn't make sense to say: "My profit is $20", the buyer wouldn't know the price; but you say: "I will sell you this for $120", outputting a frequency). Then, automagically, it is true that your profit (slip) was exactly $20.

In systems where you CANNOT CONTROL FREQUENCY, slip is a variable that results in from all other parameters, as you say. V/f is such a system, even though the frequency is a parameter, because it is not automatically updated based on rotor RPM.

Note that most ACIM material is talking about fixed frequency usage. I cannot stress it enough how different that world is. It has a lot of terms that are totally irrelevant for us, and the relationships are very different. 

I have found it is simply impossible to try to talk about ACIM's with people who have their background in direct 3-phase wall power usage.

The only problem here is that you just don't understand it. But take it or leave it.


----------



## gunnarhs (Apr 24, 2012)

Siwastaja said:


> Our super duper simple slip control is working perfectly fine. Absolutely nothing to complain about at this point. (We need to build the proper motor mount however!)


Congrats to your project and respect for carrying on your concept and improving your (and our) knowledge on VFD use in EV! 

As I suggested in my first post here in the thread you have created a frame for your drive-train and you can now continiously improve it. But what is more important is, as you point out, to get a understanding of the basic problems of the motor which do cause the same problems regardless of control-type
(temperatur, inertia etc)

In my case I have chosen to improve the VFD (V/f) by adding a current control based on the same concepts like DTC (using Space vector Modulation and Clarke-transformation but not Park which in my opinion is the distinction between DTC and classic FOC) to improve handling load changes. This has been working well for standard industrial motors of size up to 15 kW (I use maximal 2 x to get maximal power, in this case 30 kW).

Recently I have been testing another motor from Siemens which has much more power and unfortunately a lot of inertia and I have not yet beeing able to control it like I would like (before putting it into a vehicle). So there is always a way to improve the concepts and there is no one way to do it in my experience.

So good luck with further progress on this ...


----------



## stickytechnology (Sep 19, 2010)

Siwastaja said:


> I was rereading through the thread (oh, I'm feeling nostalgic), and have to quote this because this is a very good point. Our 150A IGBTs are still feeling well, and no faults from the desat detection yet.
> 
> Highest currents we have seen on the DC bus with a typical cheap clamp meter has been around 140-150A.


Thanks for the shout out  



Siwastaja said:


> Some ideas what might have gone wrong (based on "been there, done that"):
> 
> - Trying to control torque by controlling slip instead of voltage ("slip control" - do not touch the slip - not the most descriptive name out there)
> - Using relative slip (%, multiplication) instead of absolute (Hz, addition) (and slips are often given as %; again confusing!)
> ...


I think there is a bit of a problem with your algorithm, though. First, controlling torque through voltage will work, as there is a quadratic relationship between torque and voltage, all else held constant. Problem is, you can quickly get into saturation. The flux (voltage times time) can't really exceed the rated values by much. This is a function of how much iron is in your motor. You will probably run into this once you increase your bus voltage. Second, your idea of using absolute slip will work too, as you are essentially finding the rotor time constant (constant frequency slip = 1/rotor time constant). Problem there is, the rotor time constant might change by a factor of two or three depending on the temperature and magnetic saturation.

That's the brilliant thing about the DTC algorithm, is it doesn't use any of these "constants". 

The other thing that DTC does well is that it gets rid of the idea of voltage and frequency entirely. The voltage source inverter is at heart a digital device- it's either on or off. It doesn't apply any voltage but the bus voltage or zero, and it certainly doesn't apply anything resembling line frequency. The trick is to choose the switch states from a table to get the flux and currents in the motor to do what you want. The whole sinusoidal PWM + 3rd harmonic business is just a holdover from people thinking about applied voltage as a continuous, smooth function, which in an inverter it's anything but.

OK, enough DTC evangelism. You'd think I work for ABB 

Cool videos- looking forward to seeing more.


----------



## Siwastaja (Aug 1, 2012)

stickytechnology said:


> Problem is, you can quickly get into saturation. The flux (voltage times time) can't really exceed the rated values by much. This is a function of how much iron is in your motor.


Exactly. So, the torque command needs a limiter. However, we have gone to pretty high values, higher than I originally anticipated, without ill effects. But I recognize that with a more precise control scheme, we don't need to leave the leeway we currently need to have in order to avoid saturation. This way, FOC or DTC can utilize all the torque better.



> Second, your idea of using absolute slip will work too, as you are essentially finding the rotor time constant (constant frequency slip = 1/rotor time constant). Problem there is, the rotor time constant might change by a factor of two or three depending on the temperature and magnetic saturation. That's the brilliant thing about the DTC algorithm, is it doesn't use any of these "constants".


Exactly! This confirms what we have been thinking about. Thank you for pointing it out. In a nutshell, FOC and DTC "automatically" determine the actual rotor flux, even in the case of changing rotor resistance, by integrating the actual current the motor takes. (FOC needs a lot of constants, though.)




> The other thing that DTC does well is that it gets rid of the idea of voltage and frequency entirely. The voltage source inverter is at heart a digital device- it's either on or off. It doesn't apply any voltage but the bus voltage or zero, and it certainly doesn't apply anything resembling line frequency. The trick is to choose the switch states from a table to get the flux and currents in the motor to do what you want. The whole sinusoidal PWM + 3rd harmonic business is just a holdover from people thinking about applied voltage as a continuous, smooth function, which in an inverter it's anything but.


Thanks, I have been thinking along these lines, but you said this very clearly.

DTC also has the advantage of fewer parameters and less parameter tuning over FOC. This is something we want to try.

The reason we implemented the slip control is that we want to be able to compare the algorithms in a real-world application against each other. But before we can do that, we need a larger, higher-voltage battery pack.

Due to the low weight of this test car, we may need to downgrade the motor to a smaller one first to better show the difference of the algorithms.


----------



## gunnarhs (Apr 24, 2012)

I have to add my "been that done that" to this


> That's the brilliant thing about the DTC algorithm, is it doesn't use any of these "constants".


Well it uses other "constants" like inductance + resistance which also change with temperature and frequency. 


> The other thing that DTC does well is that it gets rid of the idea of voltage and frequency entirely.


In a constant speed (variable torque) application maybe...
In other applications, speed (frequency) feedback is usually used.
And in all Inverters I know bus voltage is monitored too during DTC. 
Usually to shut it down when bus voltage differs about 20% from "recommended" voltage 



> The voltage source inverter is at heart a digital device- it's either on or off. It doesn't apply any voltage but the bus voltage or zero, and it certainly doesn't apply anything resembling line frequency. The trick is to choose the switch states from a table to get the flux and currents in the motor to do what you want.


This basic DTC results indeed a very fast but violent torque behaviour with high ripple when load changes quickly. The other disantvantage is the variable switching frequency for the IGBT's. The result is most often switching in the range from 2 kHz - 10kHz, makes a painful sounding Inverter too...


> The whole sinusoidal PWM + 3rd harmonic business is just a holdover from people thinking about applied voltage as a continuous, smooth function, which in an inverter it's anything but.


A good inverter makes a smooth sinus for the motor and the motor thanks it with good sound and long live A crude inverter can be helped by a filter...
There is a reason why in modern DTC the Space Vector Modulation is used with constant switching frequency...


----------



## PStechPaul (May 1, 2012)

I suppose one could dispense with the frequency and voltage terms and instead use current and time, where you may be able to apply the bus voltage (which is essentially fixed) and observe the current in that leg of the motor and then turn off the drive when the inductance just starts to saturate, thus obtaining maximum torque. As the motor speeds up, the applied frequency will also rise, and the effect will be similar to a PWM drive with a fixed carrier frequency and a variable drive frequency that leads the shaft speed by an optimal amount of slip. But my point was, and still is, that a motor controller can only apply or remove voltage, and does so with a rectangular waveform with variable time on and off, which results in a frequency. 

Perhaps the PWM carrier frequency need not remain constant, but if it shifts into the audible range it can cause annoying noise and possibly harmful harmonics, and it needs to be limited because of the switching times of the IGBTs or MOSFETs. I liked the "debate" format of the link supplied earlier, where some of the trade-offs of either method are revealed. Mostly, you must balance efficiency against response time, and either method may be able to add some tuning constants to satisfy the desires and needs of the EV driver. And they can even be chosen by the driver as "performance" or "efficiency" modes.


----------



## Hollie Maea (Dec 9, 2009)

This is one of the best papers I have read on these subjects. Goes in great depth into DTC-SVM but also talks quite a bit about other schemes as well.

http://www.isep.pw.edu.pl/icg/pdf/phd/marcin_zelechowski.pdf


----------



## Siwastaja (Aug 1, 2012)

It seems to me that the PWM frequency doesn't make _so much_ difference at all as long as it is within sane limits. (Why would it? Of course there are relatively minor things like the bus capacitance.)

The inductance of the motor slows down the current changes anyway, otherwise the motor wouldn't work from direct wall input at all.

Ours changes between 3 and 6 kHz.

You can find a lot of videos on Youtube presenting different kind of trains with drives that are clearly designed to sound funny in different ways. Some use fixed PWM frequency, some use PWM frequency that changes with the base frequency with steps when it would get out of good range (just like our does), some use a combination of these (some use fixed first, then changing, some other way around), some play melodies, etc... Some designs clearly show that there were no technical, only artistic reasons for the scheme chosen. 

http://www.youtube.com/watch?v=_J9soWMGtJU
http://www.youtube.com/watch?v=YUux8rFoK00 "Do re mi fa inverter"
https://www.youtube.com/watch?v=YUux8rFoK00


----------



## Tesseract (Sep 27, 2008)

Siwastaja said:


> It seems to me that the PWM frequency doesn't make _so much_ difference at all as long as it is within sane limits. (Why would it? Of course there are relatively minor things like the bus capacitance.)


You are correct that PWM frequency can vary quite a bit and the motor will still operate, but I wouldn't say it is only relevant to minor things, nor would I characterize its effect on bus capacitance as a minor thing.

The lower the PWM frequency the more harmonic distortion in the current waveform, resulting in higher stator temperature and acoustic noise ("singing"), as well as higher stress on the bus capacitance (from higher ripple current, which results in heating according to I²[ESR]).

Too high a PWM frequency, however, results in higher losses in both the motor - proximity and skin effect losses in the windings; hysteresis and eddy losses in the "iron" - as well as the switches in the inverter. Higher PWM frequencies also demand that the transitions between on and off (or vice versa) happen more quickly, and that leads to more EMI and a subtle yet fiendish failure mode peculiar to PWM-driven motors (AC or DC, mind you): Bearing EDM (ie - electrical discharge machining).

On a side note, carrier-based PWM (aka "sine modulation") is decidedly inferior to space vector modulation techniques* for a number of reasons, but the primary one is that SVM can deliver a higher average voltage to the motor for a given DC link.


* - the use of plural implying there are a number of different SVM techniques, and each has its own pluses and minuses.


----------



## subcooledheatpump (Mar 5, 2012)

http://scholar.lib.vt.edu/theses/available/etd-09092002-112817/unrestricted/Thesis.pdf

I found this a while back, a study on switching frequency vs motor efficiency. 

What would really concern me, using a low switching frequency with a high bus voltage and a low inductance motor. Power stage may become unhappy.... 

I know for an industrial motor that usually inductance isn't a problem but some high performance EV motors actually require external inductance


----------



## Tesseract (Sep 27, 2008)

subcooledheatpump said:


> ...What would really concern me, using a low switching frequency with a high bus voltage and a low inductance motor. Power stage may become unhappy....


This problem has more to do with the fact that the switches must remain on for a minimum amount of time once they have been fired than the switching frequency, per se. But still a potential problem, yes.


----------



## gunnarhs (Apr 24, 2012)

subcooledheatpump said:


> http://scholar.lib.vt.edu/theses/available/etd-09092002-112817/unrestricted/Thesis.pdf
> 
> I found this a while back, a study on switching frequency vs motor efficiency.
> 
> ...


Thanks for posting this paper!
This could actually be some help for me for the Siemens motor behaving differently than the standard motors I have dealt with.


----------



## Siwastaja (Aug 1, 2012)

Tesseract said:


> On a side note, carrier-based PWM (aka "sine modulation") is decidedly inferior to space vector modulation techniques* for a number of reasons, but the primary one is that SVM can deliver a higher average voltage to the motor for a given DC link.


... because SVPWM creates a sine wave with 3rd harmonic (which is _very_ near to a simple sine wave with its peaks just clipped, to give an idea to those who have hard time imagining 3rd harmonic on top of another sine wave.)

Why compare SVPWM with pure-sine synthesis? If you synthesize PWM using traditional counter method (sawtooth or triangle wave), you most likely use a look-up table for the sine values (like we do). In this case, you can synthesize _any_ waveform you want as easily as pure sine wave. We do use a sine wave with 3rd harmonic added. The waveform is practically identical to what SVPWM creates, and indeed gives approx 15-20% higher base frequency AC voltage for the same DC bus voltage.

SVPWM however, AFAIK, allows less switching which would reduce switching losses.


----------



## stickytechnology (Sep 19, 2010)

gunnarhs said:


> I have to add my "been that done that" to this
> 
> Well it uses other "constants" like inductance + resistance which also change with temperature and frequency.
> 
> ...


Obviously I have to defer to experience if you've build a working DTC drive, but I'd like to point out that the resistance and induction that you are referring to are only second order corrections, and are of the stator, not the rotor, so are not prone to as large temperature variations (and can be measured on the fly). 

I think you misunderstood my comment about voltage. Bus voltage is the only thing that is real, and of course needs to be measured. Believing that you are applying anything but bus voltage to the motor, though, is magical thinking (except of course for the corrections that Stiive and I discussed at length in his thread).



gunnarhs said:


> This basic DTC results indeed a very fast but violent torque behaviour with high ripple when load changes quickly. The other disantvantage is the variable switching frequency for the IGBT's. The result is most often switching in the range from 2 kHz - 10kHz, makes a painful sounding Inverter too...


Any control system can be set up wrong. If the response is too fast, slow it down. The torque setpoint is a command from god to the inverter, it's true, but the torque control signal can be subject to whatever filtering you like. 
The variable switching frequency is a feature, not a bug. If you don't switch when you don't need to, you save energy. Maybe not as musical, but to each their own. Besides, you can set the tolerance band however you like, to produce whatever range of switching frequencies you like.




gunnarhs said:


> A good inverter makes a smooth sinus for the motor and the motor thanks it with good sound and long live A crude inverter can be helped by a filter...
> There is a reason why in modern DTC the Space Vector Modulation is used with constant switching frequency...


Wrong... no inverter produces a sinusoidal voltage. Measure it sometime . Sinusoidal current, sure, but there are awful voltage transients. As far as filtering, do you want to waste energy and risk unreliability in the filter or the motor? it's your choice... Modern motors have excellent winding insulation that is specifically designed for handling the high dV/dt of inverter drives. As far as SVM in DTC, sure I can see doing that- hexagons are inconvenient at times, but then the question is whether you want to switch fast enough to make it worth it. After awhile, the iron and switch losses eat you up.


----------



## gunnarhs (Apr 24, 2012)

stickytechnology said:


> Obviously I have to defer to experience if you've build a working DTC drive, but I'd like to point out that the resistance and induction that you are referring to are only second order corrections, and are of the stator, not the rotor, so are not prone to as large temperature variations (and can be measured on the fly).


Your DTC sounds very , very simple as if it was open loop (if you only use stator resistance). I had expected you would at least feed back the current info?
If you feed back currents and calculate from them the flux / voltage you need at least stator AND rotor induction parameters too. 
And the "second" order parameters can affect this calculation lineary at least.
See the table here http://en.wikipedia.org/wiki/Direct_torque_control
I have not applied switching table based DTC to our Inverter drive but we were thinking about it once as it looked very handy in implementation when using FPGA. 


> I think you misunderstood my comment about voltage. Bus voltage is the only thing that is real, and of course needs to be measured. Believing that you are applying anything but bus voltage to the motor


I was refering to your comment about getting rid of voltage and frequency (as parameters I did understand?), my answer to this is you are at least not going to avoid it for an inverter for an automobile. 
I think you are refering another thread for your mentioned parameter discussion, could not find it in this thread...?



> The variable switching frequency is a feature, not a bug. If you don't switch when you don't need to, you save energy. Maybe not as musical, but to each their own. Besides, you can set the tolerance band however you like, to produce whatever range of switching frequencies you like.


Unfortunately our electronic specialist told me this was not true when all is taken into account, I have to believe him in this case. It looked quite ok in the simulation I got in Matlab though 



> Wrong... no inverter produces a sinusoidal voltage. Measure it sometime . Sinusoidal current, sure, but there are awful voltage transients.


I provide here a picture of the voltage and current coming out of one phase of our inverter 2 years ago. Looks quite sinus-like to me...
http://www.diyelectriccar.com/forums/album.php?albumid=217&pictureid=1243 
This is not Space-Vector-PWM by the way but a sort of sinusodial-generation in the FPGA. We were using a "normal" resistance as load



> As far as filtering, do you want to waste energy and risk unreliability in the filter or the motor? it's your choice...


Yes I did use a filter even with our inverter producing quite good sinus.
This was to eliminate some unwanted harmonics.
After changing to Space-Vector-PWM, I am considering to skip it.



> Modern motors have excellent winding insulation that is specifically designed for handling the high dV/dt of inverter drives.


Unfortunately, the motors I am using do not have this kind of insulation.


----------



## PStechPaul (May 1, 2012)

gunnarhs said:


> I provide here a picture of the voltage and current coming out of one phase of our inverter 2 years ago. Looks quite sinus-like to me...
> http://www.diyelectriccar.com/forums/album.php?albumid=217&pictureid=1243
> This is not Space-Vector-PWM by the way but a sort of sinusodial-generation in the FPGA. We were using a "normal" resistance as load


Invalid link for the image


----------



## stickytechnology (Sep 19, 2010)

gunnarhs said:


> Your DTC sounds very , very simple as if it was open loop (if you only use stator resistance). I had expected you would at least feed back the current info?
> If you feed back currents and calculate from them the flux / voltage you need at least stator AND rotor induction parameters too.
> And the "second" order parameters can affect this calculation lineary at least.
> See the table here http://en.wikipedia.org/wiki/Direct_torque_control
> I have not applied switching table based DTC to our Inverter drive but we were thinking about it once as it looked very handy in implementation when using FPGA.


I'm afraid we're still misunderstanding each other, and I don't want to derail from talking about closed-loop slip control any more (which I looked up in my textbook and got almost a whole page on, btw ), but before we go on I just want to clarify that I mean something very specific when I say "DTC":

-First, all vectors are in the stator reference frame. You can forget about the rotor from now on
-Measure two phase currents and bus voltage every 40 microseconds or faster
-Estimate motor flux linkage vector by integrating bus voltage times the switch state vector by time between samples. If you feel fancy, you can add a correction term to the bus voltage that is current times stator resistance, and another term to correct for the switch voltage drop. 
-Estimate torque as the cross product of the flux linkage vector and the current vector.
-Select new switch states from a table so that the magnitude of the flux linkage vector is kept in a tolerance band, and the torque magnitude and direction is kept in its tolerance band. The only assumption is that the current vector lags behind the flux linkage vector because of the time constant of the motor. No assumption is made about the rate of lag, or any other motor parameters. If you like, estimate motor speed by taking Fourier transform of current vector.
-Measure again and repeat

And, yes, very very simple, conceptually at least. In practice difficult enough that I went and bought an ACS800 on ebay  

In other words, basic, open loop DTC with no SVM, but with very precise and fast current and DC link measurement


----------



## gunnarhs (Apr 24, 2012)

PStechPaul said:


> Invalid link for the image


Sorry Paul, my Album was private, try the link again and let me know if it still does not work...As bonus you should get more pictures when you click on my profile name



stickytechnology said:


> I'm afraid we're still misunderstanding each other, and I don't want to derail from talking about closed-loop slip control any more


I think we are getting there With closed loop in this case I referred though to feedback parameters regarding DTC, as mentioned in the link to wiki, not to the topic subject. 



> Specific when I say "DTC":
> 
> -First, all vectors are in the stator reference frame. You can forget about the rotor from now on


I like that very much As I assume that the slip is not constant all the time I have not seen the advantage of beeing in the rotor reference frame.



> -Measure two phase currents and bus voltage every 40 microseconds or faster
> -Estimate motor flux linkage vector by multiplying bus voltage by the switch state vector times time between samples. If you feel fancy, you can add a correction term to the bus voltage that is current times stator resistance, and another term to correct for the switch voltage drop.


In my case I would need the correction as I have batteries on the bus side and their voltage is rocking and dropping by time (additional to the switch Voltage drop)



> -Estimate torque as the cross product of the flux linkage vector and the current vector.


Yes, yes



> -Select new switch states from a table so that the magnitude of the flux linkage vector is kept in a tolerance band, and the torque magnitude and direction is kept in its tolerance band.


The inverters I know (which mostly use FOC or sort of DTC ) try to hold torque OR speed constant, they have no mixed mode. Usually their tolerance band is the bus voltage / igbt-current/temperature, what are the tolerances in your case e?
Can you give the inverter some other info it follows, maximum/minimal torque and/or speed?



> The only assumption is that the current vector lags behind the flux linkage vector because of the time constant of the motor. No assumption is made about the rate of lag, or any other motor parameters. If you like, estimate motor speed by taking Fourier transform of current vector.


Ok, it makes sense for fast torque correction I would worry about the efficiency in this case (?)
I prefer measuring and feeding speed back too as I have to do it in the vehicle.
for other purpses too.



> And, yes, very very simple, conceptually at least. In practice difficult enough that I went and bought an ACS800 on ebay
> In other words, basic, open loop DTC with no SVM, but with very precise and fast current and DC link measurement


OK, this is a quite new ABB-inverter I assume? I have used the 600-version with FOC, but there I had to feed at least 4 parameters (Stator and rotor R and L) and it used phase current (all 3), Bus voltage and speed feedback (optional but necessary if under variable speed condition). I had an "for you my friend only" offer of 5000 euros for the newest ABB (800 series as I remember) which included the new DTC (which has not been until recently(?)), I did not take it , what did you pay? 
I have been sceptic as the standard-inverters i have tested have not performed very well in my car so far but I would like to get any information I can on this new ABB type (without paying the 5000 Euros of course )


----------



## subcooledheatpump (Mar 5, 2012)

I have an ACS 600 in my van, it has DTC. 

In the parameters list it allows selection of "Scalar" or "DTC" under "Motor Control Selection" 

Makes really funny sounds, and the switching frequency changes all the time. Sometimes it sounds like shifting gears with a regular ICE and a transmission


----------



## stickytechnology (Sep 19, 2010)

stickytechnology said:


> -Estimate motor flux linkage vector by multiplying bus voltage by the switch state vector times time between samples. If you feel fancy, you can add a correction term to the bus voltage that is current times stator resistance, and another term to correct for the switch voltage drop.


Sorry correction to this. Flux linkage is the integral of bus voltage times switch state vector times dt. 

I'm not sure how important the switch voltage and IRs terms are.

That pic does look sinusoidal-- what is the switching frequency? I am still a bit skeptical that a filter will

a) be smaller than the motor for reasonably efficient switching frequencies
and
b) do anything for you performance wise. I understand the IEC has things to say about EMI, which this would help with, but I can't see how the motor would care.

If I was designing an AC drive from scratch, I'd put a DC-DC converter on the front instead- it would be awesome to drive a DTC inverter with a DC bus voltage that was roughly proportional to speed. You'd have next to no switch loss at low speed, and you could run one of the godawful low inductance motors from a high voltage bus without a ~1us cycle time.


----------



## stickytechnology (Sep 19, 2010)

gunnarhs said:


> The inverters I know (which mostly use FOC or sort of DTC ) try to hold torque OR speed constant, they have no mixed mode. Usually their tolerance band is the bus voltage / igbt-current/temperature, what are the tolerances in your case e?
> Can you give the inverter some other info it follows, maximum/minimal torque and/or speed?
> 
> 
> ...


Usually DTC does speed in an outer control loop, so it uses torque to control speed. This can be open loop (use FFT of current to estimate speed) if you don't want an encoder, or closed loop if you need very good performance near zero rpm. 

DTC has been around awhile in the higher end ABB drives. I know the ACS600 series has it and I think maybe the -500 does too. I paid $600 for my (25kW) drive, and it looks in good shape, but YMMV with ebay drives. The ABB website has quite a lot of good info, including installation and software manuals.

I'll start a thread one of these days where I'll share the fun with this drive. I haven't had a chance to play with it yet.

I agree with you about most industrial inverters not working that well in a car. I started off with a TECO drive which kinda worked, but the control was really wacky. That's how I got started on the DTC kick-- I had a plan to replace the control of the other drive, but then this ABB drive came along. The Aussies have had quite a bit of luck with industrial drives and such. My original inspiration was Tuarn Brown's Red Suzi.


----------



## gunnarhs (Apr 24, 2012)

subcooledheatpump said:


> I have an ACS 600 in my van, it has DTC.
> In the parameters list it allows selection of "Scalar" or "DTC" under "Motor Control Selection"
> Makes really funny sounds, and the switching frequency changes all the time. Sometimes it sounds like shifting gears with a regular ICE and a transmission


Ok do you set the motor-parameters by yourself or does the inverter "learn" the motor curve ? (as I was told the newer one does). 
(Probably I am mixing up some info in my head but I was quite sure that in the ABB I had temporarely I had to manually set parameters.)
And how is the drive-feeling, is it smooth?. 
What is your range in km/kWh and vehicle weight/average speed?



stickytechnology said:


> That pic does look sinusoidal-- what is the switching frequency?


On the IGBT's it is 20 kHz (constant), the (modulatet) sinus shown on the oscilloscope would variate from 10Hz to 100Hz for the applications we use.
Inverter has constant efficiency (european) of 98,5% measured by LTI-Energy.
(maximal efficiency over 99% according to US-rating).
Tests were done for variable speed, constant torque application (this exemplar of inverter was not built for traction application)



> I am still a bit skeptical that a filter will
> a) be smaller than the motor for reasonably efficient switching frequencies
> and


The bigger the motor, the smaller the filter in comparision, but yes, the filters take much place in a car. I would like to get rid of it though if possible...



> b) do anything for you performance wise. I understand the IEC has things to say about EMI, which this would help with, but I can't see how the motor would care.


You loose about 1% of efficiency of the Inverter actually but heating is less in motor and longer life I was told (less effects of corona when using higher voltages)



> If I was designing an AC drive from scratch, I'd put a DC-DC converter on the front instead


I assume you are talking about a boost-buck - converter(?)
It looks good in simulation and I would like to test it, the only car I know uses it is Toyota Prius for their hybrid drive. 
They use it mostly to step up low batery voltage but this should also stabilize the voltage which is good for control.



> Usually DTC does speed in an outer control loop, so it uses torque to control speed.


Yes and that is the problem I have with the FOC/DTC in standard inverters. 
If you look it vector-wise it does only adjust stator OR rotor flux (not both) which I would think is necessary if you have a limited power source (batteries in our case). In theory one would think that the stator flux vector would be adjusted according to available voltage and the rotor flux to maximal torque/speed requirements at the moment .
Meaning 
1) TorqueRequired ~ StatorFluxAvail X RotorFluxReuqired,
2) SpeedRequired ~ StatorFluxRequired X RotorFluxConstantIfpossible (else 1))

The FOC/DTC control in standard Inverters I have experienced is more like this (in this case of DC Bus 300V, Motor 220V AC)
(here I have the inverter speaking)

1) Give me some torque command
2) Ok voltage under 290 , f... off (shut down)
3) Ok enough voltage, f... I have do do some work now.. how about this...?
Too much ehh? You crashed..., Oh you have a bad looking leg, sorry, I thought you knew the 100% torque by zero rpm featus
4) Noticed you pressed a torque command during high speed ... You want to overtake at 60 km/h, are you crazy? no I now better, I think 70 km/h is enough.

this sounds like joke but unfortunately it is not in my case at least


----------



## subcooledheatpump (Mar 5, 2012)

For the ABB drives with DTC... you enter the motor nameplate ratings; 

Rated current, Voltage, speed and horsepower ( or kW)

Once you enter them the drive will run through a tuning program, it can either tune the motor running or stopped

You can then specify up to 300% of rated torque, provided the drive can output that much current and you have allowed the current limiter to reach that current as well. 

Same with speed, you can allow for an increase in speed as long as the drive can output a high enough frequency to make it happen. Mine only goes to 300 Hz. So for me that would be 6000 RPM at the motor, which is more than enough speed 

The torque is smooth except for if you are stopped and you jam the accelerator, then it can become unstable and cause vibrations. I am running open loop though.

The vehicle is very heavy, 2500+ kg and the battery is small, 10 kWhr so range isn't good. I have had it up to 88 km/h though. It could probably do something like 10, maybe 15 miles at 50 km/h on flat ground


----------



## stickytechnology (Sep 19, 2010)

gunnarhs said:


> 1) TorqueRequired ~ StatorFluxAvail X RotorFluxReuqired,
> 2) SpeedRequired ~ StatorFluxRequired X RotorFluxConstantIfpossible (else 1))


No! I'm not sure why this is such a popular misconception, but here goes...

The stator and rotor fluxes are identical in an ideal motor, whether dc or ac. They only differ by the leakage flux in any case, which is mostly due to the end turns. Think of the motor as a transformer- there is the same flux on the primary (stator) as the rotor (secondary). If there isn't, the motor/transformer is designed poorly. So, where does torque come from? It comes from current flowing in the magnetic field, the Lorentz force. Again, same in dc and ac. The only trick in an ac motor is to get the current 90degrees out of phase with the flux, which happens automatically in a series dc motor.


----------



## gunnarhs (Apr 24, 2012)

subcooledheatpump said:


> For the ABB drives with DTC... you enter the motor nameplate ratings;
> 
> Rated current, Voltage, speed and horsepower ( or kW)
> 
> ...


Ok thanks for the info.


----------



## gunnarhs (Apr 24, 2012)

stickytechnology said:


> No! I'm not sure why this is such a popular misconception, but here goes...
> 
> The stator and rotor fluxes are identical in an ideal motor, whether dc or ac. They only differ by the leakage flux in any case, which is mostly due to the end turns. Think of the motor as a transformer- there is the same flux on the primary (stator) as the rotor (secondary). If there isn't, the motor/transformer is designed poorly. So, where does torque come from? It comes from current flowing in the magnetic field, the Lorentz force. Again, same in dc and ac. The only trick in an ac motor is to get the current 90degrees out of phase with the flux, which happens automatically in a series dc motor.


Now I think we have to go through some basics. 
First lets categorize the DC you have different types, here are few classics
(not refering brushless DC at is an AC in structure and control)
In most DC motors, field winding and armature linkage are controlled by structure/brushes during rotation so they are more like synchron AC in terms of the Phase (do not need correction)

1) Series: Here you have the same current flowing through armature and field winding, so only in case of similar inductor (which is never in praxis for reason) you could have same flux in armature and field

2) Parallel: Here the field and armature winding are parallel and only in case of same resistance AND Inductor (which is never in praxis for reason) the flux would be the same in armature and field.

3) Compound: Mixture of 1) and 2) dependent on application (torque/speed requirement)

4) Sepex: The most interesting and only DC I would use to compare to the AC.
You can look at the Sepex as a practical model of stator/rotor flux - model of an AC and as you find in literature, this is often done.
So how does it behave:
It has usually a "small" field winding with "high" resistance/inductance and a bigger armature with low resistance/inductance. This windings are not electrically connected but located in the motor that they produce together the Torque ~ Field X Armature.
The field current limits the "base speed" (and is most influential for torque), the armature voltage decides the maximum speed. 
Together they produce the resulting electric torque as said before
This is used in the Peugeot 106 electric this way: (The field current goes from 10A to 1A, the Armature Voltage from 10 - > 120 V)
At the start of the vehicle field current is maximal and armature voltage minimal.
As the vehicle moves on field current is decreased and armature voltage increased. The torque is constant first, after base speed is reached, it drops lineary and during high speeds (saturation) torque drops faster.
The resulting curve is the same as in AC under constant voltage but variable speed condition (first constant torque, then constant power, then saturation).

The point is: You control two phases, the stator and rotor phases (flux). 
You only control the amplitude not the phase angle, this is in the structure.
This is the same as in synchronous AC-machines (except for minor corrections)
(specially simple in PMSM where the current - magnet side (rotor in most cases) is kept near zero as there are magnets present).

In the AC-induction, especially in the squirrel cage, there is a big difference in rotor and stator structure. 
As most literature describe the model as a trafo, this is in case of the squirrell cage a very narrow approximation and in terms of variable frequency very difficult to verify as rotor has no real "windings"
(works well only for a narrow region near base-speed). 
I dont know how many "Dr. Ing" (the Dr.rer nat.'s sem to understand the really nonlinear model better for some reason) I have stopped from "prototype testing" an inverter with an trafo for example but lets stop here.

In the simplest form of vector control you can skip controlling the phase angle but only control the amplitude of the flux vectors/current in rotor and stator as in the Sepex. 
Under constant low load you can play with adjusting this two components and you will see the same behaviour as in the Sepex, one component has more influence on speed, the other more on torque.

The only difference from the Sepex is the slip, but if load is constant you will adjust the torque determining component (rotor flux for AC-Induction) and speed determining (stator flux for AC-Induction) and hold slip constant. 
You also have the possibility in the AC-induction to play with the phase angle, but in most cases you want maximum perfomance with 90 angle.
Therefore angle correction is often ADDED to the basic amplitude control.
(normally you need to measure slip/speed to do that under VARIABLE load)

You could also do vica-verse both in Sepex and AC and control speed with the field determining flux and torque with the speed determining flux as BOTH influence torque and speed, you will soon realize this is not good to do in a car.

And now to our actual problem finding (or making) an good inverter for a car.
The problem finding a adequate control box for our french Sepex car was the same as finding a control for our Chinese induction motored car.
Standard industrial applications are mostly fixed on variable speed and variable torque applications so the only "mixed" mode application I have found is the original Peugeot Control box for the Sepex. 
The other I have had to do myself but I have not found the perfect solution yet. 
Only thing I know is that it will be a mixed mode application as pure speed- or pure torque - control do not give the optimal performance/efficiency and certainly not the best driving behaviour for an electric motor 
(for gasoline torque control is good enough but only with gearing)

The simplest form of a mixed mode control has already been done in this topic


----------



## stickytechnology (Sep 19, 2010)

gunnarhs said:


> Now I think we have to go through some basics.


It's nice to go over the basics from time to time, but it's not relevant to my point that in all iron core motors, regardless of type or operating condition, Stator flux = Rotor flux, neglecting flux leakage, which is kept to a minimum. You can convince yourself of this in a number of ways, but the easiest way to think about it is that the stator iron and the rotor iron are essentially one piece. Ideally, you can neglect the air gap. Then it's clear that an amp turn in the stator results in an identical flux in the magnetic circuit to an amp turn in the rotor. There is only one flux, because there is only one magnetic path. Torque is felt by conductors carrying current in that flux. That's why stator windings have to be varnished in place- there's a torque on them too! 

Later, when you add the air gap and other sources of flux leakage back in, they become sources of inefficiency and so on, but they don't change the fundamental way the motor works.

I just realized the exception to my blanket statement is switched reluctance motors. They don't have a constant magnetic path, and they produce torque by minimizing the stored energy in the magnetic field, which makes a really strange beast.


----------



## gunnarhs (Apr 24, 2012)

stickytechnology said:


> It's nice to go over the basics from time to time, but it's not relevant to my point that in all iron core motors, regardless of type or operating condition, Stator flux = Rotor flux, neglecting flux leakage, which is kept to a minimum.


I must assume you are still talking of induction motors as the DC-Motors in my previous example do not behave like that when normal structure is considered.
As I have pointed out the trafo model in the case for a squirrel cage induction motor only applies when you are operating with rated voltage/current near rated frequency, and you have a constant load/slip.
By lineary working from that optimal point using CONSTANT V/f control during variable speed the stator flux will be quite proportional to rotor flux.
(meaning adjusting the voltage proportionally to speed which you can only do with constant load for variable speed application.)

So you believe in the U/f control after all?
With slip control to help adjust the phase angle of course 
I love to hear that.



> You can convince yourself of this in a number of ways, but the easiest way to think about it is that the stator iron and the rotor iron are essentially one piece. Ideally, you can neglect the air gap. Then it's clear that an amp turn in the stator results in an identical flux in the magnetic circuit to an amp turn in the rotor.


In symmetric build trafo this is true but even there if you continiously variate the frequency then even that simple model becomes quite distorted.



> There is only one flux, because there is only one magnetic path. Torque is felt by conductors carrying current in that flux.


Assuming the ideal case that we had only one magnetic field going from stator to rotor, the flux which is defined as magnetic field flowing through a certain volume in a certain time (Volt seconds/m2) is obvously not the same, as rotor frequency and volume is not the same as the stators. But if slip, frequency and voltage is kept constant stator and rotor flux will be proportional as pointed out above.
The real case is that additional back-emf is induced and you have to consider that too. The more you change voltage, frequency and load and go away from the ideal state, the more the back-emf distorts the ideal model.



> Later, when you add the air gap and other sources of flux leakage back in, they become sources of inefficiency and so on, but they don't change the fundamental way the motor works.


Well this components are making me some pain for more powerful, higher speed motors at the moment... 



> I just realized the exception to my blanket statement is switched reluctance motors. They don't have a constant magnetic path, and they produce torque by minimizing the stored energy in the magnetic field, which makes a really strange beast.


Dont know them but they seem a hot topic now. 
What happened to the PMSM with up to 98% efficiency, soo easy to control an soooo powerful, are they "OUT" already?


----------



## stickytechnology (Sep 19, 2010)

gunnarhs said:


> Assuming the ideal case that we had only one magnetic field going from stator to rotor, the flux which is defined as magnetic field flowing through a certain volume in a certain time (Volt seconds/m2) is obvously not the same, as rotor frequency and volume is not the same as the stators. But if slip, frequency and voltage is kept constant stator and rotor flux will be proportional as pointed out above.


Of course I meant flux linkage (Vs) , not flux density (Vs/m^2), sorry. Flux linkage is a handy quantity because it is constant through the magnetic circuit.

Why should it be true for constant slip but not otherwise?

I'm not sure what model you are using in your calculations. I'm speaking of the dynamic T-model, which is on page 112 of the book I like, which is "Control of Induction Motors" by Trzynadlowski:

http://books.google.com/books?id=58...&q=dynamic t-model of induction motor&f=false

Apologies if this link doesn't work in other countries. The book is probably in the library of your local uni.

You can see what I'm talking about in figure 6.3. There's only one magnetizing inductance, Lm, and flux linkages in the rotor and stator only differ from each other by the leakage inductances, Lls and Llr. The equation for the torque is on the next page, (eq 6.17) only as a function of stator current and stator flux linkage, which is what DTC uses.

Most of the tuning a drive does is to determine the leakage inductance, which is only geometrical- it doesn't change much with temperature.


----------



## gunnarhs (Apr 24, 2012)

stickytechnology said:


> Of course I meant flux linkage (Vs) , not flux density (Vs/m^2), sorry. Flux linkage is a handy quantity because it is constant through the magnetic circuit.


Ok lets stick to that definition of flux linkage and flux density, in literature this is often confusing



> Why should it be true for constant slip but not otherwise?


In the cases of slip change additional back-emf is induced which has to be taken into account. You see for example totally different current in the motor during startup, very low frequencies and under partial load than under ideal condition. 



> I'm not sure what model you are using in your calculations. I'm speaking of the dynamic T-model, which is on page 112 of the book I like, which is "Control of Induction Motors" by Trzynadlowski:


This is basicly the same I use but I have the whole time frame from startup with the startup-condition. The "dynamic" T model above is an already steady state model. The reason I prefer mine is that some of applications I have to model are start-stop applications.
Additionally it had to be modified with motor inertia (rotor) and temperature changes stator side at least in my case.



> Apologies if this link doesn't work in other countries. The book is probably in the library of your local uni.


Some pages are missing, especially 120 which explains the interesting analogy to SepEx- Motor. I assume here though that the analogy is based on common industrial use, not the way the Peugeot 106 is using that.
But this is guessed, I miss the pages...
Will not go to university again though, not missing it since finishing my degree 15 years ago.



> equation for the torque is on the next page, (eq 6.17) only as a function of stator current and stator flux linkage, which is what DTC uses.


In 6.17 I see a (nonlinear) formula dependent on both stator and rotor current there (but seen from the stator frame): 
Torque = (2/3) *P*( RotorCurrent*StatorFluxLinkage - StatorCurrent*RotorFluxLinkage)

Note: Rotor current and rotor-flux-linkage components must be calculated from stator as they can not be measured.

The same as equation (6) in this paper http://ljs.academicdirect.org/A18/027_044.htm. 
Note though: 
"maintaining the constant amplitude of reference stator flux"
As I have not all pages of your book I assume the same there (?)
Yes found it on page 115,...

But I tried to read further and then I found a formula more adequate to your description
This leads us in chapter 7 to equation 7.2 which is quite similar to previous 6.17. and with "aligning the D-axis with another flux vector"
the rotor flux component becomes zero (?) and we get finally 7.4
Torque = (2/3) *K*( RotorCurrent*StatorFluxLinkage). (A)

I would think (A) is what you are aiming at, is simpler than 6.17

We are already in steady state, both paper agree on that (meaning load is constant, the voltage is also kept constant according to both).
The "dynamic" T - model is assuming stable frequency (not neccsesseraly constant but surely not on/off application)

So we can go to my referenced paper again and look at formula (8) which is looked at in the time frame
Steady state is reached at t >> 0, assuming slip is constant and what happens?
We get something like 
Torque = (2/3) *K1*(FluxLinkStator*FluxLinkStator).
With K1 = K*L(Rotor)/L(mutual) we see the analogy between (A) and (B)

( Simplyfying : L(mutual)*RotorCurrent) ~= FluxLinkStator, ignoring leakage and extra back-EMF)

So let me translate:
Keeping stator flux linkage vector constant = Bus voltage is constant
Providing voltage space vectors = adjusting voltage/frequency.
Aligning axis of rotor and stator frame = forcing constant slip.

I can say: 
The scalar addition of of the length of two base vectors gives me the resulting output 2 
or
1 + 1 = 2


----------



## stickytechnology (Sep 19, 2010)

gunnarhs said:


> In 6.17 I see a (nonlinear) formula dependent on both stator and rotor current there (but seen from the stator frame):
> Torque = (2/3) *P*( RotorCurrent*StatorFluxLinkage - StatorCurrent*RotorFluxLinkage)


No, 6.17 reads:

Torque = 2/3 P (y_component_of_stator_flux*x_component_of_stator_current -x_component_of_stator_flux*y_component_of_stator_current)


Where x and y are orthogonal stator coordinates (traditionally d and q for some reason)
In words, this says torque is proportional to the cross product of stator flux linkage and stator current. That's all, and that equation is the beginning of understanding DTC. Without seeing your model, I'm afraid we can't really have any more of a discussion, but I assure you this model works on transients as well as steady state. Remember, flux linkage is an integral over time, so it takes account of the history of the voltage applied to the device all the way back.


----------



## gunnarhs (Apr 24, 2012)

stickytechnology said:


> No, 6.17 reads:
> 
> Torque = 2/3 P (y_component_of_stator_flux*x_component_of_stator_current -x_component_of_stator_flux*y_component_of_stator_current)
> 
> Where x and y are orthogonal stator coordinates (traditionally d and q for some reason


The "x and y " (or d and q) are orthogonal (90 degree shift) as they represent stator and rotor component, induced by the stator voltages of course.
To start from beginning you have 3 phases 120 degree shifted (a,b,c)
When transferring them to stator frame for example, you have two sinussodial currents, one in the stator and one (induced) in the rotor which are shifted by 90 degrees, same as trafo model 
(often referred as alpha, beta if transformation is timevariant see Clarke transformation)

The original stator current vector, which is not aligned to rotor frame in beginning, can be split up as two vectors Ids and Idq and the same you can do with the stator flux linkage vector (Qds and Qdq). 
The ds part is aligned to the stator, the dq to the rotor (rotor inducing current part)
The Torque is made from T ~ Idq * Qds - Ids *Qdq in case of orthogonality



> In words, this says torque is proportional to the cross product of stator flux linkage and stator current. That's all, and that equation is the beginning of understanding DTC.


Only of the stator flux linkage (d) X rotor current(q) part 
minus back EMF ( rotor flux linkage (q) X stator current(d) ).



> Without seeing your model, I'm afraid we can't really have any more of a discussion, but I assure you this model works on transients as well as steady state. Remember, flux linkage is an integral over time, so it takes account of the history of the voltage applied to the device all the way back.


Start reading the link I provided...
It is about a way to use slip to correct basic DTC by the way 
You have to admit it is easier to read and understand than your book (except few typos like disadvantage instead of advantage) 
Book is though good by the way, I went through it until late tonight, found a point regarding varying the stator-voltage-flux, which is seldom mentioned in literature.
The model I use is based on the same equations (1)-(8) 
(same as the T-model , dont take me wrong it is a good and valid model for steady state calculation, needs only a "small" adaption to real world)
Then read further to (10) and (11)
It shows the Torque variant to time, notice the slope (1-exp (-t/o)).
When applying it on startup-condition (t=0) it shows a sinus-torque starting from zero ! (at rotor zero rpm), then getting stabilized (in my model at about 10 Hz, in the paper earlier).
The diagrams beneath show the stabilized (!) d-q components ( really alpha, beta in sense of clarke transformation as they are timevariant)

Applying the steady state T-Model only, it gives me the same torque at zero rpm
as at 1000 rpm for my motor parameters(constant torque region).

This is not what happens in practice, as at beginning there is not current in the rotor, Torque is zero at first moments.
Stabiliation is achived when rotor achieves some speed , in my case to minimize the starting current I have starting frequency higher than is done in other papers I have read. 
The only difference I am making yet to the equations is adding motor inertia to load inertia and ugrading the formulas (the L and R) when heat turns up (I start with "cold" values) .
I correct the model for low rpm and very high rpm by using voltage/frequency control instead of the vector-model during startup and saturation (field weakening). 
What happens is that I get smoother starting-torque/current in low rpm and during high rpm I have better control of the field weakening. I am questioning this latter approach though, but I have not found a better solution yet, I am looking for a better controlled way to do the field weakening like we do for the Sepex-Motor.

I am digging out my Matlab - Models by the way now (12 years old some of them) but I do not want to spoil this thread which is about the practical implementation 
(already posted som heavy code)


----------



## PStechPaul (May 1, 2012)

gunnarhs said:


> [snip]
> Applying the steady state T-Model only, it gives me the same torque at zero rpm
> as at 1000 rpm for my motor parameters(constant torque region).
> 
> ...


There must be some torque upon first application of voltage to the motor, except for the negligible amount of time to achieve magnetization. Obviously, there is "locked rotor torque" when the motor first starts, and this torque will continue even with no relative motion between rotor and stator. However, the pull-out torque, at the point of maximum slip for a given RPM, may be higher than locked rotor torque. But I think that may apply only to motors running with fixed frequency and full voltage. The locked rotor torque should depend mostly on the relative surface speeds of the stator and rotor, and the current in the stator. However, since the inductance of the motor is not constant over all frequencies, there may be some variation over the full operating range.


----------



## gunnarhs (Apr 24, 2012)

PStechPaul said:


> There must be some torque upon first application of voltage to the motor, except for the negligible amount of time to achieve magnetization. Obviously, there is "locked rotor torque" when the motor first starts, and this torque will continue even with no relative motion between rotor and stator. However, the pull-out torque, at the point of maximum slip for a given RPM, may be higher than locked rotor torque. But I think that may apply only to motors running with fixed frequency and full voltage. The locked rotor torque should depend mostly on the relative surface speeds of the stator and rotor, and the current in the stator. However, since the inductance of the motor is not constant over all frequencies, there may be some variation over the full operating range.


Yes, of course, the Torque following the first "neglible zero-torque moment" is high and can be much higher than the torque after stabilisation. This can result an heavy accelelaration on the load at the first moments. 
It depends on the applied frequency. the trick is to find the optimal "starting" frequency for the load.


----------



## stickytechnology (Sep 19, 2010)

gunnarhs said:


> The "x and y " (or d and q) are orthogonal (90 degree shift) as they represent stator and rotor component, induced by the stator voltages of course.
> To start from beginning you have 3 phases 120 degree shifted (a,b,c)
> When transferring them to stator frame for example, you have two sinussodial currents, one in the stator and one (induced) in the rotor which are shifted by 90 degrees, same as trafo model
> (often referred as alpha, beta if transformation is timevariant see Clarke transformation)


No again. This book at least uses d and q for the orthogonal stator coordinates (as opposed to a b c for the 3-phase coordinates) It uses D and Q for the rotating frame. So, in the equation I mentioned, lambda_ds is the flux linkage of the stator in the d direction, for instance, and lambda_qs would be the stator flux linkage component in the q direction.


----------



## stickytechnology (Sep 19, 2010)

gunnarhs said:


> Only of the stator flux linkage (d) X rotor current(q) part
> minus back EMF ( rotor flux linkage (q) X stator current(d) ).


I was wondering what it was you keep referring to as back EMF. That minus sign is just another way of writing a cross product. You take one component of the first vector times the opposite component of the second vector and multiply them, and then you subtract the product of the other two components:

*current_s* X *flux_s* = current_qs * flux_ds - current_ds * flux_qs

Back EMF in AC induction motors isn't really a thing. If you remove the power and measure the voltage on the leads, the voltage will decay exponentially to nothing within a short time (well, almost nothing- there will be a little residual magnetism in the rotor)


----------



## jhuebner (Apr 30, 2010)

Sorry for "stealing" the thread, I was offline for the last 2 weeks and want to follow up on an older post.


Siwastaja said:


> - Trying to control torque by controlling slip instead of voltage ("slip control" - do not touch the slip - not the most descriptive name out there)
> - Using relative slip (%, multiplication) instead of absolute (Hz, addition) (and slips are often given as %; again confusing!)
> - Setting wrong slip
> - Failing to get correct RPM readings from encoder (for example, at low RPM)
> - Lack of any voltage boost (constant addition to the voltage command)


Very precise 
Those are things that I did and still am doing wrong.
- Currently the pedal sets both slip AND voltage bearing in mind some simplified efficiency formular: 1-s. The car also drives with that setup and also this logic replaces your "slip boost" block. Once the motor exceeds around 5Hz it is completely smooth, below that I'm still having problems.

How do you get rpm from the encoder?

I'm currently eliminated the idea of rpm and introduced angle. Whenever I see a pulse from the encoder I know that the shaft has rotated 6° (I have 60 pulses per rev). Between the pulses I interpolate by using the time between the last two pulses and the time elapsed since the last pulse (using the timer hardware, might be more simple than it sounds)

So the 3-phase PWM interrupt gets the angle, adds a slip angle, looks up the sine wave at that angle, scales it and outputs it.

Following up on my FOC attemps: the FOC code never ran the motor for real (I hope I mentioned that before) and I preferred to stick with my working slip control.

Maybe I should add that I did a 15km test drive (no video unfortunately). Top speed 120 km/h, hilly terrain and at the end 30°C heat sink and 70°C stator temp. I used 3rd gear all the time, a [email protected] Motor and 500V bus voltage.


----------



## stickytechnology (Sep 19, 2010)

jhuebner said:


> Sorry for "stealing" the thread, I was offline for the last 2 weeks and want to follow up on an older post.


No worries, we got pretty far into the bushes while you were gone 

I think it's pretty cool what you guys are doing. This method of scalar slip torque control isn't in my book at all. It might be worth writing it up. The novelty appears to be in the fact that you can control torque with no current measurement


----------



## jhuebner (Apr 30, 2010)

stickytechnology said:


> No worries, we got pretty far into the bushes while you were gone
> 
> I think it's pretty cool what you guys are doing. This method of scalar slip torque control isn't in my book at all. It might be worth writing it up. The novelty appears to be in the fact that you can control torque with no current measurement


Another variant of "sensorless"  I still use current sensors for current limiting when things go wrong. But even that could be simplified.
The control might not simplify the hardware by a great deal, but certainly the software. All parameters are somewhat "real world". All the code works with 1st order real world values. Siwastaja did a good job stressing the simplicity and things you can forget about 

I would really like to know how much better the more advanced methods perform in terms of efficiency. Should it turn up to be 1.55% or something I will label them as "enterprisy" and forget them


----------



## gunnarhs (Apr 24, 2012)

stickytechnology said:


> No again. This book at least uses d and q for the orthogonal stator coordinates (as opposed to a b c for the 3-phase coordinates) It uses D and Q for the rotating frame. So, in the equation I mentioned, lambda_ds is the flux linkage of the stator in the d direction, for instance, and lambda_qs would be the stator flux linkage component in the q direction.


You still have to explain what is the d and what is the q-direction then...(?). And why are they (usually) orthogonal ?
My "suggestion": It has to do with the stator / rotor alignment...



stickytechnology said:


> I was wondering what it was you keep referring to as back EMF. That minus sign is just another way of writing a cross product. You take one component of the first vector times the opposite component of the second vector and multiply them, and then you subtract the product of the other two components:
> *current_s* X *flux_s* = current_qs * flux_ds - current_ds * flux_qs


Yes of course, you can look at it that way too. 
But in interest of this thread and forum I will try to explain the physics and skip the math as much as possible.
Meaning one part of the equation is the "motor" part, the other the Back-EMF ("generator part").




> Back EMF in AC induction motors isn't really a thing. If you remove the power and measure the voltage on the leads, the voltage will decay exponentially to nothing within a short time (well, almost nothing- there will be a little residual magnetism in the rotor)


Well this depends on the load situation. Under "full load" you have little Back-EMF, under low load / high speed Back-EMF increases. The less Back-EMF, the higher the Power - Factor, which is quite important.
In a situation when load speed is more than supplied frequency, meaning motor is acting as generator, BACK-EMF is dominant (called regen also)

But as previously explained by me in the thread under full constant load and ideal slip (and preferably stable frequency) you can skip the Back-EMF component.
Then you have your ideal simple torque-control. 

I encourage you to play with this factors
But if you do not want to get injured, do it outside the car.
(with a standard inverter at least  )


----------



## jhuebner (Apr 30, 2010)

Siwastaja said:


> - Trying to control torque by controlling slip instead of voltage ("slip control" - do not touch the slip - not the most descriptive name out there)
> - Using relative slip (%, multiplication) instead of absolute (Hz, addition) (and slips are often given as %; again confusing!)
> - Setting wrong slip
> - Failing to get correct RPM readings from encoder (for example, at low RPM)
> - Lack of any voltage boost (constant addition to the voltage command)


Thanks again for this list! I did another test drive yesterday and the car now drives smoothly all the way down to 0 rpm!
- Two parameters: slipmin, slipmax and the pedal controls also the slip
- So I do touch the slip, but am thinking I should maybe go your "boost" route
- am using absolute slip
- Worked a lot on the encoder reading, now it works down to 0.25Hz/15rpm (this was the largest problem)
- There is voltage boost

Regen is able to stop the car, though rather aggressively when it comes close to a full stop. Maybe add a curve for that as well?

Here is a video: http://youtu.be/70uQymh2TGQ


----------



## jddcircuit (Mar 18, 2010)

jhuebner said:


> Thanks again for this list! I did another test drive yesterday and the car now drives smoothly all the way down to 0 rpm!
> - Two parameters: slipmin, slipmax and the pedal controls also the slip
> - So I do touch the slip, but am thinking I should maybe go your "boost" route
> - am using absolute slip
> ...



Thanks for sharing the video. I find the homebrew conversions very inspiring. I am also attempting my own motor control and individual cell monitoring designs. It has been a learning experience to say the least. I hope to be on the road by the end of the year. I can't imagine how it will feel to get to that point.

Regards
Jeff


----------



## Siwastaja (Aug 1, 2012)

Very nice to see and I'm glad to be of help.

Your driving looks as smooth as our does and you have a bit more top speed in uphills. Plus, you seem to have your motor mounted which helps .


----------



## PStechPaul (May 1, 2012)

The video shows it to be running very nicely. This was all in third gear? It would be helpful to have captions or voice narration to indicate when you are starting, accelerating, and braking, and some instrument readings showing current and regeneration. Will the motor hold the vehicle when stopped on a hill? That may be a good point to determine the basic losses incurred in your system.


----------



## jhuebner (Apr 30, 2010)

jddcircuit said:


> Thanks for sharing the video. I find the homebrew conversions very inspiring. I am also attempting my own motor control and individual cell monitoring designs. It has been a learning experience to say the least. I hope to be on the road by the end of the year. I can't imagine how it will feel to get to that point.


It is rather awesome  The first test drive with everything working was something special 5 years after doing this:











Siwastaja said:


> Very nice to see and I'm glad to be of help.
> 
> Your driving looks as smooth as our does and you have a bit more top speed in uphills. Plus, you seem to have your motor mounted which helps .


I wonder what became of the 18.5kW on the nameplate  Feels like a bit more than that.



PStechPaul said:


> The video shows it to be running very nicely. This was all in third gear?


Yes, 3rd gear all the time.



PStechPaul said:


> It would be helpful to have captions or voice narration to indicate when you are starting, accelerating, and braking, and some instrument readings showing current and regeneration.


True. Currently I'm short of data. I'll write a small php script similar to the BMS one that polls data from the inverter and plots it. Maybe I can edit that in.


PStechPaul said:


> Will the motor hold the vehicle when stopped on a hill? That may be a good point to determine the basic losses incurred in your system.


No, the current flow stops below 0.5Hz because I don't want to waste energy during stand still. But thats a parameter of course that I can reduce to 0Hz. But what will the reading show? DC resistance?


----------



## gunnarhs (Apr 24, 2012)

jhuebner said:


> Regen is able to stop the car, though rather aggressively when it comes close to a full stop. Maybe add a curve for that as well?
> 
> Here is a video: http://youtu.be/70uQymh2TGQ


Looks good! From what I see in the Video I would decrease the frequency more slowly when releasing the pedal but of course it depends on you how you like the regen. You must be careful though when the normal brakes are pressed , provided frequency should follow the load in every case.
So you have to adjust the regen-braking to the normal braking.

Remember when pressing brakes foot goes off the gas-pedal, this makes the car brake because of regen and you must be sure that pressing the normal brakes for final stop, which slows the load, will not accelerate the car again, if inverter is still supplying some voltage/frequency higher than the load (I have had problems when using standard inverter with FOC).

The advance test would be pressing the normal brakes,pressing the pedal, ,releasing the pedal, pressing the brakes and so on ( in different order).
Start doing it on even ground, then driving uphill and downhill also
Be careful when doing that especially as it seems you do not have a clutch.


----------



## gunnarhs (Apr 24, 2012)

jhuebner said:


> No, the current flow stops below 0.5Hz because I don't want to waste energy during stand still. But thats a parameter of course that I can reduce to 0Hz. But what will the reading show? DC resistance?


Keep it that way and even increase it to a few Hz for better efficiency.
Otherwise a huge current will be drawn for nothing.

The best way to measure the total efficiency is the range of the vehicle compared to battery-pack of course
If you have more than 5 km/kWh for a 1000 kg vehicle you are quite good.

The other thing to measure heat from your drive (inverter/Motor) as far as you can.

There is no point in measuring efficiency in a no drive condition as you point out


----------



## gunnarhs (Apr 24, 2012)

Siwastaja said:


> Plus, you seem to have your motor mounted which helps .


I appreciate your dedication for the EV-community but please do not kill yourself we might need you longer...


----------



## jhuebner (Apr 30, 2010)

gunnarhs said:


> Looks good! From what I see in the Video I would decrease the frequency more slowly when releasing the pedal but of course it depends on you how you like the regen. You must be careful though when the normal brakes are pressed , provided frequency should follow the load in every case.
> So you have to adjust the regen-braking to the normal braking.
> 
> Remember when pressing brakes foot goes off the gas-pedal, this makes the car brake because of regen and you must be sure that pressing the normal brakes for final stop, which slows the load, will not accelerate the car again, if inverter is still supplying some voltage/frequency higher than the load (I have had problems when using standard inverter with FOC).
> ...


The response to the vehicle slowing down is really quick as there is hardly any delay between measuring the actual speed and commanding the new electrical frequency.
I have an intermediate value called "potnom" that runs from -X% to 100%. When the break pedal is pressed potnom is set to -Y%. X,Y are user parameters. This also means that while throttle and brake pedal are pressed simultaneously, the regen will stay on. But as you say - subject to test.



gunnarhs said:


> Keep it that way and even increase it to a few Hz for better efficiency.
> Otherwise a huge current will be drawn for nothing.
> 
> The best way to measure the total efficiency is the range of the vehicle compared to battery-pack of course
> ...


The test run on the video (and back) caused an inverter heat sink temperature of 40°C and a motor temperature of 60°C at 30°C ambient temperature.
Can't wait to do some actual efficiency runs but that have to wait until BMS and charger a built in.



gunnarhs said:


> I appreciate your dedication for the EV-community but please do not kill yourself we might need you longer...


Agreed 
As a side note: lightly touching 500Vdc didn't kill me either


----------



## PStechPaul (May 1, 2012)

You can probably add a time delay function for deceleration (as is available on some standard VFDs). Then adjust that time delay according to brake pedal pressure. There is also a ramp-up time delay, which might be adjusted according to accelerator position. It is probably good to have several weighted parameters based on throttle position. Maybe a PID algorithm. I think the dominant parameter should be speed, which would be like a cruise control based on where the pedal is, and have torque adjusted by the difference between pedal position speed and actual motor speed. Maybe have a switch to sense full throttle and go into a maximum performance mode which could include road speed vs wheel speed to maintain traction at its maximum before spinning the tires.


----------



## gunnarhs (Apr 24, 2012)

jhuebner said:


> The response to the vehicle slowing down is really quick as there is hardly any delay between measuring the actual speed and commanding the new electrical frequency.
> I have an intermediate value called "potnom" that runs from -X% to 100%. When the break pedal is pressed potnom is set to -Y%. X,Y are user parameters. This also means that while throttle and brake pedal are pressed simultaneously, the regen will stay on. But as you say - subject to test.


Ok, you seem to have worked it out. 
I use different time ramps for acceleration and regen, your solution might be better... 



jhuebner said:


> The test run on the video (and back) caused an inverter heat sink temperature of 40°C and a motor temperature of 60°C at 30°C ambient temperature.


Ok this gives me an indication that your efficiency is quite good assuming only aircooling. Do you have values for lower ambient temperature in the region of 15 C?



jhuebner said:


> Agreed
> As a side note: lightly touching 500Vdc didn't kill me either


Ha,ha this was intended for Siwastaja, according the comment about a not mounted motor (his?) , but yes 500 VDC are dangerous too.
I have touched 300V myself but fortunately with gloves...
The multimeter was smoked though, I forgot turning the voltage off when measuring a low internal resistance in the 300V path...


----------



## jhuebner (Apr 30, 2010)

gunnarhs said:


> Ok, you seem to have worked it out.
> I use different time ramps for acceleration and regen, your solution might be better...


Will see, will see... I wonder what happens when jumping from -30% to 100% throttle. I might need a ramp or filter in between. I'm not too fond of time ramps though.



gunnarhs said:


> Ok this gives me an indication that your efficiency is quite good assuming only aircooling. Do you have values for lower ambient temperature in the region of 15 C?


 Not yet.




gunnarhs said:


> Ha,ha this was intended for Siwastaja, according the comment about a not mounted motor (his?) , but yes 500 VDC are dangerous too.
> I have touched 300V myself but fortunately with gloves...
> The multimeter was smoked though, I forgot turning the voltage off when measuring a low internal resistance in the 300V path...


I know and thats what I agreed to 
In my former company (that made inverters) there were really strict security regulations. Like if you touched 60V+ you have to go the hospital for a day for observation. Sometimes the health and safety crew went through the plant to check.
I REALLY enjoy imagining their reaction when they saw me tightening the terminal screws with a bare metal wrench  Or Siwastaja driving with a loose motor


----------



## jhuebner (Apr 30, 2010)

PStechPaul said:


> You can probably add a time delay function for deceleration (as is available on some standard VFDs). Then adjust that time delay according to brake pedal pressure. There is also a ramp-up time delay, which might be adjusted according to accelerator position. It is probably good to have several weighted parameters based on throttle position. Maybe a PID algorithm. I think the dominant parameter should be speed, which would be like a cruise control based on where the pedal is, and have torque adjusted by the difference between pedal position speed and actual motor speed. Maybe have a switch to sense full throttle and go into a maximum performance mode which could include road speed vs wheel speed to maintain traction at its maximum before spinning the tires.


Paul, your making it complicated  But I have actually thought about putting some sort of full throttle boost at 90% throttle position or so. E.g. 1 Hz slip frequency from 1% to 90% and 3 Hz from 91% to 100%.


----------



## Siwastaja (Aug 1, 2012)

Guys, you are making it difficult again.

Releasing the gas pedal will command in a negative torque, and if your algorithm works at all, this will mean deceleration, not acceleration, so it won't work against the mechanical brakes. No need for separate kludges. If your control gives positive torque even when negative is instructed, fix the control first, don't fiddle with the input command which is just right. Our super simple algorithm works, so it's not that hard.

Of course we have a minimum frequency implemented, I think it was 2 or 1 Hz. Below that, it would take a higher-resolution encoder (we have 8 per rev) to respond quickly enough, and there would be very little velocity left to regen. So the car practically stops with regen, without any ill effects. Of course this could be expanded to 0 Hz which could work as a DC brake, but why bother? Mechanical brakes are there to keep the car standstill at 100% efficiency.

I see that jhuebner has a pretty high-resolution encoder which really helps. I can see a small effect of low encoder resolution in extreme cases, but otherwise 8 per rev is working fine. What I mean that when I use very "sporty" gas pedel parameters, hitting it to the floor will cause the first half a second of acceleration to be slower than it could be, with clearly reduced slip, because the frequency command cannot be updated as quickly as it should. I'd bet just doubling the encoder resolution would satisfy most if not all needs. We are going with 8, it's good enough. Maybe future builds will have more. (8 was easy because we made the motor axle coupler from the old clutch disk by using 8 bolts to connect; these bolts are easily picked up by an inductive transducer.)


----------



## gunnarhs (Apr 24, 2012)

Siwastaja said:


> Guys, you are making it difficult again.
> Releasing the gas pedal will command in a negative torque, and if your algorithm works at all, this will mean deceleration, not acceleration, so it won't work against the mechanical brakes. No need for separate kludges.


Ehhh we Paul were just replying to jhuebner post as he had a bit worry that his regen deceleration was maybe to hard.
In our case one idea was using a ramp which has been fine for me but I think jhuebner was not so fond of that idea. 
This is a very simple feature nothing complicated, only problem it has to be adjusted to the mechanical brakes. 
There was no doubt on the decelaration itself.


----------



## jhuebner (Apr 30, 2010)

Siwastaja said:


> Of course we have a minimum frequency implemented, I think it was 2 or 1 Hz. Below that, it would take a higher-resolution encoder (we have 8 per rev) to respond quickly enough, and there would be very little velocity left to regen. So the car practically stops with regen, without any ill effects. Of course this could be expanded to 0 Hz which could work as a DC brake, but why bother? Mechanical brakes are there to keep the car standstill at 100% efficiency.


Actually I'd reduce the resolution next time. Its 60 now, I'd go down to 30.

I think you mentioned that "your" regen stops the car rather vigorously. Have you fixed that? How?
I can feel how regen comes in rather strong below 10Hz or so. Then the commanded frequency is 8Hz which is a relative slip of -20%. Gets worse the lower the speed.


----------



## Siwastaja (Aug 1, 2012)

jhuebner said:


> I think you mentioned that "your" regen stops the car rather vigorously.


Well it is _capable_ of doing that. The algorithm works just fine; I just limit the regen torque command to whatever value I find comfortable to get less vigorous action.

In fact I limit it to about 10-15% of the acceleration torque limit. IIRC, the range being from -255 to 255 (arbitrary units), I scale to -30 to +255. I also map the throttle position to torque command so that the regen side is half the steepness. Something like this:












> Then the commanded frequency is 8Hz which is a relative slip of -20%.


This is as it should be, the slip is always absolute. It is only specified as a relative number when driven from a fixed frequency, because then it allows comparing motors. If you use some kind of a voltage boost, that could be the culprit. We use constant addition as a voltage boost.


----------



## jhuebner (Apr 30, 2010)

gunnarhs said:


> The advance test would be pressing the normal brakes,pressing the pedal, ,releasing the pedal, pressing the brakes and so on ( in different order).
> Start doing it on even ground, then driving uphill and downhill also
> Be careful when doing that especially as it seems you do not have a clutch.


I tested yesterday: press the brake pedal then press the accelerator all the way down.
Result: the car does not move, no motor current
Then release the brake pedal
Result: the car takes off quickly

So now I have launch control


----------



## jhuebner (Apr 30, 2010)

Siwastaja said:


> This is as it should be, the slip is always absolute. It is only specified as a relative number when driven from a fixed frequency, because then it allows comparing motors. If you use some kind of a voltage boost, that could be the culprit. We use constant addition as a voltage boost.


Ok, but the formular for slip is s=1-p*n/n1 where p is pole pairs, n is rotor speed, n1 is field speed. So thats relative. Practically, the relativ slip control gives too little torque at the low end.

How exactly does your voltage mapping work?

I use the traditional F/U scaled with the throttle input. So at standstill (well a bit above that actually) the voltage is boost*throttle.

The formular in general is (boost+slope*frq)*throttle/100. throttle is in [0..100], boost in [0..37813], currently set to 2000.
If that exceeds the maximum amplitude it is set to the maximum amplitude (37813). Thats where the so called "field weakening" starts.


----------



## gunnarhs (Apr 24, 2012)

jhuebner said:


> I tested yesterday: press the brake pedal then press the accelerator all the way down.
> Result: the car does not move, no motor current
> Then release the brake pedal
> Result: the car takes off quickly
> ...


Ok.....



jhuebner said:


> Ok, but the formular for slip is s=1-p*n/n1 where p is pole pairs, n is rotor speed, n1 is field speed. So thats relative. Practically, the relativ slip control gives too little torque at the low end.
> 
> How exactly does your voltage mapping work?
> 
> ...


Ok, this is very similar to the way we used to do it with gearbox.
(Now we are using ATM so it is a bit different).

The difference is in few details:
1) We start motor at about 10 Hz (or more in case of ATM), during engaging clutch /ATM the frequency is near to 20 Hz (1000 RPM)
2) Our "slope" (more ramp) is different during acceleration than decceleration (usually slope acceleration > slope decceleration) but the speed of the load determines that as long as load is engaged.
3) When setting the voltage it calculates the "optimal" Voltage/frequency , both from the pedal input ("Absolute Torque command") and from the current calculation (field control currents) which gives us a relative torque command based on load/speed situation.
That is the point where we are moving now to SVPWM based on the FOC-model. 
(at the moment we are using known motor -parameter-lines to find the optimal power point).

The reason for point 3 is:
1. Security, avoid high motor currents and wrong torque/speed for gearbox/ATM.
2. Better use of DC-BUS-Voltage and better efficiency
3. Mixed mode driving (Torque/Speed) as it suits (ECO/Sport).


----------



## PStechPaul (May 1, 2012)

I don't know where you got the slip formula, but it doesn't seem right:



> s=1-p*n/n1 where p is pole pairs, n is rotor speed, n1 is field speed


For one thing, it is 1 for any number of pole pairs at locked rotor (n=0), and it is an undefined singularity if field speed is zero. Slip is usually defined as a percentage of synchronous speed (or RPM). So a 2 pole 60 Hz motor has a synchronous speed of 3600 RPM and may have a rated speed of 3450 RPM, so the slip is 150 RPM, which is 4.2%. For a constant torque, this speed differential must be maintained at lower RPM, because the optimum induction takes place at a certain relative speed of the rotating field and the rotor surface. And it should seem obvious that under locked rotor conditions you will need a drive frequency corresponding to the rated slip, or 0.042*60 = 2.5 Hz. For maximum torque, which is typically 2.5 times rated torque, the frequency would be increased to 6.2 Hz.


----------



## gunnarhs (Apr 24, 2012)

PStechPaul said:


> I don't know where you got the slip formula, but it doesn't seem right:


From the usual definition you have a point...
Here we are talking about the difference between frequency provided by the the inverter versus the frequency of the load. I was under the impression that this was also called slip, so in my case I would set the formula:
FrequencyInverter = Frequency of Field in the stator (in above discussion 8 Hz)
frequencyLoad = Rotor frequency (in above discussion 10 Hz)
s = slip
s = (frequencyInverter -frequencyLoad) / frequencyInverter 
which in my case would give s = (8-10)/8 = -0,25 = 25% negative .

But I think for the basic concept this does not matter as long as long as is it is consistent through the calculation.
(In the field oriented control you can also be in stator or rotor frame as long you get the calculations right)


----------



## jhuebner (Apr 30, 2010)

PStechPaul said:


> I don't know where you got the slip formula, but it doesn't seem right:
> 
> 
> 
> For one thing, it is 1 for any number of pole pairs at locked rotor (n=0), and it is an undefined singularity if field speed is zero. Slip is usually defined as a percentage of synchronous speed (or RPM). So a 2 pole 60 Hz motor has a synchronous speed of 3600 RPM and may have a rated speed of 3450 RPM, so the slip is 150 RPM, which is 4.2%. For a constant torque, this speed differential must be maintained at lower RPM, because the optimum induction takes place at a certain relative speed of the rotating field and the rotor surface. And it should seem obvious that under locked rotor conditions you will need a drive frequency corresponding to the rated slip, or 0.042*60 = 2.5 Hz. For maximum torque, which is typically 2.5 times rated torque, the frequency would be increased to 6.2 Hz.


For your example p=1, n1=60, n=57.5. In the formular: s=1-1*57.5/60=0.042=4.2%
Same for a 4-pole motor
p=2, n1=60, n=1725rpm=28.75 1/s=28.75 Hz
s = 1-2*28.75/60=4.2%
The formular is from a text book. But now I understand that the difference in speed creates the torque. Well actually thats why our algorithm works well


----------



## Siwastaja (Aug 1, 2012)

jhuebner said:


> The formular is from a text book. But now I understand that the difference in speed creates the torque. Well actually thats why our algorithm works well


No, difference in speed is what allows the stator field to "transfer" to the rotor and create the rotor current. Together, these produce torque.

Voltage (or more precisely, how much you differ from linear V/f) controls the stator field, and the difference in speed controls what part of it will be transferred to the rotor. So, keeping slip constant, you control both stator and rotor current by controlling voltage.

Keeping slip constant keeps the rotor and stator fields at the same ratio automatically, just like in a DC series motor.

"Slip control" known in literature is indeed usually this "constant slip" control.

Then you control both stator and rotor currents by controlling voltage.

The problem in this control is the temperature instability which FOC and DTC address.

If you also control slip, you are also controlling the ratio of stator and rotor currents. Do you have a reason for this? We increase slip only if the voltage is already maxed out, but this probably decreases the efficiency a bit. Also having slip too low decreases efficiency and especially power factor. You don't want to drive your motor on low slip, it works nicely but wastes power. We tried it and both inverter and motor got much warmer. Instead, turn down the voltage when little torque is needed. Keep the slip.

Disclaimer: the terms may not be exact, but the idea should be correct.


----------



## jhuebner (Apr 30, 2010)

Siwastaja said:


> The problem in this control is the temperature instability which FOC and DTC address.


So to every rotor temperature there is one slip which is optimal? Is it worthwhile using the stator temperature, estimate the rotor temperature from it and adjust the slip?



Siwastaja said:


> If you also control slip, you are also controlling the ratio of stator and rotor currents. Do you have a reason for this? We increase slip only if the voltage is already maxed out, but this probably decreases the efficiency a bit. Also having slip too low decreases efficiency and especially power factor. You don't want to drive your motor on low slip, it works nicely but wastes power. We tried it and both inverter and motor got much warmer. Instead, turn down the voltage when little torque is needed. Keep the slip.


Allright, so drive with slip X as long as voltage isn't maxed out and linearly increase slip to have some extra torque if the voltage is maxed out? X can be derived from the nameplate values.
The reason why I let the throttle control the slip AND the voltage is to go beyond the motors rated torque if the driver requests it.


----------



## Siwastaja (Aug 1, 2012)

jhuebner said:


> So to every rotor temperature there is one slip which is optimal?


Yes, exactly, because the rotor temperature affects the rotor resistance, which affects the time constant and optimum slip. Higher resistance means higher slip.



> Is it worthwhile using the stator temperature, estimate the rotor temperature from it and adjust the slip?


Of course it's better than nothing, but it's difficult to estimate exactly. FOC and DTC do not need the temperature estimation because they estimate the rotor current directly (by measuring the stator current and applying some fancy maths).



> Allright, so drive with slip X as long as voltage isn't maxed out and linearly increase slip to have some extra torque if the voltage is maxed out? X can be derived from the nameplate values.


Yes, this is *exactly* what we do.



> The reason why I let the throttle control the slip AND the voltage is to go beyond the motors rated torque if the driver requests it.


Well the increased voltage does just that. It makes the motor take up more current, and this extra current divides evenly between stator and rotor because the slip is still optimal. (Simplified explanation.)

You indeed can also force the motor to take up more current by increasing the slip, which we do when we do not have more voltage at our disposal anymore. Well we also "overdrive" a bit, clipping the sine. These kludges may be removed once we have our 333 volt pack in use. Now we are going with 96V.


----------



## jhuebner (Apr 30, 2010)

Siwastaja said:


> You indeed can also force the motor to take up more current by increasing the slip, which we do when we do not have more voltage at our disposal anymore. Well we also "overdrive" a bit, clipping the sine. These kludges may be removed once we have our 333 volt pack in use. Now we are going with 96V.


So I have a question. In the datasheet of my motor it states: 
*[email protected] rpm* and *120Hz *field speed and *360V *stator voltage. Thats *0.7Hz* slip. The rated torque is about *50Nm*. To achieve the same torque at half the speed that would be *180V *and *60Hz*.
Now, they also specify a peak torque of *200Nm*. How do I get to that? By applying *4*[email protected]* or by setting the slip to *4*0.7Hz*? Or a bit of both?


----------



## gunnarhs (Apr 24, 2012)

I agree with you in all previous points but I want to add to this


> The problem in this control is the temperature instability which FOC and DTC address.


This I often read. The argument is that by measuring the current (at least 2 Phases) and calculating the stator/rotor currents you address the changing of the (stator) resistance due to heat (assuming constant voltage)
Unfortunately this is not true unless you have constant voltage, constant load and (almost) constant frequency (slip preferabely too). 
And this is a situation where you are often not in controlling a vehicle.
Practically you want to use the measurements of the currents to calculate your model SVPWM voltages (imeaning setting the appropriate stator Voltage and frequency). 
During heating which always occurs , resistance AND inductance changes and BOTH affect the calculation. These leads to severe model errors which only can be corrected by
1) Using encoder for speed AND angle measurement and feedback and make an additional outer loop to correct this.
2) Adjusting motor parameters (L,R) to known conditions
3) Using slip control  This leads to next point

FOC and DTC correct nothing magically. You have to correct that by yourself or let the motor do that. Typically you try to put the pedal in the "right" position so your FOC /DTC does go again. 
The Matlab -model works it shows violent current spikes and torque-load ripples not going to happen in real life (gearbox will die sooner or later)
A standard inverter usually shuts off or coasts.




> If you also control slip, you are also controlling the ratio of stator and rotor currents. Do you have a reason for this? .


This is right and this is the "problem" of slip control, it affects both the amplitude AND the angle between the stator and rotor components.
By holding slip constant and only boosting the voltage stator and rotor components rise equally meaning Torque rises in second order.
By applying both slip and voltage-control you can somewhat get more "linear" torque but with cost of efficiency. But sometimes it is better to have less torque ripple than more efficiency. 
In previous post I did post a paper which uses slip control to help minimize torque ripple in DTC.
In theory controlling stator and rotor current and the angle between means that you can control speed and torque lineary. 
In practice this is only possible up to certain point.


----------



## gunnarhs (Apr 24, 2012)

jhuebner said:


> So I have a question. In the datasheet of my motor it states:
> *[email protected] rpm* and *120Hz *field speed and *360V *stator voltage. Thats *0.7Hz* slip. The rated torque is about *50Nm*. To achieve the same torque at half the speed that would be *180V *and *60Hz*.
> Now, they also specify a peak torque of *200Nm*. How do I get to that? By applying *4*[email protected]* or by setting the slip to *4*0.7Hz*? Or a bit of both?


For best behavior you would do a bit of both.
If you have good speed try to use a bit more Voltage (you should have it)
If you have low or very high speed try to use more slip (at high speed increase frequency after increasing Voltage as much as possible)

But try to avoid maximal torque at start, it should be applied when overtaking the Nissan Leaf


----------



## Siwastaja (Aug 1, 2012)

jhuebner said:


> So I have a question. In the datasheet of my motor it states:
> *[email protected] rpm* and *120Hz *field speed and *360V *stator voltage. Thats *0.7Hz* slip. The rated torque is about *50Nm*. To achieve the same torque at half the speed that would be *180V *and *60Hz*.
> Now, they also specify a peak torque of *200Nm*. How do I get to that? By applying *4*[email protected]* or by setting the slip to *4*0.7Hz*? Or a bit of both?


By applying *2*[email protected]*, I'd say!

The magnetic saturation pretty much limits how strong a stator field you can get.

I don't really know whether it helps or not to increase the slip near the magnetic saturation point (if you also have extra voltage at your disposal). It may help. It needs to be tested in practice. This is exactly why we created our slip control -- to test the really underlying principles directly, whereas FOC abstracts those away.

I think it is generally better to have a bit more slip than too little. Too little just means energy transfer back and forth. It keeps the rotor "charged up" to respond quickly to changing load, but that's something that doesn't happen in a car, instead we want smooth torque control. A bit more slip also allows getting a bit more torque. The efficiency starts dropping when the slip gets much higher. How much, it depends on the motor and you should find the actual motor curves. Just don't go near to the breakdown slip. You see, where the torque curve starts to flatten, the current still rises quickly so the efficiency quickly drops. 

But the voltage control should clearly be the _primary_ torque control mechanism. This is very evident if you try to coast by instructing zero slip (synchronous speed) with full rated voltage. You use a lot of power to do nothing. Just like underloaded ACIM driven off the wall. If you control it with voltage, well, it naturally becomes 0 volts and no power is consumed at all.

Disclaimer: I still don't fully understand everything, so correct me if something is wrong.


----------



## PStechPaul (May 1, 2012)

As I think I said before, you can't really control slip (or speed, for that matter, or torque). Those are all measured or estimated, and the only thing you can actually control is the applied voltage and frequency (which includes various waveforms). Just as with an ICE car, you do not control speed or acceleration. You just ask for more/less acceleration or higher/lower speed. The operator adjusts the accelerator to provide more or less fuel and air, and the engine responds according to its design parameters.

You can measure current and speed and determine the slip since you know the applied frequency. With a constant V/F, I think torque is proportional to slip. But you can reduce the voltage to increase slip without increasing torque. And similarly you can increase frequency at a fixed voltage to increase slip with the same, or less, torque.

The rated slip frequency is probably the optimum point where efficiency is best at rated torque. But you may be able to reduce losses at different combinations of voltage and frequency for a given set of conditions. Efficiency requires power input and output to be meaningful. Losses will be lower as voltage and frequency are reduced, but power factor may also be significant.

Anyway, just trying to understand these motor concepts from my own perspective and rather limited experience.


----------



## Siwastaja (Aug 1, 2012)

PStechPaul said:


> As I think I said before, you can't really control slip (or speed, for that matter, or torque). Those are all measured or estimated,


ARGH, not again! Read my previous replies.

Yes you directly apply any slip you want because you can directly control it by the very definition of what slip is! You GENERATE the waveforms by yourself so you can apply ANY frequency you want in real time, and slip is just a difference in two frequencies, other one you know all the time, other one you set.

There always is a small error due to finite response time and finite measuring accuracy when you measure the rotor rpm and set the frequency you want, but it doesn't mean you can't control slip directly. You control it *directly* with a small amount of error.




> Just as with an ICE car, you do not control speed or acceleration.


Which is true. But in an ICE car, you can control the amount of gasoline you inject as exactly as you want if you build it that way.

There are things you can control directly (such as motor voltage, frequency and slip), and things you control through other parameters and can only approximate: motor current, actual speed, torque. You are just putting slip on the wrong category because you are thinking about the fixed frequency (wall socket or basic V/f inverter mode) usage without encoder feedback.

The _core idea_ of the slip control is to move the slip from the "indirectly controlled" (as in simple sensorless V/f) category to "directly controlled" category. Encoder makes this possible.

You also may be thinking that we adjust voltage to get certain slip in a PI(D) loop. That's not true either. We have no control loops in our system at all. In fact, our base algorithm doesn't even run sequential logic! It's all combinatorial. We set the slip _directly_ outside any other calculation process. Then, parallel to that, we control voltage to control the torque, and the only thing that makes this work _is_ the realtime application of the slip that keeps it constant in all situations. Yes, _directly_.



> You can measure current and speed and determine the slip since you know the applied frequency.


NO, you don't "know" the applied frequency, you S E T the applied frequency, which SETS the slip because you KNOW the actual RPM.

Let me give an example.

- You request more torque by pressing the pedal to the floor.
- The algorithm sets rather high voltage to the motor
- The motor produces a lot more torque due to higher voltage, and will increase its speed.
( If we stopped here, we would have decreased the slip which would decrease the torque again, but forget this, we *never* want that to happen )
- The encoder quickly sees this increased speed, and keeping the slip constant, the inverter frequency is increased accordingly.
- We gain more speed







> With a constant V/F, I think torque is proportional to slip.


Exactly. Which makes V/f control unusable in a car. Yes we tried it. Both the motor and inverter became hot very soon.



But guess what? When you directly control _slip _to keep it constant, you don't have free control of the frequency anymore. Frequency control is only used to satisfy the slip, so you cannot simply use it for another purposes at the same time. And you wouldn't want to, either. This is a torque control where the only input is torque. BTW, this is exactly how FOC and DTC also work. All proper motor control algorithms only control torque, and if you then want to control speed, _then_ you will need the PI(D) loop.

I hope you appreciate me putting so much time on explaining this same thing to you over and over again. Please try to do your homework also, and read this reply through as many times as you need to get it. Think about it, use your brain. I bet you are lost by reading too much, but this is not explained anywhere. You need to use your own gray cells... (Not CALB)


----------



## PStechPaul (May 1, 2012)

I think we are saying the same thing with different words, and my assertion may be academic. Yes, you do apply a certain, calculated slip, but it is actually a frequency. And the _*frequency*_ you apply is equal to the rotor frequency plus or minus the slip. But you also need to know the motor characteristics or perform other calculations to determine the correct _*voltage*_ to apply at this frequency. Therein lies the "magic". The motor has three wires and the only thing you can do is apply a certain amount of voltage at a certain time, and then vary that voltage based on measurements you make on the rotor position and current, which are really the only things you can measure on the time scale of the PWM frequency. It is very difficult to measure torque directly, except that the vehicle operator feels the torque as acceleration and adjusts the pedal position accordingly to get what is needed.

This is probably more of an exercise in philosophy and semantics, rather than engineering and technology, and what matters most may be how each of us understands (or not) how the motor operates and what is needed to provide the desired torque and RPM with the highest efficiency and/or performance. And in one article about the pros and cons of DTC and SVM techniques, it was shown that there may be trade-offs between the two and the choice may come down to personal choice and need, and it may even be possible to "tune" the algorithm according to what the driver wants at any given time.

Thanks for the effort to explain this from your perspective. Until I actually build and test a motor controller of my own I can only comment from a theoretical basis and not direct experience.


----------



## Siwastaja (Aug 1, 2012)

Well, even when we can control slip directly, it should be noted that slip itself is a useless "intermediate" quantity. What we really wanted to control is rotor current. FOC and DTC are there to model exactly that; these need to control the rotor current through the slip, too, but they can abstract the slip term away from the algorithm.

Slip control OTOH just accepts the compromise that a constant slip is good enough in providing the rotor current we want. If we can make this compromise, slip control is indeed at least two orders of magnitude simpler than FOC or DTC. It's unbelievably simple, and for its simplicity, it's working really well.


----------



## gunnarhs (Apr 24, 2012)

Siwastaja said:


> Well, even when we can control slip directly, it should be noted that slip itself is a useless "intermediate" quantity. What we really wanted to control is rotor current. FOC and DTC are there to model exactly that; these need to control the rotor current through the slip, too, but they can abstract the slip term away from the algorithm.
> 
> Slip control OTOH just accepts the compromise that a constant slip is good enough in providing the rotor current we want. If we can make this compromise, slip control is indeed at least two orders of magnitude simpler than FOC or DTC. It's unbelievably simple, and for its simplicity, it's working really well.


So true, so true, I am thankful for this thread.
For those who still believe online estimation of parameters is easy in FOC-model I finally found a paper estimating the rotor time "constant" on the fly by using a FOC-approach
http://web.eecs.utk.edu/~tolbert/publications/trans_cst_mar_2007.pdf

So you FOC-fans have the choice, adding some slip control to your stuff or code this addition described in the paper to the Tumanako-FOC-project
But yes, they have abstracted the slip term away from the algorithm, actually it seems that this (still ideal model) works in the slip-frame.

For my case, I prefer using the slip control in addition to the DTC- current model (or slip control with DTC-current field model)...


----------



## jhuebner (Apr 30, 2010)

Siwastaja said:


> Slip control OTOH just accepts the compromise that a constant slip is good enough in providing the rotor current we want. If we can make this compromise, slip control is indeed at least two orders of magnitude simpler than FOC or DTC. It's unbelievably simple, and for its simplicity, it's working really well.


It would be really nice if someone could compare the efficiency of slip control to that of DTC or FOC. Under real driving conditions, not some contrived steady state.
Like driving the same uphill stretch 10 times with slip control and 10 times with DTC and see how much more energy is used by slip control.


----------



## gunnarhs (Apr 24, 2012)

jhuebner said:


> It would be really nice if someone could compare the efficiency of slip control to that of DTC or FOC. Under real driving conditions, not some contrived steady state.


Ok I can give you preliminary number in km/kWh.
But the problem is different cars/inverters/battery due to limited budget. I will provide new (corrected) numbers when we have new batteries and same control box.

Car parameters: 1000kg, 70 km/h average speed, average outside temp 10 degree C

Conversions use gearbox/ATM except Peugeot 106 has direct drive
Nissan and Mitsubishi commercial cars use direct drive.

Conversions do not use electric heating, 
Nissan and Mitsubishi use some, but during tests as little as posible.

3 phase standard induction motor (Chinese Suzuki WagonR Gearbox/ATM)

FOC without speed feedback (no temperature correction) : 5km/kWh
FOC with speed feedback (no temperature correction): 5km/kWh
Basic slip control with voltage boost: 6 km/kWh
Slip control with voltage boost and current field calculation (no SVPWM):
8 km/kWh

DC-Motors (Daewoo Lanos)
DC-series current control : 5km /kWh

Sep-Ex Motor (Peugeot 106 with LiFeYPO4)
FOC -SepEx depending on Motor speed: 8 km/kWh (!!)

PMSM (Mitsubishi MIEV, Nissan Leaf)
Advanced FOC with speed feedback: 5 km/kWh

Best driving behavior : 
Daewoo Lanos DC-series (over 90 km/h) and Nissan Leaf PMSM (up to 90km/h)

Worst driving behavour:
Chinese Suzuki WagonR with FOC without speed feedback. 
Absolutely dangerous with TECOS Westinghouse FOC. 
(2 major accidents including almost rollover and crash)


----------



## PStechPaul (May 1, 2012)

Those are very interesting figures. I was also a bit surprised to see the SepEx also giving the highest range figure of 8 km/kWH. This translates to about 200 Wh/mile, which is excellent. I think the only definitive test would be a reconfigurable controller which could be installed in one vehicle with an ACIM and comparisons made with various control methods. It would also be helpful to use a datalogger to record the temperature of the motor and the controller, which should be a good indication of the losses, and where they are experienced.

There should also be some sort of measurement of drivability and performance, which could include at least the 0-60 MPH (or equivalent) time on a flat track, and regeneration measured on a hill. It may also be useful to determine maximum torque from standstill, which could be done with a variable slope incline to see what the maximum percentage slope can be obtained.


----------



## jhuebner (Apr 30, 2010)

gunnarhs said:


> 3 phase standard induction motor (Chinese Suzuki WagonR Gearbox/ATM)
> 
> FOC without speed feedback (no temperature correction) : 5km/kWh
> FOC with speed feedback (no temperature correction): 5km/kWh
> ...


So that was always the same car? Slip control did better than foc?
Whats slip control with current field calculation?



PStechPaul said:


> Those are very interesting figures. I was also a bit surprised to see the SepEx also giving the highest range figure of 8 km/kWH. This translates to about 200 Wh/mile, which is excellent. I think the only definitive test would be a reconfigurable controller which could be installed in one vehicle with an ACIM and comparisons made with various control methods. It would also be helpful to use a datalogger to record the temperature of the motor and the controller, which should be a good indication of the losses, and where they are experienced.
> 
> There should also be some sort of measurement of drivability and performance, which could include at least the 0-60 MPH (or equivalent) time on a flat track, and regeneration measured on a hill. It may also be useful to determine maximum torque from standstill, which could be done with a variable slope incline to see what the maximum percentage slope can be obtained.


Yes, that would be perfect. 

Also the paper posted by gunnar is interesting as it has some actual numbers for the rotor time constant. It starts out at 0.115s and decreases to 0.09s as it heats up. Thats a 20% decrease. So I guess slip-wise that means you'd have to increase the slip by 20%. For my motor thats from 0.7Hz to 0.84Hz. Doesn't sound like much...


----------



## Siwastaja (Aug 1, 2012)

Slip control did randomly better, because in reality the differences are so small that all random errors will be an order of magnitude higher than any real difference in inverter algorithm.

Guys,

All electric vehicles (that work) have excellent efficiency. If they didn't, the concept just wouldn't work; they would blow up or require special cooling systems (something you wouldn't build by accident). The cooling just isn't designed for any more losses than 10-20% or so.

Consider this;

A good controller has an efficiency of 98%. At 20 kW motor power, it produces 400 watts of heat. What if the efficiency was dropped to 85%? That would decrease the electric "mileage" by mere 15%, something that's very hard to see without careful testing, but it would generate 3 kilowatts of waste heat, something no cooling system is designed to dissipate. So it would blow up.

The same goes for the motor.

The only way you can run an inefficient system "by accident" is to hugely oversize the components.

But to have a real efficiency issue by accident, it would require some serious dragging of the brakes etc. You'd probably notice that, too.

My point being, any efficiency difference in an _usable _and _working_ EV _motor and controller_ combo will be a few percentage points. You can have 200 Wh/km with one random motor and controller, and maybe 180 Wh/km with a better control algorithm, but that's about it.

In order to really see that kind of difference, you need closely controlled dyno runs.

You can have bad efficiency by running, for example, standard V/f, but you will notice that by having a totally unusable car that's impossible to control and overheats quickly.

The numbers stated above probably have an error margin that explains all the differences alone.

So the right conclusion is that all those conversions work as intended and all have similar efficiency. No point in comparing further without getting real data first. This data is meaningless. You really need a careful study to find what the real efficiency is. But does it matter? I'd say no; you have great numbers that prove that all these cases do work as intended, and all have potential for further study.

And I'm not saying not to optimize the efficiency as much as possible. In the big picture, it makes a lot of sense. But it's pretty damn difficult and you need very good testing facilities.


----------



## Siwastaja (Aug 1, 2012)

Let's put it another way;

Let's assume that those numbers are correct and a FOC system gets 5 km/kWh = 200 Wh/km, and a slip control system gets 8 km/kWh = 125 Wh/km.

Let's further assume that the system that scored better (slip control) has an average motor efficiency of 92% and an average inverter efficiency of 98%. These are pretty much the upper limits unless you are running some very special hardware. The combined efficiency is 90% and when you run at 15 kW, you produce 1200 W waste heat in motor and 300 W in the inverter.

Now, assuming that the measured efficiency differences are correct, it means that the FOC system uses 200/125 = 60% more power. All this power is wasted as heat. So, instead of 15 kW, we use 24 kW. This means 9 kW more heat. The combined efficiency is 56%.

The only way this would be possible is by running a hugely oversized motor and controller that can stand the heat.

Sounds totally impossible?

I agree.

So the data is wrong. Sorry . The real explanation: the differences in the testing environment. Different cars, different driving styles, different routes, different speeds. 

As a _range_ difference, it's not _that_ much, but as a _motor/controller_ efficiency difference, it's impossible.

If they were gasoline cars, that kind of difference in efficiency wouldn't be strange at all! This brings us back to the very foundation of the electrification of the cars; it's always easy to improve when the starting point is totally crap, like the efficiency of ICE vehicles. Add 10 %points to 10% and you have made a huge difference. But then, it's pretty hard to improve something that's already 90% the way to the perfection. Even if you did manage to get it to 100%, it would be a rather minor improvement.


----------



## gunnarhs (Apr 24, 2012)

jhuebner said:


> So that was always the same car? Slip control did better than foc?


Same car, my slip control with my inverter was better than FOC of standard TECO-Westinghouse Inverter for this special case.


> Whats slip control with current field calculation?


You calculate stator/rotor field with Clarke-Transformation like in DTC/FOC
During the V/F operation angle is adjustable by tuning the acceleration time. By tuning the time scale of the voltage profile you can modify the proportion of the stator/rotor currents as mentioned in previous posts.
Higher acceleration profile makes the rotor current relatively larger than stator current because it needs more torque to accelerate the rotor. 
On the contrary,lower acceleration profile makes the rotor current relatively smaller than the stator current.
As mentioned before the voltage decides the amplitude and the (set)slip the angle and therefore proportion of the stator/rotor currents. The current model helps you adjusting this in the right direction. 
You can use a custom table like DTC, additional info (transformations as in FOC), SVPWM-map, Voltage ramp, temperature-map or anything else to set your Voltage/Frequency parameters for your Inverter. 
It depends on the need of your application.




> Also the paper posted by gunnar is interesting as it has some actual numbers for the rotor time constant. It starts out at 0.115s and decreases to 0.09s as it heats up. Thats a 20% decrease. So I guess slip-wise that means you'd have to increase the slip by 20%. For my motor thats from 0.7Hz to 0.84Hz. Doesn't sound like much...


I am angry not having found this paper before. It says that change of Rotor time constant (average change is slow) can be estimated with (crude) temperature measurement. I have had the feeling but not the proof before.If true this could simplify parameter estimation a lot. Until then I rely on slip


----------



## gunnarhs (Apr 24, 2012)

Siwastaja said:


> A good controller has an efficiency of 98%. At 20 kW motor power, it produces 400 watts of heat. What if the efficiency was dropped to 85%? That would decrease the electric "mileage" by mere 15%, something that's very hard to see without careful testing, but it would generate 3 kilowatts of waste heat, something no cooling system is designed to dissipate. So it would blow up.


The controllers used have an efficiency-spectrum of 90 -98%.
At 20 KW they loose 200 -2000W 
No problem there, dissipation gets a problem over 4000W



> The same goes for the motor.


No, you are totally wrong there. you obviously have no idea of the real efficiency of an induction motor. For a fully loaded 2 Pole motor it varies from about 50% to 90% most the time when driving it through a cycle.
When partly loaded additional Back-EMF makes it worse.
You get the 90% efficiency only in a small region when having full load (small back EMF), optimal Voltage and frequency. The trick is to stay there



> The only way you can run an inefficient system "by accident" is to hugely oversize the components.


Getting 5 km/kWh per 1000 kg and average speed of 50-70 km/h is an quite efficient system compared to ICE, but it can be improved a lot. The theoretical limit according to BMW data is that you need 15 kW to keep a 1500 kg. car at 100 km/h.
So assuming a car with fairly good efficiency you could easely reach 10 km/kWh for 1000 kg vehicle at about 70 km/h.



> My point being, any efficiency difference in an _usable _and _working_ EV _motor and controller_ combo will be a few percentage points. You can have 200 Wh/km with one random motor and controller, and maybe 180 Wh/km with a better control algorithm, but that's about it.


I do not agree with that. Small errors in a control providing torque-ripple can reduce efficiency in inverter of up to 5%, in motor of 20% and in gearbox/ATM of 10% (you seem to have forgotten that part)
A totally wrong control strategy usually shuts down the inverter. 
So instead of
0.97 * 0,90* 0,95 = 0,83 you can have
0.93*0,70*0,90 = 0,59

In the Inverter and gearbox/ATM you will experience most of the losses as heat. In the motor 60% will be heat, the other will be EMI-related.
But do not worry about the motor, your inverter will usually die first




> In order to really see that kind of difference, you need closely controlled dyno runs.


Why should a rightly configured dyno give other results than driving the car?
And why do you prefer dyno to a real road test?
(The dyno-tests by the way is one of the reason why you get this totally out of reality values from OEM in terms of usage.)

Have you ever seen inside a car production and test feature?

(My first job I did at MAN was throwing out their fault dyno-measuremnt by the way...)



> You can have bad efficiency by running, for example, standard V/f, but you will notice that by having a totally unusable car that's impossible to control and overheats quickly.


Well in multiple tests the cars went at least 50 km, the Sepex car up to 200 km.



> The numbers stated above probably have an error margin that explains all the differences alone.


There is for sure a error margine of maybe 10% due to different conditions but you must realize that the DC-cars are driven over 30.000 km and the AC about 1000 km.

In my case I made the mistake to compare different inverters for the induction motor, for the other cars which have been driven for 30.000 km each the last 2,5 years I have nothing to add.

I will clarify it here the induction motor test.

First inverter result:
FOC with speed feedback (not angle position feedback) gives better driving behavior but not better overall efficiency.
Here I could only change parameters but not the software itself as it is a standard inverter.

Parameters during driving (yes I will provide logs next time, sorry for that)
Rated efficiency of the standard Teco 37 kW Inverter is 95 %
Average efficiency during driving with average 15 kW was 90%
Average efficiency of the drivetrain (motor / ATM/wheels) was about 60 %
After finishing 10 kWh we had driven 50 km (yes average speed slower than 70)

Second Inverter result:
Rated efficiency of our 50 kW, 98,7 (99% my friend says but he is still arguing)
Here I have programed the control myself (my partner did the FPGA-part)

First we have "basic" slip control as in water pump

I measured average efficiency of 97% in the inverter during 15 kW
Average efficiency of the drivetrain (motor ATM/wheels) was about 66%
After finishing 10 kWh load we had driven 60 km (yes average speed slower than 70)

Then we did add the field control

I measured average efficiency of 98,5 in the inverter during 15 kW
Average efficiency of the drivetrain (motor ATM/wheels) was about 78%
After finishing the 10 kWh load we had driven 75 km (yes average speed a bit faster than 70)




> And I'm not saying not to optimize the efficiency as much as possible. In the big picture, it makes a lot of sense. But it's pretty damn difficult and you need very good testing facilities.


I could use the Universities dyno but it is still waiting to get configured (guess who will be asked to help with that?)
It did put out pretty bullshit last time when my collegue used it 
(far to good results). 
Actually they were really measuring the efficiency of the dyno I assume 
But real road tests are better, just go to your local OEM and get their data.
Then test the car yourself. I expect about 50% difference in fuel usage. (independent of type of car, electric or not)


----------



## PStechPaul (May 1, 2012)

Efficiency measurement can be deceiving, and a better metric may be the losses incurred under various conditions. A motor generally has best efficiency at its rated power, torque, and RPM, and at that point it may also have the highest losses. At the same speed but reduced torque, or at the same torque but lower speed, the losses should be less. But even though the output power is also much less, the efficiency as a ratio of power out to power in may actually be higher. IIRC the losses due to resistance are proportional to the square of the current, while losses due to frequency (speed) are proportional to the square root of speed.

Thus a 10 kW motor with 90% efficiency might have 1000W of losses at rated speed of 1800 RPM and 53 N-m torque, drawing 25 amps at 440 volts (11 kW). If the losses are resistive, the motor has an ESR of 40/25 = 1.6 ohms. At half the torque and half the current, output power will be 5 kW with losses of 12.5^2 * 1.6 = 250 watts, so efficiency will be 5000/5250 = 95.2%. This does not take PF into account so that may result in lower efficiency, although a good motor control algorithm should be able to come pretty close. I don't know if this is verified by actual data, but I think it should apply over some reasonable range of torque and RPM.


----------



## gunnarhs (Apr 24, 2012)

Siwastaja said:


> Let's put it another way;
> 
> Let's further assume that the system that scored better (slip control) has an average motor efficiency of 92% and an average inverter efficiency of 98%. These are pretty much the upper limits unless you are running some very special hardware. The combined efficiency is 90% and when you run at 15 kW, you produce 1200 W waste heat in motor and 300 W in the inverter.


Actually my result was that pure slip control was slightly worse than slip control with field correction when comparing same Inverter. 
But this was misleading comparing two total different inverters, I admit.
In case of our maximal efficiency I have not measured the motor without gearbox/ATM but according to specs it is near 89%. 
The ATM now applied looses from 3 to 10% in efficiency, so best is 97%. 
Having an excellent inverter of 98,7% my maximal possible efficiency would be:
0,987*0,89*0,97 = 0,85 which is 85%.
My best average is well under 80% yet so I can still improve. 



> Now, assuming that the measured efficiency differences are correct, it means that the FOC system uses 200/125 = 60% more power. All this power is wasted as heat. So, instead of 15 kW, we use 24 kW. This means 9 kW more heat. The combined efficiency is 56%.
> The only way this would be possible is by running a hugely oversized motor and controller that can stand the heat.
> Sounds totally impossible? I agree.


Start at the beginning, then stop. 
I have already corrected myself regarding different inverters.
Now lets look at the Inverters first.

The standard inverter has about 7 percent less average efficiency which craves at least 5% of it using forced cooling. 
This is expressed in a set of fans in the bottom of the box (the other inverter does not need this under 30 kW) This means at 15 KW up to 1 kW has to be provided by the fans. Assuming not so efficient fans we loose about 1,5 KW additional for cooling the inverter.

The other place we lose is about 500 -1000W in the ATM if FOC fucks up the desired speed and torque (which it does more often during standard-inverter) So lets assume additional 500W on the ATM -cooling pump.

Together we have additional losses of 2 kW because of the cooling system
(Thank god we have not electric heating too in the converted cars).
Driving about one hour makes the car use up to 2 kWh more energy.




> So the data is wrong. Sorry . The real explanation: the differences in the testing environment. Different cars, different driving styles, different routes, different speeds.


The range is (was) there...
Same driver(-s) same route in case of AC.
Difference in outside temperature and weather.



> As a _range_ difference, it's not _that_ much, but as a _motor/controller_ efficiency difference, it's impossible.


Inverter efficiency counts twice if it needs forced cooling.
Same for drivetrain, but we get away having poor efficiency in the AC-motor without extra cooling.
You sound a bit like the boss of Bosch. 
My answer to him after looking at their system for Porsche : 
Stay away from the electric powertrain and keep on the good work with the electric car locks (would prefer IP 55 motors though).
But I have more believe in the crew here in diy at least they are driving the cars.
I am sure we would have done better with the 500 million euro budget



> But then, it's pretty hard to improve something that's already 90% the way to the perfection. Even if you did manage to get it to 100%, it would be a rather minor improvement.


If we were at 90% then if using BMW data their 45 kWh battery pack should get their new car 300 km range. I bet they will have problems getting 200 km. I would say we are getting up to 60-70% Tesla seems to have maybe 80%.


But the question still remains, why are we still so far away?

Possible explanation:

1) To much extra electric heating and cooling, takes up to 30% of range
2) We have good maximal efficiency but with standard inverter/motor technology our average efficiency is still well under 80%
The best player (Tesla)does builds all the stuff himself
3) Known concepts not used. Why are electric cars build as low speed citycars (ATM /gearbox can help with torque at higher speeds)


----------



## gunnarhs (Apr 24, 2012)

PStechPaul said:


> Efficiency measurement can be deceiving, and a better metric may be the losses incurred under various conditions. A motor generally has best efficiency at its rated power, torque, and RPM, and at that point it may also have the highest losses. At the same speed but reduced torque, or at the same torque but lower speed, the losses should be less. But even though the output power is also much less, the efficiency as a ratio of power out to power in may actually be higher. IIRC the losses due to resistance are proportional to the square of the current, while losses due to frequency (speed) are proportional to the square root of speed.
> 
> Thus a 10 kW motor with 90% efficiency might have 1000W of losses at rated speed of 1800 RPM and 53 N-m torque, drawing 25 amps at 440 volts (11 kW). If the losses are resistive, the motor has an ESR of 40/25 = 1.6 ohms. At half the torque and half the current, output power will be 5 kW with losses of 12.5^2 * 1.6 = 250 watts, so efficiency will be 5000/5250 = 95.2%. This does not take PF into account so that may result in lower efficiency, although a good motor control algorithm should be able to come pretty close. I don't know if this is verified by actual data, but I think it should apply over some reasonable range of torque and RPM.


Well I look at the total efficiency. If we really had this near to 90% average efficiency most of the electric cars would be in the 300 km range region.

Most efficient gasoline cars are about 30% energy efficient and use 3 liter gasoline to bring a 1000 kg car 100 km. Assuming that one liter gasoline has 10 kWh, 30 kWh at 30% efficiency is needed for 100 km.
If 90 % efficiency is assumed as in electric I should get 300 km with a 30 kWh battery (assuming not much additional weight).
I can tell you that the converted car will give me a bit over 200 km range

So tell me guys where is all the the efficiency lost?


----------



## PStechPaul (May 1, 2012)

The figure of 15 HP for a 1500 kg car at 100 km/hr seems about right. My EV calculator says 16.4 HP or 12.3 kW. That is for a flat road with no acceleration. The energy consumption would be 12.3 kWh for 100 kM or 123 Wh/km or 197 Wh/mile. That probably is based on the power required given typical rolling resistance and aerodynamic drag. If you actually measure 250 Wh/mile then the losses are 50/250 and efficiency is 80%. That seems reasonable if you multiply all the component efficiencies, which might be 90% for the motor, 95% for the controller, and 95% for the drivetrain. That comes to 81.5% efficiency. At 12 kW the heat produced will be about 1200 watts in the motor, 600 watts in the controller, and 600 watts in the drivetrain. Given the size of these components and their average temperature and/or the rate of cooling, that seems about right. So total losses are 2400 watts and the actual power consumption will be 14.7 kW.

It seems that a typical good EV runs about 300 Wh/mile, which would seem to indicate an efficiency of only 67%. But also take into account that the power requirement for a 2% grade is about 28 HP or 21 kW. So depending on what percentage of time is spent going up and down hills and/or accelerating and decelerating, and the amount of energy that can be recouped by means of regeneration, the Wh/mile may reach 400-450. If the motor and/or controller are undersized, their efficiency will become even worse under overload conditions. But then again an EV should use almost no energy when coasting downhill, although the drag and rolling friction would tend to keep the vehicle at the rated speed on about a 2% grade and it would actually require some power on a lesser grade.

Perhaps that helps explain where the losses occur and why efficiency seems so low. 80% is actually quite good.


----------



## Siwastaja (Aug 1, 2012)

gunnarhs said:


> If 90 % efficiency is assumed as in electric I should get 300 km with a 30 kWh battery (assuming not much additional weight).
> I can tell you that the converted car will give me a bit over 200 km range
> 
> So tell me guys where is all the the efficiency lost?


Battery efficiency and mechanical drivetrain efficiency, including the energy transfer from wheels to road, were missing. I guess it gets to about 60-70% from battery to road. But when comparing inverter algorithms, we should stay with inverters and motors..... so I said but of course I'm wrong with that. If you increase the power consumption, you also decrease battery efficiency, and as you said, torque ripple affects the rest of the mechanical drivetrain efficiency. So indeed, it needs to be evaluated as a complete system.

In addition, a 30 kWh battery pack in reality isn't 30 kWh as you don't want to fully discharge it. This is not an inefficiency, but affects range nevertheless.



Anyways, thanks for your great insight. I would like to ask, how did you obtain all of your efficiency numbers? You show several dozen of percentage numbers in your last few posts. How did you acquire those?

What I'm thinking about would be a calorimeter. That would be a rather easy way to measure inverter losses, but for a motor it's a bit more difficult due to the size and the close physical connection to the gearbox.

Also, thanks for clarifying that your test drives were quite of controlled nature. I agree completely that dyno doesn't give real-world data. But, hopefully, it gives _repeatable_ data which is an absolute must when comparing small differences.

My point was that a _proper_ FOC should have good efficiency numbers. You have most certainly had some weird issues. Therefore, we cannot say that advanced slip control increases mileage by 60% over FOC, but that something was certainly wrong with that particular FOC installation.

But your data is really interesting because you show that slip control has been in real use and worked well, which is also our experience at this point. 

I feel good when thinking about all the comments that we should "just implement FOC" even without understanding it as it "just works" and slip control is "so much inferior". I was right from the beginning : simple things work easier than complex things, and from all induction motor theory, simple slip control gets quite close to the optimum -- and has _absolutely nothing_ to do with the so called "V/f" algorithm, which is unusable in automotive traction.


----------



## gunnarhs (Apr 24, 2012)

PStechPaul said:


> The figure of 15 HP for a 1500 kg car at 100 km/hr seems about right. My EV calculator says 16.4 HP or 12.3 kW. That is for a flat road with no acceleration. The energy consumption would be 12.3 kWh for 100 kM or 123 Wh/km or 197 Wh/mile. That probably is based on the power required given typical rolling resistance and aerodynamic drag. If you actually measure 250 Wh/mile then the losses are 50/250 and efficiency is 80%. That seems reasonable if you multiply all the component efficiencies, which might be 90% for the motor, 95% for the controller, and 95% for the drivetrain. That comes to 81.5% efficiency. At 12 kW the heat produced will be about 1200 watts in the motor, 600 watts in the controller, and 600 watts in the drivetrain. Given the size of these components and their average temperature and/or the rate of cooling, that seems about right. So total losses are 2400 watts and the actual power consumption will be 14.7 kW.
> 
> It seems that a typical good EV runs about 300 Wh/mile, which would seem to indicate an efficiency of only 67%. But also take into account that the power requirement for a 2% grade is about 28 HP or 21 kW. So depending on what percentage of time is spent going up and down hills and/or accelerating and decelerating, and the amount of energy that can be recouped by means of regeneration, the Wh/mile may reach 400-450. If the motor and/or controller are undersized, their efficiency will become even worse under overload conditions. But then again an EV should use almost no energy when coasting downhill, although the drag and rolling friction would tend to keep the vehicle at the rated speed on about a 2% grade and it would actually require some power on a lesser grade.
> 
> Perhaps that helps explain where the losses occur and why efficiency seems so low. 80% is actually quite good.


Ok thanks for this input Paul and back-checking the BMW-data. This actually could explain why for example the Sep-Ex car is performing that well, it has a 11 kW Motor but the other converted cars have a 15 kW Motor. Meaning that the SepEx is more often "fully loaded" and could therefore have better average performance. But then again the motor may not be over or undersized as you point out. 
In my case there is also an indication that FOC works worse under partial load. But I have still to back it up with some data. At the moment I am changing both battery pack and controller (using Infineon now which has much better logging interface than ours but a bit lower efficiency)

By the way, I did correct the efficiency values for the drivetrain for my own inverter in previous post , I had put in the assumed calculated motor efficiency, not the measured for the drivetrain.


----------



## gunnarhs (Apr 24, 2012)

Siwastaja said:


> In addition, a 30 kWh battery pack in reality isn't 30 kWh as you don't want to fully discharge it. This is not an inefficiency, but affects range nevertheless..


Well I was referring to the usable energy of 30 kWh



> Anyways, thanks for your great insight. I would like to ask, how did you obtain all of your efficiency numbers? You show several dozen of percentage numbers in your last few posts. How did you acquire those?


It was measured during driving. 
Current and Voltage battery side were logged
DC-BUS and 3 phases Inverter (LEM-Hall) at inverter out /drivetrain in too.
What was the main problem was drivetrain-out, as the drivetrain was already in and I never got the change to measure it outside the car 
(I was away when ATM was put in instead of original gearbox) 
I followed a route cars before had been tested with better equipment inside. Out of that I calculated the average energy consumption and compared with the energy put in drivetrain-side.
Temperature on inverter, motor and transmission were also measured but not used in the model. I noticed a significant difference in heat dissipation.

You can see some of the data represented in the different range but not the extra difference of about 10-15% which is mostly wasted in forced cooling. 
By the way, I did correct the efficiency values for the drivetrain for my own inverter, I had put in the assumed calculated motor efficiency, not the measured for the drivetrain.



> My point was that a _proper_ FOC should have good efficiency numbers. You have most certainly had some weird issues. Therefore, we cannot say that advanced slip control increases mileage by 60% over FOC, but that something was certainly wrong with that particular FOC installation.


The point I wanted to make was that in the standard-inverter FOC was not able to "make up" for the standard inverters sluggish efficiency. 
But assuming better efficiency FOC in the standard-inverter and basic slip control in my inverter would have put out quite similar result of 6 km/kWh.
And in the advanced slip control with field correction the first step of FOC (Clarke) was helping the basic slip control (and vica verse of course ) 
But the problem is I never could verify that with high speeds as batteries did not permit that.



> But your data is really interesting because you show that slip control has been in real use and worked well, which is also our experience at this point.
> 
> I feel good when thinking about all the comments that we should "just implement FOC" even without understanding it as it "just works" and slip control is "so much inferior". I was right from the beginning : simple things work easier than complex things, and from all induction motor theory, simple slip control gets quite close to the optimum -- and has _absolutely nothing_ to do with the so called "V/f" algorithm, which is unusable in automotive traction.


Like wise here  I feel though in my case that both efficiency and drive can be improved a lot. So I have made a decision to change the inverter to improve logging and observation of drivetrain data. The surprisingly good performance of the unflexible Sep-Ex Motor (which has the "featus" that the motor armature and field components can be easely set but only specific torque at specific speed) indicates that FOC can do a lot. But not without understanding the underlying motor as you point out.


----------



## parasole (Jun 27, 2013)

Siwastaja said:


> And hey, this project and codes will be openly published pretty soon (I'm not saying "opensourced"; some limits may apply) so just buy a small FPGA board and get the codes from me and you get a motor running


Hi Siwastaja, 
is your offer still available?


----------



## Siwastaja (Aug 1, 2012)

Yeah, I'll get the most recent codes from the laptop and maybe clean them up a bit in a few days! I'd need to come up with a small schematic to help connecting everything up. I'll try to do this next weekend.


----------



## parasole (Jun 27, 2013)

Siwastaja said:


> Yeah, I'll get the most recent codes from the laptop and maybe clean them up a bit in a few days! I'd need to come up with a small schematic to help connecting everything up. I'll try to do this next weekend.


Good to hear, thanks, looking forward for your posting.


----------



## szkarbun (Nov 3, 2013)

Hello Dear Friends
I would like to show you one interesting topic about control method (DTC) asynchronous motor. Design is based on a STM32F4 microcontroller.


http://www.edaboard.com/thread281567.html


----------



## jhuebner (Apr 30, 2010)

szkarbun said:


> Hello Dear Friends
> I would like to show you one interesting topic about control method (DTC) asynchronous motor. Design is based on a STM32F4 microcontroller.
> 
> 
> http://www.edaboard.com/thread281567.html


Looks like good craftsmanship. Is the source code available? I'd love to study it.


Different topic: these days I experimented with slip control and regen. And works perfectly (=braking occurs and current flows into the pack) at low regen torque but as soon as I raise the regen torque above 25% the motor rocks vigorously or the controller does an over-current shutdown. Its very sudden. At 25% its fine, at 30% its broken. When I use a lower gear even 25% can be too much. 
I use the same slip that is used for accelerating.
Any ideas?


----------



## gunnarhs (Apr 24, 2012)

jhuebner said:


> Different topic: these days I experimented with slip control and regen. And works perfectly (=braking occurs and current flows into the pack) at low regen torque but as soon as I raise the regen torque above 25% the motor rocks vigorously or the controller does an over-current shutdown. Its very sudden. At 25% its fine, at 30% its broken. When I use a lower gear even 25% can be too much.
> I use the same slip that is used for accelerating.
> Any ideas?


Hi, I need more information to make a valid suggestion so I am guessing a bit. Also I am no specialist in electronics, so I will assume that your drivers function normally. The regen-problem seems load-dependent (changes with different gears) .
I assume also:
1) The problem to increase if batteries are fully loaded
2) That you are not using a clutch meaning that motor rotor and gearbox are always connected (but in different ratios of course depending on gear.

To be sure what is happening I would try to measure the DC-Bus voltage to see if it rises too much.
I would assume that the problem is that the regen-energy is not absorbed by the power stage (DC-link-capacitor, batteries, dissipative (brake) resistor if present). When this happens energy flows back and forth and motor oscillates. Normally this should not lead automatically to a rise in average current but momentan values (ripple currents) can rise. Temperature will rise for sure as Energy flows back and forth.
To prevent this happening DC-link capacity and dissipative resistor are increased. There is also a possibility during regen to slow the process with a time ramp for example.


----------



## jhuebner (Apr 30, 2010)

gunnarhs said:


> Hi, I need more information to make a valid suggestion so I am guessing a bit. Also I am no specialist in electronics, so I will assume that your drivers function normally. The regen-problem seems load-dependent (changes with different gears) .
> I assume also:
> 1) The problem to increase if batteries are fully loaded
> 2) That you are not using a clutch meaning that motor rotor and gearbox are always connected (but in different ratios of course depending on gear.
> ...


Sorry, bit late on that.
Your second assumtion is correct, I don't use a clutch.

The behaviour doesn't change between full and used batteries. The DC voltage reaches 510V at the subtle regen level I currently programmed. That is 15V above idle voltage (495V).


----------



## gunnarhs (Apr 24, 2012)

jhuebner said:


> The behaviour doesn't change between full and used batteries. The DC voltage reaches 510V at the subtle regen level I currently programmed. That is 15V above idle voltage (495V).


Ok 15V is not much rise in voltage compared to 485V, so my assumption must be wrong, also behavior is same regardless of battery status as you point out. Inertia (load) should ensure that the motor is not slowing down to fast (when only using gaspedal to break).
Next question: 
1) The (average) current should be about the same during negative slip as positive slip (would expect about 30 A + -) is that the case? If adjusted (with time-ramp delay) it would be less during regen. Is that the case?
2) How fast are you slowing down the rpm when gaspedal is released?
Meaning going from 3000 to 1000 rpm in X seconds, what is X in your case when regen behaves normally and you are in 4th gear? Does that change much if slip is to much (assuming bad behavior starts below 1000 RPM)

My hint would be that it has to be ensured that you are in control of the slip all the time and not letting the load control it. This is the analogy when towing a heavy load uphill and downhill using a rope. It is easier controlling it uphill than downhill when just using a rope but when using a iron bar, it would be the same problem. The distance (rope /iron bar length) analogy is the slip. 
The iron bar in this case would be a fixed timeramp (Voltage/frequency slowdown) or use of the current motor model with additional control input if present (voltage/frequency adjustment through SVPWM).
Maybe a stupid analogy but I hope it helps.


----------



## dcb (Dec 5, 2009)

I've been trying to understand the benefits of FOC v/s slip myself.
from: http://industrial.embedded-computing.com/articles/the-versus-field-oriented-control/#

I appreciate the simplifications here, but it seems like slip control defaults to a more efficient setup? whereas FOC defaults to a max transient torque setup with less slip? 

the FOC proponent implies that you can run it more efficiently, but that doesn't make much sense to me. The controller isn't a mind reader, nor is it aware of changing traffic conditions. It cannot predict when you will be wanting/needing acceleration, and it would always have to "be at the ready", at a lower effective slip angle in order to have that transient response which is the claim to fame of FOC. Am I understanding it right? 

FOC can change torque instantly, I see that, but how does it affect an actual vehicles acceleration, say 1/4 mile times? And how much extra energy is spent maintaining that precision control of torque? Indeed some averaging of torque can be useful when you are turning gears, which introduce their own torqe pulses, you don't really want to expend the energy to precisely adjust to every tooth contact, or do you?


----------



## jhuebner (Apr 30, 2010)

I was surprised when I read the page you link that slip is actually more efficient than FOC.
What I'd do with FOC would be setting the id setpoint proportional to the throttle input. The plot shows some 50ms that slip control needs to fully recover from a transient. Of course in a car there is no such speed transient unless you hit a wall. The only transient I can see is a sudden increase in throttle input.
In normal street driving the "slow" transient response of slip control is irrelevant (by my experience), maybe it is relevant in racing.

Next, it is important to know that there are only two variables when controlling a ACIM: slip and voltage.

FOC determines the slip with a more or less sophisticated slip estimator. slip control uses a fixed value or one that scales with the throttle input.

FOC determines the motor voltage with 2 current regulators (that must be adjusted to remain stable). Slip control uses a precomputed (V/Hz) voltage scaled with the throttle input.

In addition FOC needs current sensors on two phases, slip control doesn't. FOC needs a faster micro than slip control, but with todays devices I don't see how that is relevant.

With a very fancy slip estimator that estimates rotor resistance I could see that FOC gets a bit closer to breakdown torque than slip control.


----------



## Tony Bogs (Apr 12, 2014)

Wow, FOC shows a fenomenal step torque response. 
Is anyone on this thread designing or building a BLDC (PMAC) electric power steering? 
Maybe a PMAC drivetrain (FOC is a must)?

After reading this thread in every detail I'm still sticking to ACIM constant slip control 
as described in Freescale's design reference manual DRM115.pdf. http://www.freescale.com/files/microcontrollers/doc/ref_manual/DRM115.pdf.
Without the PI part and speed ramp. I want the driver in the feedback loop. 
A PI controller is an option for cruise control.

The throttle requests a motor speed. It is the 'required speed' signal in the DRM115 schematic. 
The difference between the requested speed and the actual motor speed is the* torque request.* 
It is the input for the output voltage (limiter) stage. 

The system enters regen mode when the requested speed is less than the actual motor speed. 
The slip changes to negative as described in DRM115. A speed difference threshold creates a coasting region. 

Varying the slip and voltage limits changes the properties of the drive system. 
Eco, sport, performance and levels of regen braking. 
In performance mode the parameters are set for the motor's short period peak power region.


----------



## jhuebner (Apr 30, 2010)

Why would you want to take speed into your equation? You can directly use the throttle input for setting motor voltage and slip (after you've run out of voltage)

Mathematically in what you're doing the speed will eventually cancel out.

In an ICE car the throttle doesn't command speed, it commands torque.


----------



## Tony Bogs (Apr 12, 2014)

The throtlle as a speed request has to do with perspective. 

In a iCE where the throttle controls the air intake, it commands power. That's why a lot of ICE enthousiasts love a turbo charger. 
At some speed point the delivered power equals the power needed at the wheels. That's why you can look at the throttle as a rough, load dependant speed * request*. Not a command. It's a matter of perspective. 
Of course, you're right, the commanded ICE power directly translates to a speed dependant torque. At low engine speed the maximum ICE power is generally low. That's where AT torque converters are useful.

Why look at the throttle as speed request? For instance, it makes it very easy to implement a coasting region. So the answer is control options. A bit like DTC. It's a matter of perspective. 

From a efficiency point of view, you don't want to go deep into the high speed field weakening region (max voltage, higher slip).
That's why I am going to use a modified automatic gearbox. And maybe keep the torque converter for the performance setting.


----------



## dcb (Dec 5, 2009)

re: cruise control, anyone considering it should tap into the brake signal to shut it off, and in a manual also monitor vehicle speed vs rotor speed and shut it off if the two dont match a known gear ratio (i.e. clutch or slipped into neutral). For an AT I guess you just have to watch the gear selector switch.

FWIW the ice in the prius uses a generator/motor basically for the torque converter, really don't think you want that turbine in your driveline  The torque converter has even worse efficiency when it slips (plus constant pumping) 

Since you are talking about high loads, you are down in 20% efficiency land on the left there for maybe 50% more torque.
http://www.emeraldinsight.com/content_images/fig/0330220307001.png

whereas the slip for max torque on an acim can be 60% efficient, and provide like 5x as much torque as slip for max efficiency or 2x as much torque as max pf. Electric motors ARE torque converters


----------



## Tony Bogs (Apr 12, 2014)

The torque converter is a maybe. I haven't looked at the numbers yet. 
Modern ATs have lockup. For every day driving in high efficiency eco mode the power losses in the transmission with the converter in lockup must be acceptable. Otherwise it is a no go.


----------



## Tony Bogs (Apr 12, 2014)

Back to the topic: the basics of VFD, FOC and DTC. They are all part of control system design.
Control options, analysis of the drive train (in control terms plant), design criteria and construction. 
Adding the Id/Iq transformations is constructing control options. 

For my ACIM drivetrain I don't need the DTC transformations. 
The reaction time of the modified DRM115 (open loop, no PI) control to a torque step request is more than adequate for a EV.

 Back to basics on the throttle in a ICE.
With the throttle the driver commands a power. To control the acceleration or the speed of the car. The driver is the feedback path in control terms. The driver also determines the properties of the closed loop control system: a acceleration (torque) control system or a speed control system.

How can requested torque and speed be determined from one throttle setting? 

Speed: at some throttle position there's going to be speed Vr where an equilibrium is reached. 
The commanded power equals the power needed at the wheels to maintain that speed. The throttle can be seen as a crude Vr speed request. 
Of course, it is load dependant. A problem? No, because the driver is the feedback path. He can adjust the throttle (power) to match the load. 

Acceleration: When there's a difference between the commanded power and the power needed at the wheels to maintain the momentary speed Va, the difference results in a accelaration torque. 
There's some factor Kt to match the accelaration torque equation: Te = Kt x (Vr – Va). 
Is it important to exactly know Kt? No, again, the driver is the feedback path. 
An estimation will do to construct a torque control option. And, it also works for regen braking. The throttle requests a level of regen braking.


----------



## dcb (Dec 5, 2009)

I've been watching/reading a lot of stuff on field oriented control, I about have pm sorted out but I still don't get (ACIM related):

1. rotor flux angle in an acim, is it changing because of slip? I can't visualize how rotor flux changes over time, even from a rotating frame.

2. if we tailor the peak current of the sinewave at 90 degrees to the rotor flux, are we cancelling out slip?

3. how does independent control of torque and flux help with max efficiency, or max power? 

4. does FOC help with low speed efficiency or power (or low load efficiency)?

5. The motor parameters to enable FOC can be determined on the bench (locked rotor/no load/standstill freq resp), or possibly at runtime?


----------



## jhuebner (Apr 30, 2010)

Tony Bogs said:


> Back to basics on the throttle in a ICE.
> With the throttle the driver commands a power. To control the acceleration or the speed of the car. The driver is the feedback path in control terms. The driver also determines the properties of the closed loop control system: a acceleration (torque) control system or a speed control system.


To that point I absolutely agree. But then it seems you're overcomplicating things. For simplification, lets say V/f ratio control the motor torque at any given speed. Let the throttle control the V/f ratio and you're done. No complicated second order quantities are needed.
With FOC you'd say throttle controls Iq. Period.



dcb said:


> I've been watching/reading a lot of stuff on field oriented control, I about have pm sorted out but I still don't get (ACIM related):
> 
> 1. rotor flux angle in an acim, is it changing because of slip? I can't visualize how rotor flux changes over time, even from a rotating frame.
> 
> ...


1. I gave up on that one
3. It's just a tool. Being able to control those indepently gives you ... control about them  Inherently, this doesn't result in any more effiency or power.
4. No more then slip control. As outlined above its worse at low load conditions if not explicitly commanded to save energy.
5. I read some white papers about determining those at runtime. So it seems possible.


----------



## Tony Bogs (Apr 12, 2014)

DRM115 with speed input is not complicated at all. On the contrary. In fact it makes it much easier to design a road ready EV controller.

1. The car can be driven like a ICE. The throttle acts in the same way. Using the throtlle as a torque input is maybe useful for testing in a lab setting. 

2. The DRM115 control makes it very easy to implement driving modes like eco (high efficiency), sport (less efficient but more torque) and top performance (racing). Modes a driver wants to able to select in a EV.

Finally, FOC and ACIM: who needs lightning speed torque response in a EV? Or in fact in any car?


----------



## dcb (Dec 5, 2009)

Part of what interests me is there was an earlier reference to 10% more efficiency at 25% load and 2% at 50%, with foc. Now I'm used to loading up a gas motor for efficiency, so with acim slip it looks like that still stands, either get on it a bit or coast. And voltage boost looks useful too.

So it seems like the efficiency question can be minimized with driving technique, but this is very speculative. Of course if I have overextended my range and want to limp home, an additional 10% efficiency could be very useful (probably exponential below that load).

As well, reading about full torque at zero speed w/foc? If you can get more out of a smaller motor then that is good.

There is something to knowing the flux angle, the only way I can visualize it, and it may be entirely incorrect, is from the rotor, looking at a strobed image of a field coil, is that the flux angle would sweep across the face of the field, from +180 to -180 magnetic degrees, at a constant rate if conditions/slip are constant. And most importantly, the field sine wave peaks would always be 90 magnetic degrees away from it. We would always be applying peak current where it will do the most good, relatively speaking. 

Wish there was an actual comparison... wish someone had already made it easy  seems like it HAS to be adaptable, not specs from the factory though, especially with temperature being a variable, and it isn't clear how one even validates that their algorithm is doing what it claims to do.


----------



## dcb (Dec 5, 2009)

can someone tell me, plainly, how to compute the output shaft torque reasonably accurately, by measuring phase voltages and currents? Can it be done with one current and one voltage averaged over one magnetic revolution? 

I'm looking for average torque anyway, not instantaneous. It doesn't have to be absolute, just fairly linear. I can scale it later.

I would like to get some feedback while I'm driving, independent of whatever control scheme. If there is an accurate torque measurement available, and a speed signal, then there is a basis for training your foot. And if you compare it to battery volts/amps then you have a basis for efficiency.


----------



## Stiive (Nov 22, 2008)

dcb said:


> can someone tell me, plainly, how to compute the output shaft torque reasonably accurately, by measuring phase voltages and currents?


T_induced = Power(air gap) / w_sync

Where power air gap = sqrt(3)*V*I*PF - 3*I^2*R


You will need to know all the values from the equivalent system model (R1,R2,X1,X2,Xm) to work these out accurately, however you could just assume a constant PF (say 0.8) to get a rough value


----------



## dcb (Dec 5, 2009)

no getting around the rotor there, and stuff like temperature and etc.

Well maybe I can use one of these (not recommended) and monitor the encoder vs the vehicle speed sensor for torque  (abs sensor would be better)


----------



## gunnarhs (Apr 24, 2012)

dcb said:


> I've been watching/reading a lot of stuff on field oriented control, I about have pm sorted out but I still don't get (ACIM related):


I hope I understand your questions right, I will try to answer them here
Controlling an induction motor with FOC is somewhat like controlling a PM with FOC in a field weakening operation (overspeed)



> 1. rotor flux angle in an acim, is it changing because of slip? I can't visualize how rotor flux changes over time, even from a rotating frame.


 It is quite constant if you hold slip constant. But when changing slip then you get an additional component to the id and iq components.
I find it simplest to think of it as if i would do FOC in the "slip frame" (meaning my d and q axis are rotating with slip frequency)



> 2. if we tailor the peak current of the sinewave at 90 degrees to the rotor flux, are we cancelling out slip?


 I am not sure I understand this right.
You might be forcing a constant (low) slip but that will only hold for a constant load / speed condition



> 3. how does independent control of torque and flux help with max efficiency, or max power?


 The calculation of Id and Iq with the motor model itself helps with (rough) estimation of the (average) power factor. 
Due to mutual inductance you will never be able to separate totally the torque and the flux in an induction motor as you can do in a PM (under base speed).
But you can in some way control torque and speed independently as long as you adapt the torque-component to the load, the increased stator flux (voltage) goes into increasing the speed.
The other way is holding a constant (stator) flux voltage and controlling the load/speed only by torque component.
First method gives more efficiency, the second a better torque-response.
As Power is related to Torque X Speed (K*iq X id)
you get a rough idea about your performance and also remember that slip speed is proportional to iq/id


> 4. does FOC help with low speed efficiency or power (or low load efficiency)?


 Not so much in an induction motor if you are using the standardized motor model (parameters) but you can of course adapt that model to work also in low region. 
You have to determine the exact motor parameters which are quite different depending on temperature, meaning low speed under half load is quite different to low speed under full load.
Another method is adding a slip control in the lower region 



> 5. The motor parameters to enable FOC can be determined on the bench (locked rotor/no load/standstill freq resp), or possibly at runtime?


 You have to do both. The standard tests (locked rotor etc.) give you the basic motor parameters (stator resistance, inductances etc.) at optimal conditions.
At runtime you determine the rotor-time "constant" which you use to adapt you parameter-models to changing conditions, mostly due to temperature.


----------



## dcb (Dec 5, 2009)

Well, there are so many unproven models, seems like %99.9999 of FOC is done in a computer with gross approximations about what is actually going on, with no apparent feedback from the real world. Even the adaptive models seem to exist only on paper. What have folks been doing for the past 20 years?

I would think cost effective actual torque measurements, and an indexing encoder, would get rid of pretty much all the guesswork.

Torque sensors can be shaft mounted encoders, or even a well thought out motor mount can be a torque sensor (and quite cost effective). Compared to the cost of a washing machine, the sensor costs can be fairly trivial on the scale of an EV, but most importantly they give real information. And you can calibrate them in the garage with a torque wrench.

If you have a multidimensional tree/map of v/hz/torque/speed/temp/batteryamps/volts, which is easy to observe with sensors, then finding the optimum v/hz (for power or efficiency) is trivial.

Back to basics, you want to know torque, then measure it directly 

EDIT: oh look, Argonne stole my clutch disk spring as torque measurement idea 
http://www.transportation.anl.gov/pdfs/HV/454.pdf

EDIT2: it seems that the clutch disk thing works, and as long as you are making a coupler for your motor to your transmission, adding a couple gear tooth sensors and some teeth on both sides of the clutch so you can monitor phase changes (torque) is fairly straightforward
http://papers.sae.org/2001-01-0869/ and the encoder and wheel speed sensor may be good enough already (though at different frequencies).


----------



## gunnarhs (Apr 24, 2012)

dcb said:


> Well, there are so many unproven models, seems like %99.9999 of FOC is done in a computer with gross approximations about what is actually going on, with no apparent feedback from the real world. Even the adaptive models seem to exist only on paper. What have folks been doing for the past 20 years?


These models have been used in industrial applications for 20 years with success. These applications have usually this spectrum:

1) They use standard (induction) motors .

2) Most of the applications use adequate motor sizing and the motor is running in steady state conditions on a power line (voltage not breaking down).

3) There are two mains of control, speed OR torque (very seldom both)
Meaning either of both is constant.

4) Most of the effort regarding FOC was used for saving costs on sensors, meaning developing an universal control with minimum sensor efforts.

5) All extra developments (2% of the market) uses non standardized FOC which is adapted for a special motor/inverter combination

For an EV:
1) No standard motors (if induction then an overclocked motor usually)

2) Not adequate motor sizing because of problems fitting standard motors in the car, motors applied need often extra cooling. 
When using direct drive you have a start/stop situation which is often not steady state.

3) Because of limited energy reserves (batteries) you need a very efficient control. 
FOC (or DTC) which relies only on controlling the torque-component gives good dynamic response (which is great for driving experience) but is not efficient in start/stop applications.
So a kind of balanced controlled is needed which has to control speed AND torque.

4) You can not save speed sensors on EV due to regulation regarding to ESP/ABS. 
The usual sensors available are not good enough for EV-control with FOC with AC (they are good enough for DC-motors and OK for slip control of AC). 
So for AC with FOC you need to upgrade your sensors.

5) EV is definately an extra market which is small. All FOC - solutions for EV are not universal, they use matched controller/motor combos.



> I would think cost effective actual torque measurements, and an indexing encoder, would get rid of pretty much all the guesswork.
> 
> Torque sensors can be shaft mounted encoders, or even a well thought out motor mount can be a torque sensor (and quite cost effective). Compared to the cost of a washing machine, the sensor costs can be fairly trivial on the scale of an EV, but most importantly they give real information. And you can calibrate them in the garage with a torque wrench.
> 
> If you have a multidimensional tree/map of v/hz/torque/speed/temp/batteryamps/volts, which is easy to observe with sensors, then finding the optimum v/hz (for power or efficiency) is trivial.


I agree on that, I see no reason of saving sensors in EV, the cost is not an issue compared to the total cost and all the trouble explaining to the TUV that your sensorless control is so much better than the previous used ESP/ABS when converting newer cars. Would TUV believe a nerdy guy explaining that he has programmed the perfect "Estimator" which only needs an extra adaptive correction and another calculation instead of measuring real values?



> Back to basics, you want to know torque, then measure it directly
> 
> EDIT: oh look, Argonne stole my clutch disk spring as torque measurement idea
> http://www.transportation.anl.gov/pdfs/HV/454.pdf
> ...


Curious to see your torque measurement in vehicle  . This is a new approach for me not seen this before


----------



## dcb (Dec 5, 2009)

Thanks for explaining the situation, I really wasn't getting it after an incredibly frustrating amount of research or how it applied to EVs.

I will have to test the clutch as torque sensor idea on my civic.

re EPS/ABS: in a civic sized vehicle, I think I would prefer a manual steering rack and some more leverage on the brake pedal


----------



## John Metric (Feb 26, 2009)

dcb said:


> Well, there are so many unproven models, seems like %99.9999 of FOC is done in a computer with gross approximations about what is actually going on, with no apparent feedback from the real world. Even the adaptive models seem to exist only on paper. What have folks been doing for the past 20 years?
> 
> I would think cost effective actual torque measurements, and an indexing encoder, would get rid of pretty much all the guesswork.
> 
> ...


How about a simple smart phone gee-force meter mounted somewhere in the car?
Transform g-force with velocity and you should get a number directly proportional to torque.


----------



## stealthhack (Aug 18, 2011)

Few questions: can a Inverter controls two motors(identical) in Open loop control scheme(2 motors with connected rotors)?
Can a Inverter controls two motors in V/hz mode and deliver their nominal torque from zero speed(again with connected rotors, identical motors).
What efficiency can be estimated in such a drive(losses due to V/hz regulation).


----------



## jhuebner (Apr 30, 2010)

Yes you can do that in open loop.
Maintaining nominal torque without controlling slip is a bit of a guess game. While controlling slip its no problem.
The V/f schema doesn't introduce any extra losses when slip is controlled.


----------



## stealthhack (Aug 18, 2011)

jhuebner said:


> Yes you can do that in open loop.
> Maintaining nominal torque without controlling slip is a bit of a guess game. While controlling slip its no problem.
> The V/f schema doesn't introduce any extra losses when slip is controlled.


So infact two AC24LS(with connected rotors) in V/hz mode can get more torque than one in vector control mode?


----------



## jhuebner (Apr 30, 2010)

stealthhack said:


> So infact two AC24LS(with connected rotors) in V/hz mode can get more torque than one in vector control mode?


Definitely yes, with slip control (i.e. closed loop w/ speed sensor)

Open loop V/Hz mode it will be hard unless you drive some sort of constant speed load. In a car open loop mode is useless (yes, I tested it).

FOC a.k.a vector control is not some sort of magic that mystically squeezes more power out of a motor.


----------



## stealthhack (Aug 18, 2011)

jhuebner said:


> Definitely yes, with slip control (i.e. closed loop w/ speed sensor)


closed loop with speed sensor possible with one controller on 2 identical motors?


----------



## jhuebner (Apr 30, 2010)

stealthhack said:


> closed loop with speed sensor possible on one controller?


I'm not sure I understand your question.

Do you mean whether you can run 2 motors on one controller closed loop with a speed sensor?

If thats what you mean, yes you can. 2 motors share one speed sensor. The controller won't even notice that its driving 2 motors, logic-wise.


----------



## stealthhack (Aug 18, 2011)

jhuebner said:


> I'm not sure I understand your question.
> 
> Do you mean whether you can run 2 motors on one controller closed loop with a speed sensor?
> 
> If thats what you mean, yes you can. 2 motors share one speed sensor. The controller won't even notice that its driving 2 motors, logic-wise.


You inderstand it right, sorry my english in rusty.
Can these 2 motors in this mode make torque from 0rpm?
My controller is sevcon gen 4 size 6 (80V) so i'm hoping to drive 2 AC24LS in closed loop control with acceptable losses.


----------



## jhuebner (Apr 30, 2010)

stealthhack said:


> You inderstand it right, sorry my english in rusty.
> Can these 2 motors in this mode make torque from 0?
> My controller is sevcon gen 4 size 6 (80V) so i'm hoping to drive 2 AC24LS in closed loop control with acceptable losses.


Yes they produce torque from 0.

I'm not sure how a sevcon gen 4 works. My answers about the 2 motor configuration are only valid for pure slip control. If thats what it does, you're fine. You should check with the manufacturer.


----------



## stealthhack (Aug 18, 2011)

jhuebner said:


> Yes they produce torque from 0.
> 
> I'm not sure how a sevcon gen 4 works. My answers about the 2 motor configuration are only valid for pure slip control. If thats what it does, you're fine. You should check with the manufacturer.


Thanks for the good answers.
My motor produce 42Nm in WYE nominal, so hoping 2 identical to produce 84Nm from 0rpm without too much sweat.
that's enough for my daily driving without making too much heat losses.
And Sevcon have *speed control* mode which i think correspond to open/closed loop V/hz control, the 2nd type of controlling with this controller is *Torque control*(maybe FOC or vector control) mode but it's unpractical for dual motor setup.


----------

