TMS320F280025C: Errors while driving LVSERVOMTR on TMS320F280025C and DRV8323RH board

And if I try to run the motor identification for motor parameters, still, I can get this same currentUnbalance error, and then 'startupFailed'

Current unbalance error indicates one of the phase currents is higher or lower than the others.

1. What is the build configuration of the project?
   1. 
2. In user_mtr1.h, what is the value of USER_MOTOR1 ?
   1. 
   2. 

Regards,
Jason Osborn

Jason,

1, I'm using build configuration of DRV8323RH

2. Motor of Teknic_M2310PLN04K(Same as required on this lab development kit)

Thanks,

Hengchen

And here is my pre-defined symbols

1. Please double-check all setup instructions in the UMCL User's Guide- disconnects, jumpers, etc.
2. Does this issue happen in Build Level 3?

Regards,
Jason Osborn

1. All board connections are good, all same as the user's guide.

2. And this issue happens only in Build level 4, FAST based Sensorless FOC algorithm. No matter I run the motor parameters identification or just try to run the motor directly.

3. The motor can run without errors under any other algorithms, including eSMO, ENC and HALL.

Regards,

Hengchen

Hengchen,

Interesting. How accurate are the voltage ADC readings? If everything else is running correctly, this makes me think that something is off on one or more voltage ADC channels.

Regards,
Jason Osborn

This is the Expressions before I start the motor or parameters identification, and the voltage I give to DRV8323 board is 24V

Regards,

Hengchen

But, at first, this build stage 4 could run normally on board for the parameters identification, and also to run the motor(but the motor runs very very slow, even though the reference speed is set to 60Hz). I don't know why it now could not to run.

I'm wondering right now if either a parameter that's only relevant to FAST is incorrect, or if the ADC for the voltage legs is set up incorrectly.

• Run the motor in Build level 3
• Look at the contents of motorVars_M1.adcData
  • 
• Specifically, we want to know the contents of the following elements:
  • motorVars_M1.adcData.V_V
  • motorVars_M1.adcData.offset_V_sf

While running the motor in build level 3, determine the following:

1. Are all 3 values in motorVars_M1.adcData.offset_V_sf approximately equal to 0.5?
2. Are the 3 values in motorVars_M1.adcData.V_V plausible?
   1. These are the U/V/W phase voltages, for context if that was not clear.

Regards,
Jason Osborn

I checked those elements in build level 3, it seems like all right?

All 3 values in motorVars_M1.adcData.V_V is around '-9', and values in motorVars_M1.adcData.offset_V_sf is around '0.5'

and here it is:

offset_V_sf correctly being 0.5 tells me that it does not appear to be an issue in the voltage ADC setup.

While running the motor in build 3, does the speed in motorVars_M1.estOutputData closely match the actual motor speed motorVars_M1.speed_Hz ?

If you have an oscilloscope, it would also be very useful to view the generated angle and the estimated angle on the scope, as described in the user's guide.

Regards,
Jason Osborn

I remember the value of speed in motorVars_M1.estOutputData should be the same as my speed setting(60), I can run it again for sure and give you a feedback, but it will be the next Monday for me(I’m on holiday for this week). Please leave this question not to closed.

Thanks,

Regards,

Hengchen

The output of motorVars_M1.estOutputData seems like to be closely match the actual motor speed, and the fe_Hz of motorVars_M1.estOutputData varies between 50 and 70, and my given speed is 60.

I have an oscilloscope, but I don't have the EPWMDAC or DAC128S, so I don't know how to use it directly, I just use Datalog to observe it.

By the way, after minutes of running, the motor becomes warm, even hot, is that normal?(But this won't happen if I use ENC or HALL to run)

Regards,

Hengchen

I already update the param USER_M1_Ix_OFFSET_AD and USER_M1_Vx_OFFSET_SF according to the auto offset calculate, and also chose the right motor model 'Teknic_M2310PLN04K', but how should I know how to change the other parameters to an appropriate value？

And in build level 4, it could run without 'motor identify', but just rotates very slowly, only in FAST, under eSMO, it could rotates just fine.

Apologies, I had forgotten that you were using a pre-defined motor.

Have you completed the following step, listed in the Universal Motor Control Lab User's Guide?

Regards,
Jason Osborn

Of course, but only the first 2 steps, because I'm not using DAC128S085EVM board for monitoring variables, and directly change reference speed through variables in Expressions

Besides, I could run this motor on the level 1, 2 and 3 without any errors under any avaliable algorithm, including FAST.

Regards,

Hengchen

Hengchen,

Thank you for confirming. The reason I'm asking is that populating these capacitors is required only for the FAST algorithm, none of the others. Each of the questions I've asked so far has been related to a previous instance in which I've seen something similar to this problem.

Can you do the following debug step?

• First:
  • Run the motor in build level 3
  • Run the motor with FAST enabled
  • In the datalog tool, have both graphs open, showing the following variables:
    
    • The open-loop generated angle: motorVars_M1.angleGen_rad
    • The FAST estimator estimated angle: motorVars_M1.angleEST_rad
  • While running the motor, take a screenshot showing both graphs at the same time. We expect these waveforms to be essentially identical (sawtooth waveforms).
    
    
• Second:
  
  • Run the motor in build level 4
  • Run the motor with FAST and eSMO both enabled
  • In the datalog tool, have both graphs open, showing the following variables:
    • The eSMO estimator estimated angle: motorVars_M1.anglePLL_rad
    • The FAST estimator estimated angle: motorVars_M1.angleEST_rad
  • Before running the motor, set motorVars_M1.estimatorMode to "ESTIMATOR_MODE_ESMO" in the CCS Expressions Window
  • While running the motor, take a screenshot showing both graphs at the same time.
  • Stop the motor using the expressions window. Set motorVars_M1.estimatorMode to "ESTIMATOR_MODE_FAST" in the CCS Expressions Window
  • While running the motor, take another screenshot showing both graphs at the same time.

After doing these debug steps, you should have 3 screenshots.

1. Build level 3, running open-loop, with 2 charts. One of the charts shows motorVars_M1.angleGen_rad and the other shows motorVars_M1.angleEST_rad
2. Build level 4, running the eSMO estimator, with 2 charts. One of the charts shows motorVars_M1.anglePLL_rad and the other shows motorVars_M1.angleEST_rad.
3. Build level 4, running the FAST estimator, with 2 charts. One of the charts shows motorVars_M1.anglePLL_rad and the other shows motorVars_M1.angleEST_rad.

Please post all 3 screenshots here for me to observe. This should give me a lot of insight into the problem.

Regards,
Jason Osborn

* This is for step1:

* And this is for step2:

** eSMO:

** FAST:

Regards,

Hengchen

Hengchen, in that final screenshot (build 4 with FAST and eSMO enabled, using FAST as the primary estimator), is the motor still behaving abnormally?

Regards,
Jason Osborn

My apologize, I forgot to change the build level, here's the new screenshots for step2(second):

**eSMO

** FAST

And the motor just rotates very slowly

Regards,

Hengchen

Hengchen,

Apologies for the delay in response. As I think I've mentioned, I've seen very similar issues in the past, and so far, none of those problems have appeared to be applicable. This is very odd. Please post these images:

1. An image of the top of the F280025C LaunchPad, by itself
2. Images of the top and bottom of the DRV8323RH Booster Pack
3. An image of the fully attached setup of the LaunchPad, Booster Pack, and motor.

To summarize my current thought process, for clarity: If eSMO and build level 3 are working, but FAST is not, this indicates to me that something is wrong with one of the following:

• The voltage sensing, causing FAST to fail
• The FAST estimator settings, causing FAST to fail for this motor specifically
• The trajectory/ramp/slew generator, causing startup to fail

Of these;

• You have confirmed that voltage sensing appears to be good.
• The FAST estimator settings are known good, and we can see that when FAST is not actually controlling the motor, the estimation appears to be working.
• If untouched, the traj generator should be good. I have not replicated this behavior locally, so I'm not sure why it would be bad on your computer, but not mine.

Regards,
Jason Osborn

Osborn,

Yes, this bothers me too, as it could works before, but suddenly one day, it just can't, but I didn't change any settings or wire connection.

Here are the images

I used wire connection between 280035C and DRV board, as I didn't bend J3-29 and J3-30, I just skipped them from connection

Regards,

Hengchen

If it was working before and is not any longer, it's possible one of the wires failed. Jumping the wires between the LP and the Booster Pack can cause instability in many signals. I'd recommend connecting the two boards directly- one thing that we sometimes do to avoid bending the pins directly is attaching an extra set of connectors on top of the LP, then bending or removing those pins instead.

The part number is the Samtec SSQ-110-03-T-D as seen in the LP's BOM.

Let me know if a direct connection possibly improves things?

Regards,
Jason Osborn

Osborn,

Thanks for the advice, I directly connect the DRV and LaunchPad now(bend J3-29 and J3-30), however, I'm in the same situation:

1. If I directly try to start the motor, It just rotate very very slow, even if the speedRef is setting to 60

2. If I tried to start the auto motor identify, it just failed to start, with 'currentUnbalance' and 'startupFailed' error

Regards,

Hengchen

Hengchen,

Apologies for the delay in response. Do you have any other LaunchPads and/or boosterpacks that you could verify this issue with in an A/B swap? Isolating the problem is important here.

Regards,
Jason Osborn

Osborn,

I changed with another LaunchPad to try to run it, but the behaves exactly the same, and how can I verify the issue with in an A/B swap?

Regards,

Hengchen

Negative, but thanks a lot.

Hengchen