• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Subscribers 82 subscribers
  • Views 176 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

LAUNCHXL-F280049C: servo_drive_with_can issues

Mike Twieg1
Intellectual 390 points
Part Number: LAUNCHXL-F280049C
Other Parts Discussed in Thread: BOOSTXL-DRV8320RS, LVSERVOMTR

I'd like to use the example project servo_drive_with_can_f28004x to see how to properly use an incremental encoder for sensored foc. I'm following the Lab Projects User's guide and am using the LAUNCHXL-F280049C, BOOSTXL-DRV8320RS, and LVSERVOMTR (Teknic M-2310P-LN-04K) as suggested by the guide.

When I get to part 3.2, I observe that everything seems to work fine, motor spins, I can change its speed and see step response, etc. But if I pinch the rotor a bit, the motor stops spinning (and won't resume until I reset everything or turn the shaft again manually). After looking around a bit I find that the eQEP1 peripheral registers are all zero, and also qepHandle_sensor->qepsensor->lsw = ENC_WAIT_FOR_INDEX, even while the motor is spinning. Looking further I find that this is because the macro _EQEP_EN_ is not defined (the build configuration includes the predefined symbol EQEP_ENABLE, not sure why there's another macro for this...).

Ok, should be a simple fix. I define _EQEP_EN_ in hal_obj.h, rebuild, and try again. Now when I set motorVars.flagEnableSys = 1 and motorVars.flagRunIdentAndOnLine = 1, what I observe is that the motor will twitch very briefly, then stop. After that I can see in the expressions window that qepHandle_sensor->qepsensor->lsw = ENC_CALIBRATION_DONE. I'm guessing it rotated as normal until it saw an index pulse. No fault flags have tripped in motorvars. I probe the hardware and find that there's several amps DC being pushed through the motor. It doesn't seem like a hardware fault though. None of the electronics heat up significantly, and if I rebuild after disabling _EQEP_EN_, its behavior reverts to what I saw before. I checked the encoder waveforms manually with a scope, all three signals seem to function normally. 

I'm not familiar enough with the SDK to determine why the controller locks up when the encoder is enabled. Based on the user guide, I thought that code was supposed to use the encoder for speed feedback. Is there some other way I should have enabled the eQEP1? Is there something else I'm missing

Regards,

Mike

  • 0
    TI__Guru** 109810 points

    Which DMC_BUILDLEVEL are you setting in servo_main.h? You might change the _EQEP_EN_ to EQEP_ENABLE in hal.c as below, and the EQEP1 is supported in the project by default, so you must connect the encoder to the J12 on LaunchPad.

    #ifdef EQEP_ENABLE
        // initialize QEP driver
        obj->qepHandle[0] = EQEP1_BASE;         // EQEP1
        obj->qepHandle[1] = EQEP2_BASE;         // EQEP2
    #endif

  • 0 in reply to Yanming Luo
    Intellectual 390 points

    Hi Yanming,

    I was observing the issue with DMC_LEVEL_2. Yes, the encoder (J4 on the motor) is connected to J12 on the LAUNCHXL.

    Sure, changing #ifdef _EQEP_EN_ to EQEP_ENABLE makes sense. But in that case I still get the same result. The motor moves slightly then stops. So it seems there's some other bug lurking in the code.

    Is there some simple way of verifying eQEP1 is configured correctly? Unfortunately, since the motor locks itself up immediately after it starts, that makes it pretty difficult to manually turn the shaft to observe the behavior of eQEP1. And even if I could turn it, I'm not sure what specifically to look for.

    Regards,

    Mike

  • 0 in reply to Mike Twieg1
    TI__Guru** 109810 points

    Double check the project, it works well on DMC_LEVEL_2 and other levels.

    1. Please check if the motor and encoder wires are connected correctly to LaunchPad and BoostPak.

    2. Please check if the switch on S3 on LaunchPad are set to QEP position for routing the GPIOs to QEP interface.

  • 0 in reply to Yanming Luo
    Intellectual 390 points

    Hi Yanming,

    Below is a photo of the connections to the motor+encoder. One thing I like so far about the motor is that the connections are already grouped to match with the headers, which makes it difficult to mix up the connections. I also double checked the motor connections match with table 3 in the user's guide.

    I also verified S3 is set correctly. The user guide apparently refers to a different rev of the LAUNCHXL board, it refers to S5 instead. I probed the encoder signals all the way to the MCU pins to verify the switch was correct.

    Again, I don't think it's a hardware setup issue (unless there's some gross mixup in the colors of the motor wires). Are there any specific variables I should be watching to debug further?

  • 0 in reply to Mike Twieg1
    Intellectual 390 points

    Is there a way to modify the code such that the eQEP peripheral and object/handle are configured, but its output is not actually used by the closed loop controller? I think that would make debugging this much easier.

    In servo_drive_with_can.c, I see this in the ISR (line 750):

    #if (DMC_BUILDLEVEL == DMC_LEVEL_1)
        angleFoc_rad = angleGen_rad;
#else
        angleFoc_rad = qep_sensor.Angle; //get angle from qep
#endif  // DMC_BUILDLEVEL != DMC_LEVEL_1

    If I just force it to use use angleGen_rad, will that work?

    I also see this earlier in the ISR (line 728):

            qep_sensor.CaliAngle = angleGen_rad;
        QEP_SENSOR_run(qepHandle_sensor);
        motorVars.speed_Hz = qep_sensor.SpeedHz;

    Not sure if I should comment out the third line... is speed_Hz used for feedback, or just monitoring/debugging?

  • +1 in reply to Mike Twieg1
    TI__Guru** 109810 points

    Double check again to run the lab, seems all build levels work well. I have to ask you check if the motor and encoder are connected correctly again.

    You might run build level1 to check if the value of qep_sensor.SpeedHz equals to the value of motorVars.speedRef_Hz.

    And check if motorVars.faultUse.all is not equal to zero, if yes, set motorVars.flagClearFaults to "1" to clear the fault, and start run the motor by setting the motorVars.flagRunIdentAndOnLine to "1" again.

    motorVars.speed_Hz is used in GRAPH tool and just for debugging in this lab.

  • +1 in reply to Yanming Luo
    Intellectual 390 points

    Hi Yanming,

    I tried your suggestion of going back to build level 1. Also changed all references of _EQEP_EN_ to EQEP_ENABLE. Didn't touch any connections or switches. Now I observe

    • The motor spins at the proper speed
    • The current draw from the power supply is much higher than it was previously at build level 1. Supply voltage is 24V, drawing 0.68A total with the motor speed = 40Hz (10Hz mechanical), with no torque applied.
    • If I grab the shaft, it maintains speed much nicer than it did previously. Interestingly, supply current drops slightly to ~0.55A. If I really grab hard it will stop, but resumes again immediately after I let go.
    • While spinning, the qep sensor_object show lsw = ENC_CALIBRATION_DONE, and SpeedHz matches the reference speed.
    • If I disable the drive (set motorVars.flagRunIdentAndOnLine = 0), I can freely turn the shaft and I can see the angle and speedHz in qep sensor update appropriately

    So that's all good, except for the high current draw from my DC supply. Thermal camera shows no exceptional heating on the electronics, all that power must be dissipated in the motor. I'm guessing there's some parameter(s) set incorrectly.

    Then I change to build level 2:

    • On setting motorVars.flagEnableSys and motorVars.flagRunIdentAndOnLine, the motor spins again (instead of locking like before)
    • At the same speed as before, total current draw from PSU is 0.125A instead of 0.68A. Grabbing the shaft causes supply current to increase, as expected.

    I think the reason build level 2 didn't work previously is because hal_obj.h isn't included everywhere that _EQEP_EN_ was referenced, so the eQEP1 still wasn't set up completely. Probably a better way to fix the project is to just add _EQEP_EN_ as a predefined symbol, along with EQEP_ENABLE.

    Anyways, it seems I'm back on track, thank you! Also wanted to ask, are there any other labs or examples using sensored FOC (hall or incremental encoders) which work with the hardware I have (LAUNCHXL-F280049C/BOOSTXL-DRV8320RS/LVSERVOMTR)? Most of what I'm finding requires instaspin Motion, but I need to stick with the F280049C. Any suggestions?