Blockdiagramm verschwindet beim freien Platz Schaffen.

Hallo LV-Forum,

ich habe einen Bug bei LV2012.
Wir haben zur Erfassung und Weiterleitung von Messwerten ein VI, welches aus einer Textdatei über ein Sub-Vi Werte einliest und diese in Globale Variablen schreibt.
Das Blockdiagramm dazu ist sehr groß. (Füllt in der Breite drei Monitore und kann meilenweit gescrollt werden)
Die Größe liegt daran, dass die Messwerte (etwa 1000 Stück) einzeln und großteils parallel abgefragt werden, damit wir eine Abfragerate von etwa 4 Hz halten können.

Wenn ich jetzt mit Strg + gedrückter linkter Maustaste etwas Platz schaffen will um neue Variablen einzupflegen, verschwindet das komplette Blockdiagramm.
D.h. ich sitze dann vor einem leerem Blockdiagramm (wie bei einem neuem VI) auch ohne Scrollbalken. Frontpanel ändert sich nicht.

Ist dieser Bug bekannt? Gibt es Lösungsvorschläge?
Kann das VI leider nicht posten.

Gruß,

Christian

Hallo Christian,

Zitat:Ist dieser Bug bekannt?

Ja.
EBKAC. Layer 8 Problem.

Zitat:Gibt es Lösungsvorschläge?

Blockdiagramm aufräumen.
SubVIs nutzen.
StyleGuide beachten.

Zitat:Die Größe liegt daran, dass die Messwerte (etwa 1000 Stück) einzeln und großteils parallel abgefragt werden, damit wir eine Abfragerate von etwa 4 Hz halten können.

Nein, das ist nicht der Grund für die BD-Größe.
Der Grund ist die grobe Missachtung des StyleGuides!
- Dinge, die parallel laufen, können problemlos in subVIs ausgeführt werden!
- Muss man wirklich ~1000 Messwerte einzeln abfragen?

Grund für den Fehler: Das BD ist zu groß. Bei einer Überschreitung gewisser Grenzen (32k Pixel Breite oder Höhe, oder waren es 16k?) kommt LabVIEW durcheinander.

Hallo Godfather,

bei einem VI, dessen Blockdiagramm 3 Monitore füllt sollte man sich in aller Regel schonmal darüber Gedanken machen. Zudem halte ich die von dir beschriebene Platzschaff-Funktion ohnehin für sehr bedenklich - man sollte sich zumindest genau überlegen, was sich in Strukturen dahinter verbirgt. Die Leitungsführung kann dabei nämlich derart verändert werden, dass später kein Mensch mehr durchsieht in deinem VI. Aber dieses Problem wirst du bei der beschriebenen BD-Größe wahrscheinlich sowieso haben.

noch ein Tip zu Sub-VIs:
Diese kann man in den Eiganschaften auf ablaufinvariant stellen, sodass sie auch "gleichzeitig" laufen können.



Gruß, Marko

Hallo Gerd,

grundsätzlich vielen Dank für deine Antwort.
Leider ist sie (wie so oft hier) darauf ausgelegt gehässig gegenüber dem Fragesteller zu sein.
Ich schätze eure Erfahrung sehr, würde mir aber ein professionelles Vorgehen wünschen.

Nun zur "Rechtfertigung" der angewandten Programmierung.

Punkt 1:
Das "Riesen-VI" existiert nunmal so seit einigen Jahren und wird von Versuch zu Versuch lediglich korrigiert/ergänzt.
Mir als jungem Mitarbeiter wurde nun die Aufgabe zu Teil in diesem (und anderen VIs) die neuen Messstellen einzupflegen (mehr als genug Arbeit).
Ich werde in der kurzen Zeit bis zum Versuch dieses VI nicht neu erfinden können. Die Neugestaltung kann ich lediglich als To-Do für die nächsten Versuche anregen.

Punkt 2:
Eben in der Rücksprache mit den Kollegen hat sich herausgestellt, dass bei der Erstellung des VIs geprüft wurde ob man nicht die Such-Strings Clustert und dann Cluster-Weise an die Auslese-VIs weitergibt. Jedoch führte dies zu schweren Performance Einbußen und die 4 Hz konnten nicht gehalten werden. Daher entschied man sich für die angewandte Architektur (Suchstring -> Auslese Sub-Vi -> Anzeige auf FP + Globale Variable).
Vorteil ist dabei auch, dass bei verwendeter Sortierung der Messstellen Ergänzungen und Änderungen schnell und leicht erledigt werden können.

----

Da es ja scheinbar ausser dem Austausch meiner nicht LabView-Würdigen Wenigkeit keine Lösung dieses Problems/Bugs gibt, muss ich schauen, wie ich auf dem vorhandenem Platz noch etwas in Handarbeit verschieben kann.
Daher nochmal Danke für die Antwort, dann brauche ich nicht weiter nach Lösungen suchen.

Wünsche trotz allem noch einen schönen Tag.

Gruß,
Christian

Hallo Christian,

das ist nicht "gehässig" gemeint!

Zitat:Nun zur "Rechtfertigung" der angewandten Programmierung.

Wenn du "Rechtfertigung" schon selbst in Anführungsstriche setzt, gibst du selbst zu, dass das Programm einfach nur schlecht programmiert ist.

Zitat:Das "Riesen-VI" existiert nunmal so seit einigen Jahren und wird von Versuch zu Versuch lediglich korrigiert/ergänzt.

Das ist der eigentliche Grund für den beschriebenen Fehler - und nicht das, was du oben angeführt hast.

Zu Punkt 2:
Auch hier liegt das Problem nicht unbedingt in der Nutzung von Clustern. Ich sehe nichts, was hier dein Programm auf <4Hz Looprate beschränken würde. Bei richtiger Wahl der Mittel kann man auch nach Namen schnell suchen lassen, ohne diese vorher sortieren zu müssen: RedBlackTree (ein netter Trick, seit 2006 offiziell dokumentiert)!
In meinen Programmen arbeite ich auch mit ähnlich vielen Werten, die teilweise noch zusätzlich eine Historie von Stunden speichern und mit hunderten parallelen Schleifen, die alle auf diese Werte zugreifen (können). Und mein PST läuft mit 10Hz Looprate mit Luft nach oben…

Zitat:Ich schätze eure Erfahrung sehr, würde mir aber ein professionelles Vorgehen wünschen.

Ich habe oben schon den "echten" Grund in der Meldung hinterlegt. Einfach mal den Text markieren…
Außerdem ist der Hinweis auf den LabVIEW-Styleguide, der in der LabVIEW-Hilfe nachzulesen ist (und das seit etlichen LV-Versionen), meiner Meinung nach sehr professionell. Im Gegensatz zu Leuten, die dies (ebenfalls seit Jahren) missachten und sich nun über Probleme wundern.

Zitat:Da es ja scheinbar ... keine Lösung dieses Problems/Bugs gibt

Die offizielle Lösung dieses Bugs habe ich oben genannt. Andere wirst du nicht zu hören bekommen, selbst dann nicht, wenn du den NI-Support dazu befragst!
NI empfiehlt, BDs auf eine "vernünftige" Größe zu beschränken. NI hat kein Interesse daran, die BD-Größenlimitierung aufzuheben. Wenn dich das ärgert, kannst du gern im LabVIEW Idea Exchange einen entsprechenden Vorschlag unterbreiten. Dann solltest du aber auf Kommentare ähnlich meinem vorbereitet sein und damit umgehen können, dass ein solcher Vorschlag von NI sehr schnell den Status "declined" bekommt…

Merke:
LabVIEW erlaubt es, schnell Programme zu erstellen - auch von Programmieranfängern.
Ebenso schnell erstellt man aber auch "schlechte" Programme, gerade bei Programmieranfängern.
Grundsätzliches Wissen zu "Programmierung" ist in jeder Programmiersprache nötig!

Und in einem Uni-Institut (vermute ich mal) dauernd ständig wechselnde Studenten mit der Programmierung eines Prüfstandes zu beauftragen, zeigt nicht viel Weitsicht des zuständigen Ingenieurs.

Hallo zusammen,

ich werde wie bereits gesagt anregen die Software-Teile zu ändern/neu aufzusetzen.
Sehe aber momentan wenig Möglichkeiten das zu entschlacken, da die meisten Werte nach der Abfrage und vor dem Speichern in der globalen Variable bearbeitet/benutzt werden.
So müssen Temperaturen von °C in K umgerechnet, über eine Kalibriertabelle (Je Sonde/Messstelle eine Tabelle) korrigiert, mittels Recoveryfaktor- und Dichtekorrektur (Tabellen hierfür auch je nach Messebene verschieden) angepasst und dann mit den passenden Werten arithmetisch oder flächengewichtet gemittelt werden.
Daher braucht jede Stelle, auch wenn man sie über Sub-Vis auslesen bzw. bearbeiten kann einen eigenen Eintrag. Auch das Aufteilen auf mehrere VIs hat wenig Sinn, da für die Temperaturkorrekturen z.B. die Drücke (statisch und total) benötigt werden.
Somit gibt es viele Kreuzverbindungen zwischen den einzelnen Messstellen. Und es muss sichergestellt werden, dass es keine Verwechslung der Eingangsdaten gibt (diese werden mit 4 Hz generiert).
Wir werden da mal überlegen was machbar ist. Wird aber eine große Baustelle.

Ich hoffe, dass ich euch die Problematik etwas darstellen konnte. Auch wenn das jetzt etwas in die Richtung geht.

Ich bin kein Student, sondern Doktorand/akademischer Mitarbeiter und übernehme wie jeder der in diesem Projekt sitzt einmal die etwas eintönige Aufgabe dieses VI zu pflegen. Es fand auch eine gute Übergabe statt und ich finde mich gut in dem VI zurecht. (Ist ja auch grundsätzlich simpel, aber halt sehr sehr oft simpel und deswegen groß.)
Bei einer durchschnittlichen Verweildauer von 4 Jahren ist es bei uns normal, dass man sich in fremde Programme reinfuchsen muss.

Hallo Godfather,

dies hier ist ein Forum für LabView, nicht zur Selektion bzw. Bewertung akademischer Grade. Wenn du in LabView als Neueinsteiger daherkommst, bist du auf diesem Gebiet eben genau so ein Neuling, wie ein Student im 1. Semester. Du wirst, was deine Arbeit außerhalb von LabView angeht sicher auf einer intellektuell höheren Ebene stehen als ein Student - das nützt dir in LabView aber mal gar NIX!

Wenn nun jeder bei euch im Hause dieses VI als gottgegeben hinnimmt und an der Struktur nichts verändert, dann sollte es dir als Doktor in spe ja nicht schwerfallen, zu extrapolieren, wo das wohl hinführen wird, wenn jeder etwas dranstrickt.

Ich kann deine Argumentation emotional nachvollziehen, die Tatsache, dass DU momentan wenig Möglichkeiten siehst, das VI zu entschlacken hat mit Sicherheit aber viel mit deinem LabView-Newbie-Status zu tun und wird auf längere Sicht dir und deinen Kollegen Probleme bereiten.


Zudem sei noch angemerkt, dass die Verwendung von immer demselben Quellcode in Kopieform (also nicht in SubVIs) die Fehleranfälligkeit / Unwartbarkeit signifikant erhöht!



Gruß, Marko

Danke Trinitatis für deine hilfreichen Worte.
Genau diese Bemerkungen wie deine Seitenhiebe Richtung Student/Doktorand meinte ich in meinem zweiten Beitrag mit "gehässig".
Dein Beitrag ist DAS Beispiel für die Sachen, die ich hier bemängel.
qed.

Es sind ja genügend Mods aktiv an diesem Thema dran. Dann könnt ihr uns doch alle erlösen und die beantworte Frage "Gibt es diesen Bug?" "Ja, Lösung wäre eine komplette Umstruktuierung des VIs" (Oha, ganz ohne Seitenhiebe formuliert!) schließen. Danke.

Hallo Christian,

Zitat:Genau diese Bemerkungen wie deine Seitenhiebe Richtung Student/Doktorand meinte ich in meinem zweiten Beitrag mit "gehässig".

Kannst du mir bitte sagen, was in Beitrag #2 "gehässig" war?
Die einzigen nicht vollkommen ernst gemeinten Worte habe ich extra mit einem Emotikon gekennzeichnet. Solche Emotikons dienen üblicherweise dazu, eben diese Emotionen klar auszudrücken, wenn dies durch den Text allein nicht klar erkennbar sein sollte…

Alles andere bewegt sich auf einer sachlichen Ebene!
Ich habe:
- die Ursache des Problems benannt
- mögliche (und für dein Problem die einzigen) Lösungen benannt
- den relevanten Eintrag in der LabVIEW-Hilfe benannt

Meine Vermutung, das hier ein Prüfstand an einer Uni für Probleme sorgt, war ja dann wohl auch nicht unbegründet. Ich spreche da aus Erfahrung.

Zitat:Dein Beitrag ist DAS Beispiel für die Sachen, die ich hier bemängel.

Auch bei Markos Beitrag kann ich keinerlei Gehässigkeit oder Überheblichkeit feststellen.
Anscheinend hast du ein anderes Verständnis davon, wie eine Forums-Kommunikation ablaufen sollte, als wir…