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

7 years 9 months ago #29531203 by elektrinis
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.

Please Log in or Create an account to join the conversation.

7 years 9 months ago #29531205 by TechSupport
If you want free wheeling, then use the !EX function instead. To release from that, use !MG.

With a brushless motor controller, if the motor command is not at 0 prior to release or at a low enough motor command, it will go into a stall condition. In that case, bring the command back to 0 to get it to clear the stall condition.

Please Log in or Create an account to join the conversation.

7 years 8 months ago #29531336 by elektrinis

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?

Please Log in or Create an account to join the conversation.

7 years 8 months ago #29531337 by TechSupport
No sample code to provide. Emergency stop turns off the fets, so if the motors stop quickly it is due to the load causing it to stop quickly; nothing we can do about that.

E-stop is disengaged when !MG is sent.

If the motor shorts as a result of this, you would need to look at what the command was prior, and how much the motor power is saying it has. If the motor power is still above or below 0 and you release, then the fets turn back on and will get a bit screwed up by the fact that the motor power was trying to get to 0 and then being sent the command to go back up really quickly.

Please Log in or Create an account to join the conversation.

7 years 8 months ago #29531338 by elektrinis
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.

Please Log in or Create an account to join the conversation.

7 years 8 months ago #29531339 by TechSupport
That is because it is re-engaging the fets. This isn't a bug. The controller uses progressive regenerative braking that is applied upon a command change if braking or going the other direction. This cannot be changed.

You're also on a brushless motor. The movement occurs with the hall and UVW wiring phases changes. So it first looks at the condition of the halls and then sends the phases transitions to get it to move again. It's probably that when you re-engage the fets, the phase transitions have to be reassessed which is what causes the motor to jerk. It isn't limited to the torque mode; it will happen on the other closed loop modes.

The torque mode runs on the I gain. The speed in which it reacts is based on your speed and acceleration parameters. Max speed rpms/acceleration.

Default is 1000 and 2000/ Therefore the change over in command is 500mS.

Please Log in or Create an account to join the conversation.

7 years 8 months ago #29531340 by elektrinis
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?

Please Log in or Create an account to join the conversation.

7 years 8 months ago #29531341 by TechSupport
The 120A max is only meant for 30 seconds to 1 minute at most. If it is being drawn for longer than that, it would explain why the blades are melting. It could also possibly mean that the connection between the blade and your connector are not secured, causing the current to draw higher and thus melt the blade. If connections are not tightly secured, then the loose connection will cause the connectors to melt.

120A max and continuous 60A. This means that the 120A max purpose is to get the motors moving from start up and once the motor is moving it winds its' way back down to 80A or less continuous.

So in your case for torque mode, the 120A or 100A continuous is the issue.

Understandable adding another blade terminal to each output pin would reduce the load on each blade, but that would induce a redesign. In this case the FBL2360S would be the controller best fit for that or one of the GBL1xxx controllers. Again if your connections are not secured, the same problem could occur even with these controllers.

Please Log in or Create an account to join the conversation.

7 years 8 months ago #29531343 by roboteq
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

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.

Please Log in or Create an account to join the conversation.

7 years 8 months ago #29531344 by roboteq
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.

Please Log in or Create an account to join the conversation.

Moderators: tonysantoni
Time to create page: 0.094 seconds