Thank you for the explanation. My opinion is that having it in line with the duty cycle would be simpler to understand. But I also see what you are saying and its also 100% valid. Think it's best to keep things they are now, as this is working good.
Would you be interested in implementing the FRF measurement functionality? If you want, I can make a topic with some explanation and some pieces of code to make this functionality. With this, you can measure the full frequency response of for example the current loops. Also, you can see the margins and delays in the control loops. I think that with my input it should not be that much work to make the functionality, but the part that is not fully clear to me is the communication possibilities of the VESC. You need to buffer 2047 samples with the code I have. Is this possible?
That would be very interesting. Buffering 2047 samples of all measured values is no problem, it is already how the sampled data plot works. If you start a thread about it we can work on that.
A search of this forum for "flux linkage" brought me here. This is my first post and I must say the competence, professionalism and civility of this thread is truly impressive!
I am new to motor control and would like to understand how the flux linkage (lambda) parameter affects motor performance. I started by reading Viktor Bobek's AN4680. (The URL above is broken, but I was able to find it by Googling.)
This also lead me to wonder about VESC Tool's determination of motor resistance and inductance. How does it know if the coils are wired as a wye or a delta? Or does it not matter in the end?
The Help screen for motor resistance says, "The motor winding resistance should be half of what is measured between two motor wires." So, it must be assuming a wye connection. However in the case of a delta connection, the measured resistance (and/or inductance) would be 2/3 that of an individual phase winding.
I ask this partly because I am trying to reconcile several sources of information (manufacturer's data, my measurement, VESC Tool's determination) regarding motor inductance and resistance.
Nice compliment, thanks. Must say I also like your contibution.
Delta vs wye only matters if you want to compare to datasheet values. Indeed, if you have a delta wired motor, you need to convert the measured resistance and inductance values to delta configuration values.
About the Weber-turns, yes you can call it that, but in my opinion it is better to just stay with the SI label, which is just Weber.
I don't mean to be argumentative but wanted to share what I've learned in the past few weeks. My initial interest in this topic was to understand what affect lambda has on performance. Well, it's integral to the FOC Observer algorithm! But now I'm wondering if lambda is really the right thing to call the parameter?
The first source I referenced regarding lambda was Chapman's Electric Machinery Fundamentals. That's where I got the idea the units should be weber-turns. That textbook says lambda is the summation of the flux phi over the number of turns. Many internet sources seem to corroborate this. Here is the simplest and most complete explanation I found: https://lambdageeks.com/magnetic-flux-vs-magnetic-flux-linkage/
But, I also see that "flux linking", "flux linkage" and "flux" are all described using psi in the MathWorks PMSM Help https://www.mathworks.com/help/physmod/sps/ref/pmsm.html Elwin mentioned in post #2. (Which has been really useful.)
Most importantly, Ortega et al's observer algorithm (referenced in the VESC's Help for Observer Type) uses psi for flux linkage.
Bottom line, the determination of R, L and lambda (or psi as I would prefer to call it) are integral to the proper operation of the Observe. It now seems unthinkable to me that tweaking any of these parameters could result in improved performance. It's best for me to consider the VESC's implementation substantially correct, and if there are bugs they will be found and fixed.
I would say the flux linkage value is not an integral part of the FOC algorithm. It is only used in the observer which estimates the rotor position, when you use an encoder you can totally do without.
About the psi or lambda, I see both used for flux linkage. Why would you want to pick psi over lambda? Also, your your statement that "lambda is the summation of the flux phi over the number of turns" actually points to lambda being the correct symbol, since we look at the whole coil, not an individual loop.
Some tweaking of the parameters might improve performance, since detection is not perfect but also the motor parameters can change depending on many factors (e.g. magnetic saturation, heating of coils, heating of magnets, ...).
I take your point about the Observer being separate from the FOC algorithm. I changed post #57 to reflect that.
I think psi is more appropriate than lambda because that's what's Ortega et al called it in the paper I assumed the VESC's Observer algorithm is based on. But I may be missing something.
And perhaps I should have said, it now seems unthinkable that any tweaks I could make in those parameters would result in improved performance.
Thank you for the explanation. My opinion is that having it in line with the duty cycle would be simpler to understand. But I also see what you are saying and its also 100% valid. Think it's best to keep things they are now, as this is working good.
Would you be interested in implementing the FRF measurement functionality? If you want, I can make a topic with some explanation and some pieces of code to make this functionality. With this, you can measure the full frequency response of for example the current loops. Also, you can see the margins and delays in the control loops. I think that with my input it should not be that much work to make the functionality, but the part that is not fully clear to me is the communication possibilities of the VESC. You need to buffer 2047 samples with the code I have. Is this possible?
That would be very interesting. Buffering 2047 samples of all measured values is no problem, it is already how the sampled data plot works. If you start a thread about it we can work on that.
Here you go: https://vesc-project.com/node/3257.
A search of this forum for "flux linkage" brought me here. This is my first post and I must say the competence, professionalism and civility of this thread is truly impressive!
I am new to motor control and would like to understand how the flux linkage (lambda) parameter affects motor performance. I started by reading Viktor Bobek's AN4680. (The URL above is broken, but I was able to find it by Googling.)
This also lead me to wonder about VESC Tool's determination of motor resistance and inductance. How does it know if the coils are wired as a wye or a delta? Or does it not matter in the end?
The Help screen for motor resistance says, "The motor winding resistance should be half of what is measured between two motor wires." So, it must be assuming a wye connection. However in the case of a delta connection, the measured resistance (and/or inductance) would be 2/3 that of an individual phase winding.
I ask this partly because I am trying to reconcile several sources of information (manufacturer's data, my measurement, VESC Tool's determination) regarding motor inductance and resistance.
I started a new topic about my specific motor here: https://vesc-project.com/node/3376.
TIA
Also, a minor point, from my reading the units for lambda are weber-turns (not just webers as VESC Tool 3.0 indicates).
Nice compliment, thanks. Must say I also like your contibution.
Delta vs wye only matters if you want to compare to datasheet values. Indeed, if you have a delta wired motor, you need to convert the measured resistance and inductance values to delta configuration values.
About the Weber-turns, yes you can call it that, but in my opinion it is better to just stay with the SI label, which is just Weber.
I don't mean to be argumentative but wanted to share what I've learned in the past few weeks. My initial interest in this topic was to understand what affect lambda has on performance. Well, it's integral to the
FOCObserver algorithm! But now I'm wondering if lambda is really the right thing to call the parameter?The first source I referenced regarding lambda was Chapman's Electric Machinery Fundamentals. That's where I got the idea the units should be weber-turns. That textbook says lambda is the summation of the flux phi over the number of turns. Many internet sources seem to corroborate this. Here is the simplest and most complete explanation I found: https://lambdageeks.com/magnetic-flux-vs-magnetic-flux-linkage/
But, I also see that "flux linking", "flux linkage" and "flux" are all described using psi in the MathWorks PMSM Help https://www.mathworks.com/help/physmod/sps/ref/pmsm.html Elwin mentioned in post #2. (Which has been really useful.)
Most importantly, Ortega et al's observer algorithm (referenced in the VESC's Help for Observer Type) uses psi for flux linkage.
Bottom line, the determination of R, L and lambda (or psi as I would prefer to call it) are integral to the proper operation of the Observe. It now seems unthinkable to me that tweaking any of these parameters could result in improved performance. It's best for me to consider the VESC's implementation substantially correct, and if there are bugs they will be found and fixed.
I would say the flux linkage value is not an integral part of the FOC algorithm. It is only used in the observer which estimates the rotor position, when you use an encoder you can totally do without.
About the psi or lambda, I see both used for flux linkage. Why would you want to pick psi over lambda? Also, your your statement that "lambda is the summation of the flux phi over the number of turns" actually points to lambda being the correct symbol, since we look at the whole coil, not an individual loop.
Some tweaking of the parameters might improve performance, since detection is not perfect but also the motor parameters can change depending on many factors (e.g. magnetic saturation, heating of coils, heating of magnets, ...).
I take your point about the Observer being separate from the FOC algorithm. I changed post #57 to reflect that.
I think psi is more appropriate than lambda because that's what's Ortega et al called it in the paper I assumed the VESC's Observer algorithm is based on. But I may be missing something.
And perhaps I should have said, it now seems unthinkable that any tweaks I could make in those parameters would result in improved performance.
Would you like to join the (unofficial) Vesc Discord? I think you'll like it, there is a ton of good discussions going on there.
Pages