• State TI Thinks Resolved
  • Locked Locked
  • Replies 8 replies
  • Answers 1 answer
  • Subscribers 84 subscribers
  • Views 925 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

Original question:

CCS/TMS320F28054F: EST_ErrorCode_FluxError flux estimator error code: How to see the cause in the software?

CCS/TMS320F28054F: Problems with lab1b and lab1c functions with no source code

David Larson
Intellectual 310 points

Part Number: TMS320F28054F
Other Parts Discussed in Thread: MOTORWARE, CONTROLSUITE

Tool/software: Code Composer Studio

Continuing our attempt to work through the motorware labs for our board.  The good news is we found a way to get the motor to run with lab1b and lab1c.  The bad news is we had to bypass a function which you do not offer source code for, so we are on shaky ground until you explain how to solve this.  In addition I am attaching a graph output for lab1b that shows the Voltage with the AngleGen.  Tom would like to know why it has defects.  Is it because we need a better emulator than 100v2?

First in the case of lab1b, we have to manually change the gMotorVars.SpeedRef_krpm to 0.5 or higher to get the motor to run.  It runs better at 0.6 or higher.   Without modification, it sets it to about 0.1 which doesn't work. What is going on?

Second, in lab1c, we have to set the GmotorVars.gMotorVars.SpeedRef_krpm to 0 to get the motor to run to avoid the call to CTRL_setUserMotorParams which sets the kp variable to 0. Unfortunately you don't provide source code to CTRL_setUserMotorParams so we don't what calculation from user params is causing this.  This doesn't seem right not to provide source code to a function that uses user parameters. Can you please give us a good clue so we can proceed to lab2a?

  • 0
    TI__Guru** 117260 points
    As Sean recommended and replied to you, lab01b and lab01c use an open speed loop control to test the signal chain integrity of the hardware board.
    1. For datalog function, the XDS100V2 is good enough for it, It seems like the motor didn't spin smoothly in your case. You might change the v/f profile curve in user.h and set a right gMotorVars.SpeedRef_krpm based on your motor, to spin the motor smoothly that could improve the waveform of feedback voltage. The output voltage of the motor is not high enough to be spun if you set the gMotorVars.SpeedRef_krpm to a lower value.
    2. You muse set gMotorVars.SpeedRef_krpm to a right value as lab01b in lab01c if you didn't change the example project in motorWare. You need to set gMotorVars.Flag_enableUserParams to "true" in both lab01b and lab01c, which is set to " true" by default. You need to set the motor parameters (Rs, Ls) to a defination value in user.h, and can't set it to "NULL".
    3. CTRL_setUserMotorParams() is not called for motor identification in lab02a/b/c,is just used to calculated the control parameters based on motor parameters if gMotorVars.Flag_enableUserParams is set to "true".
  • 0 in reply to Yanming Luo
    Intellectual 310 points

    Thank you for your reply and the information you provided.   We will focus on the suggestions 1-3 this next week. Can you provide an example regarding the v/f profile curve to discuss? That sounds promising.

    Lab1b works with user params by just increasing gMotorVars.SpeedRef_krpm, but lab1c does not. There are hidden functions with no source code even in lab1b and lab1c (unless they are in assembly language that I didn't notice … but that makes no sense as the functions do not seem that time critical).     We have proven the board can run the motor and the feedback values seem reasonable.   The current adc values can be watched and look correct as well as the voltage.  The voltage adc counts increase with voltage and the current adc counts decrease from about 2000.  Scaling and offset should calculate the real voltage with a negative scale for current. This appears to be working.  If we are blocked from seeing the source code we can't track the calculations past that.

      In my opinion, since the focus is on lab1b and lab1c, there should be 0% hidden source code and 100% open source for those 2 labs.  Its the least TI can do to ensure success when software engineers are hired to work on a project using motorware so we can check the calculations all the way through for clues.  TI went to the trouble of avoiding using motorware in labs 1b and 1c so why hide pieces of the source code?

      

  • 0 in reply to David Larson
    Intellectual 310 points

    We are waiting for a reply of an example of how to vary the v/f curve to get reasonable voltage output in lab1c before proceeding with our tests.  SInce a function with no source code is involved, we need to know what we need to change in user.h to improve the voltage output when we enable user params.

    .

  • 0 in reply to David Larson
    TI__Guru** 117260 points
    There is no v/f profile required in lab01c, the v/f profile (in vs_freq.c and vs_freq.h) is only used in lab01b. The lab01c uses i/f control, you just need to set gMotorVars.IdSet_A, gMotorVars.IqSet_A and gMotorVars.SpeedRef_krpm to ensure the motor spin well.

    Btw, no more source code is hidden in both lab01b and lab01c, there is only instaSPIN-FOC FAST code in the ROM that you can't find the source code. You should find all other source code used in lab01b and lab01c in .c or .h files.
  • 0 in reply to Yanming Luo
    Intellectual 310 points
    Thanks for the update. What about the CTRL_setUserMotorParams function in lab1c? Where is the source code for that function?
  • 0 in reply to David Larson
    TI__Prodigy 410 points

    After motor parameters are identified, CTRL_setUserMotorParams will be called by instaSPIN ROM code to configure motor current controller parameters, and no user's tuning needed. It is also the reason why the source code for CTRL_setUserMotorParams is not needed by instaSPIN users. 

  • 0 in reply to Hui Tan
    Intellectual 310 points

    The problem there is the values it is producing to run the motor are too small so we wanted to see the calculations it is doing with the parameters.  It is just my opinion that those labs should be open source even if in rom so we can see what we might be doing wrong.  I have been told that the company is moving on and someone else is writing a solution not involving motorware.   It would be nice to see a solution so we can use it.

  • 0 in reply to David Larson
    TI__Guru** 117260 points
    Agree with you. If you want to design your solution with open source, you might have a look at some example references in controlSUITE which are totally open source, that includes scalar and FOC for ACIM and PMSM.
    www.ti.com/.../controlsuite
    There is an example reference as lab01b or lab01c also.
    C:\ti\controlSUITE\development_kits\HVMotorCtrl+PfcKit_v2.1\HVACI_Scalar

    For lab01b and lab01c in motorWare, the CTRL_setUserMotorParams must be called by instaSPIN ROM code to calculate the parameters for the controller and estimator with motor parameters from the user.h. To keep continuity, easy and simple on this software, we used a library interface for rom code, not the open source code for it.