Messwerte aus UM232H (USB) jede ms in TDMS Datei schreiben

Hallo liebe Community,

ich bin seit längerer Zeit bereits regelmäßig als stiller Mitleser hier dabei.
Nun habe ich ein neues Projekt begonnen und benötige etwas Hilfe…

Folgendes soll realisiert werden:

Mein Kollege hat eine Platine entworfen, die über CANBUS Messwerte von zehn Teilnehmern empfängt. Die Messwerte werden von einem Mikrocontroller verarbeitet und dann via USB 2.0 (FTDI board UM232H) an den Rechner gesendet. Die Werte werden jede ms als ein zusammenhängender String gesendet.

Treiber habe ich bereits D2XX von FTDI installiert und ich kann auch bereits erfolgreich den gesendeten String einlesen, nach Werten untersuchen und aufteilen.
Nun möchte ich die Werte in eine TDMS Datei schreiben, auch das funktioniert bereits.

Allerdings liegt genau hier mein Problem:
Ich möchte, dass jede ms ein Wertepaket in der TDMS Datei gespeichert wird. Ich erwarte also für jede Messgröße 1000 Werte (1000 strings) in der Sekunde. Bei einer Laufzeit von 4 Minuten müsste ich dementsprechend 4x60x1000 = 240.000 Werte in der Datei finden.
Ich finde jedoch nur um die 2000 Werte…

Habe ich irgendwo einen Denkfehler? Reicht eventuell die Rechnerleistung nicht aus? Ist mein Vorhaben überhaupt umsetzbar mit Windows? Ist mein Labview Programm fehlerhaft und braucht für die Verarbeitung zu lange?


Ich hoffe ihr könnt mir weiterhelfen

Für eure Bemühungen im Voraus besten Dank.

Meine LV Version ist 2013 Sp1.

Viele Grüße,
Ben

Anzeige

Hallo Ben,

liest du wirklich immer genau 1 Datensatz innerhalb deiner While-Schleife ein? Oder enthält dein String "Lesen aka USB" mglw. jeweils viele Datenblöcke?

Wie ist denn das Format eines Datensatzes? Hat der immer die gleiche Länge? Oder ein festes Abschlusszeichen? Oder wird der Beginn eines neuen Datensatzes durch das "A" festgelegt?

Gruß, Jens

(02.06.2021 14:52 )jg schrieb:  Hallo Ben,

liest du wirklich immer genau 1 Datensatz innerhalb deiner While-Schleife ein? Oder enthält dein String "Lesen aka USB" mglw. jeweils viele Datenblöcke?

Wie ist denn das Format eines Datensatzes? Hat der immer die gleiche Länge? Oder ein festes Abschlusszeichen? Oder wird der Beginn eines neuen Datensatzes durch das "A" festgelegt?

Gruß, Jens

Der String hat immer die gleiche Länge und ein festes Abschlusszeichen (ohne funktioniert das Zuordnen der einzelnen Werte nicht zuverlässiu nd LV schmeißt ne Fehlermeldung)

ich bin mir nicht sicher, ob ich wirklich nur einen Datensatz innerhalb der While-Schleife einlese. Wie könnte ich das herausfinden? Ich habe letztendlich das Demo-Programm hergenommen und dort lediglich den Lesezugriff mit einer While-Schleife modifiziert.

Hallo Ben,

Zitat:ich bin mir nicht sicher, ob ich wirklich nur einen Datensatz innerhalb der While-Schleife einlese. Wie könnte ich das herausfinden?

Wie sieht denn der empfangene String aus?
(Für Debugging-Zwecken kann man den ja auch unbearbeitet in eine Datei schreiben oder zuindest mit einer Sonde anschauen…)

(07.06.2021 08:16 )GerdW schrieb:  Hallo Ben,

Zitat:ich bin mir nicht sicher, ob ich wirklich nur einen Datensatz innerhalb der While-Schleife einlese. Wie könnte ich das herausfinden?

Wie sieht denn der empfangene String aus?
(Für Debugging-Zwecken kann man den ja auch unbearbeitet in eine Datei schreiben oder zuindest mit einer Sonde anschauen…)

Stringbeispiel:
A00001B00002C00003D00004E00005F00006G00007H00008I00009J00010

Mit den Buchstaben A bis J ordne ich die jeweilige 5-stellige Zahl (Messwert) zu, sprich damit ich weis welcher Messwert wo steht.



Ich habe bereits weitere Sachen herausgefunden, indem ich die Anzahl der Schleifendurchläufe mitzähle:
1) Teile ich einen festdefinierten String auf, ohne ihn tatsächlich über USB einzulesen, so schießt der Schleifenzähler in die Höhe. Genau das erwarte ich ja.
2) Füge ich in der Whileschleife ein "Schreibe in TDMS Datei" ein, so wird das Hochzählen des Schleifenzählers deutlich verlangsamt.
3) Lese ich einen String über USB ein, so steigt der Schleifenzähler recht langsam. Gefühlt um 1-3 Werte pro Sekunde nur noch.

Ich habe also zwei Probleme zu lösen.
- Das USB Einlesen muss deutlich schneller werden. Wie könnte ich das am Besten realisieren?
- Speichern darf nicht so viel Zeit in Anspruch nehmen. Wie könnte man hier am Besten vorgehen? Schieberegister?

Hallo Ben,

Zitat:Ich habe also zwei Probleme zu lösen.
- Das USB Einlesen muss deutlich schneller werden. Wie könnte ich das am Besten realisieren?

Hier ist nicht die Geschwindigkeit des "Einlesens" entscheidend, sondern "wie oft/schnell" sendet der Sender überhaupt Daten!?

Zitat:- Speichern darf nicht so viel Zeit in Anspruch nehmen. Wie könnte man hier am Besten vorgehen? Schieberegister?

Das Speichern von Einzelwerten ist so ziemlich das langsamste, was du machen kannst.
Das Speichern wird deutlich schneller (gerade auch bei TDMS), wenn du die Samples in etwas größere Blöcke zusammenfasst und dann speicherst. (TDMS muss noch Verwaltungsdaten zu deinen Samples hinzupacken!)
Außerdem kann dir eine Producer-Consumer-Struktur helfen, die Datenerfassung und Speicherung zu entkoppeln…

Zitat:Stringbeispiel:
A00001B00002C00003D00004E00005F00006G00007H00008I00009J00010
Mit den Buchstaben A bis J ordne ich die jeweilige 5-stellige Zahl (Messwert) zu, sprich damit ich weis welcher Messwert wo steht.

Wenn die Reihenfolge "A bis J" feststeht und sich nicht dynamisch ändern kann, wäre ein "normaler" String mit einfachem Trennzeichen (z.B. Tab oder Semikolon) deutlich einfacher zu verarbeiten!

Anzeige

(07.06.2021 10:46 )GerdW schrieb:  Hallo Ben,

Zitat:Ich habe also zwei Probleme zu lösen.
- Das USB Einlesen muss deutlich schneller werden. Wie könnte ich das am Besten realisieren?

Hier ist nicht die Geschwindigkeit des "Einlesens" entscheidend, sondern "wie oft/schnell" sendet der Sender überhaupt Daten!?

Zitat:- Speichern darf nicht so viel Zeit in Anspruch nehmen. Wie könnte man hier am Besten vorgehen? Schieberegister?

Das Speichern von Einzelwerten ist so ziemlich das langsamste, was du machen kannst.
Das Speichern wird deutlich schneller (gerade auch bei TDMS), wenn du die Samples in etwas größere Blöcke zusammenfasst und dann speicherst. (TDMS muss noch Verwaltungsdaten zu deinen Samples hinzupacken!)
Außerdem kann dir eine Producer-Consumer-Struktur helfen, die Datenerfassung und Speicherung zu entkoppeln…

Zitat:Stringbeispiel:
A00001B00002C00003D00004E00005F00006G00007H00008I00009J00010
Mit den Buchstaben A bis J ordne ich die jeweilige 5-stellige Zahl (Messwert) zu, sprich damit ich weis welcher Messwert wo steht.

Wenn die Reihenfolge "A bis J" feststeht und sich nicht dynamisch ändern kann, wäre ein "normaler" String mit einfachem Trennzeichen (z.B. Tab oder Semikolon) deutlich einfacher zu verarbeiten!

Der Sender soll jede ms ein Wertepaket zur Verfügung stellen. ICh grüble derzeit noch, wie ich das am einfachsten Prüfen kann, denn die Sendeleistung des FT232H (UM232H) müsste ja zum Ausschließen von Fehlern nachgewiesen werden. Hat hierfür jemand eine Idee?

Größere Blöcke zum Speichern klingt vernünftig. Da werde ich mich noch einmal ausführlich belesen, auch was Producer/Consumer betrifft. Danke.


Der Kollege hatte das sicherheitshalber so gemacht, dass der string eben immer gleich aussieht. Wie würde man denn einen String ohne Buchstaben dann zuweisen in Labview?

vielen Dank,
Ben

Hallo Ben,

Zitat:Der Kollege hatte das sicherheitshalber so gemacht, dass der string eben immer gleich aussieht. Wie würde man denn einen String ohne Buchstaben dann zuweisen in Labview?

Dein bisheriges Stringbeispiel sieht so aus:

Code:

A00001B00002C00003D00004E00005F00006G00007H00008I00009J00010

Ich würde dagegen so schreiben:

Code:

1;2;3;4;5;6;7;8;9;10<LF>

Vorteile:
- String nach Array of I32 einfach per SpreadsheetStringToArray
- Verzicht auf führende Nullen kann Übertragungsrate optimieren
- Alternativ auch gern <TAB> statt Semikolon, oder anderes TermChar (je nach Bedarf/Wunsch)

Zitat:Der Sender soll jede ms ein Wertepaket zur Verfügung stellen. ICh grüble derzeit noch, wie ich das am einfachsten Prüfen kann, denn die Sendeleistung des FT232H (UM232H) müsste ja zum Ausschließen von Fehlern nachgewiesen werden. Hat hierfür jemand eine Idee?

Einfach die empfangenen Strings direkt in eine Datei schreiben. Das ganze für 3-5 Sekunden laufen lassen, dann solltest du theoretisch 3000-5000 Strings empfangen haben…

Edit:
So in etwa:
   

(08.06.2021 08:23 )GerdW schrieb:  Hallo Ben,

Zitat:Der Sender soll jede ms ein Wertepaket zur Verfügung stellen. ICh grüble derzeit noch, wie ich das am einfachsten Prüfen kann, denn die Sendeleistung des FT232H (UM232H) müsste ja zum Ausschließen von Fehlern nachgewiesen werden. Hat hierfür jemand eine Idee?

Einfach die empfangenen Strings direkt in eine Datei schreiben. Das ganze für 3-5 Sekunden laufen lassen, dann solltest du theoretisch 3000-5000 Strings empfangen haben…

Und für so einen Versuch die Abfrage, wie viele Bytes gerade im Buffer liegen, mit in die While-Schleife reinziehen, nicht 1x davor abfragen. Das dürfte nämlich aktuell eine deiner Ursachen sein, wieso deine Datei nur so wenige Datensätze enthält.

Gruß, Jens

(08.06.2021 08:23 )GerdW schrieb:  Hallo Ben,

Zitat:Der Kollege hatte das sicherheitshalber so gemacht, dass der string eben immer gleich aussieht. Wie würde man denn einen String ohne Buchstaben dann zuweisen in Labview?

Dein bisheriges Stringbeispiel sieht so aus:

Code:

A00001B00002C00003D00004E00005F00006G00007H00008I00009J00010

Ich würde dagegen so schreiben:

Code:

1;2;3;4;5;6;7;8;9;10<LF>

Vorteile:
- String nach Array of I32 einfach per SpreadsheetStringToArray
- Verzicht auf führende Nullen kann Übertragungsrate optimieren
- Alternativ auch gern <TAB> statt Semikolon, oder anderes TermChar (je nach Bedarf/Wunsch)

Danke, diesen Tipp behalte ich mal im Hinterkopf.

Zitat:Und für so einen Versuch die Abfrage, wie viele Bytes gerade im Buffer liegen, mit in die While-Schleife reinziehen, nicht 1x davor abfragen. Das dürfte nämlich aktuell eine deiner Ursachen sein, wieso deine Datei nur so wenige Datensätze enthält.

Gruß, Jens

Vielen Dank, dieser Tipp hat mich auf die richtige Spur gebracht. Es lagen immer 4080 Bytes zur Abholung bereit, diese wurden dann komplett eingelesen. Mein String hat aber immer nur eine Länge von 61 Bytes. Ich habe nun die abhzuholenden Bytes auf 61 eingestellt und siehe da: Nun läuft die Schleife in 3 Sekunden ca. 3000x durch.

Ich habe dies auch wie beschrieben in eine Txt Datei gespeichert und erhalte dort die 3000 Strings. Perfekt!

Vielen Dank an alle für die Hilfe bis hierhin.

Nun muss ich mich noch um das Schreiben in eine TDMS Datei kümmern, damit ich meine Messwerte auf einem Diadem Report anwenden kann.
Die TDMS Datei erwartet ja dynamische Daten. Meine Überlegung war es, die einzelnen Werte zu bündeln und über einen indizierten Kanal aus der Schleife nach jedem Durchlauf raus zu geben. Leider passt das Datei-Format dann nicht mehr. Ich möchte das ganze natürlich auch etwas entkoppeln, damit die Schleifendurchläufe nicht so verlangsamt werden.
Wie würdet ihr hierzu vorgehen?

Viele Grüße,
Ben