Nucular Electronics owner's thread (setup infos, FW updates, links etc.)
- Thread starter madin88
- Start date
DanGT86
100 kW
Does anyone have a firm understanding of the PID terms? I have been watching generic youtube vids on PID control in an effort to better understand the theory but if anyone can relate it to the process of tuning in a motor setup it would be most helpful.
From what I understand the Kp terms are basically how drastically the controller can react in an effort hit a certain target. The Ki terms are how quickly the Kp term should be reduced as it approaches that target to prevent overshoot.
So they are basically "Gain" settings? If they react too slow then limits will be overshot. If they react too quickly then you get oscillations and stutter because they overshoot. If they are set absurdly low than they can become slower than the desired ramp up you are desiring?
Does this sound correct to you electronics experts out there?
Is the DCi PID the "gain" settings for overall current of the DC battery input? If those were way wrong would this cause overcurrent cutouts?
Are the FOC ki and FOC kp terms controlling the current regulation of the motor or do they deal with the timing of FOC?
I've been all over the place with my FOC ki and FOCkp terms. The ki seems to control the amount of time between stutter. Based on my limited understanding I'm thinking the FOC kp should effect the magnitude or harshness of the stutter.
Am I close to understanding this?
From what I understand the Kp terms are basically how drastically the controller can react in an effort hit a certain target. The Ki terms are how quickly the Kp term should be reduced as it approaches that target to prevent overshoot.
So they are basically "Gain" settings? If they react too slow then limits will be overshot. If they react too quickly then you get oscillations and stutter because they overshoot. If they are set absurdly low than they can become slower than the desired ramp up you are desiring?
Does this sound correct to you electronics experts out there?
Is the DCi PID the "gain" settings for overall current of the DC battery input? If those were way wrong would this cause overcurrent cutouts?
Are the FOC ki and FOC kp terms controlling the current regulation of the motor or do they deal with the timing of FOC?
I've been all over the place with my FOC ki and FOCkp terms. The ki seems to control the amount of time between stutter. Based on my limited understanding I'm thinking the FOC kp should effect the magnitude or harshness of the stutter.
Am I close to understanding this?
DanGT86
100 kW
He is the one that first suggested I do some research into PID control strategy. He said he has trouble explaining the "magic"
Its totally understandable that it would be beyond the realm of standard tech support from the controller manufacturer.
I just figured with all the brains on here someone would be very familiar with PID tuning. Seems to be the most common control strategy in most industries.
Its totally understandable that it would be beyond the realm of standard tech support from the controller manufacturer.
I just figured with all the brains on here someone would be very familiar with PID tuning. Seems to be the most common control strategy in most industries.
Ki is the integral gain and Kp the proportional gain
The PID makes it possible to obtain a regulation curve that is as linear as possible in anticipation of demand. This avoids on / off operation by setting a measuring range with a timed neutral zone. So instead of getting a sawtooth curve you get soft waves. How to interpret this on an Ebike controller is not easy to explain.
The PID makes it possible to obtain a regulation curve that is as linear as possible in anticipation of demand. This avoids on / off operation by setting a measuring range with a timed neutral zone. So instead of getting a sawtooth curve you get soft waves. How to interpret this on an Ebike controller is not easy to explain.
DanGT86
100 kW
Its very conceptual and its been too long since I was in school. Back then glancing at formulas gave me a general sense of what was going on. Now days that's gone.
So in my case with a small low inertial high kv motor the current and rpm can spike quickly so the stuttering behavior could possibly be remedied by lowering the proportional gain to make the error correction less overreactive? The stuttering is likely the result of the controller overcompensating?
I need to get a scope on my hall signals before anything else to rule that out so Im not chasing my tail.
Found a pretty straight forward explanation of PID on this page. There is a nice easy to follow process for tuning I think I'll try.
https://www.ni.com/en-my/innovations/white-papers/06/pid-theory-explained.html
Tuning
The process of setting the optimal gains for P, I and D to get an ideal response from a control system is called tuning. There are different methods of tuning of which the “guess and check” method and the Ziegler Nichols method will be discussed.
"The gains of a PID controller can be obtained by trial and error method. Once an engineer understands the significance of each gain parameter, this method becomes relatively easy. In this method, the I and D terms are set to zero first and the proportional gain is increased until the output of the loop oscillates. As one increases the proportional gain, the system becomes faster, but care must be taken not make the system unstable. Once P has been set to obtain a desired fast response, the integral term is increased to stop the oscillations. The integral term reduces the steady state error, but increases overshoot. Some amount of overshoot is always necessary for a fast system so that it could respond to changes immediately. The integral term is tweaked to achieve a minimal steady state error. Once the P and I have been set to get the desired fast control system with minimal steady state error, the derivative term is increased until the loop is acceptably quick to its set point. Increasing derivative term decreases overshoot and yields higher gain with stability but would cause the system to be highly sensitive to noise. Often times, engineers need to tradeoff one characteristic of a control system for another to better meet their requirements.
The Ziegler-Nichols method is another popular method of tuning a PID controller. It is very similar to the trial and error method wherein I and D are set to zero and P is increased until the loop starts to oscillate. Once oscillation starts, the critical gain Kc and the period of oscillations Pc are noted. The P, I and D are then adjusted as per the tabular column shown below.
"
So in my case with a small low inertial high kv motor the current and rpm can spike quickly so the stuttering behavior could possibly be remedied by lowering the proportional gain to make the error correction less overreactive? The stuttering is likely the result of the controller overcompensating?
I need to get a scope on my hall signals before anything else to rule that out so Im not chasing my tail.
Found a pretty straight forward explanation of PID on this page. There is a nice easy to follow process for tuning I think I'll try.
https://www.ni.com/en-my/innovations/white-papers/06/pid-theory-explained.html
Tuning
The process of setting the optimal gains for P, I and D to get an ideal response from a control system is called tuning. There are different methods of tuning of which the “guess and check” method and the Ziegler Nichols method will be discussed.
"The gains of a PID controller can be obtained by trial and error method. Once an engineer understands the significance of each gain parameter, this method becomes relatively easy. In this method, the I and D terms are set to zero first and the proportional gain is increased until the output of the loop oscillates. As one increases the proportional gain, the system becomes faster, but care must be taken not make the system unstable. Once P has been set to obtain a desired fast response, the integral term is increased to stop the oscillations. The integral term reduces the steady state error, but increases overshoot. Some amount of overshoot is always necessary for a fast system so that it could respond to changes immediately. The integral term is tweaked to achieve a minimal steady state error. Once the P and I have been set to get the desired fast control system with minimal steady state error, the derivative term is increased until the loop is acceptably quick to its set point. Increasing derivative term decreases overshoot and yields higher gain with stability but would cause the system to be highly sensitive to noise. Often times, engineers need to tradeoff one characteristic of a control system for another to better meet their requirements.
The Ziegler-Nichols method is another popular method of tuning a PID controller. It is very similar to the trial and error method wherein I and D are set to zero and P is increased until the loop starts to oscillate. Once oscillation starts, the critical gain Kc and the period of oscillations Pc are noted. The P, I and D are then adjusted as per the tabular column shown below.
"
John in CR
100 TW
DanGT86 said:
The halls are taken out of the equation at relatively low rpm, after which the controller runs sensorless, so any problems related to halls should only occur on take-off.
DanGT86
100 kW
Is that true for all modes like square and foc or just combined mode?
John in CR
100 TW
DanGT86 said:
It's definitely in FOC. I don't know why anyone would want to use any other mode, so I don't know about them.
square mode does not use hall sensors, it is made for motors without sensors. combined mode allows the motor to be used in mode with sensor, and in the event of a hall sensor failure and automatically switches to mode without hall sensor.This is the working principle of small Chinese 350w dual mode Ebike controller.
If you need to change the PID parameters for your motor to work properly, your motor is defective.If your motor works well in square mode and it works badly in Foc or Sinewave mode, your sensors are surely defective.
If you need to change the PID parameters for your motor to work properly, your motor is defective.If your motor works well in square mode and it works badly in Foc or Sinewave mode, your sensors are surely defective.
serious_sam
10 kW
I don't think that is correct. In my understanding (for Nucular controller):PITMIX said:
- "Square" mode uses halls at all speeds.
- "Sensorless" uses BEMF feedback only, and not halls.
- "Combined" uses halls for startup, and changes to sensorless (BEMF feedback) at a specified RPM.
John in CR
100 TW
serious_sam said:
What Sam said sounds right to me. Is that also the selection item where you choose FOC, and/or is the "combined" where you choose throttle (torque, speed, or combined)? I can't believe how long it's been since I changed any Nuc settings. Time doesn't just fly...It accelerates.
DanGT86
100 kW
John in CR said:
This was my understanding as well.
Obviously square mode is square commutation. But does anyone know if sensorless-mode is square or sine wave commutation?
Is FOC similar to sine wave or square wave commutation or is it its own separate thing not related.
I ask because the LMX motor I am using is commonly reported to not work well with Sine wave controllers. With the NUC it runs best so far in square mode. I'd like to eventually get all the bugs worked out of FOC mode. If FOC is sinewave based strategy then it might explain why this has been tricky.
True FOC commutation, aka flux-vector control, aka vector drive
defined here
https://endless-sphere.com/forums/viewtopic.php?t=105139
related
https://endless-sphere.com/forums/viewtopic.php?p=1561230#p1561230
Not all sinusoidal controllers are true "sinewave FOC", but just "sinusoidal commutation". Yes still better than old school "trap" trapezoidal (depends on the motor design of course).
Other techniques to measure the rotor position, like interpolating from the hall sensors, are not as accurate but cheaper to implement
True FOC requires a faster CPU, in itself doesn't cost much these days, but needs more engineering and support tuning to the motor to properly interpret the signals.
Heavy maths involved, representing the total stator field as current space vectors
Park- and Clark- (and inverse-) transformations
so that Quadrature/Torque (Iq) current vs Flux/Direct (Id) current are controlled directly,
in order to as perfectly as possible
keep the stator current vector in orthogonal alignment (at 90 degrees) to the rotor flux.
(whoooosh!)
defined here
https://endless-sphere.com/forums/viewtopic.php?t=105139
related
https://endless-sphere.com/forums/viewtopic.php?p=1561230#p1561230
Not all sinusoidal controllers are true "sinewave FOC", but just "sinusoidal commutation". Yes still better than old school "trap" trapezoidal (depends on the motor design of course).
Other techniques to measure the rotor position, like interpolating from the hall sensors, are not as accurate but cheaper to implement
True FOC requires a faster CPU, in itself doesn't cost much these days, but needs more engineering and support tuning to the motor to properly interpret the signals.
Heavy maths involved, representing the total stator field as current space vectors
Park- and Clark- (and inverse-) transformations
so that Quadrature/Torque (Iq) current vs Flux/Direct (Id) current are controlled directly,
in order to as perfectly as possible
keep the stator current vector in orthogonal alignment (at 90 degrees) to the rotor flux.
(whoooosh!)
serious_sam
10 kW
FOC is smoother and more efficient, but square/trap can potentially output higher peak torque/power for a given set of MOSFETs. So if you were going for outright performance, potentially square/trap is the way to go.John in CR said:
DanGT86
100 kW
My brief experience with this Nuc 6fet supports that assertion.
Square feels lightly more powerful and trips the overload where FOC does not.
I know amps in are not directly proportional to power out so I'd really need a dyno to confirm but it sure does feel more powerful in square mode.
Square feels lightly more powerful and trips the overload where FOC does not.
I know amps in are not directly proportional to power out so I'd really need a dyno to confirm but it sure does feel more powerful in square mode.
serious_sam
10 kW
Square mode has a sharper change in current, so it's possible that you get more overshoot which might trip a cutout.DanGT86 said:
DanGT86
100 kW
That is exactly what I was suspecting. Is that because the controller is applying current as if the rotor position were discrete ticks of a clock rather than smoothly ramping the current up as the rotor transitions between windings?
Or is it just because a square wave has a super steep almost vertical ramp?
Makes sense that in the real world a rotor is in continuous motion so FOC and sine wave would be more efficient than a hard on/off square wave.
Or is it just because a square wave has a super steep almost vertical ramp?
Makes sense that in the real world a rotor is in continuous motion so FOC and sine wave would be more efficient than a hard on/off square wave.
John in CR
100 TW
serious_sam said:
For outright performance unless it's just a drag race you have to take heat into account, and the Nuc's FOC has a meaningful efficiency advantage, so you'll end up with less performance potential for riding anything other than very short distances by not using FOC. When I do another build for outright performance, I'll power one of my remaining HubMonsters with dual 24F's.
What we need to do (assuming no additional hardware is needed in the controller) is get Vasily to have regen accomplished using SOC (Stator Oriented Control) as Lebowski suggests is more efficient for braking. The difference must be significant as the other day I did a short ride with only one controller on, and while acceleration was normal, quiet and smooth just less torque, regen braking was unusable and at all braking speeds sounded like the growling knocking sound of startup of a cheapie hubbie with a square wave controller. Thank goodness it's quiet and smooth running both controllers. The problem must have been the result of FOC braking and the low slot/pole count of my motors or everyone would be complaining.
Hi !
After little over a year of use (and 1.7k km) whitout any troubles, I decided to check on updates for this little wonder of a controller.
What's unclear to me is whether or not I should apply each and every one of the updates or if the last one is enough. In other words : are the update incremental or cumulative ?
Thanks for the input !
After little over a year of use (and 1.7k km) whitout any troubles, I decided to check on updates for this little wonder of a controller.
What's unclear to me is whether or not I should apply each and every one of the updates or if the last one is enough. In other words : are the update incremental or cumulative ?
Thanks for the input !
You can directly download the latest version, it will bring you all improvements Don't forget to update the display as well and save you config before.
You will love v07.18 with the possibility of adjusting the acceleration curve, it's great
You will love v07.18 with the possibility of adjusting the acceleration curve, it's great
. I was thinking this would be the same for the display as well, thanks for the clarification.litespeed
100 kW
My set up is a QS205 V3 3.5T motor, 20s15p 30Q pack with a 24F controller. Did auto set up, saved settings and road around for about an hour 2 days ago. Worked excellent. Disconnected the battery when I was finished. Plugged the battery in and closed the cover. Twisted the throttle and the bike shuttered & wheel turned backwards? WTF? Tried to auto tune and motor was fine, did angle correction and motor just stayed still and couldn’t be turned. Timed out! Kinda clueless as I’ve never had this happen before with any controller. Figured it might be halls even though the second set has never been used......I tried to run sensorless. Never tried sensorless on any controller and it’s sluggish. If feels like it’s never in sync. When I turned to the halls screen and rotated the wheel it went in order from 6,5,4,3,2,1,6,5,4,3,2....... any ideas?
Also the left button decided to stick and wouldn’t work. Apparently this one has a bad mold on the switch plate. I was able to bend a bit to get it to work but most probably will need to be replaced. The small lip at the top slips off the switch.
Also the left button decided to stick and wouldn’t work. Apparently this one has a bad mold on the switch plate. I was able to bend a bit to get it to work but most probably will need to be replaced. The small lip at the top slips off the switch.
Attachments
John in CR
100 TW
Litespeed,
Is it possible that you forgot to save the configuration? If you did save, are you sure the save worked? On one of my Nucs, apparently the controller memory was too full and saved settings wouldn't take. If forget now what the procedure was to erase memory and start again from scratch.
Or did you already figure out the problem and it was related to the issue affecting the button on the display?
Is it possible that you forgot to save the configuration? If you did save, are you sure the save worked? On one of my Nucs, apparently the controller memory was too full and saved settings wouldn't take. If forget now what the procedure was to erase memory and start again from scratch.
Or did you already figure out the problem and it was related to the issue affecting the button on the display?
VasiliSk
1 kW
- Joined
- Apr 10, 2014
- Messages
- 418
Square wave control is troublesome for controlling current on high rpm, because every step it starts from "0" current. And PI regulator goes crazy about that what leads to easy overshoot.
Sensorless, combined modes are square wave
FOC is true FOC
Sensorless FOC is planned sometime later. Should help with those noisy halls and not equal electrical hall position for one mechanical rotation. Some motors have this mechanical-rpm current oscillations that do overshoot too. (most of them actually, more or less)
Sensorless, combined modes are square wave
FOC is true FOC
Sensorless FOC is planned sometime later. Should help with those noisy halls and not equal electrical hall position for one mechanical rotation. Some motors have this mechanical-rpm current oscillations that do overshoot too. (most of them actually, more or less)