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.

TMS320F28069M: Torque control failure during regen

Part Number: TMS320F28069M
Other Parts Discussed in Thread: DRV8353, UCC27714, MOTORWARE, DRV8312, DRV8302, TMS320F28069

Can anyone explain why we are seeing this strange behavior and loss of control during regen, and how we can tune the controller to eliminate it?

I am seeing a problem with my custom design where when I set Iqref higher and higher, at some point, the torque delivered to the load decreases with increasing Iqref. This is with a fixed speed load on a dynamometer. If I continue to increase Iqref, the controller becomes confused and stutters a lot and produces unsteady torque. We saw this behavior at both 550 RPM and 850 RPM. VBAT was about 55 V, and the motor rated speed is about 2600 RPM at 55 V. The motor is a 10 pole-pair outrunner. We are using a large test battery that can accept very large regen current without any problem.

Here is a graph showing measured torque, measured phase current (peak) and estimated torque (from FAST output) vs Iqref. In the graph, I am showing Iqref positive, but of course, since it is regen, the Iqref we are setting is actually negative.

The code we were running is essentially lab 5a. We adjusted Iqref using the debugger.



It seems like Rs can affect this problem. In one case we forced Rs to be slightly higher than the result of the ID, and that raised the Iqref level at which control was lost.

user.h stuff:
2625.user.h


We have a DRV 8353RS gate driver. Low-side shunts are 500 uOhms. Shunt amplifier gain is 40 V/V. Vref is 3.3 V. Hardware phase filters have a cutoff frequency of about 1400 Hz.

Note: in the past we have performed testing on this motor with other controllers and were able to achieve torque levels in regen higher than this. I don't think stator saturation is happening.

Back emf of motor when spinning freely (no controller attached)


Current waveform after loss of control (not sure if this is typical... it seems like the waveform looked a bit different every time)

  • Hardware phase filters have a cutoff frequency of about 1400 H

    Do you mean the analog filter pole frequency for voltage sensing? What PWM frequency are you using? What's the maximum electrical frequency of the motor?

    Here is a graph showing measured torque, measured phase current (peak) and estimated torque (from FAST output) vs Iqref. In the graph, I am showing Iqref positive, but of course, since it is regen, the Iqref we are setting is actually negative.

    Do you monitor the dc bus voltage at this testing condition? And what's the Vd and Vq output value of the d&q-axis current controller?

    Do you add a ramp control for setting the Iq reference? How do you change the Iq reference from a large positive value to a negative value? What's the state and speed when you change the Iq reference value to a negative value?

  • Yes, the analog filter pole is about 1400 Hz. The maximum electrical frequency is around 600 Hz. PWM frequency is 20,000 Hz.

    The DC bus voltage was not monitored during the test but the test was performed with a large battery, and the voltage during the test was around 55 V. We didn't record the Vd and Vq. We will redo the test and monitor Vd and Vq outputs.

    We were not using ramp control. We were changing Iq reference directly using the debugger.

    Iq reference was never positive. We only used negative values. At any value from 0 to to -50 A we did not notice any problems or instability. But when we increase Iq reference above -50 A we noticed a decline in actual output torque and then at about -52 A we see a loss of control / instability. We do not believe the torque ramp has anything to do with this. The speed was controlled at all times by the dynamometer. The speed was about 550 RPM in the forward direction throughout the test. This is a regen braking test where the motor is applying negative torque during positive rotation.

  • Here are some pictures that show Vd and Vq under different conditions. Red text in photos is annotation.

  • The maximum braking torque current must be lower far than the short-circuit current, otherwise the mathematical model of the motor is not correct for the FAST estimator, so it's better to limit the braking torque current to implement the sensorless-FOC.

    BTW, the analog filter pole could be a little bit higher for your motor with 600Hz maximum electrical frequency, recommend the pole is between 400~800Hz for this motor.

  • There is something here that does not make sense, though. The back EMF should be large enough to generate much more than 50 Amps of current. If you look at the pictures (I uploaded higher resolution pictures) you can see that the flux linkage is 0.06255. With 10 pole pairs, the voltage is 0.06255 * 10pp * 577rpm / 60sec/m = 6 V. Then 6 V / 0.06 Ohms = 100 Amps. So it doesn't make that much sense to me that Vq would be near zero at 50 Amps at this speed. I will measure some more stuff and update in a little bit. But let me know if my calculation makes sense. I will change the pole frequency closer to 600 or 800 Hz and update the user.h at some point. If you think that is critical I will change it today (let me know).

  • Do you have any limitation of the Id and Iq PI controller? Can you monitor the reference and feedback Iq, and the output of the Iq controller? Both Vd and Vq are not correct if the reference Id and Iq are a fixed value when you do the test.

  • I don't fully understand what you are asking. In the test, we set Iq ref and Id ref to fixed values. For example, if we set Iqref to -50 Amps and Idref to 0, we get stable operation. But if we sest Iqref to -54 and Idref to 0, we get loss of control. Note that the speed was set by the dynamometer. The instaspin motor controller was operating in torque mode. Is it possible for you to specify the variable names that you want me to monitor? For example do you mean gMotorVars.IqRef_A? That is the reference Iq, correct? We set it to a constant for the test. What is the feedback Iq? And what is the output of the Iq controller? Isn't it gMotorVars.Vq and gMotorVars.Vd?

  • You can check these variables in the PI controller for Id and Iq.

    Did you try to run the machine with such torque current in motoring mode?

    What's the maximum current sampling value of the ADC? Is there any overflow of the ADC?

  • There should not be any overflow. We have 500 uOhm low-side shunts. The shunt amplifier gain is 40 V/V. So that works out to 2 mV / A. The ADC reference is 3.300 V. So we have a full range of 165 Amps. We should be able to read from -82.5 A to +82.5 A.

    From previously attached User.h:
    #define USER_ADC_FULL_SCALE_CURRENT_A     (165.0)


    Yes, we were able to get past 54 Amps in forward motoring mode. We can set Iqref up to 60 Amps with good control. At 65 Amps, we see a control failure in forward motoring. This is with the DC bus at about 53 V.

    You asked me to "monitor the reference and feedback Iq".  I believe the reference is the variable gMotorVars.IqRef_A, right? We are setting the reference using the debugger. You also asked me to monitor "feedback Iq." What is the feedback Iq?

  • There should not be any overflow.

    Please monitor and capture the phase current of the motor, to see if the peak current is greater than half of the scale current when you try to increase the torque current in braking mode.

    I believe the reference is the variable gMotorVars.IqRef_A, right?

    Yes, it's the reference current with SI format. You may check gMotorVars.Id_A and gMotorVars.Iq_A for the feedback current.

    And please also check and monitor the variables in PI struct variables in CTRL object as below.

    Yes, we were able to get past 54 Amps in forward motoring mode

    What's the value, 54A you mean? Did you check the phase peak current of the motor with a current probe?

  • Please review the very first post. The curve labelled "Ipeak" is the peak current measured with a current probe and oscilloscope. The X axis is Iqref, the current we are trying to achieve (the setpoint of the Iq PID). The peak current matches Iqref, generally, until the point of failure.

    The estimated torque comes from the FAST estimator. The measured torque comes from a torque sensor on the dynamometer.


    When we do regen, we can increase Iqref as high as -52 Amps. Ipeak, the actual current measured with a current probe, is equal to Iqref. But when we increase from -52 to -54, we experience loss of control, and in this case the current waveform is erratic (not sinusoidal) and Ipeak does not track Iqref.

    However, in forward motoring, we can increase Iqref > 54 without loss of control. We were able to get to 60 Amps.
    When I say "54 amps" this is both Iqref, and also, the measured peak current which agrees with Iqref except after we lose control in which case Ipeak and Vd and Vq and all variables become extremely erratic.

  • The phase peak current should be much higher than the Iq reference value always and the peak current will be variable with the dc bus voltage when set the same Iq reference value and add the same load to the motor, please help to check and monitor the phase current when you increase the torque current to the maximum value in regenerative mode.  Please check and ensure that the current and voltage sensing signals are not overflow at this condition. We can just recommend you may limit the torque current first, and we don't verify if the FAST estimator works well at full current and speed range in regenerative mode.

    What's the rated current, rated voltage and rated speed of the motor?

  • The peak phase current should track Iqref. Why do you say the peak phase current should be higher than Iqref? This does not make sense to me. Phase current is the torque-producing current, and the amplitude of the phase current is proportional to torque. That is the entire basis of the torque control method.

    In any event, we are monitoring the phase current with current probe and scope all the time during testing. THE VERY FIRST GRAPH shows phase current (measured with current probe and oscilloscope) vs Iqref during regen.

    It also shows measured torque and estimated torque (estimated by FAST). As you can see on the very first graph, the peak phase current measured by current probe tracks IqRef. However, when Iqref is set to -50 Amps or more (-51, etc), the measured torque goes down while the estimated torque continues to go up. This seems to be a disconnect between the FAST observer and reality. Can you please take a minute to review the FIRST GRAPH in the question and let me know if you have any questions about it?

    The motor is a custom design. I don't think we have settled on any official power rating. But it is approximately 550 Watts, 2500 RPM and 52 V. We have tested it with other motor controllers at much higher power levels up to around 1000 Watts and up to about 8 Nm of torque. It can motor or brake at 8 Nm, but not for a long time due to overheating.

    The voltage signals are not overflowing or saturating. We can correctly read the DC bus voltage, and the voltage divider ratio on the phase voltages is the same as DC bus.

    In our application we really need to get the maximum braking torque up to around 8 Nm.

  • The Id and Iq are dc current, and the phase currents are sinusoidal. Yes, the motor phase current will follow the Id and Iq changes, and have a relationship. But the peak value of the motor phase current is not proportional to torque directly, it is also related to the dc-bus voltage and speed.

    It's difficult to know the peak current value from the waveform you posted. Please help to capture more current waveforms to monitor and check the peak value at different test conditions as mentioned above.

  • Yes, Iq is DC current. But, Iq is also the value of the peak AC current. Also, the AC current amplitude is proportional to torque. That is basic motor theory. Torque = Kt * I. I think perhaps you are mixing up voltage and current. Voltage varies with speed. Duty cycle depends on Vbat and speed and current.

  • You are right. In motoring mode, the q-axis current corresponds to the envelope of the phase currents if the current on the d-axis is zero for PMSM. But still need to check if there is any overflow on current and voltage sensing during generatoring mode. And you may check if the estimation angle and flux are correct at the different test conditions if possible.

  • OK, thanks. We will try to validate the sensing and flux angle. We have some ideas of how to do that.

  • Sounds good. We also need to take some time to verify the estimator in generating mode if the torque current is far over than the rated current.

  • While we have not fully resolved this issue, we do have some updates. First we found that in some cases we WERE getting saturation of the current ADC inputs (transient saturation). We changed the gain of our current sense amplifier so we are not getting saturation anymore. Also, we decreased the control tick count to 1, so now we are running control at the same as the ADC sample rate, 20 kHz. Also, we inserted code to log variables and stop logging upon instantaneous over-current event. This has allowed us to capture data from the controller leading up to loss of control. I will post more about that separately.

  • Great. Please make sure both current and voltage sensing signals are not saturated at the high current state. And please monitor both current and voltage, it's better to capture some waveforms with the oscilloscope at the transition state when the motor works from the normal status to the failed state.

  • Very difficult to trigger the oscilloscope at the moment of transition. We would have to use an IO from the board to trigger input on DSO. Maybe we can do that. I will post again soon.

  • Here are some graphs. These show various variables from the controller just before control is lost. First one is phase voltage ADC result (this is the result of the ADC conversion, so 4095 is a full-scale reading... there is  no saturation occurring).


    Here is a second graph of the same event showing ADC results for the current sense ADCs as well as the FAST estimated flux angle (labeled "phase angle" in the graph). We are nowhere near saturating, but you can clearly see somewhere around sample number 186 things start to go bad. However, we are still nowhere near numerical saturation of the ADC (phase angle is in PU on right hand axis). NOTE: all of these graphs are time correlated. Sample 186 on this graph corresponds to sample 186 on the other two graphs. The only reason I am posting three separate graphs is because it is too hard to see what is going on if all traces are on the same graph.




    Finally, here is a graph of Vd and Vq. As you can see, somewhere around 186 Vd and Vs are numerically saturating high while Vq is saturating low shortly after. This is when control is lost.

    We can see that things don't look good but don't fully understand what is happening here as far as the sequence of events. If you have any suggestions how we can operate in this current regime without losing control or any further experiments to try we would be very grateful.

    I want to emphasize that we do have a high degree of functionality from the motor. We can motor and regen over a wide range of torque and speed, but at very high torque we seem to be encountering these problems and could really use some help.

    I don't know if this could be related to our other outstanding question where we ask about speed estimate errors during heavy regen. For now I will keep them as two separate questions.

    Thanks and best regards,
    McKenzie

  • Hi McKenzie

    he shunt amplifier gain is 40 V/V. So that works out to 2 mV / A. The ADC reference is 3.300 V. So we have a full range of 165 Amps. We should be able to read from -82.5 A to +82.5 A.

    Seemingly typo, 20mv/A at gain of 40. Even with rail-to-rail amps the output will be more like +3.18v, typical ±120mV from high/low rails. So best estimate +3.18v/0.02 gives 159A ADC full scale. Lastly there is precision error at the low end 500µΩ shunt added too by any input filtering. Seemingly ±79.5A is more realistic and may give better control over PI current. The other thing to consider is current monitors tend to clip the output in bidirectional monitoring best determined via PSPICE models. One might solder tack short wrap wire on the output of current amp/s to probe signals during testing confirm any output clipping occurs or not Thinking.

    If you don't expect the motor will ever reach 79.5A peak, increase shunt to 1mΩ then 2mΩ. That will directly improve motor runtime testing, zero in on peak expected current and set very accurate CCMP trip points.

    Regards 

  • Typo or math-o or whatever. You are definitely right that it is 20 mV/A. However the fullscale number is correct. And so it is correct in the user.h file, despite the typo here.

    However, the gain is no longer 40 V/V. We reduced it to 20 V/V when we found that we were seeing transient numerical saturation (we actually saw conversion results of 4095 and 0 when gain was 40, FYI). We never set Iqref > 75 Amps, even before reducing the gain. So now the FS range is nominally 330 A (+/- 165A). Seems adequate guardband against any hard clipping or loss of gain.

    We added instantaneous current limiting at around 90 Amps. So if there is ever a single sample > 90 Amps we "trip" into a fault state and stop driving the motor. Likewise if a single sample is < -90 A, we "trip." We also continually log various data to circular buffers, then stop logging when we get a trip event. So we can dump those buffers using the debugger and examine all the variables that lead to the trip. That is where the most recent graphs came from. We may not do that in the future but for now it allows us to examine the state of the controller as it approaches an anomalous event. 

    We don't want to increase the shunt resistance due to power dissipation considerations.

    Since the current shunt amps previously put out full rail-to-rail voltage, and we subsequently reduced gain by a factor of 2, I am confident that we are not seeing any clipping now.

    The current shunt amps are included in the DRV8353RS we are using.

    Probing the output of the shunt amplifier is not all that easy due to small parts used everywhere. We can do it, but we also have to prioritize our debug effort using our judgement and right now I don't want to do that because I don't think it is a problem (based on ADC data stream).

  • How do you get these graphs? Can you monitor the d-axis reference current and feedback current to know why the d-axis voltage is so big variable?

    Is it possible to use the oscilloscope to capture some phase voltage waveforms on the ADC input channels? And capture the current waveforms with the current probe. Seems like the current and voltage shapes have distortion on the graph above.

  • We created circular buffers to monitor variables of interest. The circular buffer is updated every sample (20 kHz). Then we put in code that checks the current every sample. If the current is > max instantaneous current, we set the controller to offline state and stop logging to the circular buffers. After the over-current event, we manually cut and paste the data from the debugger window in code composer into a spreadsheet.

    The D-axis reference current is fixed (we are in torque control mode) but we can try capturing the Q and D axis feedback current. We have a lot of things to work on, so it may not happen immediately, but we will do it at some point.

    While it is possible to capture data on the oscilloscope, it is difficult to synchronize the oscilloscope data with the internal data. Also it is difficult just because the components and pins and pads are small. But we can capture some example waveforms during good operation (before tripping).

  • Got it. I just doubt that the phase voltage waveforms are not smooth with distortion. What dc bus voltage is implementing on the inverter? And what's the value of USER_ADC_FULL_SCALE_VOLTAGE_V and USER_VOLTAGE_FILTER_POLE_Hz of the hardware board?

  • We have changed our filter pole based on previous feedback. Below is the up-to-date value.

    #define USER_ADC_FULL_SCALE_VOLTAGE_V     (66.08745)
    #define USER_VOLTAGE_FILTER_POLE_Hz     (673.8529)

    We are using a battery during testing. Voltage varies according to state of charge, but it is always between 50 and 58 V.

  • What's the motor speed when meet the issue? Is it possible to reduce the R22 and increase the C27 for both dc-bus and phase voltages sensing circuit?



  • How close can we put the filter pole to our maximum electrical frequency? For example if our maximum electrical frequency is 500 Hz, what is the lowest pole frequency we can use? There will be some amplitude loss and phase shift if the electrical frequency is close to the pole frequency. This is why I have tried to keep the pole frequency a bit on the high side.

    We have tested at various speeds. In the more recent graph we were running at shaft speed of about 1700 RPM. Electrical frequency is about 280 Hz. The x-axis is the sample number, and we are sampling at 20 kHz, so that is every 50 us.

  • How close can we put the filter pole to our maximum electrical frequency? For example if our maximum electrical frequency is 500 Hz, what is the lowest pole frequency we can use?

    The filter pole is related to the PWM switching frequency to filter the high frequency signal, its value can be 300~800Hz and select a big value if the PWM switching frequency and PWM switching frequency are high.

    It's better to increase USER_ADC_FULL_SCALE_VOLTAGE_V  to ensure at least 20% greater than the maximum dc bus voltage.

  • Our PWM frequency is 20 kHz. I understand that the filter is intended to remove the PWM.  But it also must pass the electrical frequency of the motor to avoid attenuating and phase shifting the voltage signal. It seems to me that if the pole is too close to the electrical frequency of the motor the filter will attenuate the signal (and produce phase shift). I have not traced the code to see if it attempts to compensate for this attenuation and phase shift. If so, maybe it is OK to put the filter pole very close to the maximum electrical frequency. Are you able to comment on this?

    We can change the divider and raise USER_ADC_FULL_SCALE_VOLTAGE_V if you recommend it. However in the testing we have done so far we are not close to the maximum at all. So I don't think that is related to the issue at hand.

  • The FAST estimator will add a delay compensation according to the filter cut off frequency, so the pole is mainly related to the PWM frequency and is set to the recommendation value.

    Generally, the bus voltage will be boosted when the motor is in generating mode, so it's better to make sure that it's not over the ADC sampling range.

  • Hi Yanming,

    Generally, the bus voltage will be boosted when the motor is in generating mode, so it's better to make sure that it's not over the ADC sampling range.

    So it is better to add 30% in the EMF voltage divider range as ADC overhead and that is the maximum voltage possible during regeneration Lab6?

    Seemingly any braking method needs a control algorithm to limit rotor deceleration speed to USER_ADC_FULL_SCALE_VOLTAGE_V.

    Perhaps coasting typedef word controls rotor decent (Rad/Sec) in flying restart (Lab9) if user never asserts a restart command? And (motorVars.torque_Nm) should indicate negative counter torque during coasting? Assuming costing is enabled under DC inverter FAST control with full bus voltage applied. 

  • I have lots of experience with regen. Regen does not lead to uncontrolled charge current. You have a torque limit (just as you do when motoring) and that sets an envelope on how high the regen current can be. You add foldback limiting to the torque based on battery voltage. So as the battery approaches its maximum voltage, the torque folds back to zero. In torque control mode, the torque is set by setting the Iqref and idref for the current PIDs.

    The user can request braking torque, but there is a maximum allowable amount of torque that can be requested. And then the requested torque will be subjected to foldback limiting based on battery voltage.

  • The other potential issue is, what is the maximum speed of the motor? If it may run at high speed while the battery is disconnected, even though all MOSFETs are off, then the DC bus voltage can climb to match the back EMF. So if this is possible, then the ADC overhead should be large enough to accommodate without damaging the ADC input.

  • I was thinking lab9 but add drv8353 code to set inverter to coasting after user set trajectory speed is reached. This does not specifically make use of a dyno to determine regeneration torque current, rater CCS debug analysis. So you set desired Idq.value[1] for an allowable current level as it defaults to torque idq.value[1] anyway upon flying restart, seemingly after a set delay time during Standby. When flying restart is not set in speed mode it defaults to torque idq mode as the original code was written SDK 2.01.    

    motorVars.flyingStartMode = FLYINGSTART_MODE_STANDBY; //FLYINGSTART_MODE_HALT

    Below snip added to set DRV8353 cost bit during mainISR(). Only sets COAST bit true the first time as not to bang SPI interrupt unless write/read verify fails. The routine keeps trying to change REG2 bit 2 until ePIE passes the IRQ up to CPU as not to cause faulting. Suppose it might be good to only allow few hundred SPI IRQ's to assert then exit out of mainISR(). They are nested IRQ's exist in different groups of core priority and SPI has very fast TXD/RDX times.

            //
            // run the flying start function
            //
            runFlyingStart(estHandle);
    
            //
            // run the speed controller
            // when speed control set true
            //
            if(EST_doSpeedCtrl(estHandle))
            {
                counterSpeed++;
    
                if(counterSpeed >= userParams.numCtrlTicksPerSpeedTick)
                {
                    if(motorVars.flagEnableSpeedCtrl == true)
                    {
                        counterSpeed = 0;
    
    					#ifdef DRV8353_SPI
    							// Check control REG2 bit 2 bool state
    						   if(drvSPI8353Vars.Ctrl_Reg_02.COAST == true)
    						   {
    							   // Disable Coasting NFETS ~high Z state
    							   drvSPI8353Vars.Ctrl_Reg_02.COAST = false;
    					 tryagain_1:
    							   // Write the update
    							   drvSPI8353Vars.writeCmd = 1;
    							   HAL_writeDRVData(halHandle, &drvSPI8353Vars);
    							   // Verify Control REG 2 Update
    							   drvSPI8353Vars.readCmd = 1;
    							   HAL_readDRVData(halHandle, &drvSPI8353Vars);
    							   // Something go wrong SPIA/B INT6.x IRQ ?
    							   if(drvSPI8353Vars.Ctrl_Reg_02.COAST == true)
    							   {
    								   goto tryagain_1;
    							   }
    						   }
    					#endif
    
                        PI_run_series(piHandle_spd,
                                      estInputData.speed_ref_Hz,
                                      estOutputData.fm_lp_rps * MATH_ONE_OVER_TWO_PI,
                                      0.0, (float32_t *)(&(Idq_ref_A.value[1])));
                    }
                    // Disabled speed control, do Torque Control Coasting Mode
                    else
                    {
                    	// Set coasting torque reference current, 0.0 set above
                    	// Typically inverter is not in High Z state 
                        Idq_ref_A.value[1] = IdqSet_A.value[1];
    
    					#ifdef DRV8353_SPI
    							// Check control REG2 bit 2 bool state
    						   if(drvSPI8353Vars.Ctrl_Reg_02.COAST == false)
    						   {
    							   // Enable Coasting NFETS high Z state
    							   drvSPI8353Vars.Ctrl_Reg_02.COAST = true;
    					 tryagain_2:
    							   // Write the update
    							   drvSPI8353Vars.writeCmd = 1;
    							   HAL_writeDRVData(halHandle, &drvSPI8353Vars);
    							   // Verify Control REG 2 Update
    							   drvSPI8353Vars.readCmd = 1;
    							   HAL_readDRVData(halHandle, &drvSPI8353Vars);
    							   // Something go wrong SPIA/B INT6.x IRQ ?
    							   if(drvSPI8353Vars.Ctrl_Reg_02.COAST == false)
    							   {
    								   goto tryagain_2;
    							   }
    						   }
    					#endif
                    }
                }
            }
            // Clear the Idq torque reference
            else
            {
                Idq_ref_A.value[1] = 0.0;
            }
    
     

  • Setting the DRV to coast is OK as long as we are not in the field-weakening regime. If field weakening is active, the back EMF may be larger than VBAT, so it is necessary to command zero torque rather than simply turning off all half-bridges. To make it more concrete, if the battery voltage is 50 V, and the peak back emf is 55 V, it is still possible to achieve zero torque using field weakening. But if you turn off all MOSFETs under this condition, they will passively rectify the back EMF and charge the battery and generate braking torque.

  • Do you have a chance to monitor the dc bus and motor phase voltage when the motor is running in generating mode with a negative torque current? Just want to make sure that the sensing voltage is not over the input range of the ADC.

  • I will post it for you to remove all doubt, but I am 100% certain that it is not out of range. We will have an update today with much more data in it.

  • they will passively rectify the back EMF and charge the battery and generate braking torque.

    Seemingly motor braking requires DRV8353 REG2 bit 1 set to enable low side NFETS, that effectively uses the stator coils as braking load resistors. In theory +VBUS over voltage condition gets squelched by the motor coils and the battery voltage remains mostly constant without need of BMS being alerted. It would seem an important point to regulate or modulate motor braking bit, so the stator coils don't overheat in long decent time to 0Hz. Braking bit control is nice feature of DRV8353 that standalone gate drivers like UCC27714 don't have.

    My custom inverter PCB has a separate PWM low side drive circuit for NFET offloading braking EMF onto external load resistor/s squelching +VBAT-VBUS over voltage conditions. It can be enabled by user control and triggers 20KHz braking interrupts via free PWM output on CMPA up/down match counts. The GPIO oscillates at 20Hhz drives the low side NFET driver IC and has a user set on/off period for brake resistor cooling.

    However, when motor has an over current fault condition the gate drivers HO/LO outputs are rapidly disabled and PWM-A/B outputs via HW action control are put into high impedance state (coasting). The high side NFET body diodes alone are said to rectify sinewave into halfwave DC pulses as short-lived high voltage regenerative energy. The bottom of the resulting wave form lies flat on scopes zero vector, DC probe setting. But does not overpower the supply during coast rapid deceleration to 0Hz since it is an unregulated linear DC supply with 6x 2200µF 250v electrolytics.

  • Are you asking a question or imparting advice? I am having trouble understanding your main point. If you have questions, I would be happy to answer them if I am able. I do not have any system design questions about braking. I have a few years of experience with system design of battery powered vehicles using regenerative braking. I assess my competence in this area as relatively high. The things you are saying about braking are a bit muddled, so I apologize if I am misunderstanding.

  • OK, I have some more data graphs to show. We are operating at low speed (about 770 RPM) in regen with Iqref set at -50 Amps. It appears to me that Vd is really messed up with very large ripple at 6x the electrical frequency. This seems to be the root cause of why the voltage waveform is so distorted. VBAT was at about 52 V. The VBAT ADC is not anywhere near numerical saturation. See last graph.

    Do you have any idea why Vd has so much ripple? I believe this is the root cause of why the output voltage is so distorted. Should we try tuning the PIDs, or adding a digital notch filter to remove the ripple from Vd  (and possibly Vq also?) What do you suggest? Do you think this issue could be related to the speed divergence (see my other question on this forum).

  • Are you asking a question or imparting advice?

    Your previous posts suggest there was issue in your ADC voltage divider design. There was no response posted as to having corrected dividers resistance values adding 30% ADC overhead. It is obvious you do not have full understanding of DRV8353 two braking modes mentioned, neither did I. Off handedly I suggested an alternative DRV8353 configuration can use INLC pin 39 with x69M PWM output interrupt to modulate low NFETS much like my system described above. That was more of a gee-whiz how nice those two features are for other future post readers.   

    The SDK (FOC) Lab6 code was not designed to work with a dynamometer with SPM motor in regenerative braking mode. The DRV8353 must be reconfigured sending SPI control codes to enable REG2 bit 2 when the motor is set into generator mode by the dyno. That course of action plan Yanming has not yet commented on being mostly unable to give such alternative advice due to forum policy. 

    Perhaps I've misunderstood you were using Lab6 (Torque Control 5a?)  during regenerative braking without reconfiguring DRV8353? Seem incorrect to modulate the inverter in Lab6 while the motor is being driven by a dyno (regenerative) without added code as I provided for Lab9 example. Flying start Lab9 gives the engineer time to get external riggings in order using CCS debug to control the DRV8353, seemingly with more control over regenerative experiment.

    Edit: The SDK (FOC) code is newer for x49c MCU. You would have to modify a similar Motorware Flying start lab or add the SPI control. The DRV8353 SPI control should be the same between MCU classes driver lib calls. Threw me off your using a newer Gate driver with an older x96M MCU class.

    LAB 5a.   Adjusting the supplied current controllers:

    Seemingly Motorware Lab5a was to adjust the PI current control for DRV8312 to ONLY run the motor.

  • You believe I have insufficient headroom on my VBAT ADC. But I think it is enough headroom, particularly since I am currently running at 52 V or so (look at the graph of VBAT ADC samples...). I may increase the headroom later, but in the most recent posted example, the battery voltage was 52V with a full scale ADC range of 66V. That should be plenty of headroom. (66 - 52) / 52 = 27 percent headroom. I am trying to focus on a specific problem and don't want to get side-tracked into lengthy discussions about basic EE stuff.

    We always operate in torque mode. We are implementing braking by setting Iqref to a negative value. It is not necessary to do anything special with the DRV chip to brake in this fashion. Braking works fine for the most part and produces controlled torque. We are only having difficulty at very high torque/current. So far, this basic issue has not been addressed by you or by TI.

    The type of braking where you modulate the low-side FETs together results in high current going through the high-side body diodes. In our application this will lead to overheating. In my previous job we implemented braking like this using the DRV8302. But in that product we did not use FOC. We used six step commutation and we had hall sensors to aid in start up. Then we transitioned to sensorless six step commutation after we were rolling (using back emf sensing to time commutation).

    I don't have the lab numbers memorized. I am a hardware engineer working with a FW engineer on this project. So I am not sure what Lab 6 is for you. For me it is motion stuff. We skipped the motion labs. Maybe the numbering is different for F2806xM vs the x49.

    Flying start is not an issue because we always stop the dyno when we start the controller. The dyno, which we designed and built, runs in speed mode and the motor we are controlling is in torque mode.

  • Do you have any idea why Vd has so much ripple

    Maybe the Id feedback value is significantly variable. Could you please check the Id reference and feedback values when run the motor in this mode and state?

    Should we try tuning the PIDs, or adding a digital notch filter to remove the ripple from Vd  (and possibly Vq also?) What do you suggest?

    Yes, you can try to use different Kp&Ki of the Id PI controller. To reduce the Ki first. Seems like the phase voltage waveform you captured by the oscilloscope has distortion, it's not right as the machine runs in motoring mode.

    What do you suggest? Do you think this issue could be related to the speed divergence (see my other question on this forum).

    Current waveform looks good, but the voltage waveform is not right as mentioned above. No more ideas about this, have to find the root cause on the voltage sampling signals. I have tried to repeat the issue, but it's not easy to do it till now in our lab.

    Can you help to check if the "gMotorVars.Flux_VpHz' has very big variable in generating mode vs. motoring mode?

  • I will try looking at the Id feedback values. Id reference is fixed at 0.

    I will check out gMotorVars.Flux_VpHz.

    The voltage waveform is the actual voltage waveform. The controller is putting out that voltage waveform. The voltage sampling process is not adding distortion to the voltage. Since the controller is putting out the distorted voltage waveform I am asking for your help to figure out why. Vd has a very distinct ripple at 6 x the electrical frequency. Do you have any idea what might be causing that? Have you ever seen it before? That 6 x ripple is visible in the voltage output, the current output and even the battery voltage has ripple at 6x the electric frequency.

  • But I think it is enough headroom, particularly since I am currently running at 52 V or so (look at the graph of VBAT ADC samples...)

    So you changed the resistors in the above divider schematic? The values are high according to the formulas and debug captures. The 2vPeak 500mV/cm is not close to MSB precision or +3.3xx -20% to 30%. That leaves 1.3xx volts up to MSB, seemingly will affect alpha beta wave forms in the Clarke transforms. The ADC can measure hundred or more DC volts in +1.3xx volts of head room counts.

    The ADC current wave forms (75 amps peak?) are well below MSB according to the debug plots just posted. I'd expect current peaks to be closer to 3585 counts or a bit below, again precision affects Clare transforms. BTW the scope capture (CH2) 100A P2P or 50A peak, that is well above 75A previously stated.

    We always operate in torque mode.

    That would be your Motor control suite Lab 4 not 5a. The universal motor control SDK used with LaunchXL_x25c MCU would seemingly be more compatible for newer DRV8353. There is a new embedded SVM with FAST and new eSMO Enhanced algorithm also embedded in x49c MCU according to Yanming. The x69M is nearing end of life unless you have few hundred on hand. Yet seems futile to start a new product design from x69 MCU class unless simply experimenting.

    It is not necessary to do anything special with the DRV chip to brake in this fashion.

    I wouldn't expect regenerative current will even flow from the motor into the battery with the inverter MOSFETS are being driven by the controller in torque mode even set with -50Id. That is why the DRV8253 has a control bit to disable the HO/LO drive outputs into High Z state. NFET body diodes are free-wheeling to protect the DS junction from inductive high voltage kick back when they switch off at various times. Perhaps your voltage wave forms are being distorting since the inverter NFETS are being stressed? 

  • I did not change the resistors. They are still 215k and 11.3k.

    On the one hand you seem to suggest that I am not making good use of the full range of ADC inputs for voltage. On the other hand, you seem to be indicating that I need to add headroom. Do  you not understand that those two things are absolutely directly contradictory? If I adjust the voltage divider by making the 11.3k resistor smaller, I will utilize even less of the ADC range. Please let me know if I need to go through it step-by-step with all the calculations. I am aware that TI design documents recommend having 30 percent extra headroom above the highest expected voltage. Perhaps, later, when we are using fully charged batteries, I will change the voltage divider ratio. But for now, with a battery at 52 V, there is no need to alter the resistor divider for VBAT or the phase voltages.

    Additionally, do you not understand the relationship between speed and voltage? This particular test was done at very low speed, so the motor output voltage is low. But we also operate at high speed. This is just the reality of the problem. If we were always going to operate at low speed we could use a different divider. It is inevitable that the ADC range will be poorly utilized at low speeds.

    You and I have discussed the current ADC already. It is not possible to utilize the full ADC range because the current shunt amplifiers do not have a linear response over the full rail-to-rail output range. In the most recent capture the shunt resistors are 300 uOhm and gain is 40 V/V. I do not have infinite freedom to choose any shunt value and any gain I want. I think this combination of 300 uOhm and 40 V/V will be OK.

    Idref was set to zero. Iqref was set to -50. Note that when the magnitude of Isref is 50, one expects that the peak current for each phase will also be 50. So the current shown in the oscilloscope is EXACTLY what it should be with Iqref set to -50. I do not know why you think that the current is "well above the 75 A previously stated." Obviously, 50 is less than 75.

    According to the TI website, the TMS320F28069MPZT is still in production. They have not issued any notice that I am aware of that it is not recommended for new designs. It probably would be better to use the x49, but they are very difficult to find, and availability is the main reason I selected the older processor. When is TI planning to discontinue the TMS320F28069? Did they tell you a specific date or they just told you it is nearing end of life? Does TI discontinue products without notice? Or do they normally issue a notice that it is not recommended for new designs and announce a last-time buy date?

    As far as your expectations go regarding regen, it seems that your expectations are different than mine. When using FOC, my expectation and experience is that negative torque results in regen current to the battery. In your experience designing, building and testing inverters using FOC and commanding negative torque, have you observed that there was no battery charge current? Or are your expectations based more on intuition rather than experience? Because in my experience testing our controller on the dyno with battery, negative torque results in battery charging current. This also matches theory and analysis.

    The voltage waveform is distorted BECAUSE THE INVERTER IS OUTPUTING A DISTORTED WAVEFORM. You can see this very clearly when you look at the Vd and Vq outputs from the PID or Valpha and Vbeta (after the inverse park transform). Valpha and Vbeta are used by the output stage of the controller to calculate the duty cycles that set Va, Vb, and Vc. So if Valpha and beta are distorted, the output voltage will also be distorted. It may help to look at the block diagram of how sensorless FOC works.


  • On the one hand you seem to suggest that I am not making good use of the full range of ADC inputs for voltage

    Right I'm saying the voltage peaks are nowhere close to MSB if that is 30% OVH. Seems much greater than PDF loosely worded text, closer to MSB. Seemingly with the correct divider values the signal will peak closer to MSB 4096 -30% is 2867 counts. The 215k seems high for 50v, I used 182k/3K9 for Nominal +100V and FSV +163.59V. You're right the current amplitude is ok does not use R dividers Flushed but does enter Clarke. Settling time for inductive current depends on the amplifier BW and CMRR, INA240-A1 claims 9.6µs settling to 5% of the output signal. The ADC window time for both might require tweaking and 3-5 PWM periods trigger delay up to SOC.  

    When is TI planning to discontinue the TMS320F28069?

    The older Motorware Control Suit was removed from REX if you use CCS try to find it there is no download links and recent updates have ended. You can get an LaunchXL-x25c from Digikey (Last checked 5 stock) and the universal motor control RDK directly supports DRV83xxRS see Pg.21 Fig.2-15 attached PDF. /cfs-file/__key/communityserver-discussions-components-files/171/TI_2D00_F2802x-Motor-Control-SDK-Universal-Project-and-Lab.pdf 

    So if Valpha and beta are distorted, the output voltage will also be distorted

    Agree but why are the Clarke EMF inputs distorted the bigger question, seems power supply related seeing VBat signal. Curious if you leave Lab 4 default torque settings do the EMF signals improve with positive torque values?