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.

GUI without User.h works but GUI with user.h doesn't

Other Parts Discussed in Thread: MOTORWARE

HI,

I've spent all day trying to run down this problem without any success.  And I've spent quite a while looking though  this forum and couldn't find any similar problems.  

If I use the GUI (with Lab10a) and uncheck User.h and check RsRecalc the program goes through the Rs and Ls calculations just fine and when it finishes I can run the motor up to 12800 RPM.  The motor runs smoothly with no issues. Now if I uncheck RsRecalc and check User.h, re-enable the system and click Run the motor will only go to 3500 revs before it starts to oscillate badly.

Is there some secret sauce in the GUI if the User.h file isn't used?

Here is the screen grab of the no User.h run:

Here's the GUI with the USER.H checked:

I sure hope it's something obvious that I've left out or miscalculated.

Here is my USER.H variables:

#define USER_IQ_FULL_SCALE_FREQ_Hz        (1200.0)

#define USER_IQ_FULL_SCALE_VOLTAGE_V      (15.0)

#define USER_SYSTEM_FREQ_MHz             (60.0)
#define USER_PWM_FREQ_kHz                    (45.0)

#define USER_NUM_PWM_TICKS_PER_ISR_TICK        (3)
#define USER_NUM_ISR_TICKS_PER_CTRL_TICK       (1)    
#define USER_NUM_CTRL_TICKS_PER_CURRENT_TICK   (1)  

#define USER_MOTOR_NUM_POLE_PAIRS       (7)
#define USER_MOTOR_Rr                                      (NULL)
#define USER_MOTOR_Rs                                     (0.0992)
#define USER_MOTOR_Ls_d                                 (0.000007325)
#define USER_MOTOR_Ls_q                                 (0.000007325)
#define USER_MOTOR_RATED_FLUX                 (0.0065481369)
#define USER_MOTOR_MAGNETIZING_CURRENT  (NULL)
#define USER_MOTOR_RES_EST_CURRENT    (6.0)
#define USER_MOTOR_IND_EST_CURRENT      (-3.0)
#define USER_MOTOR_MAX_CURRENT               (20.0)
#define USER_MOTOR_FLUX_EST_FREQ_Hz     (180.0)

I hope this makes sense.

Thanks,

Richard

  • Richard, I'm stumped. I don't see any differences between the two. The Ls is close. The Rs is close. The controller gains are essentially identical. The offsets are correct.

    In the 2nd one the acceleration is 10x slower...that really shouldn't be a problem, but just to baseline I would try making them the same.

    After that try starting up with RsRecal checked to see if that makes a difference.

    If either one was going to give you an issue it should have been the first, trying to do motor ID on a high speed motor.  As you can see the RoverL saturated to 2000 which means you are supposed to use proj_lab02c method to ID this motor.  You kind of got lucky that it worked.

    I don't see any reason why  you would have an issue running 10a from user.h.  I do it all the time...

  • Chris,


    Just to make the situation a little stranger - when I run the motor through the GUI without the USER.H file, the RPMs are correct.  The displayed number exactly matches my tach.  But if I run it with the USER.H file the RPMs are too high.  Meaning that the displayed numbers are low compared to my tach.  If the GUI shows 1000 revs my tach will show 1130.  We don't have the current probe yet so I can't see the waveform yet.  As son as we get it I'll send you ascreen grab of the currents.


    Thanks,

    Richard

  • that obviously doesn't make any sense...all the inputs to the EST_ are essentially the same, there shouldn't be any reason for the estimated speed to be so off.
  • can you try starting with a fresh install of MotorWare and a new CCS workspace? Just trying to eliminate the possibility of a compile / link issue.
  • Hi Chris,

    No joy. I downloaded a fresh copy of Motorware and used a new workspace. Same results. Bad RPMs. Do you have any other ideas? At this point I don't care how improbable I'll try anything now.

    Richard
  • when loading from user.h enable the RsRecal and OffsetCal at least.

    I'm pretty stumped...I haven't been able to reproduce the issue. I'm not using a Tach, but I don't see any unusual control behavior with motors I've tried loading from user.h Never seen any issue reported by customers, etc.
  • Hi Chris,

    I finally got the two motors to run at the proper RPMs.  I had to increase the Ls-d values from 0.00000716567 to 0.0000216567.  I don't quite understand why it matters but the motors are running just like they're supposed to.  I there a downside to increasing the inductance?


    Thanks,

    Richard

  • well, the estimators are a motor model, so if the parameters are off the estimations will be off. And when you are talking about the very lower limit of the inductance value it makes some sense.

    I read through the thread again but could figure it out. What are the Tachometer readings when using 7uH vs. 21uH?
  • Hi Chris,

    One motor was showing 3000 revs while my two tachs were showing 3604. This motor has 14 poles so I used 7 pole pairs. The other motor has 11 pole pairs and when the GUI showed 1000 rpm the tachs showed 560. So one was high and one was low.

    Thanks,

    Richard
  • "3000 revs while my two tachs were showing 3604. This motor has 14 poles"
    20% error @ 420 Hz. This could be believable, though I'm surprised. This is the one that you changed Ls from 7uH to 21uH?

    "other motor has 11 pole pairs and when the GUI showed 1000 rpm the tachs showed 560"
    78% error @ 100 Hz. That doesn't seem feasible...even if the Rs value was significantly off and adding to the error...seems suspect.
  • actually, we did some testing of FAST across a bunch of conditions, Ls variation being one of them.

    going from -50% of actual Ls to +50% of actual Ls:
    under high load current we are seeing essentially +/- 16 degrees of drift in the estimated angle.
    That results in almost no loss of available torque and I would think the speed estimation would be quite reasonable (but that wasn't tested).

    Your case is 4x worse than 50% though...that gives a significant angle estimation error which should result in significant loss of torque and I'm sure inaccurate speed estimations (but I can't quantify).

    Let me see if someone else has any input on this one.