Stimuli in Simulink textbasierend generiert, TimeSignals-FB

Stimuli in Simulink textbasierend generiert, TimeSignals-FB

Inhalt


Topic:.Smlk_de.TimeSignals.

Last changed: 2018-11-16

Das folgende Video zeigt den Einsatz des FB values_TimeSignals_Inspc_SfH, eine S-Function in Simulink. Diese erzeugt Ausgangssingale als Sprünge oder Rampen mit oder ohne Spline nach textuellen Vorgaben in einem File.

TimeSignals_ApplInspc.mp4 Kurzvorstellung 3:19 min


1 Anwendung des FBlock value_TimeSignals_Inspc

Topic:.Smlk_de.TimeSignals.appl.

Last changed: 2018-11-16

TimeSignals_Appl_details.mp4 Gesamtanwendung etwas ausführlicher 8:00 min

Die Besonderheit - die Vorgaben der Stimuli erfolgen nicht im Inneren des FB sondern werden aus einem Textfile gelesen. Das Textfile kann ein Matlab-Script sein (m-File), das auch weitere Befehle enthalten kann, die insgesamt als Einstellung für einen Simulationslauf genutzt werden. Statische Parametrierung und Zeitvorgaben. Ein Stimuli-File kann/soll in allen im Modell enthaltenen TimeSignals-FBs genutzt werden. Die Signalzuordnung geschieht über Namen.


Das Steuerfile für diesen FB kann sowohl einfach per Hand editiert werden als auch generiert werden. Für die Hand-Edition ist gegenüberzustellen:

Für den ersten Fall muss noch hinzugesetzt werden: Nach dem einfachen editieren zeigt der schnelle Start der Simulation, wie das Signal aussieht. Ein zweites kleines Modell nur mit einem Scope hinter dem FB kann dies zeigen, wenn ein großes Modell doch sehr lange braucht für den Gesamtablauf. Man kann weitere signalauswertende Elemente wie Differenzierer in dieses Test-Stimuli-Modell einbringen. Eine weitere Herangehensweise: Das Stimulifile bleibt offen, der Cursor am Punkt des Interesses. Nach Sichtung des Simulationsergebnisses wird dort, beispielsweise ein Signalpegel, schnell korrigiert und die Simulation wiederholt.

manuelles editieren der Vorgaben 4:35 min

Es ist ein direkter Handeingriff in die Werte der Simulation möglich, über das Inspector-Tool und den Inspector-Service im Modell. Das wird im folgenden Video gezeigt.

manueller Eingriff in die laufende Simulation mit dem Inspector 3:13 min

Die einfache textuelle Schreibweise der Stimuli eröffnet nun Möglichkeiten der textbasierenden Generierung.


2 Regelungstechnische Überlegungen zu den Spline-Vorgaben

Topic:.Smlk_de.TimeSignals..

Spline und Regelung 6:29 min

Das Spline (Rundung) in erzeugten Stimuli vermeidet Schwingungsanregungen aufgrund des Sollwertes. Im Video wird gezeigt, dass dazu die zweite Ableitung des vom TimeSignals-FB erzeugten Sollwertes nicht springt. Dies wurde so programmiert und getestet. Auffällig beim Test war aber, dass es Schwingungs-Anregungen sichtbar in der zweiten Ableitung gibt: die dritte Ableitung springt.

Ein Spline, der keine Sprunganregungen enthält, auch nicht in der n-ten Ableitung (mit der Grenze der Abtastzeit) ist mit einem sinusförmigen Spline erreichbar. Ein Sinus ist abgeleitet immer wieder eine Sinusform, bekannt aus der Mathematik. Der Spline muss also einen Ausschnitt aus einer Sinuskurve darstellen, die bei 45° Steigung beginnt, also sin(0) bei einem schnellen Anstieg vor dem Spline. Je nach Anstieg nach dem Spline ist der richtige Abschnitt zu wählen. Wenn der Übergang vom Sinus in die Anstiegsgeraden knickfrei ist, dürten sich damit kaum Anregungen ergeben. Die zeitliche Breite des Splines richtet sich damit nach dem Anstieg, bei kleinen Anstiegen darf dabei der Sinus-Auschnitt bei einem flacheren Winkel beginnen also ein kleineres Sinusstück winkelbezogen umfassen.

Die Intension für diese Lösung: Fourieranalyse. Jeder Knick, auch in der Ableitung entspricht einer höheren Frequenz. Auch der Übergang vom sinus in den linearen Anstieg ist ein frequenzgemisch, aber ein moderates. Schwingungsanregungen sind in der Frequenztransformation gut zu überschauen.

Diese Lösung ist im Moment nicht implementiert (Stand 2018-09).


3 Generierung der Stimuli-Files

Topic:.Smlk_de.TimeSignals.gen.

Last changed: 2018-11-16


3.1 Grundsatzüberlegungen zur Generierung

Topic:.Smlk_de.TimeSignals.gen..

Stimulis sind die Basis für Testfälle, in diesem Sinn vielfältig und generierungsbedürftig. Oft rekrutieren sich notwnedige Stimulis für Tests auch aus Praxisanwendungen: Unter bestimmten Bedingungen gab es Fehlverhalten einer gelieferten Software, nun sollen die Praxisbedingungen mit Stimuli nachgestellt werden. Das geschieht dann aus Messwerten heraus. Eine automatische Generierung lohnt sich dann immer, wenn es einen Wiederholungsgrad gibt. Ansonsten muss die manuelle Erstellung von Stimulis überschaubar und kontrollierbar sein.

Für das hier vorgestellte System der Stimulis wurde die flachtextbasierende Speicherform gewählt. Andere verbreitete Möglichkeiten sind:

Die flachtextbasierende Speicherung ist mit einfachen Mitteln überschaubar. Letzlich sind die Stimulifiles einzeln betrachtet nicht sehr komplex, auch für 20..100 Signale mit gleichviel Zeitangaben. Mit dem Mittel des Textsuches kann oft ein markanter Wert eines Signals schneller aufgefunden werden als innerhalb Excel.

Text-generierende und transformierende Tools sind nun ebenfalls vielfältig anzutreffen. Das Textformat hat hier wieder den Vorteil, das man gut sehen kann, was generiert wird. Man kann also sich in eine gegebene Toolwelt integrieren. Beispielsweise werden Messdaten traditionell mit Excel gespeichert und vorverarbeitet. Nun lässt sich Excel selbst textuell exportieren (über csv) oder besser noch direkt aus dem xlsx-File auslesen. Dazu steht auch unter vishia ein Tool bereit (XMLJzReader).

Die hier propagierte Herangehensweise - JZtxtcmd als Kern zu verwenden, ist also nur eine von mehreren Möglichkeiten. In JZtxtcmd lassen sich andere Tools über cmd-line aufrufen, und über den Java-Zugriff xlsx und XML lesen. Damit ist eine Anpassung und Integration von Anwender-Gegebenheiten möglich.

JZtxtcmd basiert auf Java und kann sehr einfach Java-Teile integrieren. Java wiederum ist in leistungsfähigen Mainstream-Programmierumgebungen etabliert. Java mit Eclipse für ein mehr oder weniger tiefes Debugging (auch nur zum Anhalten am Einsprungpunkt und Daten kontrollieren) ist nicht nur kostenfrei und einfach für das persönliche Studium erhältlich sondern wird auch an den Ausbildungseinrichtungen verwendet und gelehrt.


3.2 Arbeitsweise des Generiervorgabescripts mit Stimuliselektor

Topic:.Smlk_de.TimeSignals.gen..

Im folgenden Video wird gezeigt, wie die Stimuli-Selektion eingerichtet werden kann und wie sie abgearbeitet wird:

../mp4/TimeSignals_Script.mp4

Es wird vollständig auf JZtxtcmd gesetzt. Die GUI ist in Java programmiert. Selbst die GUI kann mit JZtxtcmd-Mitteln aufgebaut und damit im Script auch vom Anwender leichter angepasst werden, anstatt den Einstieg in Java-GUI-Programmierung zu benötigen. Dies ist aktuell nicht realisiert, aber geplant (Stand 2018-09). Die Steuerung was die GUI anzeigt und welche Werte-Zusammenstellungen selektierbar sind, ist in den JZtxtcmd-Scripts enthalten. Dabei sind die Scripts nicht sehr lang.

Im Video wird erläutert, dass ausgehend von der Zeilenselektion in den Tabellen der GUI dem Generierscripts Schlüssel (keys) übergeben werden, das sind die Inhalte der Variable name in den Tabellenzeilen. Über den Weg werden dann die passenden Informationen gefunden.

Eine Tabelle für dieses Beispiel wird wie folgt vorgegeben:

List variation_1 =  ##times
[ { name="slow",  select="x",   t1="3.0", t2="5.0", t3="8.0", descr="slow cycle"    }
, { name="slow2",  select="x",  t1="2.0", t2="5.0", t3="6.0", descr="middle cycle"    }
, { name="mid1",  select="x",   t1="2.0", t2="4.0", t3="6.0", descr="middle cycle"    }
, { name="mid2",  select="x",   t1="2.0", t2="3.0", t3="4.0", descr="faster cycle"    }
, { name="fast",  select="GJ",   t1="1.0", t2="1.7", t3="2.5", descr="fast cycle"    }
];


Bild: GUItab1

Die Gui zeigt damit folgendes an:

Wenn der Anwender wie hier gezeigt die Zeile mid2 anwählt, so wird von der GUI dieser String aus der aktuellen Tabellenzeile gelesen und als Parameter der Generier-Subroutine übergeben: key1 wird mit "mid1"" besetzt:

sub genStimuli(String key1, String key2,...){
   ....
   for(var1: variation_1) {
     for(...)  ##nested for for all lists
       if(var1.name == key1 && ...

Auf diese Weise wird auf die gewählten Daten zugegriffen. Die GUI in Java und das JZtxtcmd-Script arbeiten also perfekt zusammen.


4 Komponenten, Sources, in der Anwendungsumgebung

Topic:.Smlk_de.TimeSignals..

Dieses Kapitel steht vorn da es die Downloadfiles zum testen und die Anleitung dazu enthält.

Mir als Verfasser ist es wichtig, diese gesamte dahinterstehende Technologie kleinteilig bereitzustellen. Diese Herangehensweise etabliert sich in der IT-Welt momemtan insgesamt: Statt großer Programmsysteme, die nicht nur entsprechenden Platz auf Datenträgern und Ladezeiten benötigen, geht der Trend hin zu überschaubaren Einheiten, die locker gekoppelt sind.

So enthält das Zipfile

Smlk_InspcStimuli_yyyy-mm-dd.zip ==>.../smlk/: Basispaket Simulink Inspector und TimeSignals - zip-Archiv-Verzeichnis

in einem überschaubaren knappen 1 MByte alle Files mit Beispielen nicht nur für TimeSignals sondern die gesamte Inspector-Library einschließlich der zugehörigen mex-dll für die Abarbeitung auf Windows (7..10 und folgende) 64 bit.

Das folgende Video enthält einen Ersteinstieg nur mit diesem Zipfile:

../mp4/TimeSignals_First_zip.mp4

Für den FB value_TimeSignals_Inspc_Sfh.mex64 allein in einer beliebigen Anwenderumgebung braucht man nur das genannte mex-File, dass sich in Simulink in eine S-Function-Hülle packen lässt. Damit braucht die hier benutzte Strukturierung (Lage der Verzeichnisse) nicht in einer anderen Umgebung berücksichtigt zu werden. Im zweiten Ansatz ist allerdings die Zusammenstellung der Simulink/lib/lib_Inspc.slx als Simulink-Library und zugehörig auch die Verzeichnisstruktur mit Simulink/lib/+genSfn/lib_Inspc_mex.m zum Nachgenerieren des mex-Files auf einer anderen Umgebung, nach C-Quellenänderung oder für das Debugging zu empfehlen. Wie genau, muss im Anwendersystem abgestimmt werden. Es gibt mehrere mögliche Gepflogenheiten, wie im Simulink das current directory gesetzt werden kann und dergleichen, die miteinander in Einklang zu bringen sind.

Für ein Test wird vorgeschlagen, die Inhalte der Zipfiles zunächst genau in vorgesehenen Sub-Directories auf der Festplatte auszupacken. Der absolute Path sollte keine Rolle spielen und ist folgend mit .../ angedeutet. Danach muss das obige Zipfile (gespeichert und) ausgepackt werden unter

.../smlk

Es entsteht dann ein Filetree:

.../smlk/Smlk_InspcStimuli/
                 +- lib/
                 +- test/+inspcStimuli/
                 +- startSmlk.bat

Wird das startSmlk.bat in diesem aktuellen Verzeichnis gestartet, dann werden über setupMatlabPath_local.m sowohl der Matlab-Path eingestellt als auch das Root- und current directory gesetzt. Man kann direkt im Simulink weiterarbeiten.

Um die Stimulation-Select-GUI abzuarbeiten benötigt man einerseits die GUI als Java-Programm, andererseits den JZtxtcmd-Script-Executer. Beides zusammengefasst ist in

vishiajar_yyyy-mm-dd.zip ==>.../Java: jar-Files Java-GUI, JZtxtcmd

Dieses zipfile soll also entpackt und gespeichert werden in einem Ordner Java im selben Filebaum parallel zu smlk. Mit dem Auspacken entsteht:

.../Java/
     +- vishiajar/
          +- zbnf.jar
          +- vishiaGui.jar
          +- org.eclipse.swt.win32.win32.x86_64_3.106.0.v20161027-0130.jar
          +- org.eclipse.swt.win32.win32.x86_3.5.1.v3555a.jar

Mit in diesem Paket sind zwei SWT-Libraries von Eclipse enthalten. Dessen Copyright liegt bei www.eclipse.org. Es handelt sich um die Anpassung der Java-Graphic an Windows-API. Für eine andere Plattform (Linux, Raspberry) gibt es passende Libraries im Internet. Für den Start von java als 64-bit- oder 32-bit-Version benötigt man unterschiedliche SWT-Libraries. Beide sind hier enthalten. Die SWT-Library für 32 bit Windows ist aus dem Jahre 2009. Diese ist dennoch kompatible mit den übersetztem vishiaGui.jar und läuft auch unter Windows-XP.

Die Simulation-Selection-GUI kann über das File

.../Smlk_InspcStimuli/test/+inspcStimuli/+stimuli/stimuli_Selection.jzT.cmd

oder aus Matlab heraus gestartet werden:


mex file neu compilieren:

Will man den TimeSignals-FB neu übersetzen, dann braucht man dessen Quellen. Im oben genannten Zipfile sind nur die Sfunction-Wrapper enthalten, nicht die Basisfunktionen. Ein größerer Umfang der Quellen ist mit dem FB Service_Inspc verbunden. Dieser FB kann, muss nicht für den einfachen Fall, im Zusammenhang mit dem TimeSignals-FB genutzt werden. Die Quellen für den sogenannten Inspector-Service sind die selben, ohne Änderung, wie sie auch auf einem Target-System (embedded) verwendet werden. Dazu gehört allerdings dann auch eine Anpassmöglichkeit, die mit einem OSAL-Layer (Operation System Adaption Layer) verbunden ist. Alles in allem ergibt das einen Satz von Quellen unter dem label emC (embedded multiplatform C), die als Komponente für verschiedene Zwecke bereitstehen. Diese Komponente wird unverändert benutzt:

emc_2018...zip ==> .../: emC-Quellen

Komponentendenkweise: Die Herauslösung, Abtrennung einzelner Quellen aus einer Komponente und Abspeicherung in der eigenen maßgeschneiderten Umgebung ist nicht unbedingt zielführend, es wird zu kleinteilig gedacht. Möchte man den Inspector-Service in einem Targetsystem unterbringen oder nur erst testhalber eine PC-version untersuchen, dann würde man mit der Sortierung der Sources wieder von vorn beginnen. Es ist also angemessen, den Trend zu kleinen überschaubaren Software-Einheiten bei Komponenten einer gewissen Größe zu stoppen. Sonst erhält man eine Vielzahl unüberschaubarer weil immer in anderen Konstellationen zusammengefassten Einzel-Sourcefiles.

Die zur Komponentendenkweise passende Fragestellung ist das System der Anordnung der Komponenten. Diesbezüglich gibt es in verschiedenen Anwendungsumgebungen unterschiedliche Herangehensweisen. Diese zusammenzubringen sollte möglich sein, ist aber Feinarbeit.

Anordnung der Files im Gesamt-Baum

Nutzt man die Download-zip von vishia original, dann sind diese in bestimmten Unterverzeichnissen zu entpacken. Beim mir entsteht dann im Filesystem ein Baum, der mit D:/vishia beginnt. Das absolute Verzeichnis spielt aber keine Rolle, der Verweis auf Files aus einer anderen Komponenten ist jeweils relativ über ../.. geführt. Sie als Anwender müssen also nicht D:/vishia benutzen. Aber die relativen Pfade sollten eingehalten werden, dann ist keine Anpassung notwendig. Ansonsten gibt es jeweils findbare Pfade, die aber beispielsweise in einem Visual Studio Projekt im Projektfile stecken. Sie sind dort anpassbar auch mit Suchen/Ersetzen.

Es ergibt sich damit folgender Verzeichnisbaum für das vollständige hier vorgestellte System. Die jeweiligen zipfiles müssen mit ihrem Inhalt dort entpackt werden wo sie hier stehen. Die Zipfiles enthalten immer ein Start-Verzeichnis intern. In der folgenden Übersicht wird der Inhalt im zipfile strukturell angedeutet.

Root_user (d:/vishia)
 |
 +-smlk
 |   +- Smlk_InspcStimuli_2018-...zip  (Diese Dokumentation)
 |   |  Smlk_InspcStimuli/
 |   |    +-lib/
 |   |    |  +-mex/
 |   |    +-test/+inspcStimuli
 |   |                 +- TestInspcStimuli.slx
 |   |
 |   +- mexDbg/       (Generated mex for debug, PC-specific)
 |   |
 |   +- SmlkSfuncJZtc_2018...zip     (licensed scripts)
 |      SmlkSfuncJZtc/
 |             +- simulinkSfuncBusGen.jzTc
 |
 +-emc_2018-...zip  (Die emc-C-Sources)
 | emc
 |   +source/*
 |   +sourceApplSpec/*
 |   +...etc
 |
 +-Java/
 |   +- vishiajar_2018-...zip  (passend zusammengestellte jars)
 |   |    +- vishiajar/
 |   |          +-zbnf.jar         (Java-Archiv JZtxtcmd)
 |   |          +-vishiaGui.jar   (Java-Archiv GUI, Inspector-GUI)
 |   |          +-org.eclipse.swt...jar (SWT-Library von Eclipse)
 |   |
 |   +- srcJava_vishiaGui     (sources der jars)
 |   +- srcJava_vishiaRun
 |
 +-ZBNF/
     +- srcJava_zbnf.zip
     |
     +- zbnfjax_2018....zip
        zbnfjax
           +- zbnf/Cheader.zbnf   (Für Reflectiongenerierung)
           +- jzTc/Cheader2Refl.jztxt.cmd
           +- zbnf.jar (hier dupliziert)

Dieser Verzeichnisbaum ist harmonisiert für alle vishia-Komponenten.

Man kann von den Binary-Komponeten (hier mex und jar) Quellen erhalten, wenn man deren Funktionsweise wissen oder ändern möchte. Diese sind im obigen Baum mit angeführt. Man kann passende Versionen unabhängig auswählen, wenn für andere Teile im selben Anwender-Applikationsraum eine andere Version notwendig ist. Die Funktionen der jar-Files sollten entweder abwärtskompatibel sein oder markant auf kleine anpassbare Änderungen hinweisen, so dass ein Versions-Mix möglich ist. Welcher Source-Stand zu Binaries gehört lässt sich entweder aus dem Datum ableiten oder ist in den Binaries verzeichnet.

Hinweis zu Versionen: Für das Download der zip klappt jeweils ein Verzeichnis auf. Dort befinden sich jeweils mit *_yyyy-mm-dd.zip gekennzeichnet meist mehrere Versionen im Verzeichnis oder es gibt ein Archive-Verzeichnis. Man hat hier die Möglichkeit, auch noch auf eine ältere möglicherweise bekannte Version zurückzugreifen, wenn gerade upgedated wurde. In wieweit Versionen mischbar sind, hängt von verschiedenen Faktoren ab, muss man probieren. Sie sollten in der Regel mischbar sein, möglicherweise mit klar gemeldeten oder offensichtlichen wenigen Anpassungen von Pfaden und Namen.

Die Sources sind ebenfalls in zip-Archiven versioniert. Die Versionshistorie selbst ist entweder in einem zip-File, dass ein git-Archive enthält, lokal downloadbar und nachsehbar, einige Sources sind auch bei www.github.org/JzHartmut gelistet.

Übersichtstabelle der relevanten Downloads in der Reihenfolge des Tiefeneinstieges

Download-link

File im Verzeichnis

Zielverzeichnis ab root

Gebraucht für

../../smlk/Download

Smlk_InspcStimuli_*.zip

smlk

Basispaket Simulink Inspector und TimeSignals, damit Test im Simulink möglich

../../Java/Download/vishiajar

vishiajar_*.zip

smlk

Nutzung der Stimuli-Gui und Stimuli-Generierung

../../emc-download/emc

emc_*.zip

.

Neu-Übersetzung der Sfunctions, andere Platform, Änderungen im C-Code, mex für Debug

../../ZBNFdownload/zbnfjax

zbnfjax_*.zip

ZBNF

Neu-Übersetzung der Sfunctions, Tools für Reflectiongenerierung

../../Java/Download/srcJava_Zbnf

srcJava_Zbnf_*.zip

ZBNF (or: Java)

Debugging in JZtxtcmd, for example Eclipse as IDE

../../Java/Download/srcJava_vishiaRun

srcJava_Run_*.zip

Java

Necesarry component for vishiaGui

../../Java/Download/srcJava_vishiaGui

srcJava_Gui_*.zip

Java

Debugging or changing GUI in Java

auf Anfrage

SmlkSfunc_jzTc_*.zip

smlk

notwendig wenn Sfunctions neu zugeschnitten werden sollen


5 Speicherort der Files relativ zu Simulink und dem Anwenderprojekt

Topic:.Smlk_de.TimeSignals.rootPath.

Es gibt mehrere Möglichkeiten der Anordnung von Files, der Wahl eines aktuellen Verzeichnisses (current dir) und der Aufruforganisation.

Current directory:' Ein Problem wurde mit der Entscheidung UNIX 1970 verursacht. Man meinte damals, es muss ein festes user-related current directory geben, also /home/hartmut/Simulinktests in meinem Fall. Die klare Strukturierung des Verzeichnisbaums und der Arbeit mit dem Filesystem hatte damals Anforderungen der 2000-er nicht ganz berücksichtigt: Die Vielfalt von Aufgaben, Parallelarbeit usw. Wer kennt nicht den Ärger mit falschen relativen Pfaden und der Nutzung usinniger absoluter Pfade.

Interessanterweise wurde mit den Querverweisen in html-Seiten eine andere Strategie präsentiert: Relative Links gehen immer vom aktuellem File aus, in dem der Link steht. Das funktioniert gut. Dieses System hätte auch in anderen Kontexten Verwendung finden können. Beispielsweise wäre in batch-Files für gerufene batch-Files auch diese Strategie, relativ vom rufenden File aus, etablierbar gewesen.

Im Simulink bestimmt der oben in der Pfadzeile stehende Pfad das current directory (Current Folder) innerhalb Simulink. Man kann dies beliebig, auch versehentlich irgendwie. ändern mit Klick im Filebaum. Dann geht gar nichts mehr, wenn man relative Pfade im Simulink benutzt. Das betrifft Angaben zu Filenamen, nicht zu Modellteilen, die sind mit dem Simulink-Suchpath (addpath-command) geregelt.

Anordnung von Files: Wie oben dargestellt gibt es mehrere gleich gute Möglichkeiten. Dazu allgemeine Überlegungen:

Die Schlussfolgerungen für dieses Projekt, allgemein für Simulink-Projekte:

Es gibt ein Root-Verzeichnis für Simulink. Dieses wird beim Start des Simulink automatisch als rootPath in eine Simulink-Variable eingetragen. Dazu steht in diesem Simulink-Rootverzeichnis:

D:\vishia\smlk\InspcStimuli\Smlk_InspcStimuli>dir
   <DIR>          lib
   <DIR>          test
              363 setupMatlabPath_local.m
              117 startSmlk.bat
               54 startSmlk.m

Im setupMatlabPath_local.m wird sowohl die rootPath variable gesetzt als auch der Simulink-path entsprechend erweitert:

currdir = pwd;                  %Currdir for the users simulink project
rootPath = fullfile(pwd, '.');  %Root for simulink for common accesses. Note: add ../.. if currdir is inside.
addpath(fullfile(rootPath,'test'));
addpath(fullfile(rootPath,'lib'));
addpath(fullfile(rootPath,'lib/mex'));

Die currdir-Variable ist etwas freier verwendbar, siehe folgend. Die rootPath-Variable ist im Simulink ein fester Bezug für alle Files. Diese wird zur Runtime absolut gesetzt. In Kombination von

fullfile(rootPath, ''test/my/file.x'')

werden dann alle Files, im Modell relativ zum rootPath angegeben, absolut gefunden.

In einem Script, dass File-paths verwendet, kann man nun starten und enden mit:

rootPath = evalin('base', 'rootPath');
currdir_ = pwd;
cd(rootPath);
...the users script
cd(currdir_);
end

Diese Herangehensweise sichert, dass das Script funktioniert, egal wo der Current Folder des Simulink steht.

Ordnung im Modell, gleiche Strategie für Verzeichnisse innerhalb Simulink:

Hier gilt es nun von UNIX-1970 zu lernen. Im Unix/Linux ist jedem Nutzer klar, was in den Verzeichnissen bin, home, user/local usw. steht.

Desweiteren ist die Möglichkeit, die Punktnotation in Simulink zu verwenden, wichtig. Es vermeidet name-clashs bei komplexen Modellen. Funktioniert nur leider nicht für Libraries.

Beim Verfasser hat sich dazu folgende Herangehensweise herausgebildet:

Simulink-Root
 |
 +-lib            alle libs
 |  +- +mkSfn/    Scripts für Sfunction-Wrapper-Generierung aus Header
 |  +- +genSfn/   Scripts um Sfunction zu generieren, aus C-Sources
 |  +- +genBus/   Scripts um Busdefinitionen für die Library-Nutzung zu generieren
 |  +- mex/       mex-Ordner (ohne +, muss im Simulink-Path stehen)
 |  |    +- tlc_c/ Wird so von der Codegenerierung erwartet
 |  +- libxyz.slx Die lib selbst.
 |
 +-test
 |  +- +myTestPrj
 |       +- +genStimuli/  generierte Files
 |       +- +stimuli/     Vorgaben, Primärquellen für Stimulis
 |       +- MyModell.slx Das Modell
 |       +- MyModell_init.m  Dieses File ist einziges callback im Modell
 |
 +-myProject
 |      +- +subComponentsOfProject/
 |
 +- setupMatlabPath.m    startfile

Die Schreibweise mit dem + am Verzeichnisnamenanfang ermöglicht in Simulink die Bildung eines paths zum Modell oder script:

myTestPrj.MyModell_init()

ist dann die notwendig richtige Schreibweise um im callback des Modells dieses init-Script zu rufen. Das + wird nicht notiert. Damit Simulink das Script findet, muss Simulink-Root/test Bestandteil des Simulink-path sein, mehr nicht. Der Simulink-Path wird also auch kürzer. Damit werden name-clashs (Verwechslungsmöglichkeiten von Files aufgrund gleichen Namen im Suchpfad) vermieden.


6 Float oder Double-Arithmetik

Topic:.Smlk_de.TimeSignals..

Der TimeSignals-FB ist in der vorliegenden Form mit float programmiert. Dazu sind einige Zusatzfunktionen notwendig, damit bei langen Anstiegen der exakte Endwert erreicht wird. Bei fortlaufender Addition eines einmalig berechneten Zuwachses wird der Endwert nur in der float-Auflösung mit Kettenfehler getroffen. Die Fehlergrenze sind etwa 2000 bis 4000 Inkremente. Jedes Increment hat einen möglichen Fehler von ca. 10e-7, Mantissenlänge 24 bit. Bei 4000 Inkrementen wird bei einem maximalen Kettenfehler ein Fehler von (10e-7*4000) =~ 1/2500 erreicht, also etwa die Größe des Inkrements selbst.

Die Lösung des Problems ist eine Neuberechnung des Anstieges aller 2000 Schritte. Das erfolgt bei einer Abtastzeit von 100 µs für 10 s Anstieg also etwa 50 mal im Anstieg. Jeweils ein Zwischenpunkt wird über die Geradengleichung in Floatgenauigkeit berechnet und möglichst exakt angefahren. Bei Änderungen des Anstieges, die im 0.Promillebereich liegt, wird wieder ein Spline generiert, damit ein Knick vermieden. Dies ist sonst als Anregung wirksam! Diese Größenordnungen passen für mechanische Stellantriebe. Die Abtastzeit von 100 µs ist für genaue Positionierung angemessen.

Warum float statt double? Man trifft häufig auf die Haltung, es müsse immer double sein, heutzutage. Dazu ein Zitat

For good performance in C++, use float in all cases unless you actually need double.

Quelle: https://social.msdn.microsoft.com/Forums/en-US/2b190cfa-e221-4e91-b40c-c2a00aee4b36/float-vs-double-performance-on-arm


Der Artikel bezieht sich auf die X86-Architektur, selbst dort bei vorhandener double-Arithmetik gilt dies. Im Bereich der embedded-Prozessoren ist nun die Zielrichtung nicht vorrangig höchste Performance, sondern Kühlung, Leistungsaufnahme, Größe der Boards und des Gerätes und auch der Preis der Hardware. Folglich ist in embedded Prozessoren meist zwar float in Hardware realisiert, nicht aber double. Unter diesen Umständen geht es nicht nur um die Einsparung der halben Rechenzeit (wegen weniger Speicherzugriffen) sondern Faktoren >10, die zur Emulation der double-Arithmetik in der float-Umgebung benötigt werden.

Es lohnt sich also, mit etwas Programmieraufwand die Notwendigkeit des double zu umgehen, wenn die Ergebnisse in Ordnung sind. Der TimeSignals-FB lässt sich nach Codegenerierung auch in der Zielhardware unterbringen.

Eine Relalisierung in double für den Simulink-Einsatz ist mit wenig Aufwand möglich, aber erscheint unter diesen Umständen nicht notwendig.

*****