LabVIEWForum.de

Hallo Jungs,

es geht um ein VI zum nachträglichen Neuabtasten von TDMS-Datein. Ich wollte die "neuen" Abtastraten bewusst hart im Quellcode unterbringen, um ein Editieren von außen unmöglich zu machen - darum geht's garnicht, bloß eine präventive Rechtfertigung.

Heraus kam eine Case-Struktur mit ca. 50 Frames. Geht noch. Mit der Zeit dauerte das Zwischenspeichern immer länger, bis es richtig nervig wurde (ca. 30-60 Sekunden). Ab Case ca. 30 kam dann der unten beschriebene Fehler auf meinem normalen Entwicklungs-Laptop (WinVista ... ja ich weiß ...)

[attachment=40821]
[attachment=40822]

Dann das VI auf nen neuen Laptop mit Win7 64bit (LV2010 32 bit) gepackt und es ging wieder! Dauerte zwar, aber ging. Restliche 20 Cases fertig gemacht ... Speichern ... wieder selber Fehler, diesmal endgültig. Mass Compile vom Projekt lief durch aber ohne Effekt für das betroffene VI.

(Ich verabschiede mich jetzt von der großen Case Struktur und pack die Info in ne ini.) Was lerne ich jetzt aus der Geschichte? Je neuer das System, desto mehr Frames kann ich inner Case-Struktur unterbringen? Quatsch ...

[attachment=40823]

Edit: Hab jetzt gelesen das http://zone.ni.com/reference/en-XX/help/..._ad_aware/ soll/kann Abhilfe schaffen.


Gruß Dimitri

Hallo Dimitri,

- LV2011SP1 konnte dein VI auf einem älteren WinXP-Laptop mit 2GB RAM laden und in gefühlten 15s speichern (konvertieren und kompilieren eingeschlossen)

- du sagst leider nur die halbe Wahrheit: jeder viele deiner 50 Cases enthalten eine weitere Case-Struktur mit knapp 20 Cases! Dort könntest du viele entfernen, wie du es bei einigen "Haupt"-Cases schon getan hast, die nur eine Case-Struktur mit 2 Cases anthalten...
- selbst diese innere Case-Struktur ließe sich vereinfachen, indem man den TDMS-Speicher-Teil aus den Cases herausnimmt, da er (bei schnellem Durchschauen) immer identisch ist; der einzige Unterschied der (inneren) Cases scheint die Resample-Funktion zu sein...
- auch die "Haupt"-Cases enthalten viel gleichen Code, der nicht in den Cases enthalten sein muss...
- das ganze VI schreit nach dem Erstellen von subVIs für ständig gleiche Funktionalitäten...

Bei soviel dupliziertem Code (ohne Einsatz von subVIs) würde ich auch streiken

Zitat:Was lerne ich jetzt aus der Geschichte?

"Effizient" programmiert man nicht durch Copy & Paste
(Bzw. sollte man "Effizienz" dann genau definieren, da das Erstellen des VIs, abgesehen von den Unzulänglichkeiten der Programmierumgebung (wie dir ja aufgefallen ist), natürlich sehr schnell geht )

Dimitri, Schande über dich.
Alleine, dass du in der innersten Case-Struktur immer dasselbe machst (bis auf einen einzigen Parameter), das schreit schon nach einem SubVI.

Und bei einer Case-Strukur mit 50 Cases von geht noch zu sprechen...

Gruß, Jens

P.S. & Edit: Das von dir eingesetzte Resample-VI ist Reentrant, das erklärt die 1,9 MB -Dateigröße!

1) Die Memory Erweiterung hilft nicht.
2) Zu wenig präventive Rechtfertigung =)

Ja, viele Cases ließen sich zusammenfassen - natürlich. Wenn ich aber etwas vorbereite und dann beim Kunden in Betrieb nehme, will ich möglichst viele Freiheitsgrade zur Verfügung haben, deswegen hat jeder Kanal einen eigenen Case bekommen. Dass der Speicherbedarf eines VIs oder Quellcodes zu einem Problem werden kann, war mit nicht bewusst, ist mir bisher noch nie passiert. Jetzt weiß ichs besser.

Die neue Version des VI kommt ganz ohne Case-Struktur aus ... die Abtastraten kommen einfach alle aus ner ini.



Gruß Dimitri

Hallo dimitri,
noch ein paar Hinweise bezüglich den TDMS-Channel-Properties umshiften auf die neue Datei.
Die For-Schleife (Anhang 1) brauchst Du nicht. Es wird nur unnötig oft der TDMS Set Properties Baustein benutzt.
Einmal reicht ! (Anhang2). Wenn Du jetzt auch noch den Fehler den Du ausradiert wegbekommen möchtest, dann wie im Anhang 3.
Hintergrund: In den Properties befindet sich das Property "name" und dieses kann man nicht mit Set properties überschreiben.

Gruß
Ralf

Hallo Ralf,

ja, da hab ich auch noch selbst etwas erweitert:

[attachment=40865]

Nicht nur "name" darf nicht editiert werden, sondern auch einige andere die dynamisch von LV angelegt werden. Jetzt sortiere ich folgende aus:
"NI_ChannelLength", "NI_ChannelName", "NI_DataType", "NI_UnitDescription"
(Diese werden auch in der neuen TDMS automatisch angelegt.)

Was wirklich seltsam ist: wf_increment (also dt) wird zum Zeitpunkt der Datenerfassung automatisch angelegt. Mache ich jedoch das händische Resampling und hinterlege das neue dt im Signalverlauf-Datentyp, so fehlt die Eigenschaft gänzlich in der neuen TDMS-Datei.

[attachment=40867]

D.h. wf_increment lege ich explizit selbst an. Keine Ahnung warum das so ist, schließlich steht diese Info genauso zur Verfügung wie zum Zeitpunkt der Datenerfassung ...

(Der "Clear-Error" issn Überbleibsl.)

Gruß dimtiri