Hallo K2000,
Zitat:Du hast hier jetzt ein neues "Daten speichern" VI gebaut. in Diesem geht vorne ein Cluster rein. Also muss doch aus dem VI "Daten lesen" auch ein Cluster rausgehen, ansonsten kann ich die doch gar nicht verbinden. Und aus dem VI "Berechnung" muss doch auch ein Cluster rausgehen damit ich das mit dem "Daten speichern physikalische Werte" verbinden kann oder?
Ich habe kein neues VI gebaut - ich habe dein vorhandenes "aufgeräumt"…
Der Cluster war schon vorher vorhanden - und den habe ich nicht entfernt!
Zitat:Die Dateinamen sind möglicherweise umständlich aber ich komme so am besten zurecht.
Dann musst du aber jedesmal aufpassen, wenn du ein subVI kopierst und mit neuem Datum im Namen versiehst, dass auch alle anderen VIs sich dann auf die neue Kopie beziehen und nicht weiterhin die alte Kopie verwenden!
Keine mir bekannte Programmierumgebung unterstützt eine solche Arbeitsweise (IMHO aus gutem Grund).
Wie schon gesagt: verwende ein SCC-Tool oder wenigstens häufige Backups deines Projekts anstatt ständig Dateinamen zu ändern…
Zitat:Wollte dich nicht aufregen aber das habe ich wohl geschafft.
Ja,
eine gewisse Renitenz Unwillen, sich mit Grundlagen einer Programmierumgebung vertraut zu machen, verärgert mich…
Du kennst doch die Links in meiner Signatur nun schon eine ganze Weile, oder?
Hallo GerdW,
ok das mit den Dateinamen werde ich versuchen zu ändern.
ok du hast die Datei nur aufgeräumt, aber trotzdem geht ja der Cluster rein. Also muss "Daten lesen" einen Cluster ausgeben. Da liege ich doch richtig oder?
Hallo K2000,
Zitat:aber trotzdem geht ja der Cluster rein. Also muss "Daten lesen" einen Cluster ausgeben. Da liege ich doch richtig oder?
Ich wollte das MainVI soweit wie möglich "intakt" halten, habe also die I/O jedes subVIs nicht angetastet!
Ich würde entweder beim Array bleiben - oder durchgängig typdefinierte Cluster verwenden. (Oder je nach Anforderung auf eine Key-Value-Table umsteigen und die Messwerte anhand ihrer Benennung verwalten.)
Tipp zum Thema Messstellen-Benennung: habt ihr da eine einheitliche Vorgehensweise am Institut?
Wir verwenden z.B. an unseren Prüfständen ein Schema, wo dein "Tkoll_ein" eher "TbCOL_WF" heißen würde (
Temperature
before
COLlector in
Working
Fluid, physikalische Größe + Ortsbestimmung + Bauteilbezeichnung + gemessenes Medium). Muss man einmal einheitlich definieren und sorgt danach für gut zuzuordnende Messtellennamen - und bewirkt dann auch gleich gut dokumentierte Programme, wenn man auch dort dieses Namensschema umsetzt!
Du dagegen verwendest in deiner nicht mal großen Software 2 oder 3 verschiedene Namen für die gleiche Messstelle…
Hallo GerdW,
alles klar.
Du wirst dich vielleicht wundern aber die Geschichte mit dem Datum im Dateinamen ist Teil der Vorgehensweise an unserem Institut. Die genaue Benennung wie du sie hier jetzt vorschlägt ist bei uns mehr oder weniger so wie ich es gemacht habe. Habe noch nicht alles abgeglichen aber der Name für eine Messstelle ist bei uns T_Koll_ein oder T_koll_aus usw...
Trotzdem danke für den Vorschlag.
Hallo K2000,
Zitat:Du wirst dich vielleicht wundern aber die Geschichte mit dem Datum im Dateinamen ist Teil der Vorgehensweise an unserem Institut.
Wenn da noch mehr Kollegen programmieren und alle ihre Software über Datumsangaben in den Quelltext-Dateien versionieren, solltet ihr alle zusammen mal über ein zentrales SCC-Tool, gehostet auf eurem Instituts-Server, nachdenken!
(Tipp: TortoiseSVN ist kostenlos, sogar für kommerziellen Einsatz. Fragt mal die IT-Verwaltung eurer Uni.)
Hallo Leute,
mein Programm wird langsam größer und größer und ich weis nicht wie ich die Übersichtlichkeit des Blockdiagramms verbessern kann um bei Änderungen nicht so viel Arbeit zu haben. Wenn ich die Funktion "Diagramm aufräumen" wirft ihr mir hier und da was durcheinander. Ich weis, dass das Blockdiagramm zur Zeit wirklich sehr unordentlich aussieht und wahrscheinlich nur ich selber mich darin zurecht finde, aber vielleicht hat der ein oder andere ein Tipp damit diese ganzen Leitungen etwas sauberer verlegt werden.
[
attachment=61146]
Das geht ja noch, da gibt es Schlimmeres. Fürs "Diagramm aufräumen" ist es aber schon zu viel.
Du könntest Anzeige-Elemente, die zusammengehören, in deinem Cluster zusammenfassen (auch schon in den SubVIs), dann hast du nur Terminal, in das du etwas schreiben musst. Ähnlich bei deinen Eingaben. Beim manuellen Anordnen führe ich den Draht gerne "durch" das Terminal hindurch (bzw. verschiebe das Terminal auf den Draht), wenn der Wert noch an einer anderen Stelle verwendet wird, auch das hilft bei der Übersicht.
Gruß, Jens
Hallo jg,
also du meinst zum Beispiel alle Temperaturen die angezeigt werden in einen Cluster ? Kannst du mir ein ein Vi bzw. Screenshot schicken wie das aussehen soll. Bei der Sache mit dem Terminal weis ich nicht wirklich was du meinst. Meinst du mit Terminal den Knotenpunkt?
Hallo K2000,
Zitat:Kannst du mir ein ein Vi bzw. Screenshot schicken wie das aussehen soll. Bei der Sache mit dem Terminal weis ich nicht wirklich was du meinst. Meinst du mit Terminal den Knotenpunkt?
Beispiel:
[
attachment=61147]
Ein Terminal ist der Anschluß eines FP-Elements im Blockdiagramm…
Alle Inputs dieses subVIs gehören "logisch" zusammen und sollten deshalb in einem Cluster (auf dem FP) gebündelt werden.
Alle Outputs dieses subVIs gehören "logisch" zusammen und sollten deshalb in einem Cluster (im subVI) gebündelt werden.
Cluster übrigens immer typdefinieren und ihre Elemente mit sinnvollen Label versehen - dann kann man nämlich sehr schön mit (Un)BundleByName arbeiten!
Entwurf:
[
attachment=61148]
Dieses UnbundleByName macht man natürlich im subVI, so hat man nur noch einen Draht als Input statt vorher gleich 6!
Und bei den Outputs dann genauso: dein subVI gibt nur noch einen Cluster aus, den man dann auch als Cluster auf dem FP anzeigen lassen könnte. Und bei Bedarf dann mit UnbundleByName einzelne Werte davon auslesen…
Und wenn dein subVI dann wieder eine sinnvolle Anzahl IO-Anschlüsse hat, dann bitte meinen Hinweis vom 30.07. bzgl. des empfohlenen ConnectorPanes umsetzen!
Nachtrag:
Die zwei ExpressVIs zum Berechnen von P_therm und Wirkungsgrad sind doch (fast) nur Multiplikationen? Warum nimmst du stattdessen nicht einfach die CompoundArithmetic im Modus "Multiplikation"??? Eine winzige Node statt eines aufgeblähten ExpressVIs!