Graphical User Interface / Identification Method / `User.h Settings`

Hi,

I am moving your thread to the C2000 forum as they will best be able to answer your question.

-Nick

The InstaSPIN-FOC and -MOTION GUI are meant for quick evaluation and demonstration of some of the capabilty.

After demonstrating capability you need to move to the embedded code, using MotorWare and Code Composer Studio.

With MotorWare you should follow the projects/labs. They walk you through the steps and capabilities (Motor ID, ADC offset, saving parameters in your user.h, tuning current controllers, tuning speed controller, over modulation, field weakening, etc.). 

Hello Chris,

I have tried Motorware example project until lab 7, and now I want to try lab 9 (I use TMDSHVMTRINSPIN and TMS320F28069M).

In this case, I want to come back using GUI Composer to understand the flow (because the explanation of this example project - lab 9 - in user guide is not much).

But my GUI Composer won't load and won't open (the last .out in F28069M is from lab 7).

I thought GUI Composer will load automatically the necessary .out for its application (or not?)

What .out that I should load for GUI Composer?

Thanks for helping!

Best regards,

Maria

Hello,

Sorry for the previous problem.

I tried my GUI Composer in my laptop with OS Windows XP and it worked well !

But unfortunately it still won't open in my computer with OS Windows 7.

Anyway, the problem is not from .out :)

Best regards,

Maria

Maria,

Correct, the current GUI executable loads the appProgram.out from the same folder. For example, if you run

C:\ti\guicomposer\webapps\InstaSPIN_MOTION_F2806xM\InstaSPIN_MOTION_F2806xM.exe

it will load

C:\ti\guicomposer\webapps\InstaSPIN_MOTION_F2806xM\appProgram.out

as the program

assuming this is the appProgram.out that came with the installation it will work fine.

Did you try to rename one of your proj_lab##.out to appProgrom.out and run?
If so, that will NOT work.  GUI Composer works by attaching variable names to the interface widget. In this case the .exe is built with a different set of variable names than what is used in the MotorWare proj_lab## files (gMotorVars structure).  This is because the GUI C project has a very long history, it is essentially the same main.c project that we built (and have added to) for over 2 years as we created the InstaSPIN solutions.  In fact, the project existed before the GUI Composer tool was ever created (we used the Crosshairs GUI tool originally). 

The downside to this is that this project does not comply with the public MotorWare coding standard, variable naming, and to be honest the source code is a bit of a mess.  Taking the approach of having the code identify the hardware and setting initial configurations has caused many complications (especially as we now start to release even more 3-ph inverter hardware).  And because we have not given the source project you can not re-compile with your own user.h settings (to save motor parameters and change the scaling to fit your motor).  We have also seen diminished control performance using GUI vs. the projects in certain aspects, so we take the approach of: "use this for initial demonstration of capability, but please move to MotorWare projects for deeper evaluation and testing".

The upside of course is that the GUI has quite a bit of functionality, showing off most of the features of -FOC and -MOTION in a very intuitive interface (vs. using the expressions window and making sure you have a project which has the features included) and even includes things which aren't in the projects, like the speed reversal and staircase motions as well as the graphs.

Going forward we will keep the existing GUIs as is, again for "initial demonstration of capability", but to make the MotorWare projects a bit easier to interface to we will release a "Universal GUI".  This GUI has widgets attached to the gMotorVars structure thus allowing you to take any proj_lab##.out, rename to appProgram.out, place in the GUI folder, and run the .exe

This Universal GUI will NOT have all the functionality that the existing one does and you must understand that it only interfaces to the variables active in the .out you built. Ex: just entering a new Max Duty Cycle in the GUI won't actually change the max duty cycle unless the proj_lab##.c actually uses this function: CTRL_setMaxDutyCycle(ctrlHandle,gMotorVars.OverModulation);

Regarding lab 9, it is not documented yet in the lab write-up. I think this will get completed for revision _10.  But when you load the 9.js in CCS you can see the new variables that are important:

// enable or disable the "automatic" field weakening

expAdd ("gMotorVars.Flag_enableFieldWeakening", getDecimal());

// this value will change automatically if the automatic field weakening is enabled - and it required by the
// control system (e.g. Speed_Ref > Speed).  It can also be changed manually. 
// It is only allowed - in automatic or manual mode to decrease to the maximum set in user.h
//  #define USER_MAX_NEGATIVE_ID_REF_CURRENT_A     (-2.0)

expAdd ("gMotorVars.IdRef_A", getQValue(24));

// the control system becomes more challenging during field weakening so the controllers are brought
// out to the Expressions view. You will often have to decrease the Kp_spd and increase the Kp_Idq

expAdd ("gMotorVars.Kp_spd", getQValue(24));
expAdd ("gMotorVars.Ki_spd", getQValue(24));

expAdd ("gMotorVars.Kp_Idq", getQValue(24));
expAdd ("gMotorVars.Ki_Idq", getQValue(24));

// the voltage and currents should be monitored to protect your inverter and motor

expAdd ("gMotorVars.Vd", getQValue(24));
expAdd ("gMotorVars.Vq", getQValue(24));
expAdd ("gMotorVars.Vs", getQValue(24));
expAdd ("gMotorVars.VsRef", getQValue(24));

expAdd ("gMotorVars.Id_A", getQValue(24));
expAdd ("gMotorVars.Iq_A", getQValue(24));
expAdd ("gMotorVars.Is_A", getQValue(24));

Hello Chris, thanks for the explanation.

When I tried GUI Composer yesterday (in my PC with OS Windows 7), I didn't do anything to change/load the .out.

I just opened GUI Composer and I waited, and nothing was appeared in GUI Composer Window.

After tried couple of times and noticed that it didn't work, I looked for this AppProgram.out and I tried to download it using CCS (but not success).

Then I used my laptop because the first time I worked with GUI Composer, it was in my laptop with OS Windows XP (not in my PC).

And it worked!

And then I did trying and renaming one of my proj_lab##.out to AppProgram.out in hoping I could bypass the ID process (but the GUI Composer didn't work, of course :D )

So, my question here, has GUI Composer been tested in Windows 7 before?

About lab 9, when working using GUI Composer, indeed I could run my motor more than its maximum RPM (more than 1725 RPM - for Marathon motor 5K33GN2A).

But when I ran the motor using lab 9 (with field weakening enable) from Motorware, I could not run my motor even to reach its maximum RPM. It ran well only until 1550 RPM.

In user.h, this line is defined.

#define USER_MAX_NEGATIVE_ID_REF_CURRENT_A     (-2.0)

Did I miss something here?

Thanks for your help.

Maria,

I use Windows 7 x64, and that is the primary testing platform for the GUI Composer product, so that should not be the issue.  Let me send this to the GUI C team to see if they have ideas.

"And then I did trying and renaming one of my proj_lab##.out to AppProgram.out in hoping I could bypass the ID process (but the GUI Composer didn't work, of course :D )"
This is not expected to work. As explained, the current GUIs (InstaSPIN_MOTION_F2806xM.exe, InstaSPIN_FOC_F2806xM.exe) only work with the appProgram.out provided.  If you use a MotorWare built .out none of the variables will connect to widgets.

The default limitation in both the GUI project and the user.h for MotorWare is USER_MAX_NEGATIVE_ID_REF_CURRENT_A  (-2.0)

When using the GUI you have access to increase this limit (make it a higher negative current).  Did you change this to allow more than 2A of field weakening when using the GUI?

What value of Id did you use in the GUI to achieve max speed? What value of Id in the MotorWare project?

The next thing to check would be the maximum duty cycle. In the GUI we used a different SVM which could be adjusted up to a scaling of 2.0.  In MotorWare version _09 we moved to a new SVM which for overmodulation goes up to a maximum value of #define USER_MAX_DUTY_CYCLE        (1.309401076758503)   which is the default in the user.h, so you should be at the peak of our voltage utilization, but do check this value.

Are you using the same bus supply voltage when working with both projects?

Other than that there is no reason not to reach the same maximum speed.  You could be off a little due to different tuning on the controllers, but it would be a very small amount, not like what you are seeing.

Hi Maria,

We tested GUI Composer on both Windows XP and Windows 7. 

Is the GUI app that you have on the Windows 7 machine coming up blank? Can you please attach a screen capture of the app here?

Also, are you able to load the .out file using CCS on the Windows 7 machine?

Regards,
Patrick