MotorWare updated to version 15

You have not included in this new version, a lab with IPD_HFI and speed loop control. Are you going to do later?

Thanks

Javier
To be honest, probably not, but it remains on our "to do" list.

The IPD_HFI while good in theory is proving to be very difficult to get working with the vast majority of motors that are normally available (low saliency). It only works with very high saliency machines which typically have to be custom designed. On top of this - even with high saliency machines - as soon as you start pumping in large currents that saliency effect - and hence the IPD_HFI ability to estimate the rotor flux angle - diminishes. Due to these challenges, we don't see this solution being as effective for a large number of customers, so we are deprioritizing additional example projects.

1.It’s strange that why TI don't care any code example about communication(ecan、sci、spi) In motorware framework? I think many customers need this.

2.whether the bug about usDelay function (It was not accurate before) has been fixedor not ?

1. I agree that MotorWare is not as complete as it should be when it comes to the communications drivers. We are working on documenting how best to use the examples in controlSUITE.

2. I don't see any bugs filled on "usDelay" in our system. Can you point me to some information on this error?

 "usDelay" bug：

http://e2e.ti.com/support/microcontrollers/c2000/f/902/t/357840

 I have done a test before,it was not accurate.

I wasn't aware of this bug, it was never tagged for MotorWare. Let me look into it...
it appears that the main problem is that it doesn't take into account the user.h #define USER_SYSTEM_FREQ_MHz since it came from the controlSUITE version of the code.

did you try the workaround suggested?

There is a minor issue with MW 15
user.h default settings.

It ships with
#define USER_MAX_VS_MAG_PU (2.0/3.0)

but any value > 0.5 should only be used if you are using the overmodulation technique in proj_lab10

It is recommended to change this to
#define USER_MAX_VS_MAG_PU (0.5) // only use 0.5 < MAX_VS_MAG_PU < (2.0 / 3.0) if using SVGEN_CURRENT from proj_lab10

and use the gMotorVars.Overmodulation variable when using proj_lab10 to increase the modulation up to 0.66

There is a minor issue with MW 15
proj_lab10 (a/b/c versions)

Problem: CTRL hangs at EST_STATE_RsRecalc if system is enabled with RsRecalc flag enabled

Fix for MW 15:

in proj_lab10a.c
Currently:

{
int16_t minwidth = SVGENCURRENT_getMinWidth(svgencurrentHandle);
SVGENCURRENT_IgnoreShunt_e ignoreShuntNextCycle = SVGENCURRENT_getIgnoreShunt(svgencurrentHandle);

// Set trigger point in the middle of the low side pulse
HAL_setTrigger(halHandle,ignoreShuntNextCycle,minwidth,gCmpOffset);
}

Change to:

if(gMotorVars.EstState == EST_State_OnLine)
{
int16_t minwidth = SVGENCURRENT_getMinWidth(svgencurrentHandle);
SVGENCURRENT_IgnoreShunt_e ignoreShuntNextCycle = SVGENCURRENT_getIgnoreShunt(svgencurrentHandle);

// Set trigger point in the middle of the low side pulse
HAL_setTrigger(halHandle,ignoreShuntNextCycle,minwidth,gCmpOffset);
}


Root cause is something in the new HAL_setTrigger function. This will be fixed for MW 16.

I can only "make up the number" to get the time what I need.

Actually,usDelay (1) does not equal 1us,I have done a test,if I want to get 1us,I have to set usDelay (15) . I used 28069M running at 90MHz.

Another problem: Look at the MotorWare Module API Documentation

We can see usDelay(ADC_DELAY_usec) in HAL_AdcCalConversion().

Because usDelay () is not accurate,the time for converting ADC channels is not accurate.I feared it may impact performance of ADC.

we will look at this usec delay issue for MotorWare 16.

Hi ChrisClearman,

Whether your MotorWare team plan to add HAL for F28335 (floating point DSP) to the next version of MotorWare or not?

Beside I'm a beginner with MotorWare, although I was familiar with ControlSuite for 2 years. But I think that the way to set bits in a register in MotorWare is not efficent in the ControlSuite.

I hope while using the Motorware I will have more info to ask your team.

Thank you for your listening.

Tran.

Sorry, MotorWare is only for InstaSPIN-FOC and InstaSPIN-MOTION development, which will not be made available on F28335.

Dear ChrisClearman,

Thank you for your reply. But where your team can make more examples or write documents in order to help users to use API functions more easily? Because I used ControlSuite in which I can develop my project for controlling motor from low level (open-loop) to high level (full vector control). While in MotorWare the labs is designed so compicated, it's difficult for users (as me) when Lab02 demotrated the full vector control.

Beside I read the document named "InstaSPIN-FOC and InstaSPIN-MOTION User's Guide" some section, such as: Sensored System, Adding System Functions, Building Your InstaSPIN-FOC and InstaSPIN-MOTION board and so on, is not completed.

I also see the modules, such as: CAN, QEP... is not completed.

I hope MotorWare's users will be received a new update soon.

Tran.

Tran,
In MotorWare you can view proj_lab11, which is a simplified version. Essentially it inlines the run-time forward control which is normally in the CTRL functions in the library. This gives a more similar flow to the controlSUITE projects where you can see each piece of the control loop called.

We purposefully went away from controlSUITE style for InstaSPIN because we needed to make the entire system more automated. To do that, you give up some flexibility. We are now trying to find a nice middle ground for the experts who would like to use our FAST observer but don't want to use the control system as we have written.

Regarding peripheral modules / drivers, you are correct. This has been a big gap and unfortunately not something we are going to finalize to our goal. We will be publishing shortly some documentation that explains how to use the controlSUITE drivers and peripheral examples with MotorWare.

Dear ChrisClearman,

Thank you for your guiding. But the proj_lab11 is only available for F28069F while currently I have my own board that is built based on F28054F. On the other hand, when I complied the proj_lab11, I got 03 errors as the following figure:

Whether you can help me to porting this project in order to work with F2054F or not?

Thank you so much in advance,

Tran,