DRV10983EVM: A DRV10983 IC driving a Maxxon ECX SQUARE 16 L sensorless brushless BLDC motor switches off intermittently after a stall torque is encountered and continues to stop intermittently even after the stall condition is removed

Part Number: DRV10983EVM
Other Parts Discussed in Thread: DRV10983, DRV10987

We are using a DRV10983 IC for driving a Maxxon ECX SQUARE 16 L  sensorless brushless BLDC motor, but when we try to run it with all the motor-lock safety checks enabled and a stall condition is introduced, the motor switches off as expected but once the stall torque is removed and the motor switches back on, the motor - driver keeps detecting lock condition and switches off intermittently. Is this normal? how can we avoid this?

  • Hey Jain,

    Can you check register 0x1E and 0x10 and tell me what bits are set here? 

    If you could also provide your EEPROM settings that would be nice. Alternatively you could post some screenshots from the basics, advanced, and display tabs on the GUI.

    After the stall is introduced, and tLOCK_OFF elapses, the device still thinks there's a fault. So checking these registers after tLOCK_OFF elapses will tell us more about exactly which LOCKx is getting triggered. 

    Thanks,

    Michael

  • Dear Michael,

    We have got the screenshots you requested. Attached the same along previous reply.

    Please refer and tell if any more data is required 

    Thanks,

    Jain James

  • Hi Jain,

    Just to clarify, after the stall is removed, and after tLOCK_OFF elapses, the motor still does not spin.

    If that's correct, please see below. 

    I believe that the GUI is not refreshing the left hand side of the screen, thus not showing us which LOCKx got triggered. The problem with having both auto refreshes enabled is that only one will get refreshed at a time, the other you will have to manually refresh. Please manually on the the display tab (left side), and let us know what LOCKx is getting triggered.

    Thanks,

    Michael

  • Hi Michael,

    Clarifying on your question whether the motor spins after stall is removed, it does, but after sometime it stops again even without the stall being present. 

    As to the auto refresh problem, thank you for pointing out this. We will manually refresh the left side from now on and get back to you with further data.

    Thank You,

    Jain

  • Lock bits during intermittency

    Hi Michael,

    I am attaching the image of the lock bits that turned on during the intermittent stoppage of the motor. Please do refer and reply with you inferences.

    Thanks

    Jain

  • Hey Jain,

    I see, you're hitting the overcurrent limit of 2.4A that you have set in the basics tab.

    You may have to adjust this value. Before you do this, I would suggest tuning your lead angle. We have a video on how to do this here.

    Also, we have a tuning guide for DRV10983. Take a look at these two references and let me know your results. If you need additional help on this, please let me know.

    Thanks,

    Michael

  • Hi Michael,

    The over current limit that the GUI shows as being drawn have been tested from our side and the motor seems to have only drawn 0.7 A at that point. We have verified it from our side using a current sensor output on CRO. Infact in none of our stall torque tests did the motor take more than 1.2 A. What would be the reason for it, when the drivers continuous current capability itself is 2A?

    About the lead angle, we look into it using the provided video and tuning guide that you have provided.

    Thank You,

    Jain

  • Hi Jain,

    Can you share the phase current plot? There could be a sharp spike in the phase current that is triggering the OCP fault.

    Please let me know about the lead angle, I think tuning this will likely solve your issue.

    Thanks,

    Michael

  • Hey Michael,

    Could you please guide me through as to how to take the phase current plot, we only had a current sensor that detected the total current going in and also as I told you earlier the total current going in had never exceeded 0.9 A (even under stall condition). 

    According to what I understand, the lead time parameter specifies the lead angle, is that right? If so, I have varied it to see any difference in current draw and there was no visible difference. 

    On Friday, I took out the software current limit parameter that was kept at 2.8 A and changed it to disabled and all the motor lock safeties were already disabled and the motor for the first time drew up to 1.71A.

    Thanks,

    Jain

  • Hey Jain,

    You would take a current probe, with the arrow of the current probe pointing towards the motor (current flowing into the motor). 

    Please tune your kt such the estimated kt matches your programmed kt. I calculated that your programmed kt should be 39.84056.

    The torque constant of your motor is 6.34 mNm/A, with one pole pair. Which converts to 39.84056 mV/Hz. You can see this calculation here:

    Regards,

    Michael

  • Dear Michael,

    The torque constant of our motor is not 6.34 mNm/A, rather it is 8.32 mNm/A (It is the 18V motor given in the motor datasheet). Calculating by the formula you gave, we get 52.276 mV/Hz. We are using a slightly lower value of 47.7 mV/Hz on account of better performance observed under the same.
    In reference to my earlier question on as to why the motor never draws current more than 1 A when software current limit is set at 2.8 A, could you please explain as to why this is happening?

    Thanks,

    Jain

  • Hi Jain,

    I will get back to you shortly!

    Regards,

    Vishnu

  • Hi Jain,

    Are you still seeing "Current limit" fault getting triggered? At what electrical speed does the device trigger "Current limit" fault? Can you review the App note on tuning lead time? Current limit can get triggered when the estimated Kt in closed loop is incorrect. You can tune the Lead time to achieve accurate Kt estimation in closed loop.

    About your question on software current limit, software current limit limits the voltage applied to the motor to ensure the phase current does not exceed the programmed software current limit threshold (refer to section 8.4.6.1 in the datasheet for more details). Your motor does not draw more than 1A when Software current limit is set to 2.8A because the phase current is not aligned with the BEMF voltage. Tuning the lead time will ensure phase current is aligned with BEMF voltage. Equation 7 in section 8.4.6.1 holds good only when  phase current is aligned with BEMF voltage.  

    Regards,

    Vishnu.   

  • Dear Vishnu,

    Yes, we are seeing the current limit fault getting triggered when the motor lock safeties are on. We have tried changing the Lead time from 100 to 400 μs but did not observe any current drop. However, we will ensure the results once more using the method described in the app note.

    We would also like to know, other than the motor lock safeties, software current limit and AVS protection, is there any other in-built safeties that is not accessible from our end, which may cause the driver to switch off and restart the motor?

    We would also like to know what are the ways in which we can get the phase current data other than using probes? 

    Thanks and Regards,

    Jain 

  • Hi Jain,

    Section 8.4.7 in the datasheet lists all the lock functions and protections in the device. In your application, is the device triggering current limit fault only? If that is true, then I don't think there could be any other lock functions that could trigger a fault condition. You can connect a resistor in series to the phase wires and measure the voltage drop but it won't be accurate. Using a current probe would give you instantaneous values and can help through the debug process.

    Regards,

    Vishnu, 

  • Dear Vishnu,

    We have currently disabled software current limit and all motor lock safeties, leaving only mechanical AVS enabled. So according to what you said so far, there won't be any other safety feature that can cause driver to switch off the motor and again start it after sometime. Is that right? If so, please do confirm it

    We have tried tuning lead time using the method mentioned in the app note, however the presence of noise from the sensor output of the current sensor prevented us from observing the variation of current with change in lead time. Although we observed that when lead time was between (400 - 480)μs there was a drop of 0.02 A in the current drawn from the power supply. Should we set our lead time a value between (400-480)μs based on this observation?

    Thanks and Regards,

    Jain 

  • Hi Jain,

    Vishnu will respond shortly!

    Thanks,

    Matt

  • Jain,

    Even if all the locks are disabled, device can still trigger overcurrent protection (OCP) fault . OCP fault cannot be disabled. You can set the lead time to 400-480 us and see if you can operate your motor at higher speeds.

    Regards,

    Vishnu

  • Dear Vishnu,

    As we have said earlier currently software current limit and all motor lock safeties are disabled, leaving only mechanical AVS enabled. So according to what you had said in the previous reply, device can still trigger overcurrent protection (OCP) fault. Then, could you please brief me on how the overcurrent is detected by the motor driver in this case?

    Also, we have tried putting lead times between (400 - 480)μs with software current limit enabled at 3 A  but still the motor driver drew only up till 1 A maximum (as shown on power supply) under stall condition. The estimated Kt is put at 47.7 but the estimated Kt varied between 33 to 56 as the speed varied from 15% to 75%. Can this affect the driver calculations in any way? Could you please confirm if this is normal?

    Thanks and Regards,

    Jain 

  • Jain,

    DRV10983 provides three current limit modes as shown in below table. Acceleration current limit is same as software current limit. DRV10983 has an internal comparator that compares the current, as measured from the FETs with the IOC-limit threshold. Overcurrent (OCP) gets triggered when the FET current exceeds the threshold. 

    I think there is a transient spike in the phase current that triggers OCP. 1A that you are measuring might be the steady state current. You can try DRV10987 which has higher current rating.  

    Regards,

    Vishnu

  • Dear Vishnu,

    We needed your assistance on one more point that we raised earlier, the estimated Kt is put at 47.7 but the estimated Kt varied between 33 to 56 as the speed varied from 15% to 75% (I2C values: - 76 - 380). Can this affect the driver calculations in any way? Could you please confirm if this is normal?

    Thanks and Regards,

    Jain 

  • Hi Jain, 

    Monday the 6th is a U.S holiday and we are out of the office, a team member will get back to you in a couple days.

    Regards,

    Michael

  • Hi Jain,

    Thanks for your patience. Estimated Kt changes due to the change in speed/torque. Lead time should be adjusted to maintain a constant Kt at different load points. When speed changes, the angle between phase current and BEMF voltage changes. This change in angle will cause variation in the estimated Kt. For more details, please refer to this video

    Regards,

    Vishnu

  • Dear Vishnu,

    We have seen this video earlier for tuning the lead time. As we have mentioned earlier lead time has been put at the value where the steady state current drawn is the least for a given speed. Still, the estimated Kt is seen to be varying with load, is this expected?

    Thanks and Regards,

    Jain

  • Jain,

    Yes, the estimated Kt will vary with load. As mentioned in my previous post, when speed changes, the angle between phase current and BEMF voltage changes. This change in angle will cause variation in the estimated Kt. Estimated Kt will be equal to the actual/programmed Kt when the phase current and BEMF voltage are aligned. When both signals are misaligned, a component of phase current will either weaken or strengthen (depending on the polarity of the current) the rotor flux and cause variation in estimated Kt. 

    Regards,

    Vishnu