# SoftSPS sps4linux



## Anonymous (17 Oktober 2005)

Hallo,

ich programmiere das Open Source Projekt SPS4Linux, eine
SoftSPS die aus standart Linux PCs eine SPS macht.

Die neue Version 1.7.3 unterstützt zur Ausgabe neben 8255 PIOs auch
den IO Warrior 40 sowie den Dil/net PC.

Weitere Informationen findet Ihr unter:
http://www.eilers.net/sps/

Bei Fragen: Hartmut@eilers.net

Gruss Hartmut


----------



## Zottel (17 Oktober 2005)

Es gibt ja bereits das Projekt matPLC:
http://sourceforge.net/projects/mat
Was denen meiner Meinung nach fehlt ist:
- harte Echtzeitfähigkeit.
- persistente (remanente) Daten
- die Möglichkeit, Programmmodule zu verändern, ohne das Programm neu zu starten
Wie ist das bei deinem Konzept?


----------



## Anonymous (19 Oktober 2005)

Zottel schrieb:
			
		

> - harte Echtzeitfähigkeit.
> - persistente (remanente) Daten
> - die Möglichkeit, Programmmodule zu verändern, ohne das Programm neu zu starten
> Wie ist das bei deinem Konzept?



Keiner der von Dir angeführten Punkte ist in SPS4Linux realisiert.
Aus meiner Sicht wirklich interessant wäre die Echtzeitfähigkeit,
aber das ist Zukunftsmusik.

Gruss Hartmut


----------



## Zottel (19 Oktober 2005)

Gast schrieb:
			
		

> Aus meiner Sicht wirklich interessant wäre die Echtzeitfähigkeit,
> aber das ist Zukunftsmusik.


Ja, bloß eine vorhande Lösung auf RTLinux, RTAI oder andere Echtzeitsysteme zu portieren, bedeutet wahrscheinlich so gewaltige Änderungen, daß man besser gleich so anfängt.

- persistente (remanente) Daten
Wenn du z.B. eine S7 mit einem OP oder sonstwas hast, wo der Anwender Einstellungen vornimmt, werden die Daten in einen DB geschrieben. Der ist remanent über einen Neustart/Stromausfall sowie über stecken/ziehen/Austauch des OPs.  Und man möchte diese Daten ja nicht jedesmal neu eingeben... Hast du dafür etwas vorgesehen? Datei auf Festplatte wäre ja schon mal mehr als nichts.

- die Möglichkeit, Programmmodule zu verändern, ohne das Programm neu zu starten. Erstens haben sich die Leute daran gewöhnt, Programme an der laufenden Maschine ändern zu können, zweitens gibt es Anlagen, die man wirklich nicht für eine kleine Änderung stillsetzen möchte oder kann, drittens ist es ohne persistente Daten noch schlimmer: Jeder Test mit einer winzigen Änderung würde eben wieder die Neueingabe aller Einstellungen verlangen.


----------



## Anonymous (21 Oktober 2005)

Ich Deinen Ausführungen nicht ganz folgen.
Bisher habe ich den Bedarf persistente Daten zu halten oder Programmmodule während der Laufzeit zu ändern noch nicht gesehen, daher ist in dieser Richtung auch nichts implementiert.

Hartmut


----------



## Zottel (21 Oktober 2005)

Anonymous schrieb:
			
		

> Ich Deinen Ausführungen nicht ganz folgen.


Dann weiß ich auch nicht, wie ich es erklären soll, aber ich bin hartnäckig 

Persistente Daten:

Nehmen wir an, es gibt eine Maschine, die Schokoladenkekse macht. Für verschiedene Sorten sind Rezepte hinterlegt. Die stehen z.B. in einer Datenbank auf der Festplatte.
Rezept wird übertragen Produktion geht los. Krümelmonster von der Qualitätssicherung probiert die Kekse. Sie sind ihm nicht süß genug. Also stellt der Bediener die Zuckermenge etwas höher ein. Sie sind innen zu feucht. Also stellt er die Durchlaufzeit durch den Ofen etwas niedriger ein. Nun sind sie zu dunkel. Also stellt er den Ofen etwas kälter ein. 
Die Kekse sind jetzt gut und er produziert bis Freitag zu Feierabend. Übers Wochenende schaltet er den Hauptschalter aus.
Wenn die Maschine lauter Potis für die genanten Einstellungen hätte, könnte er Montag genauso weiter produzieren.
Wenn er eine S7 mit OP7-Bediengerät hätte, würden seine Einstellungen in einem DB überdauern.
In die Rezeptdatenbank will er die abweichenden Einstellungen nicht übernehmen, da sie nur ganz kleine Korrekturen sind (vielleicht um auszugleichen, daß der Zucker aus einer Charge weniger süß oder der Ofen ein etwas schmutzig oder die Luftfeuchtigkeit heute hoch ist) und nicht zu erwarten ist, daß sie einen Monat später noch gültig sind.
Persistente Daten erlauben also einfach nachzubilden, daß die Drehknöpfe am Montag noch in derselben Stellung stehen würden wie am Freitag, sofern keiner dran dreht.

Nun läuft die Keksproduktion gut, bis eine Störung auftritt: Ein Endschalter im Zuckerstreuselstreuer ist defekt, der Durchlaufofen hält an. Der Zuckerstreuselstreuer wird für das Produkt gar nicht gebraucht, aber der Programmierer hat das nicht bedacht und sein Programm schaltet den Transport ab. Der Servicemann möchte nun ganz schnell eine kleine Änderung am Programm vornehmen, um das zu korrigieren so daß die Fehlermeldung vom Zuckerstreuselstreuer nur ausgewertet wird, wenn auch laut Rezept Zuckerstreusel gestreut werden. Er kann aber nicht die ganze SPS stillegen, weil dann die Gasbrenner im Ofen ausgehen, der Ofen  gereinigt und neu angefahren werden müßte, der Teigrührer stillsteht und der Teig oben antrocknet usw. Außerdem hat er nicht lange Zeit, weil die Kekse auf dem stillstehenden Band im Durchlaufofen langsam verbrennen. 
Bei einer S7 oder auch den meisten SPS, die ich kennen gelernt habe, hätte er die Möglichkeit, eine zusätzliche Verknüpfung "U Zuckerstreuer_aktiv" in den Programmbaustein einzufügen und den geänderten Baustein in die SPS einzuspielen.


----------



## HeizDuese (22 Oktober 2005)

Vielleicht sollte die Fa. Beckhoff mal ihr TWINCAT nach Linux portieren, da ist alles drin


----------



## zotos (22 Oktober 2005)

Beckhoffs TwinCAT ist ja auch "nur" CoDeSys und dafür gibt es ein Target für RT-Linux  :lol: Leider nicht kostenlos.

http://www.3s-software.com/index.shtml?CoDeSysSPOEM_d


----------



## HeizDuese (22 Oktober 2005)

CoDeSys stellt meines Erachtens nur die Entwicklungsumgebung unter IEC 61131. Der Echtzeitkernel (Soft-SPS) ist nach meiner Information eine Beckhoff-Entwicklung.


----------



## Anonymous (24 Oktober 2005)

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 ).

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.

Das Speichern von Daten könnte man wie eine Art Suspend to Disk beim Notebook lösen. Ein Event löst einen dump der internen Daten in ein File aus,
ein anderer Event holt den dump zurück und die SPS läuft mit diesen Daten weiter.

Könnte Dich sowas befriedigen ?

Gruss Hartmut


----------



## Zottel (25 Oktober 2005)

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.


----------



## l_netwalker (25 April 2006)

@Zottel,

Du schreibst doch Visual oder ? ich würde SPS4Linux gerne mit Visual
"verheiraten" wie kann ich da einen passenden Treiber bauen ?

Pflegst Du visual noch weiter ?

Danke
Hartmut


----------



## drfunfrock (14 Mai 2006)

zotos schrieb:
			
		

> Beckhoffs TwinCAT ist ja auch "nur" CoDeSys und dafür gibt es ein Target für RT-Linux  :lol: Leider nicht kostenlos.
> 
> http://www.3s-software.com/index.shtml?CoDeSysSPOEM_d


Und so weit ich das richtig gelesen habe, hat Beckhoff einen speziellen Vertrag mit Microsoft. Schade eigentlich, aber zu verstehen ist es, wenn man bedenkt, wieviele Kernel und Distris da im Umlauf sind.  Wenn man auf dem Win-PC mit Beckhoff Soft-SPS allerdings nicht zu viel installiert, läuft er sehr gut.


----------

