AVR oder TTL f. Laengenanzeige?

"Falk Brunner" schrieb:

Praxistest.

An der Stelle muss ich passen. Ein normaler mechanischer Drehenkoder geht wohl recht schnell über die Wupper, wenn ich ihn mit Hilfe einer Bohrmaschine bediene; davon abgesehen kommen dessen Kontakte dann wohl gar nicht mehr mit ;-)

Jetzt fehlt mir ehrlich gesagt die Einschätzung, wie weit und wie schnell so ein CNC-Maschine-Inkrementalgeber inklusive der abenteuerlichen mechanischen Randbedingungen ("Rolle und Skalenseil") durch überlagerte Torsionsschwingungen seine Signale tatsächlich ändert. Wenn die Schwingweite nur maximal einen Step beträgt, würde wohl die doppelte Abtastrate genügen, um worst case noch ohne Übersprung zählen zu können. Bei mehr als einen Step wird die Prellfrequenz interessant, um die tatsächlich benötigte Abtastrate herauszubekommen.

-- Es gibt keine Neue Rechtschreibung. Es gibt eine Rechtschreibung und eine neue Schreibweise. Ausserdem hätte ich lieber eine Mathematikreform, dann wäre das Rechnen nicht so schwer.

"Andreas Donner" schrieb im Newsbeitrag news:dgjk4t$2i4n$ snipped-for-privacy@ulysses.news.tiscali.de...

Muss man ja nicht zwangsläufig mit einem echten Inkrementalgeber machen. Ein programmierbarer Funktionsgenerator tuts hier auch, ist teilweise sogar besser, da man GENAU definerte Störmuster erzeugen kann.

Na das ist dann die Creme dela creme im Praxistest. Denn ein 100% funktioniertender Encoder nützt wenig wenn die Mechanich schurch Schlupf, Spannung und wasweissich die Messung versaubeutelt.

MfG Falk

Hallo Rolf

Ein freund von mir möchte, das ich eines kommentar hier bringen. Ich bin aus Dänemark, ud habe schwirigkeiten Deutsch zu screiben. So ich enschuldige dass ich in english fortsetsen.

I have read this long thread, A lot of people have said a lot of correct things, but the information is not condensed into a single post, I will try doing that for one possible solution out of many,

And yes, the job to resolve the output from a quadrature encoder is not as simple as it looks at first sight.

The main issue is to keep correct track of the encoder movement, if that criteria is not met, the rest is nonsense.

For reading correctly, the receiver of the signal must be faster than the encoder signal frequency. It must have a margin, which leaves room for torsional vibration, and jitter because of limited accuracy of the fabricated position of individual "position marks".

Next you have to use a schmitt trigger with RC filter to remove noise that is faster than 3 to 5 times the maximum possible encoder frequency. Take care to dimension this filter correctly (consider also time for the signal to pass the hysteresis interval).

Next you need a state machine to get the reading correct. The state machine can be made as a x1, x2 or x4 output counting "frequency" of the encoder input frequency, I prefer the x2 because it is a compromise between resolution and noise immunity.

Next you have the problem of concurrency, One job is to carefully track the encoder signal, another is to display the result, and maybe do offset calculations.

As this is a hobby project, I don't consider the additional cost of some cheap components as a showstopper.

What matters more is to use some components and a development environment already known, so a solution can be reached within a reasonable time.

As this supposedly is not going to be produced in millions of units, I suggestt a two chip solution: One AVR for tracking the encoder, this AVR just acts as a hardware 8-bit encoder counter.

This will reduce the timing constraint by a factor of approx. 100. This allows for a timer interrupt routine in the other AVR, which inputs the eight bits, and extends the resolution to the required number of bits. And this without any timing sweat.

Instead of having severe trouble making a program with hard timing requrements, you now have two simple programs to make. The cost for this solution is a little more current consumption, PCB space and an AVR costing less than 2 euros.

I have personally chosen this solution, and made a tiny26 encoder counter, which samples the encoder at 1.1 MHz, This should be enough for your case. It is just a simple assembler main loop not using interrupts executing at an average of 14,5 cycles. It requires some analysis to reduce the cycles to that level, but less can do the job for you.

Good luck with your project. :-)

Best regards Erik

Gar nicht kniffelig. Ungefähr so (20 kHz Sample / 500 Hz muxen):

volatile char mux_interrupt = 0;

void Interrupt() { static char zaehler = 0; Behandle_Quadratur_Signal(); zaehler += 1; if (zaehler >= 39) { mux_interrupt = 1; zaehler = 0; } }

void main() { init_all_stuff();

while (1) { while (mux_interrupt == 0) sleep();

mux_interrupt = 0;

rechne_ganz_lange_nur_nicht_zu_lange(); } }

In dem Beispiel oben wird rechne_ganz_lange_nur_nicht_zu_lange() (fast) beliebig oft unterbrochen, man muss sich um keine Syncronisation sorgen machen, usw.

( Die Funktion sleep() wacht nach jedem Hardware-Interrupt auf. )

Your german is a notch above my english!

Thanks for the time you spend for me and my issue.

Take a look at the de.sci.electronics FAQ:

The solution there is closly to your.

This sounds simply and safely. At present i look for a flat, no time to tinker, no workshop. So i can try your solution only at end of year.

Thanks again, and all the best wishes.

Rolf