Wenn dein Problem oder deine Frage geklärt worden ist, markiere den Beitrag als "Lösung",
indem du auf den "Lösung" Button rechts unter dem entsprechenden Beitrag klickst. Vielen Dank!
Guten Morgen zusammen,
über GerdW bin ich vom englischen zum deutschen LWF gekommen und er hatte angedeutet, dass meine Programmstruktur nicht gut ist.
Zur Situation: Meine Hardware besteht aus GPIB Netzteilen und einem DAQ Modul. Da ich mit so großen Programmen noch keine Erfahrung hatte, dachte ich mir ich packe alles in eine Sequenz.
<while>
1. GPIB Initialisierung und Start der Netzteile
2. Datenerfassung und Anzeige im FP
3. Manuelle Steuerung von Netzteilen über FP
4. PID Regler für TEC Steuerung
5. Daten speichern
</while>
Da Timing eher eine untergeordnete Rolle spielt und das so funktioniert war ja alles schön und gut. In jedem Schleifendurchlauf wird alles hintereinander abgearbeitet. Ich dachte bei ca. 30Jahre alter Hardware geht es so noch am ehesten.
Allerdings wäre der nächste Schritt gewesen am Ende der Sequenz noch eine Bilderfassung einer Webcam einzufügen und dann wird es schon ziemlich langsam.
Ich würde mich sehr freuen, wenn sich jemand mal mein VI anschauen würde und mir sagt wie es besser geht.
Auch: Wie mache ich mein VI schlanker im Bezug auf PC-Auslastung, meiner ist nämlich nicht mehr der jüngste (1GB RAM und P4).
Ich danke euch vielmals!
Gruß, Franz
PS: LV Version 2012
Anzeige
03.09.2014, 08:06 (Dieser Beitrag wurde zuletzt bearbeitet: 03.09.2014 08:08 von GerdW.)
Zur Programmstruktur: Was du da beschreibst, gehört in eine Statemachine!
Nicht umsonst bietet LabVIEW im Rechtklickmenü einer Sequenzstruktur das Umwandeln in eine Case-Struktur an - damit hättest du nämlich schon fast alles erledigt, um eine Statemachine zu erstellen!
Zitat:Allerdings wäre der nächste Schritt gewesen am Ende der Sequenz noch eine Bilderfassung einer Webcam einzufügen und dann wird es schon ziemlich langsam.
Das reduziert sich dann auf das Einpflegen eines neuen States in die Statemachine…
Zitat:Wie mache ich mein VI schlanker im Bezug auf PC-Auslastung, meiner ist nämlich nicht mehr der jüngste (1GB RAM und P4).
Kann man pauschal nicht beantworten.
Hantierst du mit großen Datenmengen? Lässt du Schleifen ungebremst laufen? Ist die verwendete Hardware (Webcam?) einfach zu resourcenhungrig?
(Nachtrag: Kann momentan nur LV2011 verwenden und daher deine VIs nicht anschauen.)
Gut, Danke für den Hinweis. Ich habe jetzt mal ein paar Tutorials zur Statemachine gelesen. Meine Herangehensweise ist jetzt:
1. Sequenz in Case umwandeln
2. Daten die zwischen Cases übergeben werden sollen in Cluster packen EDIT: sollte ich jetzt ganz auf lokale Variablen verzichten?
3. Cluster als Schieberegister
Fragen: Ich brauche das Enum nicht im FP, da die Reihenfolge während des Ablaufs nicht geändert werden soll. Deshalb lasse ich es als Konstante im BD und stelle es auf den "Init State", richtig?!
Wenn ich im FP ein Netzteil einstellen will, wie geht es am besten, dass er nicht erst wartet bis dieser State wieder aufgerufen wird, sondern das gleich der entsprechende "Steuerung-Netzteil State" aufgerufen wird?
Die Kamera ist eine USB-Webcam, die ich über das Vision-Express VI konfiguriert habe. Kann ich die Bilderfassung parallel zu der Statestruktur laufen lassen? Falls ein continous grab zu lahm wird, kann ich auch Einzelbilder jede Sekunde aufnehmen.
Danke!
(03.09.2014 08:26 )elhorst schrieb: 2. Daten die zwischen Cases übergeben werden sollen in Cluster packen EDIT: sollte ich jetzt ganz auf lokale Variablen verzichten?
Wenn es geht, ja. Muss aber nicht immer sein. Hängt auch vom Datentyp ab, da bei lokalen Variablen eine Kopie im Speicher angelegt wird. Bei großen Arrays also besonders schlecht.
(03.09.2014 08:26 )elhorst schrieb: Fragen: Ich brauche das Enum nicht im FP, da die Reihenfolge während des Ablaufs nicht geändert werden soll. Deshalb lasse ich es als Konstante im BD und stelle es auf den "Init State", richtig?!
Ja
(03.09.2014 08:26 )elhorst schrieb: Wenn ich im FP ein Netzteil einstellen will, wie geht es am besten, dass er nicht erst wartet bis dieser State wieder aufgerufen wird, sondern das gleich der entsprechende "Steuerung-Netzteil State" aufgerufen wird?
Habe mir dein Programm nicht angeschaut, kann dazu nichts sagen. Hört sich dann nach dem nächst-höheren Programmierschema an, z.B. Producer-Consumer oder Queue-driven State Machine (QSM)
(03.09.2014 08:26 )elhorst schrieb: Die Kamera ist eine USB-Webcam, die ich über das Vision-Express VI konfiguriert habe. Kann ich die Bilderfassung parallel zu der Statestruktur laufen lassen? Falls ein continous grab zu lahm wird, kann ich auch Einzelbilder jede Sekunde aufnehmen.
Autsch, relativ aktuelles Vision auf einem so schwachbrüstigen Rechner? LabVIEW alleine ist ja schon Speicher-hungrig...
Gruß, Jens
Wer die erhabene Weisheit der Mathematik tadelt, nährt sich von Verwirrung. (Leonardo da Vinci)
!! BITTE !! stellt mir keine Fragen über PM, dafür ist das Forum da - andere haben vielleicht auch Interesse an der Antwort!
(03.09.2014 08:42 )jg schrieb: Wenn es geht, ja. Muss aber nicht immer sein. Hängt auch vom Datentyp ab, da bei lokalen Variablen eine Kopie im Speicher angelegt wird. Bei großen Arrays also besonders schlecht.
Datentyp sind in 90% numerisch und der Rest boolsch (Buttons).
(03.09.2014 08:42 )jg schrieb: Autsch, relativ aktuelles Vision auf einem so schwachbrüstigen Rechner? LabVIEW alleine ist ja schon Speicher-hungrig...
Ok, ich probiers einfach. Das ist mehr ein "nice-to-have", damit ich nicht Fenster hin-und-her klicken muss.
Danke schonmal, ich setz mich mal an die Statemachine.
Wenn ich einen Case nur ausführen will, wenn ein Button gedrückt wird, sollte ich alle Controls des Cases in den Cases selbst packen oder außerhalb? Solange der Case nicht ausgeführt wird, sind die Eingaben ja egal, also kann ich die Controls in den Case stecken, oder verstehe ich das falsch?
gruß, Franz
Zitat:Wenn ich einen Case nur ausführen will, wenn ein Button gedrückt wird, sollte ich alle Controls des Cases in den Cases selbst packen oder außerhalb?
Allgemeine Frage, allgemeine Antwort: Das hängt von deinem Programm ab…
Wenn du eine Event-Struktur zum UI-Handling benutzt, wäre es vielleicht sinnvoller, alle Controls in dieser Eventstruktur zu verwalten.
Ansonsten musst du natürlich THINK DATAFLOW beachten und die Controls erst abfragen, wenn sie benötigt werden…
(03.09.2014 10:46 )GerdW schrieb: Hallo Franz,
Wenn du eine Event-Struktur zum UI-Handling benutzt, wäre es vielleicht sinnvoller, alle Controls in dieser Eventstruktur zu verwalten.
Nun gut, soweit bin ich noch nicht in die Tiefen des LV eingestiegen, da ich es für meine Anwendung noch nicht für nötig gehalten habe. Kann man eine pauschale Angabe machen, inwiefern sich der Einbau einer Event-Struktur lohnen würde?
Bis jetzt laufen die Cases nacheinander durch und wenn z.B. Case2 im FP nicht aktiviert wird, wird er eben übersprungen.
Mein VI soll im "Hintergrund" kontinuierlich Daten erfassen, anzeigen und speichern.
Wenn ich dann Netzteil1 sage gib mir 5V, soll es das tun und dann weiter durch die Schleife rattern. Beides parallel geht imo nicht, da die Hardware über GPIB kommuniziert.
Falls das zu viel Text ist oder unverständlich erscheint, sagt mir bitte Bescheid.
Gruß
Kleiner Tip am Rande: Der BD-Code ließe sich schlanker und übersichlticher machen (ohne dass das Programm deswegen effizienter wird). Am meisten fällt auf, dass Du nicht dahintergekommen scheinst, dass sich die Funktion "Array indizieren" nach unten hin aufziehen läßt, so dass man diese Funktion nicht vielfach als Tapetenmuster plazieren muss.
Weiterhin würde ich auf dem FP ausgiebig von Clusteren Gebrauch machen. Gegebenenfalls kann man die dann auf dem BD zur besseren Verarbeitung in Arrays umwandeln.
Hier mal ein ganz kleines Beispeil (Viel mehr lohnen würde es sich aber bei anderen Teilen des Programms).
