MBL1650 drag torque in torque mode at !M 0?

Hi,

I am trying to get my drive based on a MBL1650 and a Hall-equipped RC-Motor running but experience unexpected behavior.

First observation: when turning the controller on, the drag torque from the motor significantly increases, indicating connected phases?

Second observation: in torque mode at !M 0 I would have expected a free running motor, but there is still drag caused by the controller.

The application requires a free running motor (coasting with minimum drag, when zero torque requested).

How can I achieve that with the MBL1650?

Kind regards,
Stephan

When the motor command is 0, the motor wires are shorted.

If you need coasting, you could put the MOSFETs in the \"all off\" state, but this is not a good solution because it means you will have no drag at 0, but you will then have drag as soon as it is different than 0, because the MOSFETs will engage again at that time.

The most proper way to do this is to implement an active method as described in the active regenetion article here

dev.roboteq.com/dev1/how-to/controlled-r...l-time-speed-sensing

It may look a little complicated but the results are excellent.

Thanks, I already read the article.
I was wondering, why the power is set using the G command (position or speed) instead of torque M?
Am I right, assuming that the motor can freely increase speed (due to external torque) when run in torque mode?
And, for the example in the regeneration article: is it possible to read a user variable from RS232 to be used as ThrottleCommand?

Another issue: I found somewhere in the forum, that (negative) current is not measured during regeneration. What is best practice to protect the battery from high currents during regeneration? Do I have to add external current sensing or will there be a software update to provide measured currents during regeneration?

M is an old command that was used to control the command level for 2 motors. Syntax !M nn mm, where nn is the command level for motor 1 and mm for motor 2

Since this is the only command that operates that way, it has been retired and it is now necessary to use the !G instead, once for each channel. !M still works but it should not be used.

Torque mode is not working when the power level is 0 because at that moment, the motor is shorted by the mosfets. Since the controller has sensor on the battery lead, no current is mesured at that point. This is why we recommend you use the method described in the article.

Negative current is measured. It just no limited. Using microbasic scripting, you could use this information to alter the controller\'s operation.

Thanks for your clarifying reply.
I assumed regenerative current is not measured, since current was always 0 when decelerating the motor quickly without load. Maybe the motors inertia is to low, to produce a regenerative current above the measurement resolution.
There is one remaining question for the moment: you wrote \"you could put the MOSFETs in the \"all off\" state\", but I could not find a corresponding command. How do I do that (via RS232 or micro basic command)?
And: are user variables assigned via RS232 by the !VAR command persistent in the script loop? More precise: can I update a user variable via RS232 i. e. each 100 ms and use it in the scrips loop i. e. each 10 ms?

roboteq wrote:

If you need coasting, you could put the MOSFETs in the \"all off\" state

Can anybody tell how to do this by a RS232 command? I did not find any appropriate command in the documentation to switch of all FETs.

To refresh this thread, again the still open question: how to turn off all FETs by RS232 command?
And another question comes up regarding the application note regarding regeneration. It suggests to figure out the speed at a given power request and to use this for coasting.
In Battery powered applications, speed at a given power request probably depends on battery voltage.
Are there any experience, if the described method works well, even if the battery voltage varies from full to almost discharged?

Use the E-stop command or function using a digital input switch, or as an action taken on one of your inputs. This will turn off all fets and will provide a coasting to a stop on the motor(s).

I tested the MicroBasic example with different battery voltages yesterday and got the expected behaviour.
Configuring the proper RPM and power command in no load condition results in reasonable "freewheeling". Charging the battery to a higher voltage results in acceleration when using the same parameter.
Using the method described in the example would require to make the parameters adaptive to battery voltage. That would increase the effort, since measurements for command-rpm in no load condition had to be performed for different battery charging states.
I tried to use !G BS * CONST but this suffers the same effect, if the relation between RPM and !G depends on the battery voltage, which seems to be the case even in closed loop speed control!
Any ideas, how to handle this?