Servo processor "upgrade module" - looking for volonteers.

[H.O]

Hello everyone,
I've developed sort of an "upgrade module" (for lack of a better name) for the UHU based servo drives. This module is pin-compatible with the original UHU chip but allows you to use step-frequencies of 1Mhz or more and the encoder inputs are capable of tracking the encoder at speeds up to 2.5Mhz.

Here's a photo of a prototype mounted on the HP-UHU:


Other features are:
* Velocity and acceleration feed forward.
* Sliding scale following error.
* Data recorder (plot following error, PID output, motor velocity etc).
* Servo loop rate 1220-2500Hz (adjustable in 10 steps)
* Antidither function with setable range and scale for the PID gains.
* Output offset for unbalanced loads.
* Digital encoder filter for increased noise imunity.

Here's a YouTube- Servo module 1.avi video showing the module running on the HP-UHU driving a servo motor equipped with a 3600line encoder at ~3900rpm (936kHz step frequency).

Here are links to a preliminary datasheet and a preliminary manual.

What I'm currently looking for is 3-4 volonteers that are interested in trying/testing a module. I'll give you one module for free and in exchange you give me feedback on the operation of the module and its documentation which I linked to above. What's good, what's not good, what's missing - that sort of thing. I promise to do my best to sort out whatever problems we may find but I give no gurantees what so ever.

I've been testing the module myself for quite some time without having any real issues (lock-ups, motor run-away etc) but you need to understand that I can not be held responsible for any damages to humans or equipment that, in a worst case scenario, may be the result of using the module.

Once we've sorted out any bugs/issues/problems you may, if you like, send the module back and have its firmware updated and then returned to you free of charge - you pay shipping one way. (The firmware is not open source and, for the record, is not based on any other open source servo project code.)

I'd appreciate if you, as a beta tester of the module have a general understanding of how a closed loop servo system works and how to tune it - it'll make any problem solving neccessary a lot easier for both of us.

General questions, if there are any, in the thread please. If your interested in testing a module please PM me here on the zone or E-mail me at: henrik [at] henriksplace [dot] se

/Henrik.

[tenmetalman]

'WOW' I'm impressed, no wounder you've been hard to get. wonderful project, hope it goes well. unfortunately I've stripped a good portion of the wiring in my machine & an working at resolving a gremlin. so I'll not be of much help. between my gremlin & very little time I'm going backward. keep us posted.
Best of Luck & let me know if I can be of any assistance
Paul

[H.O]

Thanks Paul,
I'm sorry if you've been trying to reach me by e-mail lately, my ISP decided to discontinue my e-mail adress so I had to get a new one. If you need me please feel free to e-mail me at the adress shown in the first post or you can always PM me here on the 'zone.

/Henrik.

[jcdammeyer]

Cool. Looks like a dsPIC?

I've not even finished the patterns for my HP-UHU's although I finally ordered and bought (way too many) of the threaded inserts so that I can clamp down the FETs.

The casting is done for the knee but that uses a stepper. Drawings are done for the X and Y axis but no patterns built yet so no motors mounted. Looking at file dates of drawings etc. I can see I stopped the moment I started on the Olympic Ring projects back 01Dec08 for delivering a working ring set 02Feb09 that was then increased in scope by 50% so pushed to 05Mar09.

After that the rest of the year was a writeoff. Now I'm back and working on all this stuff like a busy beaver but I'm afraid I can't help you with testing.

John Dammeyer

[H.O]

Hi John,
No dsPIC, it's an "ordinary" 18F2431. Sounds like we're in the same boat, my knee-mill project have been on "hold" since last September or something like that. I always seem to get sidetracked, but being a hobby I don't really have a problem with that. Looking forward to declaring the machine conversion done though - like that is ever going to happen ;-)

/Henrik.

[jcdammeyer]

Originally Posted by H.O Hi John, I always seem to get sidetracked, but being a hobby I don't really have a problem with that. Looking forward to declaring the machine conversion done though - like that is ever going to happen ;-) /Henrik.

I sidetracked myself by starting a JGRO CNC router. Stepper controlled in this case and built with anal retentiveness. If you can be anal with MDF. Most of the metal bits are all castings so first I have to make patterns and then I cast. I have 3 more bearing holders to cast and 6 more rail holders.

I'm hoping this will be a nice addition to the shop for pattern making and milling holes in plastic enclosures. I also have a nice vacuum pump I picked up that will work well for a hold down system. Inbetween I'm doing the CNC conversion on the mill.

Then there are the electronic projects that are unfinished...

John

[tenmetalman]

It's good to hear that my project isn't the only one languishing for lack of attention! Arturo been waiting for, i hate to admit it, almost a year to help me with a gremlin! too many projects, interfering paying jobs & wife"s needs, etc
Paul

[jcdammeyer]

Hi Henrik,

Yeah, my latest project is a 5 channel slider pot controller that can send/receive messages via RS485 and generate the correct format messages out the CAN port.

Or use the slider pots to send the correct messages out the CAN port.

It talks to the same kind of lights used for the Olympic Rings. I still have to write the DMX-512A interpreter for it too. Then it can talk to the Light-O-Rama USB to DMX-512A module and I can control the ORing lights to Christmas music. Great Fun!

John

[LZ1TWB]

Hi Henrik,

Good to know you have some interest in upgrading the UHU drive. That is great as it has a lot of potential, I've been using the old board well over half an year and had no problems concerning the drive itself.

I am interested in the whole thing, and could eventually upgrade my system if it becomes a good alternative. A little about my setup here. I was forced to remove my 2500 pulse encoders and put 1024 ones on their places. Of course the overall pulse count was the problem. Now I get reliable rapids at 5000mm/min, could do 7000 maybe, but going further leads to errors, well known problem. I am satisfied with this speed for now, as my previous machine did only 1200mm/min, but more is always welcome.

As for the beta testing, what kind of hardware as machine, power supplies and other stuff will be needed? I suspect one should watch for all sorts of problems with this kind of equipment, curious if I could do something for the developing.

Todor

[H.O]

Hi Todor,

Only real requirement is a terminal emulating software to communicate with the module (such as hyperterminal, realterm etc). The module uses different communication parameters compared to the original chip so the terminal software specifically developed for the UHU chip will not work.

Apart from that there are no special requirements regarding powersupplies, motors, encoder etc and no special equipment should be needed. The module should work wherever the UHU chip did and "beyond" - that's the idea. So really, I'd appreciate whatever enviroment anyone can put it in. If it's within the original UHU chips speed envelope that's great, if it's outside that envelope it's even better.

In your particular case it would be nice to see how it compares at you current setup and if possible try it with the 2500ppr encoder as well and see how it does. It's been verified to work at 1Mhz so if the motor can take it you should be able to get 6000rpm with the 2500ppr encoder - at least.

I'd be more than happy to send you a module, free of charge of course, if you feel you have the time to try it.

/Henrik.

[LZ1TWB]

Hi,

So you are driving it at ~1Mhz, I assume this is with the smoothstepper. I did some calculations here. My motors are 2000rpm max, I have 1024, 2000 and 2500ppr encoders. Even with the 2500 ppr I can get "only" 333Khz, and since I am using the PP, at a kernel of 45Khz, I should use a multiplier of 8 to 10 maybe to get a reliable movement. Your manual says it should be below 10 as I recall.

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/. When this is done, there should be no problems driving this or that king of metal. Of course after proper adjustment.

It was a little hard to tune myself the axes, as I wanted to use relatively higher accelerations, and I always get some overtravel when starting or stopping, looking at the terminal program. I am now at 600mm/sec^2, and I think some of the artifacts I get on my wooden pieces are due to this. This is seen on a change of direction or at the near end of a move, where one axis stops and the other accelerates, and stuff like that.

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?

Todor

[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.