DRV8301-69M-KIT: Unstable Operation at High Speed/Current

Matt Meier said:

When I run the motor at the desired current, 20Apk, and reduce the load, the motor runs well until we reach ~400Hz.

Hi Matt,

400 hertz = 24000 RPM by conversion, is that really the speed and 550Hz = 32,999 RPM? What you describe sounds like modulator nears 100% duty cycle in sine wave modulation.

Matt Meier said:

become non-sinusoidal, with significant harmonic content

Perhaps how dead band was configured in SDK labs, one thought directly involves harmonics? PWM-A if used to for drive B and drops PWM-B drive seemingly relies on drive A for B duty changes too. Seemingly may invite dead band imbalance into duty updates as well, perhaps proves more reliable? The ePWM module we use now does not support individual channel dead bands, which brings up another point.

Perhaps dead band delay setting is a bit to fat for NFETS turn off speed? May also effect the minimum pulse width and PI speed achieved in some SW.   

Sorry...I wasn't clear.  400Hz is the electrical frequency.  We're trying to target 550Hz electrical frequency.

I haven't done precise calculations, but we should have lots of overhead with the modulation index.  We're feeding the inverter with ~24Vdc right now.  Assuming the controller is driving only q-axis current, the phase voltage should be a little under 5Vpk l-n.  Just before the problem starts, the modulation index for each phase is around 0.18 max (I plotted it in the controller), so that roughly matches the calculated value.

I thought about the deadband, because at lower speeds and currents I can see the characteristic flat spot in the phase current around 0A.  However, I'm not sure I understand what you're saying about the duty changes.  Regardless, we can't reduce the deadband.  In the labs, it's practically eliminated.  It's set to 11ns in the lab I'm using, at 1 digital count on the 90MHz clock.  The DRV8301 deadband pin is connected to ground through 1Ohm on the board, so the gate driver is providing 50ns.  We're operating at 30kHz, so that's less than 0.2% of the PWM period, so it should be insignificant.  On the other hand, the DRV8301 does seem to have an advanced automatic deadband insertion scheme.  I haven't deciphered this yet because it's not clear in the datasheet, but perhaps this automatic insertion scheme is kicking in and, at higher currents, is causing an imbalance.

Besides all that, if we can't adjust the deadband correction then at least I can increase the deadband to a known value and correct for it.  I'm adding a tunable correction factor to each phase.  I'll see where that gets us.

Thanks,

Matt

Matt Meier said:

400Hz is the electrical frequency.  We're trying to target 550Hz electrical frequency

Again rotation angle frequency of transformation relates to rotor speed in some way, otherwise why increase the frequency? What is the direct relationship between frequency and rotor speed, does it get any faster as you increase electrical frequency.

Matt Meier said:

Assuming the controller is driving only q-axis current, the phase voltage should be a little under 5Vpk l-n

That seems contrary to SVPWM transform theory as each sector relies on rotation angle based on both d & q occurring synchronously. If that is untrue I have not read TI PDF explaining a new and separate method of determining rotation angles based on q transforms working independent of d. Reviewing labs in newer SDK It seems certain ROM calls have update capability via driver lib header files. So it might be wise to update older control suite motorware for good measure. 

You didn't answer the question what rotor speeds both issues occur, no rotor speed possible in the InstaSpin GUI? Only 5 phase SVPWM documents issues with dead band harmonic imbalance, where A phase is always on or off. According to text 7 phase SVPWM is free of dead band harmonics but again perhaps it depends on how dead band is implemented via SW or HW control of it. 

Are you using the BoostXL-DRV8301 FOC Sensorless with either PMSM or BLDC motor, Kit includes a motor?

Matt Meier said:

The DRV8301 dead band pin is connected to ground through 1Ohm on the board, so the gate driver is providing 50ns. 

It's been some time to review DRV8301 driver BoostXL technical brief though unless GAN drives 50ns seems very short RED/FED. GANS boast 20ns if memory serves, little to no Trr recovery time is required.  There is difference between propagation delay and dead band delay, BoostXL-DRV8301 technical brief engineer may have used the word delay in an off hand way. Even the 60v 40 amp NEXFET (CSD88599Q5DC) Trr 36ns Max, run very cool.

What DC bus input voltage is applied to the DRV801 kit?  You may find the following code in updateGlobalVariable(), and add the gMotorVars.Vs to watch window to monitor if its value is close to USER_MAX_VS_MAG_PU (in user.h). If yes, that means the dc input voltage is not enough to run up to high speed for the motor, you have to increase the dc bus voltage that must be less than 60V (the maximum input voltage of the DRV8301 kit), or need to apply the field weakening control as lab09.

// read Vd and Vq vectors per units
gMotorVars.Vd = gVdq_out_pu.value[0];
gMotorVars.Vq = gVdq_out_pu.value[1];

// calculate vector Vs in per units
gMotorVars.Vs = _IQsqrt(_IQmpy(gMotorVars.Vd, gMotorVars.Vd) + _IQmpy(gMotorVars.Vq, gMotorVars.Vq));

Sorry for the delay.  I'm back from break now.

I tried implementing deadtime correction in the software.  It does eliminate the characteristic signs around 0A at low speed and low current, but it does not help the problem.

I also changed the voltage feedback filters (and adjusted the value in software), but this also did not affect the high current or high speed operation.

Gl,

400Hz electrical frequency is equal to 4800rpm.  It's a 10-pole permanent magnet motor.  The estimated speed in the software is accurate until the estimator starts to fall apart.  After that, the speed reported by the estimator is way off.  We aren't using the GUI, but I can see it in the debugging window.  I know it's incorrect because I can calculate the real speed from the current waveforms on an oscilloscope and I can also use a tachometer on the shaft.

The Ti software in Lab 11 is using fast-decoupled current regulators.  The PI controller for the d-axis current regulates the q-axis voltage, while the PI controller for the q-axis current regulates the d-axis voltage.  I'm not sure if you are trying to tell me that they are actually coupled, but I agree that they are not truly 100% decoupled.  However, we're commanding Id=0A and Iq=20A in the software.  If we assume the angle is correct and these two quadrature currents are true, then we need approximately 5Vln peak phase voltage, at an angle of 36° with respect to the rotor.  I get this from drawing the phasor diagram for the machine at this operating point, assuming the 20A phase current is aligned 90° with respect to the rotor.

We are using the DRV8301 EVM kit with an F2806x ISO control card.

I'm pretty sure the section of the datasheet I read was referring to deadband time, to prevent shoot-through.  Based on the MOSFET datasheet for the devices on the board, I think 50ns, the setting based on the 8301 EVM resistor, is sufficient.

Yamming,

I am using 28V right now.  gMotorVars.Vs is 0.13 at 400Hz and 20A, right before the controller stops working.  USER_MAX_VS_MAG_PU is set to 0.5 in user.h.  We should have lots of overhead.

Thank you again,

Matt

Matt Meier said:

400Hz electrical frequency is equal to 4800rpm.  It's a 10-pole permanent magnet motor. 

So this equals 5 pole pairs in software? I have 24vdc Nidec 12 pole motor, it tops out near 6300 RPM via 20-40KHz trapezoidal commutation. Our large 36 pole SPM low end 142VDC >1800 RPM 8 amps as comparison can achieve greater speed by raising voltage. Oddly motor current has very little to do with volt Weber/sec being almost directly proportional to increased speed. I personally believe motor current is more about torque moment than it does speed.

Matt Meier said:

I am using 28V right now.  gMotorVars.Vs is 0.13 at 400Hz and 20A, right before the controller stops working. 

Check If your 10 pole motor produce pure sine wave when disconnected from kit, spin by hand scope two phases. If the sine peak tops are flat there may not be enough positional information for SVPWM to select correct d/q sector angles, especially at low or very high speeds. Another way to find out is to use FOC trapezoidal wave form to drive the same motor to compare the results. I can PM you some info about our own venture system if you like. Alternative is to slowly raise motor voltage as it proportionally reduces motor current and increases rotor speed.

Yes, this means 5 pole pairs.

The back EMF is very sinusoidal.  It has ~1.7% THD.  When I don't ask for more than 20A, I get very clean current waveforms.  It's only when I ask for more current, regardless of the motor speed, that we see the estimator get lost.

At this point, I believe we're fighting two different problems.  First, I can't exceed 20A at any speed without the system behaving badly.  Second, the system behaves badly above a certain speed at any level of current.

For now, I'd like to attack the first problem (the apparent 20A limit).  Right now, I have a machine with the following parameters:

Ke = 0.001V*s (in rad/s, not Hz)
Lph = 86uH
Rph = 8.6mOhm

I'm using a 28V bus and the phase current at 1,000rpm is stable up to 20A.  Above this it looks bad and the estimator angle does not track well (although it does not seem to be slipping poles).

If I reduce the voltage to 14V then I am limited to approximately 15A before the software has trouble.

Matt

Matt Meier said:

The back EMF is very sinusoidal.  It has ~1.7% THD.

Disconnected from controller, it does matter the method. The Vmotor divider filter can alter the motor EMF roll off the edges via the RC time constant.

Matt Meier said:

I'm using a 28V bus and the phase current at 1,000rpm is stable up to 20A.

How many amps is the SMPS ? power supply rated safely deliver ripple free at 28v/20A? Perhaps try 30v Lithium battery pack to see if symptoms improve. 

Matt Meier said:

Right now, I have a machine with the following parameters:

Helper have no idea about your machines maximum voltage specification only that DRV8301 60v/40A with certain NexFETS. 

Gl said:

Disconnected from controller, it does matter the method. The Vmotor divider filter can alter the motor EMF roll off the edges via the RC time constant.

We measured this with an oscilloscope, disconnected from any filters or electronics, line-to-neutral.

GI said:

How many amps is the SMPS ? power supply rated safely deliver ripple free at 28v/20A? Perhaps try 30v Lithium battery pack to see if symptoms improve. 

We aren't using a switching supply.  We have an unregulated power supply fed from a wall transformer and a rectifier.  The power supply is rated for ~10kW, and at 1,000rpm and 20A, the electrical power (measured into the DC bus) is 13W.  The DC voltage ripple is ~1%, or 0.25V.  I measured this with an oscilloscope and can log it in the software on the C2000.  I can see the difference between the analog data and the DC voltage in the estimator.  I thought this might be the source of the problem, but I can change the DC voltage compensation from the estimated value to the measured value, and this doesn't help.

The rated voltage for the machine is 8Vll,rms at 6500rpm and 14Arms.

Matt

BTW: The biggest problem with linear transformers in general is voltage can sag. The torroid 118vac line idles around 170vdc. As motor accelerates dc quickly sags under load even rated for 20A and several electrolytic caps about. I like it on days when AC line voltage is 5v higher so motor goes 50 rpm faster - lol.     

I accidentally clicked that this was resolved when I went to reply, but I can't figure out how to undo that.  Can a moderator fix this?

8Vll is 8V line-to-line.

The 28V is our DC voltage from the power supply, not the phase voltage.  It's a variAC and rectifier, so it has changed over time as I have turned it on and off.  I'll keep it fixed at 28V from here on.  I'm not sure where 13W came from...it's a typo.  It's drawing ~90W from the power supply with almost no ripple at 6500rpm and 20Apk, which provides 125mNm.

It's not a voltage sag problem.  Suppose the line did sag by 20%...our 28V supply would now be 23V.  That wouldn't affect our motor at all because we're not using the entire available DC voltage.

But, to reset the issue, we seem to have two separate problems.  First, we can run the machine at 1000rpm and request 20Apk of phase current, and it runs well.  I can reduce the load and the motor accelerates with the same current command up to ~6500rpm, where the controller falls apart.  I suspect this is more related to the current regulators, noise, and the measurement filters than anything else, because there is a very rhythmic oscillation and an occasional DC offset.  I don't need to go this fast right now, so we can put this on the back burner and I'll do some work on my own to try and solve this one later.

Second, and this is the open issue that puzzles me the most:  We can't get more than 20Apk at any operating point.  I can set the current and load to run at 20Apk at 1000rpm, 2000rpm, 3000rpm, etc.  It works just fine.  BUT, if I ask for any more current then I run into trouble.  Let's use the 1000rpm and Iq = 20Apk (Id = 0) for our discussion.

As soon as I request more than 20Apk, the phase current waveforms fall apart with significant and inconsistent distortion, the estimated phase angle does the same, and the motor vibrates and emits significant audible noise.  It seems as though the estimator just gets lost and can't recover until I reduce the current demand.

Matt

Matt Meier said:

accidentally clicked that this was resolved when I went to reply

I've done that a few times after they revoked the ability to clear green of our own resolved. Like the caps lock key next to letter "A", rocket scientist are to blame - lol.

Matt Meier said:

The 28V is our DC voltage from the power supply, not the phase voltage.  It's a variAC and rectifier, so it has changed over time as I have turned it on and off. 

We see nearly the same peak bus voltage on the inverter legs and phases even during run time, phases reflect DC bus voltage. 

Matt Meier said:

We can't get more than 20Apk at any operating point.

Well that would depend on rotor load in most 3 phase systems as the duty cycle reacts to motor load, PI control settings and peak current cutoff point. The motor can not be commanded to source more DC current than synchronous flux requires to keep torque slip from entering closed loop or rotor loading. We used a 10KW AC generator as a effective dynomometer to see such gremlins. Most software can set the peak cutoff point 20A (trip faults) or even allow for an acceleration current threshold where duty cycle is then reduced. So I'm a bit unclear why you need more than 20A for various rotor speeds or your leaving out some details of the experiment. There is the NexFET peak current safety margin to consider as well - typically recommend half the peak. 

If your trying to improve the low end acceleration curve the new SDK has 3rd party tools that help to make finer PI adjustments. Anyway it sounds like the power supply is struggling to produce >20A and may trip 20A panel breaker. If memory serves formula to calculate AC fuse, secondary IDC x 1.39 results in AC line fuse size. Do you have an inline series current meter on the low side? There are several 50A - 100A digital add on that can be used as secondary monitor to verify. 

/cfs-file/__key/communityserver-discussions-components-files/171/Hammond-Transformer-_2600_-Rectifier-design-guide.pdf

We want more current because we want more torque headroom.  We hit the limit of stable operation at 20Apk in the lab, but I'm not confident that this limit will remain fixed in the real world.  It also indicates that there's something wrong with the controller because it is struggling to inject an amount of q-axis current that should be well within the controller's capability for this motor at this DC voltage.  We saw this once in the past with the Ti system, but the customer abandoned the Ti software and wrote their own.  I started a discussion on this same problem many years ago, but when the customer dropped the estimator we stopped trying to solve the problem.  Unfortunately, I can't find that old thread, and since this is a new motor and new project I thought it was reasonable to just start over again.

Gl said:

We see nearly the same peak bus voltage on the inverter legs and phases even during run time, phases reflect DC bus voltage. 

I understand this.  When I mention the AC phase voltage, I'm talking about the fundamental component at the electrical frequency of the machine, and not the instantaneous phase voltage at the PWM frequency.  The DC bus voltage will, I agree, always be applied directly to the windings.  I also agree that the DC bus will affect the duty cycle of the PWM waveforms, which is what Yamming was getting at, but that shouldn't affect the controller's ability to drive current.  I can turn the voltage up and down, and the behavior remains unless I really start to drop the voltage.  If I do that then the "fall-apart" current is lower.

Gl said:

If your trying to improve the low end acceleration curve the new SDK has 3rd party tools that help to make finer PI adjustments. Anyway it sounds like the power supply is struggling to produce >20A and may trip 20A panel breaker. If memory serves formula to calculate AC fuse, secondary IDC x 1.39% results in AC line fuse size. Do you have an inline series current meter on the low side? There are several 50A - 100A digital add on that can be used as secondary monitor to verify. 

We aren't going to blow anything  The variAC/rectifier combo is huge, and it's plugged into a 240V AC line with a 30A breaker.  We're drawing fractions of an amp rms on the AC input, although I imagine we would see the classic rectifier surges on the output of the variAC.  The average DC link current between the power supply and the Ti board is less than 4A, depending on the operating conditions (and where I set the variAC dial that day), and the DC link is not fused.  20Apk is just the phase current of the motor, which is not fused.

Just for sanity's sake, I put a couple golf cart batteries together and ran the motor again.  While the DC ripple has completely disappeared, the problem remains.

I want to thank you again for all the time you're spending on this.  I know it's difficult to troubleshoot something when you're not present.

Matt

Matt Meier said:

Just for sanity's sake, I put a couple golf cart batteries together and ran the motor again.  While the DC ripple has completely disappeared, the problem remains.

Smart move to eliminate the AC power source just to be sure. What is/are the phase resistance

Matt Meier said:

20Apk is just the phase current of the motor, which is not fused.

When you say command 20A it's not the actual measured phase current rather user.h max fault trip point, right? I would suspect motor control software has configured DRV8301 for NexFET peak phase current <20A even though 40A peak possible. Perhaps you can increase the DRV8301 gate drive current, DRV forum may have some suggestions. It sounds like the NexFET has to little gate drive current to push >20A ID, if that is what has actually measured on the phases at each RPM.

I don't easily vision motor reaching >20A phase current 4A verified via 220vac. It sounds like the gate driver monitors trip fault minper order to protect DRV8301 from going above an arbitrary 20A. Fault minper where PWM drives are CBC interrupted by a set amount of delay time, until the current load has been removed, CBC minper remains asserted. I have not reviewed the older control suite SW in some time. The newer SDK (TMS320F280049c) has 3 inbuilt PGA feed into 3 CMPSS into 3 ePWM trip zones and DRV8320RS has single fault output for CBC OSHT into 49c Tz2. It might be worth the investment to update to the newer 100Mhz launch pad.

Matt Meier said:

I started a discussion on this same problem many years ago, but when the customer dropped the estimator we stopped trying to solve the problem.  Unfortunately, I can't find that old thread, and since this is a new motor and new project I thought it was reasonable to just start over again.

So the customer got the motor >20A peak phase current using their own software or some other modulation technique? Many variables exist in that discussion.  

Gl said:

When you say command 20A it's not the actual measured phase current rather user.h max fault trip point, right? I would suspect motor control software has configured DRV8301 for NexFET peak phase current <20A even though 40A peak possible. Perhaps you can increase the DRV8301 gate drive current, DRV forum may have some suggestions. It sounds like the NexFET has to little gate drive current to push >20A ID, if that is what has actually measured on the phases at each RPM.

20A is the value in gIdq_ref.value[1], which is the q-axis current command.  It is also the peak measured phase current, measured with a current probe on the motor leads.

What you say about not having enough gate drive current to push 20A doesn't make sense to me.  MOSFETs don't have gate current, at least any appreciable amount...the gate driver needs to supply the turn-on and turn-off charge, and The FETs turn on just fine up to 20A of phase current.  What am I missing?  Are the power devices not normal MOSFETs?

On the other hand, if the DRV chip is tripping, like you mentioned below, then that could definitely cause the estimator to get screwed up.  I don't know how the DRV8301 is communicating faults back to the 28069.  There isn't any obvious setup in the software, and there's no update in the main loop except for the gate lines.  I'll look into this.  I can run a simple experiment where I drive DC current though the bridge and see if there's a problem after 20A.

Gl said:

I don't easily vision motor reaching >20A phase current 4A verified via 220vac. It sounds like the gate driver monitors trip fault minper order to protect DRV8301 from going above an arbitrary 20A. Fault minper where PWM drives are CBC interrupted by a set amount of delay time, until the current load has been removed, CBC minper remains asserted. I have not reviewed the older control suite SW in some time. The newer SDK (TMS320F280049c) has 3 inbuilt PGA feed into 3 CMPSS into 3 ePWM trip zones and DRV8320RS has single fault output for CBC into 49c Tz2. It might be worth the investment to update to the newer 100Mhz launch pad.

I don't  understand what you mean about the phase current, 4A current, and 220V, but it's moot because the battery system didn't help.  We don't want to change anything if we don't have to.  If it's the MCU frequency, we're running at 90MHz already.  The EVAL kit has huge transistors...is there a new LaunchPad that can handle more current than the kit we have?  I'm OK if the official Ti stance is that this EVAL kit isn't good enough for this motor, but I'd like to know why the other kit is going to fix the control software.

Gl said:

So the customer got the motor >20A peak phase current using their own software or some other modulation technique? Many variables exist in that discussion.  

On that project, as we increased the current, the controller eventually fell apart at around 50Apk on a custom inverter.  We also ran the motor with the same eval kit we have now, but I can't find any measured data above 14Apk indicating the maximum current.

Matt

I found the old forum posts that pertained to our previous project.  Unfortunately, we never investigated the phenomenon where the controller falls apart above a certain level of current.  We must have encountered that just as the customer was moving on, and didn't get far enough to try and work through the problem with Ti.

I was able to do two tests with the DRV8301-69M-KIT.

1.  I adjusted the individual half-bridge duty cycles to inject 40Adc into one phase with the other two set at 50%.  For good measure, I checked to make sure the other two phases shared the current evenly.  I did this for +40A and -40A on all three phases.

2.  I attached a passive RL load and applied a 3ph 550Hz 40Apk sinusoid.

The kit seems fine in both these tests; it doesn't appear that the DRV8301 chip is faulting or struggling in any way.

Another thing I should mention is that, in the past, we've run into feedback problems messing up the estimator.  However, I've plotted the current just below the fall-apart point, and it doesn't appear that the feedback to the C2000 is especially noisy.

Matt

Matt Meier said:

What you say about not having enough gate drive current to push 20A doesn't make sense to me.  MOSFETs don't have gate current, at least any appreciable amount...the gate driver needs to supply the turn-on and turn-off charge, and The FETs turn on just fine up to 20A of phase current.  What am I missing?

Food for thought:

NFET requires certain gate drive (current) at a specific voltage to quickly reach the Miller plateau (Qgs1-2) and finally enter transconductance much like saturated switch. When gate drive current is set to low (DRV8301 registers) t3-t4 can peak late for certain Qg value of NexFET. When the drain voltage VDS peaks above BVD so do destructive IAS periods occur. To many avalanche periods can lead to shorter life and eventually failure. The flat tops are the clue that repetitive or periodic avalanche is occurring.

Matt Meier said:

I don't  understand what you mean about the phase current, 4A current, and 220V, but it's moot because the battery system didn't help. 

What was the current draw from the batteries? If was again 4A something is not as it should be. I would expect >18A drawn from 36v batteries? The 4A varia seems very low for 20 peak phase current. Stepping down 240VAC with variac on XFMR secondary seems a bit odd if not some how also inviting 3rd harmonic gremlins. That issue mostly depends on motor winding type being WYE or Delta often used to gain increased speed. 

I apologize...I didn't know you were going that deep with the gate drive current.  Still, it's not something that would manifest itself at 22A but not 20A.

I don't think the gate drive current is the problem.  First, I think we should be able to assume that this demo kit was reasonably well designed.  If the gate driver was that weak, and the transistors were avalanching, I doubt I'd be the first one to notice.  Second, I was able to drive 40Apk into a passive load without any apparent problems.  If there's a specific reason you disagree and still think that this is a gate drive problem then, I'm open to it.

I think I can take another step toward eliminating the gate drive circuit from this discussion.  I'll write some software that lets me bypass the main controller and lock the frequency and phase voltage.  I can use the regular controller to get close and then slowly adjust the phase voltage and load to get more than 20Apk.  If that works, we can eliminate the evaluation kit power electronics as the source of the problem.  Agreed?

The battery bank was nominally 30V.  It measured 32V at the inverter when the motor was running.  When I ran the motor at 1000rpm, I got less than 1A.  I didn't record a trace and I've gone back to the variAC because we need the battery bank elsewhere.

There's nothing wrong with that current.  Why do you think we should be seeing over 18A on the DC line?  Can you share your math?  If we take 18A out of a 36V battery, that's 650W into the inverter.  At 1000rpm and 0.125N*m, that's 13W out of the motor.  Even at 6500rpm, that's still less than 90W.  Where is the rest of that power going?  The inverter isn't getting hot, and neither is the motor.  If we had 550W of loss split between the inverter and the motor we would know it.

Matt

I can step the motor up to Iq = 30Apk in open-loop.  I played around with the voltage amplitude to until the current was minimized, indicating I was properly aligned.  It took a few tries because if I went too far the rotor would slip a pole and then stall out, but I'm pretty sure we have good q-axis alignment.

I should mention that I've increased the speed of these tests to 2000rpm so I get more flexibility in the load.  I only made some quick load adjustments, so the motor was actually running at around 2500rpm instead of 2000rpm.

So, I really don't think this is a problem with driving the power electronics but I'm not sure what else to look at.  It's kind of a chicken-egg scenario.  I don't know if the estimator fails first and then the regulators, or the regulators aren't keeping the current steady and then the estimator falls apart.  I've tried huge ranges in the regulator gains, but that doesn't do much for what I'm seeing.

Matt

Matt Meier said:

Second, I was able to drive 40Apk into a passive load without any apparent problems. 

Hardly believe motor achieved anywhere near 40A input power as that would leave no overhead space for motor braking. Unless somehow the OCP trip changes on drv8301 when you input a current >20A but how would that affect current limiting? You know a motor could still run even with Minper cycles limiting current CBC. Seemingly rotor vibration and odd sounds being made at the same time but it would run.  

As I have recently  been informed TI typically configures motor drive kits at half the rated current for overhead braking. Sorry for any confusion NexFET above but it too has same 40A peak of your x96 kit NFETS, and DRV3820RS has NexFTES, 3 current monitor are PGA amplifiers gain up to 12 and even add filter components. The NexFETS are rated 40A but the BoostXL-drv8320rs kit web page shows 20A, likely for braking aspect first mentioned.

Gl said:

Hardly believe motor achieved anywhere near 40A input power as that would leave no overhead space for motor braking.

We really did get 40Apk, but the load was passive.  I don't understand what you mean by overhead space for motor braking.  Do you mean in case the three phases are shorted together through the bridge?

Gl said:

As I have recently  been informed TI typically configures motor drive kits at half the rated current for overhead braking. Sorry for any confusion NexFET above but it too has same 40A peak of your x96 kit NFETS, and DRV3820RS has NexFTES, 3 current monitor are PGA amplifiers gain up to 12 and even add filter components. The NexFETS are rated 40A but the BoostXL-drv8320rs kit web page shows 20A, likely for braking aspect first mentioned.

If they set the trip point for 1/2 the rated current then we should be good up to 55A.  Those FETs are huge.  They're D2PAKs rated for 110A.  It looks like there's a function in the control software where I can read the peak current off the DRV8301.  I'll see if I can figure out what that's set to.  Either way, I was running the real motor in open-loop up to 30Apk today.  It was nice and smooth as long as there wasn't too much d-axis current.  I'll see if I can push that to 40A tomorrow.

Matt

Yea it was the voltage set half for braking overhead not the current. The TI web page of Drv8301-69m-kit shows 60 volts 40 amp, makes it seem like 8301 current was limited to 40A via register settings. That could interrupt the drive signals 4us intervals depending on the OCP register setting.

Yet web page states 40A, seemingly 55A would be the current 1/2 safety point, not 40A.

Applications include sub-60-V and 40-A synchronous motors for driving pumps, gates, lifts, fans, as well as industrial and consumer robotics and automation.

Exactly.  Our application is a 9Vll,rms, 14Arms pump.  The controller shouldn't fall apart when I ask for 22Apk (15.5Arms).

Here's a little more information.  The DRV8301 is configured in current-limit cycle-by-cycle mode (OCP_MODE = 00b and OC_TOFF = 0).  The overcurrent limit is set to 0.730V (OC_ADJ_SET = 21), which corresponds to approximately 200A for the FETs on the PCB.

The drive current is set to 0.25A (GATE_CURRENT = 10b), which will charge the gate to 15V in ~1us.

I just drove the motor at 40A peak.  The current waveform looks good, there's no fault, and there's no signal on the nOCTW pin, which is configured to report both overtemperature and overcurrent (OCTW_MODE = 00b).

In the process of adjusting the operating point I have to adjust the voltage, frequency, and load manually, in steps, so I end up applying more than 40Apk to the motor.  At one point I stepped too fast and got ~60Apk, but that had a significant d-axis component.  Still, even that current looked fine.

If you still want me to keep looking at the hardware then I'm still open to ideas, but I'm even more convinced now that this isn't a gate driver problem.

Matt

Matt Meier said:

If we take 18A out of a 36V battery, that's 650W into the inverter.

How is it you command 20A on q-axis and only get 90W from bus voltage 32v. As P=EI so to 32v*20A=640W  or I=P/E=20A. The point of testing battery power was to load rotor with same counter torque point as wall supply and speed estimator beaks down. If the motor wattage does not increase >90W adding same counter torque load, something is wrong with PI control. Perhaps the duty cycle did not increase >90W when the load was increased in that experiment? 

Have I misunderstood the reason for battery check was to rule out variac wall supply under the same load conditions. Odd it did not lead you to the same deduction pointed out above, PI controller is not regulating the PWM duty cycle if motor power (W) fails to increase under load. 

The q-axis current variable perhaps limits peak power relative to expected rotor loading as PI controller commands duty cycle changes relative to rotor load changes. So at some point in either experiment power should grow >90 watts especially if the current probe confirms 20A peaks occur. Otherwise the current probe is lying!

Matt Meier said:

The drive current is set to 0.25A (GATE_CURRENT = 10b), which will charge the gate to 15V in ~1us.

That is the lowest gate current setting possible and relative to any external series resistance added either side.  Also gate dirve is only 9.5v min - 11.5v Max.

Matt Meier said:

The overcurrent limit is set to 0.730V (OC_ADJ_SET = 21), which corresponds to approximately 200A for the FETs on the PCB.

Seems high for 110A NFETS, perhaps accounts for transients or set incorrectly. Perhaps check the SOA graph of D^2 FETS to see what the peak current/period at BVD. 

Everything must be configured and working correctly then?

Gl said:

Seems high for 110A NFETS,

If the adjust peak limit is set to high, nOCTW pin may not toggle in either OCP mode, unless perhaps VDS faults also occur. Have you checked the 8301 errata PDF?  

Gl said:

Also gate dirve is only 9.5v min - 11.5v Max.

That's a good catch about the drive voltage.  The MOSFET characteristic curves are indistinguishable above 10V so the shutdown point is still more or less 200A.  Yes, I'm certain everything is configured just fine for the DRV8301.  I trust that Ti did a good job setting up their hardware and configuring it in their software.  There have been bugs in their software, it is true, but everything seems to be in order after checking the parts related to the gate drivers.  Besides, I would think a misconfigured gate drive would be so fundamental that I wouldn't be the first person ever to run into it.  I can't be the only person to have run this demo kit above 20A.

Gl said:

Seems high for 110A NFETS, perhaps accounts for transients or set incorrectly. Perhaps check the SOA graph of D^2 FETS to see what the peak current/period at BVD. 

The max pulsed drain current is 400A.  They don't give a duration, and I really don't see the relevance.  I'm not trying to validate their demo kit here...it seems obvious by now that this thing can handle more than 20A without shutting down.

Gl said:

How is it you command 20A on q-axis and only get 90W from bus voltage 32v. As P=EI so to 32v*20A=640W  or I=P/E=20A.

You're mixing up the power equations and confusing the currents and voltages.

In our system, we have a 208V (I called it 240V before, but it doesn't matter here) single-phase variAC and isolation transformer.  These feed a rectifier with a large bus capacitance.  The DC output of this rectifier is fed into the Ti demo kit.  The output of the demo kit is attached to a 3-phase SPM motor on a bench, which is coupled through a torque meter to an adjustable load.

P = IV when you have DC.  If you have an AC system, P=IV*pf, where V and I are in rms and pf is the power factor and pf = cos(alpha) where alpha is the angle between the voltage and current.

For a 3-phase balanced system, then P=1.7*I*V*pf where I and V are in rms, V is line-to-line, and pf is as it was before.  You could also use P = 3*V*I*pf if you use line-to-neutral voltage.

If E is the back EMF of the machine then we can use P = 3*I*E*cos(delta), where delta is the angle between the induced EMF (aligned with the q-axis) and the current.  If the current is all on the q-axis then delta is zero.

V,I, and E are related through the winding impedance.  We'll let lowercase v, i, z, and e be the phasors:  v = e + I*z.

The induced EMF is not in any way related to the DC bus voltage.  You could run a machine at a given current, voltage, and angle and then increase the bus voltage.  If the controller continues to apply the same voltage at the same angle, you won't see any change in the power, apart from maybe some minor changes related to the electronics and the power supply.  You WILL see the DC current decrease because the input power has to stay the same.

So, let's apply 20Apk to the motor and adjust the load so that it runs at 2000rpm.  The torque is 125mNm, measured.  That's 26W mechanical.  Assume this is aligned with the q-axis.  The back EMF at 2000rpm is 1Vpk, so that's P = 3*Irms*Erms*cos(delta) = 3*0.7*14*cos(0) = 30W assuming everything is lined up as we think it is, and everything so far indicates this is the case.  Moreover, at 20Apk the calculated copper losses in the motor are ~5W, so the loss even lines up.  The power out of the 28V DC supply is then 0.9Adc, ignoring losses.  If I measure the DC current, it looks close.  I don't want to swap current probes to get a more accurate reading there because it's just not worth it.

The shaft load is variable.  It's proportional to the square of the speed, but I can adjust the proportionality constant.  All of these experiments have been performed at steady-state.  The motor power does change as I change the load.  If I adjust the load to be 125mNm at 6500rpm, the motor accelerates until the system reaches stead-state again.  At 125mNm and 6500rpm, the mechanical power is 85W (call it 90).  We think the current regulators do pretty well through this test because the mechanical torque doesn't change more than maybe 10%, and we're not concerned about the high-speed issues right now, just the high-current operation.

The current probe was the first thing I checked, but it's correct and I can verify it.  First, I request 20A from the regulators.  Then, I record the current on an oscilloscope and also log the phase current on the C2000.  I also can read the torque and calculate the amount of q-axis current required to generate that torque.  They all match.

Matt

I found a startup errata for the DRV8301, but I don't think it applies to this system as I'm using it.  Is there another one?

Matt

Matt Meier said:

You're mixing up the power equations and confusing the currents and voltages.

Actually power in is power out that is the point being made. Your formula bewilders the more simple ohms law approach.

Matt Meier said:

At 125mNm and 6500rpm, the mechanical power is 85W (call it 90).

Is this the maximum wattage prior to FAST estimator falling apart?

Matt Meier said:

First, I request 20A from the regulators.

Yet from what you have stated the motor never reaches requested iq if input power remains 85W under various loads. I assume 125mNm is the threshold, greater torque loads and the motor can not maintain stability no matter how high the commanded iq value. Perhaps the motor induction changes rapidly at higher speeds "And I'm just throwing this on the fire" phase current becomes saturated thus no greater torque can be achieved at set speed.

The torque load graph can be plotted to indicate as rotor speed increases torque decreases, no matter what iq is commanded. With PM and induction motors torque at some point is sacrificed in order to maintain requested rotor speed also being part of the ld/lq formula. Inevitably the torque load overcomes the rotation angle lq at some arbitrary iq relative to stator inductance at said speed. One way to counter measure that degrading effect is to add more power into the loop, as you have done so already.

Perhaps try to spin another motor with similar power attributes as you expect and compare the differences, if any.....

Matt Meier said:

I wonder whether there's something odd happening with the DRV8301 chip or the inverter itself to inject an unintended response, thus throwing off the estimated angle.

It would not be unreasonable to suspect a marginal NFET in the mix as the inverter remains a tested constant. One way to determine that is to use a temperature probe on suspect NFET's. They can degrade from repeated IAS (avalanche) due to various phase inductance differences impacting one phase over others. 

Gl said:

Actually power in is power out that is the point being made. Your formula bewilders the more simple ohms law approach.

Right.  2nd Law, no free lunch.  That's what I've been arguing.  We get out 85W at 6500rpm and 125mNm (P=Tw).  You argued that my reported DC current was way too low and that it must have been far larger, and that by your calculations we were putting in 650W.  That's impossible because that would mean something is getting REALLY hot.  I anticipated that your calculations were based on an oversimplification of AC power, especially with a 3ph motor.

The input power is V*I.  That's fine.  But, the output power is more complex because the current and voltage might not be in phase with each other.  For the simplest example, if you connect an ideal inductor or capacitor to an AC source then it will draw current, but there will be zero power.  Specifically, if you connect a 200uF capacitor to a regular 120V wall outlet then the impedance will be -j13.3 Ohms.  The capacitor will draw 9Arms, but the power P=V*I*cos(90) = 0W because the current leads the voltage by 90°.  There will be instantaneous power both into and out of the capacitor as it charges and discharges, but over one cycle the net (and, therefore, the average) is zero.

Our motor is running at max torque per amp, with Id = 0.  We could run at unity power factor, but that's less efficient.  Add to that the step-down for the voltage between the DC bus and the motor, and we can explain how the DC current at 2000rpm and 125mNm is less than an amp.

Sort of.  The FAST estimator begins to fall apart above a certain current request, which translates directly to a certain torque.  At 6500rpm, which is our target speed, that's equal to 85W.  At lower speeds, it's lower power.  At the 2000rpm test point, which I'd like to focus on, it's 26W.

This is a little bit distorted.  We can request 20A, which translates to ~125mNm, and the system is OK.  If I ask for 22A then the estimator falls apart.  21A might be OK sometimes and not others.  We're right at the threshold.

The motor itself is happy above that current/torque level.  I ran it manually in open-loop and got 40A and over 200mNm last week.  The motor/load/dyno setup is fine there.  It seems to be the controller that's struggling.  I don't know what you mean by the current saturating...do you mean the controller command, or maybe the output of the PI regulators?  Neither of those is saturating.  The current command is manually adjusted, and I can plot the duty cycle and that's definitely not limiting.  If you meant that the motor impedance is limiting the current then that's not happening either, as is evidenced by the 40A test.

In all these tests, we're running along the constant-torque region, the flat spot defined by the motor's thermal limit, like in the plot below (credit to Tesla):

Call our corner point for 13.5Vdc supply 6500rpm and 125mNm.  The 125mNm is our target because that's the thermal limit in our application environment, but on the bench we can exceed that for short periods of time as long as we are either:

1.  Below 6500rpm

2.  Above 13.5Vdc

Number 2 is the reason I bumped the voltage to 28V.  I didn't want to hit a wall prematurely, and I didn't want to deal with the voltage and modulation limits in the controller.

We're definitely not being limited based on theory, and we're also not being limited due to physics (we've gone up to 40A in this lab with this motor, but it's only in open-loop).

Gl said:

It would not be unreasonable to suspect a marginal NFET in the mix as the inverter remains a tested constant. One way to determine that is to use a temperature probe on suspect NFET's. They can degrade from repeated IAS (avalanche) due to various phase inductance differences impacting one phase over others. 

They didn't even get hot during the 40A testing last week.  I monitor them with my fingers when testing, and they weren't hot even after ~10 minutes of constant operation.

I'm convinced that this isn't hardware.  At Ti's advice I'm going to start a new thread focused on the control aspects of the problem, but I'll keep this alive for more discussion and hardware suggestions.

Matt

Matt Meier said:

We can request 20A, which translates to ~125mNm, and the system is OK. 

That sounds nuts to me as my 36 pole motor produces several Nm of torque +24vdc @8A open loop commutation. Hope I don't have to set the DRV8320RS that high to get my 36 pole motor to spin 48vdc. Analysis show it spins faster than expected +48v via ld/lq sine wave modulation.    

Matt Meier said:

You argued that my reported DC current was way too low and that it must have been far larger, and that by your calculations we were putting in 650W. 

Not exactly as I argued for 20 amps of phase current, 85 watts was to low and more like 560 watts into the motor, 28vdc. Then I stated your current probe was fibbing if you measured 20 amps on the phases and not measuring >85W. Who really cares about the AC line power other than for fusing, etc it is the rectified DC to focus on.

If your motor is not getting mildly warm 20 amps phase current 28vdc, (560W) something is not adding up. That was the point I tried to relate but it got thrown into the miscommunication bin.  

Best of luck on your new post.

Gl said:

That sounds nuts to me as my 36 pole motor produces several Nm of torque +24vdc @8A open loop commutation. Hope I don't have to set the DRV8320RS that high to get my 36 pole motor to spin 48vdc. Analysis show it spins faster than expected +48v via ld/lq sine wave modulation.   

Sure, but your motor is different.  I have a different motor that produces 716N*m with only 30A of phase current.  Even for the same stator and rotor, you can change the torque constant just by changing the number of turns in the machine.  If I double the wire size and cut the turns in half on my motor then I'll get 125mNm at 40A.  On the other hand, if I use 4x the turns and 1/4 the wire size then I'll get 125mNm at 5A.

Gl said:

It seems a typo had reversed 56 should read peak of 560W.

Not exactly as I argued for 20 amps of phase current, 85 watts was to low and more like 560 watts into the motor, 28vdc. Then I stated your current probe was fibbing if you measured 20 amps on the phases and not measuring >85W.

The mechanical power is 26W at 2000rpm and 125mNm.  125mNm is the torque, both theoretical and measured, at 20Apk phase current.  The phase current is not DC, nor is the phase voltage 28V.  28Vdc is the voltage input to the inverter, which generates a fundamental AC voltage for the motor that is less than or equal to 28V line to line, peak.  In our case, that voltage is significantly less than 28V.  It is also not in phase with the current.  You can't calculate the motor power as P = 28*20 for several reasons.  I can draw it out in more detail than before if it helps to clarify...it's a critically important item for this discussion, here or with any motor.

Who really cares about the AC line power other than for fusing, etc it is the rectified DC to focus on.

There are two AC systems here:  The line, which has been eliminated from our discussion, and the motor.  The motor is a 3-phase AC machine, so you HAVE to use AC calculations...if it's not clear, I can be more thorough.

Gl said:

If your motor is not getting mildly warm 20 amps phase current 28vdc, (560W) something is not adding up. That was the point I tried to relate but it got thrown into the miscommunication bin.  

Best of luck on your new post.

The winding is, I think, 14ga, 2-in-hand, with no housing but I would have to double-check that...it might be 12ga.  20A is nothing in that winding.  We're also not putting 560W into the motor.  We're only putting in ~30W.  The theoretical copper loss is less than 5W at 20A, and that matches the difference between the AC motor power and the mechanical power.  It's definitely not enough to make the motor hot.

Matt

Matt Meier said:

The motor is a 3-phase AC machine, so you HAVE to use AC calculations...if it's not clear, I can be more thorough.

Yet PMSM run on DC battery if you will. Ohms law power formula works for AC and DC alike. Your motor is not an IPM by any chance? If so this older motor control suite does not directly support IPM torque. You may have to upgrade to new SDK  F280049c to get IPM torque support in the labs.

I mention this as you pointed out the Tesla (IPM) and posted the torque curves above.

You're not suggesting you can hook the three phases of a PMSM up to a battery and make it run, are you?  P = I*V simply cannot be used for this motor.

Our motor is an SPM, hence all the discussion about Id = 0 and Iq being the only torque-producing component.

I apologize.  I was reading back through this looking for something and I think I misunderstood your starting assumptions.  It seems as though you're looking at this like the type of BLDC machine that you can run with nothing more than Hall effect sensors and some logic gates to drive the switch commutation. 
This type of system can be modeled from the DC side just like a DC machine.  Besides that, the self-synchronous nature of the machine allows it to be adjusted by just varying the DC input.  These can be driven with more complicated schemes, but in the simplest implementation the full DC voltage is applied directly to the phases through the switches, which are not PWMed.

This is not the case in our system.  We are modulating the DC voltage with PWM signals sent to the switches, and thus the DC voltage is not necessarily related to the phase voltage.  Whatever we do with our input voltage, it is stepped down to the appropriate level by the inverter so that the voltage applied to the motors is lower than what comes in.  It is not running like a classic self-synchronous BLDC machine in any way.

I should have made that connection earlier.  I've been trying to clear up AC/DC misconceptions with some students the past few weeks, and I must have gotten tunnel vision.  I do apologize for missing that.

Matt Meier said:

You're not suggesting you can hook the three phases of a PMSM up to a battery and make it run, are you? 

Not at all without a DC inverter and or controller.  That comment was about AC line power versus DC battery voltage. If your AC powered DC supply is 1/2 wave rectified it may produce odd results

Matt Meier said:

We are modulating the DC voltage with PWM signals sent to the switches, and thus the DC voltage is not necessarily related to the phase voltage.

The amplitude of the inverter sinusoidal wave should remain nearly the same as the DC supply voltage at all speeds. If amplitude of sinusoidal wave drops lower than the DC bus voltage something is not right in the circuit. DSP separates the kind of modulation schemes and even the discrete motor driver has an PWM oscillator. They often modulate the top drives in those discrete motor controllers but I have been referring to FOC via SVPWM from DSP. No FEM math simulation ld/lq solver ever reduces phase voltage to simulate rotor speed. The only thing that changes rotor speed is the duty cycle of sinusoidal waveform at a specific PWM frequency such as 10-40kHz. 

Matt Meier said:

It is not running like a classic self-synchronous BLDC machine in any way

PMSM requires the same synchronous flux as BLDC, perhaps you are thinking of induction motor slip.  The IPM has odd torque conditions, the new SDK only fully supports. Perhaps IPM odd flux has issues around d/q frame decomposition of the rotation angles. If I recall IPM flux is axial and partly radial in the air gap. An overly wide air gap can lead to high phase current and low torque resulting is very little ripple.   

1/2-wave rectification into a capacitor bank just produces more voltage ripple, unless the capacitor is completely discharging.  Ours is a full-wave rectifier on a single-phase transformer.  You can assume our input power to the inverter is purely DC, just like a battery.  We can see it on an oscilloscope.  The ripple is negligible.

Gl said:

The amplitude of the inverter sinusoidal wave should remain nearly the same as the DC supply voltage at all speeds. If amplitude of sinusoidal wave drops lower than the DC bus voltage something is not right in the circuit.

That just isn't true.  Hypothetically, suppose our DC voltage is 28V.  The PWM signals to the transistors on each pole are complimentary.  If I apply a PWM signal to phase A at 25% duty cycle, the voltage from phase A to negative bus will be 7V.  If I apply 75% duty cycle, the voltage from phase A to negative bus will be 21V.  Now, let's generate a sine wave with the positive peak at 75% and the negative peak at 25%, centered on 50%.  If phases B and C are doing the same but shifted 120° and 240°, respectively, then we will get 7Vpk line-to-neutral on each phase and 12Vpk line-to-line.  We have many measurements that show this, and I can simulate it and demonstrate the results if that helps.  The DC bus is not automatically equal to the peak sine voltage at the motor.

However, at any instant (ignoring dead time), each phase is either connected directly to the positive bus or the negative bus.  This happens at the switching frequency which, in our case, is 30kHz.  But, the low-frequency phase voltage is modulated to whatever we wish it to be (or whatever the controller requires to get the demanded current).

Gl said:

DSP separates the kind of modulation schemes and even the discrete motor driver has an PWM oscillator. They often modulate the top drives in those discrete motor controllers but I have been referring to FOC via SVPWM from DSP. No FEM math simulation ld/lq solver ever reduces phase voltage to simulate rotor speed. The only thing that changes rotor speed is the duty cycle of sinusoidal waveform at a specific PWM frequency such as 10-40kHz. 

The duty cycle of the sinusoidal waveform is EXACTLY what steps the voltage down so that it is less than the DC voltage.  This will result in more or less phase current, which will produce more or less torque, and the motor will accelerate or decelerate.  But, the rotor speed must match the inverter's applied frequency (or, the inverter must match the rotor's speed).  In our case, the controller adjusts the phase voltage magnitudes and angles to generate the torque-producing current that we want, and that torque-producing current causes the motor to accelerate or decelerate according to the applied shaft load.  Because the controller is adjusting the phase of the voltage with respect to the rotor position, it will automatically commutate at the rotor frequency.

This is something of a semantic discussion, still, but I was referring to the classically-driven BLDC machines where Hall effect sensors provide position information and that automatically determines the transistor states.  I'm definitely not thinking about induction motor slip.  This machine is synchronous, but it is not controlled by a 6-step controller.  We're using the field-oriented controller that Ti supplied with their demo kit.

Motors shouldn't have axial flux for a radial-gap motor, even IPMs.  But, all motors (including SPMs) need to have some tangential (circumferential) component to their flux because otherwise you wouldn't get any torque.  When trying to develop analytical models, some people have estimated that the flux in an SPM is all radial when the coils are off, but when the coils are on there needs to be some tangential flux.  If you have seen that an SPM is 100% radial gap flux then that is either a tool for developing a simpler model, or it is incorrect.

Matt

Matt Meier said:

If phases B and C are doing the same but shifted 120° and 240°, respectively, then we will get 7Vpk line-to-neutral on each phase and 12Vpk line-to-line

How is it you have neutral on a three phase motor? If neutral does exist it must not be connected to anything, left floating.

Matt Meier said:

Motors shouldn't have axial flux for a radial-gap motor, even IPMs

The FEM motor flux is considered axial relative to the stationary stator, not the rotating magnets.

Matt Meier said:

We're using the field-oriented controller that Ti supplied with their demo kit.

Right and it uses seven phase SVPWM to produce near sinusoidal waves. 

Matt Meier said:

but it is not controlled by a 6-step controller.

Yet with the correct SW some kits can also produce 6 code trapezoidal wave forms according to some of TI web text.

Matt Meier said:

The duty cycle of the sinusoidal waveform is EXACTLY what steps the voltage down so that it is less than the DC voltage

That's odd since the analysis plots of sinusoidal wave form are all depicted at the same amplitude. Also SVPWM is not true sine wave DSP as the peaks have inflection points mid center shown in all the DAC plots. I recently produced similar sine wave (sin/cos) via BEMF decomposition of 7 phase rotation angle codes without clarke/park transforms. So it seems there are older DSP methods besides FAST that may have similar or better control of flux current angles. Please review section 6.2 relative to flux angle and ensure you have entered a correct value in user.h.

/cfs-file/__key/communityserver-discussions-components-files/171/Piccolo-TMS320F28069F-68F-62F-InstaSpin-FOC-software.pdf 

Page 289 discuss salient versus non-salient rotor types as they relate to the labs:

/cfs-file/__key/communityserver-discussions-components-files/171/1830.instaspin_5F00_labs.pdf

Gl said:

How is it you have neutral on a three phase motor? If neutral does exist it must not be connected to anything, left floating.

We have a neutral because the motor is wye-connected.  Most of the motors we use are connected in wye.  The neutral here is not connected to anything, but it DOES have a potential based on the rest of the circuit.  The motor frame is open, so we can actually measure that line-to-neutral voltage.

Gl said:

The FEM motor flux is considered axial relative to the stationary stator, not the rotating magnets.

The cylindrical coordinates are the same for the rotor and the stator.  The axial (z) direction is the same for both, the radial (r) direction is the same for both, and the tangential (phi) direction is the same for both.  The only different is that one of the coordinate systems is rotating with respect to the other.  There is almost no axial flux in this motor and that little bit of fringing at the ends is balanced, as should be the case with any radial flux design.  What FEM motor are you talking about?

Gl said:

Yet with the correct SW some kits can also produce 6 code trapezoidal wave forms according to some of TI web text.

For sure...any kit where you can control the six transistors can do this.  We've used the Ti system to do trapezoidal commutation before, but that's not what we're doing now.

That just means your controls are different than ours.  Because we're using field-oriented control, we apply the correct voltage amplitude and phase to generate the current amplitude and phase that we desire.  Some control systems just apply full voltage all the time (that's what a lot of old BLDC controllers do), and some do direct torque control, and some do V/Hz control, etc.  FAST isn't a control method.  It's just an estimator that provides the Flux, Angle, Speed, and Torque.  We're doing sensorless control, so this is convenient.

Using space vectors doesn't have to cause distortion.  Where is your distortion?  In the current or the voltage?

Gl said:

Please review section 6.2 relative to flux angle and ensure you have entered a correct value in user.h.

/cfs-file/__key/communityserver-discussions-components-files/171/Piccolo-TMS320F28069F-68F-62F-InstaSpin-FOC-software.pdf 

Page 289 discuss salient versus non-salient rotor types as they relate to the labs:

/cfs-file/__key/communityserver-discussions-components-files/171/1830.instaspin_5F00_labs.pdf

These aren't relevant, although I've been through both quite a bit.  We have an SPM with no rotor steel.  user.h is set up with the correct measured parameters.

Matt Meier said:

The cylindrical coordinates are the same for the rotor and the stator. 

However that does not dictate the direction of magnetic filed being perpendicular to axial flux.

Matt Meier said:

  There is almost no axial flux in this motor and that little bit of fringing at the ends is balanced, as should be the case with any radial flux design.  What FEM motor are you talking about?

Non-Salience motors also produce axial flux in the air gap according to Japanese Research Institute rotational FEM analysis. What is not desirable is Z direction force pushing the rotor against the ball bearings. Stator flux is perpendicular (not radial) to the magnets permanent field, typical being radial anisotrophy with some margin decay on either end. I believe but could be incorrect radial flux direction is only mentioned for traction motors.  

Matt Meier said:

That just means your controls are different than ours.  Because we're using field-oriented control, we apply the correct voltage amplitude and phase to generate the current amplitude and phase that we desire. 

I was referring to InstaSpin FOC plots via DAC output not producing true sine waves CCS debug since the peaks have inflection. They are always plotted at motor end speed in the technical manuals so it would be hard know any DC sag occurs. Until I test the BoostXL-DRV8320RS kit now in hand.

Matt Meier said:

The motor frame is open, so we can actually measure that line-to-neutral voltage.

You don't use that for voltage measures and connect scope probe ground lead to DC ground? The sine wave magnitude should not change to control motor speed, only the speed PI regulates the duty cycle. It sounds like you may have scope probe ground lead connected to neutral. If the probe is differential that too might show odd results. So you have stated the magnitude of sine wave PTP changes with motor speed and DC supply is not sagging under load? 

We see as much as >20v change in the commutate wave form as motor accelerates due to supply sagging 167v to 143v. Hope that improves with SVPWM sine wave but I wont hold my breath. The 24v test of InstaSpin will show one way or another.

Gl said:

Non-Salience motors also produce axial flux in the air gap according to Japanese Research Institute rotational FEM analysis. What is not desirable is Z direction force pushing the rotor against the ball bearings. Stator flux is perpendicular (not radial) to the magnets permanent field, typical being radial anisotrophy with some margin decay on either end. I believe but could be incorrect radial flux direction is only mentioned for traction motors.

I think you're decomposing the flux.  I'm referring to the fluxes in the full assembled machine, and specifically in the air gap.  It has a radial component (it has to cross the gap) and it has a tangential component (otherwise there would be no torque).

Regardless, unless you aren't using a radial-flux machine, there is no axial flux except for fringing at the drive end and non-drive end of the motor.

Gl said:

I was referring to InstaSpin FOC plots via DAC output not producing true sine waves CCS debug since the peaks have inflection. They are always plotted at motor end speed in the technical manuals so it would be hard know any DC sag occurs. Until I test the BoostXL-DRV8320RS kit now in hand.

I don't really know what you're doing...Are you using the DAC so that you can see internal DSP data on an oscilloscope?  It's possible the distortion is from the DAC.  Why don't you directly plot the current in the DSP and download it to a PC?  Do you see this same distortion when you use a current probe directly on the phase windings?  When you say the peaks have inflection, is it possible you're talking about the zero crossings?  Show me a plot.  This might also be because you're not correcting for deadtime.

Gl said:

You don't use that for voltage measures and connect scope probe ground lead to DC ground? The sine wave magnitude should not change to control motor speed, only the speed PI regulates the duty cycle. It sounds like you may have scope probe ground lead connected to neutral. If the probe is differential that too might show odd results. So you have stated the magnitude of sine wave PTP changes with motor speed and DC supply is not sagging under load? 

We can measure the voltage directly line-to-neutral.  Our scope is isolated so we can put the ground reference anywhere we want, including the motor neutral.  The motor phase voltage amplitude is not equal to the DC voltage.  No ifs, ands, or buts.  This is what anyone should expect to see FOR OUR CONTROLLER.  I don't know what you're doing, but if your phase voltage amplitude matches the DC voltage then you're obviously not using the same control method.

In the Ti system, the speed PI produces d- and q-axis current commands (just q-axis for an SPM in the labs).  The current PI controller produces voltage commands.  These voltages vary.  We don't have a speed PI, just a current PI.  We're commanding the torque by commanding a q-axis current.

The motor voltage does not change to control motor speed.  It changes to produce the requested current (and, therefore, torque).  If the motor torque is not equal to the load torque, the speed changes.

Our DC supply doesn't sag for any reason, and the voltage ripple is trivial (less than 0.5V).

Gl said:

We see as much as >20v change in the commutate wave form as motor accelerates due to supply sagging 167v to 143v. Hope that improves with SVPWM sine wave but I wont hold my breath. The 24v test of InstaSpin will show one way or another.

If your DC bus is sagging then changing your modulation scheme probably isn't going to fix that.  It's sagging because you're drawing enough power to cause the resistive drop to be significant.  You can watch the DC voltage from the inverter all the way back to the rectifier output, and then you can even watch the AC input line when you start up the motor.  Odds are it's a combination of wires and connectors, but some of them might be more dramatic than others.  If it's sagging at your wall connection then you might be stuck if you don't have a larger feed somewhere else.

Matt Meier said:

Why don't you directly plot the current in the DSP and download it to a PC? 

I'm not talking about phase current rather the PWM phase voltage being sent to three output DAC to view. Scope probe from ground to any 1 of 3 phases will reveal the same wave shape. The x86 kit should use the same 3 DAC's as the older previous MCU motor ware did.

Matt Meier said:

  The motor phase voltage amplitude is not equal to the DC voltage.  No ifs, ands, or buts. 

It won't be the same amplitude from neutral perhaps 1/2 the PTP value would be more plausible.

Matt Meier said:

If your DC bus is sagging then changing your modulation scheme probably isn't going to fix that.  It's sagging because you're drawing enough power to cause the resistive drop to be significant. 

Did you not state several times the phase voltage PTP magnitude was not the same as DC supply voltage on your system. Phase voltage might be changing with speed due to supply sag was my point. Again the phase voltage PTP value should not rise or fall "without" DC supply following along. If it does that would indicate issue in software causing bizarre phase voltages to be produced. Speed is controlled by the PI altering the PWM duty cycle in the current angles of Uout each sector, Not by lowering or rising the phase voltage. If your PWM interrupt timing is askew from SOC the current angle in each sector Uout may be altered and phase voltage drop my be the result as speed increases. Just a guess worth looking into.

Gl said:

I'm not talking about phase current rather the PWM phase voltage being sent to three output DAC to view. Scope probe from ground to any 1 of 3 phases will reveal the same wave shape. The x86 kit should use the same 3 DAC's as the older previous MCU motor ware did.

You might have a limit in your PWM generator that's inducing distortion on your applied voltage.  If you're trying to apply a 0% to 100% sinusoidal voltage on each pole, but your PWM generator limits the duty cycle to, say, 95% like in the Ti software, then you'll clip the peaks.  Also, if your DC bus has a ripple and you're not compensating for it then you'll also run into distortion problems.

Gl said:

It won't be the same amplitude from neutral perhaps 1/2 the PTP value would be more plausible.

OK, let me rephrase.  The peak line-to-line voltage should not match the DC bus in our scheme.  Neither should the peak-to-peak phase voltage.

Gl said:

Agree high current at high voltage is a job for Li-Ion battery not AC line power. It's an induction issue between primary secondary XFMR coupling  and not enough farads to catch up with the loss. That's the *** of unregulated HVDC there are no TI buck circuits to regulate the kind of power required, even if more farads are added.

Just not true for the control method we're using.

Hi Matt,

To simplify and shorten the thread, what problems do you still have? Could you please post the user.h and some waveforms of the motor phase current you captured to show the questions? Thanks!

I know this largely devolved into discussion on theory and hardware, and it's definitely not a hardware problem and the control method is theoretically sound. This thread can be closed. If we do revisit the hardware we can start fresh because this is a mess.

I have a new one that revisits the problem detached from the hardware. It has some waveforms like you requested, but I can provide more if you want me to produce something specific. You posted to that one last week, but here's a link.

Matt