[Al_The_Man]

Actually I do not even understand the term BLDC... There is no way that kind of motors to work with DC...
They are simply triphasic motors...
Mihai

The term BLDC or Brushless DC comes from the fact that with a BLDC motor, only two or three stator coils are energised at any given time and represents a DC motor turned inside out, as opposed to the virtually identically wound 3ph motor that energises all three windings, often in 3ph sinusoidal pattern.
Al.

[mcm_xyz]

Final PCB... (I hope...)

Servo drive mounted on radiator. Waiting for a bigger motor.
New status and error led added.

Schematic features so far:
Error output
Step / Dir / Enable inputs - toggling enable will also clear servo error if any
RS232 TTL for setup and debugging
ICP port for firmware upgrades. (it's not time yet for flashing firmwares through RS232 as many things are in test, but if things get ok and all works well this port should be removed and firmware should be upgraded via RS232)

Pictures and documents below...

In the eagle folder you can find the HPGH files for milling and drilling the board if you wish.
Firmware still needs some fine adjustments but things are functional. The board is unlikely to change anymore.
I hope tomorrow I will receive a bigger motor. I will let you know on progress

https://www.youtube.com/watch?v=H0R8rw6JPEE


Mihai

[James Newton]

That is seriously cool! Can I ask what sort of motor you have on the way? E.g. what types of larger motor can this be used with?

[mcm_xyz]

I am waiting for a: 57BLF02, see pdf here: http://www.ht-motor.com/en/01/57BLF.pdf. That is a NEMA 23 mount motor, ready to fit in my cnc. I still need to solve the problem of the encoder, although the mouse encoder did not failed me in anyway... I will use something with about 200PPR.
For bigger motors than that I am not sure. I saw on the internet that other commercial servo drives have some kind of current sensing circuit. This one does not... I am afraid something might blow without that...
But I will keep digging... I think the software is based on a simple and reliable ideea. The PID process controls in fact the phase shift required to move the motor from one position to another. If the error is big the phase shift is big forcing the motor to spin fast. if error is small the shift is small... anyway... I will keep working...

Mihai

[Khalid]

great work...please keep sharing ...i want to see spinning bigger motors 100+ Nm...

[mcm_xyz]

New motor in place!
125W Nema 23 mount BLDC motor with my own milled encoder wheel (200PPR)
All seems to work just fine.
Some significant changes in the firmware since last version:
1. PWM frequency got a bigger prescaler. Seems that with high loads the final mosfet and drivers are too slow to switch.
2. A power limiter has been added as a configuration parameter. PMax = 0 .. 100 %. I only have for now a 19VDC 3A power source that enters protection mode when in full power. I managed to obtain good results at max 70% power as you can see in the movie.
3. The PID process now works on int16 instead of int32 giving this way a better performance. (Theoretically all math calculation is done twice as fast).

I will keep you informed.

Mihai

https://www.youtube.com/watch?v=wSWapA9UW-k

[hesham morsy]

:wee::wee::wee:

[mcm_xyz]

New tests with 125W motor, fitted with a 400PPR Avago encoder.
The Step/Dir signal is provided by PlanetCNC USB software and board.
You can see how servo parameters affect movement smoothness and so...
I managed to reach 1500 RPM with about 80% power (I am still waiting for a lab power source... soon to come... )
I think the movement got really smooth and precise. I will mount this to my new Z axis and see how it acts under some load conditions.

Enjoy the video.

https://www.youtube.com/watch?v=PPH6...AFGMm4G97dv1pw

Firmware updates very soon.

Mihai

[mcm_xyz]

Here is the latest source code and board as promised.

Changes in software:

New parameter added:
END POSITION ERROR = when in a stable position if you move the motor shaft with external force (by hand or vibrations or stuff), it will remain unpowered until the error will be over this threshold.

Changes in hardware:
Added a capacitor to the high power line (50-100u / 50V)
Changed Step/Dir/Enable coupling resistances from 1K to 100ohm (Enable signal is still ignored by software, will be fixed in next versions)

Someone please start to build this and play with it! I need second opinions!

Mihai

[James Newton]

Someone please start to build this and play with it! I need second opinions!

Mihai

First, HOW EXCELLENT! I'm very pleased to see you doing this and posting it open source.

I would be interested in making a PCB or 20 if you could post gerbers and a PDF or PNG or something of the schematic instead of the Eagle board files. I'm trying to avoid installing, but more importantly, learning Eagle.

[punisher454]

Part 1;

A few years ago I built a BLDC driver with an AVR. My motor had hall sensors so I used a square wave 6 position truth table to determine the commutation. I used this system as opposed to the back emf technique so I would be able to run all the way down to 0 rpm. This was for a positioning application where the motor only rotated 33 revolutions and had just a single index pulse near the center of travel. I used the hall sensors for instant resolution of the commutation at any speed, but especially at full stop.
I do not see a hall or back emf commutation solution in your code (I just quickly browsed it in notepad++) but I do see a sine-wave look-up table. Are you using the optical encoder with the look-up table? And if so do you have an index pulse or something? How do you determine position from a cold start? or if there is an error?

part 2;

I see you are using MikroPascal for AVR. I briefly looked at their offerings for AVR's several years ago, and at that time their AVR solutions seemed very buggy (while their PIC stuff was much more solid). Has this software matured since then? I seem to recall that the libraries were closed source and you were more or less locked into their hardware configurations if you used the supplied libraries. I did however like ME's IDE concept a lot. How do you like this software?

Marvin

[mcm_xyz]

Part 1;

A few years ago I built a BLDC driver with an AVR. My motor had hall sensors so I used a square wave 6 position truth table to determine the commutation. I used this system as opposed to the back emf technique so I would be able to run all the way down to 0 rpm. This was for a positioning application where the motor only rotated 33 revolutions and had just a single index pulse near the center of travel. I used the hall sensors for instant resolution of the commutation at any speed, but especially at full stop.
I do not see a hall or back emf commutation solution in your code (I just quickly browsed it in notepad++) but I do see a sine-wave look-up table. Are you using the optical encoder with the look-up table? And if so do you have an index pulse or something? How do you determine position from a cold start? or if there is an error?

part 2;

I see you are using MikroPascal for AVR. I briefly looked at their offerings for AVR's several years ago, and at that time their AVR solutions seemed very buggy (while their PIC stuff was much more solid). Has this software matured since then? I seem to recall that the libraries were closed source and you were more or less locked into their hardware configurations if you used the supplied libraries. I did however like ME's IDE concept a lot. How do you like this software?

Marvin

Hello Marvin

Thanks for your interest! Let me clarify...

part 1;
Back EMF indeed could not be used for cold start and it's very hard to use even for low RPMs. Hall sensors are indeed a good solution but my implementation does not use them, mainly for maintaining the code and schematics simple. Cold start is done the hard way . A short commutation sequence is applied to the motor with low speeds, then a pause is done, waiting for the motor to get stable. So, indeed a disadvantage, when starting, the motor will spin freely for a small part of a rotation. After that the commutation sequence is synced using the encoder position, a part of the algorithm maintains the correct commutation sequence (the sine wave table you saw) with the encoder position. So it's very important to know:

1. exactly how many PPR your encoder has (Parameter ENCODER PPR)
2. how many poles your motor has (Parameter MOTOR POLES). I am unsure of the terminology here... What I am expecting for you to enter here is how many times the full sine commutation table must be applied for the motor to make a whole rotation... I had motors with 4 and motors with 6. I expect there is a large variety on the market.

without setting this 2 values correctly your motor wont spin. Or if your encoder looses steps the motor will not stay in sync and will stop after a while. But what good is a positioning system that looses steps

part 2;
Indeed, mikroPascal might be a disadvantage, mainly because it's not free. In my opinion this compiler has reached maturity a couple of years ago, starting with the PRO versions. I developed a complex project a few years ago in mikroPascal, an ATMEGA644 webserver that had ethernet, RTC, communication with other MCU's using UART over radio modules, temperature reading with 1-wire sensors and some relays. It was a smart management thermostat with schedules and wireless sensors. the whole thing works stable for weeks without a crash.
In future I might migrate to C code in AVR Studio. I started with this because I am very familiar with it, my first development board was mikroElectronica...

Hope this helps

Mihai