Closed loop is jerky, motor is stopped when drive re-enabled

Thank you roboteq, this engineer-to-engineer discussion and straight answers is what I was looking for, not the usual sales talk.
I understood the issue with near-zero PWM and current sensing right after taking it apart: there is only one channel for current measurement used. This explains why it has quite poor and jerky starting torque. Improvement would need a redesign (shunts on phases and better phase connectors), and of course it could use a STM32F303 for better cycle-by-cycle current handling.
Maybe other products have this done differently and we are just bad at picking most suitable model.

About maximum current duration. Now I see 80A continuous rating in the datasheet. We have missed that somehow when selecting the product.

I have just tried the newest firmware and was still unable to get stable closed loop operation with and without load.
We have experimented a lot with scripting-in the always-on adaptive freewheeling functionality and now it works. However it is still a pretty nasty workaround. For example, we have had a situation once, when motor overheated, magnets lost some strength and RPM/V constant increased. If such freewheeling script would have been used, it would accelerate to maximum speed on it's own, which is a safety issue as well. You need to take that in to account in the script as well, which is even more coding.
The product should have worked in torque mode right away without scripting, as advertised. A lot of expensive time was wasted for workarounds, it cost us many times more than product itself. Same goes for sinewave operation: after evaluating the software, we were lead to believe it will support sinewave operation, but turns out that no.
In our products, we do not include incomplete features in to public releases, we only sometimes include grayed-out options with tooltip to let users know what's coming up soon.

My overall opinion is that you are very strong on software side, I mean scripting capability is a huge plus and we would like this on every other product we use. But power stage drivers and hardware need improvement.

Glad to hear that you managed to make the always-on freewheeling work.

Change of magnets characterisitics will certainly be a problem. The script should also be adapted to compensate for changes in the supply voltage.

This controller has a single current sensor on the battery rail.

Our newest products, like the FBL2360 and FBL2360S are based on the STM32F303 have current sensors inline with the U and W outputs and will therefore measure the battery current. We are currently respinning the MBL1330/1660 to include the same MCU and amps sensing technique.

Sinusoidal mode works with the MBL1330/1660 but requires an incremental encoder. But we do not recommend using this mode because high current motors require also Field Oriented Control to keep the current in check. The new controllers do have FOC, in addition to sinusoidal commutation using the following rotor sense:
- Encoder (requires home search at power up)
- Hall Sensor (angle is estimated between two hall transitions)
- Hall + Encoder (no home search needed)
- Sin/Cos sensor
- SPI absolute sensor

We have similar issues in open loop speed mode. Our assembly contains a flywheel too and we only want that the assembly decelerates by itself without breaking. In my opinion the "progressive regenerative breaking" is not a feature but a bug as long as this is the standard setup and the only way to get rid of it is a complicated workaround.
Even cheapest chinese ebike controllers are able to turn off the fets by a lowered throttle signal and accelerate without a hiccup when throttle signal is increasing again. As most of the roboteq controllers the cheap controllers have only one shunt to measure the current. So i absolutely don´t understand why this should not be possible without a micro basic "coasting" script. I don´t want to coast, I wan´t to turn it off if no power is needed.

This is also a very serious safety problem in my opinion.
It begins with initial operation.
If you have to drive a mass and accelerate it for the first time and it stopps immediately you can run into serious problems.
If you test a ebike or another electric vehicle for the first time it would be the same.

Either you are damaging the mechanics or you accidently fall off your ebike or you damage electronics if you use no battery.
Micro basic scripting has to be adapted to every motor and it depends on many parameters if it works or not. If anything goes wrong the motor accelerates to maximum speed or decelerates by breaking again.

We destroyed already some SBL1360 controllers and some other electronics from first testing to setting the parameters in the coasting script.

Your suggestions to use a battery is no argument to me in times of modern battery technologie. What if the battery is fully charged and the bms is cutting of the battery? This even could happen during the regeneration.

The progressive regenerative breaking mode has to be enabled and disabled by a simple click and it has to be disabled by default.

We just discussed if we should sell the MBL1660 instead of SBL1360 for the future but if we are not able to solve this problem in the near future we have to change the supplier although the roboteq controllers apart from that are well constructed,equipped, documented and supported.

It is of course possible to add functionality to the script to self-tune for any motor or varying characteristics, but that gives one more source of potentially serious bugs. And of course work hours are expensive.

In our case, we realized this product is not something we can use due to:
1. really bad and jerky starting torque
2. really bad hardware:
2a. highly overrated connectors
2b. only one current shunt, leading to poor current control and possibly non-working closed loop torque node (even though it did not work under load and highed speeds)
2c. crashing USB (poor PCB design or coding)
2d. bad (dry) solder joints on electrolytic capacitors and no glue for vibration tolerance
3. really bad low-level hardware coding.

Third point needs some explanation, so here it is. I mean high-level application is fine and really good actually. Assembled from bits and peaces from the internet, like ST's bootloader, but overall it is good. However low-level coding, like power stage control and motor control algorithms need a lot of improvements. As I mentioned before, I have designed 3-phase motor controllers, so I do understand how and why it is so hard, and I understand that finding a firmware developer, who also is a good power electronics engineer, knows motors and their algorithms well is very hard to find. I am looking for such person to employ.
I believe the best fix here would be to use existing STM motor control library. It is not the prettiest solution, but it works.

mcguiver, ebike controllers work in 'asynchronous' mode, which is basically, for example, switching only upper fet, while lower one is always off and only the diode is conducting the current. In this mode, freewheeling is very easy, however the controller heats up a lot. To solve this issue and also to make regen possible, a synchronous switching is used. In this case, if you need it to freewheel, you have to completely switch off the power stage and later re-enable it at exactly the right state to match motor's speed. In this case what we see is powerstage coming back in wrong stage, doing some seriously wrong stuff.
The worst part is that I spent months emailing and writing it here to even try to explain this issue to the sales guy.
And what I understood now from the tech guy ('roboteq'), that this is by design and looks like no change is coming, because they are working on a new hardware to replace this one. Lucky us, who bought these now.

Anyway, my suggestion to solve this issue: make a soft-switch between synchronous and asynchronous mode. It can be current-dependent: enable synchronous only at high current or when regen is needed. That of course is not a 10-minute fix, but should solve this huge safety issue.

Hello electrinis! Thank you for your answer!

Really don´t know what to do at the moment to solve this problem.

How can powerstage coming back in wrong stage if the controller works with hallsensors? Is it due to the unknown load at this moment or are the hallsensors disabled too if the fets are switched off in emergency stop mode?

I have not bothered to check it with proper equipment, but it seems that it actually comes back on with 0% PWM duty cycle. Which means it is basically shorting all three phases together, making a very sudden breaking force and overcurrent condition, until new power stage PWM values are loaded by the script. Important to note that very likely this overcurrent is not controlled and probably is much higher than rated 120A.
To fix this, proper PWM values must be loaded before enabling the power stage.
I think this is an issue with low level coding of power stage driver: it is powered down instead of 'muting' the output, and later it goes through full re-initialization with default (0%) PWM values, instead of simple 'unmuting'. Just my guess, but fairly educated one.

Hi,

I've got the same problem here. In reply to my question whether it is okay to turn on the FETs while the wheel is spinning, 'TechSupport' answered here :

To answer the question about turning on the fets while motor is spinning in free spin is perfectly okay. Just not that it will resume whatever the command is, so there may be a small hickup while motor is under load to pick up speed. It would be like the effect of a car going 50 MPH, you put in Neutral, and hit accelerator when put back into drive. There will be a small delay and possibly a jerk that occurs when the gear gets back in action.

Yesterday, I've tried it. There is a small hiccup at lower speeds, but the hiccup gets worser (increases) when increasing speed. It looks like the controller is doing exactly what elektrinis explained. Re-initializing the PWM values.

What I think is happening after _ESTOP is, that the controller doesn't continue to observe the Hall Sensors and restarts doing that not until _MG0 command. So after you release from emergency stop, the FETs are being turned on with 0% PWM.

I also observed, that the re-initialization takes longer, the higher the speed is. Estaminated 0.2 secs for lower speeds, until estaminated 1.3 seconds for higher speeds.

Important to note that very likely this overcurrent is not controlled and probably is much higher than rated 120A.

I can confirm that. While trying that, one of our current-measuring IC's went up in flames. It's rated for 50A, 100A for less than 0.1 sec.

@Roboteq, could you create a fix, which keeps the FETs off, unless re-initialization is done?

Edit:
Further, a programming command which returns the perfect value for _G calculated by the current Hall speed would be extremely nice. That command should also work while the FETs are off, of course. Such command would allow to turn on the FETs in the right condition and thereby avoiding the hiccup.

As explained before, current sensing is not done on the motor leads. Current is measured on the battery leads, meaning that motor current estimation is degrading at low PWM. It is not measured at all when 0 PWM (motor leads are shorted). Our more recent brushless product do have motor current sense, allowing the implementation of FOC and a more effective Torque Mode.

We are not using glue on capacitors. Even in the most abusive applications like this one dev.roboteq.com/dev1/index.php/applicati...x2550-survives-abuse, we have never seen capacitors coming undone.

The faston connectors have also performed very well and have never suffered any damage in several thousands of units deployed.

The USB code comes straight from the STM32 library. We have found early on that under noisy electrical environment, it was sometimes difficult to maintain a reliable USB connection. And when a connection is lost, because of the OS recovery is practically impossible without manual intervention. Since we believe the code to be good, we concluded that USB is not dependable enough for anything other than setup and monitoring. We recommend using RS232 instead.

We also take exception on the low-level firmware being bad. The firmware is entirely our design and has been refined over years based on user feedback. With only a few exception (like the USB just mentioned), we know and understand it inside/out. And while it may have lacked some functionality, which we worked to complete, it has many many other features, like Microbasic scripting, which makes it far more capable and versatile than any other product in this price range.

Now, regarding the issue that got this thread started, when we worked on the hybrid scooter, we did try disabling the synchronous rectification. The results were not entirely satisfactory and this is where we came up with the proposed method of adjusting the PWM based on the measured RPM. We still believe that if properly tuned, this approach gives the best results.

For sure, emergency stop should not be used to temporarily float the MOSFETs. This is not the purpose of this function. A better way to float the transistors is to artificially induce an over or under voltage condition (by changing the voltage threshold configuration on the fly using scripting), but again apply the correct amount of PWM for a given RPM will produce the same effect. The difference being that transitioning to braking or accelerating will be done without jerking.

However, we are open to try other methods, like disabling synchronous rectification again.

Artificially induced under/over-voltage condition sounds interesting. How does it work? Are drivers disabled and then re-enabled when condition clears, without restarting the power stage? That is, if correct motor command is calculated and applied before clearing over-voltage condition, will it continue operation without the high current jerk? Are there other possible issues arising from this workaround?

use the script command:

setconfig(_OVL, 50) to set the overvoltage limit to 5V. Then
setconfig(_OVL, 280) to restore to 28V, for example.

During overvoltage conditions, the MOSFETs are floated but the PWM is unchanged. So this should work.

If it doesnt, let us know and we'll add a command to turn on/off the MOSFETs without affecting the PWM. This is something that has been siting in our todo list for a long time.

Note that since you know when it is safe to re-engage, we still believe that the cleanest approach is to keep PWMing but at the level you want vs the drive/regen/freewheel you need.