Open Loop Mode Coasting
7 years 9 months ago - 7 years 9 months ago #29531186
by Ryan
Open Loop Mode Coasting was created by Ryan
Hi,
we've recently switched to sbl1360 controllers and are amazed about how good and powerful they accelerate even under high load.
But we've got one big problem. In our situation the motor is directly attached to a 5 kilogram flywheel. The controller is attached to a 42v 20a power supply. So far accelerating is no problem at all, but we want it to slow down at it's natural speed.
We've already killed one controller by accident by letting it accelerate and then set motor command to zero because it's trying to brake the flywheel.
We really want to use open loop mode, because controlling of speed and power is done by our hardware which gives the power signal to the controller. But we don't want the controller to brake down the wheel because we have also a eddy current brake attached to it and the regeneration current isn't good for the power supply and sometimes causes over voltage in our system.
I've found this Article and derviated the following script for our use case:
What we want to do basically is to accelerate the wheel using maximum power possible and if command gets lower than current neutral power coast to that power.
The problem here is, that the script needs to get fine tuned for every our devices to have a realistically slow down behavior. If RPMat50pct doesn't match perfectly, the wheel slows down too fast, takes far to long to slow down or will even run away if neutral power gets too high.
So I've developed another script, which turns off the fets if neutral power is far too high, so it'll give us perfect coasting (theoretically), turns on the fets when it get's closer to the command and using neutral power get near to the command so it doesn't turn on and off the fets continuously.
The problem with this attempt was that the controller didn't like turning on the fets while the wheel is spinning and got killed. I already told my colleauge that i want to have mechanical solution for free-wheeling but he doesn't want to implement it with the following reason: "If a $15 controller from china can do that (KU63 ebike controller) then this controller will do that, too!" And I have to admit that he is right about that.
We've also tried torque mode, but that won't allow us to control speed that directly. With speed mode it's the other way around. Open loop mode behaves perfectly exempt from not allowing us to coast.
So can you give me a hint how I can realize realistic, non-regenerative coasting in open loop mode without modifying a script each time? I think all I need to do is turning off the fets instead of active braking. How can I realize that?
We're also very interested in how to get rid of that regeneration problem. The chinese controller doesn't do that.
I've also read your understanding regeneration article, but it doesn't really help. All it basically says is "use a battery". But what happens if the battery is full?
We're using a switching Power supply. About that it says
Thank you!
we've recently switched to sbl1360 controllers and are amazed about how good and powerful they accelerate even under high load.
But we've got one big problem. In our situation the motor is directly attached to a 5 kilogram flywheel. The controller is attached to a 42v 20a power supply. So far accelerating is no problem at all, but we want it to slow down at it's natural speed.
We've already killed one controller by accident by letting it accelerate and then set motor command to zero because it's trying to brake the flywheel.
We really want to use open loop mode, because controlling of speed and power is done by our hardware which gives the power signal to the controller. But we don't want the controller to brake down the wheel because we have also a eddy current brake attached to it and the regeneration current isn't good for the power supply and sometimes causes over voltage in our system.
I've found this Article and derviated the following script for our use case:
option explicit
dim RPMat50pct as integer ' Measured RPM at 50% power level during bench test
dim MeasuredSpeed as integer ' Measured MeasuredSpeed
dim NeutralPower as integer ' Level so the motor neither accel or decelerates
dim AppliedPower as integer ' Power that will be applied to the motor
dim ThrottleCommand as integer ' User command
' Change these constant to meet your requirements
RPMat50pct = 3690 ' Measured RPM at 50% power level and no load
top:
' ' Read user command from Analog Joystick on in 5
ThrottleCommand = getValue(_CIA,1)
' Uncomment on of the two following lines depending on motor type and sensor
MeasuredSpeed = getvalue(_BS, 1) ' Measure current speed using Hall sensor
'MeasuredSpeed = getvalue(_S, 1) ' Measure current speed using Encoder
' Compute Power Level needed to maintain current speed
NeutralPower = ((MeasuredSpeed * 500) / RPMat50pct)
if (NeutralPower < 0)
NeutralPower = 0
end if
if (NeutralPower > ThrottleCommand)
AppliedPower = NeutralPower ' coasting
else
AppliedPower = ThrottleCommand ' accelerating
end if
' Only allow positive commands and cap to +1000
if (AppliedPower < 0)
AppliedPower = 0
elseif (AppliedPower > 1000)
AppliedPower = 1000
end if
setcommand(_G, 1, AppliedPower) ' Apply power to the motor
'setcommand(_G, 1, 500) ' calibration power
' Optional log printed on the console for monitoring or debug
print("C= ", ThrottleCommand,"\tS= ",MeasuredSpeed)
print("\tN= ", NeutralPower,"\tP= ", AppliedPower,"\r")
wait(10) ' Wait 10ms
goto top ' Repeat loop foreverWhat we want to do basically is to accelerate the wheel using maximum power possible and if command gets lower than current neutral power coast to that power.
The problem here is, that the script needs to get fine tuned for every our devices to have a realistically slow down behavior. If RPMat50pct doesn't match perfectly, the wheel slows down too fast, takes far to long to slow down or will even run away if neutral power gets too high.
So I've developed another script, which turns off the fets if neutral power is far too high, so it'll give us perfect coasting (theoretically), turns on the fets when it get's closer to the command and using neutral power get near to the command so it doesn't turn on and off the fets continuously.
option explicit
dim RPMat50pct as integer ' Measured RPM at 50% power level during bench test
dim MeasuredSpeed as integer ' Measured MeasuredSpeed
dim NeutralPower as integer ' Level so the motor neither accel or decelerates
dim AppliedPower as integer ' Power that will be applied to the motor
dim ThrottleCommand as integer ' User command
dim ManualCoasting as integer ' Difference to Throttle command for manual coasting
dim FetsOff as boolean
dim FetsOffOld as boolean
' Change these constant to meet your requirements
RPMat50pct = 3690 ' Measured RPM at 50% power level and no load
ManualCoasting = 200
' initializing
setCommand(_ESTOP,0) ' fets off
FetsOff = true
FetsOffOld = true
top:
' ' Read user command from Analog Joystick on in 5
ThrottleCommand = getValue(_CIA,1)
' Uncomment on of the two following lines depending on motor type and sensor
MeasuredSpeed = getvalue(_BS, 1) ' Measure current speed using Hall sensor
'MeasuredSpeed = getvalue(_S, 1) ' Measure current speed using Encoder
' Compute Power Level needed to maintain current speed
NeutralPower = ((MeasuredSpeed * 500) / RPMat50pct)
if (NeutralPower < 0)
NeutralPower = 0
end if
AppliedPower = NeutralPower
if (NeutralPower > (ThrottleCommand + ManualCoasting))
' coasting far over ThrottleCommand
'print("Off")
FetsOff = true
elseif ((NeutralPower < ThrottleCommand + ManualCoasting/2) and NeutralPower > ThrottleCommand)
' manual coasting near over ThrottleCommand
'print("On1")
FetsOff = false
elseif (NeutralPower < ThrottleCommand)
'print("On2")
FetsOff = false
AppliedPower = ThrottleCommand ' accelerating
end if
' Only allow positive commands and cap to +1000
if (AppliedPower < 0)
AppliedPower = 0
elseif (AppliedPower > 1000)
AppliedPower = 1000
end if
if (ThrottleCommand < 2)
FetsOff = True ' Always turn Fets off if no command is given
end if
setcommand(_G, 1, AppliedPower) ' Apply power to the motor
if (FetsOff and (not FetsOffOld))
setCommand(_ESTOP,0) ' turn fets off
setcommand(_G, 1, AppliedPower) ' Apply power to the motor
FetsOffOld = true
'print("Fets OFF\r")
elseif ((not FetsOff) and FetsOffOld)
setCommand(_MGO,0) ' turn fets on
setcommand(_G, 1, AppliedPower) ' Apply power to the motor
FetsOffOld = false
'print("Fets ON\r")
end if
'setcommand(_G, 1, 500) ' calibration power
' Optional log printed on the console for monitoring or debug
print("C= ", ThrottleCommand,"\tS= ",MeasuredSpeed,"\tF= ", FetsOff)
print("\tN= ", NeutralPower,"\tP= ", AppliedPower,"\r")
wait(10) ' Wait 10ms
goto top ' Repeat loop foreverThe problem with this attempt was that the controller didn't like turning on the fets while the wheel is spinning and got killed. I already told my colleauge that i want to have mechanical solution for free-wheeling but he doesn't want to implement it with the following reason: "If a $15 controller from china can do that (KU63 ebike controller) then this controller will do that, too!" And I have to admit that he is right about that.
We've also tried torque mode, but that won't allow us to control speed that directly. With speed mode it's the other way around. Open loop mode behaves perfectly exempt from not allowing us to coast.
So can you give me a hint how I can realize realistic, non-regenerative coasting in open loop mode without modifying a script each time? I think all I need to do is turning off the fets instead of active braking. How can I realize that?
We're also very interested in how to get rid of that regeneration problem. The chinese controller doesn't do that.
I've also read your understanding regeneration article, but it doesn't really help. All it basically says is "use a battery". But what happens if the battery is full?
We're using a switching Power supply. About that it says
Can you point out, which literature is meant?A switching power supply in general is not suitable. Consult the Roboteq literature on this subject.
Thank you!
Please Log in or Create an account to join the conversation.
- roboteq
7 years 9 months ago #29531187
by roboteq
Replied by roboteq on topic Open Loop Mode Coasting
Freewheeling can easily be done by turning the fets off, like you did.
Turning back on at the wrong time will cause regeneration and if no battery is present, voltage can rise at dangerous levels. If a battery is present, voltage will not rise.
It is not certain that an ebike controller will behave very differently if connected to a powwer supply instead of a battery.
Make sure that you set the overvoltage limit only 1-2V above your power supply voltage. This will provide some protection.
The first algorithm is the preferred approach. In your case you could look for regeneration and move the PWM up to lower it. You can see that regeneration occurs by looking at the battery current, and/or the battery voltage. A negative battery current means regen. A voltage above your power supply also means regeneration. Regen overvoltage can happen quite fast, so this may be tricky to achieve.
Turning back on at the wrong time will cause regeneration and if no battery is present, voltage can rise at dangerous levels. If a battery is present, voltage will not rise.
It is not certain that an ebike controller will behave very differently if connected to a powwer supply instead of a battery.
Make sure that you set the overvoltage limit only 1-2V above your power supply voltage. This will provide some protection.
The first algorithm is the preferred approach. In your case you could look for regeneration and move the PWM up to lower it. You can see that regeneration occurs by looking at the battery current, and/or the battery voltage. A negative battery current means regen. A voltage above your power supply also means regeneration. Regen overvoltage can happen quite fast, so this may be tricky to achieve.
Please Log in or Create an account to join the conversation.
Moderators: tonysantoni
Time to create page: 0.055 seconds
