LabVIEWForum.de

Der eine oder andere, der schon mal ein VI von mir gesehen hat, wird sicher die Hände über dem Kopf zusammeschlagen.
Führ die Fahrt eines riemengetriebenen Linearschlittens hab ich, zumindest für mich, ein relativ brauchbares Resultat erreicht.
Arbeite mit einer CompactRIO 9073 & den Modulen 9401, 9263 - falls diese Info notwendig ist.
Natürlich mit einem Problem:
Der Schlitten läuft in der wichtigen Phase nicht ruckfrei.
Sofern ich aus dem Rahmen alles für die Fahrt "unnötige" (sprich Verlaufsdiagramm, Speicherung usw) entferne läuft das ganze. Natürlich kann ich auf diese Inhalte nicht verzichten.
Natürlich hab ich schon von Optimierungsregeln gehört und gelesen, kann sie aber oftmals entweder nicht nicht interpretieren oder nicht weiter auf mein Programm anwenden.
Explizit geht es in meinem Pogramm um den Case "Rampenfahrt" und dort um den 9. und damit letzten Rahmen.
Wäre super, wenn jemand reingucken und den einen oder anderen Tipp geben könnte, wär wirklich wichtig für mich.
Zu erkennen ist, dass die SOLL-Position, welche im Sub-VI errechnet wird "unrund" berechnet wird.
Wessen ich mir bewusst bin ist, die extrem hohe Verwendung von lok. Variablen im Sub-VI was Raceconditions nach sich zieht und hier sicher ein Problem darstellt, weiß aber so recht nicht, dies zu umgehen.
In den Rahmen davor klappt aber auch alles ruckfrei, deswegen ist mir nicht ganz klar, was falsch oder suboptimal ist.

Vielen Dank im Vorraus
JAN

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...

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?

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.

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.)

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...

ch

' 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...

Du hast natürlich völlig recht, dass quadrieren und Wurzel ziehen hätte ich mir sparen können mit der Verwendung der richtigen VIs.
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: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?

Ich muss ganz ehrlich gestehen, dass ich die Funktion der Formelknoten nicht kannte. Das ist eins meiner Probleme, dass ich mich zu selten auf unbekannten Funktionspaletten umschaue. Hätte mir natürlich viel Arbeit ersparrt und werde ich in Zukunft bei Gegebenheit verwenden.

' 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.

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: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.)

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: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...

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


Ich danke dir schon mal für deine Mühe, würde mich aber freuen, wenn du auf den einen oder anderen Punkt noch mal eingehen würdest.

Gruß JAN

So, kurz vor dem verfrühten Feierabend:

' 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

Doch, hast Du, hab zwar manchmal eine blühende Phantasie, aber so sehr...;)VI Rampenfahrt, untere Sequenz, Rahmen 0.

' 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?

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: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

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:Damit meinst du eine "Warten"-Fkt? Mit was für einer Wert?

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.

Viel Spaß,

ch

' 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.

Du hast recht.
Ich kanns mir nicht erklären und ich muss gestehen, ich weiß oft nicht genau, was bei LV abgeht, aber mit dieser Einstellung läuft das Programm wie es soll

' 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.

Danke für den super Tipp. Hab das Sub VI komplett überarbeitet.
Und deine Mutmaßung war richtig, ich habe inzwischen alle lok. Variablen und einiges an Cases rauswerfen können

' 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...

Ich muss sagen, hab die Dateispeicherung nach wie vor nicht wie gewollt hinbekommen. Die richtige Einstellung von "Datei öffnen/ schreiben/ schließen" gelingt mir nicht.
Im Endeffekt will ich für jeden neuen Durchgang des 9. Rahmens eine neue Datei, am liebsten mit vortlaufenden Nummern, die mir die Soll- & Istposition, eventuell die verstichene Zeit, als Tabdatei oder ähnliche speichert. klappt aber nicht

' 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.

Den Loop-Timer hab ich eingesetzt.
Das eigentliche Problem ist aber leider nicht behoben. Das ganze läuft subjekt gesehen etwas flüssiger, aber nicht mit dem gewünschten Resultat
Woran kann es noch liegen, wo sollte ich noch mal Hand anlegen?
Am Sub-Vi ist glaube nicht mehr wirklich was zu verbessern, am Hauptgrogramm weiß ich nicht wo ich ansetzen sollte.

HILFE


Hab das verbesserte SUB-Vi samt Host-VI noch mal angehängt...

Hi,

versuch doch mal, nicht in der While-Schleife zu schreiben, sondern die beiden Werte, die Du schreiben willst, erst aus der Schleife rauszuführen, Autoindexing aktivieren und dann nach Ende der Schleife erst die beiden entstehenden Arrays in eine Datei zu schreiben. Dann sparst Du dir die Datenzugriffe in der zeitkritischen Schleife.

ch

Ich hab leider keine Ahnung, wie das strukturiell aussehen muss.
Könntest du mir das vielleicht zeigen?
Welche while Schleife meinst du? Sicher die innere, oder?


Gruß Jan

Sofern ich die Datenspeicherung und das Verlaufsdiagramm rausnehme läuft das ganze einwandfrei.
Eine Auslagerung der Speicherung sollte eigentlich helfen. Wär für mich nur noch die Frage wie. Wär toll wenn jemand helfen könnte.
Was mach ich aber mit dem Diagramm? Es ist nicht zwingend erfoderlich, wär aber schon gut, wenn man die Fahrt als solche nachvollziehen könnte.

Nur noch ne Sache, die mich interessieren würde: könnte man die Datenspeicherung auch über das Target machen? Wenn ja wie und würde es überhaupt Sinn machen?

Jan

Autoindexing... Habs Dir mal als beispiel angehängt... Das Diagramm in der Schleife sollte m.E. die Laufzeit nicht allzusehr beeinflussen...

[attachment=24822]

Die Thematik der Autoindizierung hatte ich inzwischen gefunden.
Das Problem stellt derzeit eher die Speicherung an sich da.
Für dich sicher nichts großes, aber bekomme das nicht zum Laufen.
Das Express-VI "Messwerte" schreiben scheint nicht nutzbar zu sein, Datei öffnen/ schreiben/ schließen bekomme ich nicht "eingerichtet". Ich erhalte keine Datei im Verzeichnis.
Ich streube mich der Sache zu fragen, aber vielleicht kannst du mir das anhand meiner Datei zeigen?
Es soll aber keineswegs der Eindruck entstehen, dass ich meine Arbeit abgeben will.