Firstly, some premises of the design are related to the high speed needed (maximum as possible) and precise stop point. The motor is feed at a maximum of 40V and consumes at normal operation 1.5A. Due to this I've relied on the L6203, which at begins seemed a good choice.

The machine operates on a cycle that it goes forward and then goes back. It should be done at the minimum time as possible unless the user selected a lower speed. It does also have to stop every time at about the same point (chosen by user). Some tests showed us the great variance at speed given different conditions, like temperature, voltage level on net or mechanical differences. Due to the speed requirement and because there is none acceptable overshot (the machine can't goes back while on a forward command) I've discarded an implement of a PID or another simple control. The machine knows the stop point by an optical encoder and it's behaving well (the problem is really the variations on speed).

Even that it does not stops as desired, the robustness is validated. The machine is being tested at several weeks, sometimes 24h a day and did not shown any worrying issue even without any fan attached on L6203. It has worked on a nonstop routine since Friday until almost now.

I think the easiest way to stop it is by an electronic brake. But the L6203 apparently does not allow this function (I've already searched for Appnotes, reread DS and searched on a tons of sites). Beyond this, I think the L6203 has some issues regarding to dI/dT, because at the begin of the project some bridges were blew, solved by a greater delay between the direction reversion.

So, to brake it, I've made an auxiliary PCB and did minor modifies on the uC code. The PCB consists on a TRIAC which triggers when A and B are 0 (transistorized NOR) closing a loop and braking the motor. To avoid damage on L6203 I've programmed to send 0 to its enable port right before send 0 to both directions (so I'm sure the L6203 is off when the motor is being braked). Also, to avoid turning it on again while the motor is short-circuited, it has a delay between trigger some direction and enable the L6203 (so I'm sure the brake is cut before the L6203 is enabled again).enter image description here

The snubber, although delays a little the brake, was added to limit the dI/dT (a critical spec on triacs).

My last L6203 has burned on a mistake during the test with the brake board. I believe due to a mistake while connecting the command (A and B). So I can't test it before thursday.

The questions are:

  1. Does the TRIAC (precisely the BT139-800E) provides a reliable operation on this design?

  2. Is there any simpler way (and cheaper) to brake the motor while still using the L6203?

  3. Are there any other issues with all I've described before?

If needed I can also upload the entire schematic or the code.

  • \$\begingroup\$ The change of H-bridge is not discarded and I'm also studying the possibility of make my own CMOS one \$\endgroup\$ – Pedro Quadros Aug 4 '15 at 19:30

Your TRIAC circuit looks like it should work OK, however it shouldn't be necessary because the L6203 automatically brakes the motor whenever both inputs are high or low (and ENABLE is active). If you apply PWM via IN1 or IN2 then it operates in Synchronous Rectification mode (called 'one phase chopping' in the datasheet) and the motor will be dynamically braked whenever it is running faster than the set speed. Simply turning PWM down to 0% will apply maximum braking.

Brake strength is limited by resistance of the braking circuit. In the L6203 two FETs are in series so the total braking resistance is about 0.6Ω (0.3Ω per FET). To be effective it needs to be much lower than the motor's internal resistance (which I am guessing is about 10Ω for a motor that normally draws 1.5A at 40V). If motor resistance is too low then braking current could exceed the driver's rating and an external brake circuit would be required. however the braking current won't normally go higher than the starting current - so if the L6203 is able to start your motor without being overloaded then it should also be able to stop it.

If you don't use PID and just stop the motor when the optical encoder reaches a particular position then it will run on past the stop point (you cannot prevent this from happening because the motor's braking torque is limited, so it cannot stop instantly). To stop at a precise point you need to start braking before it gets there.

Exactly when you need to start braking depends on how fast the motor is going and the mechanical loading on it. The optical sensor tells you how fast it is going, and current draw or PWM required to get that speed gives you an idea of what load is applied. Using this information you could adjust the braking point to match the known stopping times under those conditions, either by calculating it in real time or using a lookup table of predetermined values.

  • \$\begingroup\$ Firstly, there's enough torque to instantaneous stop the motor (at least on tests I did). Secondly, on the first tests some L6203 burned, probably because I inverted the command (forward x backward) before the motor stops. I said probably because when I raised the delay between the reversion (so there is enough time to the motor totally stops) all the things gone well. Finally, this "lookup" table will not work. Since, as I said, there are various factors that influences the motor speed, so is needed a closed loop control (if the break does not works as I expect). \$\endgroup\$ – Pedro Quadros Aug 5 '15 at 10:37

Although the L6203 presents the brake function, it was not suiting well for this application. It had a hard time trying to brake because it was underrated for this project. Even the TRIAC way works, it was not well suited too. TRIACs have a significant issue while switching inductive or capitive loads due to its dI/dt and dV/dt limitations which may hardly reduces its lifespan. Another problem was the cost. Building this additional circuit makes the entire design costly than redesign the H-bridge. The H-bridge, due to limited availableness on my city, is now overrated and also uses CMOS. As expected, only braking, with no kind of control beyond the ON/OFF, worked fine. The positioning system has really good precision, with error varying not beyond than +- 5mm than the defined setpoint.

The resulting design is very close of the schematic bellow. The mosfets, for example, were not those, but some with a little higher specs. Due to them low Rds they are working very cold, even at the highest speed switching operation (low speed). Also, although it was not showed in schematic, there are two ultra high speed diodes connecting the motor's terminals to ground.

enter image description here

Sorry for the probably stupid post, but it was my first project controlling a motor and my second design since I've undergraduated. But certainly it taught me a lot.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.