Das Forum für LabVIEW-Entwickler

Hallo zusammen,

ich möchte mehrere Analogwerte erfassen. Mit der Scan-Engine komme ich an die Grenzen, wenn ich die Signale skaliere und filtere. Daher wollte ich das ins FPGA auslagern.
Den Butterworth-Filter habe ich schon gefunden, nur die Skalierung bereitet mir Probleme (er erinnert jedoch an die Express-VIs ...).
Mir ist der Datentyp "Fixedpoint" irgendwie unsympathisch.

Ich habe versucht, mir ein SubVI für die Skalierung zu schreiben, aber da weiß ich nicht, welche Werte ich übergeben muss.

   

Bei DAQmx kann ich z.B. Double-Werte nutzen und sagen, dass die Werte unskaliert bei 0,004 bis 0,02 mA liegen und skaliert bei 10 - 200 l/min o.ä.
Aber auf FPGA-Ebene kriege ich das (noch) nicht hin.

Wie funktioniert das denn?

Vielleicht ist es auch sinnvoller, alles in Fixedpoint zu berechnen, auch im RealTime-Bereich, wenn das schneller ist. Nur kann ich mir dann noch weniger vorstellen, wie das ablaufen muss. Beispielsweise, wenn es um den Vergleich der Messwerte mit einem Triggerwert geht.

Sofern es geht arbeite ich lieber mit RAW Werten. Die meisten Module die ich verwende haben eine 16bit Auflösung, liefern also I16 Werte.
Dazu werden bei FPGA Initialisierung die Kalibrierwerte der Module an den RT gegeben und können entsprechend verrechnet werden. Triggerschwellen werden dann als I16 an den FPGA zurückgegeben.
(Die Anzahl der Kalibrierdaten hängt von der im Modul verwendeten Anzahl von DAC's/ADC's ab.)

Die Kalibriervorschriften sind je nach Modul unterschiedlich. Die beste Referenz ist hier die LV Hilfe ( benutze ' Converting and Calibrating ' als Suchstring )

Hope it helps
Christian

Hallo,

vielen Dank, aber noch fehlt's mir an der Umsetzung. Die FPGA-Schulung ist erst Ende August ...

Ich habe es wie folgt versucht, doch ich erhalte keine skalierten Werte und der FPGA-Compiler bringt die Warnung, dass der reale Takt 39,8 MHz beträgt, ich jedoch 40 MHz eingestellt habe. Niedriger geht es jedoch nicht.
D.h. die Performance stimmt bei meiner Umsetzung absolut nicht.
Und das ganze ist aktuell bei 2 Kanälen so, später habe ich 16.

Die FPGA-Skalierung:

   

Der FPGA-Code:

   

Und der Real-Time-Code:

   

Welche grundlegenden Fehler mache ich denn bzw. mache ich überhaupt etwas richtig?

Die FPGA Schulung hilft da auch nicht weiter. Die Kurse sind wirklich nicht der Hammer.

Fixed Point frisst Ressourcen ohne Ende. Schau Dir mal die Verarbeitungsbreite bei FixedPoint an. Das geht bis 64bit ! Bei 16Kanälen ist der FPGA garantiert dicht. Du müsstest auch noch FixedPoint-Werte per Control an den RT übergeben, da die DMA FIFO's mit FixedPoint nicht laufen... sinnlos... (Immer dran denken die Backplane-RT Verbindung ist 32bit breit.)

Wenn Du kurzfristig Dein Taktproblem lösen willst musst Du SCTL's einsetzen. Das läuft dann unter FPGA Optimierung (schon x-mal im Forum).

Nochmal meine Empfehlung: Arbeite mit RAW Daten !

Sorry, aber was soll ich sagen !?

Gruß Christian

Hi,

wenn Du doch schon ein RT-Target hast, würde ich folgendes machen:
- Daten im FPGA als I16 (oder was auch immer die Module mitbringen) einlesen
- Daten in FIFO schreiben (wie man das macht, steht ganz gut in den FPGA-Beispielen im Beispielfinder)
- RT liest den FIFO aus, sortiert die Kanäle und skaliert. Filterung würde ich ehrlich gesagt auch da machen, wenn Du nicht auf FPGA-Ebene eine Regelschleife implementierst...

Zur Performance:
NI hat ein paar Hinweise, wie man das auf FPGA-Ebene machen kann. Also z.B. keine Divisionen sondern Multiplikationen mit anschließendem Bitschieben, Pipelining nutzen (das wird wahrscheinlich Deine Compilerwarnung erledigen können: 1. Stufe Einlesen der Module, 2. Stufe Skalierung, 3. Stufe Filtern. Macht einen Time-Lag von 3* der längsten Durchlaufzeit, vermutlich das Einlesen oder die Skalierung.)

Zu dem Punkt, dass du mit dem oben beschriebenen Code keine skalierten Werte bekommst: m.E. logisch, da Du die Module direkt mit den Filtern verbindest und nicht die (wahrscheinlich vorhandenen) Ausgänge deiner Skalierungs-SubVIs.

Wenn Du unbedingt mit FXP arbeiten willst: Mach Dir die Arbeit und schau Dir an, wie breit Deine Daten sein müssen. LV nimmt leider als Standarteinstellung immer die höchsten Werte mit 64 bit Breite und die braucht man meist nicht... Wenn Du das optimierst müssten Deine Skalierungsvorgänge vom Compiler deutlich besser zu implementieren sein...

ch