Hallo, ich brauche einen µC für meine Diplomarbeit und bin grad bei der Wahl. Die Diplomarbeit kurz zusammengefasst: Ich muss eine elektrotechnische Schaltung für Drehzahlkonditionierung konzipieren. Dabei enstehen Frequenzen von bis zu 24kHz. Diese werden von sinusförmigen Signalen zu Rechtecksignale umgewandelt (TTL-Signal, dank Bauteil MAX9926). Die sinusförmigen Signale sind die Zähne eines Zahnrads. Mein µC soll die Anzahl der Zähne eingegeben bekommen und dann pro Umdr. ein Signal ausgeben. Sozusagen wäre nur eine Einlese- Zähl- und Ausgabefunktion vom µC erwartet. Das spannende ist nur, dass der µC nicht länger als 1µs für das ganze brauchen darf. Bei Digikey.de kann man nach Eigenschaften filtern. Bei den 16/32 bit µC sind welche da die bis zu 400MHz takten. Die Wahl des µC bezieht sich auch auf die Programmierung, mir wäre die C-Programmiersprache am liebsten. Was könntet ihr mir da empfehlen. Danke im Voraus Gruß Koray
Ein Link auf den bestehenden Thread wäre nett gewesen, meinst du nicht? Beitrag "hochfrequente Drehzahlmessung mit welchem MC?"
Koray schrieb: > pro Umdr. ein Signal ausgeben. Sozusagen wäre nur eine Einlese- Zähl- > und Ausgabefunktion vom µC erwartet. Das spannende ist nur, dass der µC > nicht länger als 1µs für das ganze brauchen darf. Und wozu brauchst du da einen µC? Jeder diskrete Rückwärtszähler, dem man den Zählanfang vorgeben kann, kann das. > Bei Digikey.de kann man nach Eigenschaften filtern. Bei den 16/32 bit µC > sind welche da die bis zu 400MHz takten. <erstaunter Ausruf> Bist du wahnsinnig? Jeder schwachbrüstige µC der mit mehr als ein paar Mhz getaktet werden kann, kann das. > Was könntet ihr mir da empfehlen. Welche µC kennst du denn schon? Auf einem AVR kann zb ein extern getakteter Timer das meiste deiner Aufgabenstellung vlllständig alleine in Hardware lösen.
> Die Diplomarbeit kurz zusammengefasst: Interessant fuer was man heute alles ein Diplom bekommt. > Bei den 16/32 bit µC sind welche da die bis zu 400MHz takten. Das ist ein Witz oder? Nimm einen beliebigen kleinen Controller fuer das Userinterface und einen externen Zaehler wenn er nicht schnell genug zum zaehlen ist. Und nebenbei gesagt, bloss weil die fetten Controller intern so schnell laufen, muss das noch lange nicht heissen das ihr IO da mitkommt. > Was könntet ihr mir da empfehlen. Liess doch einfach selber ein paar Datenblaetter und begruende deine Wahl in deiner Arbeit. Ich meine irgendwas musst du doch selber machen oder? Olaf
> Und wozu brauchst du da einen µC? Es gibt nicht nur ein Zahnrad, meine Schaltung soll mehrere Zahnräder messen können. D.h. es gibt welche mit mehr oder weniger Zähnen. Der Benutzer der Schaltung soll das Extern eingeben können, und der µC soll das dann für die Messung als Vorgabewert speichern und dem entsprechend zählen. > Bist du wahnsinnig? Jeder schwachbrüstige µC der mit mehr als ein paar > > Mhz getaktet werden kann, kann das. Hinzuzufügen ist, dass der µC eine Messungenauigkeit von max 25ns haben darf. > Welche µC kennst du denn schon? Nicht viele oder eher gesagt kaum welche, das ist fast Neugebiet für mich.
Naja Messungenauigkeit hat in dem Fall aber wohl eher was mit der Taktungenauigkeit vom uC zu tun. Wenn dein 400Mhz Teil einen zu ungenauen und evtl Temperaturinstabilen Takt hat kommste damit ja auch nicht weiter...
Kannst Du die Vorgaben (1 uSec und 25 nsec)mal präzisieren? So allein im Raum klingen sie nach horrendem Schwachsinn. Hab vor mehr als 30 Jahren in meiner Diplomarbeit u.a. eine Drehzahlregleung mit Hilfe eines Z80 realisiert. Solche Vorgaben wie bei Dir sind mir aber schleierhaft. 25 nsec bei mechanischen Teilen klingen in meinen Ohren sinnlos.
Mit einem AVR und seinen Zeähler (Eventzähler + einstellbare Compare-match) bekommst du das auch einstellbar hin. Aber wieso um Himmelswillen schreibst du so eine Diplomarbeit, wenn du von Mikrocontrollern keine Ahnung hast? Und was studierst du überhaupt? Und wo?
slowslow schrieb: > Kannst Du die Vorgaben (1 uSec und 25 nsec)mal präzisieren? > kann ich gerne machen. Es geht um das Blade Tip Timing -> http://www.agilismeasurementsystems.com/nsms/fundamentals/arrival-times-to-deflection.html Ein Zahnrad ist an einem Schaufelrad gekoppelt. Durch die hohen Drehgeschwindigkeiten, kann es passieren, dass die Schaufeln ausgelenkt werden. Sie sind also nicht starr. Das Zahnrad dass ich zu untersuchen habe ist starr. Ich soll aus dem Zahnrad dann den genauen Zeitpunkt der Umdr. angeben können, sodass dann durch andere Sensoren am Schaufelrad ermittelt werden kann ob denn die Schaufeln ausgelenkt werden, wenn ja wie sehr. Mein Zahnrad ist sozusagen das Referenzsystem, da es starr ist. Meine Diplomarbeit beschäftigt sich mit der Triebwerkstechnik. Sinn der Arbeit ist es oder eher gesagt Sinn der Schaltung soll sein, frühzeitig eine zu Hohe Auslenkung erkennen und ein Triebwerksausfall durch gebrochene Schaufeln zu verhindern. Somit denke ich müssten die 25ns (Un-)genauigkeit etwas besser erklärt worden sein.
Mir ist die Aufgabenstellung nicht präzise genug. Was sind die 1µs und die 25ns? Wenn ich das richtig verstehe, geht es doch eher um eine Frequenzmessung mit einer entsprechenden Auflösung. In der Richtung muss einmal denken. Es gibt da ja Verfahren, die eine hohe Auflösung mit einer zweiten Frequenz erreichen ohne dass der µC selbst mit 400MHz getaktet werden müsste.
>Aber wieso um Himmelswillen schreibst du so eine Diplomarbeit, wenn du >von Mikrocontrollern keine Ahnung hast? Die Diplomarbeit klang sehr interessant, und die Anforderungen wurden mir am Anfang gar nicht gesagt, ich hatte sogar fertige Lösungen vorgestellt mit Audiokarten die die Signale schon bearbeiten. Problem war das mit der Zeit erst klar wurde, dass das System "echtzeitfähig" sein soll und die hohen Anforderungen. Zumal ich am Anfang auch nur Analogtechnik anwenden wollte. Weiteres Problem die Arbeit ist schon an der Hochschule angemeldet, also muss ich da jetzt leider durch und versuche noch das beste daraus zu machen, und nehme jede mögliche Hilfe an. Ich studiere Elektrotechnik.
> Mir ist die Aufgabenstellung nicht präzise genug. Was sind die 1µs und > die 25ns? die 1µs ist die Verzögerung Eingang-> Ausgang. Meine Schaltung darf also max 1µs Bearbeitungs-Rechenzeit brauchen, um es dann am Ausgang als TTL auszugeben. > Wenn ich das richtig verstehe, geht es doch eher um eine Frequenzmessung > mit einer entsprechenden Auflösung. ja > Es gibt da ja Verfahren, die eine hohe Auflösung mit einer zweiten > Frequenz erreichen ohne dass der µC selbst mit 400MHz getaktet werden > müsste. kannst du das näher erklären?
Koray schrieb: > Ein Zahnrad ist an einem Schaufelrad gekoppelt. Durch die hohen > Drehgeschwindigkeiten, kann es passieren, dass die Schaufeln ausgelenkt > werden. Sie sind also nicht starr. Das Zahnrad dass ich zu untersuchen > habe ist starr. Ich soll aus dem Zahnrad dann den genauen Zeitpunkt der > Umdr. angeben können, sodass dann durch andere Sensoren am Schaufelrad > ermittelt werden kann ob denn die Schaufeln ausgelenkt werden, wenn ja > wie sehr. Mein Zahnrad ist sozusagen das Referenzsystem, da es starr > ist. Das heißt: Du musst den "Nulldurchgang" des Referenzzahnrads auf 25ns genau bestimmen können. Sehe ich das so richtig? Der Nulldurchgang ist durch einen Referenz-"zahn" am Zahnrad markiert. Wobei der exakte 0-Durchgang durch die Mitte dieses Referenzzahnes definiert ist. Dein 0-Signal darf maximal +/- 25ns von diesem exaktem 0-Durchgang abweichen. Soweit korrekt? (Um mal die Ratespiele soweit abzukürzen, dass ich in meinen Worten formuliere, was ich auch dem Studium von Unmengen von Beiträgen glaube verstanden zu haben)
Karl heinz Buchegger schrieb: > Das heißt: > > Du musst den "Nulldurchgang" des Referenzzahnrads auf 25ns genau > bestimmen können. Sehe ich das so richtig? > > > Der Nulldurchgang ist durch einen Referenz-"zahn" am Zahnrad markiert. > > Wobei der exakte 0-Durchgang durch die Mitte dieses Referenzzahnes > > definiert ist. Dein 0-Signal darf maximal +/- 25ns von diesem exaktem > > 0-Durchgang abweichen. > Soweit korrekt? > exakt!
PS: Da das Zahnrad mechanisch ist, kann es ja nicht beliebig schnell seine Drehzahl ändern. Mir fällt da deshalb noch ein PLL-System ein. Das könnte man so gestalten, dass man quasi schon "vorher weiß" wann (ungefähr) der letzte Impuls kommen wird. Der µC macht alle Berechnungen vorher und synchronisiert sich dann ggf. nur noch auf den letzten Impuls. Ich denke da an einen AVR, dessen Timer mit dem externen Takt des PLL-VCO läuft und via Compare-Register das Teilen übernimmt und damit einen Ausgangspin steuert. Das geht alles noch in Hardware. Allerdings braucht jedes Zahnrad seinen eigenen Timer und die Frequenz will man ja auch noch messen. Mehr als zwei Einheiten dürfte ein AVR mit drei Timern daher nicht schaffen. Verbieten die Vorgaben, mehrere µC einzusetzen, ggf ein Master für die Siebensegmentanzeige und mehrere Slaves, z.B. einen pro Zahnrad?
Detlev T. schrieb: > PS: Da das Zahnrad mechanisch ist, kann es ja nicht beliebig schnell > seine Drehzahl ändern. Mir fällt da deshalb noch ein PLL-System ein. Das > könnte man so gestalten, dass man quasi schon "vorher weiß" wann > (ungefähr) der letzte Impuls kommen wird. Der µC macht alle Berechnungen > vorher und synchronisiert sich dann ggf. nur noch auf den letzten > Impuls. Genau in diese Richtung hab ich auch schon nachgedacht. Bei einem 60 Zähne Zahnrad: Während die Zähne 1 bis 57 durchrauschen, wird die Drehzahl möglichst exakt bestimmt. Zahn 58 wird benutzt um Berechnungen zu machen: Wann genau, nach Auftreten des Trigger-Pulses vom 59ten Zahn, muss der 0-Durchgang kommen. Danach legt sich der µC auf die Lauer und wartet auf die ansteigende Flanke vom 59ten Zahn. Kommt die, beginnt der Rückwärtszähler zu laufen und wenn der 0 erreicht, erzeugt der µC den Ausgangspuls. Während dann das Zahnrad weiter durchrauscht, Zähne 1 bis 57, hat der µC dann wieder jede Menge Zeit die Drehzahl bzw. deren Veränderung, exakt auszumessen bzw. eine 7-Seg upzudaten, falls notwendig. Die heiße Phase kommt erst wieder, wenn sich die Umdrehung dem Ende zu neigt. Allerdings ist das Zeit runterzählen mit den Timing Vorgaben nicht mehr so simpel, so dass die hohen Taktfrequenzen für den µC tatsächlich ihre Berechtigung haben (sofern man nicht auf einen externen Zähler ausweicht, der den kritischen Teil komplett eigenständig in Hardware macht)
Nein mir stehen alle wege offen. Ich hatte mir auch schon Gedanken darüber gemacht ob ich denn nicht eben mehrere µC einsetze die sich dann die Aufgaben sozusagen teilen.
Könnt ihr mir das Prinzip etwas näher erklären oder mich auf Info im Web verweisen ausse Wiki.
Es hängt natürlich auch von den Nulldurchgängen (und überhaupt den Signalen denn so GANZ verstehe ich die Sensorik und die vorhandenen Signale leider immer noch nicht.) ab, aber http://www.acam-usa.com/GP1.html ist ein Ansatz, -wesentlich- genauer als mit einem uc-Timer zu arbeiten, wenn es um Zeitbestimmung geht.
Die Sensorik ist eignetlich simpel. Aus einem ferromagnetischem Zahnrad wird durch einem induktiven Sensor das Signal erzeugt. Wenn die Zähne nah beieinander liegen, dann sieht das Signal sinusförmig aus. Es gibt auch zahnräder die haben nur einen Zahn, was die Situation meiner Meinung nach einfacher macht. Da es verschiedene Zahnräder gibt muss ich die Anzahl der Zähne eingeben können. Meine Frage, würde das Prinzip funktionieren wenn man niur ein Zahn hat?
Irgendwie errinnert mich das ganze fast an eine DCF-77 Auswertung, wobei der fehlende Minutenpuls auf +/-25ns genau rekonstruiert werden muss und sich natürlich die zeitliche Distanz zwischen den Minutenpulsen sich nicht ändert :-)
60 Zähne - ist ganz klar - klingt wie ein DCF77 Dekodar! Zumindest erfordert auch DCF77 die Prädiktion der vollen Sekunde.
Ich könnte mir vorstellen, daß ein Zahn im Bezug auf eine Nulldurchgangstriggerung blöd ist. Dann gibts doch sicherlich eine Menge verrauschtes Signal um Null herum? @DCF-77 hört sich nach einem Geistesblitz an? Kenne ich mich nur so gar nicht mit aus. Neugier ist aber geweckt. Lasst das nicht versanden :-)
Eddy Current schrieb: > Zumindest erfordert auch DCF77 die Prädiktion der vollen Sekunde. Yep. Und ich denke man könnte durchaus auch davon lernen, wie es bei Uhren gemacht wird. Im µC läuft eine 2-te Uhr mit, die die eigentlichen Ausgaben macht. Das DCF Signal dient (*) nur dazu, diese interne Uhr so in der Phase zu verstellen, dass sie mit der externen synchron läuft. In diesem Zusammenhang ist ja auch das Stichwort PLL auch schon gefallen. Mit etwas gutem Willen könnte man da IMHO auch eine Analogie zum Abgleichen einer PLL auf Frequenz und Phase sehen. (*) neben der Übertragung der aktuellen Zeit natürlich
mittlerweile kann ich euch nicht mehr folgen, was ist denn das DCF-77 hab gegoogelt aber nur bahnhof verstanden
DCF-77 ist das Zeitsignal, welches einen Funkwecker ansteuert. Die Pulse werden in Frankfurt von einer Atomuhr generiert. D.h. der Sender steht bei Frankfurt. Die Uhr selber IMHO in Braunschweig. Ihr Markenzeichen: nach jeweils 59 Sekundenpulsen fehlt 1 Sekundenpuls - der Anfang der nächsten Minute. Aber mir machen die 25ns noch zu schaffen. Die sind ziemlicher Knackpunkt.
> 25ns Jitter > Nein mir stehen alle wege offen. Ich würde ein FPGA zur Signalvorverarbeitung nehmen... Aber da wird wohl die Zeit nicht ganz reichen... >>>>> ich brauche einen µC für meine Diplomarbeit > Die Diplomarbeit klang sehr interessant, und die Anforderungen wurden > mir am Anfang gar nicht gesagt, ich hatte sogar fertige Lösungen > vorgestellt mit Audiokarten die die Signale schon bearbeiten. Und wie wird die Signalverarbeitung dort gemacht? kHz(Audio) != 1us != 25ns > Zumal ich am Anfang auch nur Analogtechnik anwenden wollte. Was spricht dagegen, die Aufgaben in Analogtechnik und uC aufzuteilen?
>>Das spannende ist nur, dass der µC nicht länger als 1µs für das ganze >>brauchen
darf.
Das hört sich nach einer Aufgabenstellung an, wo der Betreuer selbst
wenig Kenntnisse hat (welches mechanische System soll den in 1us
reagieren?).
Dafür brauchst du keinen MC, sondern eine PLL, oder einen kleinen DDS,
der dir je nach Anzahl der Zahnräder eine passende Frequenz liefert und
einen Zähler taktet.
Wenn der letzte Zahn durch ist, wird noch der Zählerstand ausgegeben und
fertig. Das kriegt man in 1us locker hin.
Hast du die time to digital converter schon mal gesichtet? Wenn du die crux der Trigger Erzeugung im Griff hast, und du bist da ja analogtechnik nicht abgeneigt, sicherlich einen Blick wert. Ok und die Meßdauer darf da natürlich nciht zu lang sein, kA ob das garantiert ist.
Lothar Miller schrieb: >> 25ns Jitter > >> Nein mir stehen alle wege offen. > > Ich würde ein FPGA zur Signalvorverarbeitung nehmen... > > > > Aber da wird wohl die Zeit nicht ganz reichen... > >>>>>> ich brauche einen µC für meine Diplomarbeit > Eben deswegen, hab leider nur noch 3 Monate >> Die Diplomarbeit klang sehr interessant, und die Anforderungen wurden >> mir am Anfang gar nicht gesagt, ich hatte sogar fertige Lösungen >> vorgestellt mit Audiokarten die die Signale schon bearbeiten. > Und wie wird die Signalverarbeitung dort gemacht? > > kHz(Audio) != 1us != 25ns Die haben analoge Messsysteme, die nicht genau genug für sie sind. Ich bin ja derjenige der die Lösung dazu finden soll. Deren Genauigkeit liegt momentan bei ca. 200ns Jedes Zahnrad hat eine eigene Schaltung, meine Schaltung soll universell sein >> Zumal ich am Anfang auch nur Analogtechnik anwenden wollte. > > Was spricht dagegen, die Aufgaben in Analogtechnik und uC aufzuteilen? tue ich ja, aus den Sinussignalen der Zähne habe ich schon durch analogtechnik, TTL-Signale erzeugen können.
Koray schrieb: > tue ich ja, aus den Sinussignalen der Zähne habe ich schon durch > analogtechnik, TTL-Signale erzeugen können. Ich nehme an, das ist irgendeine Form eines Schmitttriggers. Wie genau (zetlich) hast du denn die Schaltflanke? Was ich meine: Bei deiner maximalen Frequenz, steigt das Signal in 25ns um wieviele Volt an? Ist garantiert, das der Schmitt Trigger auch wirklich innerhalb dieser Volttoleranz durchschaltet?
Karl heinz Buchegger schrieb: > Ich nehme an, das ist irgendeine Form eines Schmitttriggers. > Wie genau (zetlich) hast du denn die Schaltflanke? ja das ist ein bauteil der laut datenblatt eine genauigkeit von 20ns und eine übertragungsverzögerung von 150ns hat. wobei ich grade am oszilloskop 300ns verzögerung messe aber naja. > Was ich meine: Bei deiner maximalen Frequenz, max ist 24kHz > steigt das Signal in 25ns > um wieviele Volt an? Ist garantiert, das der Schmitt Trigger auch > wirklich innerhalb dieser Volttoleranz durchschaltet? Das Bauteil schaltet beim Nulldurchgang. Man kann es eigentlich auch Nulldurchgangsdetektor nennen, wobei es auch eine Schmitt-Trigger Funktion realieren könnte, je nach Einstellung.
Koray schrieb: > Dabei enstehen Frequenzen von bis zu 24kHz. 24kHz ist doch gar nichts. Du brauchst da doch nichtmal den MAX. Das sollte eigentlich mit einem AVR, dem Analog Comparator und einem Timer/Counter zu erschlagen sein Ist das wirklich ne Diplomarbeit oder vielleicht eher Bastelstunde vierte Klasse? Die eigentliche Aufgabe könnte IMHO sogar ein ATtiny13 schaffen
Der springende Punkt sind ja auch nicht die 24kHz sondern die 25ns Genauigkeit und die übertragungsverzögerung
Verstanden habe ich das Problem zwar nicht, aber hier eine Lösung: Ein µC hat einen Timer mit 40MHz Taktfrequenz und Capture-Funktion. Die gelieferten 0-Durchgänge triggern jeweils das Capture-Register und werden zudem per Interrupt gezählt. Die Differenz der Capture-Werte werden addiert und nach Erreichen der Anzahl der Zähne als Gesamtzeit für eine Umdrehung weiterverarbeitet. Sofern der Zähler nicht überlaufen kann, reicht es auch nur den 1. und letzten Capture-Wert zu verrechnen (Zeitdifferenz), wenn die Anzahl für eine Umdrehung erreicht ist. Das Ergebnis (Zeit für eine Umdrehung) ist binnen <1µs verfügbar. Da es so einfach wäre, habe ich bestimmt etwas falsch verstanden :-)
Christoph schrieb: > Sry Markus ich glaub du hast das nicht verstanden ;-) Aber das hält ihn nich davon ab, gleich mal provokant zu werden ;) Eigentor würd ich mal sagen :D
Muss aber auch noch mal nachbohren: hast du abgeschätzt, ob die obigen Zeit converter in Frage kämen? Sie sind gut. Und wo kommen denn 1 us (?) Übertragungsverzögerung her im Anforderungskatalog...DAS ist mir auch noch nicht klar. Ich wollte Markus nur etwas gegen trollen.
>Sofern der Zähler nicht überlaufen kann,
Ergänzung: ... nicht wiederholt überlaufen kann ...
Anderfalls müßten die Überläufe mit bewertet werden.
Also ich habe mich während meiner Diplomarbeit sowohl in einen uC als auch in einen FPGA eingearbeitet, das geht schon ;) Da ich auch eine zeitkritische Messung durchführen musste, kam ich an dem FPGA nicht vorbei. Ist nicht so schlimm wie viele immer sagen. Man kennt Grundzüge ja auch schon aus dem Studium.
Ich hätte doch von anfang an alles reinschreiben sollen. Wollte nicht mit zuviel Text abschrecken naja. zur Übertragungszeit: Lasersensoren messen die Position der Schaufeln am Schaufelrad. Da diese aber ausglenkt werden können muss ein Referenzsystem her. Das ist dann mein Zahnrad. Die Verzögerung der Lasersensorik und Schaltung beträgt 1µs meine Schaltung soll ja dasselbe auf die reihe bekommen, damit man die signale vergleichen kann. Jetzt kommt bestimmt: warum verzögert man nicht einfach das signal der Lasersensorik. Hab ich auch schon vorgeschlagen, aber wurde abgelehnt, weil es bis zu 9 Lasersensoren sind, die dann verzögert werden müssen. Das sei zu teuer (keine ahnung was an einem Verzögerungsglied zu teuer ist) was verständlicher wäre ist, dass man so früh wie möglich das Brechen einer Schaufel verhindern will.
Koray schrieb: > Der springende Punkt sind ja auch nicht die 24kHz sondern die 25ns > Genauigkeit und die übertragungsverzögerung Mag sein, dass ich es nicht verstanden hab oder die Problematik nicht erkenne. Die 25ns hast du ja erst deutlich später erwähnt. Die grundsätzliche Aufgabe ist es doch, bei einem Zahnrad mit bis zu 60 Zähnen und maximal 30000 Umdrehungen die Impulse zu zählen und nach jeder Umdrehung ein Signal auszugeben. Klingt für mich nach einer Aufgabe, die ein 8 Bit Timer/Counter nahezu alleine erledigen kann. Taktsignal rein, Counter fängt bei 0 an, OCR steht auf dem passenden Wert für das entsprechende Zahnrad, wenn Counter=OCR wird ein Ausgang getriggert. Verzögerung zwischen Taktsignal und Ausgang sollten nur ein paar Taktzyklen sein. Hab jetzt nicht im Kopf, wie viel genau.
xGast schrieb: > Christoph schrieb: >> Sry Markus ich glaub du hast das nicht verstanden ;-) > > Aber das hält ihn nich davon ab, gleich mal provokant zu werden ;) > Eigentor würd ich mal sagen :D Naja, wenn man einzelne Informationshäppchen in zwei Threads über mehrere Beiträge verteilt... Ich bin davon ausgegangen, dass die wesentlichen Informationen in den Startbeiträgen stehen. Und nach dem, was ich da gelesen hab sollte meine Lösung eigentlich funktionieren
Markus schrieb: > Mag sein, dass ich es nicht verstanden hab oder die Problematik nicht > erkenne. Die 25ns hast du ja erst deutlich später erwähnt. > > Die grundsätzliche Aufgabe ist es doch, bei einem Zahnrad mit bis zu 60 > Zähnen und maximal 30000 Umdrehungen die Impulse zu zählen und nach > jeder Umdrehung ein Signal auszugeben. Genau. Erschwerend kommt hinzu: Dar Zahn, bei dem das Umdrehungs-0-Signal kommen soll, ist nicht vorhanden. Das Signal, welches das Ende einer Umdrehung anzeigt, darf nicht später als 25ns nach dem tatsächlichen Ende der Umdrehung kommen. Und genau da liegt der Hund begraben. Die 25ns schüttelst du mit einem AVR nicht mehr einfach so aus dem Ärmel.
ok also ich habe die ganze Zeit etwas zu hohe Anforderung an Zeitauflösung im Hinterkopf gehabt. Dafür Markus sicher etwas harsch angegangen... (was aber eigentlich auch ok ist, denn in einem halbwegs konstruktiven thread kann man sich ja mal mit so posts zurückhalten) Sollte mich erst mal zurückhalten, denn wenn man nicht ganz bei der Sache ist kommt so was raus. Wenn du schöne jitterfreie Triggersignale hast und das fpga in den Griff bekommst, mach das am besten damit. Du kannst die Zählerbreite so breit machen wie es sein muss und bekommst keine Überlaufprobleme wie beim Seppl. In 1 us bekommt man das Messergebnis über ne schnelle serielle Verbindung ja auch raus. Oder war das sogar nur das TTL Signal was nach 1 us außen ran muss? Whatever ganz bestimmt machbar und sollte passen. Zur Not ist eine Verlängerung raus zu handeln, die Betreuer wissen sicher selber am besten, daß die auch nicht die ultimative Stütze sind.
als Komparator schau dir mal den MAX913 an, der ist ziemlich schnell und ist so aufgebaut, dass im Nulldurchgang keine Glitches auftreten.
Eine Verlängerung wären maximal 4 Wochen möglich. Ich muss zugeben vor FPGA's hab ich angst, da ich keine Erfahrungen mit Vhdl oder sonstwelchen Programmiersprachen habe. Aus diesem Grund war mir eigentlich ein µC mit C-Programmierung am liebsten.
Aus meiner Sicht fehlen hier wichtige Informationen. Wie definiert man eine Abweichung von weniger als 25ns von einem nicht existenten Signal? Ist die Drehzahl überhaupt so stabil, dass man aus den bisherigen Messwerten diesen Zeitpunkt ausreichend genau schätzen kann? Und heißt "nicht später als", dass das Signal auch früher kommen darf? Um wie viel? Aus meiner Sicht kann man das nur mit einer PLL-Schaltung erreichen, egal ob analog, digital oder in Software.
Detlev T. schrieb: > Aus meiner Sicht kann man das nur mit einer PLL-Schaltung erreichen, > > egal ob analog, digital oder in Software. Ich werde nicht viel schlauer. Habe mich dumm und dämlich gegoogelt. Was genau kann man mit PLL erreichen und wie.
Karl heinz Buchegger schrieb: > Und genau da liegt der Hund begraben. Die 25ns schüttelst du mit einem > AVR nicht mehr einfach so aus dem Ärmel. Ok, bei 20MHz sind es 50ns Zykluszeit. Das erschwert die Sache. Christoph schrieb: > Dafür Markus sicher etwas harsch angegangen... Ich muss mich entschuldigen. Aber nach dem Lesen der ersten Beiträge kam mir das wirklich wie eine Aufgabe für Anfänger vor und nicht wie eine Diplomarbeit. Ändert aber nichts am Prinzip. Man bräuchte nur einen Timer/Counter, der die entsprechenden Werte erreicht. Dafür braucht man keine 400MHz MCU
Ich hoffe es hilft dir irgendwie weiter: In Time-correlated single photon counting (TCSPC) Systemen wird normalerweise ein CFD (constant fraction discriminator) zusammen mit einem TAC (oben schon erwaehnt, siehe ACAM) benutzt. Dadurch werden genaue Messungen (100 ps sind kein Problem) moeglich. Durch den CFD hat man keine Probleme mit staerkeren oder schwaecheren Pulsen (eine Aenderung in der Amplitude verursacht keinen Fehler im Timing mehr). Dann hat der TAC ein leichtes Spiel, die 10 ps Variante von ACAM kostet btw. etwa $200 (10 ps Aufloesung glaub ich). Solche Systeme koennen 10 Mio. Pulse / s mit der Genauigkeit auswerten. Beispiele gibts hier: http://www.becker-hickl.de/tcspc.htm#spc130 http://www.picoquant.com/_products.htm Vielleicht kennt ja jemand abgespeckte Varianten, die hier in Frage kommen wuerden. Felix
Eine PLL auf Basis eines DDS-Generators mit Phasenmessung und -korrektur, das sehe ich nur in einem FPGA. Zumindest läßt sich damit entspannt und beim Zähneputzen an die Sache herangehen. 2 Wochen FPGA spielen (24/7 :-)und Du denkst bereits lösungsorientiert. Alles andere gerät zu einem Workaround.
Markus schrieb: > Ändert aber nichts am Prinzip. Man bräuchte nur einen Timer/Counter, der > die entsprechenden Werte erreicht. Dafür braucht man keine 400MHz MCU Mit dem Timer meinst du bestimmt, einen der im µC intergriert ist, oder kann man einen Zähler auch als Taktgeber benutzen. Im Endeffekt wenn der Zähler extern vorher einstellbar wäre würde ein µC gar nicht benötigt oder? In Digitaltechnik bin ich ziemlich gut, ich könnte ganz leicht einen 6Bit Zähler aufbauen, der dann bis 63 zählen könnte oder anders herum von 63 runter und sobald er die 63/0 erreicht hat würde er ein takt ausgeben. Da mache ich mir bei der Übertragungsverzögerung und bei der vorherigen Festlegung der Zähneanzahl des Zählers sorgen. Ausserdem müssten die analogen Daten doch dann noch gewandelt werden oder?
Koray schrieb: > Ich werde nicht viel schlauer. Habe mich dumm und dämlich gegoogelt. Was > genau kann man mit PLL erreichen und wie. Wenn du das noch nicht kennst, wird die Anwendung natürlich schwierig. :-( Du kennst wahrscheinlich einen Regelkreis. Da wird eine Ist-Größe so geregelt, dass sie identisch mit der Sollgröße ist. Eine PLL-Schaltung macht das im Bereich der Frequenz. Man hat einen (spannungsgesteuerten) Oszillator, dessen Ausgang in der Regel mit einem Zähler durch n geteilt wird. Dieses Signal (bzw. dessen Phase) wird mit dem Sollsignal (deinem Messsignal) verglichen, so dass beide Signale phasengleich ablaufen (deshalb Phase locked loop), nur die des Oszillators entsprechend schneller. Sagen wir einmal 40MHz bei der Drehzahl. Der Zähler in der Schaltung gibt dann also die Zeit seit dem letzten Impuls mit einer Auflösung von 25ns an. Der Ausgang des Zählers (nach der Teilung durch n) ist dann im Idealfall identisch mit dem Signal, dass von den Zahnrädern kommt, wenn letzteres entsprechend stabil ist. Du brauchst jetzt noch einen digitalen Vergleicher, dessen einer Wert vom Zähler kommt, den anderen gibt der µC vor. Dann kannst du mit einer Auflösung von 25ns vorgeben, wann der Vergleicher diesen Impuls ausgibt. Vom Prinzip her dürfte es das sein, was du brauchst. Die praktische Umsetzung ist aber nicht so einfach. Erst einmal brauchst du entsprechend schnelle Komponenten. Insbesondere der Oszillator ist wohl nicht so einfach, weil er hohe Frequenzen können, eine breiten Regelungsbereich haben und zudem noch ziemlich stabil sein muss. Auch das Einrasten auf die richtige Frequenz (und nicht z.B. die halbe) ist nicht ganz trivial. Insgesamt brauchst du sicher Hilfe vor Ort. Als Einzelkämpfer in kurzer Zeit bekommt man das wohl nicht hin. Und auf jeden Fall brauchst du eine klare Beschreibung, was die Schaltung können muss (Pflichtenheft!). Gelten zum Beispiel die 25ns nur für die Maximaldrehzahl? Bei der halben Drehzahl würden ja 50ns reichen, um die gleiche relative Genauigkeit bei der Position der Turbine zu haben.
Ich habe mich auch 2 Wochen intensiv mit VHDL beschäftigt und danach hatte ich alles Notwendige für meine DA parat. Es gibt bestimmt auch fertige PLL-Bausteine für nen FPGA, die man nur noch parametrieren muss. Und das FPGA-Forum hier kann dem uC-Forum doch glatt das Wasser reichen ;)
Koray schrieb: > In Digitaltechnik bin ich ziemlich gut, ich könnte ganz leicht einen > 6Bit Zähler aufbauen, der dann bis 63 zählen könnte oder anders herum > von 63 runter und sobald er die 63/0 erreicht hat würde er ein takt > ausgeben. Nur das du mit einem 6 Bit Zähler nicht weit kommst. Wenn du deine 25ns unterschreiten willst, kannst du dir ja mal ausrechnen, wie weit so ein Zähler in zb der Zeit die dir für eine komplette Umdrehung zur Verfügung steht zählen muss. Alternativ: Ausgehen von einem fixen Zeitpunkt, zb der steigenden Flanke des letzten Zahnes einer Umdrehung, muss der Zähler wie weit zählen können, damit ermit 25ns Genauigkeit in dein 'Signal-Fenster' kommt. Du brauchst da schon einen Timer der mit geschätzten >400Mhz Takt zählen kann.
<25ns führen aber eher zu "nur" >40MHz. Wir wollen doch nicht über das Ziel hinaus schiessen?
Karl heinz Buchegger schrieb: > Du brauchst da schon einen Timer der mit geschätzten >400Mhz Takt zählen > > kann. eben drum. gibt es denn nicht zähler die schnell genug sind. Ich meine, wenn ich denn nur die Takte zähle die ich bekomme, dann hätt ichs ja schon oder nicht? Bei maximal 60 Zähnen wäre doch 6bit ausreichend. das hat ja nichts mit den 25ns zu tun. Nur die Geschwindigkeit würde doch die 25ns beeinflussen können. Schließlich meine ich mit den 6bit nur die anzahl der Zähne die der Zähler drauf haben sollte.
Hmm, nachdem ich jetzt den gesamten Thread gelesen habe, würde ich definitv einen FPGA einsetzen ... Bei z.B. 60 Zähne: Mit den Impulsen der Zähne 1-59 die Zeit über einen schnellen Zähler messen (100MHz sind kein Problem!). Anschließend den Mittelwert der Zählerstände bilden (unterdrückt Rauschen) und genau diese Zeit nach dem 59. Zahn warten und dann einen Impuls ausgeben. Ich glaub nicht, dass irgendetwas anderes einfacher ist ... Mir ist allerdings nicht klar, wie man das sauber bei nur einem Zahn macht ... Da müsste man über mehrere Umdrehungen einen Mittelwert bilden ... Grüße, Günther
Eddy Current schrieb: > <25ns führen aber eher zu "nur" >40MHz. Wir wollen doch nicht über das > Ziel hinaus schiessen? Aber nur, wenn du den Zähler auch genau genug starten kannst, so dass sein Endstand im Target-Intervall liegt. Wenn du einen Zähler nur zur jeweils vollen Stunde starten kannst, dann muss der Zähler schon eine feinere Auflösung als Minuten haben, damit du ihn exakt zu einer bestimmten UTC-Zeit (plus/minus ein paar Zerquetschte) zum stehen bringst, wenn deine 'Volle Stunden Zeit' nicht UTC synchronisiert ist.
Koray schrieb: > eben drum. gibt es denn nicht zähler die schnell genug sind. Klar, in einem FPGA ... Mit soetwas sind die total gelangweilt! > Bei maximal 60 Zähnen wäre doch 6bit ausreichend. das hat ja nichts mit > den 25ns zu tun. Nur die Geschwindigkeit würde doch die 25ns > beeinflussen können. Schließlich meine ich mit den 6bit nur die anzahl > der Zähne die der Zähler drauf haben sollte. Überhaupt kein Problem ... Kannst auch einen einzelnen z.B. 32Bit Zähler in VHDL modelieren und am Ende des Zyklus den zählerstand durch 59 teilen und das Ergebnis für einen weiteren Zähler nehmen, der dann den Impuls bekommt, wenn die Zeit abgelaufen ist. Mit FPGAs bist du da definitiv auf der richtigen Seite!
2 probleme: Betreuung scheint mies zu sein. Die haben mMn selber keine vage Vorstellung und der Prof scheint ein richtiger Prof zu sein. Das erschwert es, denn wenn die Bertreuuer nicht halbwegs konkret mitdenken ist das eine Hausnummer... Schaffst du trotzdem nicht verzweifeln! Keine genau definierte Aufgabe: ich wette da gibt es kein richtiges Lastenheft ^^ Was ich an der PLL Lösung im Gegensatz zur Zeitmesslösung nicht verstehe ist folgendes. (und ich schreib das jetzt mal, denn so eine Diskussion hilft dem OP mit Sicherheit): Was genau wolltest du vorgeben? Eine feste HF und einen passenden Teiler für die aktuelle Drehzahl suchen? Kann doch eigentlich nicht klappen? Teiler == Zahnzahl in einer Umdrehung? Was meinst du mit Ausgang des Zählers nach Teilung? Es ist heiß hier.
Frage zum lastenheft muss ich das schreiben oder der auftraggeber (also die firma)
Nur so eine Idee: Die Mikrocontroller ADuC702x von Analog Devices arbeiten mit 48MHz Taktfrequenz, haben einen ARM-Core 32 bit und einen kleinen PLA-Teil (programable Logic Array) extra auf dem Chip. Im Datenblatt ist auch ein Beispiel für einen mit PLA realisierten "externen" Zähler angegeben. Den kann man ja noch mit (echten) externen schnellen ICs kombinieren, um dort die 1us Reaktionszeit und die 25ns Durchlaufzeit hinzubekommen (in Zusammenspiel mit dem ARM-Core). Wie das gehen könnte, das habe ich jetzt nicht durchgespielt. War nur so eine Idee. Blackbird
In der Theorie: der Auftraggeber In der Praxis: Du, mit ein wenig Hilfe vom Auftraggeber :-)
Hast du denn eigentlich schon mit irgendeinem uc was gemacht? Wenn, ja, dann würd ich versuchen eine Lösung da drum zu dengeln, denn neuen ARM, Problemlösung und das in 3 Monaten ist für mich echt zu haarig :-o Aber abklopfen schadet ja nicht. mfG
Karl heinz Buchegger schrieb: > In der Theorie: der Auftraggeber > > In der Praxis: Du, mit ein wenig Hilfe vom Auftraggeber :-) Ich habe ein Lastenheft geschrieben, was dem Auftraggeber in dem Moment eigentlich auch gepasst hat, aber da steht auch nicht mehr drin als hier. Ich würde gerne die ersten Seiten meiner DA hier zugänglich machen, aber hab irgendwie schiss davor, dass es dann irgendwie negative auswirkungen bezüglich der Firma auf mich hat.
Ich häng mal drei Oszi-Bilder an, vielleicht könnt ihr aus den Signale verstehen wie zumindest momentan mein Eingangssignal aussieht. Erst zur Schaltung. Ich hab das MAX9926 Bauteil mit Spannungsversorgung, Frequenzgenerator und Oszilloskop verbunden. Der Frequenzgenerator generiert 24kHz und 10Vp-p Bei den Oszilloskop-Bilder ist das gelbe Signal das Eingangssignal und das blaue mein Ausgangssignal. Das Bauteil generiert aus den Nulldurchgängen in der negativen Flanke einen Takt und somit ein TTL-Signal (0-5V) Das blaue Signal wird dann das, welches ich dann einspeichen wollte. Ich hab eigentlich somit dem µC oder FPGA was auch immer die Arbeit erspart den Nulldurchgang zu detektieren.
@Koray Am besten erarbeitet man ein Pflichtenheft gemeinsam. Es soll sicher stellen, das beide Seiten das gleiche meinen. Deshalb sollte es so präzise wie möglich sein. Es passiert sonst nämlich leicht, dass man etwas macht, was man für richtig hält, aber der Auftraggeber hat sich etwas ganz anderes vorgestellt. Christoph schrieb: > Was ich an der PLL Lösung im Gegensatz zur Zeitmesslösung nicht verstehe > ist folgendes. (und ich schreib das jetzt mal, denn so eine Diskussion > hilft dem OP mit Sicherheit): > Was genau wolltest du vorgeben? Eine feste HF und einen passenden Teiler > für die aktuelle Drehzahl suchen? Kann doch eigentlich nicht klappen? > Teiler == Zahnzahl in einer Umdrehung? Was meinst du mit Ausgang des > Zählers nach Teilung? Es ist heiß hier. Also, von dem Zahnrad bekomme ich eine Frequenz f geliefert. Ich habe einen Zähler, der während eines Impulses von 0 bis N zählt und via PLL mit den Zahnimpulsen synchronisiert wird. Immer wenn der Impuls vom Zahnrad seine Flanke hat, ist der Zähler wieder 0. Jeder Impuls vom Zahnrad wird also in N Impulse unterteilt, der Oszillator läuft demnach mit der Frequenz N * f. Die einzelnen Bits des Zählers gebe ich auf einen digitalen Vergleicher (TTL), dessen Vergleichswert vom µC geliefert wird. Während des Impulses, wo das Zahnrad seine Nullstellung erreicht, schaltet der µC den Vergleicher scharf und der gibt dann zum entsprechenden Zeitpunkt einen Impuls aus. Das Ganze läuft also in Hardware ab. Der µC hätte einen ganzen Zahn Zeit, die Werte auszugeben. Das ist nicht mehr sonderlich zeitkritisch. Die relative Auflösung ist 360°/Zahl_der_Zähne/N . Wie das mit den 25ns hinkommt, muss man schauen. Nach meiner Vermutung ist eher die relative Auflösung entscheidend, man will ja wohl einen Impuls bei einem ganz bestimmten Winkel.
Das ganze hört sich für mich nach einem Projekt an, wo die Projektanden nicht verstehen, was sie tun. Es gibt eine Reihe von Problemen: . Was nützt es, so schnell den Wert zu haben? Die Reaktionszeit wird ohnehin um Größenordnungen länger. . Das Signal ist selbst nicht annähernd gut genug für 25 ns Präzision. Auch das Zahnrad wird schwingen und ist nicht 100% rund und die Zähne nicht 100% gleichartig. Dazu kommt eine Rise Time von 1 us am Trigger. Da ist die Zeit schon rum, bis das Signal erstmal registriert wird! . PLL fällt doch eigentlih raus, da die erst nach mehreren Zyklen auf Veränderungen reagiert. Wo sollen da 25 ns Präzision herkommen? Was ich machen würde, nur um die Aufgabenstellung an sich zu erfüllen, auch wenn es ohnehin komplett sinnfrei ist: Mikrocontroller, der die Zahnzahl gesagt bekommt, und sie an einem 8/16 bit Port ausgibt. Permanent. Ein CMOS/TTL-Binärzähler Chip, oder besser mehrere, je nach Zahnzahl und ein AND-Gatter, das die Ausgänge der Zähler mit den Mikrocontroller Ausgängen vergleicht. Wenn alle stimmen wird der Ausgangspuls generiert, der auch den Zähler rücksetzt. Aber wie gesagt, die Baustellen von wegen Präzision und Auflösung, die sind wo anders, wenn man sich das Signal anschaut.
Nur mal so nebenbei: Ein Meter Kabel hat schon 5 ns delay! Ebenfalls der Sensor etc...
Mike Strangelove schrieb: > Nur mal so nebenbei: Ein Meter Kabel hat schon 5 ns delay! Echt jetzt? Wie ermittelt man das? Ok, Faustregel 5nH/cm aber die Kapazität?
Mike Strangelove schrieb: > PLL fällt doch eigentlih raus, da die erst nach mehreren Zyklen auf > Veränderungen reagiert. Wo sollen da 25 ns Präzision herkommen? Oder gerade nicht. Gerade weil ein PLL nicht so schnell reagiert, stört es weniger wenn ein Zahn ein etwas früheren und ein Zahn ein etwas späteren Impuls liefert. Das mittelt sich (teilweise) weg. Der Ausgang des PLL wäre dann ein idealisiertes Signal, das in diesem Punkt besser ist als das Eingangssignal. Das Ganze setzt natürlich voraus, dass die Turbine insgesamt eine entsprechend konstante Drehzahl hat. Wenn sie eiert, die Schaufeln sich verbiegen, was das Trägheitsmoment und damit auch die Drehzahl beeinflusst, oder durch externe Faktoren die Last sich verändert, dann ist einfach Schluss. Es sei denn, man findet eine Kristallkugel mit Digitalschnittstelle. :-)
Detlev T. schrieb: > Das Ganze setzt natürlich voraus, dass die Turbine insgesamt eine > entsprechend konstante Drehzahl hat. Wenn sie eiert, die Schaufeln sich > verbiegen, was das Trägheitsmoment und damit auch die Drehzahl > beeinflusst, oder durch externe Faktoren die Last sich verändert, dann > ist einfach Schluss. Das mit der konstanten Drehzahl kann ich leider nícht bestätigen. Es sind zwar keine Änderungen innerhalb weniger µs aber man sollte davon ausgehen, dass das Triebwerk beschleunigt und auch abbremst. Ich gehe davon aus, dass wenn man eine Umdr. mittelt es nicht zu drastischen Fehlern führt. Wobei ich mich aber bisjetzt zurückgehalten habe ist, was ist wenn das Zeitfenster zu klein oder die Berechnungen nicht ausreichen, wenn sich die Drehzahl erhöht, dann wird das System doch im Zeitfenster ein falsches Zahn "detektieren" Aber darüber muss ich mich noch informieren.
bwl bernd schrieb: > Mike Strangelove schrieb: >> Nur mal so nebenbei: Ein Meter Kabel hat schon 5 ns delay! > > Echt jetzt? Wie ermittelt man das? Ok, Faustregel 5nH/cm aber die > Kapazität? Wenn man annimmt, dass das Signal 200.000 km/s im Kabel zurücklegt, dann ergibt sich aus einem Meter Signalstrecke eben eine Verzögerung von 5 Nanosekunden.
Ich hätte noch einen anderen Ansatz: Einerseits das Eingangssignal im Controller zählen und das Ausgangssignal "hart" (mit Gatter) aus Eingangssignal logisch UND verknüpft mit einem Controller Output bilden. Der Controller zählt dann die 1->0 Flanken. Nach der 59. Flanke wird bis zur 60. Flanke der Ausgang auf 1 gesetzt und der Zähler geresettet. Somit wird der 60. Impuls nur durch die Laufzeit des externen Gatters verzögert. Jörg
Hi an deiner stelle würde ich mich mal mit denn TDC-XXX der Firma acam (www.acam.de) auseinander setzten, diese Scheinen für deine Diplomarbeit gut geeignet zu sein. Denn das tolle an denn Dingern ist das sie sehr exat Laufzeiten messen können. Ist etwas her das ich die Dinger das letzte mal in denn Fingern hatte aber wenn ich mich recht entsinne was einer der Vorteile von denn Chips das sie sich über SPI Unterhalten und das sie Dieses Asynchron zur Messung hin bekommen, sogar wärend sie weiter messen. Ich dneke so ein Teil kann dir denn Schweren teil der Aufgabe abnehmen, ggf. Brauchst du nun noch ein Mikrocontroller der die Daten des TDC ein wenig aufhüpscht und denn anderen Teilnehmern zur Verfügung stellt. Schwer wird es bei dnen teilen nur das sie ziemlich klein sind ( TDC-GP2 zum beispiel), und somit schwer in Prototypen zu verbauen. klär also deine möglichkeiten vorher ab diese in eine Schaltung einzubauen. Löt offen ist hier echt eine schöne Sache), beim von Hand löten muss man gutes Werkzeug und viel Erfahrung mitbringen.
Koray schrieb: > Das mit der konstanten Drehzahl kann ich leider nícht bestätigen. Es > sind zwar keine Änderungen innerhalb weniger µs aber man sollte davon > ausgehen, dass das Triebwerk beschleunigt und auch abbremst. Rechnen wir einmal ein bisschen. Bei 30.000 U/min haben wir eine Umdrehung in 2ms, oder? 25ns sind 1/80.000 davon. Die Geschwindigkeit der Turbine darf also während einer Umdrehung nicht mehr als um 0.00125% (oder 12.5ppm) schwanken, sonst kannst du die Bedingung mit den 25ns nicht einhalten. Ich kenne mich im Turbinenbau nicht aus, aber das ist ja immer noch etwas mechanisches. Ich kann mir nicht vorstellen, dass etwas so gleichmäßig laufen kann. Möglicherweise ist diese Aufgabe gar nicht lösbar, schon einmal daran gedacht?
Ich würds einfach mal naiverweise mit nem AVR austesten: Signal an externen Takteingang eines timers, output compare auf einstellen für 1 umdrehung, eventuell direkt nen PWM-Pin fürs Ausgangssignal nehmen (setzen bei compare, löschen n paar takte später), nebenbei ctc und die Timerhardware erledigt das alles schon mal von selbst. :-)
Koray schrieb: > Die Sensorik ist eignetlich simpel. Aus einem ferromagnetischem Zahnrad > wird durch einem induktiven Sensor das Signal erzeugt. Welche Genauigkeit hat eigentlich der Sensor? Stichwort Jitter. Wenn ich was von simpler Sensorik lese, habe ich so meine Probleme. Ein Sensor ist entweder simpel oder genau. Je höher die Genauigkeit, desto höher die Anforderungen an den Sensor. Und wie genau ist der Sensor, welcher den Versatz der Schaufeln ermittelt. Bei angenommenen 50 Schaufeln (eher mehr) und 20000Upm sind es 1Mio. Impuls/Sek, die ausgewertet werden müssen. Außerdem sollte die Anzahl der Schaufeln mit der Anzahl der Zahnradzähne übereinstimmen, sonst gibt es da noch mehr Rechenaufwand und das Ergebnis wird ungenau, weil dnicht zu jedem Impuls von Zahnrad eine Schaufel gegenübersteht. Deshalb ist auch die Variante mit dem einen Zahn nicht machbar. Welche Turbine hat nur eine Schaufel? Das ist nichts für einen uC. Mir fällt aber auch keine andere Lösung ein.
Mike Strangelove schrieb: > . Das Signal ist selbst nicht annähernd gut genug für 25 ns Präzision. > Auch das Zahnrad wird schwingen und ist nicht 100% rund und die Zähne > nicht 100% gleichartig. Dazu kommt eine Rise Time von 1 us am Trigger. > Da ist die Zeit schon rum, bis das Signal erstmal registriert wird! Absolut, Schau dir dein Oszillogramm doch mal mit 25ns/div an. Da sieht das "Rechteck" Signal aus wie ne Rampe ;-).
Nur zum Verständnis: Du misst die Drehzahl eines Zahnrades mit 60 Zähnen. Bekommst bei jedem Zahn einen Impuls und hast bei Maximaldrehzahl ein Messsignal mit einer Frequenz von 24kHz!? Also dauert folglich eine Umdrehung( = 360° )
Du brauchst den Nulldurchgang - also die Zahnradposition - auf 25ns genau? Also umgerechnet auf
genau ??? > Ich kenne mich im Turbinenbau nicht aus, aber das ist ja immer noch > etwas mechanisches. Ich kann mir nicht vorstellen, dass etwas so > gleichmäßig laufen kann. Möglicherweise ist diese Aufgabe gar nicht > lösbar, schon einmal daran gedacht? Da stimme ich Dir zu! Zu lösen ist es sicher irgendwie, die Frage ist nur, wieviel Geld ausgegeben werden darf. Mit einem pummeligen µC wirst Du da sicher nicht weiter kommen.
Simon K. schrieb: > Absolut, Schau dir dein Oszillogramm doch mal mit 25ns/div an. Da sieht > das "Rechteck" Signal aus wie ne Rampe ;-). Hast recht, aber ich könnte doch einen Trigger setzen. Wenn man sich das SIgnal anschaut, kann man ja sehen, dass es ziemlich gut auf Null bleibt bis der Nulldurchgang kommt. Ich könnte einen Trigger auf 0,1 Volt setzen also bräuchte ich nicht bis zur Sättigung warten. >> Ich kenne mich im Turbinenbau nicht aus, aber das ist ja immer noch >> etwas mechanisches. Ich kann mir nicht vorstellen, dass etwas so >> gleichmäßig laufen kann. Möglicherweise ist diese Aufgabe gar nicht >> lösbar, schon einmal daran gedacht? nicht nur einmal, aber hab ständig Vorschläge bekommen wie es klappen könnte. Als ich das dann schließlich meinen Betreuern sagte, meinten die, dass es wenigstens in die Richtung von 25ns gehen könnte sollte. Die haben Messsysteme speziell für einzelne Zahnräder konzipiert die eine Genauigkeit von 250ns einhalten kann. Ist halt alles analog. Ich muss sagen, ich hab schon oft nach den Schaltungen dieser Lösungen gefragt, welche mir dann zugesichert wurden, aber bisjetzt kam nichts. Ich habs auch irgendwie satt den Leuten ständig auf die Pelle zu gehen, wobei ich das machen müsste, aber es bringt mir nichts, hab ich mittlerweile herausgefunden.
Wieso ein mcu? nimm einen cpld der ist wohl für solche aufgaben wohl am besten gegeignet.
Mach eine Sprechstunde mit deinem betreuenden Prof und schildere ihm deine Probleme. So, denke ich, wird das hier nichts!
Koray schrieb: > Als ich das dann schließlich meinen Betreuern sagte, meinten > die, dass es wenigstens in die Richtung von 25ns gehen könnte sollte. So viel zu "klare Vorgaben". :-( Das ist doch Murks. > Die haben Messsysteme speziell für einzelne Zahnräder konzipiert die > eine Genauigkeit von 250ns einhalten kann. Ist halt alles analog. Das heißt nichts. Analog ist oft leistungsfähiger als digital. Faktor 10 ist der Unterschied zwischen Klappfahrrad und Formel-1-Auto. Und wenn die dich so lange auflaufen lassen, bis du aufgibst, dann hat da auch keiner Interesse an deiner Arbeit und dass du Erfolg hast. Da sollten alle Warnlampen angehen! Lass dich nicht verheizen! Hans Dampf hat vollkommen recht, da ist ein klärendes Gespräch mit deinem Prof angesagt.
Koray schrieb: > Simon K. schrieb: >> Absolut, Schau dir dein Oszillogramm doch mal mit 25ns/div an. Da sieht >> das "Rechteck" Signal aus wie ne Rampe ;-). > > Hast recht, aber ich könnte doch einen Trigger setzen. Wenn man sich das > SIgnal anschaut, kann man ja sehen, dass es ziemlich gut auf Null bleibt > bis der Nulldurchgang kommt. Ich könnte einen Trigger auf 0,1 Volt > setzen also bräuchte ich nicht bis zur Sättigung warten. Und dann? So verrauscht wie das ist hast du da immer noch Jitter drin. Mal abgesehen von Störungen, da 0,1V doch eine sehr niedrige Schwelle ist. Wie verdammt wenig 25ns zu 2,5ms sind, wurde ja oben schon angedeutet.
Mike Strangelove schrieb: > . Was nützt es, so schnell den Wert zu haben? Die Reaktionszeit wird > ohnehin um Größenordnungen länger. Die Messung von Koray ist ja ein Teil von einem Gesamtsystem und da ist es unter Umständen gut wenn dieser Teil nicht die gesamte Reaktionszeit und Gesamtmessungenauigkeit "verbraucht". > . Das Signal ist selbst nicht annähernd gut genug für 25 ns Präzision. > Auch das Zahnrad wird schwingen und ist nicht 100% rund und die Zähne > nicht 100% gleichartig. Dazu kommt eine Rise Time von 1 us am Trigger. > Da ist die Zeit schon rum, bis das Signal erstmal registriert wird! Was spielt denn die Abweichung von einem Teil des Gesamtmesssystems für seinen Teil der Messung für eine Rolle. Wenn natürlich die mech. Genauigkeit der Zahnräder in der Verantwortung von Koray und auch innerhalb der 25nS liegen hast Du Recht. Die Zähne müssen übrigens nicht gleich sein da ja am Ende nur der Zahn Null zählt ;-) Am Schluss noch eine Frage: Was ist an Joerg Wolframs Lösung im Posting Beitrag "Re: µC Wahl für meine Dipmlomarbeit" so verkehrt, dass niemand darauf eingeht? Hier ist die max. Messzeit (1µS?) Messzeit/Signalverzögerung vom MAX9926 + 1x Gatterlaufzeit und eine max. Ungenauigkeit (25nS?) Ungenauigkeit vom MAX9926 + max. Schwankung in der Gatterlaufzeit. Jeweils plus die Werte des Sensors wenn Bestandteil, plus die Werte von den Zahnrädern wenn Bestandteil (siehe etwas weiter oben.) frank
frank schrieb: > Am Schluss noch eine Frage: Was ist an Joerg Wolframs Lösung im Posting > Beitrag "Re: µC Wahl für meine Dipmlomarbeit" so verkehrt, dass > niemand darauf eingeht? Hier ist die max. Messzeit (1µS?) > Messzeit/Signalverzögerung vom MAX9926 + 1x Gatterlaufzeit und eine max. > Ungenauigkeit (25nS?) Ungenauigkeit vom MAX9926 + max. Schwankung in der > Gatterlaufzeit. > Jeweils plus die Werte des Sensors wenn Bestandteil, plus die Werte von > den Zahnrädern wenn Bestandteil (siehe etwas weiter oben.) > frank Genau in der Form hatte ich mir das auch vorgestellt als er das vorgeschlagen hat. Ich hatte das in meinem Beitrag auch erwähnt, das mit Zähler der 6bit zählt, wäre das denn nicht eine Variante. Die Frage ist halt der Zähle muss schnell sein. frank schrieb: > Wenn natürlich die mech. > Genauigkeit der Zahnräder in der Verantwortung von Koray und auch > innerhalb der 25nS liegen hast Du Recht Nein die Verantwortung liegt nicht bei mir. Das was der Sensor bringt ist meine Ausgangslage, da kann und soll ich nichts ändern.
Wenn die Lösung von Jörg prinzipiell richtig ist, bzw. ich das Problem richtig verstanden habe und Max + Gatter erfüllen die 25nS und die 1µS, muss der Zähler doch nur 30kHz (60 Zähne x 30.000 U/min) zählen können. Die "25nS-genaue" Phasenlage kommt ja vom Max+Gatter am Ausgang. Welcher MC, bei wie viel Taktfrequenz, wie schnell zählen und vergleichen kann, wissen hier die Profis besser als ich. Grob über den Daumen (16MHz / 30kHz = 533 Instruktionen zwischen den Ereignissen) kann das fast jeder 8-Bitter und nebenher noch das Interface zur Zahnradauswahl etc. frank
ich finde 25 nSek ganz schön sportlich, gerade mit dem induktiven Aufnehmer. Ich würde das ganze optisch abtasten. Ansonsten fällt mir noch ein Baustein ein, der speziell für solche Induktive Sachen (Automotive Bereich) entwickelt wurde, vielleicht verbessert der deine Schmitt-Trigger Schaltung. Hab das Datenblatt mal angehängt. Angenommen ihr lasst euch ein Zahnrad mit 180 Zähnen also 360 Impulse fertigen. 1 Umdrehung bei 24kU/Min = 2,5 msek / 360 Impulse wären = 6,9 µSek/1° Wie willst du jetzt innerhalb von 1 µSek die Drehzahl feststellen? Wenn du nur alle 6,9 µSek einen Impuls bekommst. Und was bringt es dann wenn du diesen Wert dann nur alle 2,5 mSek übermittelst?
So wie ich das verstanden habe soll er doch am Aufbau der Messschaltung nichts verändern. Von daher würd ich mal sagen das das mit den 25ns eher schlecht aussieht. Koray schrieb: > Die haben Messsysteme speziell für einzelne Zahnräder konzipiert die > eine Genauigkeit von 250ns einhalten kann. Vor allem wundert es mich wenn Messsysteme auf die Zahnräder angepasst wurden mit 250ns Genauigkeit arbeiten und du sollst nun eins für alle entwickeln welches 25ns Genauigkeit bietet. Da du ja auch Zeitprobleme zu haben scheinst würd ich das ganze mal mit einem AVR o.ä. aufbauen und schauen wie genau du damit wirst. In der Diplomarbeit kannst du dann ja auch darauf hinweisen bzw. einen Ausblick geben wie eine genauere Lösung aussieht. Das hört sich jetzt alles nicht so an als wenn du während der Arbeit groß Unterstützung von deinen Betreuern bekommst.
Hallo Frederik, als erstes müsste man wohl den Jitter des Eingangssignal bestimmen. (http://de.wikipedia.org/wiki/Jitter). Was da an Murks ankommt, kann man auch nicht mehr "heraus rechnen". Auch wenn Koray sagt, dass das nicht in seinen Verantwortungsbereich fällt: Wenn seine Schaltung nicht funktioniert, ist er der Dumme.
Joa klar, ob der Jitter dann aber an jedem Zahnrad gleich ist bezweifle ich auch mal dafür wird die Kombination Sensor/Zahnrad wahrscheinlich alleine schon zu großen Schwankungen ausgesetzt sein. Klar fällt das in seinen Verantwortungsbereich aber wenn er am bestehenden System nix verändern kann/darf muss er ja erstmal mit dem arbeiten was er hat...
Interessante Sache... Da ist sicher auch ein wenig CYA angesagt. (Cover Your Ass) Also sind Gespräche mit dem Prof. wohl unerlässlich, damit er frühzeitig ein Verständnis für die Probleme entwickelt. Der Sinn einer Diplomarbeit ist ja zu zeigen, dass man mit Material und Theorie klarkommt. Wenn er also etwas aufbaut, was im Prinzip das Richtige tut, wenn die Berechnungen und die Strategie stimmen, dann sollte das für ein "Bestanden" ausreichen. Wenn er dann noch zeigen kann, warum die Aufgabe unlösbar ist oder falsch gestellt wurde, nun ja, dann hat er eben alles getan, was möglich ist. Ähnliches gilt wohl, wenn sein Aufbau exakt der Aufgabenstellung folgt, genau verstanden und berechnet wurde, aber das Ergebnis nicht verwertbar ist (z.B. wegen Jitter, schwingender Zahnräder, unkonstanter Umdrehungsgeschwindigkeit, nichtidealer Zahnräder usw.), und er dann zeigen kann, warum nicht. Mit geeigneten Messreihen usw. Ich könnte mir vorstellen, dass ein Aufbau sinnvoll ist, der erstmal das jeweilige Zahnrad genau ausmisst. Z.B. mit einem schnellen, freilaufenden Zähler, der bei jedem Signaldurchgang gelatcht und das Latch-Ergebnis vom µC in ein Array eingelesen wird. Zwischen den Zähnen hat man dann immer ein wenig Zeit zum Rechnen (Mittelwerte, Zeitpunkt usw.). Wenn der Referenzpunkt des Zahnrads darin besteht, dass ein Zahn fehlt, braucht man die Zahnzahl gar nicht eingebbar machen, weil der µC das dann sofort selbst feststellen kann. Wenn man ein paar Umdrehungen gezählt hat, weiß der AVR dann, wieviele Zähne das Teil hat, wie stark der Zahnjitter ist (der "kennt dann ganz genau sein Zahnrad), wie groß die Variabilität der Umdrehungen ist, die Umdrehungsgeschwindigkeit sowieso, usw. Nach dem, was hier gesagt wurde, würde ich wohl mit so einem Aufbau beginnen, um dann Messreihen für die Systeme zu machen. An den Zählerwerten kann man dann Statistiken rumrechnen, um festzustellen, ob und wie genau die Aufgabe gelöst werden kann. An diesem Punkt ist schon ein großer Teil der Diplomarbeit fertig, denn wenn man das alle beschrieben hat, wird jeder sehen können, wie man mit so einem Thema umgeht. Außerdem kommen einem dann wohl auch noch ein paar Ideen. Um den Synchronisationsimpuls zu erzeugen, kann man dann einen weiteren Rückwärtszähler rechtzeitig mit dem Abstandswert laden, der dann, freigegeben durch dem µC, nach dem letzten Zahnimpuls, und durch diesen getriggert, dann genau so weit runterzählt, bis der theoretische Mittelimpuls des fehlenden Zahns erreicht ist, und dann den Impuls erzeugt. Der µC kann bei der Berechnung dieses Zählerwerts einen Geschwindigkeitstrend berücksichtigen, also bei einer während der letzten Zähne festgestellte Beschleunigung/Verzögerung den Wert entsprechend korrigieren.
> wird jeder sehen können, wie man mit so einem Thema umgeht. Ja, das ist m.E. hier der Knackpunkt. Zuerst sollten verschiedene Lösungsansätze analysiert und bewertet werden. Und wenn es einen klaren Sieger gibt, kann der realisiert werden. Wenn nicht, dann können Verfahren nach weiteren Aspekten klassifiziert und dargestellt werden. Aber abgesehen von ein paar Messungen und einem Schmitt-Trigger-Aufbau scheint mir das hier noch recht unausgegoren. Hier werden irgendwelche Bausteine mit irgendwelche Quellen verbunden, ohne zu wissen, was eigentlich herauskommen soll (so sehe ich das, wenn Zeiten von 25ns aufgeführt werden und ein MAX9926 mit einem Gain-Bandwidth Product GBW von 1.4 MHz als Messverstärker herhalten soll. siehe Beitrag "Re: µC Wahl für meine Dipmlomarbeit") @ Koray >>>>> Die Diplomarbeit klang sehr interessant, Das ist schon mal gut. >>>>> und die Anforderungen wurden mir am Anfang gar nicht gesagt, Und du hast nicht gefragt? War dir das alles schon klar? Warum gibt es dann jetzt solche Probleme? Mein Tipp: sieh zu, dass du die Arbeit so schnell wie möglich in die Theorie-Schiene (Machbarkeitsstudie) auslenken kannst. Dazu ein paar Testaufbauten mit Sensoren+Verstärkern, und fertig. Mehr schaffst du nicht.
> nach dem letzten Zahnimpuls, und durch diesen getriggert,
Wenn man das so macht, hängt die Genauigkeit davon ob, wie genau ein
einzelner, und zwar exakt der letzte, Zahnimpuls ist.
Man kann die Genauigkeit aber verbessern, indem man Mittelungen der
Zahnimpulse nutzt. Dann kann man allerdings nicht den Rückwärtszähler im
Vorfeld des letzten Zahnimpulses laden, weil dessen genauer
Ankunftszeitpunkt ja nicht bekannt ist.
Dies Problem lässt sich aber umgehen, indem man einen ausreichend
vielbittigen Komparator für den freilaufenden Zähler einsetzt. Den kann
man dann sogar noch nach dem letzten Zahnimpuls laden und dann auch
"irgendwann rechtzeitig" freigeben.
Der Grundgedanke meines Vorschlags ist, dass alles, was Genauigkeit
erfordert, komplett im externen Zählaufbau realisiert wird und dieser
gleichzeitig möglichst einfach bleibt.
So wird die Arbeit des µC genauigkeitsunkritisch, der kriegt pro Zahn
den Zählerstand (benachrichtigt z.B. über einen IRQ o.ä.), braucht dann
nur noch ein wenig rechnen, hat für alles genug Zeit, und der Diplomand
kann seine guten Digitalkenntnisse gut einsetzen. Ein freilaufender
Zähler, ein Latch, ein Comparator, ein durch den (am besten synchron,
wg. evtl. Comparatorglitches) getriggerter Impulserzeuger (Monoflop...)
und ein bissel Logik dürfte da ja nicht das Problem sein.
Auf diese Weise erscheint mir diese Aufgabe lösbar und sogar relativ
einfach. Die Firma erhält dann eine Genauigkeit, die dem Machbaren
entspricht und relativ exakt von der Genauigkeit ihrer Impulse abhängt,
wobei die Mittelungen die Genauigkeit freundlicherweise noch verbessern.
Einarbeiten muss der Diplomand sich dann allerdings ein wenig in die
Rechnerei auf dem µC. Sollte vermutlich aber schaffbar sein. Es geht ja
letztlich nur um die Grundrechenarten in digitaler Form und über mehrere
Bytes. Keine wirklich Hürde, vermute ich.
Viel Erfolg!
Ich hab mal eine blöde Frage: Wenn man von einem sich drehenden Rad (Scheibe) eine bestimmte Position feststellen will, dann ist die wohl einfachste Lösung die, da ein Loch durchzubohren und eine Lichtschranke anzubringen. Im Zeitalter des CNC ist es auch nicht weiter schwierig, das Loch auf den tausendstel Millimeter genau an immer der gleichen Stelle anzubringen. Wäre das nicht wesentlich einfacher, als im Nachhinein aus verrauschten Sensorsignalen den exakten 0-Punkt der Scheibe festzustellen. OK. Das Zahnrad wird jetzt sicherlich in einem Kasten drinnen sein, in dem es mit Öl geschmiert wird. Aber es wird irgendwo eine Abtriebswelle geben an das man entweder eine zusätzliche Scheibe mit einem Loch anbringen kann oder überhaupt in die Welle eine Markierung einlassen kann, die mit einer Reflexlichtschranke ausgewertet wird. Ist das zu naiv gedacht? Zu einfach? Zu wenig Herausforderung? Zu billig in der Realisierung?
@Koray: Nachdem hier soviel geschrieben wurde, bin ich mir nicht mehr sicher, was wirklich gemachht werden soll. Willst du wirklich die Umdrehungszahl messen, durch die Zeit, die ein einziger Zahn des Zahnrades braucht, um deine Lichtschranke zu passieren? Falls ja: Hier mal ein paar Gedanken für dein Gespräch: "Können sie die Zähne der Zahnräder auf 1/80000 genau fräsen?" "Wärmeausdehnung führt zu großen Toleranzen" "Verschleiß führt hier zu erheblichen Ungenauigkeiten"
bei der hohen Impulszahl ist die Beschleunigung/Verzögerung ziemlich gering, denke nicht das man das da braucht. Ich habe das mal gemacht weil ich auf einem Kurbelwellenrad nur 4 Impulse pro Umdrehung hatte und da gabs dann beim Beschleunigen bzw. Anblitzen wärend des hochdrehens schon einige Abweichungen. Habe dann einfach eine Differenz aus vorheriger und aktueller Messung gebildet und teilweise in die nächste Berechnung mit reingenommen. Den Codeschnipsel .asm kann ich zur Verfügung stellen falls es interessiert. Aber mit der induktiven Geschichte kann ich mich eh nicht anfreunden, ich habe einen Hallsensor mit integrierten Schmitt-trigger genommen, da hab ich mir schonmal die ganze Abstimmung gespart. In diesem Fall würde ich es aber optisch machen, notfalls kann man das Zahnrad ja um einen halben Zacken verdrehen und dann liegt eine Flanke genau in der vorherigen Mitte und die Verzögerung ist immer gleich so das man diese aus dem Timerwert raus rechnen kann. Bei der Induktivgeschichte ist ja die Signalhöhe schon drehzahlabhängig.
Lothar Miller schrieb: > @ Koray >>>>>> Die Diplomarbeit klang sehr interessant, > Das ist schon mal gut. >>>>>> und die Anforderungen wurden mir am Anfang gar nicht gesagt, > Und du hast nicht gefragt? War dir das alles schon klar? Warum gibt es > dann jetzt solche Probleme? Weil jedesmal wenn ich ein Lösungsvorschlag abgegeben hatte, ständig neue Anforderungen gestellt wurden von denen ich vorher nichts wusste. Das mit den 25ns hab ich erst viel später erfahren, auch dass das System "echtzeitfähig" sein soll und die daten nicht gespeichert werden sollen. Zu Anfang hatte ich eine Aufgaben Beschreibung von der Firma bekommen. Und daraus kann man sich eigentlich viele Aufgaben ableiten. Es hieß dies ist die ausführliche Beschreibung der Aufgabenstellung: >In der Messtechnik werden für eine Vielzahl von Messmethoden präzise >Drehzahlsignale benötigt. Diese werden bei Entwicklungstriebwerken in der >Regel mittels gesonderter Drehzahlsensoren (1/ ref) erzeugt. > >Serientriebwerke verfügen überwiegend nicht über diese sogenannten 1/ ref >Sensoren. Um dieses Manko auszugleichen ist es theoretisch möglich aus >den Standard Produktionssensoren 1/ ref Signale zu erzeugen. Da bei den >verschiedenen Triebwerkstypen unterschiedlich Drehzahlmesseinrichtungen >verbaut sind, soll eine möglichst Umfassende Lösung gefunden werden. > >Der Schwerpunkt der zu erstellenden Arbeit soll in der Simulation und der >Realisierung einer Schaltung liegen die für verschiedene Triebwerkstypen >eingesetzt werden kann. Da ist zu berücksichtigen das es sich sowohl um >Entwicklungs- als auch um Serientriebwerke handeln kann. Es ist besonders >darauf zu achten das die elektrische Schnittstelle keine Rückwirkung auf >das Triebwerksregelsystem bzw. seine Komponenten hat. > >Nach der Realisierung der Schaltung sind Tests an den verschiedenen >Triebwerkstypen durchzuführen und zu Dokumentieren. Gegebenfalls sind >Adapter zu konstruieren um einen parallelen Betrieb von >Triebwerksmesstechnik und Konditionierungssystem zu ermöglichen.
Karl heinz Buchegger schrieb: > Ist das zu naiv gedacht? > Zu einfach? > Zu wenig Herausforderung? > Zu billig in der Realisierung? Nicht Thema der Arbeit? ;-)
Auch ein einzelnes Loch erzeugt Jitter. Was ändert das? Viele Zähne haben den Vorteil, innerhalb einer Umdrehung Beschleunigung messen zu können, weil eben die Impulsanzahl -- bei gleicher Umdrehungszahl -- viel höher ist. Aber da es anscheinend auch Ein-Zahn-Zahnräder gibt, überschneiden sich die Fälle sowieso. Der Vorteil mit dem externen freilaufenden Zähler (der für 25 ns nur 40 MHz braucht) mit einem Comparator für die Impulserzeugung beim Wunschzählerstand ist, dass man das Synchronsignal auf jeden beliebigen Rotationswinkel legen kann. Außerdem ist die Anforderung an die Langzeitstabilität des Oszillators nicht sehr hoch, da man die Werte bei jeder Umdrehung neu anpassen kann, die Zeit kürzt sich gewissermaßen raus, weil man letztlich nur mit Strecken- (bzw. Winkel-)verhältnissen rechnet.
Thomas O. schrieb: > In diesem Fall würde ich es aber optisch machen, notfalls kann man das > Zahnrad ja um einen halben Zacken verdrehen und dann liegt eine Flanke > genau in der vorherigen Mitte und die Verzögerung ist immer gleich so > das man diese aus dem Timerwert raus rechnen kann. Es geht um Triebwerke die mittlerweile schon fliegen, d.h. sie sind so akzeptiert und durchgesetzt worden, da kann ich an den Sensoren nichts ändern, ich muss damit leben/zurechtkommen was ich von den Sensoren bekomme. Ansonsten wäre meine Diplomarbeit ja auch unsinnig, falls jedes Zahnrad einen 1/rev Zahn hat. Dann brauchen die ja das messen. Haben sie aber nicht, an dieser Stelle soll ich ins Spiel kommen. Mit dem Loch im Zahnrad und dann optisch abtasten ist natürlich kein Problem, aber wenn das Triebwerk schon in der Produktion ist, kann man da nichts mehr ändern. Zumindest werden die nichts am Zahnrad und dem Sensor ändern. Meine Aufgabe ist es aus dem Signal was brauchbares zu machen, siehe unverständlicherweise Aufgabenbeschreibung der Firma.
@Koray Das liest sich ja ganz anders. Da solltest du dich in deinem Gespräch mit dem Prof. darauf berufen und ihm ein eigenes Konzept für deine Arbeit präsentieren. Aus meiner Sicht könnte das so aussehen: 1.) Erfassen, welche verschiedenen Signaltypen es gibt 2.) Konzepte entwickeln, diese Signale zu systematisieren und digital verarbeitbar zu machen 3.) Aufbau einer entsprechenden Referenzschaltung 4.) Testen deren Eigenschaften, Quantifizierung der Leistung. 5.) Identifizierung und Diskussion möglicher Schwachstellen/Verbesserungsmöglichkeiten intern/extern (z.B. auch Qualität des Eingangssignals) Das wäre etwas, wie ich mir eine Diplomarbeit vorstellen könnte. Auf Vorgaben wie "25ns" sollte man sich gar nicht erst einlassen. Man entwirft ein Konzept und stellt deren Leistungsfähigkeit fest.
Blöd ist, dass du etwas messen mußt, das gar nicht da ist... Kannst du nicht (wie bei DCF77) den ersten Zahn/Impuls nach der Lücke als Referenzzahn definieren?
Detlev T. schrieb: > Das wäre etwas, wie ich mir eine Diplomarbeit vorstellen könnte. Auf > Vorgaben wie "25ns" sollte man sich gar nicht erst einlassen. Man > entwirft ein Konzept und stellt deren Leistungsfähigkeit fest. Ja aber dann hat doch die Firma nichts davon. Abgesehen davon geht es sowieso in erster Linie um mein Studium und mein Abschluss, aber was bringt denen das, und was wenn die Firma die Arbeit als nicht bestanden an den Prof weitergibt. Der muss sich ja in gewisser Weise mit der Firma absprechen und dann die Note vergeben. Auch wenn er nicht müsste, würde er sich beeinflußen lassen. Die Diplomarbeit sollte eigentlich mein Vorzeigeprodukt sein, und wenn ich da mit ner knappen 4 einfach nur bestehen sollte, womit soll ich mich dann bei den Firmen für einen Job bewerben?
Lothar Miller schrieb: > Blöd ist, dass du etwas messen mußt, das gar nicht da ist... > Kannst du nicht (wie bei DCF77) den ersten Zahn/Impuls nach der Lücke > als Referenzzahn definieren? Ich hab mit ach und Krach zwei Signale bekommen, einmal ein Zahnrad mit 43 Zähnen und der eine ist kürzer. Einmal ein Signal wo die Zahnanzahl unbekannt ist und kein Referenzzahn.
Koray schrieb: > Ja aber dann hat doch die Firma nichts davon. Abgesehen davon geht es > sowieso in erster Linie um mein Studium und mein Abschluss, aber was > bringt denen das, und was wenn die Firma die Arbeit als nicht bestanden > an den Prof weitergibt. Der muss sich ja in gewisser Weise mit der Firma > absprechen und dann die Note vergeben. Auch wenn er nicht müsste, würde > er sich beeinflußen lassen. Was studierst du eigentlich? Gehts nur mir so, oder haben auch andere das Gefühl, dass dieser Job ein Himmelfahrtskommando ist, bei dem selbst die Leute in der dortigen Firma nicht recht wissen, wie sie es lösen sollen/könnten?
Liest hier keine meine Beiträge? Meiner Meinung nach ist das eine gut machbare Lösung. Warum dann noch über die angebliche Undurchführbarkeit reden, wenn man es auch einfach machen könnte? Mit der Hardware kann man das Machbare auch erreichen, es ist nicht kompliziert, sie ist sogar flexibel genug, um an verschiedene Bedingungen und sogar zusätzliche Wünsche an das Ausgangssignal angepasst werden zu können, und als Bonus könnte sie sogar die Zahnraddaten ausgeben und sogar Veränderungen desselben feststellen. Man könnte evtl. sogar die Schaufelsensoren mit einbeziehen (wenn deren -- angenommene -- Vorbeiflug-Induktionssensoren eigene Latches an dem Zähler triggern) und direkt deren Veränderungen messen...
> Genau in der Form hatte ich mir das auch vorgestellt als er das > vorgeschlagen hat. Ich hatte das in meinem Beitrag auch erwähnt, das mit > Zähler der 6bit zählt, wäre das denn nicht eine Variante. Die Frage ist > halt der Zähle muss schnell sein. Wie schon gemeint ... Am saubersten und am deterministischsten wird es mit einem FPGA/CPLD gehen ... Damit bist du dann sehr schnell (>100MHz möglich, 100MHz ohne Probleme möglich) und hast ein absolt perfektes Echtzeitverhalten, weil du das Ding ohne zusätzlichen Aufwand perfekt vom Timing im Griff haben kannst. Eine reine µC-Lösung würde mich bedenklich stimmen ... Aber ein FPGA/CPLD mit einem simplen SPI-Bus zur Parametrisierung und da dran dann ein schwachbrüstiger 8Biter angeschlossen, wäre meiner Meinung nach die beste Möglichkeit. Und Ausreden "Das kenn ich nicht und da muss ich mich einarbeiten" sind falsch, denn bei einer Diplomarbeit muss man sich eben in neue Sachen einarbeiten ... Glaub's mir ... Anders wirst es nicht besser und/oder einfacher hinkriegen ... Grüße, Müller
Koray schrieb: > und was wenn die Firma die Arbeit als nicht bestanden > an den Prof weitergibt. Der muss sich ja in gewisser Weise mit der Firma > absprechen und dann die Note vergeben. "Failure is always an option" :D Ein Grund mehr, sich nicht eine Aufgabe geben zu lassen, die möglicherweise gar nicht lösbar ist. Wenn du auf Grund deiner Untersuchungen schlüssig begründen kannst, welche Präzision überhaupt erreichbar ist und zudem eine Apparatur vorweisen kannst, die dieser ziemlich nahe kommt, dann ist das ein hervorragendes Ergebnis.
Grolle schrieb: > Liest hier keine meine Beiträge? Doch ich glaube mittlerweile habe ich den kompletten Thread schon dreimal durch. Es werden soviele Sachen vorgeschlagen, sodass ich nicht weiss was denn jetzt das beste ist auszuprobieren und den Ansatz zu finden. Grolle schrieb: > Der Grundgedanke meines Vorschlags ist, dass alles, was Genauigkeit > erfordert, komplett im externen Zählaufbau realisiert wird und dieser > gleichzeitig möglichst einfach bleibt. Ich bin schon auf der Suche nach einem Zählerbaustein, der die Takte einfach nur zählt.
Müller schrieb: > Wie schon gemeint ... Am saubersten und am deterministischsten wird es > mit einem FPGA/CPLD gehen ... Damit bist du dann sehr schnell (>100MHz > möglich, 100MHz ohne Probleme möglich) und hast ein absolt perfektes > Echtzeitverhalten, weil du das Ding ohne zusätzlichen Aufwand perfekt > vom Timing im Griff haben kannst. > > Und Ausreden "Das kenn ich nicht und da muss ich mich einarbeiten" sind > falsch, denn bei einer Diplomarbeit muss man sich eben in neue Sachen > einarbeiten ... Wie ichs auch vorher gesagt habe, ich scheue mich nicht vor Arbeit. Ich bin bereit die Sache 7/24 anzugehen alle Lösungsmöglichkeiten auszuprobieren. Ich kenne mich gut genug um zu wissen, dass wenn ich etwas unbedingt will, auch schaffe. Deswegen habe ich hier geschrieben, die von der Firma haben nun leider keine Ahnung.
Koray schrieb: > Ich hab mit ach und Krach zwei Signale bekommen, einmal ein Zahnrad mit > 43 Zähnen und der eine ist kürzer. Einmal ein Signal wo die Zahnanzahl > unbekannt ist und kein Referenzzahn. Also, nochmal: Aufgabe: Es soll aus einem Signal, welches von einem sich drehenden Zahnrad mit beliebiger Zähnezahl abgenommen wird, einmal pro Umdrehung einen Impuls erzeugt werden. Die Anzahl der Zähne soll dabei vom Benutzer parametrierbar sein. Frage: Ist die räumliche Winkellage des zu generierenden Impulses im Bezug auf das Zahnrad festgelegt (was bei einem Zahnrad ohne Referenzzahn nicht ohne Zusatzinformationen möglich ist), oder kannst du die frei bestimmen? Koray schrieb: > die 1µs ist die Verzögerung Eingang-> Ausgang. Meine Schaltung darf also > max 1µs Bearbeitungs-Rechenzeit brauchen, um es dann am Ausgang als TTL > auszugeben. Zeitliche Bedingungen: Der zu generierende Impuls darf zeitlich maximal 1µs von dem "idealen" Impuls abweichen. Die Wiederholgenauigkeit muß kleiner als 25ns sein. Die maximale Eingangsfrequenz des vom Zahnrad abgenommenen Eingangssignals beträgt 24kHz. Frage: Gibt es auch eine minimale Frequenz, unterhalb der das System keine Impulse zu liefern braucht? Zusatzfrage: Gibt es einen Messmöglichkeit, mit der die Einhaltung der vorgegebenen zeitlichen Bedingungen von dir nachgewiesen bzw. von anderen überprüft werden kann? Stimmt das mit der Beschreibung soweit? Oliver
>Eine reine µC-Lösung würde mich bedenklich stimmen ...
Mich eigentlich nicht, aber das Problem ist mir immer noch nicht klar.
Schade nur, dass sich hier so viele Leute mit einer Lösung beschäftigen
und nach wie vor keine klaren Anforderungen vorliegen, was überhaupt
gemessen werden und in welcher Form irgendein Ergebnis ermittelt werden
soll.
Schade um die Zeit!
Ich dachte an normale TTL-Logik... 3-4 Bytes bräuchte man wohl, jeweils für Zähler, Latch, Komparator und Komparator-Latch, plus Ansteuer/Bus-Logik für den Anschluss an den µC. Das sind natürlich schon einige Bausteine... Aber wichtiger ist, dass das Prinzip dieser Sache verstanden ist. Und für so eine Arbeit reicht vielleicht ein funktionierender Prototyp. Wenn man das dann mit anderen Bausteinen realisiert, auch ok. Warum nicht FPGA, geht sicher auch irgendwie. Aber wenn man sich in µC UND FPGAs einarbeiten muss, ist es natürlich eine Hürde mehr. Einen Haufen Standard-Logikteile miteinander zu verschalten ist ja eher reines Handwerk, das hat man zur Not nach einem Tag ohne viel Nachdenken mit stumpfsinniger Fädeltechnik erledigt und kann sich dann um's Programmieren und Debuggen kümmern.
> Ist die räumliche Winkellage des zu generierenden Impulses im > Bezug auf das Zahnrad festgelegt (was bei einem Zahnrad ohne > Referenzzahn nicht ohne Zusatzinformationen möglich ist), oder kannst du > die frei bestimmen? ja ich das frei bestimmen. > Gibt es auch eine minimale Frequenz, unterhalb der das System > keine Impulse zu liefern braucht? ja, das Triebwerk wird ja hochgefahren, da muss ich ab 10% der Höchstgeschwindigkeit des jeweiligen Triebwerks messen können, bei 24.000Umdr./min wären das 2.400 Umdr./min bei 60 Zähnen wäre das dann eine Frequenz von 2,4kHz. > Gibt es einen Messmöglichkeit, mit der die Einhaltung der > vorgegebenen zeitlichen Bedingungen von dir nachgewiesen bzw. von > anderen überprüft werden kann? Nein, leider nicht, also kann meine Schaltung nur dann geprüft werden, wenn die alten (analogen) Schaltungen, die für jeweilige Zahnräder speziell konzipiert wurden zu vergleichen. > Stimmt das mit der Beschreibung soweit? wenn ich nichts falsch verstanden haben sollte, ja.
Meiner Meinung nach solltest du dir über folgendes klar werden. Wenn du mit Sicherheit sagen kannst das die Firma nur auf das vermarktbare Endergebniss aus ist, und dir bei Nichtlieferung der Lösung ne schlechte Note reindrückt hast du nur noch 2 Möglichkeiten. a) Diplomthema zurückgeben, beim nächsten Versuch vorher schon Aufwandsabschätzung machen Oder b) was ich bevorzugen würde... b) Schnell eine Lösung finden in die man sich auch gut einarbeiten kann. Ich hab die Problematik deines Themas nur überflogen, aber ich hab in meiner Diplomarbeit auch schnelle Flanken zählen müssem mit ner Kombi aus µC und CPLD. Bei dir reicht womöglich auch nur CPLD aus. Daher mein Tip: Besorg dir dieses Board im privaten und zwar schnell, http://www.pollin.de/shop/dt/MTM5OTgxOTk-/Bausaetze/Diverse/Bausatz_CPLD_Evaluation_Board.html mit der Dokumentation die dabei ist kannst du innerhalb von einer! Stunde dir nen Zähler basteln. Dann hast du nen Einstieg und kannst damit weiterarbeiten und hast zumindestens nen Versuchsboard da PS: vielleicht machst du den Leuten der Firma auch klar, das nach 3 Monaten sowieso keine perfekte Lösung existieren kann die vermarktbar ist und sie dich doch bei Bedarf weiter an dem Thema arbeiten lassen sollen... Das ist auch in derem Interesse den eine halbfertige Diplomarbeit macht niemand anderes Zuende und dann hat auch keiner einen Nutzen davon
> ...die von der Firma haben nun leider keine Ahnung. Wie haben die das dann bisher gemacht? Irgendwie muss ja schon mal irgendwas gelaufen sein. Das einfachste wäre doch, diese Funktion in neue Hardware+Software zu giessen. > Nein, leider nicht, also kann meine Schaltung nur dann geprüft werden, > wenn die alten (analogen) Schaltungen, die für jeweilige Zahnräder > speziell konzipiert wurden zu vergleichen. Häh? Babelfish? Wie auch immer: es wird also zum Schluss auf irgendeine Art dein neues Verfahren mit dem Alten verglichen. Und bei einem Unterschied von weniger als 25ns wird davon ausgegangen, dass die beiden gleich sind?
> PS: vielleicht machst du den Leuten der Firma auch klar, das nach 3 > Monaten sowieso keine perfekte Lösung existieren kann die vermarktbar > ist und sie dich doch bei Bedarf weiter an dem Thema arbeiten lassen > sollen... Das ist auch in derem Interesse den eine halbfertige > Diplomarbeit macht niemand anderes Zuende und dann hat auch keiner einen > Nutzen davon Die erwarten mittlerweile auch nur noch einen ausbaufähigen Prototypen. Ich glaub nicht dass die mich noch länger an der Sache arbeiten lassen würden.
Dipl-Ing 09 schrieb: > mit der Dokumentation die dabei ist kannst du innerhalb von einer! > Stunde dir nen Zähler basteln. Aus Wiki: Digitale Schaltungen welche viele Register erfordern, wie beispielsweise Schieberegister oder digitale Zähler, lassen sich daher nur bis zu einem gewissen Grad in CPLDs effizient realisieren.
Koray schrieb: > wenn ich nichts falsch verstanden haben sollte, ja. :-) Die Frage war eigentlich umgekehrt gedacht. Das ist ja schließlich deine Diplomarbeit. Koray schrieb: >> Gibt es auch eine minimale Frequenz, unterhalb der das System >> keine Impulse zu liefern braucht? > ja, das Triebwerk wird ja hochgefahren, da muss ich ab 10% der > Höchstgeschwindigkeit des jeweiligen Triebwerks messen können, bei > 24.000Umdr./min wären das 2.400 Umdr./min bei 60 Zähnen wäre das dann > eine Frequenz von 2,4kHz. Hm. Das reicht mit nicht. Wieviele Zähne hat das Zahnrad mit den wenigsten Zähnen? Wie groß ist die Maximaldrehzahl des langsamsten Triebwerks? Und weiter: Wie groß ist die maximale Änderungsgeschwindigkeit der Drehzahl, bei der das System noch zuverlässig funktionieren muß? Da gibt es sicherlich noch mehr. Es ist DEINE Aufgabe, die etwas unscharfen Anforderungen deines Auftraggebers in eine eindeutige, realisier- und überprüfbare Form zu bringen. Nur dann kannst du am Ende ja auch sagen: Auftrag erfüllt. Also, setz dich hin, und schreib zumindest die dir bekannte Anforderungen zusammen. Diskutier das mit den Auftraggebern und deinem Prof, lass von mir aus ein paar Änderungen zu, aber dann ist Redaktionsschluß. Oliver P.S. Wenn du dann später bei den Vergleichsmessungen mit dem alten System herausfinden solltest, daß das alte System viel schlechter ist, als angenommen, tja, ...
Oliver schrieb: > Hm. Das reicht mit nicht. Wieviele Zähne hat das Zahnrad mit den > wenigsten Zähnen? Wie groß ist die Maximaldrehzahl des langsamsten > Triebwerks? Ganz genau da ist der Knackpunkt. Ungelogen ich habe locker ein Monat damit verbracht die Anzahl der Zähne der verschiedenen Zahnräder herauszufinden. Ich bin den Leuten so sehr auf die Pelle gegangen, dass sie mir jedesmal ok kriegst du bis blablabla gesagt haben. Am Ende kam trotzdem nichts bei raus. An der Stelle danke ich einem Kumpel auch aus der Firma der an einem Triebwerk arbeitet und sich die Mühe gemacht hat Daten und Zeichnungen von einem Zahnrad für mich herauszufinden. Nun bin ich dort angelangt, dass ich mir bestätigen lassen hab, das die maximale Anzahl der Zähne 60 und die maximale Drehzahl 24.000Umdr/min ist. Mehr konnte ich bisher nicht erreichen.
> Digitale Schaltungen welche viele Register erfordern, wie beispielsweise > Schieberegister oder digitale Zähler, lassen sich daher nur bis zu einem > gewissen Grad in CPLDs effizient realisieren. Betrifft dich das? Wieviele Flipflops brauchst du? Davor steht:
1 | Gleichzeitig sollte die Anzahl der notwendigen Speicher (Flipflops) bei der |
2 | Anwendung von CPLDs minimal sein, da pro Ein- bzw. Ausgabepins meist nur ein |
3 | einziges Flipflop als Register zur Verfügung steht. |
Du kannst nicht irgendwelche Zitate irgendwoher rausreissen und darauf deine Argumentation aufbauen!!!!!!elfelfeins Du kannst in einem billigen Spartan3 FPGA locker einen 400MHz-Zähler implementieren. Mit einem CPLD kommst da auch leicht auf 100MHz. Und das wird dir weit reichen (bei dir ist ja bei lockeren 40MHz schon Fine)...
Lothar Miller schrieb: > Du kannst in einem billigen Spartan3 FPGA locker einen 400MHz-Zähler > implementieren. Mit einem CPLD kommst da auch leicht auf 100MHz. Und das > wird dir weit reichen (bei dir ist ja bei lockeren 40MHz schon Fine)... Habe grade ein CPLD Grundlagen Tutorial gefunden und schau mir das grade etwas näher an.
Na, dann halten wir doch mal fest: Mit einem externen Zähler kann man bei Einsatz entsprechender Bausteine Auflösungen bis zu 1/400 MHz erreichen. So weit zum Thema "Ausbaufähigkeit" und "Kunde zufrieden". Die Umdrehungs- und Zähnezahl ist so, dass ein µC die durch eine externe, prinzipiell eher einfache Schaltung mit der gewünschten/vorgegebenen Genauigkeit gemessenen Impulsdurchgänge im verfügbaren Zeitrahmen vermutlich ausreichend genau verarbeiten kann. Den Ausgangs Impuls kriegst Du auch noch hin. Die Fragen von Oliver sollten beantwortet werden, genau wie das hier gesagte rechnerisch und experimentell bestätigt werden sollte. Das ist eine Sache von Lastenheft/Machbarkeit/Technische Daten der Schaltung. Dazu muss man einfach etwas rechnen, sich mal ein paar Schemata auf Papier malen, usw. Ich denke, Du kommst der Sache und den Anforderungen schon sehr nahe. Nur Mut und weiter! Wenn Du dich jetzt nicht noch verzettelst oder verplanst, dann kannst Du meiner Meinung nach noch alles schaffen, was Du erreichen willst, inkl. einer guten Note und Vorzeigeprojekt.
Was die fehlenden Daten angeht: Da musst Du dann halt mit Annahmen arbeiten. Sofern Du eine Größenordnung hast -- und die hast Du schon lange -- und es konfigurierbar ist (das ist ja eh eine Anforderung), dann kannst Du mit ein paar realistischen Werten verschiedene Szenarien durchrechnen, um so ein besseres Gefühl für die Aufgabe zu erhalten und die Sachen auf Plausibilität zu prüfen.
Grolle schrieb: > Was die fehlenden Daten angeht: > > Da musst Du dann halt mit Annahmen arbeiten. Sofern Du eine > Größenordnung hast -- und die hast Du schon lange -- und es > konfigurierbar ist (das ist ja eh eine Anforderung), dann kannst Du mit > ein paar realistischen Werten verschiedene Szenarien durchrechnen, um so > ein besseres Gefühl für die Aufgabe zu erhalten und die Sachen auf > Plausibilität zu prüfen. Sehe ich auch so. Wenn sich die Brüder nicht auf ein paar fixe Zähnezahlen einlassen (oder es nicht wissen), dann komm ihnen entgegen. Frag sie nicht: wieviele Zähne haben wir exakt. Sondern: So ungefähr, welche Anzahl muss ich erwarten? 10, 20, 30, 100, 500 Und die auf die Art eingekreiste Anzahl dokumentierst du dann als Faktum.
Grolle schrieb: > Ich denke, Du kommst der Sache und den Anforderungen schon sehr nahe. > Nur Mut und weiter! Wenn Du dich jetzt nicht noch verzettelst oder > verplanst, dann kannst Du meiner Meinung nach noch alles schaffen, was > Du erreichen willst, inkl. einer guten Note und Vorzeigeprojekt. danke für die Ermutigung, das habe ich momentan wirklich nötig.
Ohne jetzt den gesammten Thread gelesen zu haben... die Timing Anforderungen sind massiv ueberzogen. Ich hab mal ne Drehzahlregelung gemacht, da wurde die Drehzahl als ein Puls pro Umgang direkt gemessen und es waren 4kHz, entsprechend 240'000 U/min. Die Anspechzeitzeit was aber viel langsamer. In den 100Hz.
> Ich hab mal ne Drehzahlregelung gemacht
Hier geht es aber nicht um eine einfache Drehzahlregelung, sondern
darum, einen Referenzimpuls zu erhalten, anhand dessen dann die
dynamische Verformung von Triebwerksschaufeln während des Betriebs
gemessen werden soll.
Also ich habe mir das Tutorial von Thomas Unmuth mal durchgelesen, hab ihm auch eine E-mail geschrieben. Wenn ich das richtig verstanden habe, ist ein CPLD ein Controller, der Rechenlogiken realisiert. Bin momentan auf der Suche nach einem Evaluierungskit zum Einarbeiten für zu Hause. Hoffe damit etwas weiterzukommen.
Achso link zum Tutorial, falls das jemanden interessiert: http://www.unmuth.de/technik/projekte.htm unter CPLD/FPGA Tutorial sind drei Kapitel als PDF gespeichert.
> Bin momentan auf der Suche nach einem Evaluierungskit zum Einarbeiten > für zu Hause. Hoffe damit etwas weiterzukommen. Sieh dir das mal an: Beitrag "XILINX Development Board Bausatz CX95144" > Wenn ich das richtig verstanden habe, > ist ein CPLD ein Controller, der Rechenlogiken realisiert. >>>> Karl heinz Buchegger schrieb: >>>> Was studierst du eigentlich? >>> Elektrotechnik Nur zur allgemeinen Information: Wo? Wie sieht denn der Lehrplan dort aus, wenn du als fast fertiger Ingenieur (Diplomarbeit) noch nichts zum Thema "Programmierbare Logik" weißt?
Lothar Miller schrieb: > Nur zur allgemeinen Information: Wo? > Wie sieht denn der Lehrplan dort aus, wenn du als fast fertiger > Ingenieur (Diplomarbeit) noch nichts zum Thema "Programmierbare Logik" > weißt? Technische Hochschule Darmstadt Nichts wäre jetzt übertrieben, aber mehr als die Grundlagen der Digitaltechnik haben wir nicht gehabt. Wir haben die Kurse Digitaltechnik 1 und 2 gehabt. Wobei ich beim ersten Kurs ne 1 und beim zweiten 2,3 bekommen habe. Ich habe das mit den Logiken und was es da nicht alles gibt. aber das haben wir alle mit Altera MAXPlusII gemacht, also so wirkliche Hardware haben wir nicht gehabt. Nur Software-basierende Labore (Übungen). Ich fand die einfach zu verstehen, weil das Thema mir auch lag. (Zugegeben der Prof hat einem auch ordentlich was beigebracht, übrigens der ist auch im moment mein Betreuer.
Koray schrieb: > ihm auch eine E-mail geschrieben. Wenn ich das richtig verstanden habe, > ist ein CPLD ein Controller, der Rechenlogiken realisiert. Nicht wirklich. Naiv gesagt: Ein CPLD ist ein Baustein mit eine Unmenge an UND und ODER Gliedern bzw. fertigen Flip-Flops, die frei miteinander verschaltet werden können. > Achso link zum Tutorial, falls das jemanden interessiert: > http://www.unmuth.de/technik/projekte.htm Was willst du denn mit diesem Tutorial? Zum eigentlichen Thema steht da ja so gut wie nichts drinnen. Da steht ja schon bei Wikipedia mehr zu dem Thema.
> Zugegeben der Prof hat einem auch ordentlich was beigebracht, übrigens > der ist auch im moment mein Betreuer. Das ist doch schön, wenn wenigstens der sich mit sowas auskennt. Kontaktier den doch mal und frag ihn, was er davon hält.
Lothar Miller schrieb: > Das ist doch schön, wenn wenigstens der sich mit sowas auskennt. > Kontaktier den doch mal und frag ihn, was er davon hält. Werd ich machen.
Und verwende, wenn es geht, einen FPGA ... Die CPLD haben begrenztere Logikresourcen, die nicht sooo flexibel verschaltet werden können ... Ansonsten, ist ein FPGA und ein CPLD in etwa gleich - von der Hardware-Beschreibung sowieso, weil beide in VHDL beschrieben werden. Ist aber meines Erachtens der richtige Weg ... Worauf du auch noch aufpassen musst ist, wie du die Ergebnisse - falls du welche benötigst - innerhalb 1us aus dem FPGA kriegst ... RS232 ist zu langsam ...
> Die CPLD haben begrenztere Logikresourcen, die nicht sooo flexibel > verschaltet werden können ... Ein CPLD hat gewaltige Logikressourcen (die Produktterme). Aber leider hat so ein CPLD nur sehr wenige Flipflops. Und die würden hier dringend gebraucht (Zähler, Zwischenspeicher...). > RS232 ist zu langsam ... Das wollte bisher auch keiner :-o
Also jetzt eine Frage nach dem ganzen Verlauf des Threads: Soll ich FPGA verwenden? Würde meine Zeit bis Ende September zur Einarbeitung und Programmierung reichen? Ist das zumutbar?
Wenn sowiso Konferenz mit dem Prof ansteht würde ich die Aufbereitung der Sensorsignale auch noch mal explizit ansprechen. Sind Nulldurchgänge im Rauschen problematisch? Wie viel Jitter kommt durch die erzeugung der digitalen Trigger Signale schon zustande? Also ist das was du da bisher realisiert hast so schon für eine digitale Weiterverarbeitung innerhalb der Spezifikationen. Ansonsten viel Erfolg und bei fragen mach einen thread im vhdl Forum auf, der Herr Miller hat bei konkreten Fragen eigtl. immer kompetente und hilfreiche Antwort parat. P.S. Ich hasse so Arbeiten, wo die Betreuer sich selbst noch nie Gedanken gemacht haben und weniger Plan haben als man selber. So ist das eigentlich nciht gedacht :-(
Koray schrieb: > Soll ich FPGA verwenden? > Würde meine Zeit bis Ende September zur Einarbeitung und Programmierung > reichen? > Ist das zumutbar? Was genau studierst du nochmal? Und was wäre deine ALternative dazu? Hau rein... Oliver
Christoph schrieb: > P.S. Ich hasse so Arbeiten, wo die Betreuer sich selbst noch nie > Gedanken gemacht haben und weniger Plan haben als man selber. So ist das > eigentlich nciht gedacht :-( Wieso? Aud der einen Seite wird doch immer über eine zu praxisfremde Ausbildung gemeckert, und kommt dann mal jemand mit einer Aufgabe aus dem richtigen Leben, ist es auch wieder nicht richtig ;-) Wie mans macht, ist es verkehrt. Oliver
Oliver schrieb: > Was genau studierst du nochmal? Elektrotechnik > Und was wäre deine ALternative dazu? der Thread hier hat sich eigentlich zu dieser Frage entwickelt. Ursprünglich wollte ich einen µC einsetzen, aber bei den Anforderungen scheint es nicht möglich zu sein.
Bevor hier schon zuviel in eine Richtung gemacht wird, noch ein anderer Vorschlag für die Hardware: PSoC3 von Cypress. Vorteil: als normaler Controller verwendbar, frei konfigurierbare Analog- und Digitalperipherie und, falls die fertigen, zusammenklickbaren Komponenten nicht reichen, auch in Verilog anpassbar. http://www.cypress.com/?id=2232
Ist offtopic, aber der Name Betreuung impliziert das.... Dann sollte die DA als Gruppenarbeit angeboten werden, damit das offenbar notwendige Brainstormen und einkreisen nicht in Foren gemacht werden muss.
Koray schrieb: > Soll ich FPGA verwenden? > Würde meine Zeit bis Ende September zur Einarbeitung und Programmierung > reichen? > Ist das zumutbar? Also wenn du schnell an ein Eval-Board kommst, sollte die Einarbeitung in 2 Wochen machbar sein. Man muss sich halt erst einmal an die etwas andere Denkweise in VHDL gewöhnen, wenn man die sequentielle uC-Programmierung gewohnt ist. Bei mir war das "Problem" die lange Lieferzeit des Cyclone III Starter Kits, das ich verwendet habe.
Hey noch Was schrieb: > VHDL ist nicht zwingend noetig, die schematische Eingabe sollte in den > meisten Faellen genuegen. ... Ist aber fehleranfälliger ... würde ich nicht empfehlen ... VHDL mit getakteten Prozessen ist ideal :)
Hallo, wenn Du das Datenblatt des MAX genau liest siehst Du daß die dort einen Prozessor mit "TPU" empfehlen. Wenn Du im WEB nach TPU suchst findest du Prozessoren von Freescale und entsprechende Application Notes um "toothed wheels" auszuwerten. http://www.freescale.com/webapp/search/Serp.jsp?qt=toothed+wheel&Go=%C2%A0&QueryText=toothed+wheel&baseUrl=http%3A%2F%2Fwww.freescale.com%2Fwebapp&PART_NUMBER=&SEARCH_OPERATOR=Contains&attempt=0 Ich glaube nicht daß Du noch rechtzeitig fertig wirst wenn Du nicht entsprechende fertige Hard+Software einsetzt. Gruß Anja
Auf alle Fälle würde ein mittlerer FPGA reichen, in den Du zur Not noch einen Mikrocontroller synthetisierst, welcher Dir eine menschenwürdige Kommunikation/Parametrierung mit dem PC erlaubt (seriell). Das Ganze als Aufsteckmodul für eine Trägerleiterplatte, welche die Interfaces an Deine Messaufnehmer und PC beinhaltet und in ein vernünftiges Gehäuse paßt, dann sieht die Hardware schon mal beruhigend komplett aus.
@Anja kannst du vielleicht deine Vorschläge konkretisieren gibt es da denn überhaupt fertige lösungen?
Koray schrieb: > kannst du vielleicht deine Vorschläge konkretisieren gibt es da denn > überhaupt fertige lösungen? Die Application Notes im Link oben sind ja schon mal ein Anfang. Eine Winkeluhr zur Positionsbestimmung eines Zahnrades zu bauen ist offensichtlich ein Standardproblem für das es entsprechende Bibliotheken gibt. Natürlich mußt Du das Ganze noch anpassen und zur Winkel-Nulllage deinen Referenzimpuls ausgeben. Eine Komplettlösung wirst Du wahrscheinlich nicht finden. Ansonsten würde ich schauen ob es ein Evaluation-Board zu den entsprechenden Prozessoren gibt. Wenn Deine anvisierten Stückzahlen groß genug sind könnte es sogar sein daß Du Unterstützung durch den Hersteller des Prozessors erhälst. Gruß Anja
Dieser Prozessor ist auf jeden Fall für das Projekt geeignet: http://www.xmos.com/technology/architecture Das Entwicklungskit gibt es für 99$
Hier der Vergleich des XMOS-Prozessors zu FPGA-Anwendungen: http://www.xmos.com/focus/compelling-alternative-low-cost-fpgas Der Prozessor ist deutlich einfacher als ein FPGA zu programmieren.
@Anja Hast Du eine Einschätzung, mit welcher Taktfrequenz die gängigen TPUs von freescale laufen? Mir würde spontan der SH7211 einfallen, der typisch mit 40MHz für die Timer arbeitet.
Hallo, nach ein bisschen Zeit bin ich es noch mal. Ich habe jetzt noch bis Ende September Zeit für meine Diplomarbeit. Folgendes habe ich schon aufgebaut: Ich habe das FPGA Board von Altera Cyclone II Starter Development Board bestellt und programmiert. Ich habe einen 6Bit Zähler mit einstellbaren Zählwert programmiert, der den Takt extern bekommt. Den Wert bis zu dem er zählen soll, bekommt er von Switch-Schaltern, die binär angelegt sind. Der externe Takt wird durch ein User I/O eingegeben, welcher dem Zähler dann den Takt gibt. Dieser Takt ist dann auch das Signal dass ich aus meinem Maximbaustein bekomme -> ein Rechtecksignal aus einem sinusförmigen Signal, wobei die Nulldurchgänge detektiert werden. Ich denke als Laie einen FPGA zum laufen zu bringen ein Programm draufzuladen und dies auch in der Form, in der man es auch möchte innerhalb 2,5 Wochen ist eine gute Leistung. Nun stehe ich jedoch vor einem anderen Problem. Es gibt aber auch Zahnräder die einen speziellen 1/rev Zahn haben. deshalb muss ich jetzt noch drei verschiedene Signaltypen erkennen können. Dazu gehören Zahnräder die, 1. einen kürzeren Zahn 2. einen längeren Zahn 3. einen fehlenden Zahn haben. Der Sinn dabei ist, wenn ich die gesamte Anzahl der Zähne zähle noch ein gleiches System parallel laufen zu lassen, falls diese 1/rev Zähne an dem Zahnrad vorhanden sind. Dann später beide Signale miteinander in Vergleich zu stellen. Ich habe mir 2 verschiedene Lösungen überlegt: 1. Ich werde beim kurzen Zahn die Signale Triggern und der kurze ZAhn wird nicht erkannt, so als ob ne Lücke wäre, und dadurch kann ich den doppelten Signalabstand detektieren lassen. -> gleiche Lösung für die Lücke. Beim langen Zahn Shcmitt Trigger, sodass nur der lange Zahn erkannt wird und dann den Zähler bis 1 zählen lassen. Hierbei ist das Problem aber dass sich die Drehzahl ändert, und dadurch auch die Amplituden, also muss ein adaptiver Schmitt-Trigger her -> Vielleicht durch einen µC steuern lassen aber ich hab kaum noch Zeit. 2. Einen IC finden der bei einem bestimmten Takt aktiviert wird und aus analogem Signal digitale macht und daraus den höchsten wert liest und an den Ausgang gibt. Das würd ich dann nach jedem Nulldurchgang laufen lassen und immer drei miteinander vergleichen. Somit wird dann der kurze oder der Lange Zahn erkannt. Nur habe ich bisher weder einen IC gefunden noch weiss ob das funktioniert. Ich hoffe ich konnte euch mein Problem einigermaßen deutlich klarmachen und hoffe auf hilfreiche Antworten.
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.