Actual limit on encoder frequency

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

[vroemm]

Originally Posted by kreutz The apparent problem could be also un-related to encoder noise, but more related to noise/jitter at the Step input.

There is a way to measure the jitter.
At startup the free version of turbocnc on msdos shows a screen with on it a text something like:

"On this computer Jitter approaches 10% at xxxxx Hz."

On my old amd 7934 500 Mhz computer it shows 16500 Hz.
I do not know if this is a reliable or useful number.
You could try it, and see if you get a higher step rate when turbocnc shows a higher frequency.

Are there differences in the quality of the parallel port ?
Maybe a different parallel port card gives less jitter ?

Do you have other programs running ?
Maybe without knowing it ?
Other programs demand some cpu time.
Which could increase jitter.

Can other PCI, ISA, USB or other cards increase jitter ?
Like the presence of a soundcard ?

Vroemm.

[neilw20]

Henrik,

You really don't want to close up the overlap time.
Does this card use 4013 flip flop or some other counter chips.
A generic 4013 requires clock rise time better than 15uS as do quite a few counter chips. This is a trap because if the designer used schmit trigger input counters his design would work.
Phillips HEF4xxx parts have no rise time limits. Most generic parts quite often have.
If the clock inputs are not buffered into a CMOS counter chip the rise time usually has to be less than 15uS. This is because internally the flip flop uses the property of a transmission gate, namely remembering the last data state during the clock transition. The small capacitor storing this state loses it's charge and hence the logic can become corrupted. It is also temperature dependent.

[vroemm]

Originally Posted by H.O 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.....

The UHU community talks about a lot.
But somethings are not talked about, as far as i have read.
Like the accuracy of their cnc router, 1 mm, 0.1 mm or 0.01 mm ?
Which is important.
I rarely have read about it.

Have you read messages mentioning the actual step speeds others have reached ?
If not, maybe everybody uses the lower step speeds ?

Vroemm.

[H.O]

Hi Guys,
The computer is running Mach3 and Mach3 only (well of course there's other processes running but nothing "extra", no antivirus etc). The LPT-port is the onboard one, I don't have a PCI-card right now but I doubt it'll make any difference. Running the Mach3's DriverTest application shows that the system stability is "excellent" - even att 100kHz kernal frequency, please see the attached screendump.

Scoping the step-signals reveals that there's jitter on the pulsestream for sure, the higher kernal-frequency I select the better it gets - as can be expected. If I set the step-pulse width to 3 in Mach3 I get roughly 10uS wide pulses but even with the kernal frequency set to 100kHz I can not go above 600rpm (20kHz step-frequency). (I know it wouldn't work with 10uS wide pulses at 100kHz step-rate but I can't reach that speed anyway so....)

Normally, if a step pulse is to be sent during "this" interrupt Mach3 sets the output, then go and do some other housekeeping and then resets the output at the end of the same interrupt. This produces narrow(ish) pulses on the step-line. But there's also a mode available where the step-pulse doesn't get reset untill the next interrupt, thus producing much wider pulses (and effectively reducing the max step frequency by 50%). I've tried this mode too to no avail, so building a flip-flop circuit that stretches the pulses probably won't make any difference.

Regarding what speed others get - I don't know....that's pretty much why I started this thread. There are some confliting number floating around, everything from 100kHz to over 300kHz on the UHU-website, then someone stating they never could reach beyond 75kHz.

Obviously the problem IS the jitter since it works fine with the signal generator, I'm just a bit dissapointed that it just won't work with Mach3 without spending more money on a Smoothstepper or simmilar device :-(

Thanks!
/Henrik.