unfortunately I need to help with a solution the of very sad problem. I have destroyed 2 odrives. Both of them have damaged U4 - driver from TI. I am not sure if even anything else. I am going to replace all damaged parts, but…
Does somebody has any idea about possible case. Most important is to avoid it to the future. So I would like to know the root cause of this. Very thank you for any help…
U4 is most easily damaged by overvoltage and/or inrush surges. Make sure your 48V battery is never charged to more than 56V, and use anti-spark connectors e.g. “XT90-S”
Thank you towen for idea. Fully charged battery has about 54V, of course there is possibility to swing a little bit due to cables inductance. Maybe that is a root cause. On both modules was as first damaged U4 which is providing even a 5V out from buck. I use this voltage even for powering a control board with uC with shielded cable, maybe this could catch some noise…
Anyway I am going to optimize cables routing, decrease a little bit battery voltage (I will discharge some energy to be in nominal voltage levels), and do a galvanic insulation of control board. I hope, that it would be enough to stay “alive”…
Is it even possible to destroy board with bad configuration??? Or only possible way is to find a problem in interconnection. What is exactly the critical parameter that could leads to defect?
Last question I have about maximal current limit and requested current limit. I am not sure if one is basically used as set point for torque control and second is used as a threshold for error?
If not, which parameter is used for torque control limit in velocity control?(I don’t want to apply so big torque to reach it).
I think the U4 is the first to blow on an inrush surge just because it is located at the end of the board.
If you very suddenly connect ODrive to a high voltage, low resistance source like a 54V battery, then a very large current will flow into the capacitors. It gets to the capacitor nearest the connector “first” (we’re talking about nanoseconds here, but because the board has non-zero resistance and inductance, there is a time constant) when it gets to the last capacitor, the inductance causes the voltage to continue rise past the battery voltage, like a wave crashing.
Please use anti-surge/anti-spark connectors, or a pre-charge circuit if working near to the voltage limit of the board.
It shouldn’t be possible to destroy a board (of course, you can burn out a motor or a brake resistor with bad config) and nothing in your config looks ‘bad’ although you should perhaps set dc_bus_overvoltage_trip_level to 55V instead of 60V
Did the failure occur when you first connected the board to the battery, or when you tried to drive a motor? What was the last thing you did before the smoke came out?
The torque limit is controlled by motor.config.current_lim
The other parameter requested_current_range relates to the gain of the current sense amplifier, and it should always be much higher (1.5x - 2x) than the current_lim otherwise the current sensor can saturate.
A first board was destroyed immediately after commanding a velocity from external controller, not by powering on. Second was something similar - after commanding a board for velocity there was a DRV_FAULT error occured. After rebooting a drive a controller parts were destroyed.
As long no DRV8301 are currently in stock, I have ordered brain new odrives. But I need to do even a better settings regarding controller and motor. On my motor there is 2 independant endcoders - HAL and INCREMENTAL with index. According tests, it looks much better to use incremental with uncomparable better resolution (Incremental10000cpm / HAL26cpm). Behavior on low speed and as long a torque on NO speed is much better with incremental. But I am not able to do encoder calibration with index search request. Signal from incremental is very noisy. My encoders have differential signals but odrive takes only single ended, so a noise is still propagated. I have added a small capacitors to index pins but without significant improovement. Does somebody any idea to do additional filtration to incremental encoder???
How are you converting from differential to single-ended?
I would recommend that you use a triple RS-422 reciever chip e.g. MAX3097. Don’t just connect one side to GND.
As you said, I simply use only positive terminal from all sensors and ground. I didn’t have any another possibility. Of course - using of differential driver would be fine, but I don’t have currently one. Tomorrow is deadline for presentation…
I am going to use HALL sensors, but my device configuration is tracked vehicle and behavior on low speed is critical (it provides huge friction) - especially a rotation. Overcurrent sense is very often presented. Currently I am on top - 100 A current limit with 20 A margin, but it would need even a little bit more power. Commutation would be much better with incremental, but there is still problem with calibration, so I am unable to use it …
Thank you all. Presentation turned out well. Odrive is still alive But for the future I need to handle more power than can provide odrive. So I am looking for VESC.
Second important thing is to solve encoder requirements - for weak zero speed torque in some angle and torque handling in general as well I cannot use halls. The best way for me is to obtain a absolute encoder.
But for the future I need to handle more power than can provide odrive. So I am looking for VESC.