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.

instaspin-FOC questions

Other Parts Discussed in Thread: LAUNCHXL-F28027F, BOOSTXL-DRV8301, MOTORWARE

I just started working with the TI instaspin stuff on the LaunchXL-F28027F+BOOSTXL-DRV8301.  I worked my way through some of the labs and got my motor spinning.  I have a few remaining questions:

I can’t get debugging to work in ccs6.1.  I can download code but it just sits there with the arrow on the first brace of main().  The documents mention “Real Time Silicon Mode” but I can’t find this anywhere.  What am I missing? Is this a ccs5 vs ccs6.1 issue?

The motor I am using is a 480rpm/volt 14 pole motor.  I work this out to be ~0.0179 V/Hz.  However I consistently get ~0.0107 when identifying the motor from within the instaspin gui.  It works, but why the discrepancy?

I get considerably lower top end RPM on this motor vs running with standard trapezoidal drive.  For example at 15v it tops out at ~6krpm.  It should be closer to 7000.  I reproduced this result when testing an actual propeller where I got a maximum of 1100g of thrust, but trapezoidal drive gave me ~1350g.  Is this due to the nature of the FOC?  I have not experimented with flux weakening yet, will this gain back some of this loss?

 For our application it is vital to have rapid response to commanded speed changes.  Are there any special considerations I need to make to this end?  I was thinking of adding a D term to the outer speed loop, is this possible?

  • Sorry if this sounds condescending ...

    that green arrow represents the CPUs program counter - "where it is" in the program. The CPU is halted by default after a download and reset. You need to press Play (F8 in a default setup). Then when you Pause you will see where the program is. Use breakpoints to halt at useful locations.
  • Perhaps I wasn't clear.  I understand how to debug in eclipse and have used it for many other projects.  My problem is that all these buttons (resume, step over, step into, etc) are all greyed out.  Do I need to dig into some menu or fiddle with the switches on the board?

  • Can you show us a screenshot of the green cursor near main and the state of your debug buttons?

    For me, no I had no problem with debugging working out of the box. No jumper-fiddling needed or menu-trawling needed.
  • Hmmm. When I was having this issue I was at home, now back at work, it is doing just what it should. I'll check at home again, but for now it's not really an issue.
  • For real-time variable update in the watch window, make sure that this button is pressed

    The lower top end of the motor is due in part to FOC and space vector generator (SVGEN) but it has a solution.  Inherent with FOC is the control of a motor using sine-waves.  To create a true sine-wave, the full voltage of the DC buss cannot be utilized.  With a trapezoidal motor control, the DC buss is fully switched across the phases of the motor for a whole commutation cycle thus fully utilizing the DC buss voltage, by doing this it is also more noisy at all speeds.  There is a technique called over-modulation that can be used with FOC and the SVGEN which allows the output waveforms to become trapezoidal when more voltage is needed to attain those higher speeds.  Over-modulation can be difficult to implement depending on the type of current feedback that your inverter is using.  It is most difficult when utilizing shunt resistors and very easy when using inline current sensors like LEMs or Hall sensors.

    I am assuming that you are using a BLDC motor controller designed to run model airplanes or cars.  One thing to look for is if the controller mentions that there is a phase advance programmed into the trapezoidal control.  The phase advance is similar to field weakening and will cause the motor to run faster than your DC buss would normally allow.  Field weakening with FOC will also allow the motor to spin at speeds higher than the DC buss allows and should allow you to attain speeds that you require.  Something to think about is that field weakening is controlled by increasing the magnitude of -Id current.  The spatial vector for Id current is in parallel with the field vector of the motor and creates no torque.  So by increasing -Id current, more power is lost in the motor and produces no more torque i.e. the motor will be less efficient.  I am kind of long winded here but what I am trying to say is that it is best to get the speed that you need with over-modulation first to keep high efficiency and then use field weakening if more speed is needed.

    The most acceleration possible is acquired when Iq is at the max value for the motor.  The speed PI controller is a filter which slows down this step command of Iq.  One thing that you could do is use a feed-forward option in the speed PI control.  That way your reference speed command will directly affect the Iq reference command.  To see the motor's true performance, I would remove the speed PI control and directly command Iq.  You can command a step in Iq that goes from 0 to max Iq and see if you get the acceleration performance that you require.  You could even provide a much higher Iq value than the motor is specd at, as long as it is not greater than what the inverter will allow, to have even more acceleration performance.

    -Eric

  • The motor I am using is a 480rpm/volt 14 pole motor. I work this out to be ~0.0179 V/Hz. However I consistently get ~0.0107 when identifying the motor from within the instaspin gui. It works, but why the discrepancy?
    - every motor is different and doesn't necessarily have as much flux as they claim

    I get considerably lower top end RPM on this motor vs running with standard trapezoidal drive. For example at 15v it tops out at ~6krpm. It should be closer to 7000. I reproduced this result when testing an actual propeller where I got a maximum of 1100g of thrust, but trapezoidal drive gave me ~1350g. Is this due to the nature of the FOC? I have not experimented with flux weakening yet, will this gain back some of this loss?
    - you need to experiment with over modulation (lab 10). this increases the output waveform from a sinewave (1.0) to spave vector (1.15) to trapezoidal (1.33) and will give you up to 25% speed increase. If you have any issues with this there is a new version of the over modulation technique coming in the next release of MotorWare.

    For our application it is vital to have rapid response to commanded speed changes. Are there any special considerations I need to make to this end? I was thinking of adding a D term to the outer speed loop, is this possible?
    - you need to be able to supply the current required. that's the main limitation I see often (especially if someone isn't using a battery). in these types of applications they often aren't even controlling speed, but just the Vq_Ref term directly (proportional to duty cycle / speed). Depends on your application, but it can allow for even faster accel/decal.
  • Thanks everyone for the great responses.  I have been on vacation for the past week, and will hopefully get back to this testing in the next day or two.