Gast schrieb:
Ok Zottel,
nun ist mir Sonnenklar was Du meinst, und der Sinn erschliesst sich mir auch völlig. ( Gut dass Du so hartnäckig warst ).
Gruss Hartmut
Es sind Möglichkeiten, aber da du vielleicht noch in einem frühen Stadium des Projekts bist, sollte man versuchen, das optimal zu lösen. Das heißt, es sollte kommerziellen Produkten und Hardware-SPS möglichst in nichts nachstehen. Im Detail:
Ein Event löst einen dump der internen Daten in ein File aus,
Ja das geht. Wenn ein Benutzer die korrigierte Zuckermenge in eine Eingabezeile eingibt und Enter drückt, ist das der Event. Ich mache Benutzeroberflächen oft lieber mit Plus- und Minustasten zum verändern eines Wertes. Grund: In einer Eingabezeile kann man sich schnell mal vertippen. Eines falsches Komma oder eine Null zuviel lösen eine sprunghafte Änderung im Prozeß aus. Was ist jetzt der Event? Jede einzelner Druck auf eine der Tasten. Hier müßte man vorsehen, daß der Speicherort des files und eventuell eine Verteilung der Daten auf mehrere Files konfigurierbar ist. Um absolut mit einer Hardware SPS gleichzuziehen, müßte der Benutzer seinen Rechner mit einer Ramdisk aus batteriegepuffertem SRAM ausrüsten und diese files dort hinlegen. Um Datensicherheit bei unterbrochenen physischen Schreibvorgängen zu erreichen, sollte erst das neue File geschrieben und dann das alte gelöscht werden. Dann kann höchstens eine Eingabe verloren gehen, genau wie wenn ich eine Kombination SPS/OP abschalte während jemand ändert.
Zusammen mit der Echtzeitfähigkeiit ist hier aber noch eine Sache zu bedenken: Soweit ich RTLinux kenne, macht der Echtzeit-Teil gar kein Disk-I/O. Er kann die Daten durch eine Pipe an einen Helfer-Prozeß im Userspace schicken und der schreibt für ihn. Wenn es aber nur ein einziges oder wenige Files gibt und da Batterie-SRAM keine Wartezeiten (seeks) wie eine Platte hat, bräuchte man auch gar kein filesystem, sondern der Echtzeit-Prozeß packt die Daten gleich in diese Batterie-RAM. Alternativ kann man das mit dem Helfer-Prozeß und Festplattendatei als "Billiglösung" vorsehen.
ein anderer Event holt den dump zurück und die SPS läuft mit diesen Daten weiter.
Das ist völlig unproblematisch. Das geht ohne Event einfach beim Neustart.
Da meine SPS ja als eine Art Daemon läuft ( die AWL als ASCII File auf der Platte ) waere es moeglich mit einem Signal die SoftSPS zum neulesen des Files zu bringen und das quasi ohne Unterbrechung.
Ein ASCII-file muß interpretiert werden. Deine Lösung funktioniert, wenn tatsächlich das ASCII-File Zyklus für Zyklus von neuem interpretiert wird.
Schneller gehts, wenn es einmal interpretiert wird und binäre Instruktionen daraus generiert werden. Das kann nach Art von Step7 im Programmierwerkzeug oder nach Art der JAVA/.NET just-in-time-Compiler einmalig beim Anlauf geschehen. Im 2. Fall solte es natürlich wieder ein Helfer-Prozeß im user space tun.
Dann kommt aber das Problem auf, daß beim Übergang auf ein geändertes Programm die Zykluszeit nicht mehr eingehalten wird.
Daher scheint es mir besser zu sein, es so zu lösen, wie es letztlich auch intern in einer S5 gemacht wird:
- Das Programm wird in binären Instruktionen abgelegt.
- Es ist zur Laufzeit nur dadurch änderbar, daß vorgegebene Blöcke insgesamt ausgetauscht werden (die PBs, OBs, FBs). Um das tun zu können, wird die Adresse so eines Blocks in einer Liste hinterlegt. Der Einsprung in den Code findet über diese Liste statt.
Die PG-Schnittstellen-Serviceroutine (s5) oder der Userspace-Helfer-Prozeß (Soft-SPS) schreibt den geänderten Block in unbenutzten Programmspeicher. Dann legt sie Blocknummer und neue Adresse in ein "Postfach".
Zwischen zwei Zyklen schaut nun der Echtzeit-Teil nach, ob er Post hat. Wenn ja, schreibt er die neue Adresse in die Liste, so daß ab jetzt der neue Baustein wirksam ist.