Blockdiagrammcode als Bilddatei abspeichern

' schrieb:Aber man kann doch dann trotzdem einfach die Frage beantworten statt sich in pädagogisch-erzieherischen Attitüden auszutoben.

Das habe ich zuvor schon in Post #6 getan! Das es hier ein "LV-Speicher-ist-begrenzt"-Problem gibt, war dabei für mich in dieser Art nicht abzusehen!

Zitat:Und die Frage ist überhaupt nicht abwegig, wie dieses Szenario zeigt: Das VI ist schön auf einer Seite. Aber gerade das bringt es mit sich, daß man z.B. gestapelte statt nebeneinaderliegende Sequenzen verwendet hat. Auch ansonsten ist nicht alles sichtbar, z.B .bei den Cases. Um das alles in einem png- Bild sichtbar zu machen, gehe ich in zwei Schritten vor. Zuerst werden die nicht sichberen Teile als Bild auf die Leerfläche links oder rechts neben der Hauptschleife als PNG kopiert - das geht. Und dann wird von allem ein Schnappschuß gemacht - und dieses Bild ist natürlich größer als eine Bildschirmseite.

Trotzdem wird sich mir der Sinn solcher Aktionen, d.h. Ausdruck eines kompletten BD inkl. aller Cases + Sequenzen niemals auch nur im Ansatz erschließen! Zugegebenermaßen hatte auch ich schon mal Dozenten etc., die genau so etwas wollten. Zwar nicht in LV, sondern das war damals wohl irgendwas mit VB oder Assembler, aber glücklicherweiße ließen die sich überzeugen, dass hier eine Vorauswahl inkl. Kommentierung dieser Codefragmente weitaus übersichtlicher und nachvollziehbarer und damit für die Gesamtarbeit wesentlich zweckmäßiger sind! Es ist ja rein gar nichts dagegen zu sagen, besonders "trickreichen" oder "entscheidenden" Code-Abschnitten erhöhte Aufmerksamkeit zu widmen! Als Ergänzung dazu schreibe ich bei solchen Code-Abschnitten, die dann am besten als SubVI ausgeführt sind, einen schönen ergänzenden/erklärenden Text in das Hilfe/Documentation-Feld!

Naja, wie auch immer. Es kann ja jeder so machen, wie er mag! Für mich ist dieses Drops jetzt endgültig gelutscht! Ich wäre allerdings immens am fertigen Bild interessiert. Es wäre nett, wenn du's posten kannst/darfst/willst!

Gruß
Achim

Anzeige

' schrieb:Ich wäre allerdings immens am fertigen Bild interessiert. Es wäre nett, wenn du's posten kannst/darfst/willst!

Du meinst jetzt mich? Das BD posten wenn es als Bild abgespeichert wurde? (Was überings noch nicht geglückt ist)

Die Option nur Codefragmente zu erklären, kann ich mir ja noch offen halten.
Es geht in dieser Arbeit nicht darum das der Leser jedes Detail versteht. Sondern einen Überblick über die Arbeit bekommt.

Ist jetzt auch nicht so wild. Die Frage war ja, ob jemend einen Weg kennt diese Speicherbegrenzung zu vergrößern.

Ich frage mich aber, wenn ganze Prozessabläufe und Groß-Projekte mit LabVIEW realisiert werden, dann müssen auch diese Blockdiagramme groß und "unübersichtlich" werden. Ober wird das dann anders gemacht?



Stephan

' schrieb:Ich frage mich aber, wenn ganze Prozessabläufe und Groß-Projekte mit LabVIEW realisiert werden, dann müssen auch diese Blockdiagramme groß und "unübersichtlich" werden.

Da unterliegst du aber einem sehr großen Irrtum!

Zitat:Ober wird das dann anders gemacht?

Unterprogrammtechnik?

Das kann man so weit treiben, dass jedes Unterprogramm aus lediglich z.B. 5 (fünf!) Elementen besteht. Und sei es, dass diese Elemente selbst wieder Unterprogramme sind. Unterprogramme kann man sehr, sehr, sehr tief verschachteln. In die Breite geht nur sehr breit.

' schrieb:Aber wird das dann anders gemacht?

Unterprogrammtechnick ist natürlich das Wichtigste, aber man sieht hier im Forum manchmal riesengroße oft VIs von Anfängen, die förmlich danach schreien, daß ähnliche Strukturen zu Clusteren oder Arrays zusammengefasst werden, die dann viel effektiver, platzsparender und übersichtlicher behandelt werden könnten.
Lange Rede kurzer Sinn: Für die Übersichtlichkeit eines VI sind Arrays und Cluster fast genau so wichtig wie Unterprogramme. Viele Funktionen - mehr als man denkt - sind übrigens polymorph und können mit diesen Datentypen genau so selbstverständlich umgehen wie mit Einzelwerten. Man entdeckt da immer wieder Neues.

Was mich hier im LFV aber besonders ärgert: Ein ganz einfaches Programm wird wirr und unübersichtlich auf mehreren Bildschirmseiten ausgebreitet, obwohl es (auch ohne Unterprogramme) auf viel weniger als einer Seite Platz hätte. Dies Leute machen sich nicht die 5 Minuten Arbeit, das VI etwas zu ordnen, wollen aber, daß man sich dann 30 min (+X wegen der unübersichtlichen Darstellung) mit dem VI beschäftigt.
Ein beliebte Methode ist auch, Eingänge von der Verdrahtungsrichtung so anzuschließen, als seien es Ausgänge, und umgekehrt. Der Platzspareffekt hält sich - wenn überhaupt - sehr in Grenzen, der Verwirreffekt hingegen ist total und real.

' schrieb:Du meinst jetzt mich? Das BD posten wenn es als Bild abgespeichert wurde? (Was überings noch nicht geglückt ist wink.gif )

Ich denke nicht das das geht. Windows hat selbst bestimmte Beschränkungen wie gross eine Bitmap werden darf. Und diese Beschränkungen sind effektiv noch wesentlich kleiner dann das Bitmap Format selber schon maximal unterstützen kann. Andere Formate (z.B. JPG, TIFF) können auch mit grösseren Bitmaps umgehen, aber das Standard Clipboard Format ist halt eine Windows BMP Bitmap.
Kannst ja versuchshalber einen Mac kaufen und LabVIEW darauf installieren. Die Chance steht nicht schlecht, dass Du da Deine Riesentapete ausdrucken kannst. Habs selber aber noch nie versucht da meine VIs nie mehr als einen Bildschirm gross werden und seit ich einen 22"Widescreen LCD Zweit-Monitor verwende sogar wesentlich kleiner als das.

Zitat:Ich frage mich aber, wenn ganze Prozessabläufe und Groß-Projekte mit LabVIEW realisiert werden, dann müssen auch diese

In dem man sinnvoll und viel SubVIs macht. Dabei ist aber sinnvoll sehr wichtig. Also man denkt zuerst bevor man programmiert und schon hat man eine Idee aus was für Unterteilen das Programm bestehen soll. Diese verfeinert man dann nach und nach und schreibt SubVIs wannimmer man irgendeine Operation hat die sich sinnvoll in eine Black Box auslagern lässt. Black Box deshalb weil man versuchen sollte subVIs so zu schreiben, dass man mit der Connector Pane und einer Beschreibung auskommen kann, ohne die spezifische Implementation selber jeweils nachsehen zu müssen.

Wenn Du jetzt sagst "Aber das ist alles viel Aufwand für wenig" dann liegst Du falsch. Jeder Aufwand den Du vor und während dem Programmieren machst um das Programm übersichtlicher und einfacher zu machen, zahlt sich auf Dauer 10fach und mehr aus. Stell Dir vor Du musst in einem Jahr Dein Riesendiagramm anpassen um aus Deiner Semesterarbeit eine Diplomarbeit zu machen. Dann ist die Chance sehr gross, dass nicht einmal Du mehr durchblickst und eine komplette Neuerstellung des Programms einfacher und schneller ist, dann das alte Programm das wahrscheinlich eher durch Zufall meistens korrekt läuft, zu verbessern zu versuchen.

Meine Programme umfassen in den kleineren Applikationen schnell mal 300 VIs, wobei hier kleinere Applikation wohl auch noch relativ ist. Grössere Applikationen kommen regelmässig bei 800 bis 1000 VIs zurecht. Und nein die werden natürlich nicht jedesmal alle von Grund auf neu programmiert. Nach über 10 Jahren hat man sich eine Library von Funktionen zugeeignet, teils selbst geschrieben aber ich verwende auch regelmässig Toolkits (von NI und anderen) und auch Open Source Libraries wie etwa von OpenG.

Rolf Kalbermatter

Hi Lucki

' schrieb:Was mich hier im LFV aber besonders ärgert:

Ach Gott, was willst mach'.
Ich bin da wiedermal extremer Meinung. Da ist einer, der keine Ahnung hat - woher auch! - und soll nun plötzlich mit einer Programmiersprache arbeiten. Wer intuitiv alle Striche gerade von links nach rechts zieht und die Symbole im Raster anordnet, der ist auch eher in der Lage, seine Probleme intuitiv selbst zu lösen. So ein BD sieht du eben nicht. Dazu gibt es nämlich keine Fragen. Ich ärger mich schon lange nicht mehr, auch in meinen Delphi-Forum, da gibt es nämlich genau den gleichen Fragentyp mit genau den gleichen "Styleguide".

' schrieb:Lange Rede kurzer Sinn:

Natürlich hast du Recht. Optimierungsmöglichkeiten (respektive Styleguide-gerechtes Layout) gibt es viele. Kein Zweifel. Nur: Wie das in einem Forum vermitteln. Ich bin der Meinung für so allgemeine Fragen wie "Wie wird das gemacht" ist ein Forum weniger geeignet. Wie soll man einem, der neu in der Materie ist, einen so allgemeinen Sachverhalt per Prosatext erklären. Allgemeine Sachen wie diese hier lernt man am besten in einer realen Gruppe, in der eine Frage innerhalb einen halben Sekunde beantwortet werden kann. In einem Forum - bei Chatrum (kleines Wortspiel, tschuldigung) liegt die Sache etwas anderes - muss man mit einer Reaktionszeit von Stunden rechnen. Da kann man keine großen Erklärungen machen. Das einzige, was gehen würde: Stichpunkt in den Raum werfen und sagen: "Mach dich schlau".

Anzeige

Siehe hier Tipp No.1

Hallo,
wird jetzt bisle Offtopic.
jetzt haut doch net alle auf den armen Kerle ein. Ich kann ihn verstehen. Hab grad auch mein erstes LabVIEW Programm gemacht und das Blockdiagramm ist riesig geworden, aber das soll sich dann in der Endversion noch ändern, ist jetzt halt mal für die Testphase. Am Anfang kennt man halt die Tricks noch nicht, und es kommt immer mehr dazu, da bläht sich das dann schnell auf. Allerdings würde, bzw. werde ich, es noch zusammenfassen und verkleinern, auch wenn ich denke, dass es nachher nicht auf einen Bilschirm passt, weil ich über 100 Anzeigenelemente werte zuweisen muss. Andererseits ist es halt auch manchmal so, dass man eine Arbeit abgeben muss, da ist es dann gut wenn das Programm läuft, und man hat wichtigere Dinge (schreiben) zu tun, als das Blockdiagramm zu optimieren.
Allerdings stellt sich dann die Frage, ob es dann wirklich sinnvoll ist das Blockdiagramm abzudrcken. Eventuell im Anhang, aber dann zählt es ja nimmer zu den Seitenzahlen ;-)
MfG Jeffrey

' schrieb:weil ich über 100 Anzeigenelemente werte zuweisen muss.

Nur ein Stichwort: Cluster

Mal wieder zurück zur ursprünglichen Frage, hier die Methode aus der Computer Steinzeit, die aber immer noch funktioniert:
Strg+A (alles markieren), Strg+C und dann mit Strg+V in ein beliebiges Bildbearbeitungsprogramm kopieren.
Das kopiert auch die Teile, die ausserhalb des Bildschirms liegen, nicht sichtbare Cases/Frames natürlich nicht

Viel Spaß,
Günther