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

Trying to use MBL1660 in traction application.

Several different issues.
1. A throttle is connected to analog channel and motor runs OK.
However, when closed loop is selected and set to torque mode, motor is very jerky and does not spin well. Loop error detection is disabled and PID parameters are as per example. Tried to adjust the parameters, but no luck.

2. A freewheeling function is needed. When at speed, if throttle is released, a maximum braking power is applied, which is not good in this application. To achieve freewheeling, when throttle is released, a !MS command is issued. Which simply disables the power stage, as it looks. However we have noticed, that when we re-enable the motor, regardless of what motor command was set before MS command, or after, but before re-enabling, power stage would output a brief 0% PWM to the motor, stopping it immediately if high force. Looks like there is an issue with re-enabling procedure of power stage, which writes default 0 values before taking any other commands.
We have not tested this on road, because it looks like something will blow up.

Please advise.

Hello,

I just now returned to solving these issues. Torque mode is still not working.

As for !EX and !MG commands, there is a problem. It goes like this:

1. Motor spins up and while at speed, !EX is executed.
2. Power stage switches off and motor is freewheeling. Great.
3. While at speed, !MG command is issued. Motor is shorted and immediately stopped for a brief moment - THATS BAD!
4. Further !G commands spin it up again.

Situation, described in point 3 is very bad when dealing with high loads and inertia.

Please note I can not bring command back to 0 prior enabling the motor, as this causes exactly the same issue.
I was yet unable to get freewheeling without fully stopping the motor before re-enable.

Can you provide a sample code to demonstrate usable freewheeling?

Is it my English, or something else?

During this test, motor has no load, however a large moving mass is attached for high inertia.

When E-stop is engaged, motor spins freely, stops only eventually, due to friction.

Motor stops immediately when !MG is sent. It stops so quickly, that almost breaks things.
The only explanation I can come up with is a bug in !MG command, which outputs 0 motor command for a brief moment when E-stop is disengaged.
Controller is unusable in our application due to this issue.
Also please give a response about torque mode being jerky and basically not working even after endless PID tuning attempts.

Dear TechSupport.

I have designed several BLDC and PMSM controllers and do understand how and why the controller should work in one or another way. I do understand how these motors and controllers work.
My client has purchased several controllers from you and had several problems, described in my first post. They were unable to fully use these products in their application and decided to contact me for help. After many hours trying all kinds of hacks and scripts, I was unable to get functionality, that is available on all other controllers, which is very weird.

When you say it is "re-engaging" FETs, you are right, however they should be re-engaged at certain PWM, from previous motor command. However the fets are all switched on fully, effectively shorting all three phases of the motor. This is very dangerous on our 48V 120A system, because phase current climbs well above rated 120A for a brief moment and electronics could explode, mechanical parts could break, and equipment or passenger(s) could be hurt. It is that serious.

Also I want to point out that 6.3mm blade connectors are melting away at 100Amps. No idea how this controller was rated for 120 amps.
One more thing: phase current is always higher than battery current, so why make dual connectors for battery terminals, and single for phases?

We faced the issue you raise about freewheeling and reengaging PWM while working with a customer building a hybrid vehicle.

You are correct that reengaging with the wrong PWM will cause potentially serious problems. If PWM is too low, abrupt braking and strong regen will occur. Too high will cause acceleration with a jolt.

The solution we found is what you will see described in the article dev.roboteq.com/dev1/index.php/applicati...l-time-speed-sensing

As you will see, the idea is to always have the PWM engaged and adjust it, based on the measured RPM and the desired amount of braking, accelerating or freewheeling.

We found this technique to work remarkably well and result in excellent driveability.

If you know the characteristics of your motor, it is easy to figure the back EMF at a given speed, and the resulting current for a given PWM level. This will give you the ability to control torque directly without a PID.

Regarding the torque mode, pls try the latest firmware from our web site. Torque mode had some issues in earlier versions of the firmware.

Note that torque mode still has limitations since the motor current is estimated based on the measured battery current. This estimation is degraded below 20% PWM. Current is not measured at all at 0 PWM.

About the blades, your point is well taken that the doubling should be on the U V W phases. The higher current is pushing the enveloppe but that higher current is not meant to be continuous.