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.

F28069M Lab 12 bug

Other Parts Discussed in Thread: DRV8301-69M-KIT, MOTORWARE

When I try to run lab 12 with DRV8301-69M-kit and F28069M Piccolo controlcard, a couple of strange things happen.

In lab 12a, the sensored estimate of the inertia and friction is different from the one estimated in lab 5c (sensorless), and it is larger with a factor 5. What can be the cause of this? Also, other times when I try to run the lab nothing happens, and I get an error with code 2004, which means I should lower the Goal Speed. This does not make sense, because other times it does work with the same Goal Speed. Rebuilding the project does sometimes fix the issue.

Secondly, in lab 12b, the speed control does not work the first time after building the project. First, I set "gMotorVars.SpeedRef_krpm” to 0. Then, after building and setting “gMotorVars.Flag_enableSys" and "gMotorVars.Flag_Run_Identify" to 1, I wait some time and set “gMotorVars.SpeedRef_krpm” to 0.5. At this point, the motor starts spinning at its maximum speed (3.7 krpm), and it's not possible to change this without setting "gMotorVars.Flag_Run_Identify" to 0. Strangely, when I reset "gMotorVars.Flag_enableSys" to 0 and back to 1 and retry the whole process, the motor control does work properly.

Is it possible that this is a bug, and is there any way to fix this?

Thanks in advance.

  • Thomas,

    That is a very interesting set of issues.

    Did you set gMotorVars.Flag_enableRsRecalc to false?  In the 12 and 13 labs we use this in order to align the motor and the encoder.   You issue also could be a problem with the encoder setup.  I would expect that you should get approximately the same value of inertia in lab 05c and lab 12a.  

    The issues you are seeing in lab 12b also seem like they are related to encoder setup.  I think it would be good to double check your encoder configuration and wiring.  It would also be go to confirm that you encoder and motor are rotating in the same direction.

    What direction did the motor rotate when you lab 05c?

    After setting gMotorVars.Flag_enableSys to true, do not set gMotorVars.Flag_Run_Identify to 1.  

    Add "st_obj.vel.conv.Pos_mrev" into the watch window.  This is an IQ24 variable.

    Manually rotate the motor in the same direction that your motor rotated when you ran lab 05c.  After 1 revolution of the motor, the value in st_obj.vel.conv.Pos_mrev should be 1.0.  If it is not than there are some issues with your encoder setup.

  • LineStream - Adam Reynolds said:

    Thomas,

    That is a very interesting set of issues.

    Did you set gMotorVars.Flag_enableRsRecalc to false?  In the 12 and 13 labs we use this in order to align the motor and the encoder.   You issue also could be a problem with the encoder setup.  I would expect that you should get approximately the same value of inertia in lab 05c and lab 12a.  

    I haven't touched any of the values in the lab, apart from the ones I mentioned. So gMotorVars.Flag_enableRsRecalc should have been set to true.

    The issues you are seeing in lab 12b also seem like they are related to encoder setup.  I think it would be good to double check your encoder configuration and wiring.  It would also be go to confirm that you encoder and motor are rotating in the same direction.

    The encoder wiring is done properly. Also, encoder and motor are rotating in the same direction.

    What direction did the motor rotate when you lab 05c?

    Clockwise.

    After setting gMotorVars.Flag_enableSys to true, do not set gMotorVars.Flag_Run_Identify to 1.  

    Add "st_obj.vel.conv.Pos_mrev" into the watch window.  This is an IQ24 variable.

    Manually rotate the motor in the same direction that your motor rotated when you ran lab 05c.  After 1 revolution of the motor, the value in st_obj.vel.conv.Pos_mrev should be 1.0.  If it is not than there are some issues with your encoder setup.

    After performing this test, the value of st_obj.vel.conv.Pos_mrev is indeed 1.0.

  • Thomas,

    Which compiler and ccs version are you using?

  • LineStream - Adam Reynolds said:

    Thomas,

    Which compiler and ccs version are you using?

    I am using CCS 6.0.1, with compiler version 6.2.7.

  • Thomas,

    It is possible you are getting noise or intermittent connection on the encoder lines?  I don't see why rebuilding the project would sometimes cause this issue to not occur.  

    What is the value for USER_MOTOR_RES_EST_CURRENT?  If this value isn't high enough to get your motor and encoder aligned, this could be causing these issues.  I would recommend that you increase this value.

    What voltage is your motor?  On the DRV8301-69M-Kit if you run too low of a voltage it could cause issues.

  • LineStream - Adam Reynolds said:

    Thomas,

    It is possible you are getting noise or intermittent connection on the encoder lines?  I don't see why rebuilding the project would sometimes cause this issue to not occur.  

    What is the value for USER_MOTOR_RES_EST_CURRENT?  If this value isn't high enough to get your motor and encoder aligned, this could be causing these issues.  I would recommend that you increase this value.

    USER_MOTOR_RES_EST_CURRENT is set at 3.5A, a bit more than 10% of the rated current.

    What voltage is your motor?  On the DRV8301-69M-Kit if you run too low of a voltage it could cause issues.

    The motor is a 24V BLDC motor, more precisely the Cyclone 650W BLDC motor.
  • I would recommend increasing the current int USER_MOTOR_RES_EST_CURRENT.  This will more strongly attempt to align the motor and the encoder.  Start at 7A and increase from there.  

    I looked up the Cyclone 650W BLDC motor but I couldn't find any information about the encoder.  Can you describe the encoder you are using for this motor?

  • LineStream - Adam Reynolds said:

    I would recommend increasing the current int USER_MOTOR_RES_EST_CURRENT.  This will more strongly attempt to align the motor and the encoder.  Start at 7A and increase from there.  

    I will do so on Monday, because I don't have access to the setup right now.

    I looked up the Cyclone 650W BLDC motor but I couldn't find any information about the encoder.  Can you describe the encoder you are using for this motor?

    I should have mentioned this, I am using an external encoder, more precisely the Avago HEDS-5640 encoder. You can find the data sheet here.

    Edit:

    I have another question. To see which of the inertia estimates from the labs is the correct one, I have estimated the rotor inertia myself with some basic formules. However, this gives me a value in kg*m^2. Can you provide me with a way to convert this to Aperkrpm, or vice versa?


    I have converted the values from the inertia identification to kg*m^2, and the inertia from the sensorless identification corresponds most with my own estimations. I have followed the method from the post on the bottom of this page.

    Torque = A * 0.75 * 8 * flux / (2pi)

    Here A is the value from the inertia identification (INERTIA_A_PER_KRPM), 8 is the number of poles, and flux is the motor flux, which I got from lab 2a. I found the value 0.75 in a formula a TI employee on here provided, I assume it accounts for efficiency.

    With A = 0.426 [amps*krpm/s] and flux = 0.0656 V/Hz, this yields a value of 0.0266 Nm for the Torque.

    Converting krpm/s to rad/s² yields a 104.72 rad/s² for 1 krpm/s.

    Dividing the torque with this value yields 2.54 e-4 kg*m², which is close the value of 2.71 e-4 kg*m², which I estimated with some fast calculations. I did this by approximating the volume of the rotor and taking a density of 7.5 g/cm³ for the rotor material. Assuming the rotor is a solid cylinder yields this value of inertia. I hope this was a bit clear.

    Do you see any flaws in this calculation? I find it strange that the inertia I retrieved from lab 12a is 5 times larger than the one from lab 5c.

  • Thomas,

    I think your calculation seems fine.  I think the issue in that the lab 12a estimate is 5x the 5c estimate is because there is an issue in aligning the motor and encoder.  The inertia measurement for SpinTAC is basically the relationship between amps applied to the motor and acceleration.  If we see this number as larger it takes more amps to reach the same acceleration.  When I've seen cases in the past where there was alignment issues between the motor and encoder it manifested as the inertia being larger than the true value.

  • LineStream - Adam Reynolds said:

    Thomas,

    I think your calculation seems fine.  I think the issue in that the lab 12a estimate is 5x the 5c estimate is because there is an issue in aligning the motor and encoder.  The inertia measurement for SpinTAC is basically the relationship between amps applied to the motor and acceleration.  If we see this number as larger it takes more amps to reach the same acceleration.  When I've seen cases in the past where there was alignment issues between the motor and encoder it manifested as the inertia being larger than the true value.

    Adam,

    I will try increasing USER_MOTOR_RES_EST_CURRENT on Monday. When I have the results I will post them here.

    Also, how much influence does the Goal Speed have on the identified inertia value?

    Edit: What do you actually mean with "issue in aligning the motor and encoder", from a physics point of view? Note that the encoder is also attached to the motor in the sensorless inertia identification, but the cables are not connected.

  • LineStream - Adam Reynolds said:

    Thomas,

    I think your calculation seems fine.  I think the issue in that the lab 12a estimate is 5x the 5c estimate is because there is an issue in aligning the motor and encoder.  The inertia measurement for SpinTAC is basically the relationship between amps applied to the motor and acceleration.  If we see this number as larger it takes more amps to reach the same acceleration.  When I've seen cases in the past where there was alignment issues between the motor and encoder it manifested as the inertia being larger than the true value.

    Adam,

    Something strange is happening now. When I try to run the inertia identification in lab 5c, the motor spins at its maximum speed during the identification. Changing gMotorVars.SpinTAC.VelIdGoalSpeed_krpm doesn't change anything.

    What can be the cause of this?

  • Thomas,

    From a physical point of view, when I mentioned "aligning the motor and encoder" the motor has sets of pole pairs and these pole pairs represent one electrical revolution in the motor.  When doing sensored motor control we need to know the exact electrical angle at all times.  So there needs to be a step that will place the motor into a known electrical angle in order to set the electrical angle of the encoder because with an incremental encoder there is no knowledge of the motor location on power-up.  In the labs we do this at startup when re-estimating the motor resistance when the estimator is in state EST_State_Rs, since we know that during this state the motor is forced to an electrical angle of 0.

    The value in gMotorVars.SpinTAC.VelIdGoalSpeed_krpm changes the speed that the test will try to achieve in the inertia identification test.  As part of the inertia identification test the motor may not reach the exact speed specified but it gives us an idea of the speed range the test needs to be ran over.

    What speed did you set and what speed did the motor achieve?  We recommend setting this value to the maximum speed of your motor without field weakening.  

  • LineStream - Adam Reynolds said:

    Thomas,

    From a physical point of view, when I mentioned "aligning the motor and encoder" the motor has sets of pole pairs and these pole pairs represent one electrical revolution in the motor.  When doing sensored motor control we need to know the exact electrical angle at all times.  So there needs to be a step that will place the motor into a known electrical angle in order to set the electrical angle of the encoder because with an incremental encoder there is no knowledge of the motor location on power-up.  In the labs we do this at startup when re-estimating the motor resistance when the estimator is in state EST_State_Rs, since we know that during this state the motor is forced to an electrical angle of 0.

    Thanks for the explanation.

    The value in gMotorVars.SpinTAC.VelIdGoalSpeed_krpm changes the speed that the test will try to achieve in the inertia identification test.  As part of the inertia identification test the motor may not reach the exact speed specified but it gives us an idea of the speed range the test needs to be ran over.

    What speed did you set and what speed did the motor achieve?  We recommend setting this value to the maximum speed of your motor without field weakening.  

    First, I set the goal speed equal to the rated speed, but then the motor would spin at its maximum speed under no load (it reached this spead almost immediately), being approximately 3700 rpm. Changing the value of the goal speed did not change the behaviour, the motor would just spin at its maximum speed every time the inertia identification was run.

  • Thomas,

    Prior to setting gMotorVars.SpinTAC.VelIdRun to 1, does the motor spin at about 100rpm or the maximum speed?

  • LineStream - Adam Reynolds said:

    Thomas,

    Prior to setting gMotorVars.SpinTAC.VelIdRun to 1, does the motor spin at about 100rpm or the maximum speed?

    It spins at 100 rpm.

  • Thomas,

    What did you set as the goal speed and what was the speed that it spun at during the test?

    Was there any source code modifications done?

  • LineStream - Adam Reynolds said:

    Thomas,

    What did you set as the goal speed and what was the speed that it spun at during the test?

    Was there any source code modifications done?

    I set the goal speed at the rated speed of 2050 rpm. The motor spun at approximately 3700 rpm during the test, very briefly however (which is normal for the inertia identification I assume). Changing the goal speed to higher or lower values did not change anything.

    There have not been any source code modifications done on purpose. Maybe something was changed accidentally, but I don't think so.

  • Thomas,

    It would probably be worth double checking that you had loaded in lab 05c.  I've seen occasions where you tell code composer to load in one project and it loads in another.  Especially since this behavior is similar to what you see when you ran lab 12a.

    When using lab 12a there are a couple issues that come up:

    - motor spins at maximum speed in test -> this indicates that the alignment was either not done or didn't use enough current (USER_MOTOR_RES_EST_CURRENT_A was too small)

    - motor doesn't spin -> either the encoder is not connected, has electrical noise, or the direction between the motor and encoder is wrong

    - motor spins but inertia is very large -> this indicates that the alignment was either not done or didn't use enough current (USER_MOTOR_RES_EST_CURRENT_A was too small)

  • LineStream - Adam Reynolds said:

    Thomas,

    It would probably be worth double checking that you had loaded in lab 05c.  I've seen occasions where you tell code composer to load in one project and it loads in another.  Especially since this behavior is similar to what you see when you ran lab 12a.

    When using lab 12a there are a couple issues that come up:

    - motor spins at maximum speed in test -> this indicates that the alignment was either not done or didn't use enough current (USER_MOTOR_RES_EST_CURRENT_A was too small)

    - motor doesn't spin -> either the encoder is not connected, has electrical noise, or the direction between the motor and encoder is wrong

    - motor spins but inertia is very large -> this indicates that the alignment was either not done or didn't use enough current (USER_MOTOR_RES_EST_CURRENT_A was too small)

    How would I check this? The console says it has succesfully built lab 12a or 5c, depending on which one I choose.

    I have increased USER_MOTOR_RES_EST_CURRENT_A to 7A, but the issue kept occurring. I find it strange that this happens, because previously I have been able to perform lab 5c without any problem. The only modifications that have been made, were done in the user.h file.

  • The way to make sure you have loaded the correct project is to right click on the project you want to load and select Debug As -> Code Composer Debug Session. 

    It is strange, I am not sure why you are seeing these issues.  Is your motor coupled with anything?

  • Yes, the right project was loaded.

    I will try uninstalling CCS and Motorware, to see if that helps.