[ikebosch]

Hi all!
I have been pursuing this DIY Servo controller with great interest! It's indeed all very impressive and it has been very inspirational to me since I am also working on a similar project but different concept!

I have designed a 24V 3 phase BLDC drive which was initialy going to be used to drive a PCB Drill spindle motor. For a PCB drill.... the most important thing is the spindle speed, which is usually around 60,000 rpm. Based on the fact that this does not run in a precision motion control environment, the controller can be run in an open loop! The only perimeters of concern would be to monitor and control the motor current and the rotor speed.

Being a 3 phase application, usually it is the motor frequency we control at the same time maintaining a good volts/Hertz ratio through the pulse width modulation concept! Of course this is all still on the bench under development I will make all schematic drawings and photographs available in a very near future in pdf format, once I have acquired a pdf document writer. However I would need some input from this well informed community on which BLDC motors the community wishes to see being controlled by this drive!

Thus far I can only say I am using a Kavo 36VDC 8A 100,000 rpm motor and this requires a frequency of between 5 and 1000Hz (1kHz). My PWM is generated by a 40 kHz watch crystal which I half to 20 kHz via a simple D type flip flop. I chose to use the CD4000 CMOS and operational amplifiers since they require no programing. All one would really need is a meter and maybe an oscilloscope although this would not be necessary since all engineering would be done on my bench.
Thank you all once again
Ike

[kreutz]

Hello Guys!

I am back! reading all the recent postings and will continue working on Tenmetalman's problem.

I don't have the time to redesign the firmware in order to use software generated dead-time, so I opted for a hardware modification using the IR21844. Since I don't have a quick way to make a prototype PCB it will take a little time to be ready for testing.

Regards,

Kreutz

[MrWild]

Will this be an entirelly new board, or an add on? Some of us have boards all set up and in the middle of a machine build process. I suppose it can't be helped if needed, but it won't make me a happy camper with all the $$$ I've put into the existing set up.

I thought it'd just be some cheap diodes getting swapped, some capacitor changes, and power side transistors/mosfets switched out on the old board(s).

Oh well, if it is needed for the fix, it is needed. Too far into this swamp to turn around.

[kreutz]

Will this be an entirelly new board, or an add on? Some of us have boards all set up and in the middle of a machine build process. I suppose it can't be helped if needed, but it won't make me a happy camper with all the $$$ I've put into the existing set up.

I thought it'd just be some cheap diodes getting swapped, some capacitor changes, and power side transistors/mosfets switched out on the old board(s).

Oh well, if it is needed for the fix, it is needed. Too far into this swamp to turn around.

This solution is not necessary for the most part of the UHU board users. Only those driving high current high voltage servo motors (>100 volts and > 8Amps). I still consider the UHU boards a very good design. The problems, so far, are only seen when trying to generalize the design for a broader voltage and current range, probably not tested, or not intended, originally by the designer..

[kreutz]

Dear all,
this is my first post on this board........

Daniel

WELCOME!!!

[kreutz]

ciocead4;

If I had the time I would have followed a similar path. Using a 32 bit CPU will let you add more features, the same would be accomplished by using the Attiny2313 and offloading the 4X quadrature decoding to a PLD. The PID calculation loop is not really a burden even at 8 bits, because of the low rate (1 khz interrupt), you could also program different update rates for the PID loop, even when adding a higher order term, as Uli did...

I just came back from vacation and have a lot to do on other projects, but will do my best to help solve the high power cross-conduction issue too.

I never intended to re-design completely the UHU board, I would rather have pursued a brushless servo drive design instead.

Regards,

Kreutz.

[vroemm]

This solution is not necessary for the most part of the UHU board users. Only those driving high current high voltage servo motors (>100 volts and > 8Amps). I still consider the UHU boards a very good design.

Exciting to read about the developments :-)
Good to hear most UHU users won't have the problem.

A question to clarify:
Is the improvement needed for >100 volts AND > 8 ampere ?
Or is it needed for >100 volts AND/OR >8 Ampere ?

Thanks..

[kreutz]

Exciting to read about the developments :-)
Good to hear most UHU users won't have the problem.

A question to clarify:
Is the improvement needed for >100 volts AND > 8 ampere ?
Or is it needed for >100 volts AND/OR >8 Ampere ?

Thanks..

As my tests show so far, the problem only gets critical over 80-100 Volts due to the Miller effect. In order to commutate higher currents is is also necessary to source/sink more charge to/from the gate, so current will be a factor too on switching time and cross-conduction at high Vmotor voltage.

[MrWild]

As my tests show so far, the problem only gets critical over 80-100 Volts due to the Miller effect. In order to commutate higher currents is is also necessary to source/sink more charge to/from the gate, so current will be a factor too on switching time and cross-conduction at high Vmotor voltage.

Add me to the list of folks pushing the design. These are going in a Crusader M retrofit of a Supermax YCM40. Have to check myself. but was told about 130 volts, and around 7 amps. So, will I be building new boards, or just swapping parts? I honestly appreciate all the good work you're doing. Its better to catch any problem now then after I'm all wired in. The reason I'm asking is to make sure I can at least location mount these boards and run wires. Then when the fix is ready, I can just pull and do the parts swapping. If it ends up needing totally different/new boards from the SMARBAGA boards for your fix, I'll hold off fixing the location and mounting.

I work slow due to a disability and hate having effort wasted. It comes at a high cost in time.

[tenmetalman]

Hello All,
Kreutz, I hope you have a great vacation! How did your daughters event go? I guess I'm getting too far off topic! Anyway it's good to have you back. I'm guessing one & a half to two weeks just for you to get back to speed at work, then play time. On one of the other lists it was suggested to put MOV"s on the ac lines into the power supply to reduce the power surge when coming out of E-stop. does putting a 140/150 vdc MOV on each of the ac input lines to ground, make sense? from looking at the data sheet I'm beginning to understand what I'm looking at & understand about the variable resistance due to the temperature change. In addition to the IR21844 circuit, it would seem to make sense to me. Last night I was again poring over my machine manual and found where it stated that the load on the original servo drive was expected to see 38amps +/-3 & a normal load of 15amps during a rapid & feed move. I guess the servos larger capability's is to increase their reliability.
Paul / tenmetalman

[kreutz]

Hello;

I have been working with Smarbaga from the beginning of the complains about overheating snubber resistors, he sent me one of his boards for testing, and he said: "test it even to the destruction limit".

I will post the modified schematics as soon as a definitive cure is found and tested satisfactorily. I will also send him the PCB layout/gerbers so he can provide the new PCBs.

Regards,

Kreutz.

[kreutz]

.....On one of the other lists it was suggested to put MOV"s on the ac lines into the power supply to reduce the power surge when coming out of E-stop. does putting a 140/150 vdc MOV on each of the ac input lines to ground, make sense? .....

Paul / tenmetalman

Use a 170 Vdc (130 Vac) MOV like the SK14K130E2 (Newark part number 95B8035 ) across the 120 Volt AC line (after the main fuses) Do not connect it to the Ground terminal.

[ciocead4]

ciocead4;

If I had the time I would have followed a similar path. Using a 32 bit CPU will let you add more features, the same would be accomplished by using the Attiny2313 and offloading the 4X quadrature decoding to a PLD. The PID calculation loop is not really a burden even at 8 bits, because of the low rate (1 khz interrupt), you could also program different update rates for the PID loop, even when adding a higher order term, as Uli did...

I just came back from vacation and have a lot to do on other projects, but will do my best to help solve the high power cross-conduction issue too.

I never intended to re-design completely the UHU board, I would rather have pursued a brushless servo drive design instead.
LRegards,

Kreutz.

Kreutz,
I hope you had a good time on your vacation!
Like in your case, I am working also on other projects, so the development of the new controller is a slow process. At the beginning I didn't intended to use an 32bit microcontroller just for this application, however I looked at a "motor control" oriented one. The first candidate was an dsPic member (16bits are enough for such application in my opinion), which is a very nice chip, having various "motor control" features included (hardware encoder, 3-phase PWM, nice instruction set) but I just don't like to deal with non-open software tools like Microchip is pushing. So I jumped to a 32bit (ARM family) microcontroller, again with "motor control" features on-board... even if it has more processing power than needed. In the end the price for such chips is low enough to not bother anymore ... The nice thing about this choice is that every dedicated "motor control" chip is actually 3-phase (BLDC) capable, so it could be extended to such brushless motors as well... only the development time is a problem for me these days .
Like I said, I don't know if is worthing to modify the existing UHU project only to solve the cross-conduction issue in software, but if want to have more future improvements the actual chip (ATTiny2313) is somehow overheaded.

Regards,
Daniel

[cncbasher]

WOW,
As I'm sure your aware kreutz is on vacation. but I'm sure he will welcome you with open arms to help him deal with people like me who are beginning electronic/CNC controller builders. We've not heard from designer/owner of the UHU program for awhile, who to date has locked his program and sells the preloaded chip on line.

this is the one and only reason i am not using this design , many people that can and could help solve problems such as those shown here for a long time , along with those who have committed to using this design , only to have wasted their money on blown up pcb's for whatever reason are now at a loss .

respectfully release the code so everyone can help each other , half the story is as good as none at all , after all many hands make light work , lets solve the problems and make this a Rock Solid project for all .

it helps to take the pressure off one's shoulders too

Dave

[kreutz]

Kreutz,
.... I jumped to a 32bit (ARM family) microcontroller, again with "motor control" features on-board... even if it has more processing power than needed. In the end the price for such chips is low enough to not bother anymore ... The nice thing about this choice is that every dedicated "motor control" chip is actually 3-phase (BLDC) capable, so it could be extended to such brushless motors as well... I don't know if is worthing to modify the existing UHU project only to solve the cross-conduction issue in software, but if want to have more future improvements the actual chip (ATTiny2313) is somehow overheaded.....

Daniel

Hello Daniel;

Keep on the good work. I am thinking about using a 32 bit ARM in my next project too. It has a lot of potential.

Regards,

Kreutz.

[jahonen]

Hi folks, I have some experience with using NXP ARM7s in motor control application. Although the application was not servo controller but a stepper drive, it nevertheless comes close. I Just wanted to share the experience.

At work my colleagues and I just designed a three-channel microstepping (64 µsteps/step) stepper controller with NXP LPC2164 during the last year. The current control PI-loop runs at 1/3 of PWM rate, which is 60 kHz. It uses average current control instead of the much more common mixed-decay solutions like in most of the integrated solutions.

Our experience was that although ARM7 is quite powerful in general, it is not very good choice in hard realtime application, where data comes in little pieces and there are high interrupt rates. Biggest drawback is the lack of direct addressing, which can be demonstrated with following simple example. For simple a=b+c operation, one must first load addresses of a, b and c to the registers (that takes 3 clocks per load, i.e. 9 clocks). Then actual values of b and c can be loaded, 6 clocks for that. Then comes the addition in one clock. And finally, the store operation to a takes 2 clocks. Total clocks required for that simple operation is whopping 18 clocks. That overhead makes it rather sluggish in single operations. Of course, the speed increases highly if the data can be processed in bigger blocks. Big register set also means that when interrupt occurs, there is a lot of registers to push in to the stack, which means relatively high interrupt latency. We measured about 1 µs of latency.

Another thing was the fact that at least in the NXP LPC family is that the accesses to conventional IO-ports and pheripherals are quite slow (best we could do was about 200 ns per access). Fortunately LPC2164 has fast-IO ports, which are much faster so NXP must be aware of this.

For because the all aforementioned reasons, we were sure somewhat disappointed with the performance. We got the job done, but were forced to somewhat loosen the initial specs. For example, the aforementioned current control loop was initially spec'ed to run at 20 µs intervals (6 PI-control loops total, one for each stepper phase), which turned out later that it would eat all the CPU time, so more realistic loop rate is 3 PWM periods or 50 µs. I believe any DSC would easily outperform the ARM in such realtime applications. Of course that depends what is the required interrupt rate.

Regards,
Janne

[kreutz]

Hi folks, I have some experience with using NXP ARM7s in motor control application. Although the application was not servo controller but a stepper drive, it nevertheless comes close. I Just wanted to share the experience.

Janne

Hello;

Thanks a lot for sharing your experiences, that makes me change the approach for my next project. I am planning to use an ARM for motion PID calculation and human interface, and FPGA for realtime control functions, including quadrature decoding, step direction up/down counter and current loop control and safety.

Regards,

Kreutz.

[tenmetalman]

Hello All,
Anything new in the last 24hrs + ? I had another crash and am just now up with a new Dell C-521. I'm using s cat-5 cable connection untill I can get my wireless connection working. I've purchase a new piece of software to maintain backups. Maybe I'll be able to survive furture crashes with losing everything!
Paul/tenmetalman

[vroemm]

respectfully release the code so everyone can help each other,

That would be fun.
But i had the discussion with Uli.
I understand why he keeps the code secret.

half the story is as good as none at all ,

I disagree, there is the hardware of the UHU.
And anyone can use it with his/her own code, open source or closed.

after all many hands make light work , lets solve the problems and make this a Rock Solid project for all .

Nice dream.
And then a UHU wiki where all the building, troubleshooting
and operating info is concentrated.
Up to the last piece of wire and last nut and bold.
Well, i can dream to, can't i :-)

[kreutz]

I am planning to send the new gerbers to the fab next Tuesday, it is a shame I don't have a way to make a quick prototype at home yet.

There is another point to address on this prototype for high power servos: Current sensor "blanking" circuit.