True FOC: definition and examples

stancecoke said:
If the rotor position is detected by hall sensors or by a sensorless observer is irrelevant for FOC.
Agreed, with the exception that at low speeds the rotor position is not easily detectable in a sensorless arrangement. Until the rotor moves fast enough to generate a measurable back-EMF you're running blind. (Recent advancements posted here notwithstanding.)
 
Excellent stuff! Thanks so much to everyone participating, feels like I'm getting there. . .

In parsing my homework assignments <g> I see good info about motor classifications and other commutation schemes, going back even before trap vs sine.

Rather than cluttering up this thread I'll start others on those specific topics.

Meantime, back to verifying known "true FOC" examples: Grin PhaseRunner? All the Sabvotons?

and
john61ct said:
whatever is used on Zero electric motorcycles?

Are those proprietary, developed in-house?

 
casainho said:
Lebowski controller it is not OpenSource and it is written in assembly which makes it hard to learn from and adapt.

? I posted the source code at the beginning of this month so how is it not open source ?

I cannot help it when people dont speak assembly, but that doesnt make it any less open source.
 
JackFlorey said:
Note that if you have three wires going to motor windings, due to Kirchoff's Current Law, once you know the current in two of the phases, you automatically know the current in the third. My first hybrid (Honda Civic Hybrid) had only two current sensors for the three phase traction motor for that reason.

I've seen it mentioned numerous times here that a third sensor is not required due to KCL.

One advantage of having a third current sensor is that you can pick the best two current samples and always measure currents away from a switching edge.

For OP's original question, I don't think any shunt/sensor configuration is more "true" as long as the controller is working in the two axis rotor frame.
 
Lebowski said:
I posted the source code at the beginning of this month
And on behalf of the community, thanks for that stellar contribution, and for helping advance the State of our Art so much

 
district9prawn said:
I don't think any shunt/sensor configuration is more "true" as long as the controller is working in the two axis rotor frame.
I assume that "two axis rotor frame" concept is related to
calculating Quadrature/Torque (Iq) current vs Flux/Direct (Id) current via Clark/Park-transformations
? Does that wording cover it well enough?

Cool handle BTW, that film's messages have become ever more relevant since it was released
 
district9prawn said:
I've seen it mentioned numerous times here that a third sensor is not required due to KCL.

One advantage of having a third current sensor is that you can pick the best two current samples and always measure currents away from a switching edge.
Yep, and you get redundancy, and you can do averaging more effectively, and you have to do less math in the code, and then all the phases are the same (easier to design.) Probably the best option is to use three sensors and write the software such that it only needs two to operate.
 
john61ct said:
district9prawn said:
I don't think any shunt/sensor configuration is more "true" as long as the controller is working in the two axis rotor frame.
I assume that "two axis rotor frame" concept is related to
calculating Quadrature/Torque (Iq) current vs Flux/Direct (Id) current via Clark/Park-transformations
?

Yes, and 2 axis rotor frame is a bit more generic, I'd say better suited for a definition. You can do FOC in a 5 phase motor, and in that case I dont know if "Clarke" is the name of the transform that reduces the N rotating vectors to a single rotating vector for the Park transform (probably not).
 
district9prawn said:
JackFlorey said:
Note that if you have three wires going to motor windings, due to Kirchoff's Current Law, once you know the current in two of the phases, you automatically know the current in the third. My first hybrid (Honda Civic Hybrid) had only two current sensors for the three phase traction motor for that reason.

I've seen it mentioned numerous times here that a third sensor is not required due to KCL.

One advantage of having a third current sensor is that you can pick the best two current samples and always measure currents away from a switching edge.

For OP's original question, I don't think any shunt/sensor configuration is more "true" as long as the controller is working in the two axis rotor frame.

Nope, the advantage of the 3rd is reduced noise and common mode cancellation.
 
For me FOC means that (when powering) the motor current vector is lined up with the Back EMF vector, for max efficiency. During regen the current vector is lined up with the Stator voltage vector, again for max efficiency. This is called SOC, Stator Oriented Control.
 
Lebowski said:
casainho said:
Lebowski controller it is not OpenSource and it is written in assembly which makes it hard to learn from and adapt.

? I posted the source code at the beginning of this month so how is it not open source ?

I cannot help it when people dont speak assembly, but that doesnt make it any less open source.
It does not have an OpenSource license.
 
Open Source License ? No clue what that is.... this is why I am not on Github, all this extra management nonsence is what i dont need in my hobby. I have enough of that at work. The source code is there for everyone to see so as far as i am concerned its open source.
 
Lebowski said:
Open Source License ? No clue what that is.... this is why I am not on Github, all this extra management nonsence is what i dont need in my hobby. I have enough of that at work. The source code is there for everyone to see so as far as i am concerned its open source.
That is why I think VESC is a reference/popular because it is OpenSouce since the begin, it is on Github, it is written in C, founder recorded videos on YouTube about it, etc. Seems it is more up to date with actual technologies, the way of developers and users work right now.

I also prefer to code and keep improving but I see that popularity and success depends on many other non technical parts.
 
Let's please not divert the thread, as I specifically requested
john61ct said:
Hi welcome and thanks for joining! Yes I'm a fan of FOSS, but do not want that aspect to be a derail here.

I would prefer to not get into comparisons between projects / controllers, except as pertinent to their implementation (or not) of "true FOC"


 
Lebowski said:
For me FOC means that (when powering) the motor current vector is lined up with the Back EMF vector, for max efficiency. During regen the current vector is lined up with the Stator voltage vector, again for max efficiency. This is called SOC, Stator Oriented Control.
Thanks, that seems at least relatively comprehensible for noobs. However isn't that just a "goal" of the technology?IOW are the true FOC implementations the only way to accomplish that?

_____
Also, I see that an "encoder" can be used, I assume that would be a feature installed inside the motor?

Purpose is to accurately determine real-time rotor position?

Sevcon lists compatibility with three types:
- Absolute UVW encoder input 
- Absolute Sin/Cos encoder input 
- Incremental AB encoder input

Are these usually used in conjunction with current sensors like Halls?

When (if) alone does that count as "sensorless"?

Or can they do the whole job on their own?
 
I think in the truest sense of the word FOC is the jump in reference frame from the outside world (where the rotor is turning) to the world of the rotor, where everything stands still.

Like you walking from the couch to the fridge. Looking at this trip from the moon (lets say the moon is the outside world from the previous paragraph) this is a highly complex journey. You traveling to the fridge but with the earth spinning at 1000 miles an hour, its a miracle you get to the fridge (the 3.6 seconds to the fridge from the perspective of the moon is a 1 mile journey along a complex curve). But on the reference frame of the earth (the rotor from above) this is a simple trip.

FOC has this translation of reference frame in it, making control fairly simple.
 
Yes very interesting concept, it's the complexity of the real-time maths calculations that actually makes the much simpler and more efficient control mechanism possible.

Another analogy maybe, the computerized fly-by-wire aircraft control systems lets the pilot use a greatly simplified joystick rather than physically manipulating the control surfaces.
 
Lebowski said:
For me FOC means that (when powering) the motor current vector is lined up with the Back EMF vector
Could you please explain that a little bit further ? The back EMF will probably not be a sinusoid, so what is the back EMF vector based on ?

i.e. from what basis is it calculated ? Is it based on an average/RMS/best fit of a sinusoid to the back EMF waveform ? Or taking the zero crossing points of the back EMF as a reference ? Something else?
Assuming that the Clarke and Park transforms use sine wave parameters, how are they derived from non-sine signals?

Does the controller produce a sinusoidal profile, or does it match the back EMF waveform ? I thought that FOC produced a sinusoidal wave, and adjusted the timing accordingly. Now I'm not sure if that's correct.

I think I'm in one of those situations where the more I learn, the less I know...

Thanks for taking the time to educate us. This is a really good topic.
 
serious_sam said:
Lebowski said:
For me FOC means that (when powering) the motor current vector is lined up with the Back EMF vector
Could you please explain that a little bit further ? The back EMF will probably not be a sinusoid, so what is the back EMF vector based on ?

i.e. from what basis is it calculated ? Is it based on an average/RMS/best fit of a sinusoid to the back EMF waveform ? Or taking the zero crossing points of the back EMF as a reference ? Something else?
Assuming that the Clarke and Park transforms use sine wave parameters, how are they derived from non-sine signals?

Does the controller produce a sinusoidal profile, or does it match the back EMF waveform ? I thought that FOC produced a sinusoidal wave, and adjusted the timing accordingly. Now I'm not sure if that's correct.

I think I'm in one of those situations where the more I learn, the less I know...

Thanks for taking the time to educate us. This is a really good topic.

You kind of have to know what Clarke and Park transforms do. The Clarke is the more interesting one, its function is to convert the 3 120 degree spaced values to a complex vector (2 values in an xy plane if you're not familiar with complex numbers). A rotating vector (like we have in motor control once the motor is turning) moves around like an hour hand of a watch. Speed of the hour hand is speed of the motor (can have positive and negative values based on direction), lenght of the hour hand the amplitude of the current/voltage/whatever the vector represents.


So the Clarke gets you the end-point of the hour hand from the 3 phase parameters. The Park transform, simply put, is used to add a certain speed to the hour hand (its a frequency shift in the complex frequency domain). If you have multiple hour hands then Park adds the same speed to all.


Now, FOC works by taking the largest hour hand of the backemf voltage and adding a (negative) speed to it (via the Park transform) such that the hour hand stands still. This is then used in control loops who's output is also an hour hand. Then Park is used again to add the earlier subtracted speed. Finally an inverse Clarke turns the 2 XY values of the hour hand end-point back into 3 values (voltages). The point of FOC is that for control loops it is easy to work with the still-standing hour hands, not with moving ones.

When the backemf is not a sine it will take the best-fit sine of the main frequency. A non-sine wave backemf for instance is build (always !) using the main sine frequency and multiples of the main sine frequency. The limited bandwidth of the control loops mean that the multiples of the main sine wave are ignored.
 
Thanks for that detailed explanation. I'll have to look further into the Clarke and Park transforms.
Lebowski said:
When the backemf is not a sine it will take the best-fit sine of the main frequency. A non-sine wave backemf for instance is build (always !) using the main sine frequency and multiples of the main sine frequency. The limited bandwidth of the control loops mean that the multiples of the main sine wave are ignored.
I'm always interested in how theoretical ideas get implemented in reality, and for me this is one of those steps. From what you've said, it sounds like there's not enough time to process something like FFT (maybe you can't "pipeline" the FFT because the result would be too outdated/delayed ?), so more simple/quick method needs to be used to get an approximation. I'm guessing that different programmers must use different methods to calculate that "best fit" ?
 
I understand they are fantastic.

Recently read a rave review in a thread about Nucular helping with motor overtemp reduction / protection under high-amp loading, but can't find it now.

It was asserted in the same post that everyone should go FOC

which I inferred to mean that Nucular is FOC.

But perhaps only in the colloquial sense, not quite "true FOC" in the sense defined here?

I understand that some true FOC models will be inferior in some aspects to fantastic controllers of other commutator technology sub-types

just want to continue clarifying precisely descriptive terminology to facilitate technically objective discussions.
 
Maybe related Q on Sur-Ron

https://endless-sphere.com/forums/viewtopic.php?p=1541028#p1541028
 
Just for cross referencing, casainho's post wrt their TDSZ2 FOSS firmware https://endless-sphere.com/forums/viewtopic.php?p=1547710#p1547710

ostensibly about Field Weakening (off topic here), but looks like some more references wrt FOC's definition there that are worth parsing

This from here, above:
casainho said:
Yes, probably best FOC is on VESC and because it is OpenSource and in C code, which makes much easier to learn from and adapt (just compare the many projects and available knowledge based on VESC).

There are also the OpenSource firmware I wrote for 2 different cheap slow popular STM8 motor controllers and that do FOC but at "low resolution", still, users are very happy with the results (increase of motor torque and battery range)!!
 
FFR, apparently Zero uses Sevcon Gen4 size 6, so fully "True FOC"

with their 75-7 motor, similar to ME1507

and a battery at 28S
 
Back
Top