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=830http://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.
@ 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...
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.
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.
@ 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.
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.
