Suche nach Rat: Bedatung von Constant Blöcken

WICHTIG: Der Betrieb von goMatlab.de wird privat finanziert fortgesetzt. - Mehr Infos...

Partner:

Forum

Option

[Erweitert]

• Diese Seite per Mail weiterempfehlen

Gehe zu:

stealth_mx

Forum-Fortgeschrittener


	Beiträge: 94

	Anmeldedatum: 15.06.13

	Wohnort: ---

	Version: 2013b

Verfasst am: 21.01.2015, 09:28 Titel: Suche nach Rat: Bedatung von Constant Blöcken

Hallo zusammen,

ich habe ein eine Simulation aufgebaut in der ich ausgehend von meinen parametrierten Constant Blöcken eine gewisse Systemreaktion erhalte.

Diese Constant Blöcke möchte ich in einer GUI parametrieren können. Es sind etwa insgesamt an die 200 Constant Blöcke.

All diese Constant Blöcke befinden sich in einem Subsystem so, dass ich genau weiß wo ich suchen muss. Ich habe intern nur noch einen Datenbus angelegt der Sie auf die richtigen internen Subsysteme führt. Sonst ist in dem Subsystem nichts.

Natürlich könnte ich all die Constant Blöcke in einem Struct anlegen und einfach durch die GUI parametrieren (Weil ich ja die Namen dann genau wüsste). Wenn ich aber in meinem Simulinkmodell ein Constant Block hinzufüge, muss ich dieses auch wieder in den Struct schreiben. Was natürlich nicht Sinn und Zweck der Sache ist.

Wenn ich mit dem Durchsuchen arbeite, habe ich immer die aktuellsten Constantsätze und die Komplexität des Codes steigt nicht. Wie schon oben erwähnt müsste ich nur eine Art Filter haben der mir alle Namen (für die spätere Bedatung relevant) der Constants liefert.

Habt ihr da ein anderen Vorschlag oder eine andere Vorgehensweise? Bin für alle Vorschläge offen.

Viele Grüße

stealth

Andreas Goser

Forum-Meister


	Beiträge: 3.654

	Anmeldedatum: 04.12.08

	Wohnort: Ismaning

	Version: 1.0

Verfasst am: 21.01.2015, 10:45 Titel:

Ich bin sehr interessiert zu erfahren welche sinnvolle Applikation so etwas braucht, aber wenn ich das mal so hinnehme würde ich es mit find_system und set_param / get_param lösen.

Gerne helfe ich bei Unklarheiten zur Syntax falls nötig.

Andreas

stealth_mx

Themenstarter

Forum-Fortgeschrittener


	Beiträge: 94

	Anmeldedatum: 15.06.13

	Wohnort: ---

	Version: 2013b

Verfasst am: 21.01.2015, 14:34 Titel:

Hallo,

ja die Applikation/Simulation hat durchaus ihren Sinn.

In einem Simulinkmodell bilde ich einen Controller ab. Damit ist es quasi der Kern meiner Anwendung. Man kann es wie eine Blackbox sehen. Ich stimuliere das System mit verschiedenen Schwellen, verschiedenen Parametern und intern Timings. Nach der Simulation, die etwa 10sec dauert bekomme die entsprechende Systemreaktion. Die kann dann weiter verarbeitet werden. Ich greife in das System während der Simulation nicht ein. D.h. ich bedate wirklich alles vor dem Start. Insgesamt ist es im Grunde ein sehr einfaches Modell mit einer komplexen internen Logik.
Wären da nicht die ganzen Inputs.

Die Befehle zum Setzen etc sind mir bekannt, bis jetzt bedate ich sie auch so (z.B. aus Excel dort habe ich mir Tabellen angelegt mit den Namen und passenden Werten).

Jetzt wollte ich ein paar Ideen sammeln, ob es überhaupt sinnvoll ist alles so zu gestalten.

Ich möchte all diese Inputs dem Benutzer zum Parameterieren zur Verfügung stellen. So dass er sich mit dem eigentlichen Simulink File nicht auseinandersetzen muss. Ich muss also eine Schnittstelle schreiben die mein Modell mit der GUI bindet. Leider habe ich noch keine große Erfahrung mit den Schnittstellen und deswegen fallen mir spontan nur die beiden Lösungswege ein. Entweder ich habe ein Struct/Excel/Datenbank (Mit all den Namen damit ich mir in der GUI die ganzen Textboxen/Editboxen generieren kann) oder ich durchsuche das Modell nach den Constant Blöcken und generiere demnach die Eingabefelder der Parameter. Anschließend kann ich vor dem Systemstart über set_param alles setzen.

Grüße

stealth

Das ist im wesentlichen das Problem

Andreas Goser

Forum-Meister


	Beiträge: 3.654

	Anmeldedatum: 04.12.08

	Wohnort: Ismaning

	Version: 1.0

Verfasst am: 21.01.2015, 16:23 Titel:

Alles klar. Parameterstudien sind natürlich eine weit verbreitete Applikation. Aber was ich so kenne sind Veränderungen von weniger Parametern (<10) und dies in den meisten Fällen innerhalb eines Übertragungsgliedes, Verstärkungsfaktoren, etc. und nicht eines Eingangs. Aber es ist schon OK, eine absolute "legitime" Applikation.

Wichtige Fragen zur Umsetzung: Es soll also nichts während der Laufzeit verändert werden und Codegenerierung ist auch kein Thema?

Ich würde es durch Workspace-Variablen umsetzen. Der Const Block liest diese einfach aus dem Base workspace aus.

Andreas

stealth_mx

Themenstarter

Forum-Fortgeschrittener


	Beiträge: 94

	Anmeldedatum: 15.06.13

	Wohnort: ---

	Version: 2013b

Verfasst am: 21.01.2015, 17:13 Titel:

Hallo,

Ja unter den Parametern sind eine Menge Timings. Bewertungszeiträume z.B.. Das ganze ist mehrfach verschachtelt und das macht die Sache dann für den Menschen "zu komplex" bzw ist mir viel Schreibaufwand verbunden, wenn man sich die Reaktion mit der Hand herleiten möchte. Deswegen das Modell. Aber wirklich variable Eingansgrößen gibt es ca 10 Stück. Der Rest bleibt in der Regel konstant. Trotzdem muss ich natürlich alles bedaten können.

Ja ich bedate wirklich komplett vor dem Start und die Reaktion ergibt sich dann. Ich greife während der Simulation auf nichts zu. Dh. vor dem simOut = sim(...) lese ich alle Inputs über set_param(...) ein.

Die abschliedende Signalauswertung ist dann kein Problem.

Was meinst du gerade mit Codegenerierung? In die GUI die Inputs zu schreiben?

Zitat:

Ich würde es durch Workspace-Variablen umsetzen. Der Const Block liest diese einfach aus dem Base workspace aus.

Was genau bringt mir das? und wo ist der Unterschied zu einfachem set_param(pfad/Constant_Block,'String','true')
Ich muss trotzdem doch den Namen 'Constant_Block' wissen.

Grüße
stealth

Andreas Goser

Forum-Meister


	Beiträge: 3.654

	Anmeldedatum: 04.12.08

	Wohnort: Ismaning

	Version: 1.0

Verfasst am: 22.01.2015, 10:14 Titel:

Codegenerierung: Viele Simulink-Anwender generieren aus den Modell C Code, der dann wiederum letztendlich auf verschiedener Hardware landet, z.B. einem Microcontroller. wenn man das machen möchte gilt es die Auswirkungen der Modellierungstechniken auf den C Code zu berücksichtigen. Je früher man das macht, desto mehr Zeit spart man sich später.

Workspacevariablen: Beispiel ist die Demo "f14". Auf der obersten Ebene sind z.B. die drei Gain Blöcke in der Mitte durch Workspace Variablen definiert. Einfach mal die Demo einmal laufen lassen und den Verlauf in den Scopes verfolgen, dann "Mw=-0.1" ins Command Window eingeben und noch einmal laufen lassen.

Andreas

stealth_mx

Themenstarter

Forum-Fortgeschrittener


	Beiträge: 94

	Anmeldedatum: 15.06.13

	Wohnort: ---

	Version: 2013b

Verfasst am: 22.01.2015, 10:48 Titel:

Hallo,

achso die Art von Generierung. Ne die wird nicht benötigt, da der Controller bereits in C programmiert ist.

Leider bewirkt bei mir das Ändern des Mw Faktors nichts. Das Signal sieht immer noch so aus.

Aber was genau kann mir das bei meinem System bringen? Ich habe ja das Problem mit der Namensfindung der Constantblöcken. Oder meinst du, dass man damit die umgehen kann?!

twols

Forum-Anfänger


	Beiträge: 44

	Anmeldedatum: 05.03.11

	Wohnort: ---

	Version: ---

Verfasst am: 22.01.2015, 13:02 Titel:

Ich hoffe ich habe die Frage richtig verstanden.

Man kann das System mit Parametern bedaten, und zwar denen vom Typ "Simulink.Parameter". Diese lassen sich im Workspace ablegen, in Masken verändern, als MAT-File abspreichern. Zudem enthalten sie Informationen über Grenzen, Datentyp usw.

Wenn man Data Storage verwendet, kann man in die Parameter direkt in Simulink schreiben, auslesen lassen sie sich wie Konstanten.

Ich würde einen Block mit Maske ganz oben anlegen und in seiner Maske dann die Werte der Parameter anpassen.

Mit richtigem Data Storage lassen sich die Simulink.Parameter sogar auf der Hardware laufend anpassen, weil sie als globale C-Variablen übersetzt werden.
_________________

bitmarker eLearning Videos zu MATLAB, Simulink, LabVIEW bei YouTube: http://leogo.es/youtubebm

Andreas Goser

Forum-Meister


	Beiträge: 3.654

	Anmeldedatum: 04.12.08

	Wohnort: Ismaning

	Version: 1.0

Verfasst am: 22.01.2015, 13:31 Titel:

Richtig, mit meinem Vorschlag benötigt man keine Namen von Const-Blöcken, da man ja mit guten Variablennamen arbeiten kann.

Warum mein Beispiel nicht funktioniert kann ich nicht sagen. Wirklich die Variablenzuweisung im Command Window gemacht? Im selbstgeschriebenen UI geht das nur indirekt. Irgendwas mit EVALIN, aber UIs sind nicht so mein Gebiet.

Andreas

stealth_mx

Themenstarter

Forum-Fortgeschrittener


	Beiträge: 94

	Anmeldedatum: 15.06.13

	Wohnort: ---

	Version: 2013b

Verfasst am: 23.01.2015, 16:26 Titel:

Hallo,

ich habe mir doch überlegt das als Struct einmal aufzuschreiben, der Grund dafür ist, dass ich die Daten auch direkt speichen kann und dafür dann auch direkt eine Struktur habe. Außerdem ändert sich an dem System sogut wie nichts mehr.

Das was ich die ganze Zeit gesucht habe war:
find_system('Model','BlockType','Constant')

Damit bekomme ich genau die Elemente die ich brauche und kann daraus, dann ein Struct (mit den passenden Zustanden bzw. Werten) generieren und speichern. Smile

Ich denke mal das ist die optimale Lösung die Verfahren mit dem Einlesen über das Workspace sind bestimmt auch nicht schlecht, allerdings, benötige ich Zeit um mich da einzulesen und wenn ich schnell mal einen Run testen möchte, so kann ich einfach eben die Constants selbst bedaten, weil ich ja direkt sehe was ich mache.

Besten Dank für den Rat Smile


Einstellungen und Berechtigungen
Beiträge der letzten Zeit anzeigen:	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

Impressum | Nutzungsbedingungen | Datenschutz | FAQ |

RSS

Hosted by:

Copyright © 2007 - 2024 goMatlab.de | Dies ist keine offizielle Website der Firma The Mathworks

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.