From - Fri Jun 29 15:33:38 2001 From: Stefan Luetzkendorf --------------------------------------------------------------- hallo, wie versprochen hier ein paar anmerkungen zur motorensimulation. im prinzip ist es ganz einfach, 1. die dll der komponente ins verzeichnis des programmes legen (msim.dll im attachment, liegt aber auch im repository) --> dll im Attachment habe ich hier herausgenommen (Uli Sacklowski) 2. in die datei hardware.ini den abschnitt MOTORSIM eintragen, fuer den test sieht der wie folgt aus: [MOTORSIM] SimulationType=simulation_only LogLevel=0 ; kein Protokoll LogFile=test.log StatusWindow=0 ; Statusfenster Aus dll=msim.dll 3. alle Motoren im inifile die simuliert werden sollen, muessen vom type C-812ISA oder C-832 sein (der TMotor umgeht die hardware und also auch deren simulation) und theoretisch laeuft es dann. ich gehe dabei natuerlich davon aus, dass das mit einer neuen version von develop.exe getestet wird, in der meine letzten aenderung drin sind (wie z.B. msimstat.cpp). ich haenge hinten noch die beiden abschnitte aus der dazugehoerigen dokumentation dran, die das eben gesagte etwas ausfuehrlicher bringen. ich hoffe das es keine probleme gibt, aber ich freue micht trotzdem ueber rueckmeldungen. beste gruesse, stefan luetzkendorf 60 KAPITEL 2. DIE SIMULATION DER MOTOREN 2.5 Konfigurationsparameter f"ur die Steuerung der Motorensimulation Die Motorensimulation wird "uber einige Konfigurationsparameter in der Sek-tion [MOTORSIM] des ini-Files gesteuert, die im Folgenden beschrieben werden.Abb. 2.21 zeigt einen beispielhaften Ausschnitt aus einem Konfigurationsfile. Es ist zu ber"ucksichtigen, dass die Type-Parameter der [MotorX]-Abschnitt edie Werte C-812ISA oder C-832 haben m"ussen. [MOTORSIM] SimulationType=simulation_only LogLevel=0 ; kein Protokoll LogFile=test.log StatusWindow=1 ; Statusfenster Ein dll=msim.dll Abbildung 2.21: Beispielhafte MOTORSIM-Sektion SimulationType Legt den Simulationsmodus fest (s. S. 14). Werte: [no_simulation|simulation_only|test_simulation] no_simulation stellt den Normalmodus ein (Voreinstellung) simulation_only stellt den Simulationsmodus ein test_simulation stellt den Vergleichs- oder Protokollmodus ein LogFile Name der Datei, in die die Kommunikation mit der Hardware protokolliert werden soll. Voreinstellung ist "msim.log". LogLevel Legt fest, ob bzw. wie ausf"uhrlich das Protokoll sein soll. Werte: [0|1|2] 0 - kein Protokoll (Voreinstellung) StatusWindow Legt fest, ob das Statusfenster angezeigt werden soll. Werte: [0|1] 0 - kein Statusfenster (Voreinstellung) dll Legt den Namen der DLL fest, in der die Implementation der Simulation zu finden ist. Voreinstellung ist "msim.dll". Die DLL wird mit LoadLibrarygeladen, d.h. falls nur der Dateiname angegeben wird, wird die Bibliothek in folgenden Verzeichnissen gesucht: im aktuellen Verzeichnis, im Windows-und im System-Verzeichnis, im Verzeichnis von develop.exe und im Pfad. 14 KAPITEL 2. DIE SIMULATION DER MOTOREN Die Motorenkomponente unterst"utzt 3 Modi der Simulation: NormalmodusDas ist der Standardmodus, in dem sich die Motorenkomponente wie im bisherigen XCTL-System verh"alt. Es wird versucht direkt mit der Hardwarezu kommunizieren. Eventuell registrierte callbacks werden ignoriert. Normalmodus Wird dieser Modus verwendet, ohne dass die Hardware vorhanden und ent-sprechend konfiguriert ist, wird die Motorenkomponente, wie bisher, Fehler melden. Es besteht aber weiterhin die Option, Motoren vom Typ TMotor zuverwenden. Simulationsmodus In diesem Modus werden alle Hardware-Lese- und -Schreiboperationen an die entsprechenden, zu registrierenden callback-Funktionen delegiert. "Ublicher-weise treiben diese callbacks eine Simulation. Werden keine callbacks registriert, reagiert die Motorenkomponente wie imNormalmodus. Vergleichs- oder Protokollmodus In diesem Modus wird, wie im Normalmodus, direkt mit der Hardware kommuniziert. Parallel dazu werden jedoch die callback-Funktionen wie im Si-mulationsmodus aufgerufen, aber die dort generierten Werte ignoriert. Dieser Modus hat den Zweck, eine M"oglichkeit zu bieten, die tats"achlicheKommunikation der Software mit der Hardware zu beobachten; entweder um diese zu protokollieren, oder aber um eine eventuelle Simulation zu testen,indem sie parallel betrieben wird und die von ihr generierten Werte mit denen von der Hardware gelieferten verglichen werden.