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.
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:
Rein textuelle Eingabe der Parameter der Zeitverläufe (Zeiten, Stützstellen, Übergang).
Grafische Vorgabe, Punkte setzen mit Maus, im Eingabefeld fein korrigierbar.
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.
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.
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:
XML.
Excel: Stimulis aus Messdaten werden mit dem Werkzeug Excel aufbereitet, Excel-Makro- und Rechenfähigkeiten werden genutzt.
Matlab: Matlab kann Excel importen, Aufbereitung kann mit Matlab-Scripts erfolgen, abspeicherung als Matlab-Daten (binär).
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:
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:
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.
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:
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
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
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.
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:
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.
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
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:
Projektmäßig zueinandergehörige Files sollten im gleichen Verzeichnis (-baum) stehen. Ursache der Überlegung ist: Schelles
auffinden zueinandergehöriger Dinge, aber auch ein schnelles Kopieren eines Standes (außerhalb des offiziellen Versionsmanagements)
beispielsweise auch in ein zipfile zur Weitergabe.
Große generierte Files stören in diesem Zusammenhang. Oft sind die eigentlichen Quellen eher im kByte-Bereich angesiedelt,
ein zip-File hat eine Größe im kleinen MByte-Bereich. Dies lässt sich einfach handhaben. Generierte Files oder Output-Files
(Log-Files) tendieren dagegen schonmal in den zig-Megabyte und sind nicht speicherwürdig. Man sollte also von vorhherein diese
etwas auslagern. Tip: Man kann eine RAMdisk einrichten. Bei RAM-Größen des PC von einigen GByte darf diese 512 MByte bis GByte
haben. Dort hinein kommen dann Outputfiles. Markanter Laufwerksbuchstabe, etwa T: hilft unter Windows. In Unix/Linux ist dies im Filebaum einhängbar.
Komponentendenkweise: Eine Komponente wird gebildet von zusammengehörigen Files für ein Thema, die miteinander versioniert
sind, aber gegenüber einer anderen Komponente etwas versionstolerant sein dürfen. Diese Files sollten in einem extra Verzeichnisbaum
plaziert sein, nicht gemischt mit anderen Files. Dann lässt sich eine Komponente als Ganze erfassen und austauschen.
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:
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:
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.
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.
