Quantcast
Channel: Motor drivers forum - Recent Threads
Viewing all 22142 articles
Browse latest View live

DRV8353RS-EVM: REGENERATIVE BRAKING

$
0
0
Part Number: DRV8353RS-EVM
Other Parts Discussed in Thread: DRV8353

Tool/software:

Hello team,

Currently, I am working on regenerative braking using DRV8353 EVM and f2800157 launchpad.

I want support from TI experts to implement regenerative braking in the universal motor code.

Currently I am working on 24V encoder motor, and we are able to run the motor in both FAST and ENCODER estimator methods and in all build levels.

I attached the motor data sheet for reference.

Can you please suggest some documents regarding regenerative braking. I want to know which sides of the MOSFETs we need to switch during this condition.

Currently we are running our motor in speed control mode. I want to know, can we able to implement regenerative braking in speed control mode or we need current control mode only (Torque control mode) ?

As I know, in universal motor code we have different types of braking.

I want to know, apart from this, anything is there, related to regenerative braking in universal motor code?

I want to implement regenerative braking in build level 4 under MOTOR1_ENC estimator.

Please suggest the way to implement this in our code.

Thank you,

Regards,

Kirana H P


DRV8718-Q1: schematic review

$
0
0
Part Number: DRV8718-Q1

Tool/software:

Hi team,

Could you please help review the schematic and give some suggestions? Thanks.

Regards,

Ivy

DRV3946-Q1EVM: Schematic Request

$
0
0
Part Number: DRV3946-Q1EVM

Tool/software:

Hello,

I'd like to request the schematic for the DRV3946-Q1ECM board.

Thank you!

MCT8315ZEVM: Unable to Hold position.

$
0
0
Part Number: MCT8315ZEVM

Tool/software:

Hello all,
I am using the MCT8315ZEVM to drive BLDC motors with Hall sensors. I am trying to implement position control  (or servo like behavior) with the help of EVM board. Currently I am running into the following issues: - 

1) The nFault triggers when the motor stalls. (We need motor to stall for position control).
2) This is also seen when the motor changes its direction. There is a delay due to nFault toggle which results in jerky behaviour of the motors.

Is there a way to resolve this issue by bypassing the nFault flag and achieving the position control?

Thanks,
Parag

DRV8889-Q1EVM: Problem with getting correct data using DRV8889-Q1 GUI v0.1.0 for tests with DRV8889A

$
0
0
Part Number: DRV8889-Q1EVM
Other Parts Discussed in Thread: DRV8889-Q1

Tool/software:

Hi all,

I have downloaded the DRV8889-Q1 GUI v0.1.0 for tests of the DRV8889A using an updated DRV889-Q1EVL. It works OK regarding being able to set and clear the specific bits for the new options in the DRV8889A driver. But I have problem when try to export the TRQ_COUNT values.

One thing is that values in the TRQ_COUNT stays quite high when I stop the motor, so it isn't possible to get data for the start of the motor.

Another issue is that the data file is getting very big as data are put into the file all the time also when the motor has been standing still for longer time. The only way I have found to reduce the file size is to close the GUI SW and open it again including setting driving paramters.

A third issue is that when opening in excel are the data looking strange. Values are not read correct in to excel. It can help opening the file with notepad first and then copy from notepad to excel.

Are there some which have seen similar behavior and have solved it?

Some examples:

DRV8703-Q1: VDS Fault Error

$
0
0
Part Number: DRV8703-Q1

Tool/software:

Attaching the Motor drive schematic. When the circuits related to Q35, Q36, Q4, Q3 is removed we see Motor fault. But when populated it is working. we identified that there is register control for the VDS fault. So the register  at address = 0x01h bits 0 & 1 via SPI. But when we are still seeing this fault. Can you suggest what could be issue? What can be done otherwise?

e2e.ti.com/.../Low-Motors.pdf

DRV8353: SPI Start-Up power requirements

$
0
0
Part Number: DRV8353

Tool/software:

I am building a BLDC motor control system using a DRV8353. I am having trouble getting the SPI communications functioning. Do I have to apply power to VM before I can begin communicating with SPI to set it up?  I don't want to apply high-voltage power until the DRV8353 is fully configured. What am I missing here?

DRV8334: Extra Gate Driver Current

$
0
0
Part Number: DRV8334

Tool/software:

Hello,

Is it possible to piggy back more current into the charge pump circuitry with external connections?

Thank you, Keith


MCF8316AEVM: Not able to get any motor activity

$
0
0
Part Number: MCF8316AEVM
Other Parts Discussed in Thread: MOTORSTUDIO, , MCF8316A

Tool/software:

I have an MCF8316AEVM board with a known good BLDC motor connected and I have tried using MotorStudio 0.1.22 and also web-based GUI https://dev.ti.com/gallery/view/BLDC/MCF8316A_GUI/ver/1.1.9/ but was not able to make much progress with either.

I noticed that the EVM board has a MCF8316C chip on it, and MotorStudio doesn't recognize the MCF8316A device, but does connect to the board using the MCF8361C option.  But I don't get far with this app as it asks for a file to "load preset values".  I didn't see any configuration files with the download or online.

I tried the online GUI and it connected to the board fine as MCF8316AEVM, and I tried to run through the guided tuning.  I set analog mode and max frequency and current, default registers, and tried to start MPET under Basic Controls -> Controls Configuration, by enabling MPET_R, MPET_L, MPET_KE, and MPET_CMD.  Nothing happens with the motor.  There are no faults.  

Please let me know what I might be doing wrong.

Thank you

DRV8328: VDSLVL setting (disable by tied to GVDD) with DRV8328A

$
0
0
Part Number: DRV8328

Tool/software:

Hello team,

When VDSLVL is tied to 100kΩ, VDS overcurrent protection is "disable completely" or "just set large reference threshold"? We are concerned about large pulse voltage when motor starts/stops.

Best regards,

Shotaro

ULC1001:Power management forum

$
0
0
Part Number: ULC1001
Other Parts Discussed in Thread: TCA6408A-Q1

Tool/software:

If my host I2C is 1.8V and I want to link I2C with ULC1001 that just only use 3.3V. Should I add level shift IC to contact I2C wiht ULC1001 ?

And add use TCA6408A-Q1 that I2C link my host 1.8V and can I/O expander 3.3V to control SDZ and OUTOFF pin. 

Thanks.

DRV3245Q-Q1: Occasionally unable to open using DRV3245A as a pre-driver

$
0
0
Part Number: DRV3245Q-Q1

Tool/software:

When using the DRV3245 pre-driver, there is an occasional problem of pre-driver open failure in the same software and hardware environment. Reading the value of the fault register did not find any fault. I want to know what requirements need to be met for the timing between pulling up the EN pin, chip self-test, and turning on the pre-driver. Or is there anything else I need to pay attention to?

DRV8000-Q1: DVDD 3.3V

$
0
0
Part Number: DRV8000-Q1

Tool/software:

Hi team,

Could you please share your suggestions for below questions?

1. If the DVDD is 3.3V,what values should the RS_GND and RS_PVDD be?

2. Because OUTx output fault detection is related to the value of VDVDD. If 3.3V is used for fault detection, OUTX_PU and OUTY_PD both detect an open circuit, then the OUTX and OUTY values are always 1.65V, which is 2V below the OLP_REFL values. Does this indicate that the chip is consistently reporting the fault? Does the DRV8000-Q1 support 3.3V DVDD systems?

Thanks!

Regards,

Ivy

MCT8316Z: Unexpected motor lock fault behaviour

$
0
0
Part Number: MCT8316Z

Tool/software:

We are having an issue with the MCT8316ZT (hardware variant) whereby we cannot consistently recover from a motor stall event.

First to outline my understanding of the expected behaviour:

- if the motor is driven but the Hall sensors don't change state during the period defined by the motor lock time (nominally 1 s), the MCT8316 enters motor lock state.
- the hardware variant of MCT8316 uses the latched motor lock mode: the FETs are disabled and nFAULT is driven low.
- to return to normal operation a "clear faults command" needs to be issued: nSLEEP needs to be pulled low for 20-40 us (t_RST). see section 8.4.1.3

Now to the observed behaviour:

- when the motor is stalled — note this can be accomplished in less than the nominal motor lock time — the FETs are disabled and the motor does not start turning again, even if there is nothing preventing it from doing so (i.e. the cause of stall has been removed)
- when stalled, nFAULT goes low for 0.5 s and then high for 1.0 s — this cycle repeats indefinitely. When nFAULT is high, current draw from PSU is higher than when it is low.
- issuing the clear faults command — 30 us NSLEEP reset pulse — does *not* return the system to normal operation. It appears to have no effect whatsoever, regardless of DRVOFF state.
- we have identified two ways of returning to normal operation:
  - 1) slightly nudging the motor shaft — this always works, but is not a viable solution in our application
  - 2) power cycling the system — this works most of the time, but sometimes the fault appears to be latched, i.e. after powering back up and making DRVOFF low, nFAULT goes back into the 0.5 s low / 1.0 s high cycle described above. This is the case whether DRVOFF is high or low during power-up.

Some other points worth noting:

- we are using a custom PCB (I will try to recreate the issue with the evaluation board)
- DRVOFF is used as "enable" signal, i.e. to start and stop motor
- the PWM signal is always on; frequency approx. 22 kHz; duty cycle setting has no effect on observed behaviour.
- nFAULT is connected to VBK (5 V) via 5k1 resistor
- if the circuit is powered on with DRVOFF high, nFAULT is low, but nFAULT goes high when DRVOFF is made low. According to 8.4.2, DRVOFF "...can trigger fault condition resulting in nFAULT getting pulled low"; observed behaviour is therefore not unexpected.
- although nFAULT is low during power up (suggesting device may enter "test mode"), it is believed that test mode is *not* entered because it is possible to drive the motor (which from tests does not appear to be the case in test mode).

To summarise problems:

- MCT8316 sometimes enters motor lock state a lot faster than what "motor lock time" suggests
- nSLEEP reset pulse does not clear motor lock fault
- Power cycling the system does not consistently clear motor lock fault

Any help with troubleshooting would be greatly appreciated.

Many thanks

DRV8220: MCU resets when driving a solenoid latch valve

$
0
0
Part Number: DRV8220

Tool/software:

Greetings.

I'm currently developing a board that has, among other things, an ESP32-WROVER-E microcontroller and a DRV8220-DRL H-bridge motor driver, which I use to drive a 12 VDC latching solenoid valve, model Aquative Plus from Netafim (click HEREfor datasheet of the valve).

The problem is that, when I put the DRV8220 in forward or reverse drive to turn ON/OFF the valve, the microcontroller just resets, and even when that happens, current continues to pass through the valve, which is not good given that it's a latch valve, so it shouldn't have current continuously passing through it.

Now, for some context, here is some data about the board. The board is supposed to run with a battery of 3.7 V, so it has a battery charger IC, but for these tests, I'm putting a power supply directly where the battery should be, which means that I'm "bypassing" the charger IC. After that, I have a Buck-Boost power supply of 3.3 V, which I use to power both the microcontroller and a Boost power supply of 12 V. That Boost PS is the one that powers the valve.

Here is the circuit of the DRV8220 IC:

The IN1 and IN2 pins are connected directly to the MCU.

Also, I have put filter capacitors in the MCU, technically to avoid that reset problem (which obviously doesn't happend). This is the circuit for the "ENABLE" pin of the MCU:

And this is the circuit for the 3V3 line of the MCU:

As extra information, I've tried putting some resistences in series with the valve, in an attempt to try limiting the valve current, but it doesn't prevent the MCU reset.

Also, I've tried the following DRV8220 sequences for driving the valve:

Sequence 1:

  1. IN1 = 1, IN2 = 0 (Forward Drive)
  2. 200 ms delay (also tried 50 and 100 ms)
  3. IN1 = 0, IN2 = 0 (Sleep)

Sequence 2:

  1. IN1 = 1, IN2 = 0 (Forward Drive)
  2. 200 ms delay (also tried 50 and 100 ms)
  3. IN1 = 1, IN2 = 1 (Brake)
  4. 1 sec delay
  5. IN1 = 0, IN2 = 0 (Sleep)

My guess is that, when driving the valve, a current peak appears, which causes a voltage drop in the 3V3 line, which causes the MCU to reset. But technically I've design all power supplies to stand up to 2 A of current.

Any ideas of what could be happening? If any more information is needed, please let me know. Thank you all.


DRV8320: Clearing GDF on hardware version

$
0
0
Part Number: DRV8320

Tool/software:

Hello,

I am investigating using the DRV8320H as a possible replacement for a different motor driver we're using that has gone obsolete.

We are trying to make the change without doing a software change if at all possible (which means the SPI version is not really an option).

My question is specific to the GDF since this appears to be a latching fault. 

I found this comment in another thread...

"The only way you can clear the fault on the hardware version is by toggling the ENABLE pin to reset the device. There is no retry time because this is a latching fault."

Will putting the device to sleep (de-asserting Enable) also clear a GDF that has occurred? Or does it only clear on a reset pulse?

Thanks

DRV8873: DRV8873HPWPR

$
0
0
Part Number: DRV8873

Tool/software:

Dear Murugavel,

Can you help me with calculating the RC network when I connect the Peltier Element (TEC1-12706 or TEC1-12709)

  • the power supply can handle 12VDC/5A
  • the PWM frequency = 10kHz

Thanks in advance

Piet

Motor drivers forum

$
0
0
Part Number: UC1625-SP

Tool/software:

Hello.

I am looking for a motor driver.
I am considering using UC1625-SP with the configuration shown in the attached diagram.
I would like to use the Hall sensors (H1, H2, H3) with a pulse of 17 to 267 Hz, and feedback control using the Hall sensors.
I am also considering making the Speed ​​Control signal variable at 10 kHz duty.

My questions are as follows.
(1) What kind of signal output is PUA, PUB, PUC and PDA, PDB, PDC? Also, what is the timing?
(2) When inputting Speed ​​Control from outside as shown in the attached diagram, should it be input to pin 1 (E/A IN+)?
     In that case, what is the relationship between the Speed ​​Control voltage and the Outputs duty?
(3) Please tell me the recommended part names for the diodes and Zener diodes that are not listed in the Datasheet Figure 15.
(4) Is there a function that outputs twice the frequency of the Hall sensor signal as shown in the attached diagram?
(5) Is it possible to use the UC1625-SP in the configuration shown in the attached diagram? Also, are there any other class V parts you can introduce?

Thanks and Regards,
koji

DRV8412: DRV8412 Datasheet Revision H changes

$
0
0
Part Number: DRV8412

Tool/software:

Hello,

Can i know the reason of this change ? : Changes from Revision G (July 2014) to Revision H (July 2024): Deleted values in 39 to 200 in Table 6-2 .

It's about the Programming-Resistor Values and OC Threshold.

Because it's impossible to calculate this value ourself ,its a non linear relationship and no formula is given.

And the ROCP_CBC OC programming resistor range in cycle-by-cycle current limit modes is still 24-200 kΩ

I thought i was going crazy because i had a 84kohm value in a design and can't find a relationship with this value and the new 4 values table. Hopefully someone posted a screenshoot of the old table somewhere in the forum.

Thanks!

DRV8889-Q1: Stall fault bit is not clearing immediately, is inconsistent

$
0
0
Part Number: DRV8889-Q1

Tool/software:

We have custom hardware talking with the DRV8889(latest SI rev of the chip).

We have verified normal operation, by stepping and stalling the motor. Communication packets look good and have been verified.

Open load detection is disabled in our case.

Observation:

  1. When a stall condition is detected, it lowers the Faultline, which is an ISR into our host software.
  2. Host software detects the fault line go low(or high) and send a command to clear the latched faults.
  3. A readback from the fault status register, 1ms. later, shows the stall bit still set.
  4. However a clear fault issued again ~250ms later, clears the fault

Question:
Is there a minimum time for the DRV8889 for the stall to clear? Is yes, where is this time specified. If no, how do we calculate this?


Additional info:

The register values we use are below:
FAULT: 0xA5
DIAG1: 0x00
DIAG2: 0x00
CTRL1: 0x83
CTRL2: 0x0F
CTRL3: 0xA4
CTRL4: 0x31
CTRL5: 0x18
CTRL6: 0x0C
CTRL7: 0x00
CTRL8: 0x03

Viewing all 22142 articles
Browse latest View live


<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>