' schrieb:Ich glaub, ich hab Dir schonmal was dazu gesagt. Ein paar allgemeine Optimierungstips von mir:

1. Überleg Dir immer, was das Konstrukt da tut, das Du programmierst. z.B.: Wenn man eine While-Schleife mti einem "Stop if true"-Abbruchknoten, an dem eine True-Konstante angeschlossen ist, laufen lässt, läuft die genau einmal durch. i ist dann genau ein einziges mal 0 und wird nie eins. Ergo, eine Case-Struktur mit einem Case 0 und einem Case 1 wird auch immer nur den Case 0 ausführen. Was auch immer im Case 1 ist, wird nie stattfinden.
Edit: Noch ein Beispiel: Eine Zahl zu Quadrieren und hinterher die Wurzel daraus zu ziehen macht was: Genau, einen Absolutbetrag berechnen. Dazu gibt's auch ein eigenes VI zu, gleiche Palette wie Quadrat und Wurzel im übrigen...

' schrieb:2. Du hast in deinem VI Rampenfahrt im Prinzip eine Sequentielle berechnung (untere Sequenz), wo die tatsächliche Berechnung von den WErten einzelner Variablen abhängt. Das machst du mit sehr vielen True-False-Cases. Schon mal über einen Formelknoten nachgedacht, Cases mit mehr als True-False als Cases oder zumindest über eine kurze Textkommentierung?

' schrieb:3. Mach Dich mal mit dem Datenflussprinzip vertraut. Ich behaupte, dass du in dem Sub-VI keine einzige lokale Variable brauchst. Deine doch exzessive Verwendung macht zwar einen halbwegs aufgeräumten eindruck, neben den von Dir angesprochenen Race-Conditions dauert der Durchlauf aber länger und Du brauchst mehr Speicher. Da du da Sollpositionen für eine Regelung berechnest, würde mich die Durchlaufzeit ärgern.

' schrieb:4. Was dein konkretes Problem angeht: Mach den Schreibvorgang doch außerhalb der While-Schleife. LabVIEW kann an Schleifen automatisch Arrays aus den Einzelwerten pro Durchlauf bauen und die kannst du dann nach Abschluss der Schleife mit deinem Express-VI schreiben. Alternativ: Mach's ordentlich, vor der Schleife die Datei öffnen, in der Schleife nur schreiben und nach der Schleife wieder schließen. Im Express-VI ist ein Overhead, der die Laufzeit denke ich ziemlich verlängert. (Das ist ungefähr so, wenn du jeden morgen mit dem Fahrrad zur Arbeit fährst, vorher aber immer noch alle Staumeldungen hörst, Dir drei alternative Verbindungen mit dem ÖPNV raussuchst (weil das ja auch eine Möglichkeit wäre) und zwar jeden morgen.)

' schrieb:5. Hast Du mal drüber nachgedacht, ein Timing in Deinen Case 9 einzubauen? Zumindest die maximale Samplingrate Deiner Ausgabemodule würde ich mal vorsehen...

' schrieb:Die While-Schleife mit einem "Stop if true"-Abbruchknoten & angeschlossener True-Konstante ist hoffe nur ein weiteres Beispiel, oder habe ich dies irgendwo so verwendet? Falls ja muss ich gestehen finde ich diese Stelle nicht

' schrieb:Zum Thema Datenfluss ist leider wenig zu finden. Meine beiden Grundlagenbücher biete gesamt keine drei Seiten zum Thema, wirklich Tutorials sind im Netz so recht nicht zu finden und face-to-face hab ich leider niemanden der mir weiterhelfen kann.
In welcher Form muss ich mir das vorstellen, wenn du vermutest, dass lok. Variablen in meinem Sub-VI überflüssig sind?

' schrieb:Die Thematik muss ich mir noch mal genauer angucken. Wobei mir die Datenspeicherung eh noch Probleme bereitet, aber dazu gibt es von mir noch einen anderen Thread. Dein Beispiel fand ich sehr schön

' schrieb:Damit meinst du eine "Warten"-Fkt? Mit was für einer Wert?

' schrieb:So, kurz vor dem verfrühten Feierabend:
Doch, hast Du, hab zwar manchmal eine blühende Phantasie, aber so sehr...;)VI Rampenfahrt, untere Sequenz, Rahmen 0.

' schrieb:Also, ohne Dein VI so ganz genau angeschaut zu haben: Du hast verschiedene Berechnungen für eigentlich nur zwei oder vier Variablen, die du wieder ausgibst. Die Berechnungsmethode variiert je nach Wert von einzelnen Variablen. Das hast Du mit Case-Strukturen gelöst (was prinzipiell vielleicht nicht so geschickt, aber doch machbar ist). Was Du jetzt aber machst, ist in jeder Case Struktur alle Variablen, mit denen Du rechnest, per lokaler Variable zu lesen. Jeder andere hätte die Controls auf der linken seite des Blockdiagramms und dann von da mit Drähten in die Case-Strukturen gezogen. Das gibt die kleinen Knubbel am Rand und da kann man dann auf die Werte zugreifen. Da LabVIEW-Knoten immer dann abgearbeitet werden, wenn alle Eingänge mit Werten belegt sind, bekommt man damit auch keine Race-Conditions.
Beispiel aus dem Rampenfahrt-VI: In der oberen Sequenz berechnest Du in Rahmen 1 zwei Variablen, die von den Ergebnissen aus Rahmen 0 abhängen. Die Sequenz brauchst Du nicht, einfach die Ausgänge aus Rahmen 0 mit den Eingängen der Funktionen, die in Rahmen 1 sind verbinden. Spart insgesamt vier Frontpanelzugriffe (OK, auf RT-Targets nicht so wichtig, aber generell schon) und lässt das ganze auf jeden Fall sehr viel übersichtlicher aussehen.

' schrieb:Ja, NI sollte mal das Feature einführen, dass man Express-VIs erst dann verwenden darf, wenn man sich deren Blockdiagramm angesehen hat... Dann merkt man doch relativ schnell, dass die Dinger zwar fst alles können, aber das halt auch kostet. Und leider können Sie meist das nicht, was man gerade braucht. Da lob ich mir doch, mit Version 7 angefangen zu haben, wo's sowas noch nicht gab...

' schrieb:Ja, z.B. Ein Loop-Timer wäre noch besser, weiß aber nicht, ob das auf dem RT-Target unterstützt wird, ich kenns nur vom FPGA (hab aber auch kein RT). Wert wäre entweder von Dir zu bestimmen (wenn Du eine Update-Rate von 1 kHz haben willst, entsprechend 1ms, bei 50 kHz halt 20µs) oder ist Durch die Hardware vorgegeben: Wenn das Output-Modul nur z.B. 10 kHz kann, wird auch die Schleife maximal so schnell laufen (mal davon ausgehend, dass Du das ganze optimal aufgebaut hast und alle Prozesse parallel laufen. Atlernativ: Pipelining. Dazu weiß aber auch NI was.