Die Frage ist, ob einer der beiden Befehle "besser", schneller, stabiler ist als der andere? Oder ob aus Gründen, die ich (noch) nicht weiß, immer eine bestimmete Zugriffsart zu empfehlen ist?
ich finde, dass die erste Variante kompakter und daher angenehmer ist. Ich würde auch vermuten, dass das etwas schneller ist. Genauer kannst du das aber selbst herausfinden, indem du die benötigte Zeit mit tic/toc stoppst.
Verfasst am: 02.04.2013, 12:03
Titel: Re: set(handle) oder findobj(handle)
Hallo Robert,
Die direkte Verwendung "handles.Taste_StartSimulation" ist deutlich effizienter als die dynamische Suche per FINDOBJ. Erstens funktioniert ersteres auch, wenn der Handle "hidden" ist (das könnte aber auch FINDALL schaffen), aber das Durchsuchen aller Grafik-Objekte kann sehr zeitraubend sein, sobald einige Fenster offen sind, die auch Menüs, mehrere Subplots mit jeweils einigen Kurven, Kontext-Menüs, Legenden usw enthalten. Dann ist die Verzögerung eventuell schon spürbar.
Wenn FINDOBJ wirklich einmal nötig ist, sollte man die Anzahl der zu durchsuchenden Objekte unbedingt eingrenzen, z.B. nur die CHILDREN einer spezifizierten FIGURE durchsuchen, das 'flat'-Flag benutzen usw.
Also ein eindeutiges Votum für die direkte Verwendung des im handles-Struct gespeicherten Handles!
Bin noch nicht dazugekommen die Zeit mit tic/toc zu messen aber das werde ich jetzt auch nicht mehr machen, da deine Erklärung sehr einleuchtend ist.
Das hilft mir auch ein wenig mit einem anderen Problem weiter, die ganzen nicht benötigten "Tags" in den Handle-Eigenschaften rauszuwerfen.
Es passt jetzt zwar nicht direkt in den thread hier, aber da ich gerade überlege wie ich es löse, stelle ich mal eine weitere Frage.
Ich habe eine GUI programmiert und trotz ein paar Auslagerungen der Callbackfunctions ist die GUI ca. 6800 Zeilen lang und wird langsam unübersichtlich. (ist aber eigentlich fertig, also soll nicht noch größer werden). Dabei ist der eigentliche Berechnungscode gar nicht so viel, sondern den Hauptplatz brauchen die GUI-Objekte.
Fast jedes Graphikobjekt sieht so aus. (dass alles untereinander steht ist beabsichtigt, wegen der Übersichtlichkeit)
Zwar habe ich im Internet eine pdf ("Writing fast matlab code" von pascal getreuer) gefunden, in der ein kleiner Beitrag zu GUI-Verkleinerung drin steht.
Diese Vektorisierung der handles ist in meinem Fall aber nicht wirklich hilfreich. Da ich jedem handle einen eigenen Namen geben möchte um diese dann während der GUI-Benutzung zu verändern.
wenn du mehrere ähnliche GUI-Objekte hast, könntest du die Erstellung in eine Funktion auslagern und nur die Eigenschaften variieren, die tatsächlich unterschiedlich sind. Beispiel:
noch wichtiger als der Platz wäre mir die Strukturierung, die Übersichtlichkeit des Programms. Es ist ja schön, wenn man selbst nach einer Weile auch noch versteht, was man sich beim Aufbau eines Programms dachte - von anderen Leuten ganz zu schweigen.
Es ist generell ausgesprochen hilfreich, Nutzdaten, Berechnungen und das GUI strikt zu trennen, am besten sogar in unterschiedlichen Funktionen. Z.B. wird es anderfalls sehr umständlich, wenn man eine Berechnung nicht nur für die aktuell im GUI eingegebenen daten durchführen möchte, sondern für 10'000 verschiedene Start-Werte. Wenn die Berechnung dann in eine eigene funktion ausgelagert ist und die GUI nur zur Erstellung der Inputs dient, kann man das sehr einfach mit einer weiteres Funktion bewerkstelligen. Mit den Parametern oder Nutzdaten (je nach dem wie man es nennen möchte) ist es genauso: Statt z.B. die Gravitationsbeschleunigung g=9.81 überall hart in den Code zu schreiben, kann man das auch in eine eigene Funktion auslagern. Falls man dann später die gleiche Simulation auf dem Mond berechnen möchte, muss man nur an einer Stelle im Code etwas ändern, statt dutzende Male und dabei womöglich eine Stelle zu vergessen.
Generell ist die Verwendung nummerierter Namen eine schlechte Idee: Um auf "Gelenk1", "Gelenk2", ... dynamisch zugreifen zu können sind einige Verrenkungen nötig. Wenn man das Programm später auf 200 Gelenke erweitern möchte, wird dies mühselig und fehlerträchtig. Wenn man stattdessen "Gelenk(1)", "Gelenk(2)", ... benutzt, kann man das einfach in einer Schleife bearbeiten, Properties auch gleich für den gesamten Vektor setzen und das Erweitern auf 200 Objekte ist trivial.
Grundsätzlich sollten die Namen der Variablen nur die "Klasse" der Daten beschreiben, aber keine relevante Information tragen. Innerhalb von Matlab "wandern" sowieso alle Variablen in Lookup-Tabellen, die auf die entsprechenden Speicher-Plätze weisen. Dann wichtige Information wie den Laufindex im Namen der Variablen zu speichern ist indirekt und damit ineffizient und zwar sowohl was die Programmierarbeit als auch die Laufzeit betrifft.
Aus einem ähnlichen Grund trage ich auch nicht mein aktuelles Körpergewicht in meinem Namen, obwohl dies in seltenen Fällen ein Vorteil darstellen könnte.
erstmal entschuldigung, dass ich mich jetzt die ganze Zeit nicht mehr gemeldet habe. Bin vor ein paar Wochen zum zweiten mal Vater geworden und mit 2 Kids laufen die Sachen doch erheblich unorganisierter bzw. unvorhersehbarer als mit einem Kind. Bin teilweise gar nicht zum Lernen (auch Matlab) gekommen.
Habe zuerst meine GUI so umgeschrieben, dass alle Graphik-Handles über Funktionen erzeugt werden. So wie Harald es mir geraten hat. Danach war der Code doch viel weniger und übersichtlicher. Danke dafür!
Erst nach ein paar Tagen habe ich dann den Post von Jan gelesen (werde nicht durch E-Mail über neue Antworten im Thread informiert).
Dann ging das Spiel von vorne los. Erstmal eine Logik überlegen wie ich die Handles gut neu bennnen kann und dann wieder alles umschreiben. Auch dafür besten Dank!
Habe die Graphik-Handles alle als - handles.grafik.Name(i) - und die Berechnungs-Handels mit - handles.berechnung.Name(i) - benannt. Passt diese Methode der Unterscheidung so?
Die Graphik funktioniert echt gut aber ich habe jetzt echt Probleme mit meinem SimMechanics Modell.
Ich habe nur die Handles umbenannt und sonst nichts verändert. Durch meine GUI wird dann Simulink geöffnet und die in die GUI eingegebenen Parameter auch richtig an die jeweiligen SimMechanics-Blöcke (habe ein Modell erstell in dem alles "Null" ist und verändere es über die GUI) übergeben.
Wenn ich aber dann die Simulation starte, wird zwar gerechnet (ich bekomme auch Ergebnisse von Kraft- und Momentenverläufen in den Scope) aber die Visualisierung bleibt komplett aus. Es öffnet sich nur das Visualisierungsfenster jedeoch mit hellgrauem Hintergrund (nicht dieses blaugrau wie normal sondern helleres und matteres grau) und sonst ist nichts zu sehen. Aber sie gesagt die Uhr läuft und ich bekomme auch Ergebnisse.
Noch etwas, wenn ich direkt danach das alte Programm laufen lasse geht die Visualisierung auch nicht mehr. Erst wenn ich Matlab neu starte dann geht das alte Programm wieder aber das neue nach wie vor nicht.
Aber der Witz ist, dass es eigentlich kein neues Programm ist sondern nur die Handles umbenannt. Das einzig neue sind die Funktionen für die Graphik-Handles aber die GUI selbst funktioniert ja.
Also ab hier weiß ich grad echt nicht mehr weiter.
Ist es vielleicht ein Matlab Fehler? Evtl. noch wichtig, dass ich SimMechanics 1G benutze, da die 2G noch keinen inversen Methoden kann.
inzwischen habe ich noch etwas mehr herausgefunden.
Ich habe die Callback-Funktion für die Erstellung meines SimMechanics-Modells in eine eigenständige m-file geschrieben und die Handles, die ich normal in der GUI eingeben würde, per Hand mit Werten belegt.
Unglaublich aber jetzt klappt es mit der Visualisierung.
Nach etwas Herumexperimentieren ist etwas aufgefallen:
Es ist anscheinend egal wie ich die Handles, in denen der Dateipfad+Name der stl-Dateien als String drin steht, benenne.
Lasse ich nur die Funktion der Modellerstellung laufen, geht alles gut. Auch mehrfaches stoppen, schließen (ohne speichern) und starten ist ohne Probleme möglich.
Sobald ich aber:
1: die normale GUI starte und dort auch nur einen z.B. Puschbutton, der mit der Modellerstellung jedoch nichts zu tun hat (z.B. Graphiksteuerung zum Zeigen eines anderen Panels innerhalb der GUI) drücke
2: danach die GUI und deren m-file schließe
3: dann wieder die m-file zur Modellerstellung laufen lasse
-> habe ich wieder keine Visualisierung. Obwohl ich an der m-file nichts geändert habe.
Ich verstehe das wirklich nicht mehr! Wie kann denn das sein?
da ich nun vermute, dass mein Problem mehr mit Simulink (SimMechnics) und weniger mir der reinen GUI zu hat, versuche ich im Simulink-Unterforum Hilfe zu finden.
An dieser Stelle nochmal vielen Dank an Harald und Jan! Ich habe meine GUI gut verkleinern und die Handles übersichtlicher gestallten können.
Grüße,
Robert
Einstellungen und Berechtigungen
Du kannst Beiträge in dieses Forum schreiben. Du kannst auf Beiträge in diesem Forum antworten. Du kannst deine Beiträge in diesem Forum nicht bearbeiten. Du kannst deine Beiträge in diesem Forum nicht löschen. Du kannst an Umfragen in diesem Forum nicht mitmachen. Du kannst Dateien in diesem Forum posten Du kannst Dateien in diesem Forum herunterladen
MATLAB, Simulink, Stateflow, Handle Graphics, Real-Time Workshop, SimBiology, SimHydraulics, SimEvents, and xPC TargetBox are registered trademarks and The MathWorks, the L-shaped membrane logo, and Embedded MATLAB are trademarks of The MathWorks, Inc.
RSS