DIY AC Servo Drive - ATMega based

Using the encoder for commutation is a really interesting solution. I like it a lot.
It occurs to me that since you are using a mikroelectronika compiler it would be a fairly easy process to port this to ARM (mikropascal for ARM). STM32 development has become dirt cheap and in some cases even less expensive than Arduino. Taking a wild guess I'll bet you could at least double or triple your maximum PID frequency, probably more.

Sometime in the next few weeks I plan to build at least one controller of your design. If that works out like I think it will I'll probably be building around six more.
Thanks for sharing your excellent work.

Marvin

Quote:

---

Originally Posted by punisher454

Using the encoder for commutation is a really interesting solution. I like it a lot.
It occurs to me that since you are using a mikroelectronika compiler it would be a fairly easy process to port this to ARM (mikropascal for ARM). STM32 development has become dirt cheap and in some cases even less expensive than Arduino. Taking a wild guess I'll bet you could at least double or triple your maximum PID frequency, probably more.

Sometime in the next few weeks I plan to build at least one controller of your design. If that works out like I think it will I'll probably be building around six more.
Thanks for sharing your excellent work.

Marvin

---

Hello Marvin.

Porting the code for other mcus should be straight forward. The tough part is maybe initialization. There are tons and tons of differences there even between mcus on same architecture. I am really thinking about porting this to C and AVR Studio because mainly of the impact with community. There are far more fans. If you want to build this I suggest to use optocouplers for encoder, step, dir, and enable. I had quite a few problems when leveling with my controller. There are some cheap optocouplers that have logic.level outputs, also very cheap, also buffered with trigger schmidts.
http://www.tme.eu/ro/Document/85863b...11L1-2-3-4.pdf

Best regards

Mihai

Yes, I'm a big fan of optocouplers, and have been looking into adding schmidts to some of my own designs.
If you move away from ME compilers you will probably reach quite a few more AVR developers, ME stuff seems to be fairly umpopular on most AVR forums.
Of course nothing beats Arduino for popularity and huge user base who like to share. But I'm not sure how much performance hit you'd take running Arduino vs standard C.

Marvin

hi all
i found this another forum then i understands all bldc commutation signal where use.
"""
At power up, the UVW signals are present and they provide a low resolution "absolute position" feedback that tells the servo drive the electrical position of the servo motor rotor (electrical position is different from mechanical position due to multiple pole pairs in most servo motors - if the motor was 2 pole then electrical position would be equal to mechanical position). No movement of the rotor is necessary to initialize the torque angle in the servo drive. The torque of the servo motor is proportional to the sin of the angle so there is plenty of torque to start the initial motion even if the torque was off by as much as 45 electrical degrees (70% of peak torque would be available in this case). After power-up, the UVW signals are automatically switched over to the high resolution quadrature "incremental position" data and the once per revolution reference marker signal. As soon as the servo drive detects the first occurrence of the encoder marker signal the torque angle is adjusted in the servo drive to the near perfect value. The servo motor manufacturer mechanically aligns the marker pulse to provide the near perfect torque angle during manufacturing of the motor. If the motor encoder were to be removed or replaced then this alignment process must be repeated.
With the SureServo system, the UVW encoder signals are present at power-up for about 0.5 seconds. This gives the servo drive enough time to detect rough position of the servo motor rotor. After about 1/2 second, the motor encoder automatically switches over to high resolution ABZ data signals which the servo drive uses for real-time commutation of the brush less servo motor. With the first occurrence of the Z signal (marker pulse) the rotor angle inside the drive is set to the exact value. Hope this answers your question.
""""
thanks
shabbir

Quote:

---

Originally Posted by moghul

hi all
i found this another forum then i understands all bldc commutation signal where use.
"""
At power up, the UVW signals are present and they provide a low resolution "absolute position" feedback that tells the servo drive the electrical position of the servo motor rotor (electrical position is different from mechanical position due to multiple pole pairs in most servo motors - if the motor was 2 pole then electrical position would be equal to mechanical position). No movement of the rotor is necessary to initialize the torque angle in the servo drive. The torque of the servo motor is proportional to the sin of the angle so there is plenty of torque to start the initial motion even if the torque was off by as much as 45 electrical degrees (70% of peak torque would be available in this case). After power-up, the UVW signals are automatically switched over to the high resolution quadrature "incremental position" data and the once per revolution reference marker signal. As soon as the servo drive detects the first occurrence of the encoder marker signal the torque angle is adjusted in the servo drive to the near perfect value. The servo motor manufacturer mechanically aligns the marker pulse to provide the near perfect torque angle during manufacturing of the motor. If the motor encoder were to be removed or replaced then this alignment process must be repeated.
With the SureServo system, the UVW encoder signals are present at power-up for about 0.5 seconds. This gives the servo drive enough time to detect rough position of the servo motor rotor. After about 1/2 second, the motor encoder automatically switches over to high resolution ABZ data signals which the servo drive uses for real-time commutation of the brush less servo motor. With the first occurrence of the Z signal (marker pulse) the rotor angle inside the drive is set to the exact value. Hope this answers your question.
""""
thanks
shabbir

---

I do not have such encoders on my motor. Actually I do not even have Z output on my encoder, only A and B. So it's not possible for me to implement this.

Mihai

Dear Mihai
yes
u r good programmer u can implement. its very nice for all. that we can use normal only ab r abz encoder for bldc.
i was just study why uvw encoder use. that i understand.
all ok
thanks.
shabbir

Shabbir How far you have reached?.. Did you made the controller? any video?

hi all
today i finally purchased all components for this.
now i will try to complete this in this week.
IN SHA ALLAH.
also i have to modify this for atmega 2560.
shabbir

First, I wanted to say congratulations on a fantastic project so far. You've accomplished a huge amount in a very short period of time.

I wanted to touch on a couple of things that have been brought up in the thread already.
1. I think porting this to one of the more popular development platforms could be a huge advantage to user acceptance and people who could contribute to the project. For the hardware and firmware, the easiest choice would be to move to arduino, however the requirement for 3 hardware interrupts limits you to only the Mega 2560 platform. I haven't had a chance to dig through the code too much, but could you give some details on the requirements around the external interrupts? If we could get away with 2 hardware interrupts and 1 pin interrupt, then the rest of your listed requirements could be met by the very cheap Arduino Uno.
2. Would you be willing to transition to using an online repository to maintain your code? There's multiple to choose from, and I'm not partial to any, but I'd be happy to help maintain the code base (my day job) on github, sourceforge, google code, etc.
3. Micro Pascal and Delphi are going to be hard to find experts in. If we moved to arduino, then the microcontroller code is set. Would you consider moving the client application to maybe... .NET/Mono, java, or even some of the newer html/broswer based languages?

Again, a huge thank you from the community. I'm excited to give this a try and see what happens.

Since I'm thinking in a similar project (I talked about it back in this topic), I think I can answer you (although my knowledge is a lot smaller).

The Mega 2560 board can be get pretty cheap, mine (Funduino brand, fully compatible) was 15 USD (shipping included). There are other arduinos with enough interrupts (I have a Pro Micro that have 5 external interrups, using the MEGA32U4).

BUT the arduino code is slow, but you can program them with C o Pascal without problem, that will be much faster. But as you said, this microcontrollers are more popular and pretty easy to find.

arduino is the best i feel because it is available in all countries.
and noe made smd pcb .
i m also trying this in arduino mega 2560

shabbir

I've seen some complaints about the execution speed for arduino code, so you're right, there's likely portions of the code that would need to be written in the lower level language. It would be nice to leverage the Arduino libraries for things like serial communication and configuration.

I also did a little digging and found the same thing, the Mega 2560 isn't that much more expensive. I'll pick a few up and see if I can get something prototyped. I'd be interested to see if you could do shields for multiple servo types since brushed DC servo's are a dime a dozen and could leverage the same PID and encoder code and just need a different output scheme.

Arduino code is actually compiled C/C++. The code is not slow. What is slow are some of the libraries. They were written for ease of use rather rather than performance. But they are easily bypassed.

I stayed away from Arduino for a long time, I was under the impression that it was running on an interpreter. But its compiled and like H500 said, its just some of the libraries that are slow. Whats so nice is the dirt cheap dev boards and HUGE user community. If Arduino is still too slow after some work you can just port the code over to a teensy3 or one of the other ARM-duino's out there. Cost-wise they are the same.

hi
i buy arduino but i m not using arduino software for programming.
i m using avr studio. n then upload hex from isp r usb cable.
thanks
shabbir

Quote:

---

Originally Posted by S.A.C.

First, I wanted to say congratulations on a fantastic project so far. You've accomplished a huge amount in a very short period of time.

I wanted to touch on a couple of things that have been brought up in the thread already.
1. I think porting this to one of the more popular development platforms could be a huge advantage to user acceptance and people who could contribute to the project. For the hardware and firmware, the easiest choice would be to move to arduino, however the requirement for 3 hardware interrupts limits you to only the Mega 2560 platform. I haven't had a chance to dig through the code too much, but could you give some details on the requirements around the external interrupts? If we could get away with 2 hardware interrupts and 1 pin interrupt, then the rest of your listed requirements could be met by the very cheap Arduino Uno.
2. Would you be willing to transition to using an online repository to maintain your code? There's multiple to choose from, and I'm not partial to any, but I'd be happy to help maintain the code base (my day job) on github, sourceforge, google code, etc.
3. Micro Pascal and Delphi are going to be hard to find experts in. If we moved to arduino, then the microcontroller code is set. Would you consider moving the client application to maybe... .NET/Mono, java, or even some of the newer html/broswer based languages?

Again, a huge thank you from the community. I'm excited to give this a try and see what happens.

---

Hello

1. We only need 2 external interrupt pins. 1 for encoder, 1 for Step. (earlier versions needed 2 for the encoder, not needed anymore). Enable is handled now using a PCINT but because it's not a critical signal we can drop it if MCU is not capable for this and use a simple test in the main loop.
2. I would be very very happy if someone would create an online repository for this project. We could maintain all files there, including some documentation that is missing for now. The repository choice is entirely yours, as I am only familiar with TFS (Microsoft) at my work.
3. Mikropascal should be dropped I agree. But giving my expertise I started this project in my most familiar environment. I would opt for C and AVRStudio as the first alternative. The servo drive tuner software id badly written, fast and dirty. That one could be easily written in C# for eg.

Mihai

dear mihai
please help me to conversion firmware from mega644 to mega2560. .
pin mapping changing. because i m not familiar to pascal.
shabbir

Quote:

---

Originally Posted by moghul

dear mihai
please help me to conversion firmware from mega644 to mega2560. .
pin mapping changing. because i m not familiar to pascal.
shabbir

---

Sorry Shabbir

I do not have time for a parallel branch development. I am only one man... :)
I could try answering direct questions but I do not have time for searching how to make it work on a different MCU.

Mihai

Quote:

---

Originally Posted by mcm_xyz

Hello

1. We only need 2 external interrupt pins. 1 for encoder, 1 for Step. (earlier versions needed 2 for the encoder, not needed anymore). Enable is handled now using a PCINT but because it's not a critical signal we can drop it if MCU is not capable for this and use a simple test in the main loop.
2. I would be very very happy if someone would create an online repository for this project. We could maintain all files there, including some documentation that is missing for now. The repository choice is entirely yours, as I am only familiar with TFS (Microsoft) at my work.
3. Mikropascal should be dropped I agree. But giving my expertise I started this project in my most familiar environment. I would opt for C and AVRStudio as the first alternative. The servo drive tuner software id badly written, fast and dirty. That one could be easily written in C# for eg.

Mihai

---

Sounds like this is shaping up nicely. Also funny as I maintain the TFS project for a large NC software development team, and given the choice, I'd probably go that route, but since it's not free, I think github is probably the right choice. If you want to come up with a name for it, I'll be happy to get us set up with a repository.

With only two interrupts necessary, we can probably get away with an Uno. I happen to have a couple of those sitting around and a Due. C and AVRStudio sound like a fantastic choice to me.

I can tackle the tuner application probably pretty quickly. I'll see what I can do next week.

Thanks again. Looking forward to working on this with you.

dear Mihai
yes i have some question .
if u dont mind n have time send me details of this.

in
// PWM channel 0
TCCR0A := (1 SHL WGM00) or ({1}0 SHL WGM01) or (0 SHL COM0A0) or (1 SHL COM0A1) or (0 SHL COM0B0) or (1 SHL COM0B1);
TCCR0B := (0 SHL WGM02) or (1 SHL CS00) or (0 SHL CS01) or (0 SHL CS02);
OCR0A := 0;
OCR0B := 0;
// PWM channel 1 (used in 8 bit mode)
TCCR1A := (1 SHL WGM10) or (0 SHL WGM11) or (0 SHL COM1A0) or (1 SHL COM1A1) or (0 SHL COM1B0) or (1 SHL COM1B1);
TCCR1B := ({1}0 SHL WGM12) or (0 SHL WGM13) or (1 SHL CS10) or (0 SHL CS11) or (0 SHL CS12);
OCR1AL := 0;
OCR1BL := 0;
// PWM channel 2
TCCR2A := (1 SHL WGM20) or ({1}0 SHL WGM21) or (0 SHL COM2A0) or (1 SHL COM2A1) or (0 SHL COM2B0) or (1 SHL COM2B1);
TCCR2B := (0 SHL WGM22) or (1 SHL CS20) or (0 SHL CS21) or (0 SHL CS22);
OCR2A := 0;
OCR2B := 0;
end;

what means of 1 SHL CS20
is it CS20 = 1
({1}0 SHL WGM21) what is this


shabbir