[kreutz]

FYI

So far the optimized timing without replacing the Mosfet drivers leave too narrow dead-time to be reliable at high voltages (using IRFP260N), tests are being done with a 35 volt power supply and a 24 v 3 amps servo motor with 500 ppr encoder. Here are some waveforms at 50% duty-cycle. Switching transient at the Sense resistor (due to the reverse recovery time of the Mosfet internal diodes), claims for a blanking time of 1.2 uSecs minimum in the current sense circuit.

Note: 1N4004 diodes were replaced by HER105-T (400 V 1A ) high speed diodes too.

[kreutz]

Some photos

[LZ1TWB]

Hello kreutz,
I cannot understand is there a problem with this particular board or the schematic at all? Does this mean I cannot use my uhu with irfp260n at 130VDC?
So far I am using IRFP150N 100V at 68V power supply without any problems. I am on my way of building some more boards using higher voltages. Would you give some more explanation about the problem? /I am using the old PCB design if this matters/

Thanks, Todor

[kreutz]

Hello kreutz,
I cannot understand is there a problem with this particular board or the schematic at all? Does this mean I cannot use my uhu with irfp260n at 130VDC?
So far I am using IRFP150N 100V at 68V power supply without any problems. I am on my way of building some more boards using higher voltages. Would you give some more explanation about the problem? /I am using the old PCB design if this matters/

Thanks, Todor

Just try. The problem presents itself on two different ways: overheating of the snubber resistor or, plain blowing output Mosfets at power up (or just when starting to move), with power supplies higher than 100 volts, or in this case (Tenmetalman's), 135 Volts. Tenmetalman's problem was aggravated by using IRFP264N instead of the IRFP260.

[newton]

Is Mach 3 Give Pwm Signal For X-y Motor And Z( Give Sguare Wave With Certain Freguancy Where Motor 'll Rotate By This Speed) And Diection Signal Gor Each Of Them (e.g: Logic 1 Right , O=left)

Is That Right Or No?
Thaks For Help

[LZ1TWB]

Hello newton,
Mach3 outputs Step and Direction signals where Step are narrow pulses with some frequency according speed and Direction is like you said.

Todor

[newton]

thanks a lot
do u know any other program free or trial (demo) give the PWM signal

[kreutz]

Hello kreutz,
I cannot understand is there a problem with this particular board or the schematic at all? Does this mean I cannot use my uhu with irfp260n at 130VDC?
So far I am using IRFP150N 100V at 68V power supply without any problems. I am on my way of building some more boards using higher voltages. Would you give some more explanation about the problem? /I am using the old PCB design if this matters/

Thanks, Todor

Now I have a little more time to answer your question. The R-C-Diode network is designed to introduce different delays for the turn on and turn off of the Mosfets on the same leg, the IR2184 will introduce a fixed delay (between 400 and 500 uSec) too,as you can see on the waveforms, at least when using IRFP260N, even at low voltages, there is a time interval when both, upper and lower mosfets on the same leg of the H bridge, will conduct at the same time ( actually both are in or near the linear zone when this happens). At low voltages the combined resistance of both Mosfets (since they are not fully saturated) is enough to limit the Cross-conduction current, but that is not the case at high voltage.

The delays (and probably some overlap too) were planned by the designer, probably looking to avoid the current transient on the sensor resistors during the reverse recovery of the internal diodes of the mosfets.

The problem comes when substituting Mosfets (by "equivalents" or maybe because the designer did not have a high bandwidth oscilloscope to test the worst case scenario) since the turn off and turn on delays are dependent on the mosfet total gate charge and that depends on the Vds voltage due to the miller effect. The total gate capacitance is different for each mosfet type and increases with die size. I haven't measured the switching times on any board with the IRF540N yet.

I still think the turn off and on times are too conservative to be purposely made that long in order to limit dv/dt. Current transients could be made harmless by using "blanking time" on the current chopper circuit. The problem aggravates too when using 1N4004 or 1N4007 in the switching circuit because they introduce additional delay even when using the 1000 pf capacitor (that, by the way, introduce more capacitance on the gate circuit).

[LZ1TWB]

Hello kreutz,
I am kind of confused now because I don't know whether to trust the schematic or not since I don't want to see smoke in the middle of an important job being cut.
I see the problem is complicated as many components are involved in the design of the output stage and each one differs things in its own way.
As for the BYV27-200 is there a difference if one uses them or not? I know mosfets have their internal diodes but what are the external for?
I big difference I saw in the PDF's is that the reverse recovery time of the internal diode of 260N is around 400ns and the BYV27 is 25ns. What happens when both are combined together?

I see you are doing some good job investigating this problem and I wanted to know if there is some final solution for the component values for a safe work.
I am just wondering how could be shipped 2000+ controllers and until now no one came up with a problem like this on the forum?

Thanks, Todor

[contactirfu]

Todor

Kreutz is on a 4 week vacation...

But at this stage I did expect ULI to jump in help solve the issue working together with Kreutz,

Hello ULI are u there ..............

Just realised the posting are far through the 1000 mark at 1130...........thats GREAT!

Irfan

[tenmetalman]

Hello All,
If you think its strange that this problem has cropped up, I'm the one with it.
I with the help of others have fought it for well over a year. I wasted seven out of nine boards, a large baggy of smoked components, my wifes patience as well as my own at times. It's only been sense Kreutz took my under his wing that I'm made any real progress. I now can turn the servo on with out blowing up a board! more than once !!
While Kreutz is away I'm trying a item made by Jon @ Pico Systems. It's suppose to control the power surge when going into/out of E-Stop $ starting and stopping feeds & rapid travel. I met Jon while at the CNC Workshop @ Cardinal Engineering this year. He and several others (sorry guys, I don't have my card file handy & its 2:00am) went out of their way to hear me out, offers possible courses of action wither it included their products or not and at times introduced me to others such as Jon who might have ideas for me to try.
BTW If you've not heard of the CNC workshop, look it up & go it's one of the BEST ways to spend a week surrounded by others such as yourself, go it classes to learn more about what your trying to do, attend demonstrations and put your hands on the toys you've wanted for your CNC project! A resounding "THANKS" to Rolland for putting it on for the last three years
Enough for now I've got a Doctors appt tomorrow
Paul H a.k.a. tenmetalman

[LZ1TWB]

No offence tenmetalman, this could happen to anyone. I just hope the problem will come with its good way out.
There is one other problem on my side that I cannot still figure out that I get wrap errors count from above certain speed. Every help that i received /thanks indeed/ blamed my wiring but I don't think this is the case. I know my encoders are high resolution - 1024steps but wasn't the controller capable of reading 'over 150.000 steps/s'?

I just wanted more uhu users share their experience on the forum.
Thanks, Todor

[tenmetalman]

Hello,
No offense taken LZ1TWB. I also would like more people on the list to share what their up to & what success or failures they're having. I KNOW there has to be people who are successfully running UHU drives on larger machines. It seems as though people just blend into the woodwork when their problems are solved. I'd like to be proven wrong............ But?
Yes, it's my understanding that UHU should be able to read 150,000 steps/s . I also know that different PC's with the same processors seem to limit the steps below that count. My mill also has 1000 count encoders on X & Y and 1024 on the Z axis. But to date I've not had the opportunity to see if I get errors during a program run. I'm limited as to how much help I try and give by what I feel I Know!! More than once I've seen something passed as "fact" to be disproved by another member. I guess We makes our choices & takes our chances......
Paul

[ciocead4]

Dear all,
this is my first post on this board, so let me first express my appreciation for your work and results. I have monitored this thread from time to time and also other discussions, since I am interested to develop such an motor controller, so the information found here has been very helpful for me in some designing points. I decided to share some experience I have regarding this subject, especially because I saw the work of Kreutz related to the cross conduction issue. I really don't have practical experience of how much this cross conduction is affecting the device capabilities, but I have some ideas regarding the countermeasures you can develop to avoid it. As Kreutz said the dead-time is fixed in the current hardware platform by the IR2184 drivers, so I looked at a software solution to adjust it. Of course, for that, I used IR2181 driver with separate low-side, high-side inputs and two separate PWM signals from an AVR microcontroller and I managed to adjust the dead-times within large limits (500ns-1.5us). The PWM signals were generated using "phase and frequency correct" mode therefore the actual resolution is half of the normal (fast PWM) modes.
I don't know if it's so important for you to redesign this controller to have adjustable dead-times, but in my opinion you should consider to change the H-bridge drivers (to IR2181 or similar) and the AVR itself to a more powerful one (I know that this is a major change, but maybe Uhu will find it appropriate to help you with that). A good candidate, for the same price and size aspects, are the recent ATTiny261/461/861 AVRs which have powerful PWM modes (10bit resolution, 64/32MHz input capable and hardware "dead-band" generators which solve the resolution reduction issue). Thus the controller would increase in resolution, speed and feature capabilities...

I hope I didn't mess my first post here ,
Daniel

[tenmetalman]

WOW,
I think I speak for the rest of the members without reservation, Welcome Aboard. I'm a retired Manufacturing Engineer/Machinist and spend a great deal of my time asking/getting help from other members on the list. 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. I don't criticize his stance (He has who knows, how much time invested). I expect/hope we'll hear from him shortly. I for one am stuck with the cross induction problem.
In the mean time I'd like to ask if you want/feel like telling use more about your project?
Paul a.k.a. tenmetalman

[wotje]

I know my encoders are high resolution - 1024steps but wasn't the controller capable of reading 'over 150.000 steps/s'?

A UHU is capable of doing with a 512 line encoder 9000 RPM.

Here you can find the UHU FAQ http://www.uhu-servo.de/servo_en/UHU%20FAQ_en.pdf

And here you can find de homepage (german and englisch) from Uli Huber the designer from the UHU:
http://www.uhu-servo.de/

Myself, I treid my motors equiped with 512 line encoders to run that speed, but I got frighten at 4800 RPM

Wotje

[ciocead4]

WOW,
In the mean time I'd like to ask if you want/feel like telling use more about your project?
Paul a.k.a. tenmetalman

Paul, at your request I give you some more information related to my project: I started on the same idea like UHU project but tried to improve several aspects. The first improvement I had in mind it was this "dead-time" software adjust ability therefore I made the changes that I mentioned. I also intended to use the internal analog comparator of the AVR to implement overcurrent protection, but I found out that there is no direct connection between AO output and the PWM stage. The better candidates ATTiny261/461,861 and AT90PWM microcontrollers have advanced PWM modes, with internal dead-band generators and "fault" protections. For example the "fault" detection can automatically stop the PWM outputs without external additional logic, triggered by the internal AO output stage.
Therefore I designed my first board using an ATMega162 microcontroler because it has an JTAG debugging capability and wanted to move the code to an ATTiny461 after the major functionalities were running as expected. The current status of that board is that I have the prototype with microcontroller, H-bridge drivers, power stage (IRF540 MOSFETs) and RS232 connectivity. The software is completed up to the point of fitting the PID algorithm inside... and I stopped here because I felt that an 8bit microcontroler is just not the best candidate for such task. The PID calculations are at least 16bit arithmetical operations and the AVR have inherent overhead to deal with those 16bit operation using its 8 bit architecture.
The ATMega162 board is running the PWMs correctly, the IR2181s and power stage behaves as expected, I can control the speed and direction of the motor using the RS232 to PC connection. The dead-times are just some software parameters, I played with several values (500ns..1.5us) and checked the results with an oscilloscope, the observations were OK. As a conclusion, if you want to address this particular issue (cross conduction) for UHU project it is still possible to use an AVR microcontroller with the modifications I mentioned.
If you want I can provide pictures with my development board setup, but you have to tell me how is the convenient way to attach pictures to this board...

Because of the 8bit computing limitations I mentioned above, I switched my attention to another microcontroller platform ( it's an 32bit "monster" ) and in several weeks I will have the first board ready... then the software "story" restarts .

Regards,
Daniel

[LZ1TWB]

Hello wotje,
No doubt you drive your 512 line at 9000rpm but did you probe your error count is showing "0" after that? Me myself have spinned 1024ppr at 4000 rpm but get a whole bunch of error counts every second. If I stay under around 80000 steps/sec everything is fine.

Thanks, Todor

[wotje]

Hello wotje,
No doubt you drive your 512 line at 9000rpm but did you probe your error count is showing "0" after that? Me myself have spinned 1024ppr at 4000 rpm but get a whole bunch of error counts every second. If I stay under around 80000 steps/sec everything is fine.

Thanks, Todor

I do not exactly understand what you mean.

So I wil try to make a short explaination.

On my motor is a 512 line encoder, which means that the motor needs 2048 pullses for one revolution.
At the first try I would find out how fast the UHU's where.
Because my computer can't generate that much pulses/sec, I connected my UHU to a function generator. En turned it up till my RPM meter displayd 4800 RPM wich is equal to 163840 pulses. Butt then I was affraid that my motor explodes, so I stopped.
But i did not watch the error count.
So, after I read your posting, I connected the UHU card to my computer and ran my motor at 3000 RPM = 102400 pulses/sec. Did this for about 5 min, 100 turns left, full speed turn, then 100 turns richt, and so one.
And that gives an error count of 0.

Greetings
Wotje

[LZ1TWB]

Hello wotje,

So good for you that you do not have my problem. Just for a reference can you provide some more info about your setup I mean motor supply voltage, what motor are you using, things like that.

About the high frequency why you don't use your computer and the built-in multiplier in the uhu - it does the job. Anyway It makes the motor sound loud cause I think steps are applied asymmetric in time meaning it puts out a group of steps according to the multiplier value then waits till the next pulse from the computer and the signal will look something like this -

.... .... .... instead of
. . . . . . . . . . . . which causes the high noise in the motor.

It is best when "M" is 0 but with a high res encoder we end up with a slow speed. Better to put Mach3 to 45Khz mode but that means faster computer.

Bye, Todor