Kennlinie liest Stützstellen aus Datei (DLL)

[tom_g]

Guten Abend,

vielleicht nützlich für diesen oder jenen ?

Viele Grüsse
tom_g

[Mike D]

Hallo tom_g,
interessante Lösung.
Gibt dim die Anzahl der Stützstellen aus?
Warum kommt ein neuer Ausgangswert nur im Takt von READ/ und nicht bei jedem Simulationsdurchlauf?
Und warum wird jedesmal die Tabelle neu eingelesen?
Ich halte es für logischer READ/ nur zum Einlesen der Tabelle zu nehmen und den Ausgang bei jedem Durchlauf neu zu berechnen.
Womit programmiert?

Ein Tip für die, die das Testprojekt nutzen, in die Vorgabe von $EDT2 den Pfad eintragen in der das Testprojekt ausgepackt ist, mit abschießenden \ .

Grüße von der Nordsee in die Schweiz

Michael

[tom_g]

Hoi Mike D,

danke fürs Feedback.

Ist ein erster Wurf, ich bin offen für Verbesserungen !

- Gibt dim die Anzahl der Stützstellen aus? -> Ja

- Warum kommt ein neuer Ausgangswert nur im Takt von READ/ und nicht bei jedem Simulationsdurchlauf? -> weil das Filehandling dann wohl nicht mitmacht oder das OS lahmlegt ? Habe ich allerdings nicht probiert, was dann geschehen würde. Meine Philosophie ist es, den Zeitpunkt der Programmausführung (und damit den zusätzlichen entstehenden CPU load, auch wenn dieser hoffentlich sehr gering ist) genau kennen zu wollen, daher ein getaktetes System.

- Wieso wird das File periodisch geladen ? -> Viel wichtiger für mich ist aber das damit realisierbare Online-Editierverhalten: die Kennlinie (das Tabellenfile) kann während der Laufzeit von PL mittels einem Texteditor modifiziert werden. Nach der Speicherung der Tabelle im Editor wird die Aenderung unmittelbar in PL verfügbar. Aus diesem Grund wird das File periodisch gelesen.

- Ich halte es für logischer READ/ nur zum Einlesen der Tabelle zu nehmen und den Ausgang bei jedem Durchlauf neu zu berechnen. -> ist ganz einfach zu ändern, falls Du das so brauchst, lass es mich wissen.

- Womit programmiert? -> Euphoria 3.1.1 (www.rapideuphoria.com), Translator zu C, OpenWatcom. Wenn Du interessiert bist, kann ich Dir die Source zusenden.

Freundliche Grüsse: Thomas

[Mike D]

Das ständige Nachladen des Files erzeugt meiner Meinung nach eine wesentlich höhere CPU-Last als eine Berechnung bei jedem Simulationsdurchlauf, du hättest aber viel glattere Kurven. Das periodische Nachladen könntest du dann nur bei Bedarf einschalten und wesentlich langsamer takten (1 bis 2/sec).
In was für einer Anwendung nutzt du das?

Mike

[tom_g]

Hoi Mike D,

ich werde das mit der CPU Last mal zu messen versuchen. Meine Vermutung ist, dass das File IO nicht ab HD, sondern aus dem Cache geschieht, was dann nicht so schlimm ist, aber unbestritten braucht der Vorgang Ressourcen.

Ich habe das Teil als Interface zu PL geschrieben. Eine externe Anwendung (Sequencer *), mit eigens für Abläufe und Entscheidungen geeigneter sehr schlanker Programmiersprache, schreibt Variablen und Werte in ein Textfile. PL liest und filtert die Variablen und lässt nur durch, was als Name erkannt wird.

Wann und was vom Sequencer "serviert" wird, ist PL a priori nicht bekannt, daher benötigt dieses das "Polling" = periodisches Abfragen des Textfiles. Die Anwendung entscheidet, wie häufig das zu geschehen hat. I.d.R reicht das für viele Anwendungen mit der Rate, welche Du genannt hast, speziell für Sollwertführungen. (2Hz)

Spezifisch messe ich einen Gasmultiblock parametrisch aus. Dazu benötige ich 3 Sollwerte, welche schlussendlich eine X_Y_Z "Freifläche" abfahren. Damit habe ich alle Kenngrössen erfasst, welche für den kommenden Einsatz des Multiblocks erforderlich sind.

Ich hätte den "einfachen" 3-D-Scanner in PL implementieren können, es gibt aber Abhängigkeiten der drei Steuergrössen, welche viel einfacher in der Sequencer-Programmiersprache beschreibbar sind. Hingegen ist PL die geschickte Regler- und IO-Ebene, hier ist das Teil eben super geeignet.

BTW * Sequencer habe ich auch in Euphoria geschrieben.


Viele Grüsse von Thomas