DSP inline PI ld/lq modules.

[GI101]

Hello all,

Was there some reason DSP omits ld-PI/uq-out and lq-PI/ud-out inline modules? I have checked arm_math.h and they are not included. Clarke Park transforms appear to be useless without some way to separate the frame controls prior to uq/ud inputs into InversePark. Hence an immediate road block stops any further development without these two modules.

The hope was DSP transforms can help to migrate our 6 step code over to SVPWM on an existing ARM migration path prior to leap onto M7 Cortex. That requires new hardware to support package pin layouts. Regrettably TI has no plans of improving TM4C129x MCU class with M7 core embedded Clarke/Park transforms. Yet the ROM space exists on M4 as other vendors now provide similar embedded transforms M7 cores. The inverter system is HV so there are caution signs all over.

Ideally it would be acceptable to obtain similar transforms from ARM for testing purposes only on the M4 core. We tested the C2000 TI embedded FAST estimator but the CPU lacks the power ARM Cortex provides. Again current DC inverter hardware also being the gap band of upward mobility to newer CPU classes.

Regards,

[christophe0606]

There is no specific reason. This part of the library needs improvements.

[llefaucheur]

Hi GI101, which APIs of the Digital Motor Control software library do you have in mind ? Regards, Laurent

[GI101]

Hi llefaucheur, Now it can be like NXP has put to ROM on M7 cores, below. Cypress uses the PI-uq/ud inline but NXP method also seems good. Some kind of M4 slow speed startup observer could help too. The M4 6 step FOC startup handler currently uses open loop commutation based on a repeating 5 code pattern. Ideally like to merge SVPWM into the existing ADC modules for GUI controls being high voltage system. The sector tables are already built but need to control the PWM vectors more precisely. Thanks for any suggestions how M4 can take advantage of M7 DSP codes.

[llefaucheur]

Hi GI101, I am reading MPC574 documentation for inspiration to your question... but as "human compiler for Cortex-M" I would prefer reading the mathematical equations you have in mind, or equivalently a Matlab/C model instead (we are not expert in motor control but top-notch in math & algorithms :-)). I promise you, motor control library is on our radar, but not on short-term. Regards, Laurent.

[GI101]

Hi llefaucheur, I had assumed you had a library on hand from the littoral of your first response. I have the older motor ware modules TI is no longer supporting theses packages. Some modules already have ties to use #define=CMSIS arm_math.h. I don't believe there are any export issues to France and can PM the folder of SVM modules in zip format. It has 2012 Park/Clarke transforms, PI controller and several others may add into DSP after any updates are made. With regards

[GI101]

This figure is the TI model and the FAST estimator speed angle observer is embedded into ROM. FAST has slow speed observer built in and angle can be forced to 90°, <1Hz rotor speed. FAST is proprietary but the rest was likely hijacked or modified from DSP examples from the looks of it.

[GI101]

They all copy the same basic layout and Cypress has nice structure even shows the modified signals.

[GI101]

SPM motors don't necessarily need a position input for sensorless commutation as cypress/TI models indicate. The rotor position is determined by reading the ADC phase current samples Ia,Ib,Ic into Clarke as to determine the flux angle or magnetic Nth pole of rotor magnets. Once application knows the space vector starting point it is used to drive specific sectors of the NFET drive tables. AKA SVPWM in a closed loop monitored and controlled by the PI speed handler. Sound simple but the math timing of the loop in 50µs 20Khz is somewhat complex.

[christophe0606]

The PID controller in the CMSIS-DSP library cannot be used for your needs ?

[llefaucheur]

I suppose we miss the arcsin function of equation (2.21) in this reference