Umwandlung von Ticks in Sec und Übertragung an Host

Hi Leute, ich bins mal wieder

Bräuchte ne kurze Nachhilfestunde in Digitaltechnik.

Ich habe eine While Schleife im FPGA in der ich analoge Eingänge als FXP auslese und per FIFO an das Host VI schicke.
Nun möchte ich jedoch gerne auch die dazugehörige Zeitinformation der korrespondieren Schleifenticks mitschicken.

Die Schleifentick lasse ich mir mit Timer VIs als U32 als Mikrosekunden anzeigen.

Da die Datenerfassung mit 10kHz stattfindet und relativ lange dauern kann (größenordnung 1h) würde ich die Zeitfinformation gerne in der Form 12345,1234567 [Sekunden] mitschicken.
Wie kann ich den U32 des Timers am elegantesten so wandeln, dass dies zusammen mit den Analogwerten in ein FIFO passt?

Danke und Gruß

Andy

Anzeige

Nur zum Verständnis was ich vorhabe noch ein Screenshot

Hallo Andy,

Zitat:Wie kann ich den U32 des Timers am elegantesten so wandeln, dass dies zusammen mit den Analogwerten in ein FIFO passt?

Ich würde komplett auf SGL-Daten verzichten!

Den Tickcounter würde ich in den FXP-Datentyp des AI wandeln. Und ich würde den Tickwert auf 2 (oder mehr) FXP-Werte aufteilen, nach dem Muster HH:MMS (statt nur Sekunden hochzuzählen).
Wenn die Samplerate während der Messung konstant bleibt, würde ich auch auf die Ticks komplett verzichten und einfach die Schleifendurchläufe zählen…

Kritik:
1) Wieso verwendest du zusätzliche Loop-Timer, um an einen Tick(bzw. µs)-Count zu kommen? Dazu gibt es erstens das Tick-Count-VI, zweitens bekommst du das sowieso aus dem Loop-Timer heraus, den du für das Timing der AI-Erfassung verwendest.

2) Die Verwendung des Loop-Timers ist in einer Reihe von NI-Beispielen leider immer noch sub-optimal. Ich empfehle den Einsatz innerhalb einer Flat-Sequence:
   

Gruß, Jens

Hallo,

vielen Dank für Eure Anregungen.

Leider ist die Anforderung drei unterschiedliche Sample Rates zu haben: 1S/Sec, 1kS/Sec und 10kS/Sec.
Aus dem Grund ist die Idee mit den Schleifendurchläufen suboptimal.

Das mit der Sequenz habe ich verstanden. Nur habe ich immer noch keine Vorstellung wie ich zusammen mit der variablen Sample Rate einen verlässlichen Zeitstempel erzeugen kann. Der dann zusätzlich auch am besten zusammen mit den Messdaten über das FIFO gesendet werden kann...

Ich bin doch sicher nicht der erste, der Messdaten mit Zeitinformationen versehen will, oder?

Danke im Voraus!
Andy

Rückfrage: Änderst du die Erfassungsrate WÄHREND der Erfassung? Zwecks des Interrupt gehe ich davon aus, dass du erst die Erfassungsrate einstellst und dann bei konstanter Rate solange misst, bis "Stop" gesetzt wird.
Somit ist beim Streamen der Daten per FIFO immer das dt bekannt, somit kann man sich IMHO eine Gesamtzeitberechnung auf FPGA Ebene sparen. Merke: Was man nicht im FPGA machen muss, sollte man dort auch nicht machen. Das spart FPGA-Resourcen und verringert die Compile-Zeit.

Alternative: Übertrag einfach den dt Wert per FIFO, den hast du ja schon.

Gruß, Jens

Hi Jens,

danke für die Anregungen. Ich denke daraus könnte man was machen.

Korrigiere mich bitte wenn da ein Gedankenfehler vorliegt: Ich stelle es mir so vor, dass ich mittels Bedienelement zwischen 3 Samplerates wählen kann. Dafür habe ich dann im RT VI eine Verarbeitung, welche die Änderung am Host VI erfasst und die Tick Rate im FPGA per Eingenschaftsknoten verstellt.

Frage 1: Das sollte ja auch WÄHREND der aktiven Datenerfassung möglich sein, oder? Oder denkst Du es macht mehr Sinn die Datenerfassung zu stoppen und mit neuem Interrupt und neuer Sample Rate neu zu starten?
Frage 2: Das mit dem dt könnte interessant sein. Ich habe nämlich schon drüber nachgedacht die Messdaten ohne Zeitinformation zu übertragen und dann im RT VI als Signalverlauf mit dt zu verwursten. Denkt Ihr es macht mehr Sinn einen festen Zeitstempel im FPGA zu erzeugen und mit zu übertragen oder die Rohdaten mit dt und daraus einen Signalverlauf zu generieren??

Die Ressourcen im FPGA sind nicht so mein Problem. Eher die Befürchtung, dass ich bei absoluten Zeitstempeln irgendwann mal einen Überlauf bekomme und somit die Zeit nicht valide ist.

Danke für Eure Hilfe im Voraus!

Andy

(14.12.2018 09:36 )derandyk schrieb:  Korrigiere mich bitte wenn da ein Gedankenfehler vorliegt: Ich stelle es mir so vor, dass ich mittels Bedienelement zwischen 3 Samplerates wählen kann. Dafür habe ich dann im RT VI eine Verarbeitung, welche die Änderung am Host VI erfasst und die Tick Rate im FPGA per Eingenschaftsknoten verstellt.

Genau so machbar.

(14.12.2018 09:36 )derandyk schrieb:  Frage 1: Das sollte ja auch WÄHREND der aktiven Datenerfassung möglich sein, oder? Oder denkst Du es macht mehr Sinn die Datenerfassung zu stoppen und mit neuem Interrupt und neuer Sample Rate neu zu starten?

Das kannst du realisieren, wie du es am besten brauchst und anwenden kannst. Bei Änderung "on-the-fly" solltest du aber auf jeden Fall das aktuelle dt mitschicken.

(14.12.2018 09:36 )derandyk schrieb:  Frage 2: Das mit dem dt könnte interessant sein. Ich habe nämlich schon drüber nachgedacht die Messdaten ohne Zeitinformation zu übertragen und dann im RT VI als Signalverlauf mit dt zu verwursten. Denkt Ihr es macht mehr Sinn einen festen Zeitstempel im FPGA zu erzeugen und mit zu übertragen oder die Rohdaten mit dt und daraus einen Signalverlauf zu generieren??

Die Ressourcen im FPGA sind nicht so mein Problem. Eher die Befürchtung, dass ich bei absoluten Zeitstempeln irgendwann mal einen Überlauf bekomme und somit die Zeit nicht valide ist.

Meine Meinung hierzu habe ich schon kund getan. Wenn du Angst wegen Zahlenüberlauf hast, dann schau nochmal auf den Vorschlag von Gerd: Aufteilung in Stunden, Minuten, Sekunden, Bruchteile von Sekunden. Bei U16 -Format für Stunden langt das für über 7 Jahre Laufzeit. Alle Berechnungen dafür sind in Ganzzahl-Arithmetik möglich. Alternativ ein U32 für Sekunden und ein weiteres U32 für Bruchteile von Sekunden. Das langt für über 130 Jahre.

Gruß, Jens

(09.12.2018 14:12 )GerdW schrieb:  Den Tickcounter würde ich in den FXP-Datentyp des AI wandeln. Und ich würde den Tickwert auf 2 (oder mehr) FXP-Werte aufteilen, nach dem Muster HH:MMS (statt nur Sekunden hochzuzählen).

Hallo Gerd, Hallo Jens,

danke für Eure tolle Hilfe!

Ich muss leider weiter ins Detail gehen:
Wie kann ich aus einem Tick Count eine derartige Zeitinformation in HH:MMS.ssss ableiten? Das habe ich noch nicht überrissen. Wie generiere ich derartige Zeitformate aus den Ticks und das als UINT32/UINT16???

Mein Problem ist auch, dass der Datentyp der AI ein FXP mit 5 Bit Integer und 26 Bit Wortlänge ist. Das heisst ich habe einen Bereich von plus minus 16 mit reichlich Nachkommastellen. Wie soll ich eine Zeitinformation in ein derartiges Format codieren? Diese Datentypenkonvertierungen zermartern mein Hirn... Oder wäre es tatsächlich besser auch die Messdaten in ein anderes Format zu konvertieren das zusammen mit den Zeitinformationen gesendet werden kann?

Danke für Eure Zeit!

VG

Andy

Dann erweitere den Fixedpoint-Datentyp auf (Länge 32, Integer 11), damit passen deine AI's weiterhin mit der gewüschten Genauigkeit rein.

Mit "Integer To Fixed-Point Cast" kannst du dann einen U32 Integer Wert in den Fixed-Point-Container packen.

   

Der andere Teil deiner Frage sollte bei >10 Jahre LabVIEW und CLA eigentlich auch kein Problem sein, hier ein prinzipieller Aufbau für 40 Mhz FPGA-Frequenz:

   

Gruß, Jens