[H.O]

Hi Todor,
Yes ~1MHz with a Smoothstepper, 4000rpm motor 3600 lines encoder (14400 in 4X mode).

From my experience here, using the UHU drives I realized that there are two main things where the drive should be good - keeping tight with the setpoint and always knowing where it is at. /Error counts = 0/

The UHU uses interrupts and software to keep track of the encoder and position, if the frequency is too high it starts to miss "counts" because there's a certain amount of time needed between "counts" in order to process everything.

This module uses a hardware quadrature counter incorporated inside the microcontroller, it'll keep track of the encoder at speeds up to 2.5Mhz. Aother thing that can cause "lost position" is noise. Noise is bad for any controler and the higher the bandwidth is the more sensitive the system is. Because of the UHU's "limitied" encoder count frequency it's a bit less sensitive to noise than what this module is. On the other hand, the module has a built in digital filter that can be used to "lower" the bandwidth in case noise is a problem. (It's always better to remove the problem but in reality that can sometimes be hard.)

Tuning can be quite tricky, and it's no different with this module. It does offer a few more tools though that allows you to see what is happening in greater detail. First, it has a "peak error detector" that will show you the largest error detected since power-up or reset. Simply, as long as the following error limit isn't reached it'll tell you just how big of an error there has been.

Then there's the datarecorder, it's not continously outputting the error like the UHU-chips analyse mode does but it records 128 values in internal memory and then outputs them to the terminal, this is very good for analysing the step-response. One of the possible "triggers" for the recorder is direction change - you could use that to see exactly what the motor does when reversing.

Another thing that bothers me is the fact you are using the new chip on a HP UHU board. As I see you have preserved the original PWM ratios, and this should be no problem for the old power stage. I remember Kreutz did some changes to the drivers' dead times and such on the HP ver. Is there any difference in the control signal, going out of the processor concerning this?

No, the UHU chip outputs a single PWM-signal modulated between 13 and 87% with 50% being "center", resulting a net current of 0A thru the motor (this is what's called locked antiphase). This signal, being only a single drive-signal can not contain any dead-time, the dead-time is handled completely by the drives hardware (the IR21844 drivers on the HP-UHU) and it can not distinguish the modules PWM signal from the UHU-chip's PWM signal, they look exactly the same. (Actually the frequency may be slightly (2.5%) higher on the UHU but it doesn't make any difference)

What you CAN do is increase the modulation from 13-87% up to 8-92% if the hardware can accept that but as you noted it's by default the same as on the UHU. I've run my HP-UHU at 8-92% without problems but you should verify that the high side bootstrap capacitor has enough time to refresh when doing that.

/Henrik.

[LZ1TWB]

Sorry about the delay.

With my hardware I can achieve only 1/3th of the frequency you have done, so If you want to test it to the limits, someone else has to come up with a motor with higher rpm and pulses per rev. What I can do is hook it to any axis, tune it properly and do some real world cutting and bring some kind of results. Of course this will be far below its speed capabilities.

Apart the obvious higher noise I get when using the multiplier option is there any other problem with the tuning and/or the control algorithm connected with it? As I understand the original UHU adds pulses next to the input ones and this makes some sort of jitter in the signal, which makes the motor to hum more. I guess if the chip can predict when the next encoder count arrives and put this additional pulse in the middle of the two, the motion will be a lot smoother. I've never really devoted myself with this kind of stuff, just thinking. They have taken care of this in the SS.

What about the Fault I/O pins? I cannot ask if you have done any changes, because you don't know the original code but I am curious about the behavior. Does it have some software filtering? The original UHU and the schematic seemed to not have any filtering which made it too easy to reset. In the beginning here the chip faulted every time the motor took some more current from the drive. I managed to deal with this bypassing the IN pin with a small cap to ground. Now I get only rare resets when the 3 phase vacuum-cleaner gets stopped because of contactor arcing. Should take care of it. Just asking if this will be something similar.

Todor