Rechnersteuerung ohne teure Zentraleinheit - Teil 3 - SRCP-Clients

[Epoche VI]

Hallo,

im vorigen Thread habt ihr die Hardwarekonfiguration für DDW/DDL kennengelernt. Dort war zu sehen, dass man die Programme über verschiedene Rechner mit unterschiedlichen Betriebssystemen (Linux/Windows) verteilen kann.
Sowohl DDL als auch DDW arbeiten nach dem SRCP-Protokoll.

Für Leute mit Märklin-Interface M6051 ist die DDL-Rubrik besonders interessant und für Leute mit Uhlenbrock Intellibox die TrackONE-Rubrik.

SRCP = Simple Railroad Command Protocol
Link http://srcpd.sourceforge.net/srcp/
​

Die aktuellen Versionen sind 0.7.3 und 0.8.2. Die Protokoll-Spezifikationen werden von zur Zeit 12 Leuten weiterentwickelt. Das Konzept ist zwischen 0.7 und 0.8 stark geändert worden und daher müssen die SRCP-Clients auf eine spezielle Version ausgelegt sein. Manche SRCP-Clients unterstützen sogar beide Versionen.

Eine Auflistung von Servern und Clients findet man auf:
Link http://www.der-moba.de/Digital


Hier kommen Informationen zu den SRCP-Servern:

DDL = Digital Direct for Linux
Link http://www.vogt-it.com/OpenSource/DDL
Programmversion 1.4.0 / XMAS 2001 (Stand 04.04.04)
SRCP-Protokoll 0.7.1 (Stand 04.04.04)

Programmversion 1.5.0 (Stand 04.04.04)
SRCP-Protokoll 0.8.2 (Stand 04.04.04)
​

Hierzu kann ich nur sagen, dass der DDL-Server (Daemon) erddcd (Electric Railroad DigitalDirect Command Daemon) heisst und ein Kommandozeilen-Programm für Linux ist. Es gibt eine stabile Version für SRCP 0.7.1 und eine Entwicklerversion für SRCP 0.8.2.
Man kann den DDL-Server auch per TELNET ansprechen.
Zu Linux kann ich zur Zeit keinerlei Client-Tests bieten, da zur Zeit kein Linux installiert habe und auch den DDL-Daemon von der Bedienung her nicht so sinnvoll finde.
Neben den normalen grafischen Linux-Clients für DDL gibt es auch DDSH (Digital Direct Shell) oder RCSH (Railroad Command Shell). Das sind SRCP-Clients mit denen man Scripts für bestimmte sich wiederholende Modellbahnsteuerungsabläufe erstellen kann.
Ein weiteres Highlight für Linux-Benutzer ist die Möglichkeit, das Märklin-Interface M6051 zu emulieren und dann auch NICHT-SRCP-Software wie z.B. Railroad&Co zu verwenden:



Ob das gut funktioniert kann ich aber wegen fehlenden Testmöglichkeiten nicht sagen.

DDW = Digital Direct for Windows
Link http://home.snafu.de/mgrafe/
Programmversion 0.68 (Stand 06.04.04)
SRCP-Protokoll 0.7.3 / 0.8.0 (Stand 04.04.04)
​

Den DDW-Server kann man über die Programmeinstellungen entweder auf SRCP 0.7.3 oder auf 0.8.0 konfigurieren.
Ein kleiner Nachteil ist, dass man nur COM1 oder COM2 einstellen kann. Wenn man also eine Schnittstellenkarte drin hat, kann man die nicht benutzen (außer man schaltet die Mainboard-Schnittstellen ab).
Für Windows NT, 2000, XP benötigt man einen Treiber für die serielle Schnittstelle. Funktioniert dann aber hervorragend.
Es gibt den DDW-Server auch als Dienst für NT, 2000, XP, jedoch nur in der älteren Version 0.66.
Etwas nachteilig ist, dass der DDW-Server manchmal durch bestimmte Konstellationen / Clients eine CPU-Auslastung von 100% auslösen kann.

TrackONE - Server für Windows
Link http://www.reukauff.de/TrackONE/
Programmversion 1.3 Build 1452 (Stand 04.04.04)
SRCP-Protokoll 0.7.3 (Stand 04.04.04)
​

Eine Server-Version für SRCP 0.8.2 ist in Arbeit.
TrackONE ist ein spezieller SRCP-Server zum Betrieb mit Uhlenbrock Intellibox.
Ich kann den TrackONE - Server nicht testen, da ich keine Intellibox habe, jedoch ist schon ersichtlich, dass man COM1-COM4 einstellen kann.



Und jetzt kommen Informationen zu SRCP-Windows-Clients (mit DDW getestet):

1. Gplan
   
   
   Link http://home.snafu.de/mgrafe/
   Programmversion 0.60 (Stand 04.04.04)
   SRCP-Protokoll 0.7.3 / 0.8.0 (Stand 04.04.04)
   ​
   Es gibt sowohl diese Version für Windows als auch eine für Linux.
   Bei mir macht das Programm einige Grafikfehler. Unter bestimmten Konstellationen bringt es den DDW-Server zu einer CPU-Auslastung von 100% (zum Beispiel: Lok auf Märklin-Dekoder eingestellt, obwohl man DCC hat).
   Es bietet eine Selbstbau-Fahrregler bzw. Joystick Unterstützung, die bei mir jedoch nicht den gewünschten Effekt zeigte.
   Man braucht so einige Klicks, bis man Betrieb machen kann.
   
   
   
2. Railyplan
   
   
   Link http://home.snafu.de/mgrafe/ (keine eigene Homepage)
   Programmversion 1.2 (Stand 04.04.04)
   SRCP-Protokoll 0.7.3 (Stand 04.04.04)
   ​
   Man braucht so einige Klicks, bis man Betrieb machen kann. Vor allem fehlt die Liste der zuletzt geöffneten Dateien.
   Der Gleisplan-Editor ist gut, jedoch sieht man die Gleis-Symbole nicht auf einen Blick (scrollen erforderlich).
   Sehr gut ist das Hinterlegen von eigenen Bildern für die Lok-Thumbnails.
   Die Aktivierung von Rückmeldern kann man an das Abspielen von eigenen Sounds anbinden.
   Leider keine Möglichkeit der Loksteuerung ohne Maus (keine Joystick-Unterstützung).
   Es bietet eine Automatik-Funktion wie Fahrstraßen und Stellbedingungen (die anhand von ausgelösten Rückmeldern auch Weichen schalten können).
   Super wäre noch, wenn man auch Lok-Abhängigkeiten (Lok bremsen oder anfahren lassen) bei Auslösung bestimmter Rückmelder einstellen könnte.
   
   
3. TRAINer
   
   
   Link http://members.aon.at/pkeintze/html/at/hobby/eisenbahn.htm
   Programmversion B1.0 (Stand 04.04.04)
   SRCP-Protokoll 0.8.2 (Stand 04.04.04)
   ​
   Gerade erst aus dem Ei geschlüpft, kann man unter Umständen schon mal eine Lok bewegen. Es steckt noch in den Kinderschuhen. Nur einfachste Tools im Gleisplaneditor.
   Man kann Töne auf Tastenklick abspielen.
   Das Stellpult bietet Vorwärts- und Rückwärtssteuerung, jedoch ist es noch fehlerhaft und reguliert die Geschwindigkeit nicht korrekt.
   Rückmeldung ist (nur) für das HSI-88 über serielle Schnittstelle am Client-PC eingebaut (konnte ich nicht testen). Die Automatik-Funktion ist in Vorbereitung.
   Sehr gut sind die Optionen: Projekt beim Start öffnen und automatisches Starten des DDW-Servers sind vorbildhaft für andere SRCP-Clients.
   
   
   
4. JTrain
   
   
   Link http://www.jtrain.de/
   Programmversion 0.1 (Stand 04.04.04)
   SRCP-Protokoll 0.7.3 (Stand 04.04.04)
   ​
   Der Gleisbildeditor gibt schon ein paar Symbole her, wobei man trotzdem noch einige vermißt.
   Das Programm scheint eine sehr umfangreiche Automatik-Funktion zu haben, die ich noch nicht testen konnte.
   Das Lok-Steuerpult hat leider eine getrennte Steuerung für vorwärts und rückwärts (man muss immer erst die Buttons für den Richtungswechsel anklicken).
   
   
   
5. Enjoy The Time
   
   
   Link http://members.aon.at/geramb/enjoythetime.htm
   Programmversion 1.0.1526.35772 (Stand 04.04.04)
   SRCP-Protokoll 0.8.2 (Stand 04.04.04)
   ​
   Bisher kein Test möglich. Das Programm kann keine Verbindung zum DDW-Server herstellen.
   
   
   
6. TrackONE - Client
   
   
   Link http://www.reukauff.de/TrackONE/
   Programmversion 1.1.0 (Beta) Build 2151 (Stand 04.04.04)
   SRCP-Protokoll 0.7.3 (Stand 04.04.04)
   ​
   Wegen fehlender Intellibox kein Test möglich.
   
   
   

Bewertung:
Allgemein:

Gplan +
Railyplan +++
TRAINer +++ (für die sehr guten Optionen)
JTrain ++
Enjoy The Time
TrackONE
​

Gleisplaneditor:

Gplan +
Railyplan ++
TRAINer +
JTrain +
Enjoy The Time
TrackONE
​

Lok-Einstellungen:

Gplan +
Railyplan +++
TRAINer ++
JTrain +
Enjoy The Time
TrackONE
​

Lok-Steuerung:

Gplan +(+ Joystick)
Railyplan ++
TRAINer +
JTrain +
Enjoy The Time
TrackONE
​

Rückmeldung:

Gplan +
Railyplan +++
TRAINer +
JTrain +
Enjoy The Time
TrackONE
​

Automatik:

Gplan - (keine)
Railyplan ++
TRAINer (+ in Arbeit)
JTrain ++
Enjoy The Time
TrackONE
​

Ausblick:
Für Railware ist SRCP-Unterstützung geplant.
Link http://www.railware.de




------------------------------
Lebenslauf dieses Beitrags:
erstellt: 04.04.04
Stand: 06.04.04
Fortschritt Teil 3: 100 % (wegen fehlender Zeit vorerst fertig)
Edits:
Zuletzt bearbeitet von Epoche VI, 04.4.04 um 11:50. Grund: Beschreibungen zu den Clients
Zuletzt bearbeitet von Epoche VI, 06.4.04 um 22:16. Grund: Beschreibungen zu den Clients

Hier findet Ihr Teil 1 (Auswahl): http://www.tt-board.de/forum/showthread.php?t=2289
Hier findet Ihr Teil 2 (DDW/DDL-Hardware): http://www.tt-board.de/forum/showthread.php?t=2325

 

[TRAINer!]

Hallo,

ich will mich kurz vorstellen: Meine Name ist Peter K. und ich bin der Entwickler des SRCP-Clients TRAINer!. Mit Interesse habe ich hier den Vergleich aller SRCP-Clients gelesen und möchte nun die Chance nutzen euch folgendes zu Bitten:

Alle Wünsche und Anregungen, welche Ihr zu TRAINer! habt, bitte an die E-Mail Adresse Trainer@Keintzel.at zu senden. Da mein Client, wie bereits erwähnt, noch in der frühen Phase der Entwicklung steckt, bin ich für alle Hinweise sehr dankbar.

Mit bestem Dank, Peter

 

[Epoche VI]

RR&Co bzw. Railware mit DDW/SRCP bald möglich!

Hallo,

wie aktuell im DDW-Newsletter zu lesen ist, laufen erste Tests mit einem M605x Emulator, die einen Betrieb von Railroad & Co bzw. Railware mit DDW bzw. SRCP möglich macht (allein mit Booster und PC-Adapterkabel ohne teure Zentraleinheit).

Roman Lauer hat dazu den Grundstein mit einer M605x Emulator Delphi-Komponente gelegt.
Michael Gräfe, der auch den DDW-Server und Gplan entwickelt hat, arbeitet gerade an einem Tool, das RR&Co bzw. Railware eine Märklin M605x Zentraleinheit an einem virtuellen seriellen Port vorgaukelt und dabei die M605x Signale in SRCP-Befehle umsetzt.

Zur Zeit werden die letzten Kinderkrankheiten beseitigt. Ein Tester berichtet, dass es ansonsten wunderbar funktioniert.

PS: wenn euch die nötigen Voraussetzungen für DDW interessieren, dann sucht mal nach meinen anderen Threads "Rechnersteuerung ohne teure Zentraleinheit ..."

 

[rocomania]

Hallo Leute

ich beschäftige mich seit kurzem mit dem Thema DDW / DDL. Zu diesem Zweck habe ich mir verschiedene Softwaren als Demos downgeloaded. U.a. auch den TC 5 von Railroad&Co. Nach prüfen der SW stellte ich fest,das diese nicht über DDW funktioniert, sondern nur mit etablierter Hardware verschiedener Hersteller. Daraufhin habe ich mir erlaubt, mal die Leute von Railroad&Co zu kontaktieren. Mit der höflichen Frage, ob den Ihre Software nicht auch ohne diese HW zu betreiben ist. Die Antwort die ich erhielt war mehr als nur unerfreulich ( ). Sie lautet, so nach dem Motto:" Kauf Dir was teures dann geht auch unsere Software". Das ist jetzt zwar nur übertragen, aber letztendlich ist es so. Es hieß in der Mail, das sie ihre SW nur auf qualitativ, hochwertigen und datentechnischen abgesicherten Hardwareschnittstellen läuft. Und das senden der Gleissignale direkt an einen Booster stellt eben keine solche dar. Da war kein Hinweis von wegen "Benutze doch einen Emulator" oder "Ja, da ist gerade jemand dabei ein Lösung zu finden". Oder sind die Leute Betriebsblind ??? Was bitteschön macht eine CU anders als ein PC ? Abgesehen vielleicht von den Pegeln an der RS232 !!!!!!!!
Traurig, Traurig die Angelegenheit. Zum Glück wissen aber andere immer mehr , scheinbar auch als der Hersteller selbst ;-)

Zum Glück fand ich dann RailroadExpress und die SW unterstützt DDW.

 

[RolandW]

Hallo rocomania,

wo gibt es das Railroadexpress- Programm? Kannst du mal einen link angeben oder was näheres dazu sagen.

Übrigens gibt es in der neuen RAILYPLAN-Version eine Möglichkeit, über eine (fast beliebige, im Haushalt vorhandene) IR-Fernbedienung Loks, Weichen usw. zu bedienen.
Habs getestet. Bei mir gings prima- die Idee ist einfach klasse.

Gruß Roland

 

[tokaalex]

Stellungnahme

hallo leute,

ich stelle hiermit zum Beitrag von "rocomania" eine Stellungnahme von Jürgen Freiwald (TrainController) ins Forum, da er sich nicht extra dafür anmelden und diesen Beitrag auch nicht unkommentiert stehen lassen wollte:

Zitat Anfang:

"Möglicherweise war meine Antwort an Sie nicht ganz unmissverständlich
formuliert. Das Wort "teuer" habe ich in meiner Antwort nicht verwendet. Das
Schlüsselwort war vielmehr die Passage "qualitativ hochwertig und
datentechnisch abgesichert".

Mit "datentechnisch abgesichert" ist folgendes gemeint: wenn die
Gleissignale direkt an den Fahrzeugempfänger geschickt werden, so entsteht
dadurch eine direkte Datenverbindung zum Fahrzeugempfänger. Das heisst: der
PC tauscht direkt mit dem Fahrzeugempfänger Daten aus. Ein eventuell
zwischengeschalteter Booster spielt hier keine Rolle, da er hier nur
elektrisch, nicht aber datentechnisch einwirkt. Diese Datenverbindung ist
aber aus technischer Sicht natürgemäss alles andere als "datentechnisch
abgesichert". Es gibt hier prinzipbedingt keinerlei Handshake,
Quittungsmechanismen oder Absicherungen für Kommunikationsstörungen, u. ä.
Diese Art Schnittstelle entspricht nicht dem, was wir für unsere Software
als Mindestanforderung festgelegt haben.

Unter "qualitativ hochwertig" ist folgendes zu verstehen: wir geben unsere
Software aus Qualitätsgründen grundsätzlich nur für die Kommunikation mit
solchen Geräten und Gerätekombinationen frei, die wir selbst getestet haben.
Im Moment sind dies ca. 30 Digitalsysteme und Schnittstellen. Bei
Direktbetrieb a la DDW / DDL müssten wir unsere Software seriöserweise auch
noch mit allen am Markt verfügbaren Decodern verifizieren, um dieselbe
Qualität garantieren zu können. Dies ist wirtschaftlich natürlich nicht
darstellbar. Aber auch wenn wir nur mit ausgewählten Decodern testen und uns beim Rest auf die Einhaltung der NMRA-Norm verlassen würden, so
müssten wir damit rechnen, dass es im Einzelfall zu technischen Problemen im
Zusammenspiel zwischen unserer Software und bestimmten Decodern kommen kann
(Beispiele für solche Probleme im Zusammenspiel zwischen existierenden
Digitalsystemen und bestimmten Decodern gibt es schliesslich genug). Auf
solche Probleme und den damit verbundenen Zusatzaufwand wollen wir uns nicht
einlassen.

Natürlich sind uns auch die technischen Lösungen und Alternativen bekannt.
Dass wir diese nicht empfehlen, hat nichts mit Betriebsblindheit zu tun,
sondern damit, dass wir nur Lösungen empfehlen, die wir auch selbst
ausprobiert haben.

Sie haben in Ihrer Anfrage höflich und prägnant nach "geht" oder "geht
nicht" gefragt und ebenso höflich und prägnant ein "geht nicht" als Antwort
erhalten. Dass Sie möglicherweise auf etwas anderes gehofft haben und diese
Antwort daher unbefriedigend oder unerfreulich war, kann ich gut verstehen.
Aber mehr als die ehrliche Antwort, dass unsere Software die von Ihnen ins Auge gefasste Konfiguration nicht unterstützt, kann ich Ihnen nun einmal nicht geben."

Mit freundlichem Gruß,
Jürgen Freiwald

Zitat Ende!

 

[Lokwolf]

@tokaalex

Danke für die Einstellung des Zitats.
Da funktioniert die Kommunikation mit den Herstellern ja doch besser als manche glauben machen wollen.

Jürgen Freiwald ist aber ausdrücklich eingeladen, hier mitzumachen! Denn gerade in diesem Board werden ja Steuerungsthemen des öfteren behandelt. Vielleicht kannst Du es ihm ja vermitteln.

Gruß vom Rhein
Lokwolf

 

[tokaalex]

@ lokwolf,

das wird aus zeitlichen gründen wohl leider nicht möglich sein, da er das tc-eigene forum ja auch noch neben dem software-support und der weiterentwicklung der produkte zu betreiben hat.

aus diesem grund wäre es besser, wenn dann spezielle fragen direkt in diesem forum geklärt werden würden, da es auch unterteilt ist in "hardware" und "software".

 

[Maercz]

... das kann man aber auch nicht ganz unkommentiert stehen lassen, denn es liegt seitens SRCP sehr wohl eine "datentechnische Sicherung" vor! Es liegt bei SRCP mit DDL/DDW sogar eine sehr ähnliche Abgrenzung vor, wie in jeder anderen Digitalzentrale - auch und insbesondere hätte TrainController nichts mit der Signalerzeugung zu tun. Insofern sind die Argumente auch nicht schlüssig, denn es müsste weder ein Dekoder, noch eine Zentrale getestet werden. Vielmehr muss nur die Protokollkonformität übeprüft werden, wobei sogar der Test eines einzigen DDL/DDW Servers (oder der Referenzimplementierung) ausreichend ist. Von "unüberschaubarem Aufwand" kann also meines Erachtens keine Rede sein dürfen.

Der einzigste wesentliche Unterschiede zwischen der DDL/DDW- und der Digitalzentralenvariante ist und bleibt der physische Ort des Signalerzeugers. Werkelt in Digitalzentralen ein eigener Mikroprozessor mit vermutlich ähnlicher Software wie es durch DDW/DDL geschieht, wird dieser eigenständige Prozessor in DDL/DDW-Systemen durch einen eigen Prozess (+Thread) auf der CPU des Host-Computers ersetzt. Selbst die Steuerung des Signalerzeugers ist ähnlich - während die Signalerzeuger in Digitalzentralen ihre Steuerbefehle über proprietäre Protokolle (RS, LocoNet, ...) empfangen geschieht dies im Falle von DDW/DDL durch die TCP/IP-Schnittstelle.

Was Hr. Freiwald sicher meint ist zwar, dass keine datentechnische Absicherung seitens des Signalerzeugers (hier DDL/DDW-Servers) vorliegt, aber diese liegt bei den herkömmlichen Digitalzentralen auch NICHT vor. Bis auf das Lenz'sche System gibt es keinerlei Möglichkeit im Fahrbetrieb von den Lokdekodern Bestätigungen über das Gleis zu empfangen - das anliegende Digitalsignal läuft also an dieser Stelle unidirektional hin zum Dekoder. Daran ändert der Ort des Signalerzeugers herzlichst wenig.

Eine "datentechnische Absicherung" liegt nach Hr. Freiwald also höchstens zwischen der Zentrale und dem Steuercomputer vor. Doch genau diese "datentechnische Absicherung" bietet auch der DDL/DDW Server, jeder abgegebene Befehl wird entweder bestätigt oder mit einer Fehlermeldung abgewiesen. (siehe SRCP-Protokoll!)

Meiner Meinung können das also nicht die wahren Gründe sein - ebenso halte ich es für relativ einfach, die gängigen Softwarepakete DDL/DDW-fähig zu machen, denn es müsste nur ein einziges Modul, wie es für jede Zentrale bereits vorliegt, neu geschrieben werden. Wurde die Software gut designed, müssten die Hersteller eine Art Hardwareabstraktionsschicht implementiert haben, welche sich an das SRCP sehr einfach anpassen lassen müsste - schließlich sind die übertragenen Informationen gleicher Natur, nur das Format unterscheidet sich.

P.S. Das Protokoll zwischen der Lenzzentrale über RS232 und SCRP sind übrigens sehr ähnlich, alle bestehen aus einer Initialisierung, einem Datum für je einen Befehl (z.B. Lokfahrstufe oder Schaltdecoder), der Adresse und den Parametern.

Ich vermute hingegen viel mehr (nein, dass lass ich jetzt lieber ) ...

 

[Lokwolf]

Wie sieht es mit der Echtzeitfähigkeit (gerade des DDW) aus?
Windows garantiert diese ja nicht.
Wie kann die Software diese dann sicherstellen?
Ich gehe mal davon aus, dass das ein der Voraussetzungen für eine automatische Steuerung ist.
In einer Zentrale mit einem Microchip ist das relativ einfach. Vielleicht liegt auch genau da das Problem für dei Steuerungssoftware?

Mögen sich die Spezialiten mal außern...

Gruß vom Rhein
Lokwolf

 

[Maercz]

Jo, "echtzeitfähig" ist DDL/DDW natürlich nicht - alle Befehle werden nur so schnell wie möglich umgesetzt. Da ich leider (noch?) keine Digitalzentrale besitze, kann ich nun natürlich nicht behaupten, diese seien nicht oder doch echtzeitfähig, aber ich halte das zumindest für sehr unwahrscheinlich dass diese echtzeitfähig sind, denn man liest doch hin und wieder von Abstürzen oder langen Reaktionszeiten. Auch ist die Kommunikation zwischen Computer und Signalerzeuger nicht "echtzeitfähig", übrigens in beiden Fällen nicht!

Ein einziges Problem (theoretischer Natur) bleibt natürlich, dass bei Überlast des Host-Rechners auch der Signalerzeugerprozess nicht mehr genügend Rechenzeit bekommt. An dieser Stelle sitzt man zur Zeit noch auf zwei Stühlen. Einerseits läßt sich der Signalerzeugerprozess so konfigurieren, dass er die höchste Priorität im System erhält und damit immer die angeforderten Ressourcen bekommt - als Anwendungsprozess lässt sich dieser dann nur noch durch das Betriebssystem selbst oder durch Hardware-Treiber unterbrechen. Allerdings gibt es wohl doch noch einige Bugs im Server, ... Offiziell wird als Konfiguration aber sowieso ein eigener dedizierter eigener (alter) Rechner empfohlen, was dann wiederum keinen Unterschied mehr zu Digitalzentralen macht.

Nicht verwechseln sollte man übrigends DDL/DDW mit SRCP. DDL/DDW sind die Signalerzeugerprozesse, SRCP ist das Steuerprotokoll! Auch die Intellibox lässt sich wohl per TrackONE über SRCP steuern - ohne Signalerzeugerprozess, der läuft in der IntelliBox. Insofern ist die Ablehnung aller großen Softwarehäuse gegenüber SRCP umso unverständlicher für mich, denn eigentlich bräuchte man in Zukunft nur noch SRCP fähige Software und die entsprechenden Signalumsetzer SRCP<->Lenz, usw.

Richtig tödlich ist am Ende nur der "Blue Screen of Death" - der aber in allen Fällen

P.S. Warum schreib ich das alles? Nun, ich möchte in Zukunft zumindest Digital schalten und hatte mich mit einiger Steuersoftware beschäftigt, ebenso mit SRCP und einen kurzen Blick in's Lenz'sche RS232-Protokoll. Alle Softwarehäuser hatten mir auf meine Anfrage per eMail Ihre ablehnende Haltung gegenüber SRCP geschildert. Der Tenor war leider immer der gleiche "Wollen wir nicht, zu viel Aufwand, zu unsicher." Auf ewige und wahrscheinlich fruchtlose Diskussionen per eMail habe ich aber keine Lust, ich hoffe nur, dass spätestens mit SRCP 1.1 auch die großen Softwarehäuser mal umdenken werden ...

 

[jf-]

Echtzeitfähig ist mit dem Pc schon möglich, allerdings unter DOS.
Für eine komplette Steuerung incl. DCC-Signal-Erzeugung in Echtzeit ist ein Rechner ab etwa 150MHz ausreichend (wenn er nicht gerade das Miwula steuern soll). Die Signalpegel am Com-Port sind im Prinzip direkt Booster-tauglich.
Tja-und Abstürze unter DOS...
Das Problem ist nur, daß heutzutage niemand mehr DOS-Programme will.
Jens

 

[Meik'l]

@maercz
Deinen Ausführungen bzgl. des Arguments "qualitativ hochwertig und datentechnischen abgesichert" aus #9 kann ich nur zustimmen.

@all

als Anwendungsprozess lässt sich dieser [Anm., der Signalerzeugerprozess] dann [... durch] das Betriebssystem selbst oder durch Hardware-Treiber unterbrechen

Die Unterbrechbarkeit¹ des Signalerzeugers wird aber das Problem des Herrn Freiwald sein. Er will vermutlich sicher stellen, daß seine Software mit einer bestimmten Zentrale und Firmware auf eine bestimmte Art und Weise zusammen arbeitet bzw. reagiert und dies kann er nicht, wenn er die Systemumgebung eines beliebigen DDL-Rechners nicht kennt. Das Problem ist nicht die Software an sich, also DDL/DDW, sondern die Umgebung in der DDL/DDW läuft bzw. das was in dieser noch läuft. Und im Vergleich zu einem beliebigen Rechner ist eine DCC-Zentrale doch ein ziemlich starres und definiertes System um dessen Macken er nach ausführlichen Tests relativ leicht herumprogrammieren kann.²

¹ solch eine Unterbrechung ist in zeitlicher Länge nicht definiert, also ganz mies für die Signalerzeugung
² Wie kommuniziert eigentlich die Software des Herrn Freiwald mit den DCC-Zentralen und wie wird sichergestellt, daß eine Unterbrechung der Kommunikation mit der Zentrale durch bpsw. Systemprozesse diese Kommunikation nicht nachhaltig stört?

zu ²: Hier beißt sich IMHO die Katze in den Schwanz, stellt nämlich das Computerinterface der DCC-Zentrale keine Möglichkeit bereit atomar mit der Software zu kommunizieren, muß die Software in einem Echtzeitkontext³ laufen, anders ist für mich "datentechnisch abgesichert" sonst nicht erklärbar. Tut die Software letzteres nicht, ist sie IMHO im Falle der Kommunikation mit einer DCC-Zentrale genauso unsicher - bzgl. der Übermittlung der Daten zur Zentrale - wie bei der Kommunikation mit DDL/DDW oder die Erzeugung von DCC-Signalen durch DDL/DDW. Letztlich sollte es schließlich unerheblich sein, ob Latenzzeiten bei der Erzeugung des DCC-Signals mittels DDL, bei der Erzeugung des Signals zur Erzeugnung des DCC-Signal in der Zentrale durch Herrn Freiwalds Software oder bei einer Kombination aus beidem auftreten.

³ siehe dazu auch: hard, firm, soft real time

alle Befehle werden nur so schnell wie möglich umgesetzt

Das gilt auch für Echtzeitsysteme! Echtzeit heißt ja eben nicht, führe etwas so schnell wie möglich aus, sondern führe etwas in einer maximal definierten, immer gleichbleibenden maximalen Zeitspanne aus. Also so, daß die Reaktion auf ein Ereignis x niemals länger dauert als die dafür vorgesehene Zeitspanne y lang ist.

Echtzeitfähig ist mit dem Pc schon möglich, allerdings unter DOS.

Möglich ist es nicht nur unter DOS - been there, done that. Wichtig ist hauptsächlich, daß du den Scheduler, die Interruptverarbeitung des Kernels kontrollierst und das das verwendete System überhaupt die Resourcen hat, daß zu lösende Problem in Echtzeit zu bearbeiten.

Ich hoffe ich war irgendwie verständlich,
cya Micha

ps: "Du kannst aus Sicherheitsgründen nur alle 30 Sekunden einen neuen Beitrag schreiben." - war mir neu.

 

[Lokwolf]

OT: Beiträge

"Du kannst aus Sicherheitsgründen nur alle 30 Sekunden einen neuen Beitrag schreiben." - war mir neu.

Jo, verhindert das automatische Fluten.
Gruß vom Rhein
Lokwolf