Gutes LV Design bei großen Programmen

(03.09.2014 13:27 )Lucki schrieb:  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).

MIND=BLOWN!

Vielen Dank, ich habe im Anhang die Version als State-Machine, welche gefühlt langsamer läuft. Wenn jemand Lust und Zeit hat drüber zu schauen, würde ich mich über jeden Tipp sehr freuen.

Gruß, Franz-noob

(03.09.2014 13:54 )elhorst schrieb:  [...] ich habe im Anhang die Version als State-Machine, welche gefühlt langsamer läuft. Wenn jemand Lust und Zeit hat drüber zu schauen, würde ich mich über jeden Tipp sehr freuen.

Moin,

nach vielen Jahren des stillen mitlesens, haben mich die real existierenden Fortschritte in diesem Thread dazu gebracht auch meinen Senf dazu zu geben .... und mich endlich mal zu registrieren....

Ich habe gestern abend die VIs mal etwas aufgeräumt und ein paar kleine Fehlerchen beseitigt. Ergänzend noch ein paar Kommentare:

- Wenn Du in einer Schleife mithilfe von Schieberegistrern Werte an die nächsten Durchgänge übergibst, müssen sie natürlich in den verschiedenen Cases solange "durchgeleitet" werden, bis sie verwendet werden.

- Viele Sequenzen sind unnötig, wenn man daran denkt, dass bereits die ganz normalen Verbindungen für eine zeitliche Abhängigkeit sorgen. Hier kann auch der meistens vorhandene Erroranschluß zweckentfremdet werden.

- Es ist üblich dass Eingänge möglichst von links kommen und Ausgänge nach rechts weggehen. Das sorgt nicht nur für Übersichtlichkeit sondern vermeidet auch Fehler.

- Deine (gefühlte) Verzögerung liegt vermutlich an den 200ms Wartezeit pro Schleifendurchlauf. Wenn es dabei keine funktionalen Gründe (z.B. langsame Peripherie) gibt, kann auch darauf verzichtet werden. (Damit leere Labview-Schleifen nicht am Anschlag laufen, reicht bereits 1ms aus. Aber in Deinem Falle sind ja pro Durchgang mehrere Kommunikationskommandos mit entsprechendem Zeitbedarf vorhanden. Die Schleife wird also auch ohne Wartezeit schon gebremst.)

Hi! Vielen Dank dafür, vieles erscheint mir logisch. Ich habe nur ein paar Fragen:

(04.09.2014 11:09 )Nordvestlys schrieb:  Ich habe gestern abend die VIs mal etwas aufgeräumt und ein paar kleine Fehlerchen beseitigt. Ergänzend noch ein paar Kommentare:

- Wenn Du in einer Schleife mithilfe von Schieberegistrern Werte an die nächsten Durchgänge übergibst, müssen sie natürlich in den verschiedenen Cases solange "durchgeleitet" werden, bis sie verwendet werden.

Eigentlich muss ich garnicht unbedingt Daten durch die Schleife weiterleiten sondern nur durch die Cases. Sodass ich ich nach dem "DAQ" Case alles im "TDMS" Case speichern kann. Da ich auf lokale Variablen verzichten sollte habe ich es so gemacht. Aber eigentlich denke ich, dass es so falsch ist!?

(04.09.2014 11:09 )Nordvestlys schrieb:  - Viele Sequenzen sind unnötig, wenn man daran denkt, dass bereits die ganz normalen Verbindungen für eine zeitliche Abhängigkeit sorgen. Hier kann auch der meistens vorhandene Erroranschluß zweckentfremdet werden.

Ja, dass alles nacheinaner abläuft habe ich zwar gelesen, aber verstanden hatte ich es offensichtlich noch nicht.

(04.09.2014 11:09 )Nordvestlys schrieb:  - Es ist üblich dass Eingänge möglichst von links kommen und Ausgänge nach rechts weggehen. Das sorgt nicht nur für Übersichtlichkeit sondern vermeidet auch Fehler.

- Deine (gefühlte) Verzögerung liegt vermutlich an den 200ms Wartezeit pro Schleifendurchlauf. Wenn es dabei keine funktionalen Gründe (z.B. langsame Peripherie) gibt, kann auch darauf verzichtet werden. (Damit leere Labview-Schleifen nicht am Anschlag laufen, reicht bereits 1ms aus. Aber in Deinem Falle sind ja pro Durchgang mehrere Kommunikationskommandos mit entsprechendem Zeitbedarf vorhanden. Die Schleife wird also auch ohne Wartezeit schon gebremst.)

Danke fürs Aufräumen! Die 200ms hatte ich aber auch schon in der Version wo alles in einer Sequenz ablief...

- Hast du jedes Label manuell neben das Icon gesetzt oder gibt es da eine Einstellung "Label links statt oben"?
- Die Kommentarbox in den Cases ist auch manuell eingefügt oder kann man die aktivieren?

Viele Grüße,
Franz

(04.09.2014 12:52 )elhorst schrieb:  - Hast du jedes Label manuell neben das Icon gesetzt oder gibt es da eine Einstellung "Label links statt oben"?
- Die Kommentarbox in den Cases ist auch manuell eingefügt oder kann man die aktivieren?

Die Default-Position der Labels kann man in den LabVIEW-Optionen einstellen (siehe Bild).
Dasselbe gilt für die Kommentarbox (Subdiagram Label) in den Cases.

Gruss
Chris

(04.09.2014 12:52 )elhorst schrieb:  

(04.09.2014 11:09 )Nordvestlys schrieb:  [...]
- Wenn Du in einer Schleife mithilfe von Schieberegistrern Werte an die nächsten Durchgänge übergibst, müssen sie natürlich in den verschiedenen Cases solange "durchgeleitet" werden, bis sie verwendet werden.

Eigentlich muss ich garnicht unbedingt Daten durch die Schleife weiterleiten sondern nur durch die Cases. Sodass ich ich nach dem "DAQ" Case alles im "TDMS" Case speichern kann. Da ich auf lokale Variablen verzichten sollte habe ich es so gemacht. Aber eigentlich denke ich, dass es so falsch ist!?

Den TDMS-Case habe ich mal ganz frech weiter nach vorne gelegt und am Ende einen Case nur für die Entscheidung wo es weiter geht, eingefügt. Dadurch werden die Daten gleich in der nächsten Runde verwendet.
Beim unteren Schieberegister habe ich die Daten stattdessen "brav" durch jeden Case geführt.
Achtung wenn man beim Tunnel "Standardwert" auswählt, hat das nichts mit dem Schieberegister zu tun. (Sondern wird je nach Typ z.B. auf "Null" oder leerer String gesetzt wenn nichts angeschlossen ist.)

(04.09.2014 12:52 )elhorst schrieb:  

(04.09.2014 11:09 )Nordvestlys schrieb:  - Viele Sequenzen sind unnötig, wenn man daran denkt, dass bereits die ganz normalen Verbindungen für eine zeitliche Abhängigkeit sorgen. Hier kann auch der meistens vorhandene Erroranschluß zweckentfremdet werden.

Ja, dass alles nacheinaner abläuft habe ich zwar gelesen, aber verstanden hatte ich es offensichtlich noch nicht.

Vielleicht im Blockdiagramm oben mal auf die Glühlampe klicken. Dann kann man bei der Ausführung schön beobachten, wie die Daten "fließen"...

(04.09.2014 12:52 )elhorst schrieb:  [...]
- Hast du jedes Label manuell neben das Icon gesetzt oder gibt es da eine Einstellung "Label links statt oben"?

Es gibt eine globale Einstellmöglichkeit, in diesem Fall habe ich aber alles schnell von Hand verschoben.

(04.09.2014 12:52 )elhorst schrieb:  - Die Kommentarbox in den Cases ist auch manuell eingefügt oder kann man die aktivieren?

In den neueren LV-Versionen lässt sich das per Rechtsklick auf den Rahmen bei den "sichtbaren" Sachen auswählen. (Keine Ahnung wie das bei der deutschen Version genau heißt.)

(04.09.2014 13:24 )Nordvestlys schrieb:  Vielleicht im Blockdiagramm oben mal auf die Glühlampe klicken. Dann kann man bei der Ausführung schön beobachten, wie die Daten "fließen"...

Haha ja, die kenne ich schon, aber verstehen wollte ich es wohl nicht. Dafür leuchtet die Lampe über meinem Kopf mittlerweile umso heller.

Was allerdings noch nicht funktioniert ist meine Modbus-Kommunikation. Das funktionierende VI vom Hersteller sieht so aus wie im Anhang. Jetzt dachte ich packe ich das einfach so in meins, aber nee. Funktioniert nicht.
Da am Bus drei Geräte hängen habe ich eine "for=3" Schleife mit den jeweiligen Parametern (es ändert sich ja nur die Adresse). Wenn es der first-call ist wird vorher noch initialisiert...

Sollte ich die Frage in einen neuen Thread packen?
Gruß

Moin,

wie gesagt hatte ich nur "aufgeräumt" aber nicht überprüft, welchen Zweck die verschiedenen Unterprogramme eigentlich haben. Und bei den Modbus-Sachen fehlen auch einige Sub-VIs, so dass ich nur Fragezeichen als Platzhalter sehe.

Hier noch ein paar konkrete weitere Verbesserungsvorschläge:

1) Beim -Modbus-Init-Sub-VI das (bei meiner Version) links von der Hauptschleife liegt, den Errorausgang mit dem Schleifenrand verbinden. Auch wenn innerhalb der While-Schleife nichts daran angeschlossen wird, sorgt dieser kleine Trick dafür, dass die While-Schleife erst dann startet wenn der Init-Teil abgeschlossen wurde.
(Achtung, wenn am Error-Ausgang was angeschlossen ist, poppt im Fehlerfall nichts mehr auf. Ggf. müsste hier also noch was zur Fehlerbehandlung ergänzt werden.)

2) Im Case "Modbus" gibt es das SubVI "MODBUS ExampleV2". Hier würde ich das SubVi öffnen und so bearbeiten, dass alle Eingänge von links kommen und die Ausgänge nach rechts weggehen. (Rechtsklick auf das Piktogramm oben rechts im Frontpanel und die Anschlüsse neu "verdrahten".)
Ausserdem einen Eingangs-Fehler-Cluster aufs Frontpanel einfügen und die beiden Fehlercluster (Ein- und Ausgang) unten links und unten rechts anschliessen. (So wie bei fast allen SubVIs in Labview üblich)

3) Im Case Modbus anstelle 3-fach-For-Schleife 3x das SUBVI "MODBUS ExampleV2" einfügen. Durch die Verdrahtung mit den Error-Clustern kann man dafür sorgen, dass diese 3 Instanzen nacheinander aufgerufen werden. (Das lässt sich zwar auch über die VI-Eigenschaften realisieren, aber durch die Verdrahtung ist die Abfolge sichtbar und eindeutig festgelegt.)
Anstelle der "Mode-Leitung" (Bedienelement und lokale Variable braucht man jetzt ja nicht mehr) könntest Du "Cluster nach Namen bündeln" (ich hoffe das ist die korrekte dt. Bezeichnung) benutzen und den Modbus-Cluster dort am zweiten gelben Feld von links anschliessen. Das ist der Cluster-Eingang (siehe Hilfe). Dann die Höhe auf ein Element zusammenschieben und per Rechtsklick "Node Adress" wählen. Jetzt wird nur noch dieser eine Wert verändert und der Rest beibehalten.
Das ganze natürlich für jeden Sub-VI-Aufruf einmal.

4) Die sehr gute (Kontext-)Hilfe (Strg-H) benutzen und so mehr von den verschiedenen Möglichkeiten der LV-Funktionen lernen.

5) Probes (Sonden?) mit Rechtsklick auf Leitungen einfügen.

=> Dann solltest Du eigentlich relativ klar erkennen können an welcher Stelle die Modbus-Kommunikation hakt.

Grützi!
Danke nochmal an alle, ihr habt mir sehr geholfen. Jetzt funktioniert alles so wie ich es will. Fast alles:
Wenn ich 1D Array über build-array zusammensetze kommt ungefähr das raus:

A1 A2
B1 B2
C1 C2

Ich hätte es aber gern als A1 A2 B1 B2 C1 C2, damit das in "write tmds" auch ordentlich ankommt. Die Lösung ist sicher einfach, kann mir jemand auf die Sprünge helfen?

Schönes Wochenende,
Gruß Franz

Rechtsknick -> concatenate Inputs

Gruß, Jens

Grüßt euch,

eins noch: ich bekomme nur gut alle vier Sekunden einen Wert in meine TDMS geschrieben. Kann ich das mit einem schnelleren Rechner erhöhen oder liegt das an meinem Programmdesign? Wie wirkt sich das lesen und schreiben über GPIB aus?
Gruß, Franz