Hallo,
ich habe folgendes Projekt angefangen: Ein Programm, mit dem man graphische Systemmodellierung machen kann, und das Python als numerische Engine benutzt. Sowas wie SIMULINK, nur eben auf Python- und nicht auf MATLAB-Basis.
Wer hat Lust mitzumachen?
Hier ist die Seite des Projektes auf GitHub:
https://github.com/PyLinX-Project/PyLinX
und hier die Mailing-Liste:
https://groups.google.com/forum/#!forum/pylinx-dev
Viele Grüße,
Wätzold
Systemmodellierung (ähnlich wie Simulink) auf Python-basis.
@WaetzoldP: Du hast ja schon einiges an Arbeit in Dein Projekt gesteckt. Trotzdem, oder gerade deshalb, solltest Du mal PEP8 zu Gemüte ziehen, damit sich Variablennamen und Formatierungen sich an allgemeine Standards halten.
Einmal wild herausgegriffen:
Hier macht der Code nicht das, was Du vermutest. Die ratio-Methode wird in __init__ gleich vom Attribut ratio überschrieben, ist also überflüssig. Da man auf Attribute auch direkt schreibend zugreifen kann, ist setRatio auch überflüssig. Alle weiteren Methoden der Klasse wären am besten Properties.
Wenn Du keine doppelten Unterstriche benutzt, brauchst Du auch nicht von Hand demangln (»_BContainer__Head«). Python hat eine automatische Speicherverwaltung, Elemente von Hand zu löschen, wie in BContainer.delete das mit obj gemacht wird, ist unnötig.
Methoden wie
haben gleich mehrere Unschönheiten: Wenn man nach einem Schlüssel in einem Dictionary sucht, dann mit »key in dictionary« ohne keys, weil das mit einem Hash sucht und nicht linear eine Liste durchsucht, wie mit keys(). Aber die ganze Funktion gibt es schon fertig als:
genauso isAttrTrue:
Alles in allem sieht das viel zu sehr nach Java oder ähnlichem aus, als nach Python.
Einmal wild herausgegriffen:
Code: Alles auswählen
class Scalable:
def __init__(self, ratio = 1, Target = -1):
self.ratio = ratio
if Target == Plot_Target.Gui:
self.brush = QBrush(QtCore.Qt.white)
def ratio(self):
return self.ratio
def setRatio(self, ratio):
self.ratio = ratio
Wenn Du keine doppelten Unterstriche benutzt, brauchst Du auch nicht von Hand demangln (»_BContainer__Head«). Python hat eine automatische Speicherverwaltung, Elemente von Hand zu löschen, wie in BContainer.delete das mit obj gemacht wird, ist unnötig.
Methoden wie
Code: Alles auswählen
def get(self, attr):
if attr in self.__Attributes.keys():
#print "> ", attr
return self.__Attributes[attr]
else:
return None
Code: Alles auswählen
def get(self, attr):
return self.__Attributes.get(attr)
Code: Alles auswählen
def isAttrTrue(self, attr):
return self.__Attributes.get(attr) is True
Inwieweit kennst Du Dich mit Simulink aus?
Punkt 2 ist ein gut gehütetes Geschäftsgeheimnis von Mathworks. Um sowas auch nur ansatzweise selbst hinzukriegen, brauchst Du extrem viel Erfahrung darin mechanische Modelle oder elektrische Schaltungen als DGL zu formulieren. Wenn Punkt 2 bei Simulink nicht funktioniert, weil das Modell zu komplex ist, dann löst Simulink das Modell ohne DGL und lässt einfach nur die Daten fließen.
Zu Punkt 1 besitzt Mathworks Patente.
Simulink anlysiert Deine grafische Eingabe und versucht damit eine DGL aufzustellen und diese dann zu lösen und zum Schluss werden die Ergebnisse mit Matlab Mitteln dargestellt (d.h. geplottet). Du hast also vier Bereiche:WaetzoldP hat geschrieben:das Python als numerische Engine benutzt. Sowas wie SIMULINK, nur eben auf Python- und nicht auf MATLAB-Basis.
- Die GUI zum Editieren der Modelle.
- Die Modell-Analyse: aus dem Modell eine DGL generieren
- DGL lösen
- Lösung plotten
Punkt 2 ist ein gut gehütetes Geschäftsgeheimnis von Mathworks. Um sowas auch nur ansatzweise selbst hinzukriegen, brauchst Du extrem viel Erfahrung darin mechanische Modelle oder elektrische Schaltungen als DGL zu formulieren. Wenn Punkt 2 bei Simulink nicht funktioniert, weil das Modell zu komplex ist, dann löst Simulink das Modell ohne DGL und lässt einfach nur die Daten fließen.
Zu Punkt 1 besitzt Mathworks Patente.
Ich komme eher aus der Ecke von Embedded Software Developement. Ich selber arbeite beruflich vor allem mit ETAS Ascet, weiß aber, dass in der Industrie dafür auch sehr viel Simulink benutzt wird. DGLs werden da nicht gelöst.MagBen hat geschrieben:Inwieweit kennst Du Dich mit Simulink aus?
Code: Alles auswählen
[quote="WaetzoldP"]das Python als numerische Engine benutzt. Sowas wie SIMULINK, nur eben auf Python- und nicht auf MATLAB-Basis.[/quote]Simulink anlysiert Deine grafische Eingabe und versucht damit eine DGL aufzustellen und diese dann zu lösen und zum Schluss werden die Ergebnisse mit Matlab Mitteln dargestellt (d.h. geplottet). Du hast also vier Bereiche:
[list=1][*]Die GUI zum Editieren der Modelle.
[*]Die Modell-Analyse: aus dem Modell eine DGL generieren
[*]DGL lösen
[*]Lösung plotten[/list]
Punkt 3 und 4 gibt's schon fertig in Python: Numpy, Scipy, Sympy, Matplotlib
Code: Alles auswählen
Punkt 2 ist ein gut gehütetes Geschäftsgeheimnis von Mathworks. Um sowas auch nur ansatzweise selbst hinzukriegen, brauchst Du extrem viel Erfahrung darin mechanische Modelle oder elektrische Schaltungen als DGL zu formulieren. Wenn Punkt 2 bei Simulink nicht funktioniert, weil das Modell zu komplex ist, dann löst Simulink das Modell ohne DGL und lässt einfach nur die Daten fließen.
Code: Alles auswählen
Zu Punkt 1 besitzt Mathworks Patente.[/quote]
Ich bin der Meinung, dass da eine Lücke klafft. Eine Python-basiertes Systemmodellierungstool könnte zum Beispiel für die Ausbildung sehr nützlich sein. Mal eben verschiedene einfache Reglertypen nachbauen um sie für's Studium zu verstehen wäre doch sicher eine feine Sache. Und es würde auch ein bißchen was gegen die MATALB-Monokultur machen.
Ich weiß, dass Mathworks zu Simulink Patente hat http://de.mathworks.com/company/aboutus ... tents.html und habe gehört, dass einige Patente sich auf so simple Sachen beziehen wie:
Grafische Oberfläche, darin werden Bauteile durch Rechtecke symbolisiert, diese haben Ein- und Ausgänge. Ein- und Ausgänge können grafisch miteinander verbunden werden.
Genau wie Simulink auf Matlab basiert, sollte ein Simulink Nachbau in Python auf den schon existierenden Matlab-Ersatz in Python basieren. Spyder ist auch ein sehr guter Startpunkt um selbst eine Anwendung für wissenschaftliche Datenanalyse mit Python-Konsole zu bauen. das habe ich selbst schon mit dem Spyder Vorgänger Pydee gemacht.
Grafische Oberfläche, darin werden Bauteile durch Rechtecke symbolisiert, diese haben Ein- und Ausgänge. Ein- und Ausgänge können grafisch miteinander verbunden werden.
Es gibt in Python eine sehr weit verbreitete Alternative zu Matlab ohne Simulink: Numpy, Scipy und Matplotlib. Mit viel Liebe zum Detail sind da selbst extrem merkwürdige Details der Matlab API nachimplementiert. Es gibt auch eine GUI die versucht möglichst wie Matlab auszusehen Spyder.WaetzoldP hat geschrieben:Und es würde auch ein bißchen was gegen die MATALB-Monokultur machen.
Genau wie Simulink auf Matlab basiert, sollte ein Simulink Nachbau in Python auf den schon existierenden Matlab-Ersatz in Python basieren. Spyder ist auch ein sehr guter Startpunkt um selbst eine Anwendung für wissenschaftliche Datenanalyse mit Python-Konsole zu bauen. das habe ich selbst schon mit dem Spyder Vorgänger Pydee gemacht.
Danke für die Info! Sehr hilfreich. Ich habe das gecheckt. Von den genannten Patenten sind ja nur die Europäischen Relevant. Ich habe das gecheckt. Sollte alles kein Problem sein:MagBen hat geschrieben:Ich weiß, dass Mathworks zu Simulink Patente hat http://de.mathworks.com/company/aboutus ... tents.html und habe gehört, dass einige Patente sich auf so simple Sachen beziehen wie:
Grafische Oberfläche, darin werden Bauteile durch Rechtecke symbolisiert, diese haben Ein- und Ausgänge. Ein- und Ausgänge können grafisch miteinander verbunden werden.
EP 1 963 965 B1 EUROPEAN PATENT SPECIFICATION
https://data.epo.org/publication-server ... cument.pdf
"[0008] In conventional simulation and code generation technology, the sample time(s) of a model cannot be modified
during the simulation of a model, and must be specified before the simulation and code generation of the model. Simulation
results and generated code are not valid to other systems that have different sample times. In a system running at
multiple sample times, a base rate sample time generally refers to a fundamental sample time that is the fastest in the
system. Sub-rate sample times refer to the other sample times that are integer multiples of the base sample time. If any
of the sample times (base rate or sub-rate sample time) change, the user must re-compile the model to simulate and
generate code for the model. Although all sample times must be invariant during simulation and execution of generated
code in the conventional technology, sometimes tunable sample times that can be modified during the simulation are
needed.
[0009] The Simulink Model-Based and System-Based Design user manual "Writing S-Functions" Version 5 of October
2004 describes how to vary before running a simulation sample times which specify when during a simulation a block
is sampled."
EP 1 817 700 B1(12) EUROPEAN PATENT SPECIFICATION
http://worldwide.espacenet.com/publicat ... date=&FT=D
[0002] The present invention relates to the transferring of data from a Discrete Event modeling environment to
other modeling environments, as well as the transfer of data from a non-discrete event modeling environment to
a discrete event modeling environment. Data transferred between a Discrete Event modeling environment and an-
other modeling environment must take into account the timing and data management differences between vari-
ous modeling environments such that data can be imported, exported, or both in a useable manner.
EP1899876 B1 EUROPEAN PATENT SPECIFICATION
System and method for using model analysis to generate directed test vectors
EP 1910902 B1 EUROPEAN PATENT SPECIFICATION
Method and apparatus for integrated modeling, simulation and analysis of chemical and biological systems having a sequence of reactions, each simulated at a reaction time determined based on reaction kinetics
Da hast Du sicher recht. Spyder beruht auf PyQt4, genauso wie PyLinX. Eine Integration sollte also möglich sein.MagBen hat geschrieben:Genau wie Simulink auf Matlab basiert, sollte ein Simulink Nachbau in Python auf den schon existierenden Matlab-Ersatz in Python basieren. Spyder ist auch ein sehr guter Startpunkt um selbst eine Anwendung für wissenschaftliche Datenanalyse mit Python-Konsole zu bauen. das habe ich selbst schon mit dem Spyder Vorgänger Pydee gemacht.
@Sirius3:
Danke für die Hinweise. Werde mir das mal die nächsten Tage anschauen. Kommt halt davon, wenn man alleine vor sich hin coded. Mich jetzt jedoch strikt an Codierungsrichtlinien zu halten, ... mal sehen. Ist ja ein "Freizeitprojet", und da ich beruflich auch sehr in den Ketten der SW-Entwicklungsprozesse hänge, hält sich meine Begeristerung in Grenzen. Aber vieles stimmt natürlich...
Danke für die Hinweise. Werde mir das mal die nächsten Tage anschauen. Kommt halt davon, wenn man alleine vor sich hin coded. Mich jetzt jedoch strikt an Codierungsrichtlinien zu halten, ... mal sehen. Ist ja ein "Freizeitprojet", und da ich beruflich auch sehr in den Ketten der SW-Entwicklungsprozesse hänge, hält sich meine Begeristerung in Grenzen. Aber vieles stimmt natürlich...
Ich hab für meine Abschlussarbeit eine Modellierungssprache(für einen Assembler) innerhalb Simulink gebaut. Du kannst ja Inspiration im Datenformat des Modells von Simulink nehmen, ist gezipptes XML zum reinschauen.
Ein wenig Simulink-Interna: Lines oder Block oder sonstwas werden als Objekte mit eindeutigen Handle gesehen. Hierachie wird über Parent umgesetzt und Name ist eindeutig innerhalb der Ebene. Jedes Objekt hat einen Typ und jeder Block zusätzlich einen unveränderlichen Blocktyp. Der Block besitzt Ports als Schnittstellen für Ein- & Ausgänge die wiederrum mit Lines verbunden werden. Subsysteme werden als Hierachieelement mittels Parent dargestellt. Portnummer der Inports im inneren verweist auf den Subsystem-Eingang ähnlich Outport zu Subsystem-Ausgang. Name des Subsystem ist gleich Name des Blocks.
Lange Rede, ich weiß nur soviel, das Projekt wird schnell riesig und unüberschaubar.
PS: Simulink-Reverse-Freunde sind die Attribute/Befehle: gcb & get_param, set_param und das Objektwörterbuch ObjectParameters.
Ein wenig Simulink-Interna: Lines oder Block oder sonstwas werden als Objekte mit eindeutigen Handle gesehen. Hierachie wird über Parent umgesetzt und Name ist eindeutig innerhalb der Ebene. Jedes Objekt hat einen Typ und jeder Block zusätzlich einen unveränderlichen Blocktyp. Der Block besitzt Ports als Schnittstellen für Ein- & Ausgänge die wiederrum mit Lines verbunden werden. Subsysteme werden als Hierachieelement mittels Parent dargestellt. Portnummer der Inports im inneren verweist auf den Subsystem-Eingang ähnlich Outport zu Subsystem-Ausgang. Name des Subsystem ist gleich Name des Blocks.
Lange Rede, ich weiß nur soviel, das Projekt wird schnell riesig und unüberschaubar.
PS: Simulink-Reverse-Freunde sind die Attribute/Befehle: gcb & get_param, set_param und das Objektwörterbuch ObjectParameters.