This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Sensored Torque control using DRV8301-69M-KIT / high resolution encoder overflow bug

Hello,

My goal is to create a torque controller that performs well at speeds close to 0 rpm using a high pole count motor and a high resolution incremental encoder. I have been working my way through the InstaSpin FOC/Motion Labs. However I started running into problems when I got to the sensored control example at Lab 12a/b. 

I checked the st_obj.vel.conv.Pos_mrev variable to see wether encoder feedback was working as expected. There I discovered that I had a possible variable overflow bug. My encoder line count is 30 000 and in the file "enc.c", that value is used in the variable "uint16_t num_enc_slots". I think that uint16 was overflowing during the "4*num_enc_slots" multiplications. So I changed the num_enc_slots type to uint32_t in enc.c and enc.h. This seemed indeed to be the issue because st_obj.vel.conv.Pos_mrev is now reporting 1.0 after one rotation as expected. 

Running lab12b now caused my motor to rotate but quite unstable. I assume this is caused by improper tuning of my speed controller. Since I don't want a speed controller anyway I left this and starting tying to modify the lab12b code to allow for direct torque control by doing the following:

Removing the following lines (from the updateGlobalVariables_motor function):
// get the iq reference from the speed controller
gMotorVars.IqRef_A = _IQmpy(STVELCTL_getTorqueReference(stObj->velCtlHandle), _IQ(USER_IQ_FULL_SCALE_CURRENT_A));

and (from the ST_runVelCtl function) removing:
// Set the Iq reference that came out of the SpinTAC Velocity Control
CTRL_setIq_ref_pu(ctrlHandle, iqReference);

And adding the following lines (taken from the Lab4 code) in the main loop:
// update the Iq reference manually
_iq iq_ref = _IQmpy(gMotorVars.IqRef_A, _IQ(1.0/USER_IQ_FULL_SCALE_CURRENT_A));
CTRL_setIq_ref_pu(ctrlHandle, iq_ref);

// update the direction
if(iq_ref < _IQ(0.0)) {
CTRL_setSpd_ref_krpm(handle, _IQ(-0.01));

} else if (iq_ref > _IQ(0.0)) {

CTRL_setSpd_ref_krpm(handle, _IQ(0.01));

}

However these modification don't seem to provide the desired result. Changing the gMotorVars.IqRef_A manually creates some torque but the commutation doesn't seem to work anymore. Therefore I have two questions: is my uint32_t num_enc_slots overflow fix correct? And how would I modify the lab12 code as to provide direct torque control instead of speed control?

Any help will be greatly appreciated! Best regards, Vleer

  • you made a mistake on this line for one thing:

    _iq iq_ref = _IQmpy(gMotorVars.IqRef_A,_IQ(1.0/USER_IQ_FULL_SCALE_CURRENT_A));

    I believe you are correct regarding uint32. That should be fine.

    We don't technically support encoder based torque control....all the encoder projects are supported by LineStream Technologies, and if the speed/position control components aren't being used then they won't support.  Looks like you are close though...

  • Ah yes, however that is a typo. It is correct in my code. (I'm working in a virtual machine so I cannot easily copy/paste my code).

    Thanks for responding to an unsupported quest though! Do you have any ideas what else could be the problem? When I change the torque from positive to negative the axis moves a little bit. To the "other side" of the magnet pole it seems. But no movement after that. 

    Since you seem to indicate that my approach generally correct, could it perhaps be an alignment issue?

  • I would suspect the initial alignment / zero-ing of mechanical to electrical angle is not being performed.
  • During the rs calibration stage I do see the rotor snapping into position. Is there any way to verify that the problem is in the alignment?
  • you can run with EST angle feedback (proj 4 or 5a) and then compare that angle to the one from the encoder.
  • are your phases hooked up correctly? was lab 12 working as a speed controller and providing torque when you load the machine?
  • My motor isn't clear about which wire is which so I tried all combinations.. didn't help. The original lab12b code is "kind of" working. After rs calibrations it turns a bit (although a bit jittery) but after a while, or after loading, it locks up or oscillates. I'll try recalibrating my user.h settings now.

  • Recalibrating (especially increasing the calibration current I think) and fixing another potentially overflowing variable has solved a lot! It is turning now and I'm happy. Thank you Chris for supporting the unsupported :)
  • HI . Would you mind sharing which "fixing another potentially overflowing variable" was that?

    I am trying to run sensored postion control. But the sensored inertia estimation lab just doesnt work. The rotor seems to align though its jittery and then when its time to start spinning the current draw rises until it hits phase over current limit and the trip zone shuts down the pwm, but the mot just never rotates.

    Can you please share in details what other changes did you do apart from increasing the size of num_enc_slots from uint16_t to uint32_t. My guess is that the electrical angle math is not right some where.  

  • Hi Subrat,

    If you continue to not hear back from Vleer, I would suggest that you start a new forum thread describing your issue.  This will ensure that you get help from the community and/or TI.