Should I worry about this?
Page 8, 3.2.1 - http://www.st.com/content/ccc/resource/technical/document/release_note/b1/3f/4e/1b/cc/7f/45/c1/DM00068242.pdf/files/DM00068242.pdf/jcr:content/translations/en.DM00068242.pdf
- does your encoder provide an I channel?
- you mentioned that it is magnetic and has Hall sensor emulation outputs, can you give more information on it?
- can the encoder measure the absolute rotor angle?
- do you need to be able to rev up the motor under load?
- after rev up, do you need to be able to provide torque at standstill?
The FOC algorithm interpolates the Hall sensors while the motor is turning, so there will be no degradation. But you have a 10-20% torque loss at very slow velocity (probably far slower than the numbers that you mentioned) and standstill. If that is not a problem in your application, then you'd be fine. And your possible encoder software/microcontroller limitation from your last post would become unimportant (I vaguely remember that I needed to sacrifice a GPIO for that, can check this evening).
Just one short remark on that: to know if your encoder is interpreted correctly, use the DAC feature to route the encoder output to one of the two DAC outputs (can be done statically in STMCWB), attach a scope, and turn the motor by hand. See if you get that expected triangle signal or not
Just one short remark on that: to know if your encoder is interpreted correctly, use the DAC feature to route the encoder output to one of the two DAC outputs (can be done statically in STMCWB), attach a scope, and turn the motor by hand. See if you get that expected triangle signal or not
I do not see anything in scope.
I've tried several variables for the DAC, but the output is always static.
- does your encoder provide an I channel?
- you mentioned that it is magnetic and has Hall sensor emulation outputs, can you give more information on it?
- can the encoder measure the absolute rotor angle?Yes it has an incremental output (I channel).
The encoder is this (PDF downloads automatically): https://ams.com/kor/content/download/725051/1853902/file/AS5047P_DS000324_2-00.pdf
It also gives absolute rotor angle.
Can be a problem with eval board configuration code, maybe it is overridden there. Check which eval board #define you have in the project settings. Check if there are any eval modules linked in, better to remove them.
EDIT: it may also be necessary to enable RS232 comms, not sure. The function "UI_TaskInit" does the AOUT initialization.
As you need torque at standstill, I would definitely go for hall sensor emulation, that is the only absolute angle feedback you get from that sensor (apart from SPI). You neither need sensorless revup, nor encoder feedback anymore then. Just use hall as single primary feedback. You can still add encoder for high precision control at very low velocity / standstill as secondary sensor, but I assume that your gearbox will equal out remaining motor cogging.
Can be a problem with eval board configuration code, maybe it is overridden there. Check which eval board #define you have in the project settings. Check if there are any eval modules linked in, better to remove them.
EDIT: it may also be necessary to enable RS232 comms, not sure. The function "UI_TaskInit" does the AOUT initialization.
My project is set up for the EVB I am using - P-NUCLEO-IHM001_SINGLEDRIVE
In the "UI_TaskInit" file the DAC is enabled.
I am using serial communication to use STMCW...
As you need torque at standstill, I would definitely go for hall sensor emulation, that is the only absolute angle feedback you get from that sensor (apart from SPI). You neither need sensorless revup, nor encoder feedback anymore then. Just use hall as single primary feedback. You can still add encoder for high precision control at very low velocity / standstill as secondary sensor, but I assume that your gearbox will equal out remaining motor cogging.OK friend.
I'm going to do just one more test and switch to hall sensor emulation. But the sensor and magnet in the rotor not need to be aligned?
After some adjustments the encoder is operating on the main controller.
The controller energize the motor to align the encoder and starts running from there. If I understood correctly ...
After some tuning it works.
But I still can not control the speed at low speed. The motor runs out of torque ...
How can I fine tune the torque?
Can be a problem with eval board configuration code, maybe it is overridden there. Check which eval board #define you have in the project settings. Check if there are any eval modules linked in, better to remove them.
EDIT: it may also be necessary to enable RS232 comms, not sure. The function "UI_TaskInit" does the AOUT initialization.
My project is set up for the EVB I am using - P-NUCLEO-IHM001_SINGLEDRIVE
In the "UI_TaskInit" file the DAC is enabled.
I am using serial communication to use STMCW...Hmmm, hard to say without having the hardware on my table. The AOUT feature worked without hassles right from the beginning for me and was of great help, but I remember having removed all the eval board stuff in the very beginning, because I was using my custom board right from the start. The NUCLEO board is supposed to deliver the analog signal at X2 / pin 3 ("A2"). I hope you didn't probe at pin 5 "A4".
If the motor runs out of torque, then there still is a problem with configuration. FOC basically works as two nested PI control loops:
- the outer loop controls velocity and calculates a torque value: set_torque = PI ( set_velocity, current_velocity )
- the inner loop controls torque and calculates motor set_voltage: voltage = PI ( set_torque, current_torque )
For a PMSM, motor torque is proportional to phase current (magnitude of 3-phase current vector), so you can replace torque by current in the above.
The set_torque resp. set_current value is limited by the rated motor current that you provide.
You can see that you'll get full torque in all situations, also in standstill. This makes FOC ideal for servo applications like yours. I have made a 25kW servo using this, and I have it made playing music by controlling velocity setpoint for fun. I had to make sure it is tightly bolted to the table, or it would jump off just from rotor inertia. It was amazing, you couldn't even *hear* it accelerating or decelerating.
I do not have to calibrate the values of Iq and Id PID's?
Basically in torque control mode I have parameters that I don't understand what they mean. For example Torque Ref and Flux Ref ...
For some reason, I can only use integers.
There is something very wrong!
I unplugged the encoder cables and did "start_motor" and the motor started .
Another thing that may important. You can adjust the current controller's update rate in multiples of PWM cycles. Don't make it too slow, or the controller may become instable. If your motor inductance is low, then you need a fast current controller. I suggest to set (Drive Management -> Drive Settings -> Torque&flux regulators -> Execution rate) to get an update rate of > 5kHz to stay on the safe side.
Basically in torque control mode I have parameters that I don't understand what they mean. For example Torque Ref and Flux Ref ...Torque ref / Iq is the current setpoint value for the current PI controller that I am talking about. That is the current that you want to flow through the phases. The other value, Flux ref / Id, is always zero in a servo application. I made some explanations on this in another thread: https://www.eevblog.com/forum/chat/regulating-speedtorque-of-induction-motor-methods/?all
For some reason, I can only use integers.Probably a bug, but maybe they forgot the conversion between float[amps] and their internal fixpoint integer values. What happens when you set 1? If the motor spins, then it is Amperes. If not, try larger numbers up to +-32767.
There is something very wrong!
I unplugged the encoder cables and did "start_motor" and the motor started .It starts sensorless, and tries to switch over to encoder, but only if it is present. The library always monitors the validity of its connected speed sensors. If you disconnect the cable, it will stay in sensorless mode.
Am I doing something wrong?
One question: in the last image I do encoder align and then start motor, but the motor does not rotate. Was not this the right procedure?
I'm starting to walk in circles ...
I'm not making progress.
In this link is the SDK configuration file.
https://meocloud.pt/link/ba2e6d66-9d51-4cac-80eb-46542dcb6d27/ro_mot.rar/
Cant't find a single wrong bit here. That is exactly the right way to measure the phase reference between rotor and encoder. What does the motor do when you start the adjustment? It should forcedly snap into a certain rotor position.
- the encoder angular resolution matches the reality, in your case 512 (I see that the encoder chip is programmable)
- the motor pole pair count is correct. If you are unsure about that, you can use a lab supply and push some current through two phases, and turn the motor by hand by exactly one mechanical revolution. The number of 'snaps' is the number of pole pairs.
If one or the other is wrong, the motor will lock into a certain angle and become a heater.
Checked the file and have a few questions.
- you have enabled motor temperature sensing, are you sure that this is not triggering? Maybe temporarily disable it, maybe also disable bus voltage monitoring and over-current protection to be on the safe side
- I saw the nucleo power board can be configured to one-shunt and 3-shunt, is that set to 3-shunt?
- 15kHz current loop update rate is quite high, don't know if the CPU can handle that. Maybe try :4 ratio from PWM instead of :2
- you have enabled current feed forward ("Additional Features and PFC settings"). Possible instability if motor parameters are not perfect, suggest to disable that temporarily
- the motor pole pair count is correct. If you are unsure about that, you can use a lab supply and push some current through two phases, and turn the motor by hand by exactly one mechanical revolution. The number of 'snaps' is the number of pole pairs.
If one or the other is wrong, the motor will lock into a certain angle and become a heater.I think the motor has 3 pairs of poles, but the seller says it has 4 poles, 2 pairs.
Tomorrow I will do this test to verify. Thank you!
Cant't find a single wrong bit here. That is exactly the right way to measure the phase reference between rotor and encoder. What does the motor do when you start the adjustment? It should forcedly snap into a certain rotor position.Apparently nothing.
I was hoping the current of my power supply would increase. But that does not happen.
I do not understand, if everything is set up to work with the encoder (and this sensor is the only feedback), why can I remove the wires and it will continue to work fine.
The encoder reading is certainly not being activated.
#if ((defined NO_SPEED_SENSORS)||(defined ENCODER)||(defined VIEW_ENCODER_FEEDBACK))
CSPD oVSS_M1; /* only if M1 is sensorless*/
#endif