TIDM-02007: LAUNCHXL-F28379D, BOOSTXL-3PHGANINV

Hi Valeriy,

Have you already found and referenced this guide? https://www.ti.com/lit/spraco3

Also, you will need to change the parameters in 'dual_axis_servo_drive_user.h' file for your specific motor.

Any specific reason you're looking at this TIDM-02007 dual axis FCL solution? Depending on your application, the Universal Motor Lab may be a better solution to work with. However F2837x device is not supported, only newer C2000 devices (F28002x, F28003x, F280013x, etc.)

https://www.ti.com/lit/spruj26

Best,

Kevin

Kevin,

I did follow the document you referenced:  https://www.ti.com/lit/spraco3. Unfortunately, sections 7.2.3 and 7.2.4 of that document do not give me enough information to find and fix my problem.

The LAUNCHXL-F28379D platform was selected by the previous engineer. He had several years of experience with this development board, but he has left recently, and I need to finish the project. Because the project works with a similar motor, I am hoping there will not be much effort to get it working with another motor. But if you recommend switching to a new platform it is also an option if the path to success will be shorter.

All I really need is to be able to run my PMSM motor with and without encoder.

Thanks for your help.

Hi Valeriy,

Valeriy Miagkov said:

Compiling the project to FCL_LEVEL2 and not using the encoder (for now).

You mention you're not using an encoder currently, however I believe this project requires an encoder be used.

For the overcurrent trip condition you're experiencing you'd need to look into the CMPSS (comparator) configuration. You can check the CMPSS status registers after a trip occurs to understand which specific CMPSS module experiences a trip. You may need to increase the currentLimit to prevent a trip from occurring.

Valeriy Miagkov said:

The LAUNCHXL-F28379D platform was selected by the previous engineer. He had several years of experience with this development board, but he has left recently, and I need to finish the project. Because the project works with a similar motor, I am hoping there will not be much effort to get it working with another motor. But if you recommend switching to a new platform it is also an option if the path to success will be shorter.

If you're new to C2000 and motor control the Universal Motor Lab I mentioned may be an easier starting point. The software and documentation is more straight forward in my opinion, also it's all for single motor evaluation.

It supports the BOOSTXL-3PHGANINV already and you can evaluate with encoders or sensorless control. You would just need a different LaunchPad, like the LAUNCHXL-F280025C.

Best,

Kevin

Kevin Allen18 said:

I believe this project requires an encoder be used.

My understanding when project built to FCL_LEVEL2 the encoder is not used. My Teknic M-2310P-LN-04K motor is spinning just fine with QEP not being connected. I would appreciate if you can confirm that this is true. 

Kevin Allen18 said:

You would just need a different LaunchPad, like the LAUNCHXL-F280025C.

I have ordered this launchpad just in case I will not be able to make original setup working with my motor.

In the meantime I hope to make use of the LAUNCHXL-F28379D since I have a few of them on hand.

Kevin Allen18 said:

You may need to increase the currentLimit to prevent a trip from occurring.

I have attempted to change two of the current limits available in the project: motorVars[0].currentLimit in dual_axis_servo_dirve.c and M1_MAXIMUM_CURRENT in  dual_axis_servo_drive_user.h. Neither one made a difference.

Are there any other variables that can be adjusted that affect current limit, or I should look deeper into CMPSS configuration?

Thanks.

Hi Valeriy,

Valeriy Miagkov said:

My understanding when project built to FCL_LEVEL2 the encoder is not used. My Teknic M-2310P-LN-04K motor is spinning just fine with QEP not being connected. I would appreciate if you can confirm that this is true. 

I believe you're right that it can run the motor without the encoder, since it's open-loop control. From the block diagram the speed calculation uses the eQEP encoder feedback, so the measured speed should not be correct however.

Valeriy Miagkov said:

I have attempted to change two of the current limits available in the project: motorVars[0].currentLimit in dual_axis_servo_dirve.c and M1_MAXIMUM_CURRENT in  dual_axis_servo_drive_user.h. Neither one made a difference.

Ok, you are only changing the motor in your set-up, correct? The hardware is exactly the same? And what software changes have you made so far?

Can you check which CMPSS modules are tripping by looking at the CMPSS status register values after the trip occurs (see register window in CCS debug view)? Default Motor1 CMPSS modules are listed below:

#define M1_U_CMPSS_BASE        CMPSS6_BASE         // NC: Set up based board
#define M1_V_CMPSS_BASE        CMPSS3_BASE         // NC: Set up based board
#define M1_W_CMPSS_BASE        CMPSS1_BASE         // NC: Set up based board

You should also update the electrical motor parameters in 'dual_axis_servo_drive_user.h' to match your specific motor if you have not already done so.

Best,

Kevin

Kevin,

Kevin Allen18 said:

Can you check which CMPSS modules are tripping by looking at the CMPSS status register values after the trip occurs (see register window in CCS debug view)?

The CMPSS1 is definitely tripping:

My attempt to change motor parameters in dual_axis_servo_drive_user.h did not make difference in operation. I changed M1_RS (stator resistance) and M1_POLES (Number of poles) to match datasheet from my motor. The reference motor still spinning, like before and my motor is still tripping the CMPSS. Not other changes have been attempted. The only change in HW is replacing one motor with another.

What other parameters would you recommend trying to adjust to find what is coursing the CMPSS to trip?

Thanks.

Hi Valeriy,

This is good info to know that CMPSS1 is tripping. Are the other CMPSS modules being used tripping as well?

Valeriy Miagkov said:

What other parameters would you recommend trying to adjust to find what is coursing the CMPSS to trip?

You can focus on understanding the CMPSS1 configuration and what's causing the trip. It is the Low comparator (each CMPSS module has two comparators in it, High & Low). Try and understand what input voltage condition causes a trip and you can also probe the respective ADC input on motor start-up to see if the voltage exceeds the trip limit. You'll need to set a trigger on your oscilloscope to capture the start-up waveform.

Best,

Kevin

Commenting out CMPSS allows SW to remain in the MOTOR_RUN state and does not trip the tripFlagDMC. The motor is still not spinning.

I started looking into eQEP because of your statement:

Kevin Allen18 said:

the speed calculation uses the eQEP encoder feedback,

I also see reference to the "encode feedback angle (motorVars[0].ptrFCL->qep.ElecTheta)" in paragraph 7.2.5 of the https://www.ti.com/lit/spraco3 

In my case that value remains 0 at all times:

I guess I do not understand how the encoder feedback angle is measured when encoder is not connected during FCL_LEVEL2 build.

I believe it is executed in CLA. How can I make sure CLA is being running?

Thanks

Hi Valeriy,

Valeriy Miagkov said:

Commenting out CMPSS allows SW to remain in the MOTOR_RUN state and does not trip the tripFlagDMC. The motor is still not spinning.

Are there any other fault flags reported now? You may also need to adjust Vd / VqTesting variables for running your motor in Build #2.

Valeriy Miagkov said:

I guess I do not understand how the encoder feedback angle is measured when encoder is not connected during FCL_LEVEL2 build.

It won't be measured, eQEP feedback and calculation (done by CLA task) is needed to get the actual speed (MotorVars[0].speed.Speed) and motor angle (qep.ElecTheta0).

Valeriy Miagkov said:

I believe it is executed in CLA. How can I make sure CLA is being running?

See FCL_runQEPWrap_M1() function in the code.

Best,

Kevin