dsPIC based Open Source DC Servo Driver in Brushed and BLDC.

[dwalsh62]

Hehe, I see your point.

Actually no offense, but 6 steps commutation is old & is not so good compare to recent techniques. Besides, I doubt this guy's solution as he knows nothing about the subject. But if it's good for the community then let's see.

First, any solution that works well is a good solution regardless of technique employed and for you to suggest it is old and not so good without offering anything is nothing shy of arrogance.

Since you seem to be an expert on STM32 based servo drivers and can talk a lot about how it should be done and how his method is not good, upload your eagle files and firmware for examination.

[dwalsh62]

Based on your STM32 files, using the piggy-back STM32 (mini) card is a poor method of deployment.

Since I can only see the pins you have available and used, I did two layouts in twenty minutes, which make use of the available pins in two different packages.

One layout is based on the LQFP32 (STM32F030) package (32 pins) and the second layout is based on the LQFP48 (STM32F103) package (48 pins).

I'm only missing the USB related part of the schematic so I didn't add it.

Since the number of lines you are using is low, there is no need to use a package with a higher pin count.

Since your STM32 files do not contain the schematic of your piggy-back (mini) board, I am unable to add the USB and other related components needed for USB communication.

The pins selected are based on their physical package location, the MCU can be rotated 45deg, 90deg, 135deg, 180deg etc...

Board dimensions are 100mm x 100mm (exactly), 3oz copper with continuous current support of 8A, 16A peak, 24A surge and since you limit the peak current at 10A the chances of popping a trace are slim.

If you think the traces wont support the listed currents then you don't understand the dynamics of stopped traces (or even what they are).

As a design thought, the IR2101 has two inputs (HI/LI) with non-inverting outputs (HO/LO), if you can find a substitute that gives you one non-inverting output (HO) and one inverting output (LO) you can reduce the drive lines from six to three because you can drive both HI/LI from the same line and allow you to switch to a P/N channel H-BRIDGE with minimal circuitry required for dynamic braking thus increasing performance.

[Al_The_Man]

It is not as simple as you say, most BLDC drivers have 3 or more phases and additional inputs for HALL sensors and in my opinion a poor hardware design if you need hall sensors.

.

I would refute that statement and cannot understand why the comment, I have been using A-M-C and other BLDC drives with commutation tracks on the encoder rather than discrete hall sensors.
I have used these in CNC application for some decades now and perform equally as well as any DC or sinusoidal servo's.
Al.

[dwalsh62]

THE BLDC DRIVER SCHEMATICS THAT PEOPLE ARE POSTING ALL HAVE INPUTS FOR HALL SENSORS AND THE MOTORS RUN LIKE CRAP IF YOU DON'T HAVE THEM CONNECTED.

THE OMRON BLDC DRIVE I HAVE DOES NOT HAVE THEM.

THE HITACHI BLDC DRIVE I HAVE DOES NOT HAVE THEM.

THE MIGE AC/DC DRIVE I HAVE SUPPORTS SIX PHASES.

THE MIGE AC/DC DRIVE HAS ENCODER COMMUTATION INPUTS BUT THEY ARE ONLY USED IF THE ENCODER SUPPORTS IT AND MUST BE ENABLED IN THE DRIVE IF USING A 3-PH MOTOR (DEFAULT = 3-PH/OFF, 6-PH/ON).

THIS LEADS ME TO BELIEVE THEY ARE NOT NEEDED SO I DON'T WANT THEM.

THIS ENDS MY PARTICIPATION IN THE HALL SENSOR DISCUSSION.

[RCaffin]

I would suggest you skip the brushed DC. The reason is it's out of date, not so safe for DIYers, since it can run amock on itself if the encoder fails or the the driver fails, or during tuning. Besides, having to change brushes every few months is annoying, especially when you have calibrated everything & not in the mood to do it again.

I will stick my neck out here and disagree with almost everything said here.

If brushed DC motors are out of date, why do they sell in such huge numbers today? Waffle.

To suggest that they are not so safe for DIYers, since one can run amock on itself if the encoder fails ... is to ignore commercial reality. I have never seen a brushed DC motor driven by a modern driver do this. The code in the FPGA inside the driver contains lots of safety checks, and a failed encoder is almost guaranteed to bring the thing to a halt - fast. I have no idea where this comes from, but Waffle.

I don't know of any cases where someone has had to change brushes every few months. To be sure, replacement brushes are available, but it was 25 years of fairly heavy use before I had to replace the brushes on the alternator in my 4WD. If you have to change the brushes all that often, you are doing something very wrong. Waffle.

Why would you have to recalibrate a system just for changing brushes anyhow? The calibration is completely independant of the brushes. Waffle.

Sorry to be so blunt, but, well, too much waffle.

Cheers
Roger

[dwalsh62]

OK, I've gone over the datasheet and figured out the lines for SWD and USB, made those changes, reassigned some lines and came up with what I believe is a decent layout using an STM32F030K6T6, in an LQFP32 (32pin) package, a second version was created reducing the number of lines required to drive the h-bridges based on advice from International Rectifier.

Because the source code is no longer pin correct I couldn't do anything with it so I used a generic "flash two LED's" program and was able to make the two LED's blink by changing the two pins associated with the LED's to the pins I used.

I was also able to externally test the P/N-channel triple h-bridge stage using a 2-bit counter to trigger some gates to drive IR2103's in a 180hz cycle and the motor does spin but until the code has been updated to drive it directly I'm unable to test any further.

Now it just needs the software corrected to use the pins I have assigned, if I need to make changes to the pins it's not a problem but best if you talk to me about the changes so we're on the same page.

I've got two versions of the schematic/layout using STM32F030K6T6 onboard (no piggy-back card):

1. Using the original N-channel h-bridge
   • minor modifications.
   • onboard SWD.
   • onboard USB.
   • onboard RESET button.
   • onboard BOOT0 jumper.
2. Using a P/N-channel h-bridge
   • major modifications.
   • reduced h-bridge drive lines to 3.
   • added dynamic braking capabilities.
   • onboard SWD.
   • onboard USB.
   • onboard RESET button.
   • onboard BOOT0 jumper.

I'm favoring the second revision based on the sanity surrounding the motor stage and the reduced drive lines, hopefully it doesn't take six month for someone to code the thing.

[dwalsh62]

I was informed that my selection of some pins for some functions was incorrect, I have made the necesarry adjustments and updated the schematic and layout to reflect the corrected pins.

The pins used are based on the original STM32F103 piggy-back card pins, I have reduced the motor drive lines from six to three for the motor stage as these are not needed when using a P/N-channel h-bridge.

I dropped SWD support as it was suggested it's not needed as they informed me you can program from the USB port (USB_DP/PA11 and USB_DM/PA12) but if it's really beneficial or better I can put it back.

What I need now is someone who is good at STM32 coding to make changes to the source code.

The basic code changes that need to be made are as follows:

1. from MOTOR drive code drop PB13, PB14 and PB15 as they are no longer needed.
2. add encoder index line ENC_Z using pin PA2.
3. change STATUS from pin PC13 to pin PB1.
4. change ERROR from pin PC14 to pin PB0.

If PB0 and PB1 are not suitable pins, the following pins are unused and available, just tell me which ones you have used and I will make the changes to the schematic and layout.

If the motor drive code wont work without the low side drive signal (I see no reason it wouldn't) then any of the unused pins can be used as PB13, PB14 and PB15 are not available in the selected package.

UNUSED PINS:

1. PA4
2. PA5
3. PA6
4. PA7
5. SWDIO/PA13
6. SWCLK/PA14
7. PA15
8. PB3
9. PB7

All relevant files have been attached to this post including the authors original incomplete schematic and board layout.

The Servo-STM32F030K6T6.zip is the target board for the updated firmware which you can use for reference if needed.

[dwalsh62]

After much delay and excuses from mcm_xyz regarding changes to the source code based on the proposed SMT32F030K6T6 who is being stubborn because he thinks it wont work but the ST-Micro engineer I spoke with assured me it would and he gave me the pin assignment for the specific application so, I have changed to an STM32F103TBU7 and dropped support for the encoder index signal in the hopes that it makes mcm_xyz happy and he makes the changes as requested without further delays.

At this time the only thing preventing the project from being completing is mcm_xyz making changes to the source code which I have no control over and it is sad to have a dependancy on another person involved in a project who for some unknown reason refuses to do what is requied.

Here is the schematic and board layout in eagle format for those who are interested in looking.

[Markovic Slavol]

Brushless DC motor controller board | danstrother.com

http://vedder.se/2014/01/a-custom-bldc-motor-controller/

It takes only a few modifications. You do not need to increase tensions and dust around the code - this is certainly on a voluntary basis.
Merry Christmas!
Happy New Year!

[dwalsh62]

Brushless DC motor controller board | danstrother.com

http://vedder.se/2014/01/a-custom-bldc-motor-controller/

It takes only a few modifications. You do not need to increase tensions and dust around the code - this is certainly on a voluntary basis.
Merry Christmas!
Happy New Year!

Several people have asked about the source code for the Dan Strother board and I checked myself, you are redirected to a generic bitbucket signup page and registering doesn't give you the files so scratch this one.

The second one is based on the STM32F4 Discovery Board using ChibiOS so modification of this project will be complicated as it wouldn't be an easy task to get ChibiOS to run on the STM32F103C6.