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

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

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.

[contactirfu]

I am learning a lot of things here - please continue!

[H.O]

OK, I couldn't resist trying the other computer tonight...unfortunately it didn't make much difference. I was able to reach around 600rpm without getting any false transitions.

It seems to make it bit better when "stretching" the step-pulses but even with Mach3 set to 5uS step-pulses (which in reallity is MORE than 5uS) it doesn't work above ~600rpm. (When running with the signal generator the dutycycle was 50% so....)

Does anybody know if the UHU "steps" on the rising or falling edge of the input? I have the step-pulse in Mach3 set to active high which "feels" right but I can't find any info in the docs about the UHU-chip if IT steps on the rising or falling edge.

This new computer has a 3.3V parallelport so, in hopes of that being part of the problem, I installed my C11 breakoutboard from CNC4PC but it made no difference what so ever.... The computer is a purpose built machine without any extra junk, 2.3GHz dual-core CPU and 2gig RAM so it's as good as it gets for Mach3 use, basicly.

Irfan, if your reading, you reached 1350rpm with your 250line encoder, thats 13.5kHz which matches exactly what I've been able to reach. What happend when you raised the kernal-speed in Mach3? Have you looked at the O-parameter to see if you get any false transistion?

I'm really quite bummed right now....I'll leave it for today.....

Thanks guys!
/Henrik.

[neilw20]

I will (attempt to) explain a fault transition which in normal operation is an impossible signal sequence with quadrature square wave.
As you have already discovered there are to signals lets call them A and B being approximate square waves 90 degrees out of phase.
Following just assumes forward is as described, but that could be reverse in fact. If you were to swap A and B then the following logic will magically come good.
Line A goes high/low in a square wave manner, one for each line of encoder (in most peoples opinion, but depends on who wants big numbers on their spec.) and so does Line B
While rotating in FORWARD:

1. Line B low to high transitions occur when A is high.
2. Line A high to low transitions occur when B is high.
3. Line B high to low transitions occur when A is low.
4. Line A low to high transitions occur when B is low.

While rotating in reverse:

5. Line B low to high transitions occur when A is low.
6. Line A high to low transitions occur when B is low.
7. Line B high to low transitions occur when A is high.
8. Line A low to high transitions occur when B is high.

When rotating forward the sequence is always 1-2-3-4-5-6-7-8-1-2..
When rotating in reverse the sequence is always 8-7-6-5-4-3-2-1-8-7..

A direction change can occur at any sequence position like 1-2-3-4-3-2-1..
A valid stationary position can be 4-5-4-5 or 8-1-8-1.
In a stationary position ONLY ONE channel can 'rattle' at any one time.
Both signals NEVER CHANGE at the same time. This is a fault transition.

Depending on how circuits are implemented a clock transition can be on every edge of both signals or only clocked by A sampling B.
When an edge on one line is detected the state on the other line is sampled. The sampled state depends on direction.
Of the 8 states, you can only move from one to the next or previous.
Drawing a timing/transition graph with the 2 channels soon gives some idea of the possible and the impossible following the rule 'both signals NEVER CHANGE at the same time'.
It is easier to experiment with this than describe it ! Please verify my logic.
Can someone will explain in 1 line what I should have written.

[Al_The_Man]

One other explanation which Is the way I learned , is if you consider A as the count pulse and B as the direction, which is the way that the earliest encoders functioned.
A & B are two pulses in quadrature, i.e. 90° apart.
In one direction when the leading edge A pulse clocks a count the B pulse will be high (forward), if you reverse direction, when the leading edge of A pulse clocks (previously the trailing edge) , the B pulse will be low, denoting reverse.
In order to increase the resolution of an encoder, the counts can be increased by counting both A & B (x2) or rising and falling edge of A & B (x4).
BTW, if you want to reverse the count of a single ended encoder reverse A & B, with a differential, reverse A & /A.
Al.

[H.O]

Hi,

Going forward B is low on every rising edge of A and high on every falling edge of A. Going backwards B is high on every rising edge of A and low on every falling edge of A.

I know what a false or invalid transition/state is - what I don't know is why I get them when using the PC/Mach3 to generate the STEP-pulses and not when using the signal generator.

Indeed there's more jitter in the step-pulsetrain when generated by the PC compared to the signal generator but again, that's the step-pulses, "feeding" the drive - why does it make any difference?

The UHU uses 4X quadrature decoding natively - it's not changeable.

Thanks!
/Henrik.

[kreutz]

Hello Henrik;

I kept on thinking after I replied to your P.M. about this problem. I am sorry, I was not following this thread.

The apparent problem could be also un-related to encoder noise, but more related to noise/jitter at the Step input. The way the UHU chip works, it triggers an interrupt for every transition of the A and B encoder signals, but also with every step signal transition. Noise at the step input could trigger successive interrupts, so the encoder interrupt service could be delayed until the false (noise induced) step interrupts are serviced, meanwhile the current A and B encoder channels logic levels could change, and become an invalid status when the interrupt service routine gets to run..

Using an steady input waveform (pulse generator) would emulate a more favorable condition where the above mentioned scenario does not exist, and permit the firmware to service the encoder interrupts on time, and before the current encoder A and B logic level change. So that could be the reason why the maximum encoder frequency seems to be higher when using the pulse generator.

What chip are you using in the U3 position? try using a 74HC14.

[neilw20]

When an edge generates an interrupt, ideally at the SAME TIME as the interrupt, BOTH A and B need to be read.
If the interrupt routine is reading A and or B AFTER the interrupt, it is possible the data may have already changed, so the wrong logic state is processed.
A good way to achieve this and get rid of the latency problem is to read the A and B bit on the same port and have each transition generate the the interrupt.
There are a lot of low end CPU's that can't do this. You can only tell it which pin will be the interrupt pin. We need more than one interrupt pin for proper operation.
Externally you can latch the state with a flip-flop to overcome the latency problem, but if you are going to spend money on extra parts to overcome the problem, you might just as well use a better (more expensive) CPU.

There are quadrature chips that do all the fancy timing stuff up to frequencies, that would require a Pentium, so the chip keep count and the CPU just examines the count and direction from the chip as required.

Bottom line. Can the CPU hack the pace. That's why the error signal is required. The CPU might be off in the weeds when it is needed.

[H.O]

Neil,
The drive and the processor is what it is - it's not changeable, not at the moment anyway. There may be a processor upgrade in the future but right now it is what it is.

With over 4000 UHU-chips sold and Mach3 being as popular as it is I'm having a hard time seeing that I should be the first to realize it doesn't work above 15-20kHz.....

Kreutz,
(Mixing in comments to your PM here)
U3 is 74HC14 and I've already increased the pulsewidth in Mach3 to 5uS. Doing that made it slightly better but I can't go above 600rpm (20kHz) without losing position.

I'll make some more experiments today, the goal is to have 2500counts per rev, and have the multiplier setting set to 1 in the UHU, with my gearing and screws that'll give me 500steps/mm at ~42kHz. If all else fails I'll try a "pulse-stretcher" flip-flop with around 10uS. But, with that route, if the jitter is large I may end up missing step-pulses instead....aarghh....

Please, can't anybody else report what you're getting!?

Thanks,
/Henrik.