Actual limit on encoder frequency

[H.O]

Hi,
I'd like to hear from you what real-life speeds you have been able to reach with the UHU.

I initally started out with 3600 lines encoder which I knew was a bit much for the UHU but I now have a 500 line unit mounted and I can't seem to get above 400rpm without getting invalid counts.

400 * 2000 / 60 = 13.3kHz which is WAY below the 100kHz stated in the manual. ( Yes, I have the step-multiplier setting set to 0 )

The encoder is single ended but I have it wired to a DS9638 diff.driver and then a shielded twisted pair cable, about 1m long, shield connected to GND in the DB15 on the HP-UHU and only there. I've also tried with a 120ohm termination resistor across each pair at the DB15 but that didn't make any difference.

I've scoped the signals as they enter the DB15 connector and they look nice, sharp and uniform.

My motors are rated 2000rpm and my plan was/is to order 625 lines encoders from USDigital. I have a 2:1 belt reduction and 5mm pitch screws so that will give me a nice and even 1000 steps/mm and still stay well below the published 100kHz limit.

Right now I'm a bit bummed I will revert back to the higher resolution encoder and see if I get matching results with that one. In the meantime I'd appreciate if you could give me some info about you systems.

Thank you in advance!

/Henrik.

[neilw20]

Why are you dividing by 60. What has your power supply line frequency got to do with the encoder?
400 rpm * 500 lines (assuming only single edge) = 200Khz, so that is way past 100Khz spec. It did well !!

[H.O]

Hi Neil, thanks for responding.

I divide by 60 because there's 60 seconds in a minute. The motorspeed is measured in revs per minute while the encoder frequency in measured in Hz or cycles per second. So if the motor is doing 400rpm's it's doing 400 / 60 = 6.6667 revs/second and there's 2000 encoder transistions for each rev so 6.6667 * 2000 = 13.3kHz.

So.... No, the line frequency (which is 50Hz where I live) doesn't have anything to do with it and no, I don't think it did well at all actually ;-)

I'm leaning towards a 'fishy' encoder but I'd really like to hear what kind of speeds others have been able to get before I shell out more money on new encoders.

So, what kind of speed have you been able to get and what type of encoder do you have?

/Henrik.

[rokag3]

I am going to make a new serie of test i hope i will give you some precise measure tomorow
Lucien

[rokag3]

by the way if it is 500 lines
500 * 4 =2000 points
400 rpm revolution per minutes make
400/60 =6.666666666 revolutions per second
so 6.66666666etc* 2000 =13333 signals per second or 13.33khz
this look like a software limit
if you use m=4 can you go at 1600 rpm ?
if yes you reach the limit of your software not the limit of uhu

[contactirfu]

Hi Henrik,

what is the T setting in your UHU

for me increasing T meant a lot more speed on the motor, achieved almost 150IPm and my motor looks similar to urs.

with a lower T setting my motor always errorred.

presently my settings on the UHU are

P 1600
T 250
H 7000
E 100

and also may be I did not understand your Q well!

RGDS
Irfan

[neilw20]

H.O.

Yeah sorry about the 60 !
My thumb was in bцm and mind was in neutral !
I should have canceled the units as I was taught !
It like I should doit the right way and not the other way like I say.

[H.O]

Hi,

Lucien,
No, If I change the multiplier the motor will turn faster but I get more invalid transitions. I CAN go faster with the multiplier set to 0 it's just that the faster I go the more invalid encoder transitions I get (as seen by the O paramter in the UHU. So IMHO it's definetly a problem with the encoder signals/frequency and not with the frequency of step pulses.

I'm looking forward to see your testresults!

Irfan,
The problem isn't that the drive errors out or the available torque. The problem is that I can't run the motor at any reasonable speed without getting false transistions on the encoder lines (the O-parameter in the UHU, it should ALWAYS stay ay zero) which effectively means I'm loosing position which isn't acceptable.

The Torque Limit (T) is set to 255 on mine, if you set it to a lower value, say 128, you'll only get 50% of the available torque so your results are quite expectable.

Neil,
No problem, happens to me all the time!

All,
I'm having a hard time beleiving that it's really the limit since the manual states 100kHz, the FAQ says atleast 150kHz and that over 300kHz is possible under the right conditions. So it's probably the encoder itself, the diff-driver (although I have tried without it too) and/or the wiring but I'd like to know what others have achieved before getting new encoders. Please look at the O-parameter and make sure it really stays at zero.

Thanks guys!
/Henrik.

[CarbideBob]

When you had the scope on the signals did you check to see if the A and B phase shift was correct? Transition on B should occur on the center of the A pulse and vice versa. This phase shift should have been set by the encoder manufacture during assembly and test. Rare but sometimes they mess it up.
Bob

[H.O]

Hi,
Yes I did and they are....I'd say. Attached is a photo of the scope signals, my scope software is crappy so I have to take a photo - sorry for the bad quality.

However, they are a bit jittery. I don't know if that is part of the problem or if it's just the scope having trouble triggering repeatably. I shot this video while doing a 250rev turn at 500rpm, after that I had 17 false transistions...

http://www.youtube.com/watch?v=hSfIz6FpBPY]Link to YouTube

Not very exciting but you can see that the phase shift seems to be correct but also that there are bit of jitter. Is it the scope, noice or the encoder....hmmm......

Thanks!
/Henrik.

[vroemm]

I've scoped the signals as they enter the DB15 connector and they look nice, sharp and uniform.

Message deleted
Because i had the wrong answer, sorry :-)

[H.O]

Vroemm, not at all....
( In Vroemm's now deleted message he suggsted to use a signal generator instead of the PC as the source for the step-signals to the HP-UHU )

Initially I thought about testing with a signal generator but since the UHU manual states that the O-paramter keeps track of invalid transitions on the encoder inputs I discarded the idea and "locked in" on the encoder.

However, after reading your message I though that it's worth a try and don't you just know it - it works a lot better..... I've now run it at 62.5kHz for over 10 minutes straight and the O-paramter still reads 0 as in ZERO, ZIP, NADA!

I tried going above 62.5kHz (1875rpm in my case) but the motor won't tag along very well above that apparently. (Max speed is 2000rpm according to the datasheet).

As it happends, the frequency-pot on my signal generator is bit flakey/noicy so sometimes, when turning the frequency up or down, it "jumps" a bit. - I notice that when it did the UHU immediately detected a fault transition on the encoder.

The computer I used in my previous tests is a laptop that I've been using for years with Mach3 and never had a problem. Tomorrow I'll switch the computer I'm going to use on the machine and see if that makes any difference. I REALLY hope it does or the only way to go is with an external motion controller like the SmoothStepper....

/Henrik.