INFO: Dieses Forum nutzt Cookies...
Cookies sind für den Betrieb des Forums unverzichtbar. Mit der Nutzung des Forums erklärst Du dich damit einverstanden, dass wir Cookies verwenden.

Es wird in jedem Fall ein Cookie gesetzt um diesen Hinweis nicht mehr zu erhalten. Desweiteren setzen wir Google Adsense und Google Analytics ein.


Antwort schreiben 

Gutes LV Design bei großen Programmen



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!

03.09.2014, 08:00
Beitrag #1

elhorst Offline
LVF-Grünschnabel
*


Beiträge: 17
Registriert seit: Sep 2014

2012
-
DE_EN



Gutes LV Design bei großen Programmen
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

   


Angehängte Datei(en)
0.0 .zip  GRM_09_02_2014.zip (Größe: 461,7 KB / Downloads: 77)
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
Anzeige
03.09.2014, 08:06 (Dieser Beitrag wurde zuletzt bearbeitet: 03.09.2014 08:08 von GerdW.)
Beitrag #2

GerdW Offline
______________
LVF-Team

Beiträge: 16.471
Registriert seit: May 2009

11SP1, 17SP1 (ab und zu 20)
1995
DE_EN

10×××
Deutschland
RE: Gutes LV Design bei großen Programmen
Hallo Horst Franz,

herzlich willkommen im LVF!

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

Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
03.09.2014, 08:26 (Dieser Beitrag wurde zuletzt bearbeitet: 03.09.2014 08:28 von elhorst.)
Beitrag #3

elhorst Offline
LVF-Grünschnabel
*


Beiträge: 17
Registriert seit: Sep 2014

2012
-
DE_EN



RE: Gutes LV Design bei großen Programmen
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!
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
03.09.2014, 08:42
Beitrag #4

jg Offline
CLA & CLED
LVF-Team

Beiträge: 15.561
Registriert seit: Jun 2005

20xx / 8.x
1999
EN

Franken...
Deutschland
RE: Gutes LV Design bei großen Programmen
(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!

Einführende Links zu LabVIEW, s. GerdWs Signatur.
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
03.09.2014, 08:54
Beitrag #5

elhorst Offline
LVF-Grünschnabel
*


Beiträge: 17
Registriert seit: Sep 2014

2012
-
DE_EN



RE: Gutes LV Design bei großen Programmen
(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.
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
03.09.2014, 10:43
Beitrag #6

elhorst Offline
LVF-Grünschnabel
*


Beiträge: 17
Registriert seit: Sep 2014

2012
-
DE_EN



RE: Gutes LV Design bei großen Programmen
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
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
Anzeige
03.09.2014, 10:46
Beitrag #7

GerdW Offline
______________
LVF-Team

Beiträge: 16.471
Registriert seit: May 2009

11SP1, 17SP1 (ab und zu 20)
1995
DE_EN

10×××
Deutschland
RE: Gutes LV Design bei großen Programmen
Hallo 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…

Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
03.09.2014, 11:02
Beitrag #8

elhorst Offline
LVF-Grünschnabel
*


Beiträge: 17
Registriert seit: Sep 2014

2012
-
DE_EN



RE: Gutes LV Design bei großen Programmen
(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ß
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
03.09.2014, 11:32
Beitrag #9

GerdW Offline
______________
LVF-Team

Beiträge: 16.471
Registriert seit: May 2009

11SP1, 17SP1 (ab und zu 20)
1995
DE_EN

10×××
Deutschland
RE: Gutes LV Design bei großen Programmen
Hallo Franz,

Zitat:Kann man eine pauschale Angabe machen, inwiefern sich der Einbau einer Event-Struktur lohnen würde?
Pauschale Angabe: Man kann auf Polling verzichten und eben ereignisbasiert arbeiten…

Zitat:Mein VI soll im "Hintergrund" kontinuierlich Daten erfassen, anzeigen und speichern.
Das spricht für parallel arbeitende Schleifen…

Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
03.09.2014, 13:27 (Dieser Beitrag wurde zuletzt bearbeitet: 03.09.2014 13:35 von Lucki.)
Beitrag #10

Lucki Offline
Tech.Exp.2.Klasse
LVF-Team

Beiträge: 7.682
Registriert seit: Mar 2006

LV 2016-18 prof.
1995
DE

01108
Deutschland
RE: Gutes LV Design bei großen Programmen
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).

   
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
Antwort schreiben 


Möglicherweise verwandte Themen...
Themen Verfasser Antworten Views Letzter Beitrag
Question Testen von LabVIEW Programmen Sakis 1 1.424 16.04.2020 14:42
Letzter Beitrag: Freddy
  Änderung von großen Cluster (Type Def.) führt zu out of Memory exeption spacz 8 2.852 28.10.2019 09:01
Letzter Beitrag: spacz
  Ansprechendes Design des Frontpanels | Muster in Hintergrund einfügen dulfried 3 1.715 23.08.2017 17:45
Letzter Beitrag: GerdW
  Error Handling in einem Queue Message Design Architektur galilio 2 2.368 09.08.2016 12:20
Letzter Beitrag: galilio
  Queued Message Handler Design galilio 3 3.421 14.07.2016 15:34
Letzter Beitrag: Freddy
  Design Pattern für sequentiellen Verlauf galilio 6 2.391 23.02.2016 08:50
Letzter Beitrag: Freddy

Gehe zu: