Was ist der Vorteil von Simulink?

Simulink ist vor allem für rapid prototyping aufgaben gedacht wie dem 
design von regelungen und steuerungen. die dinger manuell als pde zu 
beschreiben ist viel zu aufwändig und man verliert schnell den überblick 
- als blockschaltbild hingegen hat man einen sehr guten überblick über 
das gesamtsystem

es kommt halt sehr stark auf den anwendungszweck drauf an, simulink ist 
keinesfalls ein allzweckwerkzeug und wird von sehr vielen leuten falsch 
verwendet..

Matlabbenutzer schrieb:
> Mh, aber gerade für Regelungen bzw. Steuerungen muss ich doch die
> Mathematik dahinter verstanden haben bzw. schon auf dem Papier stehen
> haben. Den einzigen Vorteil würde ich jetzt zum Bespiel darin sehen,
> wenn jetzt irgendjemand, der keine Ahnung von der Materie hat, durch
> einfache Koeff.-Veränderungen einen Regler optimieren soll. ;-)

klar musst du die mathematik dahinter verstanden haben nur du hast 
irgendwann einfach keine lust das ganze zeug noch komplett manuell zu 
machen. gerade bei komplexeren sachen mal eben irgendwas an einer von 
zig gleichungen was zu ändern - nein danke ^^
das ganze abstrakt als block darzustellen ist da ein wirklicher vorteil.
ich arbeite in der FuE für regelungen und steuerungen, da machen wirs 
nur so und es klappt :)

> Meinst du wirklich pde's? Das geht doch weder mit Simulink noch Matlab
> oder?

matlab: pde toolbox zB. gibt auch zB runge-kutta verfahren 3ter oder 
4ter ordung in matlab als funktion. aus simulink kann man die ja einfach 
aufrufen ^^

Simulink ist gut für Rapid Prototyping und Simulation. Beispielsweise 
kann man Signalverarbeitungsketten oder Regler damit recht schnell 
exemplarisch entwerfen und simulieren.
Benutzt wird es leider viel zu häufig für die ganz normale Entwicklung 
von Steuergeräte-Code im Automobil-Sektor, wo dann aus den Modellen 
C-Code automatisch generiert wird.

Simulink wird langsam zum Hammer, bei dem für viele dann jedes Problem 
irgendwie wie ein Nagel aussieht. Entsprechend sind die Ergebnisse.
Man muss aber auch sagen, dass MathWorks mit seiner jahrelangen 
Werbetour für  "modellbasiertes Design" allen einredet, ohne Simulink 
könnte man heutzutage nicht mehr entwickeln. Gern angenommen von denen, 
die Angst vor C haben und sich lieber mit den Problemen einer eigentlich 
unpassenden Entwicklungsumgebung herumschlagen, weil Blöckchenschieben 
auf den ersten Blick so einfach erscheint.

So, habe mich angemeldet.

@Michael

Genauso habe ich mir das ja gedacht. ;-) Und ich sehe auch, dass es 
vielleicht für einfache Sachen, die schnell gehen sollen, auch ganz 
praktisch ist.

@Andi

Hatte bis jetzt ehrlich gesagt gedacht, dass niemand die PDE Toolbox 
benutzt. Es wird auch alles mit der FEM gelöst oder? Regelt ihr verteilt 
parametrische Systeme oder ist das nur für Simulation des geregelten 
Modells?

Johannes N. schrieb:
> So, habe mich angemeldet.
>
> @Michael
>
> Genauso habe ich mir das ja gedacht. ;-) Und ich sehe auch, dass es
> vielleicht für einfache Sachen, die schnell gehen sollen, auch ganz
> praktisch ist.

Simulink ist zweifellos ein mächtiges und praktisches Tool, wenn man es 
für das verwendet, wofür es ursprünglich gedacht war.

Ich habe aber auch schon erlebt, dass Leute mit Simulink auf dem PC 
unter Windows in "Quasi-Echtzeit" Signalverarbeitung machen wollten. Die 
Signalverarbeitung bestand dabei aber vor allem aus Regelsätzen, die 
mittels S-Function eingebaut wurden, Ein- und Ausgänge waren 
CAN-Bus-Schnittstellen. Spätestens mit einer solchen Konstruktion ist 
der Schwachsinn dann aber endgültig auf die Spitze getrieben worden. Das 
kommt aber dann davon, dass "man" nur das eine Tool kennt und sich 
hinter der Phrase "Das ist hier im Hause das Standard-Tool." verstecken 
kann.

Hi,

@Matlabbenutzer:

Du gehst vom mathematischen Standpunkt heran, das ist als 
Matlab-Benutzer zwar richtig, trifft aber nicht bei denen, die Simulink 
in der Industrie nutzen. Die nutzen Matlab/Simulink zur graphischen 
Programmierung, da geht es eher um Logik, Algorithmen und Abläufe (auch 
mit Stateflow). Und um die Tatsache, das eine graphische Programmierung 
sehr viel besser als Dokumentation geeignet ist, als z.B. ein 
C-Quellcode.

Und das ist im übrigen auch das Problem derer, die Simulink so nutzen 
vs. Mathworks. Für Mathworks ist das ein zusätzlicher Markt, den man 
natürlich gerne mitnimmt. Allerdings versteht man nicht bzw. will nicht 
verstehen, was solche Nutzer für Probleme damit haben. Und da sitzen sie 
und fluchen ... :-)

Schönen Tag noch, Thomas

Thomas K. schrieb:
> natürlich gerne mitnimmt. Allerdings versteht man nicht bzw. will nicht
> verstehen, was solche Nutzer für Probleme damit haben. Und da sitzen sie
> und fluchen ... :-)

Viel mehr ist es so, dass die Nutzer nicht verstehen, dass sie für 
"grafische Programmierung" das falsche Tool nutzen bzw. nicht 
hinterfragen, ob "grafische Programmierung" die Lösung für ihr Problem 
ist. Mathworks tut aber auch nichts, um dieses Missverständnis 
aufzuklären - im Gegenteil. Sie haben den Trend, Klötzchenschieben als 
"modellbasierte Entwicklung" und große Neuerung anzusehen, intensiv 
befeuert.
Ich halte es für einen teuren Irrweg, der vor allem deswegen beschritten 
wird, weil "grafische Programmierung" einfach erscheint (es aber nicht 
ist) und die enge Verquickung von Dokumentation und Code zwangsläufig zu 
faulen Kompromissen führt. An Simulink klammern sich unendlich viele 
Leute, die Angst vor C haben. Trotzdem gilt auch mit Simulink: "A fool 
with a tool is still a fool."

Klaus2 schrieb:
> ...für die steuergeräteentwicklung ist es, wie schon gesagt, eine
> wirklich praktische sache. zumal ich bei >20 stateflows pro funktion
> nicht wirklich durch den c-code steigen möchte, das wird hart.

Warum wird das hart? Komplexität wird doch durch Simulink überhaupt 
nicht genommen, es ist nur eine andere Darstellung.

> übersichtlichkeit ist bei den immer komplkexer werdenden architekturen
> das A&O. echtzeit restbus simu mit CANoe und online parameterverstellung
> machen das ganze dann zu einem extrem interessanten spielzeug. wenn man
> sich dann aber den generierten c-code anschaut, muss man durchaus
> wissen, wie man es noch optimieren kann.

Viel Spaß beim Optimieren solch automatisch erzeugten Codes. Die 
Hersteller von uCs und DSPs freuen sich jedenfalls über die zunehmende 
Simulink-Entwicklung für Steuergeräte. :)

Hi Hichael,

Michael S. schrieb:
> Ich halte es für einen teuren Irrweg, der vor allem deswegen beschritten
> wird, weil "grafische Programmierung" einfach erscheint (es aber nicht
> ist) und die enge Verquickung von Dokumentation und Code zwangsläufig zu

Hmmm ... wird ja auch so verkauft und geglaubt, zumindest von "unseren" 
Herrn Entscheidern. (das ist firmenübergreifend!) Es gibt zu 
Matlab/Simulink einen Konkurenten namens A**** aus dem Hause E***. ;-) 
Die kommen nun tatsächlich aus der Programmierungs- und Embedded-Ecke. 
Allerdings ist es da auch nicht einfacher ... oder besser ... nur 
anders. :-)

Das Hauptproblem ist m.E. nach, das man "glaubt" etwas zu bekommen, das 
"alles" kann! Marketing macht's möglich. Aber zum Schluß kommt man eben 
trotzdem nicht um Compiler, Makefile und C-Code herum. Und dann gibt's 
dann die langen Gesichter: "... wieso geht das nicht, das soll doch 
gehen ..." oder "... in der Vorführung ging das doch ganz prächtig, 
wieso geht das nun in unserem Projekt nicht?"

Schönes Wochenende noch,
Thomas

Thomas K. schrieb:
> Das Hauptproblem ist m.E. nach, das man "glaubt" etwas zu bekommen, das
> "alles" kann! Marketing macht's möglich. Aber zum Schluß kommt man eben
> trotzdem nicht um Compiler, Makefile und C-Code herum. Und dann gibt's
> dann die langen Gesichter: "... wieso geht das nicht, das soll doch
> gehen ..." oder "... in der Vorführung ging das doch ganz prächtig,
> wieso geht das nun in unserem Projekt nicht?"

Ja, das meine ich. Die Entwicklungsschritte sind komplex und die 
Bandbreite der Aufgaben ist sehr groß. Der Glauben daran, das alles mit 
einem Tool erschlagen zu können, ist das Problem.

> Schönes Wochenende noch,
> Thomas

Dito. :)
Michael