LabVIEWForum.de

Hallo zusammen,

ich bin absolute LabView Anfängerin und nun an meinem ersten Projekt dran.

Leider ist das richtige Programm völlig überladen, riesig und chaotisch, so dass ich euch nun den Teil, zu dem ich eine Frage habe, in einem Beispiel VI zusammengestellt habe.
Wer sich das andere Antun will, kann mir Bescheid geben, ich hab euch aber gewarnt, dass es absolut schrecklich und unübersichtlich und monströs riesig ist
(hab das Ding halt schon riesig von einem Studenten übernommen und ohne LabView Erfahrung immer mehr dazugepackt - und im Moment habe ich wichtiger zu tun, als den Code aufzuräumen....*schäm*)

Das Problem ist folgendes:
- die Visualisierung bei 1 Mhz braucht so viel Zeit, dass der Timed-Loop nicht mehr rechtzeitig fertig wird und somit der Regler nicht immer richtig arbeiten kann.
- in den ersten 20 Sekunden arbeitet das Programm gut, danach braucht es länger. Das tritt viel weniger auf, wenn die Visualisierung deaktiviert ist. Was mache ich ungeschickt?
- Nach längerem Laufenlassen des Programms gibt es LabViewMemory is full Meldungen. Woran könnte das liegen? (vermutlich nicht Visualisationsbedingt)

Versucht habe ich bereits folgendes:
- Wechsel von den eingebauten Grafikpanels zum Picture (Resultat: sehr grosse Zeitersparnis, aber immer noch nicht immer genug).
Wie man meine Lösung rechen effizienter gestalten?

- einen Zweiten Loop für diese nicht Zeit krischische Anwendung. Hab ich aber nicht hin bekommen, da der Hauptloop schon mit dem Regeln/Belohnungschecks, ect. die Zeit fast schon ganz aufbraucht, kommt das Programm nie in den niedrig priorisierten, zweiten Loop.
meine Idee: Earliest Deadline First Scheduling. aber wie macht man das in LabView??? Was kann man sonst noch machen?


Liebe Grüsse und schon mal vielen Dank fürs Weiterhelfen
Lina

zu den Anhängen:
- plot_beispiel ist das für euch erstellte Beispiel-VI (ich benutze LabView 2009)
- structure zeigt die Struktur des ganzen Programms
- frontpanel-ichtiges ist ein print-Screen des richtigen Frontpanels, damit ihr ungefähr seht, was geplottet werden soll
- full_memory ist die erwähnte Full-memory-Fehlermeldung (vermutlich eine plotunabhänige Baustelle)

1. Als erstes alle lokalen Variablen raus und stattdessen wenn nötig Shiftregister verwenden.
2. Was ist ein Grafikpanel und warum nicht ein XY- oder Polargraph?
3. Es sind 1 kHz und nicht 1 MHz
4. Plot aus der zeitgesteuerten Schleife raus in eine zweite, parallel zur zeitgesteuerten Schleife angeordneten Whileschliefe und die Daten paketweise per Queue übergeben. Zur Visualisierung langen 2-10 Hz.
5. Ab und an Daten löschen, sonst läuft schlicht und ergreifend der Speicher über und Labview stürzt ab.
6. Am besten das VI, welches die Regelung beinhaltet, in ein SubVI auslagern. Diesem kannst du dann per VI-Eigenschaften eine höhere Priorität verleihen. Das geht mit an sich nicht.

Hallo schrotti,

Herzlichen Dank fürs Anschauen und deine Antwort

zu:
1. oh Hilfe, das wird noch heiter . (ich hab das Programm von jemandem bekommen, der vorher nie LabView programmiert hat und alles über lokale Variabeln gelöst hat und ich hab das bei ihm so gesehen, auch keine Ahnung und drum auch so weitergemacht).
Da sind hunderte, lokaler Variablen drin.
Bringt das wirklich so viel, dass es nicht ratsam ist, die Variablen zu lassen? *mich irgendwie zu drücken versuch - mein VI ist nämlich wirklich sehr schlimm gross*, ich glaub echt nicht, dass ich das fehlerfrei schaffe, geschweige denn, dass nachher irgendjemand in dem Vi noch irgendetwas erkennt, wenn da überall Verkablungen sind.
(ist auch echt doof, dass ich die LabView-Einführung erst nächste Woche habe, obwohl ich nun schon seit September 2 x wöchentlich dran sitze)


2. einen x/y Graf hatte ich vorher. Der brauchte sehr viel mehr Rechenzeit als die jetzige Lösung mit Picture. (mir wurde gesagt, dass xy-Graphs in jedem Loop alles neu plotten, momentan füge ich pro Schleifendurchlauf jeweils einen Punkt dazu)

3. Da hast du vollkommen recht. Ich hab mich beim Schreiben vertan.

4. Hab ich versucht, aber irgendwie wurde die zweite Schleife nie aufgerufen, da ich halt die zeitkritische Schleife mit höherer Priorität ausstattete. War das Falsch? *notier, dass ich mich erkundigen muss, was überhaupt Queues sind*, hab halt im ersten Versuch lokale Variabeln verwendet.

5. *auch notier, dass ich mich dazu erkundigen soll*

6. wär wohl sinnvoll *nochmals seuftz* und *mich auch erkundigen werd, wie das geht*

Den allerletzen Satz "Das geht mit an sich nicht." verstehe ich nicht. Was meinst du genau?


Danke und liebe Grüsse
Lina

' schrieb:Da sind hunderte, lokaler Variablen drin.

Fang mit den Variablen an, die große Datenmengen beinhalten.

' schrieb:2. einen x/y Graf hatte ich vorher. Der brauchte sehr viel mehr Rechenzeit als die jetzige Lösung mit Picture. (mir wurde gesagt, dass xy-Graphs in jedem Loop alles neu plotten, momentan füge ich pro Schleifendurchlauf jeweils einen Punkt dazu)

Das ist richtig. Du könntest aber einfach darauf verzichten, jedes erfasste Datum sofort darzustellen. Der Mensch bekommts doch eh nicht mit, wenn du ihm tausend Bilder pro Sekunde zeigst. Mal davon abgesehen, dass kein normaler Monitor das mitmacht. Es langt, den Graphen 5 mal pro Sekunde zu zeichnen.

' schrieb:3. Da hast du vollkommen recht. Ich hab mich beim Schreiben vertan.

Kann passieren.

' schrieb:4. Hab ich versucht, aber irgendwie wurde die zweite Schleife nie aufgerufen, da ich halt die zeitkritische Schleife mit höherer Priorität ausstattete. War das Falsch? *notier, dass ich mich erkundigen muss, was überhaupt Queues sind*, hab halt im ersten Versuch lokale Variabeln verwendet.

Wenn die niederpriore Schleife keine Prozessorzeit zugewiesen bekommt, dann ist oft die höherpriore Schleife schlecht programmiert. Lässt sich da nichts machen, dann hilft ein zweiter Prozessor. In deinem Fall aber, da bin ich optimistisch, lässt sich einiges Verbessern.

' schrieb:6. wär wohl sinnvoll *nochmals seuftz* und *mich auch erkundigen werd, wie das geht

Macht schon deswegen Sinn, um die Daten von der Präsentation sauber zu trennen.

' schrieb:Den allerletzen Satz "Das geht mit an sich nicht." verstehe ich nicht. Was meinst du genau?
Danke und liebe Grüsse
Lina

Vergiss den Satz

Noch was: Warum läuft die Whileschleife mit maximaler Geschwindigkeit? Es ist doch klar, dass dann ein Prozessor maximal ausgelastet ist. Und warum eigentlich die Einzelpunkterfassung der Messwerte?

[attachment=30639]
Im Beispiel fehlt noch das Verknüpfen der Datenpakete in der Whileschleife.

Hallo

vielen Dank für das Umarbeiten des Beispiels, das hilft mir sehr weiter.
Mal schauen, ob ich es nun auch umsetzen kann.... (sonst meld ich mich wieder )

Zitat:Noch was: Warum läuft die Whileschleife mit maximaler Geschwindigkeit?

Das dürfte ein Tippfehler sein, laufen sollte die Schleife mit dem Regler bei 1 kHz und der ganze Rest des Codes darf langsamer sein.

Zitat:Fang mit den Variablen an, die große Datenmengen beinhalten.

Was ist besonders gross? Arrays vermutlich und dann? Datentypen mit vielen Bits, ... ?

Zitat:5. Ab und an Daten löschen, sonst läuft schlicht und ergreifend der Speicher über und Labview stürzt ab.

Ich schaffe es einfach nicht, herauszufinden, wie das geht. Gibts da einen speziellen Suchbegriff dafür? Wie heisst die Funktion in LabView, die das macht?


Liebe Grüsse
Lina

Großen Datenbeständen liegen immer als Arrays vor. Der Speicherverbrauch skalarer Typen kann bei heutigen Rechnern meist gänzlich vernachlässigt werden. Mit Daten löschen meine ich nicht, Speicher freizugeben, sondern bspw. bei einem Array nicht einfach neue Daten immer wieder hinten anzuhängen. Das Array wächst und wächst und irgendwann ist der physikalische Speicher weg oder das Programm wird unzulässig langsam, weil gigantische Datenmengen hin- und hergewälzt werden müssen. Es müssen daher irgendwann Werte des Array überschrieben werden. Zur dauerhaften Speicherung ist die Festplatte da. Wenn wir die Whileloop betrachten, in der die Visualisierung geschieht, dann wird das Problem, das großen Array verursachen, ersichtlich. Die Datenerfassung erzeugt 1000 Werte pro Sekunde, das macht also 8.000 Byte. Die Datenmenge wird verdoppelt, da wir x- und y-Position benötigen, also 16.000 Byte. Jetzt kommts darauf an, wie lang Daten vorgehalten werden sollen. Nach 1 Stunde sinds bereits 55 Megabyte. Soll der Regelvorgang über einen Zeitraum länger als sagen wir mal eine Minute visualisiert werden, muss überlegt werden, wie die Daten am besten reduziert werden können (Mittelwert etc). Frei nach dem Motto: "Der Anwender bemerkt den Unterschied eh nicht."