LAUNCHXL-F280049C: Speed controller PI calculation discrepancies

1. Convert the desired units of speed is Hz instead of rad/sec.

2. It's frequency spacing parameter between current and speed controllers gain crossover frequency.

3. Not necessary.

Hi Yanming,

I don't think you understand my question 1 correctly. I asked "Which equation is correct (for speed controller P gain -> Kp_spd) one used in the code or the one in the User's Guide?"

Could you please care to clarify this? Let me know what didn't you understand in question 1. Please see the calculation in the code  below.

Best,

Amit

Sorry for confusing you, both current and speed controllers use the series form. The speed controller bandwidth is set to a fixed value without using the motor inductance as the formula in instaSPIN user's guide. You might refer to the description of the calculation of the gain in the motorcontrolSDK instaSPIN lab guide. 

As replied to you, multiplying MATH_TWO_PI in the code is used to convert the unit of the feedback speed from Hz to rad/sec, it's not included in the formula in the guide.

The calculation gains are just for reference as default parameters for the speed controller, which may be not the better method, you should tune these parameters according to the system.

Or using the KISS principal, REM the monkey out of the call.

Brett Nourrcier said:

  Note that USER_MOTOR_INERTIA is a required parameter in this setup (whereas it was not in the MotorWare labs).

Was programmer laid off prior to completing the example InstaSpin user motors section of user.c, lab 5? Brett that was quite a WA you came up with above yet this vendor has lot more work to do in several areas of the example code. The principal behind selling LunchPads seems to have been muddied along the way. But yea I'd stick to the lab guide examples and math much as possible until they rewrite trouble shooting guide to match all the changes. For instance motor ID time wait CL1 into CL2 is not even discussed, let alone CL fine time wait but fingers tell the brain yep it's fine alright.  

#else
//#error "No vendor motor type was specified"
#endif

    }
    else
    {
        pUserParams->flag_bypassMotorId = false;

        pUserParams->BWc_rps = MATH_TWO_PI * (float32_t)100.0;
        pUserParams->BWdelta = (float32_t)8.0;

			/* Is motor intertia user.h */
        	// 3.0 * pUserParams->motor_numPolePairs * 0.1 / (2.0 * 0.00001);
        	//pUserParams->Kctrl_Wb_p_kgm2 = (float32_t)3.0 *
                //pUserParams->motor_numPolePairs *
	        //pUserParams->motor_ratedFlux_Wb /
		//(float32_t) (2.0 * USER_MOTOR_INERTIA_Kgm2);


        	/* Is not motor intertia user.h */
        	pUserParams->Kctrl_Wb_p_kgm2 = (float32_t)3.0 *
					pUserParams->motor_numPolePairs *
					(float32_t)(0.001) /
					(float32_t)(2.0 * 0.000001);


    }

I tried to add (if, else) clause to above code snip based on USER_MOTOR_INERTIA_Kgm2 being defined in user.h, CCS code analysis had a fit.

That define seems to be the switch case for vendor provided motor types Kgm2 inertia. Perhaps your programming skills can master the CCS code analysis syntax error for #define used in the if clause. There are No instructions lab5 assumes the motor is one of several vendor provided types existing in user.h. Otherwise user.c did seem to provisioned for not including kgm2 (user.h) which lab5 does not show nor instruct user to enter Kgm2 value. I find it odd LDRA analysis showed no error (user.c) yet the else error has no escape clause and code below that was unreachable without else. Not sure how that logic would every fly!

My take was the RAW inertia calculation is simply wrong as (2 * 0.000001) was fairly close mass calculation. When I entered FEM Kgm2 (user.h) the speed control was near to harm drv8320rs. Phase voltage/s took a sudden dive during deceleration of the rotor mass, was fine for acceleration curve.

GI - I commented out the entire #if …#endif section of user.c and added the following:

    if ((USER_MOTOR_INERTIA_Kgm2 == NULL)) {
        pUserParams->BWc_rps = MATH_TWO_PI * (float32_t)100.0;
        pUserParams->BWdelta = (float32_t)8.0;

        // 3.0 * pUserParams->motor_numPolePairs * 0.1 / (2.0 * 0.00001);
        pUserParams->Kctrl_Wb_p_kgm2 = (float32_t)3.0 *
                                       pUserParams->motor_numPolePairs *
                                       (float32_t)(0.001) /
                                       (float32_t)(2.0 * 0.000001);

    } else {
        pUserParams->BWc_rps = MATH_TWO_PI / USER_CTRL_PERIOD_sec / 20.0;
        pUserParams->BWdelta = (float32_t)8.0;

        // 3.0 * numPolesPairs * rotorFlux_Wb / (2.0 * J_kg_m2);
        pUserParams->Kctrl_Wb_p_kgm2 = (float32_t)3.0 *
                                       pUserParams->motor_numPolePairs *
                                       USER_MOTOR_RATED_FLUX_VpHz /
                                    (float32_t) (2.0 * USER_MOTOR_INERTIA_Kgm2);

    }

This seems to work fine.  

Brett

The problem partially was I had REMed out define versus assigning USER_MOTOR_INERTIA_Kgm2  (NULL) in user.h. Now code analysis warns divide by zero for the NULL in the (if) test. It seems a bool such as  (pUserParams->flag_bypassMotorId == true) would work better since we have to set it false (user.h) to ID our motors, it may have been false by default. At least for the vendor provide motor parameters it seems the ID wait times are not used or required.  

//! \brief A flag to bypass motor identification (1/0 : true/false)
//!
//#define USER_BYPASS_MOTOR_ID       (1)    // No motor parameters identification
#define USER_BYPASS_MOTOR_ID       (0)    // Do motor parameters identification

Have they implemented dynamic decoupling of the PI  Current controller?

Per my understanding they have not or I may be missing something here. PI current controller has been implemented with saturation values based on max motor current specified in file user.h (#define USER_MOTOR_MAX_CURRENT_A).