AVR oder TTL f. Laengenanzeige?

[Falk Brunner]

"Andreas Donner" <AnDon@gmx.de> schrieb im Newsbeitrag
news:dgi8kh$2ap7$1@ulysses.news.tiscali.de...

Moin,

Fertig. Jetzt hab ich's halt doch mal probieren müssen. AT90S2313 mit

;-)

16MHz. Abtastung, Dekodierung und Übersprungdetektion in einer
50ľs-Task, das reicht grenzwertig für 20kHz. Aufdröselung des
Anzeigezählers in 5 Ziffern plus Vorzeichen und Multiplexen der Anzeige
in der Hauptschleife. Warnung bei Übersprung und Bereichsübertretung
durch Anzeige mit abwechselnd blinkendem Zahlenwert und Strichen
"-----". Rückstellung der Einfachheit halber durch Reset. Belegung ist
71% von 2kB. Kein Pin mehr übrig ;-)

Programmieren und simulieren kann man viel. Jetzt fehlt noch der Praxistest.
Inclusive echtem Stresstest (Prellen etc.)

MFG
Falk

 

[Andreas Donner]

"Falk Brunner" <Falk.Brunner@gmx.de> schrieb:

Programmieren und simulieren kann man viel. Jetzt fehlt noch der
Praxistest.
Inclusive echtem Stresstest (Prellen etc.)

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.

 

[Falk Brunner]

"Andreas Donner" <AnDon@gmx.de> schrieb im Newsbeitrag
news:dgjk4t$2i4n$1@ulysses.news.tiscali.de...

Programmieren und simulieren kann man viel. Jetzt fehlt noch der
Praxistest.
Inclusive echtem Stresstest (Prellen etc.)

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 ;-)

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.

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.

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

 

[Erik Kuhlmann]

Michael Schöberl wrote:

hmm. Quadratur-Signal nehme ich an...

+---+ +---+ +---+ +---+
"CLK" | | | | | | | |
+---+ +---+ +---+ +---+ +---+

+---+ +---+ +---+ +---+
"DIR" | | | | | | |
+---+ +---+ +---+ +---+


alle 3 Wochen das gleiche ...
das ist nur der günstigste Fall konstanter Geschwindigkeit.
Wenn dein Geber auf der Kante steht, dann gibts sowas

+---+ ++++-------+ +---+ +---+
"A" | | |||| | | | | |
+---+ +-------++++ +---+ +---+ +---+

+---+ +---+ +---+
"B" | | | | | | |
+---+ +------------------+ +---+ +---+

Flankenwechsel koennen beliebig schnell werde -> man kann
nie alle mit einem Interrupt-Eingang erfassen

was tun? wenn man genau hinschaut sieht man, dass diese schnellen
Wechsel keiner echten Bewegung entsprechen -> man braucht sie nicht
erfassen - die Auswertung darf nur nicht durcheinanderkommen


Eine *zustandsgesteuerte* Auswertung kommt damit klar, die würde
man im Timerinterrupt machen und ist auch ziehmlich kurz.
(siehe FAQ)


Das sollte sich mit fast jeder CPU erledigen lassen.


ack


bye,
Michael

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

 

[Michael Roth]

Falk Brunner wrote:

Soweit die (unvollständige) Theorie. Schon klar, deine MUX-Routine muss nur
sagen wir mal 500 mal pro Sekunde laufen (5 Stellen mit 100 Hz geMUXt).
Aber während deine MUX Routine läuft muss die Abtastung weiter laufen. Und
das wird kniffelig.

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

 

[Rolf Bredemeier]

Hi Erik!

Erik Kuhlmann wrote:

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.

Your german is a notch above my english!

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

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

Take a look at the de.sci.electronics FAQ: http://dse-faq.elektronik-kompendium.de/
F.29. Quadraturdecoder für Inkrementaldrehgeber

The solution there is closly to your.

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

Good luck with your project.

Thanks again, and all the best wishes.

Rolf