Impulsverdoppler für alte Heidenhain Anzeige

[Simon (schimon)]

Hallo

Ich hatte mir eine Alte Digitalanzeige von Heidenhain für unsere 
Fräsmaschine gekauft. Jedoch hat die Signalauswertung der Anzeige nicht 
zur Fräse gepasst. D.h. bei einer Umdrehung am Handrad (2,5mm) hat die 
Anzeige nur 1,25mm angezeigt.

Lösung:
Daraufhin habe ich einen Impulsverdoppler gebaut und möchte diesen hier 
zum Nachbauen teilen.
Das ist nur ein möglicher Ansatz, und wahrscheinlich auch nicht die 
einfachste Lösung, aber sie funktioniert.

Aufbau:
Umgesetzt mit einem NE555 und einen uC (hier Attiny45, kann aber auch 
ESP oder Arduino genutzt werden).
In "Digitalanzeige2" sieht man das PCB mit Beschriftungen der IC´s.
In "Digitalanzeige" sind 2 Leitungen an den Pins 4 & 5 des ersten 
SN74LS192N (4-Bit aufwärts/abwärtszähler). Dort werden die ersten 
Zählimpulse für die 7-Segementanzeige abgegriffen.

Funktion:
Diese werden dann in die selbstgebaute Schaltung eingespeist. Dort 
werden sie vom NE555 erkannt und an den uC weitergegeben, der dann den 
Transistor (hier ein FET, kann aber auch BJT genutzt werden) ansteuert 
und den Pin des Zählers nach einem Impuls nochmals auf GND zieht für 
einen zweiten Impuls.

Der NE555 wird benötigt, da der Impuls der Anzeige nur ~50ns lang ist 
und das der uC sonst nicht erkennt. Die Versorgungsspannung kommt von 
der Anzeige selbst (Sind Pins auf dem PCB verfügbar -> 5V !Aufpassen 
wegen 3,3V uC).

Wichtiges:
(Dieser Schaltplan ist nur für eine Zählrichtung, um beide 
Zählrichtungen zu verdoppeln, muss alles Außer dem NE555 verdoppelt 
werden und an 2 weitere I/O`s am uC gesendet werden. Zusätzlich muss der 
Code für den uC angepasst werden, da er auch nur für eine Zählrichtung 
passt. Ist aber nur Copy/Paste und den Pin anpassen.)

Code:
Der Code erkennt den Impuls auf dem Eingangspin, wartet kurz und gibt 
einen weiteren Impuls am Ausgangspin des uC aus. Es ist eine 
Impulssperre eingebaut, damit es zu keinem Loop kommt. Diese blockt den 
künstlich erzeugten Impuls des uC auf dem Eingangspin.

Ich würde mich über Feedback freuen, da das mein erstes Veröffentlichtes 
Projekt ist.

[Wegstaben V. (wegstabenverbuchsler)]

clevere Idee!

[Andreas B. (bitverdreher)]

Bei diesem TTL Grab kommen ja nostagische Gefühle auf. ;-)
Ansonsten: Gut gemacht!

[Nick (b620ys)]

Vorsicht!
Je nach maximaler Verfahrgeschwindigkeit und Auflösung der Masstäbe 
kommst du da schnell in den zig-MHz-Bereich des Signals. Du hast 
sicherlich/hoffentlich die Pausen und Pulszeiten deines Verdopplers 
dahingehend nachgerechnet.

Noch ein Hinweis:
Die unsigned long (keine Ahnung wie viele Bytes das auf der jeweiligen 
Plattform hat, warum nicht uint32_t?) sind möglicherweise unnötig lang. 
Es genügt ein uint16_t.
Wenn da glaubst, dass du uint32_t wegen Überläufen brauchst, dann schalt 
die Anzeige aber auch nach 71 Minuten aus. :-)
Falls man mit der absoluten Zeit rechnet (machst du nicht, du arbeitest 
relativ) kommt man nur mit uint64_t (bei µs Auflösung) mit einen 
vorausschaubaren Zeitrahmen hin.

[Mi N. (msx)]

Nick schrieb:
> Vorsicht!
> Je nach maximaler Verfahrgeschwindigkeit und Auflösung der Masstäbe
> kommst du da schnell in den zig-MHz-Bereich des Signals.

Mit einem Handrad? Niemals!
Bei Messtastern von Heidenhain kommst Du auf max. 100 kHz der 
Sinussignale, womit die in den Datenblättern angegebene max. 
Geschwindigkeit schon überschritten ist.

Simon schrieb:
> Wichtiges:
> (Dieser Schaltplan ist nur für eine Zählrichtung, um beide
> Zählrichtungen zu verdoppeln, muss alles Außer dem NE555 verdoppelt
> werden und an 2 weitere I/O`s am uC gesendet werden.

Das ist etwas ungeschickt. Wenn schon ein ATtiny verwendet wird, kann 
man ihn die Signale des Weggebers unter Berücksichtigung der Richtung 
auswerten lassen und passend skaliert wieder ausgeben: Monoflops lieben 
es zu floppen ;-)

[Gerald B. (gerald_b)]

Passend zur Steuerung hätte ich das wahrscheinlich mit 1-2 
TTL-Grundgatter-ICs aufgebaut. Bei denen brauchst du dich auch nicht mit 
Pufferüberläufen u. dgl. rumärgern ;-)

[Nick (b620ys)]

Mi N. schrieb:
> Mit einem Handrad? Niemals!

Kommt auf die Schrittweite an. Ich kann 1 mm pro Schritt einstellen, 
also 100 mm pro Umdrehung. Zusätzlich hat die Fräse ja auch noch einen 
Vorschub. Soll genau dann die Anzeige nicht mehr funktionieren?

Mi N. schrieb:
> Bei Messtastern von Heidenhain kommst Du auf max. 100 kHz der
> Sinussignale,

Sind aber Impulse, kein Sinus. Steht ja auch so in der Beschreibung.

[Simon (schimon)]

Nick schrieb:
> Vorsicht!
> Je nach maximaler Verfahrgeschwindigkeit und Auflösung der Masstäbe
> kommst du da schnell in den zig-MHz-Bereich des Signals. Du hast
> sicherlich/hoffentlich die Pausen und Pulszeiten deines Verdopplers
> dahingehend nachgerechnet.
>
> Noch ein Hinweis:
> Die unsigned long (keine Ahnung wie viele Bytes das auf der jeweiligen
> Plattform hat, warum nicht uint32_t?) sind möglicherweise unnötig lang.
> Es genügt ein uint16_t.
> Wenn da glaubst, dass du uint32_t wegen Überläufen brauchst, dann schalt
> die Anzeige aber auch nach 71 Minuten aus. :-)
> Falls man mit der absoluten Zeit rechnet (machst du nicht, du arbeitest
> relativ) kommt man nur mit uint64_t (bei µs Auflösung) mit einen
> vorausschaubaren Zeitrahmen hin.

Also die Pausen zwischen den Impulsen passen, dass habe ich mit einem 
Oszi kontrolliert. Da müsste man schon mit einem Akkuschrauber rangehen 
um da was zu überlappen ;D

Zu dem unsigned long:
Also dann statt diesen ulong einfach byte nehmen?
const unsigned long min_interval = 50; // Mikrosekunden
const unsigned long pulse_delay = 20;     // Mikrosekunden Verzögerung 
vor Impuls
const unsigned long pulse_duration = 20;  // Mikrosekunden Impulsdauer

und zu den Überläufen: 71min sind für mich nicht wirklich lang (das habe 
ich vergessen nachzurechnen). Um da überläufe und probleme zu vermeiden 
könnte ich auch ein Dword nehmen oder was ist das nächst größere von 
uint32_t?

[Stephan S. (uxdx)]

Gerald B. schrieb:
> Passend zur Steuerung hätte ich das wahrscheinlich mit 1-2
> TTL-Grundgatter-ICs aufgebaut. Bei denen brauchst du dich auch nicht mit
> Pufferüberläufen u. dgl. rumärgern ;-)

Das schreit nach einem 74123

[Simon (schimon)]

> Simon schrieb:
>> Wichtiges:
>> (Dieser Schaltplan ist nur für eine Zählrichtung, um beide
>> Zählrichtungen zu verdoppeln, muss alles Außer dem NE555 verdoppelt
>> werden und an 2 weitere I/O`s am uC gesendet werden.

Ja da habe ich mich verschrieben, ich meinte man muss alles außer den uC 
verdoppeln, da hoch- und runterzählen getrennt, mit seperaten NE555 sein 
müssen.

> Das ist etwas ungeschickt. Wenn schon ein ATtiny verwendet wird, kann
> man ihn die Signale des Weggebers unter Berücksichtigung der Richtung
> auswerten lassen und passend skaliert wieder ausgeben: Monoflops lieben
> es zu floppen ;-)

Meinst du direkt die Signale des Linearmaßstabs?
Weil (so wie ich weis) kann man nur schwer die Signale in abhängigkeit 
der Richtung auswerten.
Oder was meinst du mit "passend skaliert"?

[Simon (schimon)]

Stephan S. schrieb:
> Gerald B. schrieb:
>> Passend zur Steuerung hätte ich das wahrscheinlich mit 1-2
>> TTL-Grundgatter-ICs aufgebaut. Bei denen brauchst du dich auch nicht mit
>> Pufferüberläufen u. dgl. rumärgern ;-)
>
> Das schreit nach einem 74123

Ich hatte es mit einem Xor mal versucht, aber wieder aufgegeben. Damit 
habe ich mich noch zu wenig beschäftigt.
Aber wahrscheinlich hat man weniger Singalprobleme.

[Nick (b620ys)]

Simon schrieb:
> Also dann statt diesen ulong einfach byte nehmen?

Theoretisch würde das Byte (unsigned) auch schon genügen. Ich würde aber 
lieber 2 Byte nehmen.

Simon schrieb:
> Und zu den Überläufen: 71min sind für mich nicht wirklich lang (das habe
> ich vergessen nachzurechnen).

Nein, das ist bei dir kein Problem! Bei Überläufen mit unsigned passiert 
nichts, solange man mit **Differenzen** arbeitet.
Würdest du eine absolute Zielzeit ausrechnen (also now + 50 µs) gibts 
irgendwann einen Überlauf und die Zielzeit springt zurück.

Probier die Rechnerei einfach mal aus. Das Ergebnis ist bissl witzig. 
:-)

Das mit den 71 Minuten passiert **nur** wenn du mit absoluten Zeiten 
arbeitest. Und das machst du ja nicht.

[Nick (b620ys)]

Simon schrieb:
> Weil (so wie ich weis) kann man nur schwer die Signale in abhängigkeit
> der Richtung auswerten.

Ich hab den Eindruck (aus seiner Beschreibung), dass das System eher 
steinalt ist und mit zwei Pulsen arbeitet. Einer für vorwärts und einer 
für rückwärts. Ich schätze, dass die Anzeige aus den späten 1970ern ist.

Mit Quadraturencodern (A/B-Signal) ist das mit der Impulsverdopplung 
nicht so einfach.

[Simon (schimon)]

Nick schrieb:
> Simon schrieb:
>> Weil (so wie ich weis) kann man nur schwer die Signale in abhängigkeit
>> der Richtung auswerten.
>
> Ich hab den Eindruck (aus seiner Beschreibung), dass das System eher
> steinalt ist und mit zwei Pulsen arbeitet. Einer für vorwärts und einer
> für rückwärts. Ich schätze, dass die Anzeige aus den späten 1970ern ist.
>
> Mit Quadraturencodern (A/B-Signal) ist das mit der Impulsverdopplung
> nicht so einfach.

Ja das ist eine Heidenhain VRZ102B. So wie ich das verstanden habe gibt 
es 2 Pulse und je nachdem welcher zuerst kommt zählt die anzeige 
vorwärts oder rückwärts.
Und mein Ansatz ist komplett reversiebel. Einfach die selbstgebaute 
Schaltung abstecken und die Anzeige funkioniert wie vorher.

[Mi N. (msx)]

Nick schrieb:
> Mit Quadraturencodern (A/B-Signal) ist das mit der Impulsverdopplung
> nicht so einfach.

Quadraturdekoder, Zähler mit +/- 2 bei jedem Flankenwechsel, 
Quadraturenkoder zur Ausgabe.
Vielleicht reicht es schon, eine 2-fach auf 4-fach Auswertung 
umzustellen. Das geht ganz locker mit einem ATtiny45.

Simon schrieb:
> Ja das ist eine Heidenhain VRZ102B

Das Datenblatt dazu sagt nichts über den anzuschließenden Meßtaster aus 
und trägt kein Datum. Allein wird noch eine 4-stellige PLZ angegeben.
Sehr dürftig.

Frage an den TO: MT12 -> ST1207?

[Nick (b620ys)]

Simon schrieb:
> Ja das ist eine Heidenhain VRZ102B. So wie ich das verstanden habe gibt
> es 2 Pulse und je nachdem welcher zuerst kommt zählt die anzeige
> vorwärts oder rückwärts.

Oh! Dann ist es nochmal anders. Ist das dann schon ein 
A/B-Signal??Eigentlich dürfte deine Schaltung dann nicht funktionieren. 
Oder es ist so wie bei den Hummeln, die nicht fliegen können dürften. 
:-)

Oder es ist nochmals eine andere Abart. Da wären Oszillogramme 
interessant. Mit unterschiedlichen Geschwindigkeiten damit man sieht, ob 
die beiden Signale immer gleichen Abstand haben und sich beide zusammen 
nur in der Frequenz ändern.

[Stephan S. (uxdx)]

Simon schrieb:
> Der NE555 wird benötigt, da der Impuls der Anzeige nur ~50ns lang ist
> und das der uC sonst nicht erkennt.

Ich habe gerade 2 Datenblätter von PICs auf dem Schirm, PIC10(L)F322 und 
PIC12(L)F1240, da scheinen 25 ns auszureichen, um einen Interrupt 
auszulösen. Habe es aber nicht selbst ausprobiert.

[R. L. (roland123)]

wenn man die Impulse schon mit einem µC aufbereitet, wäre es dann nicht 
am sinnvollsten gleich noch ein Display dran zu hängen und die Werte 
direkt anzuzeigen?

[Mi N. (msx)]

Kann man, braucht aber schon einen ATmega48, wenn es Sinussignale sind 
und 1 µm Auflösung benötigt wird.
Der TO hat aber seine passende Lösung gefunden.

[Falk B. (falk)]

Simon schrieb:
> Der NE555 wird benötigt, da der Impuls der Anzeige nur ~50ns lang ist
> und das der uC sonst nicht erkennt. Die Versorgungsspannung kommt von
> der Anzeige selbst (Sind Pins auf dem PCB verfügbar -> 5V !Aufpassen
> wegen 3,3V uC).

Naja. Der NE555 ist auch nicht der Schnellste, die 50ns sind schon eher 
knapp. Der AVR kann das auch selber erkennen, Stichwort Pin Change 
Interrupt. Ja, da reichen 50ns. Also reicht ein uC, wenn man es richtig 
macht auch für beide Zählrichtungen. Und der kann auch mit 5V laufen.

[Falk B. (falk)]

Stephan S. schrieb:
> Das schreit nach einem 74123

BINGO. Mit 2 Monoflops kann man die Zeitverzögerung und den 2. Puls 
problemlos erzeugen. Ganz ohne Software.

[H. H. (hhinz)]

Falk B. schrieb:
> Stephan S. schrieb:
>> Das schreit nach einem 74123
>
> BINGO. Mit 2 Monoflops kann man die Zeitverzögerung und den 2. Puls
> problemlos erzeugen. Ganz ohne Software.

Einfach den Teiler richtig einstellen, das braucht weder Hard- noch 
Software.

Aber es handelt sich ja bestimmt um ein Geheimmodell...

[Simon (schimon)]

Ich lad euch die woche noch ein paar oszigraphen hoch.

Das es noch einfacher mit 1 Baustein geht, habe ich nicht erkannt. Mich 
würde aber interessieren ob und wie es geht.

[Falk B. (falk)]

Simon schrieb:
> Das es noch einfacher mit 1 Baustein geht, habe ich nicht erkannt. Mich
> würde aber interessieren ob und wie es geht.

Man konfiguriert einfach ein 74HC123 mit 2 Monoflops. Das erste 
macht die Verzögerung und startet das 2., welches den 2. Puls erzeugt. 
Man braucht nur 2 RC-Glieder nach Datenblatt berechnen. Allerdings muss 
man auch verhindern, daß sich die Schaltung selber wieder startet. Siehe 
Anhang. So könnte es gehen. Eigentlich sind hier jetzt drei Monoflops 
drin.

[Marcel V. (mavin)]

Simon schrieb:
> Das es noch einfacher mit 1 Baustein geht, habe ich nicht erkannt. Mich
> würde aber interessieren ob und wie es geht.

Es geht sogar mit nur einem einzigen Gatter von einem 4-fach 
XOR-Baustein.

[Falk B. (falk)]

Marcel V. schrieb:
>> Das es noch einfacher mit 1 Baustein geht, habe ich nicht erkannt. Mich
>> würde aber interessieren ob und wie es geht.
>
> Es geht sogar mit nur einem einzigen Gatter von einem 4-fach
> XOR-Baustein.

Nö, nicht mit den Vorgaben und Zeiten des OP. Denn der sagt, daß 
Startpuls nur 50ns breit ist, er aber gern 20us Verzögerung, 20us Puls 
und dann 50us Pulssperre haben will.

[Falk B. (falk)]

Hier die Einchiplösung. Da die beiden Pulse nicht zeitgleich auftreten, 
sollte das passen.

[Falk B. (falk)]

Lapsus. Die Zeile in setup() muss geändert werden.

PORTB = 0b11100;

[Falk B. (falk)]

Beitrag "Re: PCINT, Signal-Timing?"

[Simon (schimon)]

Nun habe ich ein paar Graphen für euch:

Der Maßstab gibt tatsächlich Sinuswellen aus. Auf allen Pins.
Der Startimpuls ist doch eher so 300ms lang.
Der 2. Impuls kann von dem obigen code abweichen, da das eine ältere 
Version ist also nicht verwirren lassen ;D

Dann werd ich noch den code mit dem Interuppt probieren, bin nur 
neugierig, ob das so geht.

[Falk B. (falk)]

Simon schrieb:
> Nun habe ich ein paar Graphen für euch:
>
> Der Maßstab gibt tatsächlich Sinuswellen aus. Auf allen Pins.
> Der Startimpuls ist doch eher so 300ms lang.

300ns.

> Der 2. Impuls kann von dem obigen code abweichen, da das eine ältere
> Version ist also nicht verwirren lassen ;D
>
> Dann werd ich noch den code mit dem Interuppt probieren, bin nur
> neugierig, ob das so geht.

Er geht, hab ich getestet. Allerdings nicht mit 50ns Pulsbreite. 300ns 
sollten passen. Den RC-Takt vom AVR sollte man so hoch wie möglich 
einstellen, der tiny45 geht bis 8MHz. GGf. muss man vielleicht den INT0 
auf fallende Flanke umstellen. Das geht in setup() mit der Zusatzzeile.

MCUCR = (1<<ISC01);   // INT0 bei fallender Flanke

[Nick (b620ys)]

Simon schrieb:
> er Maßstab gibt tatsächlich Sinuswellen aus.

Das 3. Bild ist aber nicht das Heidenhain das ich kenne. Da sind die 
Signale 90° verschoben Das wären dann die sin/cos Maßstäbe.

[Mi N. (msx)]

Nick schrieb:
> Das 3. Bild ist aber nicht das Heidenhain das ich kenne. Da sind die
> Signale 90° verschoben Das wären dann die sin/cos Maßstäbe.

Wo und was gemessen wurde ist eh nicht klar. Die gelbe Kurve könnte das 
Eingangssignal einer Phase eines Messtasters mit 1 Vss sein. Die Taster 
arbeiten rein analog, sodaß es da auch nirgends einen 'Startimpuls' 
gibt.

Seinerzeit hatte ich ATmega48 für Sinusauswertung mit 100-facher 
Auflösung verwendet. Bei 10 µm bzw. 20 µm Perioden der Heidenhain-Taster 
ergab das eine Auflösung von 0,1 µm bzw. 0,2 µm.
Die Grundschaltung für 11 µA Signale mit IIC-Kommunikation ist hier 
gezeigt: http://mino-elektronik.de/mt12_iic/mt12_iic.htm
Die Anschlußbelegung des Signaleingangs passt 1:1 an eine 9-pol. 
Anschlußbuchse mit 10-pol. Flachbandkabel.
Dazu hatte ich auch einmal eine Schaltung mit 2 x 16 LC-Anzeige, die ich 
nicht mehr finde aber auch einfach erweitert werden könnte.

Soviel zu:
R. L. schrieb:
> wenn man die Impulse schon mit einem µC aufbereitet, wäre es dann nicht
> am sinnvollsten gleich noch ein Display dran zu hängen und die Werte
> direkt anzuzeigen?

[Ob S. (Firma: 1984now) (observer)]

Falk B. schrieb:

> Den RC-Takt vom AVR sollte man so hoch wie möglich
> einstellen, der tiny45 geht bis 8MHz.

Nö, das stimmt nicht. Neben den üblichen Alternativen (Externer 
Takt/Quarz/Resonator) verfügt diew TinyX5-Baureihe (und damit natürlich 
auch der Tiny45) über das geile Feature "PLL-Takt" und kann somit 
zumindest 16Mhz vollständig innerhalb seiner Specs. 5V-Versorgung darf 
man hier ja als gegeben ansehen.

Die nominell erlaubten 16MHz lassen sich (wohl nicht mehr ganz 
spezifikationsgerecht, aber nichtsdestotrotz erfahrungsgemäß vollkommen 
problemlos) mittels OSCCAL auch auf 18MHz hochzwirbeln. Ich benutze das 
ziemlich regelmäßig für meine eigene V-USB-Implementierung. Weil 18/1.5 
halt eine Ganzzahl ist, was vieles deutlich vereinfacht. Diese Sache 
spielt aber natürlich beim Problem des TO keine Rolle.

Was bleibt, ist das Abtast-Theorem. Auch 62.5ns sind eindeutig noch viel 
zu lang, um zuverlässig 50ns-Pulse detektieren zu können.

Aber da gibt es ja die Interrupts. Damit wäre die Detektion problemlos 
möglich. Und der Witz ist hier: man muss nicht zwingend eine ISR 
beschäftigen. Man kann die Tatsache des Interrupt-Requests auch 
problemlos synchron abfragen und zurücksetzen, also ohne dass jemals ein 
Interrupt tatsächlich ausgelöst wird.

[Falk B. (falk)]

Simon schrieb:
> Dann werd ich noch den code mit dem Interuppt probieren, bin nur
> neugierig, ob das so geht.

Schon getestet?

[Simon (schimon)]

Falk B. schrieb:
> Hier die Einchiplösung. Da die beiden Pulse nicht zeitgleich auftreten,
> sollte das passen.

Habe nun den code auf einen Attiny45 gepackt und die schaltung auf einem 
breadboard aufgebaut. PB0 und PB1 als Singal-Pin.
PB0 funktioniert (Siehe Bild PB0)
PB1 geht nicht (Siehe Bild PB1)

Bei PB0 sieht man klar die pulldown's auf GND bei PB1 sind diese nur 
sporadisch vorhanden.

[Falk B. (falk)]

Simon schrieb:
> PB0 funktioniert (Siehe Bild PB0)
> PB1 geht nicht (Siehe Bild PB1)

Hast du die Änderungen eingebaut? Anbei der aktuelle Quelltext.

[Simon (schimon)]

Falk B. schrieb:
> Simon schrieb:
>> PB0 funktioniert (Siehe Bild PB0)
>> PB1 geht nicht (Siehe Bild PB1)
>
> Hast du die Änderungen eingebaut? Anbei der aktuelle Quelltext.

Welche Änderungen meinst du?
Dieser Quelltext hat das gleiche problem

[Falk B. (falk)]

Simon schrieb:
>> Hast du die Änderungen eingebaut? Anbei der aktuelle Quelltext.
>
> Welche Änderungen meinst du?

Die ich oben genannt hatte.

> Dieser Quelltext hat das gleiche problem

Hmm, komisch.

Mit welchem Takt läuft der Tiny45? Zeig mal das Signal an PB0 gut 
aufgelöst, damit man den Orignalpuls (300ns) und den Zusatzpuls sieht.

[Simon (schimon)]

Hier habe ich besser aufgelöste Impulse. Wie wärs wenn wir einen anderen 
Pin (z.b. PB4) nehmen? Der uC läuft mit 8Mhz, 16Mhz hatte ich aber auch 
schon probiert.

[Falk B. (falk)]

Hmmm, Fehler gefunden! Ich hatte das Symbol vom ATtiny13 im Eagle 
kopiert und einfach umbenannt. Leider liegt INT0 beim Tiny45 auf PB2! 
Siehe Anhang, jetzt geht es!

[Simon (schimon)]

Ja, jetzt funktioniert es! Oh man, hätte ich das gewusst, dass es nur 
mit einem uC geht, dann hätte ich mir das ganze mit der Schaltung sparen 
können...

Das nächste mal wende ich mich direkt an euch :D
Danke nochmal!