Hallo,
ich möchte jetzt ernsthaft meine kleine Bahn mit Stellwerkslogik aufrüsten. Also keinen Automatikbetrieb aber über digitale Logik
die nötigen Abhängigkeiten in software realisieren. Verriegleung von Fahrstraßen, Zuganbieten an 2.Fahrdienstleiter, annehmen, Erlaubnis verriegeln und für Gegenausfahrten sperren.

SPS-Programmmierung mit S5 und GE-Fanuc-micro90 in AWL habe ich genügend.

Meine Signale und Weichen kann ich bereits mit Optokoppler getrennt via Triac oder ULN2803 ansteuern, ebenso habe ich galvanisch getrennte 5V-Signale für Gleisbelegtmeldungen oder Durchfahrten, also Zugschlußmeldungen mit Hall-Elementen..

Wunschendausbau wäre ein android-fingertip-display zum Signal- und Weichenstellen.

Vorstellung wäre Betrieb spielen mit getrennter Fahrdienstleiterfunktion und Treibfahrzeugführern, an Signalen KEINE Zugbeinflussung aber INDUSI simulieren und Not-Halt....


Die Frage also von der Anzahl I/O reicht mir Arduino-Due, bei Raspberry müßte ich I/O deutlich erweitern, für welche CPU gibt es eine soft-SPS?

Ich möchte weil ich Assembler und SPS-AWL kenne die Logik selbst entwickeln, nicht an Vorgaben wie bei Märklin_Memory oder ähnlich gebunden sein.

Von der Informtik her betrachte ich die Stellwerklogiken als Zustandsautomaten mit eideutigen Übergängen.

Hallo,
so was ähnliches habe ich auch gebaut (s. Signatur) - mit Fahrdienstleiterfunktion und ohne Zugbeeinflussung vor dem Signal, aber mit Indusi. Bei der Bedienung habe ich aber vorbildnah auf mechanische Schalter gesetzt.
Ich weis nicht, wie groß deine Bahnhof ist, und wieviel Weichen/Signale du ansteuern musst und wieviele Fahrstraßen zu verwalten sind. Bei mir hat für die Logikfunktionen ein ATMega-Prozessor locker ausgereicht - und der hat neben der reinen Fahrstraßenlogik noch einiges andere zu tun. (Damals noch nicht als 'Arduino', würde ich aber heute wohl machen)
Was mich beim Raspberry Pi ein wenig stört ( der läuft ja unter Linux ) ist, dass man den eigentlich nicht einfach ausschalten sollte, sondern ordentlich runterfahren muss. Wobei ich den bei meiner Schattenbahnhofsteuerung schon auch mit einem Touch-Panel zur Bedienung eingesetzt habe. Allerdings direkt programmiert und nicht über eine Android-App. Weshalb willst Du auf Android gehen? Mit einem X-Server unter Android ist dann allerdings die Bedienung auf einem Android-Tablet auch möglich,
Obwohl mein ATMega auch eine ganze Reihe IO's hat, habe ich aber doch auf I/O-Erweiterung über SPI und I2C gesetzt. Da kann man viel Verdrahtung sparen, wenn man dezentral etwas Elektronik einsetzt die die parallel/seriell Umsetzung macht (ähnlich wie der S88 Bus). Das würde dann auch direkt mit dem Raspberry gehen.

Ob es für den Arduino eine Soft-SPS gibt, weis ich nicht. Aber braucht man das wirklich? Die SPS Programmprinzipien lassen sich doch auch direkt in der Arduino IDE-realiseren: Eingänge einlesen - Signale verarbeiten ( Zustandsautomaten ) - Ausgänge schreiben und das in einer Schleife.

Hallo,
danke für die Hinweise, an android dachte ich als Weg zu einem preisgünstigen touch-display. Dein Hienweis auf I²C ist auch richtig.
Welche Zykluszeit lässt sich bei Arduinos erreichen? Gefragt ob kurze Signale wie Reed-Kontakte vor der Datentechnik mittels flip-flop zu speichern wären.

200km/h Modellgeschwindigkeit, man fährt meistens zu schnell = ca.70cm/s. Reedkontakt oder Hallelement ca. 2cm Erfassugnsbereich in Längsrichtung = 30ms als ungüstigster Fall für die Signalzeit. Alos sollten 20ms Zykluszeit eingehalten werden können oder flip-flops...

Zitat von SET800

---

Welche Zykluszeit lässt sich bei Arduinos erreichen? Gefragt ob kurze Signale wie Reed-Kontakte vor der Datentechnik mittels flip-flop zu speichern wären.

---

Hängt natürlich sehr davon ab, was er alles zu tun hat. Meine Bahnhofssteuerung hat derzeit eine mittlere Zykluszeit von 47ms. Wäre für deinen Fall also zuviel. Das ist allerdings noch ein anderes System (vom großen C), das mit einem Interpreter arbeitet. Der verwaltet neben der eigentlichen Fahrstraßenlogik aber auch noch die interaktive Bedienoberfläche mit Tastatur und Display.
Der Due wär auch deutlich schneller und wenn man für die reine Logik oder die Verwaltung der Eingangssignale einen eigenen Arduino hernimmt ( die Klone sind ja recht preiswert ) dürfte das mit den 20ms schon hinkommen. Ich habe meine HW aber grundsätzlich so ausgelegt, dass ich nicht von der Zykluszeit abhängig bin. Wenn Du den Raspberry einsetzen willst, ist das noch wichtiger, den Linux ist keine Echtzeitbetriebssystem (wobei es für den Pi wohl auch ein Echtzeitbetriebssystem gibt, das kenne ich aber nicht )

Als günstige "richtige" SPS-Lösung bietet sich auch noch CODESYS für den Raspberry-Pi an.

http://store.codesys.com/codesys-control...erry-pi-sl.html

Die Vollversion lässt sich gratis nach Anmeldung im CODESYS-Store herunterladen.
In der unlizenzierten Version ist dann die Laufzeit im Raspberry Pi auf 2 Stunden begrenzt.
Einfach mal testen!!!

Zitat von SET800

---

[...] aber über digitale Logik die nötigen Abhängigkeiten in software realisieren. Verriegleung von Fahrstraßen, Zuganbieten an 2.Fahrdienstleiter, annehmen, Erlaubnis verriegeln und für Gegenausfahrten sperren. [...] Wunschendausbau wäre ein android-fingertip-display zum Signal- und Weichenstellen. [...]

---

moinmoin,
auch ich habe ein ähnliches Projekt realisisiert http://stummiforum.de/viewtopic.php?p=1123654#p1123654. Ein ATMega reicht sicher, um die Funktion abzubilden. Mein ATMega1284P Programmspeicher ist jetzt zu 12% voll und außer der Fahrstaßenlogik ist alles fertig programmiert. Du mußt halt entscheiden, ob Du ein Betriebssystem haben möchtest, oder ob Du direkt auf der Hardware in C oder Assembler programmieren willst. Da ich mich in SPS-Programmierung nicht auskenne, war das für mich kein Thema. Allerdings muß ich feststellen, daß die Programmierung in C nur beschränkt für intensives Bitgefummel geeignet ist. Wie immer eine Frage der persönlichen Erfahrungen und Vorlieben...

schönes Wochenende,
Michael