Hallo, im Rahmen meiner Diplomarbeit (Maschinenwesen, TUM) möchte ich eine nicht messbare Zustandsgröße eines Piezo-Systems mit Hilfe anderer, messbarer Zustandsgrößen abschätzen. Dabei sollen 3D LookUp-Tabellen mit einer Größe von etwa 2,5 MB zum Einsatz kommen. Der verwendete Piezocontroller weist eine Bandbreite von 15 kHz auf. Der Piezocontroller ist aktuell über den USB-Anschluss der integrierten, digitalen Bedieneinheit mit einem PC verbunden. http://www.physikinstrumente.de/de/produkte/prspecs.php?sortnr=602600 Bei meiner Recherche bin ich auf FPGAs gestoßen, die mir für diesen Zweck sehr geeignet erscheinen. Das FPGA-System sollte also entweder den PC ersetzen, oder besser, "zwischen" PC und Piezocontroller eingefügt werden, so dass es Befehle vom PC an den Piezocontroller weitergeben, aber auch selbst z.B. Messwerte abfragen kann. Es müsste außerdem in der Lage sein, mit großen LUTs umzugehen, und diese innerhalb der vorgegebenen Zeit (0,067 ms, basierend auf der Bandbreite von 15 kHz) zu durchsuchen, und evtl. auch noch linear zu interpolieren. Bisher hatte ich an FPGA DevKits oder Evaluationboards wie z.B. diese hier gedacht: http://shop.trenz-electronic.de/catalog/product_info.php?cPath=1_114_123&products_id=830 http://shop.trenz-electronic.de/catalog/product_info.php?cPath=1_47&products_id=631 Ich bin mir allerdings nicht sicher, ob diese Boards meine Anforderungen erfüllen. Außerdem würde ich gerne wissen, ob es für einen Anfänger möglich ist, ein solches System in 4 Monaten entsprechend zu programmieren. Meine Erfahrungen mit Software beschränken sich als Maschinenbaustudent bisher auf LabVIEW, CATIA und ein wenig MatLab. Oder sollte ich für meine Anwendung eher nach einem µC suchen? Ich hoffe Ihr könnt mir weiterhelfen und bedanke mich schon einmal im Voraus! Mit freundlichen Grüßen, Martin
Martin schrieb: > Bei meiner Recherche bin ich auf FPGAs gestoßen, die mir für diesen > Zweck sehr geeignet erscheinen. Warum? FPGA's eignen sich für schnelle Verarbeitung, und 15 KHz ist langsam. FPGA's haben zwar internen Speicher, aber nur sehr teuere haben 2.5 MByte. Ansonsten müsste man den Speicher wieder extern anbinden, und dann wirds wieder langsam. > Oder sollte ich für meine Anwendung eher nach einem µC suchen? So wie Du die Applikation beschreibst, eher schon.
Um das abzuschätzen, braucht man ein paar mehr Informationen. Wieviele Einträge müssen in 15ms durchsucht werden? Wie groß ist ein Eintrag? (in Bit) Wie liegen die Eingangsgrößen vor, anhand derer die Tabellen durchsucht werden? Das "Zwischenschalten" würde dann über USB gehen? Ich würde sagen, für jemanden, der neu auf dem Gebiet FPGA ist, hast du in 4 Monaten kaum eine Chance, die Lösung zum "zwischenschalten" zu realisieren. Ach ja, im Zusammenhang mit FPGAs meint man mit "LUT" eher die kleinste kombinatorische Einheit in einem FPGA. Das ist auch eine LUT, aber eben nicht die, die dir gerade im Kopf rumschwirrt ;-)
Klaus Falser schrieb: >> Oder sollte ich für meine Anwendung eher nach einem µC suchen? > So wie Du die Applikation beschreibst, eher schon. Ich empfehle hier etwas Performantes z.B. aus der Ecke i.MX6 von Freescale. Der schüttelt das, was hier gefordert ist (Nachschlagen eines Wertes in einer 3-D Tabelle und räumliche Interpolation) nebenher aus dem Ärmel. Schlumpf schrieb: > Ich würde sagen, für jemanden, der neu auf dem Gebiet FPGA ist, hast du > in 4 Monaten kaum eine Chance, die Lösung zum "zwischenschalten" zu > realisieren. Und vor allem: unter "Maschinenwesen" zählt für mich nicht vorrangig das Basiswissen zur Beschreibung eines FPGAs. Ich bin mir sicher, dass mit einer halbwegs sauberen Programmierung die Aufgabe sogar von dem im verlinkten Gerät eingebauten 60MHz DSP erledigt werden kann. Der kann das sicher in den 4000 Zyklen (60MHz/15kHz) zwischen den Abtastzeitpunkten erledigen...
Also > 2,5 MB mit > 15 kHz 15000 x 2,5MByte = 39.3GByte/s Dann wohl doch nen FPGA ansonsten beschreibe mal genauer wie genau das laufen soll. Wie groß ist die LUT (wieviele Einträge) ? Wie groß ist ein Eintrag ? wieviele Einträge sollen pro Sekunde durchgearbeitet werden ?
4 Monate inkl. Einarbeitung => uC: schau dir mal den Nachfolger des STM32F4-Discovery-Board an, heisst glaube ich DISCO und hat ausreichend SDRAM sowei einen Display. Beispiele gibt's im Netz zu Hauf. Ausserdem ist dass Board sehr günstig. 4 Monate inkl. Einarbeitung in FPGAs, evtl. SOPCs noch dazu, ist total unrealistisch. Mind. 6 Monate Einarbeitung und noch mal ein paar Monate und dein Projekt steht vlt.
Uwe schrieb: > 15000 x 2,5MByte = 39.3GByte/s denke nicht. Das Prinzip vom "LookUp" ist ja, dass man nicht alles durchsuchen muss, sondern weiß, wo welcher Wert steht.
Uwe schrieb: > Also > 2,5 MB mit > 15 kHz > 15000 x 2,5MByte = 39.3GByte/s Ähm, eine Lookup-Tabelle ist etwa so: ich gehe in X-Richtung, dann in Y-Richtung, und dann in Z-Richtung. Also drei Multiplikationen, zwei Additionen und habe dann meine Speicherzelle. Da ist nichts mit "dreidimensionaler Suche" oder so...
Hallo, vielen Dank für eure zahlreichen Beiträge, damit habe ich in so kurzer Zeit überhaupt nicht gerechnet. Ich versuche mal, die Fragen bzw Antworten der Reihe nach zu beantworten: Klaus Falser schrieb: > Warum? > FPGA's eignen sich für schnelle Verarbeitung, und 15 KHz ist langsam. An dieser Stelle möchte ich mich gleich mal entschuldigen, da ich eine wichtige Information im OP vergessen hatte. Das Piezosystem, mit dem ich in der Diplomarbeit zu tun habe, arbeitet mit 15 kHz. Der Grundgedanke hinter der Diplomarbeit ist aber, ein möglichst universal einsetzbares System zur Zustandsschätzung für Piezoaktoren zu entwickeln, das auch mit höherer Bandbreite zurechtkommen kann. In der kurzen Zeit, die zur Bearbeitung des Themas zur Verfügung steht, ist allerdings eher eine Machbarkeitsstudie, bzw. ein Demonstrator das Ziel, um zu zeigen, dass das Verfahren überhaupt funktioniert. Auch möchte ich mich entschuldigen wenn ich über das Projekt in mancher Hinsicht nicht so viel Auskunft geben darf wie ich es gerne würde, oder wie es hier von nutzen wäre. > FPGA's haben zwar internen Speicher, aber nur sehr teuere haben 2.5 > MByte. Vom Support von NI wurde ich darauf hingewiesen, dass ich meine LUTs nicht in den Block-RAM des FPGA ablegen muss, sondern für diesen Zweck den DRAM nutzen kann. In vielen Produkten von NI, bzw auch auf vielen Evaluation Boards sind mindestens 128 MB DDR2 verbaut. Ich hatte daher angenommen, dass die Block-RAM Größe des FPGA keine Rolle mehr spielt. Kann ich deiner Antwort entnehmen, dass ich damit falsch liege? Schlumpf schrieb: > Wieviele Einträge müssen in 15ms durchsucht werden? > Wie groß ist ein Eintrag? (in Bit) Es sind zwei gleich große 3D-LUTs für zwei unterschiedliche Fälle, die sich aufgrund der Messwerte unterscheiden lassen. Beide haben etwa 90 x 90 x 150 Einträge, mit je 8 bit pro Eintrag. Soweit jedenfalls der derzeitige Plan. > Wie liegen die Eingangsgrößen vor, anhand derer die Tabellen durchsucht > werden? Die Eingangsgrößen sollen vom PI-System abgefragt werden. Dieses antwortet im "GCS" (General Comand Set) von PI, also ASCII-Klartext (zumindest per serieller Schnittstelle). Das Format ist "A=+0002.5583", d.h. da muss noch Text abgeschnitten, bzw Text in Zahl umgewandelt werden. > Das "Zwischenschalten" würde dann über USB gehen? Das Wäre optimal, allerdings bin ich nicht sicher, ob ich in der Lage bin, das entsprechend zu programmieren. Die (einfachere) Alternative wäre die serielle Schnittstelle, allerdings geht dadurch noch mehr Geschwindigkeit verloren. > Ich würde sagen, für jemanden, der neu auf dem Gebiet FPGA ist, hast du > in 4 Monaten kaum eine Chance, die Lösung zum "zwischenschalten" zu > realisieren. > > Ach ja, im Zusammenhang mit FPGAs meint man mit "LUT" eher die kleinste > kombinatorische Einheit in einem FPGA. Das ist auch eine LUT, aber eben > nicht die, die dir gerade im Kopf rumschwirrt ;-) Vielen Dank für deine ehrliche Einschätzung. Dass die LUTs in den FPGA's nur kleine Tabellen mit 0/1 und 4-6 Eingängen sind, war mir zum Glück schon klar, da ich das auf der Support/Training Seite von Xilinx gelesen hatte. Sonst wäre ich darauf wohl auch noch hereingefallen. Lothar Miller schrieb: > Ich empfehle hier etwas Performantes z.B. aus der Ecke i.MX6 von > Freescale. Vielen Dank, ich werde in die Richtung nachlesen! > Und vor allem: unter "Maschinenwesen" zählt für mich nicht vorrangig das > Basiswissen zur Beschreibung eines FPGAs. Richtig, wie gesagt, "Anfänger". > Ich bin mir sicher, dass mit > einer halbwegs sauberen Programmierung die Aufgabe sogar von dem im > verlinkten Gerät eingebauten 60MHz DSP erledigt werden kann. Der kann > das sicher in den 4000 Zyklen (60MHz/15kHz) zwischen den > Abtastzeitpunkten erledigen... Das ist eine interessante Idee für eine spätere Umsetzung, aber das muss dann wohl eher der Gerätehersteller machen. Ich denke nicht, dass ich dazu in der Lage bin. Sigi schrieb: > 4 Monate inkl. Einarbeitung => uC: schau dir mal den Nachfolger > des STM32F4-Discovery-Board an, heisst glaube ich DISCO und hat > ausreichend SDRAM sowei einen Display. Beispiele gibt's im Netz > zu Hauf. Ausserdem ist dass Board sehr günstig. > > 4 Monate inkl. Einarbeitung in FPGAs, evtl. SOPCs noch dazu, ist > total unrealistisch. Mind. 6 Monate Einarbeitung und noch mal > ein paar Monate und dein Projekt steht vlt. Auch dir vielen Dank für deine ehrliche Einschätzung. Auch in Richtung STM32F4/DISCO werde ich recherchieren. Uwe schrieb: > Also > 2,5 MB > mit > 15 kHz > 15000 x 2,5MByte = 39.3GByte/s > Dann wohl doch nen FPGA > ansonsten beschreibe mal genauer wie genau das laufen soll. > Wie groß ist die LUT (wieviele Einträge) ? > Wie groß ist ein Eintrag ? > wieviele Einträge sollen pro Sekunde durchgearbeitet werden ? rava schrieb: > denke nicht. > Das Prinzip vom "LookUp" ist ja, dass man nicht alles durchsuchen muss, > sondern weiß, wo welcher Wert steht. Lothar Miller schrieb: > Ähm, eine Lookup-Tabelle ist etwa so: ich gehe in X-Richtung, dann in > Y-Richtung, und dann in Z-Richtung. Also drei Multiplikationen, zwei > Additionen und habe dann meine Speicherzelle. Da ist nichts mit > "dreidimensionaler Suche" oder so... Ich würde gerne, um Platz zu sparen, auf meine Antwort an "Schlumpf" weiter oben in diesem Post verweisen. Kurzfassung: Zwei gleich große 3D-LUTs, etwa 90 x 90 x 150 Einträge, 8 bit pro Eintrag. Anhand der gemessenen Zustandsgrößen soll die Position (x,y,z) auf den jeweiligen Achsen gefunden, und dann der entsprechende Wert aus der Tabelle gelesen werden. Zum Finden des Werts sind jeweils etwa 8 Vergleichsoperationen zweier 8 bit Werte nötig. (Immer bei der Hälfte der relevanten Skala die Frage: Ist der Messwert größer/kleiner als der Wert auf der Achse, das dürfte das schnellste Suchverfahren sein) Ich hoffe meine Antworten und Ausführungen waren hilfreich für weitere Diskussionen, und möchte mich nochmal für die Hilfe bedanken!
Ich möchte ja nicht an deiner Intelligenz und Lernfähigkeit mäkeln, doch ich halte 4 Monate zu kurz, um mit FPGAs zu beginnen. Für die Diplomarbeit fallen ja noch mehr Aufgaben an, als nur FPGA zu kodieren. Es muss Text geschrieben werden, experimentiert werden, etc. Der Einstieg in FPGA und VHDL ist sehr schwierig, ich würde alleine für die FPGA-Einarbeitung 4 Monate veranschlagen. Darin hast du aber noch nichts anderes gemacht. Außerdem gibt es ja noch keine weitere Erfahrung mit normalen Programmiersprachen (so was wie C), so dass das Zusammenspiel mit dem Computer auch noch schwierig wird. Der Piezo-Kontroller hat USB. Alleine den per FPGA zu kontrollieren ist für einen Anfänger unmöglich. Mein Vorschlag wäre alles erst mal auf einem dicken PC zu entwicklen. Wenn dann alles steht, kann man die benötigte Rechenleistung und Speicherbedarf nehmen, und das System herunterstrippen auf die wirklich benötigte Leistung. Mit einem PC hat man auch ein Debugging-Umgebung, die man beim Spielen mit den Parametern braucht.
Allein die Wahl der richtigen Komponenten um dann eine realistische Chance zu haben die Datenverarbeitung zu bewältigen ist eine Arbeit für sich. Wenn ich das richtig verstehe willst du im 15kHz-Raster aus Umgebungsgrößen einen Eintrag aus einer 2,5MB großen Matrix rausfischen? Was ist wenn du eine Überabtastung brauchst?
Martin schrieb: > Anhand der gemessenen Zustandsgrößen soll die Position (x,y,z) auf den > jeweiligen Achsen gefunden ... werden. > Zum Finden des Werts sind jeweils etwa 8 Vergleichsoperationen zweier 8 > bit Werte nötig. Ich kapiere den Zusammenhang zwischen "Suchen" und "LUT" nicht. Woher kommen die 3 Werte für die (nennen wir sie mal so:) x,y und z Koordinaten in dieser 3D-LUT? Warum sind die Eingangsdaten nichtlinear? Warum musst du auf der jeweiligen Achse erst noch den Index suchen? Ist die Tabelle ungünstig angelegt? > (Immer bei der Hälfte der relevanten Skala die Frage: Ist der Messwert > größer/kleiner als der Wert auf der Achse, das dürfte das schnellste > Suchverfahren sein) Ja, das nennt sich Wägeverfahren oder sukzessive Approximation. So arbeitet schon der AD-Wandler. Aber wenn ich eine LUT ausrechne und anlege, dann mache ich die geschickterweise so, dass ich die Eingansdaten unverändert auf die LUT loslassen kann. Und kann so bei einer 90*90*150 LUT mit einer Rechnung wie z.B. "Adresse = x*90*90 + y*90 + z" direkt auf den Wert zugreifen. Wenn die LUT zwar statisch, aber nicht passend skaliert ist, dann lässt sie sich vorher so umrechnen, dass der einfache direkte Zugriff wieder funktioniert. So läuft das weltweit tadellos bei zigmillionen Motorsteuergeräten. Und da geht es mit weniger Rechenleistung mindestens genauso schnell zur Sache. Natürlich könnte ich dann noch die Nachbarkoordinaten auslesen und dazwischen linear (oder sonstwie) interpolieren. Aber der Trick ist doch der, dass zuallererst der Zugriff maximal vereinfacht wird.
:
Bearbeitet durch Moderator
@ Lothar Miller (lkmiller) (Moderator) Benutzerseite >Ich kapiere den Zusammenhang zwischen "Suchen" und "LUT" nicht. Woher >kommen die 3 Werte für die (nennen wir sie mal so:) x,y und z >Koordinaten in dieser 3D-LUT? Warum sind die Eingangsdaten nichtlinear? >Warum musst du auf der jeweiligen Achse erst noch den Index suchen? Wahrscheinlich weil er invers arbeiten will/muss. Also eher ein CAM Anwendung (Content Adressable Memory). Sprich, er misst eine Größe. Die ist aber nicht EINGANG sondern AUSGANG der 3D Matrix, sprich die einzelnen Werte. Nun muss er zu diesem MEsswert die nächstmöglichsten Koordinaten X, Y und Z finden.
Falk Brunner schrieb: > Nun muss er zu diesem MEsswert die nächstmöglichsten Koordinaten X, Y > und Z finden. Das geht auch nur, wenn die aufgespannte dreidimensionale Fläche keine lokalen Minima oder Maxima hat. Ein Zurückrechnen vom Ausgang- zum Eingangswert ist ja schon bei einer simplen quadratischen Funktion im Normalfall mit 2 Ergebnissen verbunden...
:
Bearbeitet durch Moderator
jo klar, das hängt extrem davon ab, welche Eigenschaften der Daten in der LUT garantiert werden können. Wenn man nichts drüber weiß, hilft nur eine Brute-Force-Suche. Die dauer lange :) ich denke, der TO müsste den Algorithmus noch etwas genauer beschreiben, damit wir ihm geeignete Hardware empfehlen können. Irgendwie habe ich aber das Gefühl, dass es ihm darum gar nicht geht...
@ PittyJ: Auch das Erstellen der LUTs aus Messwerten ist z.B. Teil der Arbeit. Es gibt also "nebenher" auch noch etwas zu tun. Ich fange im Moment damit an, das ganze mit vereinfachten LUTs am PC umzusetzen. Trotzdem wollte ich jetzt schon rechtzeitig nach geeigneter Hardware für eine spätere "Stand Alone Lösung" suchen. @René B.: > Allein die Wahl der richtigen Komponenten um dann eine realistische > Chance zu haben die Datenverarbeitung zu bewältigen ist eine Arbeit für > sich. Daher hatte ich auf ein paar Tipps gehofft, auf was ich achten muss u.ä., oder Meinungen zu der von mir gefundenen Hardware im OP. > Wenn ich das richtig verstehe willst du im 15kHz-Raster aus > Umgebungsgrößen einen Eintrag aus einer 2,5MB großen Matrix rausfischen? > Was ist wenn du eine Überabtastung brauchst? Zum ersten Teil später mehr. Ich bin bisher davon ausgegangen dass ich nicht öfter abtasten muss als der Piezocontroller überhaupt Regeleingriffe vornehmen kann. @Lothar Miller & Falk Brunner: Ich denke wir reden da etwas aneinander vorbei, vermutlich deswegen, weil mir die Umsetzung in Software nicht klar ist. Das neue System (FPGA/µC/...) soll als Eingangsgrößen Messwerte vom PI-System bekommen. (Im Idealfall soll es mit dem PI-System kommunizieren und selbst danach fragen). Diese Messwerte werden im oben angegebenen Format (A=+0002.5583) vom PI-System ausgegeben. Es handelt sich dabei um Messwerte physikalischer Größen. Diese physikalischen Größen entsprechen den Achsen der LUT. Der Inhalt der LUT ist eine weitere physikalische Größe, die nicht so leicht direkt Messbar ist, wenn das PI-System in einer Anwendung verbaut wird. Daher wurde zur Messung dieser physikalischen Größe ein Prüfstand entwickelt, mit dessen Messungen eine LUT gefüllt werden soll. Abhängig von den Eingangsgrößen soll also diese weitere physikalische Größe, deren Werte in der LUT stehen, ausgegeben werden. Wenn ich das "von Hand" mache, suche ich, wo ich mich auf den 3 Achsen befinde. Das wird im Normalfall immer zwischen zwei Achsenwerten sein, da ich 90 Werte pro Achse habe (10.0000, 20.0000 ...) es aber durch die Nachkommastellen (beispielsweise) 90000 unterschiedliche Messwerte geben kann. Also weiß ich, ich liege auf jeder Achse zwischen 2 bestimmten Werten. Das können dann 8 Felder in der LUT sein, zwischen denen ich noch 3-Dimensional einen Mittelwert bilden muss. Wie die Software nun abhängig von den Eingangsgrößen entscheidet, welche der Felder das sind, weiß ich nicht, da ich nicht weiß, wie VHDL/... arbeitet. Ich hätte vermutet, dass es die Eingangsgröße so lange mit den Achsenwerten vergleicht, bis die richtige "Höhe" gefunden wurde. Es geht also nicht darum, einen Messwert mit dem Inhalt der LUT zu vergleichen, sondern aus mehreren Messwerten über die Achsen der LUT das/die Felder zu finden, in dem der gewünschte Wert steht. @rava: Wie bereits oben erwähnt mangelt es mir wohl einfach an Wissen über die Software. Ich weiß nicht, in welchem Format eine LUT in VHDL abgelegt wird. Ich weiß auch nicht, ob es fertige "Befehlssätze" gibt, um LUTs durchsuchen zu lassen. Daher weiß ich leider auch nicht, wie ich einen "Algorithmus" beschreiben soll. Zumindest nicht besser, als in den vorangehenden Absätzen. Mich würde außerdem interessieren worum es mir geht, wenn nicht darum, geeignete Hardware zu finden.
Trivialvorschlag: Nutz ein Flash-SPI speicher und leg dort die Lookup Table ab. Bandbreite schaffste Locker.
Martin schrieb: > weiß ich nicht, da ich nicht weiß, wie VHDL/... arbeitet. Du stellst dir unter "Signalverarbeitung mit VHDL" zuviel vor. VHDL beschreibt nur Hardware. Und solange du nicht weißt, wie genau diese Hardware auszusehen hat, macht es keinen Sinn, sich nach FPGAs zu strecken. > Ich weiß nicht, in welchem Format eine LUT in VHDL abgelegt wird Du kannst diese LUT gar nicht in VHDL ablegen, weil es kein sinnvoll bezahlbares FPGA gibt, das diese LUT intern speichern könnte. Du brauchst also externen Speicher und eine Möglichkeit, darauf zuzugreifen. Du musst du z.B. in Hardware einen Zugriff auf ein RAM in viele kleine Einzelschritte aufteilen. Dass die Berechnung der Adresse im FPGA parallelisiert werden kann, bringt da nicht mehr allzuviel. > Ich hätte vermutet, dass es die Eingangsgröße so lange mit den > Achsenwerten vergleicht, bis die richtige "Höhe" gefunden wurde. "Es" vergleicht da von sich aus gar nichts. Du selber musst das, was du zur Zeit manuell machst, so beschreiben, dass es ab da dann automatisch geht. Zudem musst du da gar nichts vergleichen. Mit ein paar sinnvoll platzierten Rechenoperationen (div und modulo) bekommst du direkt den Index. Dann noch eins drauf addiert und du hast den zweiten Punkt auf der "Skala". > da ich 90 Werte pro Achse habe (10.0000, 20.0000 ...) es aber durch die > Nachkommastellen (beispielsweise) 90000 unterschiedliche Messwerte geben > kann. Also weiß ich, ich liege auf jeder Achse zwischen 2 bestimmten > Werten. Das können dann 8 Felder in der LUT sein, zwischen denen ich > noch 3-Dimensional einen Mittelwert bilden muss. Auch nicht allzu kompliziert... Ich behaupte nach wie vor: ein halbwegs potenter uC packt die Aufgabe locker.
Du hast Hardware mit fertigen Schnittstellen, Treiber für den PC und 4 Monate Zeit. Warum entwickelst du deinen Algo nicht auf dem PC ? Wenn dann alles so funktioniert wie du dir das denkst und du dann noch Zeit hast, kannst du das immer noch in ein MC oder FPGA packen.
Ich würde gerne in 4 Monaten noch mal hören, was du wirklich gemacht hast, und wie es funktioniert hat. Viel Spass bis dahin.
@ Lothar Miller (lkmiller) (Moderator) Benutzerseite >Ich behaupte nach wie vor: ein halbwegs potenter uC packt die Aufgabe >locker. Sicher. Ein 3D Array auslesen, selbst wenn es 8 Werte sind und dazwischen zu interpolieren ist ein Klacks. Könnte fast ein AVR schaffen ;-)
@ Martin (Gast) >befinde. Das wird im Normalfall immer zwischen zwei Achsenwerten sein, >da ich 90 Werte pro Achse habe (10.0000, 20.0000 ...) es aber durch die >Nachkommastellen (beispielsweise) 90000 unterschiedliche Messwerte geben >kann. >Also weiß ich, ich liege auf jeder Achse zwischen 2 bestimmten Werten. >Das können dann 8 Felder in der LUT sein, zwischen denen ich noch >3-Dimensional einen Mittelwert bilden muss. >Wie die Software nun abhängig von den Eingangsgrößen entscheidet, welche >der Felder das sind, weiß ich nicht, da ich nicht weiß, Wieso? Das hast du doch selber gesagt! Wenn der Messert z.B. 40,3 ist, dann liest man die Koordinaten von 40 und 41 aus und interpoliert. Das ganze 3dimensional macht 8 Messwerte. > wie VHDL/... >arbeitet. Ich hätte vermutet, dass es die Eingangsgröße so lange mit den >Achsenwerten vergleicht, bis die richtige "Höhe" gefunden wurde. Nein, es wird schlicht gerechnet, lineare Algebra in 3D. Eine nicht allzuschwere Aufgabe för den Schöööler. Das in VHDL umzusetzen ist auch nich allzu kompliziert, nichtsdestotrotz braucht man dazu Grundlagen. Oder man nimmt die diversen Codegeneratoren, die aus Mathlab & Co VHDL erzeugen und hofft, dass es reicht. Bei 15 kHz geht da kaum was schief, ist für ein FPGA eigentlich viel zu langsam.
Martin schrieb: >> Wenn ich das richtig verstehe willst du im 15kHz-Raster aus >> Umgebungsgrößen einen Eintrag aus einer 2,5MB großen Matrix rausfischen? >> Was ist wenn du eine Überabtastung brauchst? > > Zum ersten Teil später mehr. Ich bin bisher davon ausgegangen dass ich > nicht öfter abtasten muss als der Piezocontroller überhaupt > Regeleingriffe vornehmen kann. > > Das neue System (FPGA/µC/...) soll als Eingangsgrößen Messwerte vom > PI-System bekommen. (Im Idealfall soll es mit dem PI-System > kommunizieren und selbst danach fragen). Hast du schon mal versucht im 15 kHz Takt Daten per USB einzulesen und dann gleich auch noch Daten im 15 kHz Takt zurückzuschreiben? USB ist für sowas nicht ausgelegt und die Latenzen sind viel zu hoch für 15 kHz. (Mit 8 kHz lesen ist bei USB High-Speed/Super-Speed schluss, 125 uS Mikroframe Zyklus). Die Chance dass der Piezocontroller nur Full-Speed USB kann mit max. 1 kHz steht hoch. Ethernet z. B. ist da auch nicht besser (Gewisse Echtzeit-Ethernet Systeme schon eher). PCI oder PCI-E könnte das. Oder der DSP im Piezo System, er selber kann das so schnell. Wenn man an diesen DSP genug Speicher anschliessen kann (wie das vorgeschlagene SPI Flash), könnte das klappen. Sonst gibt es vom DSP Hersteller sicher noch Varianten die etwas schneller als 60 MHz laufen.
@ Christoph Z. (christophz) >Hast du schon mal versucht im 15 kHz Takt Daten per USB einzulesen und >dann gleich auch noch Daten im 15 kHz Takt zurückzuschreiben? Niemand sagt, dass man es SO blauäugig machen soll. Digitales Audio geht auch mit 44.1kHz über USB, sogar nur Full Speed USB mit 12Mbit/s. Das geht natürlich nur mit der passenden Pufferung und Datenblöcken. Einzelne Samples in einen USB-Frame zu packen ist reichlich sinnfrei. Dito bei Ethernet. >Systeme schon eher). PCI oder PCI-E könnte das. Wäre aber auch nur bedingt sinnvoll.
Christoph Z. schrieb: > Mit 8 kHz lesen ist bei USB High-Speed/Super-Speed schluss, 125 uS > Mikroframe Zyklus Man darf da natürlich nicht versuchen, die Daten in einem festen Zyklus abzuholen. Nein, das muss mit Zeitstempel versehen als Paket ablaufen. Sonst geht das nicht mal mit PCIe. Der ist auch nur dann schnell, wenn möglichst große Datenpakete übertragen werden. Das Übertragen von einzelnen Worten wird mit maximalem Overhead und grauenhafter Performance bestraft...
Da du ja schon mit Labview umgehen kannst, würde ich das weiterverwenden. Die Daten bekommst du recht einfach in den PC, sogar über einen UART würde das gehen, sogar die billigen CP2102 machen 921600Baud. Da kannst du immer noch so 7 Bytes übertragen, also 7 Bytes 15 000 mal je Sekunde. Das sollte eigentlich ein uC können, kannst aber auch ein kleines FPGA nehmen. Ich habe das so ähnlich gemacht, also ich habe keinen konstanten Datenstrom, aber die zufälligen Ereignisse können eben schnell hintereinander auftreten. Die Daten packe ich in einen FIFO und dann auf den UART. Um zu erkennen wo ein Packet anfängt habe ich eben ein schönes Format ausgedacht. Bei mir sind das je Byte immer 7 Bits Nutzlast und 1 Bit um zu erkennen ob Packetstart oder nicht. Am PC kann man das dann total einfach mit C parsen und auswerten. Oder eben Labview hernehmen, das kann ja auch RS232 annehmen.
Martin schrieb: > Es müsste außerdem in der Lage sein, mit großen LUTs umzugehen, und > diese innerhalb der vorgegebenen Zeit (0,067 ms, basierend auf der > Bandbreite von 15 kHz) zu durchsuchen, und evtl. auch noch linear zu > interpolieren. Martin schrieb: > An dieser Stelle möchte ich mich gleich mal entschuldigen, da ich eine > wichtige Information im OP vergessen hatte. Das Piezosystem, mit dem ich > in der Diplomarbeit zu tun habe, arbeitet mit 15 kHz. > Der Grundgedanke hinter der Diplomarbeit ist aber, ein möglichst > universal einsetzbares System zur Zustandsschätzung für Piezoaktoren zu > entwickeln, das auch mit höherer Bandbreite zurechtkommen kann. In der > kurzen Zeit, die zur Bearbeitung des Themas zur Verfügung steht, ist > allerdings eher eine Machbarkeitsstudie, bzw. ein Demonstrator das Ziel, > um zu zeigen, dass das Verfahren überhaupt funktioniert. Aus diesen Angaben lese ich, dass es sich hier um einen digitalen geschlossenen Regelkreis mit einer Regelbandbreite von 15 kHz handelt. Falk Brunner schrieb: > @ Christoph Z. (christophz) > >>Hast du schon mal versucht im 15 kHz Takt Daten per USB einzulesen und >>dann gleich auch noch Daten im 15 kHz Takt zurückzuschreiben? > > Niemand sagt, dass man es SO blauäugig machen soll. > Digitales Audio geht auch mit 44.1kHz über USB, sogar nur Full Speed USB > mit 12Mbit/s. Das geht natürlich nur mit der passenden Pufferung und > Datenblöcken. Einzelne Samples in einen USB-Frame zu packen ist > reichlich sinnfrei. Dito bei Ethernet. Das übliche Thema: Die einen Reden von Datenrate, die anderen von Latenzzeit (In der Regelungstechik öfter Totzeit genannt). Bei geschlossenen Regelkreisen habe ich keine Zeit um Sachen zu puffern und in grösseren Blöcken zu übertragen. Ein Mitarbeiter bei uns Pflegt zu sagen: "Die Totzeit ist der Tod des Reglers."
@ Christoph Z. (christophz) >Aus diesen Angaben lese ich, dass es sich hier um einen digitalen >geschlossenen Regelkreis mit einer Regelbandbreite von 15 kHz handelt. Ich nicht. Das kann sein, muss nicht. Ist aber egal. Ansonsten hast du natürlich Recht.
Mal sehen ob Martin uns da aufklärt.
Christoph Z. schrieb: > Mal sehen ob Martin uns da aufklärt. Ich werds versuchen. Beim Piezoverstärker handelt es sich um eine modifizierte Version von diesem Gerät: http://www.physikinstrumente.de/de/produkte/prspecs.php?sortnr=601070 Der integrierte Positionsregler ist eine modifizierte Version hiervon: http://www.physikinstrumente.de/de/produkte/prspecs.php?sortnr=602500 Beide zusammen bilden einen Regelkreis zur Positionsregelung, der mit 15 kHz arbeitet. Später soll die zusätzliche Zustandsgröße ebenfalls in mindestens dieser Geschwindigkeit abgeschätzt, und letztendlich auch "geregelt" werden können. Für meinen reinen Zustandsschätzer jetzt wäre ich mit einer Lösung, die mehrere Datensätze als Paket zusammenfasst mehr als zufrieden. Dennoch hätte ich ohne den Hinweis die Beschränkung der Taktrate durch den USB übersehen, oder viel zu spät bemerkt. Hans-Georg Lehnard schrieb: > Warum entwickelst du deinen Algo nicht auf dem PC ? Damit habe ich inzwischen (langsam) angefangen. Im Vordergrund steht im Moment auch noch die Erstellung der LUTs und die Generierung der Messdaten. Gustl Buheitel schrieb: > Da du ja schon mit Labview umgehen kannst, würde ich das > weiterverwenden. > Oder eben Labview hernehmen, das kann ja auch RS232 annehmen. Entweder das, oder Matlab. Unter LabVIEW ist auch die USB-Schnittstelle sehr einfach zu benutzen, da PI einen kompletten Satz Treiber und .vi Pakete mitliefert. Und ab dann bin ich in einer Umgebung, mit der ich arbeiten kann. Erneut vielen Dank für den vielen Input und die rege Diskussion. Auch wenn ich in meinen Antworten nicht auf jeden Beitrag einzeln eingehe lese ich natürlich alles und versuche davon ausgehend selbstständig zu recherchieren.
kannste knicken
Thread beobachten
Seitenaufteilung abschaltenBitte 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.