THEMA: SpDrS60 und Selectrix

Hast Du schon mal bei

http://www.der-moba.de/index.php/Digitalprojekt

reingeschaut?

Hallo Peter 8,
Danke für Deinen Hinweis. Ich kenne fast alle Seiten, die damit zu tun haben.
Ich suche jemanden, der das Progamm SpDrS60 an einer Selectrix-Anlage betreibt.
Die meisten Benutzer von SpDrS60 arbeiten mit anderen Anlagen. Fast alle praktischen Infos beziehen sich auf Motorola und DCC/NMRA. Deshalb suche ich jemanden mit praktischer Erfahrung.
LG Wally

Hallo,
ich hab so Befürchtungen, ob das überhaupt geht. M.E. stellt SRCP "nur" ein Gleissignal bereit, welches ja bei DCC bzw. MM fürs Schalten reicht.
Bei Selectrix brauch ich für die Schaltdecoder jedoch einen Sx-Bus.  Es gibt div. Hardware-Elemente, die speziell Sx-Schalt-/Meldebusse bauen (siehe bei Rautenhaus oder auch bei Müt).

Hallo,

ich habe das gleiche vor, derzeit allerdings das Problem, dass meine Interfaces (altes Trix, Rautenhaus SLX 852) die Kommunikation mit meinem Linux-Server verweigern.

@ 3: Der SRCPD schickt kein Gleissignal, sondern sinple ASCII-Zeichen über die serielle Schnittstelle an das Interface.

Es gibt inzwischen auch eine explezites Selectrix-Modul und eine Readme wie man es konfiguriert und die Schalt- und Fahrbefehle für Selectrix übersetzt. Wichtig: Das Konfigurationstool auf der SRCPD-Homepage erzeugt für Selectrix einen falschen Code. Hier ist Handarbeit gefordert

Ich habe deshalb auch schon mit dem Entwickler Mailkontakt gehabt und auf der Softwareebene funktioniert es jetzt. Allerdings funktioniert es nach seinen Angaben nicht mit allen Interfaces - scheinbar mit meinen auch nicht.. Ich vermute mal (weiß es aber nicht), dass die Problematik in den Kommunikationsparametern der seriellen Schnittstelle liegt wie Hardware-Handshaking etc

Frage an die, bei denen es funzt: Welches Interface verwendet ihr ?

Aus Zeitgründen habe ich das Vorhaben beiseite gelegt, wäre aber interessiert das Thema weiter zu verfolgen.

Viele Grüße

Michael

Beitrag editiert am 22. 01. 2008 09:37.

@4 Hallo Michael

Es freut mich jemand gefunden zu haben, der sich auch mit dem Thema beschäftigt.
Meine Interfaces sind Eigenbau. Im Prinzip wie Uwe Magnus, ich benutze aber einen
anderen Prozessor. Ich bin seit 1970 (jetzt im Ruhestand) in der EDV (ist ja heute IT)
tätig. Ich habe Hardware und Software entwickelt und war Entwicklungsleiter in zwei verschiedenen Firmen. Ich kenn mich ziemlich gut mit SX aus. Ich habe ein eigenes SX-Monitor-Programm geschrieben. Allerdings für DOS, weil man da problemlos auf die COM-Schnittstellen zugreifen kann. Ich programmiere in Assembler. Das Programm heißt SXM. Es hat Funktionen und Features, die findest Du in keinem anderen SX-Monitor. So, und nun zurück zum Thema. Kannst Du mir mal zeigen, wie Deine srcpd.conf aussieht. Hattest Du Kontakt mit Gerard van der Sel? Es sollte ja angeblich letztes Wochenende die Version 2.0.11 frei gegeben werden, aber bis jetzt habe ich noch nichts gesehen. Eventuell muß ich mir die Quellen doch mal genau vornehmen und selber eingreifen und die Fehler suchen. Aber das wollte ich eigentlich vermeiden.
Auch bin an dieser Sache schon seit Jahren dran. Habe aber auch immer wieder die Sache beseite gelegt und mich anderen Sachen gewidmet. Bin auch erst seit diesem Monat dabei, um in dieser sache endlich weiter zu kommen. Aber bevor ich selber Hand anlege, warte ich erst mal auf die Version 2.0.11 von srcpd. Bei SpDrS60 hat sich auch schon fast ein Jahr nichts mehr getan.

LG Wally

Hallo,

da ich Deine Mail-Adresse nicht habe, hier meine srcpd.conf

<?xml version="1.0"?>
<srcpd version="2.0.10">
<bus>
<server>
<tcp-port>4303</tcp-port>
<pid-file>/var/run/srcpd.pid</pid-file>
<username>nobody</username>
<groupname>nogroup</groupname>
</server>
<verbosity>4</verbosity>
</bus>
<bus>
<selectrix>
<number_ga>5</number_ga>
<number_gl>5</number_gl>
<number_fb>5</number_fb>
<mode_cc2000>yes</mode_cc2000>
</selectrix>
<auto_power_on>yes</auto_power_on>
<verbosity>4</verbosity>
<device>/dev/ttyS0</device>
<speed>9600</speed>
</bus>
</srcpd>


Laut Gerard von der Sel darf die Summe der Geräte in diesen Zeilen

<number_ga>5</number_ga>
<number_gl>5</number_gl>
<number_fb>5</number_fb>

nicht größer sein wie 112.

Hier der Original-Text der Mail von Gerard:

The error is in srcpd.conf.
The sum of "number_ga", "number_gl" and "number_fb" must be less or equal
to 112 (max number of divices on the SX-bus).
I, myself, make number_gl equal to the real number of engines.
The number_ga and number_fb is equal to the number of this sort of divices
divided by eight.

So for example:
8 engines => number_gl = 8
10 switches => number_ga = ( 10 / 8 = ) 2
28 feedbacks => number_fb = ( 28 / 8 = ) 4

Klappt mit deinem Interface die Kommunikation mit dem SRCPD ? Wenn ja, mit welchen  Einstellungen der seriellen Schnittstelle. ? Schicke mir doch mal Deine Mailadresse, da Du dich als Gast eingeloggt hast, ist sie ja wohl nicht hinterlegt.

Viele Grüße


Michael



Beitrag editiert am 22. 01. 2008 19:02.

Hallo Michael,
habe Dir per Kontaktaufnahme ne Email zukommen lassen.
Bin jetzt auch Mitglied.
LG Wally.

Entschuldigung, ich dachte Du wolltest das mit dem Direkt-Digital machen, wo der Compi direkt an einen Booster angeschlossen wird, also keine Zentrale benötigt wird.

Andere Frage: wie spricht man denn ein Selectrix Interface unter DOS an? Für die "Aufgaben", die der PC bei mir machen "müsste", würde ich dann selber ein kleines DOS-Programm - vermutlich im guten alten Pascal - schreiben.

Hallo Peter 8,

Du kannst Programme unter DOS in allen möglichen Sprachen schreiben, also auch in Pascal. Allerdings mußt Du das Programm im echten DOS, also nicht im DOS-Fenster unter Windows, laufen lassen. Du mußt dann auch Pascal für DOS haben und auch unter DOS entwickeln. Nur unter DOS lassen sich die COM-Ports einfach ansteuern. Unter Windows wird es schon komplizierter und Du brauchst dann eine DLL um die COM-Ports sauber anzusteuern. Für diese Zwecke habe ich noch diverse ältere PCs bei mir am laufen. Diese bekommt man ja zum Nulltarif und wenn man programmieren kann, kann man mit denen für die Moba noch tolle Sachen zaubern. Infos über die Programmierung von Selectrix findest in den Trixbüchern und in der alten Beschreibung des Trix-Interfaces 66824 (Beispiele für BASIC). Es gibt aber bestimmt  im Internet noch
andere Quellen. Ich bin da nicht genug informiert. Da nun schon solange Sachen für SX programmiere, kenne ich die Struktur dafür aus dem FF.

LG Wally.

Hallo Wally,
danke für den Tip. Hast Du evtl. eine Kopie (wirklich nur für den Eigenbedarf) vom Trix-Interface übrig?

Ich hab vor Urzeiten mal sowas fürs Märklin-Interface für eine Märklin-Anlage ebenso im alten Basic geschrieben, bis ich damals dann einen jungen Programmierer gefunden habe, der für einen Amiga ein Programm geschrieben hatte, was noch bis heute zu den wirklich guten Programmen für Computersteuerungen einer MoBa gehören würde, wenn er nicht plötzlich "die Seiten gewechselt hätte" (der gute Knabe ist heute Luftfahrtingenieur bei einem großen Hubschrauberwerk) und es den guten alten Amiga noch gäbe...

Hallo Peter 8,

leider finde ich die blode Beschreibung nicht auf Anhieb, Vielleicht habe ich sie auch
ausgeliehen. Und wie das immer so ist (noch) nicht zurück erhalten. Man findet aber auch Informationen bei Uwe Magnus oder bei Uni Freiburg, Schweiz.

http://diuf.unifr.ch/tcs/labo/index-d.php

LG Wally.

Hallo Wally,

Superlink, "merci vielmals" an das Weserbergland aus dem Münsterland

Hallo Peter 8,

im Prinzip ist das mit Trix Protokoll an serieller Schnittstelle immer das Gleiche:
1) Schnittstelle öffnen (das dürfte unter DOS wegfallen))
2) Verbindungsparameter einstellen, also Geschmidigkeit, dann üblicherweise 8N1, kein Handshake etc.
3) Feuer frei

vom Bus lesen:
zwei Bytes schreiben, erstes Byte die Kanalnr., zweites Byte beliebig
Antwort lesen (ein Byte)
auf Sx-Bus schreiben:
erstes Byte Kanalnr + 128, zweites Byte der neue Wert
keine Antwort

Wie Du die serielle Schnittstelle unter DOS ansprichst, da würde ich mal nach einem alten Buch aus der Zeit Ausschau halten. Da gabs Dutzende Beschreibungen von.
Alternativ wäre natürlich Linux ne gute Wahl.

HTH.
Gruß, Axel

Hallo Axel,

Auch unter DOS muß die Schnittstelle geöffnet werden.
Das fällt nur weg wenn man in Assembler programmiert.
Aber in allen anderen Sprachen  ist ein Öffnen notwendig.
Wie man die serielle Schnittstelle anspricht ist mehr von
der Sprache abhängig als vom OS. Denn die Compiler
sind ja an die Operationssysteme angepasst.
Unter Dos programmiere ich sowieso nur in Assembler,
da ich dann die Hardware optimal ausnutzen kann und
auch die optimale Geschwindigkeit erhalte.

LG Wally.

Hast Du Erfahrung mit SRCPD unter Linux?

Beitrag editiert am 25. 01. 2008 01:17.

Hallo Wally,

das Öffnen der seriellen Schnittstelle hat in allen mir bekannten Sprachen relativ wenig mit der Sprache zu tun. Üblicherweise greift man (heutzutage) auf einen Treiber zu. Das heißt unter Linux zB. das Öffnen des entsprechenden Devices. ( /dev/ttyS0 o.ä.) Und auch unter DOS hat das definitiv nix mit Assembler oder nicht Assembler zu tun. *kopfschüttel* Außer natürlich, dass man es in der jeweiligen Sprache formulieren muss. ;) Es sei denn, die Sprache wäre künstlich kastriert. Der Compiler hat übrigens mit dem Betriebssystem meist relativ wenig zu schaffen. Der größte Teil des Betriebssystemspezifischen liegt in Bibliotheken.

kleine Anmerkung am Rande: Grafikkarte direkt ansprechen ging damals unter DOS mit Turbo Pascal 5.0. Also direkter Zugriff auf Speicherbereiche und IRQs geht ohne Assembler. Hatte auch nen netten Inline-Assembler für solche Zwecke btw.

Ich habe mit srcpd nie mehr gemacht als mal den Selectrix-Patch zu lesen. Ich bastel lieber selber an der Software. Aber in Assembler... ne danke, das ist für Mikrocontroller ok. ;)

Gruß, Axel

Beitrag editiert am 25. 01. 2008 01:59.

Hallo Axel,

Treiber hat es auch schon zu DOS-Zeiten gegeben. Sogar unter BASIC, was bei DOS
mitgeliefert wurde, gab es den Befehl OPEN "COM............". Unter DOS konnte man mit fast jeder Sprache direkte Zugriffe machen. Aber unter Assembler bleibt Dir nichts anderes übrig, als direkt auf die Innereien des UART zuzugreifen. Es sei denn Du benutzt irgendwelche vorgefertigten Routinen als INCLUDES. Ich bin schon ein bischen länger in der Materie als Du und habe deswegen auch mehr Erfahrung. Zu meinen Anfangszeiten gab es EDV-Anlagen da betrug der gesamte Speicher mal gerade 16KB und zwar Kernspeicher (RAM gab es so gut wie nicht und war viel zu teuer) und eine Festplatte hatte gerade mal 5MB.
Und auf diesen Anlagen wurde z. B. die gesamte Buchhaltung gefahren. Und die 80 Anlagen, die ich in den 70er Jahren bei Bundeswehr installiert habe, sorgten für den gesamten Nachschub und hatten damals schon DFÜ (Datenfernübertragung). Heutzutage sind die OS und Sprachen so aufgeblasen, das manche 2G Rechner langsamer sind, als ein alter 486er unter DOS. Also ich brauche von Dir keine Schulungen in Sachen Software und Programmierung. Ich habe von 76 bis 88 in den USA gelebt und habe die PC-Entwicklung von Anfang an mitgemacht. Zur der Zeit wußte man in Deutschland noch nicht mal, das es so etwas wie PCs gab. Anfang der 90er habe ich die erste deutsche Faxkarte inkl. Software entwickelt (wurde u. a. von SAP eingesetzt). Diese Karte hatte als erste eine Zulassung zum Faxdienst in Deutschland, Österreich und der Schweiz.
Aleine der Ausspruch "Aber in Assembler... ne danke, das ist für Mikrocontroller ok." sagt doch alles. Ohne Assembler wären die Amerikaner nicht auf dem Mond gelandet!
Und noch was, meine ersten Programme habe ich ohne Compiler geschrieben und zwar in HEX. Denn Compiler, sowas konnten sich nur grosse Firmen leisten.

LG Wally.

PS. Läuft eigentlich schon Dein SX-USB-Interface?  Meine Interfaces sind auch Eigenbau und arbeiten mit bis zu 115200 Baud. Mein SX-Monitor SXM unterstützt das natürlich und wurde auch in Assembler geschrieben. Mit SXM kann man sogar alle Vorgänge auf dem SX-Bus in einer Datei protokollieren und nachträglich auswerten.
Ich habe auch mal ein Program geschrieben, daß den SX.Bus ohne Interface direkt über den Parallelport eingelesen hat und rate mal was, wieder in Assembler.


Beitrag editiert am 25. 01. 2008 03:33.

Hallo,
ruhig Blut. Meine Assembler-Zeit endete mit dem C 64. Saubere Maschinensprache, kleines geiles Ding. Da konnte man mit kleinen Routinen dem Basic Beine machen, z.B. eine Input-Routine, die auch "Strings" mit Anführungszeichen, Kommata usw. annimmt (ganze 120 Byte lang).
BTW meine damals für den Commodore 8032-Rechner geschriebene Fakturierungssoftware war bis auf dem lahmen Diskettenzugriff auch flotter als heutige Programme.... das liegt an dem ganzen Pommes, der rundrum mitläuft.
Der kleine 6502 hatte bei 1 MHz seine ganze Kraft auf das abarbeiten zu legen (und konnte dank des pfiffigen Prozessors auch schnell rechnen) .
Heute braucht schon eine dusselige Routine mehr Speicherplatz (32 kByte RAM hatte damals der Compi)...
Na ja, was solls. Früher war ja alles besser...

Guten Morgen Peter 8,

>Na ja, was solls. Früher war ja alles besser..<
Früher hat man ja auch nicht eben mal einen Standort dicht gemacht und tausende von Menschen arbeitslos gemacht. Du weist schon was ich da meine.
Den kleinen 6502 kenne ich auch noch von früher. Obwohl ich mehr mit 8080 und Z80 gearbeitet habe. Ich programmiere natürlich in allen möglichen Sprachen.  Business-Software habe ich in COBOL geschrieben und zwar für Mainframes wie auch PCs. Die größte Maschine auf der ich mal gearbeitet habe war eine "CRAY" und die ist auch heute noch ein Monster. Da ich aber die ganzen Sprachen, die heutzutage alle rumschwirren, nicht mehr lernen will und auch kann,programmiere ich auch heute noch gerne in den Sprachen, die damals akut waren. Mit fast 62 lässt der kleine Proc. in meinem Kopf schon etwas nach. Ich habe früher für die NCR Corp. gearbeitet, falls Dir das was sagt. Daher auch mein längerer Aufenthalt auf der anderen Seite des Teichs.

LG Wally.


Beitrag editiert am 25. 01. 2008 10:01.

Hallo,
NCR, wie hiess das noch "nichts clappt richtig, siehste, geht schon los...".

Zu den Zeiten als NCR die PC-Fertigung in Bayern aufgegeben hat war noch ein Kumpel - damals Produktionsleiter eines PC-Herstellers hier in der Kante - da und hat den Laden mit "geplündert".

An einer Cray hast Du gearbeitet? Himmel die Berge, das größte an das ich gearbeitet habe war ne IBM ("immer besser manuell) System 370 und den fiesen Nachfolger System 38, da konnte ich mich nicht mit anfreunden. Jedes Bug im Betriebssystem wurde durch ein Patch mit noch mehr Bugs behoben...
Damals aber noch mit Lochkarten "MFKE" und Kettendruckern.

Hallo Wally,

ich bin mir sicher, dass Du von den ganzen Veteranen der Computergeschichte mehr Ahnung hast als ich. Ist allerdings kein Argument.

Nur so mal am Rande: Man kann auf diesen riesigen, neumodischen PC-Betriebssystemen sehr schnelle, schlanke Programme schreiben. Nur halt nicht mehr so wie damals. Mein Sx-USB Interface ist schon einige Zeit im Einsatz. Sehr praktisch. Mein Laptop hat nicht einmal mehr nen Parallelport.

Gruß, Axel

Hallo Axel,

Wenn Du meinst, ich hätte von diesen "neumodischen OS" und Sprachen keine Ahnung, dann hast Du Dich getäuscht. bei mir laufen 6 moderne PCs im Netzwerk und wenn ich das Laptop mitrechne sind es sogar 7. Und die vielen älteren Rechner die bei mir noch diverse andere Jobs machen, sind da noch garnicht mitgerechnet. Als OS sind bei mir von MsDos bis Windows Vista und Suse Linux, Ubuntu, Knoppix, SCO UNIX, BSD alle im Einsatz (zum Teil mehrere OS auf einem PC - per Bootmanager.
In diesem Thread geht es eigentlich um SpDrS60, SRCPD und Selectrix und da kannst Du ja wohl nicht viel zu beitragen. Wenn Du so ne Kanone bist, dann leg doch mal offen, was Du beruflich machst. Kannst Du ja übers Kontaktformular machen. Das was Du in Antwort 13 zum Thema Trixprotokoll von Dir gegeben hast mag ja für Leute deines Schlages reichen. Guck Dir mal bei Uwe Magnus an, wie der das macht. Oder noch besser findest Du das in den Dokumentation von Trix für Interface 66824 und 66842.
So das wars.

LG Wally.


Beitrag editiert am 25. 01. 2008 14:07.

Nur mal am Rande: Ist es eigentlich wirklich nötig, daß man sich hier derart anfeindet?

Thom

Hallo Thom,

Auch nur mal am Rande: Hier feindet sich keiner an.
Und wenn jemand dumme Sprüche klopft, dann geb ich ein paar Fakten zurück.
Man sollte Leuten, die man nicht kennt und auch den anderen immer mit dem
nötigen Respekt begegnen und nicht unterstellen, weil man älter ist, das man von
den "neuen Sachen" keine Ahnung hat.

Viele Grüße von Opa Wally.

Hallo,

mal wieder zurück zum Thema:

- SRCPD uns SpDrS60 brauchen Linunx als Betriebssystem (alles andere ist eine Krücke), da helfen uns weder DOS noch Vista.

- Die Form der Daten, die man an den SX-Bus schicken muss, ist auch klar. Axel hat es genau richtig beschrieben, bei Uwe Magnus ist es noch detaillierter beschrieben. Das soll aber ja der SRCPD für uns erlegigen.

Und nun zum eigentlichen Problem: SpDrS60 braucht einen funktionierenden SRCPD-Server. Und da hakt es bei mir. Die Daten, die SRCPD schickt, kommen am Gleis nicht an. Ich habe es mal mit PHP und einem Apache-Webserver auf der gleichen Maschine probiert, da funzt es. Es liegt also nicht am Interface, sondern meiner Ansicht nach am SRCPD bzw. der Einstellung der seriellen Schnittstelle

Folgendes Phänomen habe ich nach dem Start des SRCPD festegestellt. Gibt man zur Anzeige der aktuellen Einstellungen der seriellellen Schnittstelle (/dev/ttyS0) stty -a ein,
so zeigt diese vor dem Start des SRCP an, dass Hardware-Handshaking ausgeschaltet ist, nach Start des Daemons steht dieses Flag auf   "ein". Schaltet man von Hand wieder auf "aus",hilft das aber auch nicht weiter.

Soweit ich informiert bin, unterstützen weder die Interfaces von Trix, Rautenhaus noch Uwe Magnus Hardware-Handshaking. Ich habe den Entwickler des Selectrix-Moduls in den Niederlanden danach befragt, aber leider keine abschließende Antwort erhalten (ich bin noch nicht dazu gekommen nachzuhaken) hier ein Zitat aus seiner Mail:

"I use the standard Selectrix interface and I have a SLX852 (temporary).
Communication with the standard selectrix interface is over three wires
(RX, TX and GND). I can't check the old software any more since the
controlling of the port is changed."

Ich interpretiere das so, dass es früher funktioniert hat und jetzt der Zugriff auf die serielle Schnittstelle (Port????) geändert wurde.

Von daher wäre es gut zu wissen, ob es hier im Forum Menschen gibt, denen mit SRCPD ein erfolgreicher Selectrix-Zugriff gelungen ist. Wenn ja, mit welchem Interface und welcher Konfiguration, Version.

Damit wir hier mal weiter kommen, werde ich meine Frage prallel in de.rec.modelle.bahn posten.

Viele Grüße


Michael

Hallo Michael,

Ich habe in den letzten Tagen diverse Tests gefahren. sowohl unter Suse als auch unter Ubuntu. Ich habe ein Programm zum Com-Port Monitoring (ASYNMON). Das läuft auf einem seperaten Dos-Rechner mit zwei COM Schnittstellen, über ein spezielles Tap-Kabel werden alle Signale der serielen Verbindung zwischen Interface und Linuxrechner aufgezeichnet und am Bildschirm angezeigt. Bis jetzt hat SRCPD nicht einen Muks gemacht. Weder bei Selectrix, noch bei den anderen Protokollen war SRCPD dazu zu bewegen auch nur ein Byte auszugeben oder die Leitungen fürs Handshake zu aktivieren. Die Hardware und Linux sind ok. Ich kann mit "echo" Daten auf beiden Ports
/dev/ttyS0 oder /dev/ttyS1 ausgeben. Wo das Problem liegt weiß ich noch nicht. Ich bekomme morgen noch diverse andere Interface zum testen. Aber ich habe da wenig Hoffnung. Denn wie Du, glaube ich, dass das Problem bei SRCPD liegt. Ich hoffe das ich bis nächste Woche noch etwas mehr weiß. Ich werde dann mit Gerard Kontakt aufnehmen und vielleicht kommen wir ja dann weiter. Es hat auf jeden Fall früher schon mal funktioniert. Ich habe auch schon bei de.rec.modelle.bahn gesucht, aber nichts Positives gefunden. Es ist ja auch für Gerard schwer sich aus der Ferne ein Bild von den Systemen der anderen Leute zu machen und meißtens bekommt er ja auch nicht genug Informationen. Dazu kommen noch Sprachprobleme.

Also im Moment verlässt nicht ein Bit SRCPD über die serielle Schnittstelle.
Ich hoffe ja das die Vers.2.0.11 bald zur Verfügung steht. Aber wenn ich mich in die Quellen einarbeiten will, wird das dauern, denn C war noch nie meine Stärke. Vielleicht sollte man aber auch einen neuen Srcp-Server nur für Selectrix schreiben. Mir spuken da so ein paar Ideen im Kopf herum. Ich könnte mich auch in den A... treten, daß ich die Infos zu meiner damaligen Konfiguration nicht aufgehoben habe. Ich weiß auch noch nicht mal mehr mit welcher Linux Version ich das am laufen hatte. Das ist der Nachteil, wenn man zuviel von dem Zeug hat. So das wärs erst mal. Schönes Wochenende.
Hast du meine Emailadresse bekommen?

LG Wally.


Beitrag editiert am 25. 01. 2008 15:42.

Hallo Michael,

so wie ich die zitierte Antwort lese, soll das über ein Nullmodemkabel funktionieren. Dann sollte es doch auch funktionieren die Zentrale (ich denke Ihr meint das mit 'Interface') über ein Terminalprogramm (Seyon oder Miniterm) anzusprechen. Auch wenn Du damit vielleicht keine 'Sinnvollen' Kommandos absetzen kannst, so solltest Du doch die jeweilige Antwort auf Tastatureingaben sehen können. Aber serielle Schnittstellen sind ja leider etwas 'eigen'.

Thom

Ach und was wird denn in den /var/log/messages protokolliert?

Thom

Hallo Thom,

Für ein Selectrix-Interface brauchst Du kein Nullmodem-Kabel, denn die Nullmodem-Funktionen sind im Interface integriert. Allerdings nur der Tausch von RX - TX und eine Brücke vo CTS zu RTS. Du brauchst ein normales 1 zu 1 Kabel. Da ich auch Eigenbau-Interface benutze habe ich die Nullmodem-Funktion in denen erweitert. Ich fahre meine ganzen Tests mit diversen Terminalprogrammen und sogar nicht nur über "localhost", sondern auch von anderen Rechnern (Windows und Linux). In  /var/log/messages wird alles normal protokolliert. Es gibt aber keine Fehlerangaben in Bezug auf die serielle Schnittstelle. SRCPD tut so, als würde es ganz normal mit der ser. Schnittstelle kommunizieren. Aber in Wirklichkeit sieht man kein Signal auf der RS-232, weder mit  ASYNMON oder mit dem Oszilloscope.
Danke für Deine Info.

LG Wally.


Beitrag editiert am 25. 01. 2008 16:37.

Ich hatte gemeint, das ein Nullmodemkabel reicht und nicht das zwingend eines benötigt wird.

Aber was steht denn nun in /var/log/messages ?
Poste doch bitte mal alles, was dort nach dem Start des Daemons protokolliert wird und vom srcpd kommt.

Thom

Hallo Thom,

Ich werde var/log/messages posten. Aber ob ich heute noch dazu komme, weiß ich nicht. Denn im Moment esse ich gerade Mittag und außerdem tanze ich noch auf weiteren drei "Hochzeiten" und verfolge so ganz nebenbei auch noch das Forum. Heute Abend habe ich auch andere Verpflichtungen. Es wird wohl erst Morgen sein.

LG Wally.


Beitrag editiert am 25. 01. 2008 18:23.

Hallo Michael, Thom

Es läuft, es läuft!!!!!!! Das Wochende ist gerettet!
Mehr dazu am Wochende. Ich muß jetzt einpacken, habe heute Abend noch was anderes vor und bin schon wieder zu spät.
Michael, habe noch keine Emailadresse von Dir. Es wäre gut, wenn wir auch direkt
korrespondieren könnten. Meine solltest Du ja haben.

LG Wally.

Mahlzeit!
Interessantes Thema, lustiger Thread (ich bin xxxxx Jahre in der IT).
Nix für ungut, mich interessiert das absolut.
Geplante Idee: einen SRCPD-Server als Mini-ITX-PC (O/S: FreeBSD) unter der Anlage, und dann mit allen möglichen SRCP-Clients und der Trix MS Betrieb machen.
Bin also dankbar für jegliche Art von Hinweisen, wie man den Spaß ans laufen kriegt.
Die nächsten Tage müssten die Teile für mein Interface eintreffen und dann werde ich natürlich alles mögliche damit ausprobieren wollen.
Grüße
Daniel

An Alle,

ich habe SRCPD jetzt am laufen und zwar auf zwei verschiedenen Systemen.
Folgende Interfaces wurden getestet und funktionieren noch nicht.
Uwe Magnus Interface2,
MTTM Advanced Computer Interface II,
Eigenbau Interface (im Prinzip wie Magnus)
Die Interfaces sind Hardwaremäßig 100% OK und wurden mit meinem eigenen
SX-Monitor SXM getestet und funktioneren dort mit allen Baudraten einwandfrei.
Es gibt einen Unterschied zwischen dem Trix 66842 und den anderen Interfaces.
Dieser wird auch von SXM eindeutig angezeigt. Aber bevor ich nicht genau weiß, ob
das die Ursache ist, werde ich mich darüber noch nicht weiter auslassen.

Ich werde noch weitere Interfaces testen, muß aber warten bis ich sie bekomme.
Warum das Trix Interface funktioniert und die anderen nicht, kann ich noch nicht 100% sagen,aber ich habe da schon einen Verdacht. Es müssen noch weitere Nachforschungen angestellt werden. Ich muß die Quellen von SRCPD nochmal in aller Ruhe analysieren.


1. System
UBUNTU 6.06 Kernel 2.6.15-29-386
2. System
SUSE LINUX 10.3 Kernel 2.6.22.13-0.3

Folgende Komponenten sind bei beiden Systemen gleich.
Server: SRCPD Vers. 2.0.10
Clients: SpDRS60 Vers.0.5.2 und SRCPTERMINAL von Thomas Borrmann
Interface: Trix 66842
Zentale: Trix CC2000

Konfigurationsdatei: srcpd.conf
*************************************************************************
<?xml version="1.0"?>
<srcpd version="2.0.10">
  <bus>
    <server>
      <tcp-port>4303</tcp-port>
      <pid-file>/var/run/srcpd.pid</pid-file>
      <username>nobody</username>
      <groupname>nogroup</groupname>
    </server>
    <verbosity>4</verbosity>
  </bus>
  <bus>
    <selectrix>
      <number_gl>1</number_gl>
      <number_ga>1</number_ga>
      <number_fb>1</number_fb>
      <mode_cc2000>yes</mode_cc2000>
    </selectrix>
    <device>/dev/ttyS0</device>
    <use_watchdog>yes</use_watchdog>
    <verbosity>5</verbosity>
    <auto_power_on>yes</auto_power_on>
    <speed>9600</speed>
   </bus>
</srcpd>
***********************************************************************

Dies ist  ein Zwischenstatus-Bericht.

LG Wally.


Beitrag editiert am 26. 01. 2008 15:48.

Hallo Thom,
und hier der Auzug aus der  /var/log/messages:
LG Wally.

********************************************************************************
Hier war der Auzug aus der  /var/log/messages.
Ist ja jetzt auch nicht mehr interressant. Denn es funzt ja!

************************************************************************************

Beitrag editiert am 27. 01. 2008 00:46.

Hallo Daniel,
ich hatte darüber über den kleinen SRCP-Server, den Du ansprichst auch schon mal nachgedacht. Interessant fand ich den Linksys NSLU2. Da gibt es eine recht rege Community, was Umbauten betrifft. (und ist mit 70 Euro preislich attraktiv) Eine serielle Schnittart ist nicht eingebaut (wozu auch?) aber man kann intern an einen UART ran.

http://www.nslu2-linux.org/wiki/Main/HomePage

Gruß, Axel

An Alle

Ein weiteres Interface arbeitet OK.
Es ist mein Eigenbau (im Prinzip wie Magnus).
Hatte ne kalt Lötstelle, die das Problem verursachte.
Also es arbeiten jetzt zwei Interface.

Gute Nacht.
LG Wally.

An Alle

Ich fasse nochmal zusammen.
Ich habe 4 Interface gestestet und 3 davon arbeiten mit SRCPD ohne Probleme.

Es arbeiten OK:
Trix 66842,
Uwe Magnus Interface2,
Eigenbau Interface (im Prinzip wie Magnus)

Nicht arbeiten tut:
MTTM Advanced Computer Interface II

LG Wally.

@35/Axel: habe mir den NSLU2 angeschaut, wäre evtl. eine Alternative. Linksys hat gute Hardware, die mit der richtigen Software auch super funktioniert (mein WRT54GS Router läuft mit DD-WRT). Der Vorteil von einem "normalen" Mini-ITX PC wäre halt die x86-CPU, da läuft zur Not auch ein Windows drauf. Kostenpunkt liegt bei ca. 100€ (gibt's natürlich auch teurer *g*).

@37/Wally: super, danke für die Testergebnisse! Dann kann ich nächstes WE ganz beruhigt mein Uwe Magnus Interface 2 zusammenlöten. Kommt SRCPD auch mit allen 3 Sx-Bussen des Interface 2 klar? Brauche zwar vorerst nur einen, aber zukünftig wäre das schon ideal.

Grüße
Daniel

Hallo Daniel

Im Moment wird nur ein SX-Bus pro Interface unterstützt, Ob in Zukunft mal mehr unterstützt werden, hängt davon ab, ob Gerard (er entwickelt das SX-Modul) und auch die anderen in der Projektgruppe es wollen und auch dafür planen. Da die Nutzer von SRCPD, die das Selectrix-Protokoll nutzen, noch der kleinere Teil ist, wird es auch davon abhängen, wieviele Leute dafür Bedarf anmelden. Vielleicht werde ich ja mal selber etwas in der Richtung unternehmen. Aber das erfordert dann auch wieder Zeit und die ist ja immer knapp.

Einen schönen Sonntag.
LG Wally.

@ zuerst gehört "wally" ein herzliches Dankeschön" für seine intensive Forschung in dieser Angelegenheit.
Immerhin sieht es so aus, als sei jetzt das Eis zwischen srcpd und SX
gebrochen.  
Damit eröffnet sich nun endlich die Chance zu all den Epoche 3 Fahrzeugen auch ein vorbildgerechtes Gleisbildstellwerk zum (digitalen) Einsatz zu bringen.
Es ist schon traurig, überlegt man sich mal, dass es fast 40 Jahre gedauert hat und nur "Aussenseiter" dafür gesorgt haben ein solches Gleisbildstellwerk zu realisieren.
Man wurde nur mit software zugeschüttet, die weitgehend zum Fahren und nicht zum Schalten gedacht war.
Alle, die hier und andernorts das digitale Schalten verdammen, wissen leider nichts von dem, was ihnen entgeht. Würde ich nochmal mit der MoBa anfangen, würde die Stellwerkstechnik zuerst digital betrieben, darin liegt weitaus mehr Potential verborgen.
Also wally, mach  so weiter !
@37-2
das interface kann nur drei Datenbusse verwalten, wenn diese auch von EINER Zentrale erzeugt werden, die DREI Busse mit EINEM Prozessor erzeugen kann.
Da ist mir derzeit nur das Selbstbau- Zentralenprojekt von Uwe Magnus bekannt.
Gleichwohl die SLX 850 von MDVR, die ZWEI Busse erzeugt.
Für ein Gleisbildstellwerk reicht der Adressraum eines Busses mit rund 800 "Kanälen" vollständig aus.
Mit 50 Weichendecodern a 8 Anschlüssen und ebenso vielen Besetzmeldern, so sie denn mal ansprechbar sind, kommt wohl z.Zt. kein Mangel auf.
Prorität hat derzeit dazu (zum Stellwerk) eher eine Kombination mit 2 Monitoren zur besseren Darstellung des "Stelltisches" ohne Tasten, die stellt Maus und Tastatur fast
"umsonst" zur Verfügung.
Gruss Datenbus


Beitrag editiert am 27. 01. 2008 14:03.

Hallo Datenbus,
dass die 3 Busse beim Magnus Interface taktsynchron sein müssen ist bekannt, das ließe sich ja auch mit dem Trix Translater (gibt's dafür eigentlich eine Alternative, Selbstbau o.ä.?) bewerkstelligen.

An alle: hat schon jemand den SRCP-Client Kdigirail ausprobiert und evtl. den einen oder anderen Screenshot davon?

Gruß
Daniel

Damit Sie Ihren Beitrag nicht nochmals tippen müssen, ist er nachfolgend dargestellt - bitte kopieren Sie den Text in Ihre Zwischenablage und versuchen Sie nochmals, den Beitrag zu posten:

Möchte den von datenbus in #40 gegeben Hinweis: < das interface kann nur drei Datenbusse verwalten, wenn diese auch von EINER Zentrale erzeugt werden, die DREI Busse mit EINEM Prozessor erzeugen kann. > etwas konkretisieren. Das SelecTRIX kompatible Interface 2 von Uwe Magnus unterstützt bis zu 3 Takt- und Frame-Synchrone Sx-Busse. Der Selbstbau-Zentrale von Uwe Magnus generiert drei Sx-Busse, die diesen Anforderungen entsprechen, die MC2004 von MUET zwei, die Multifunktions-Zentraleinheit SLX850(AD) und das Multifunktions-Interface SLX852 von Rautenhaus/Radtke ebenfalls zwei. Zusammen mit dem Sx-Translater #66843 aus dem ehemaligen SelecTRIX-Programm von TRIX besteht jedoch die Möglichkeit mit allen SelecTRIX kompatiblen Zentralen, die mindestens einen Sx-Bus zur Verfügung stellen, einen weiteren Sx-Bus zu generieren, der den Eingangs beschrieben Anforderungen genügt und somit auch zusammen mit dem Interface 2 von Uwe Magnus genutzt werden kann. Dies bedeutet, dass man über den Translator entsprechende zusätzliche Sx-Busse auch mit der SelecTRIX (Ursprungs-)Zentrale #6680, #66804 und der Central Control 2000 #66800 erzeugen kann. Was ich noch nicht getestet habe ist, ob dies auch zusammen mit der TRIX Systems Gleisbox-ZE funktioniert, wenn diese im reinen Sx-Modus betrieben wird. Im Sx-/DCC-Modus funktioniert dies nicht, da hier auf deren Sx-Bus die Protokollerweiterung entsprechend der Sx2-Definition aktiviert wird. Das potentielle Clientel, welches an der entsprechenden Erweiterung der SpDrS60 - SelecTRIX Funktionalität interessiert sein könnte, dürfte damit vorhanden sein. Zumindest erhält es damit eine breitere Basis.

Beste Grüße W. H

An Alle

Es wurde die neue Version von SRCPD heute zum Download bereit gestellt.
Allerdings im Moment nur für Suse 10.1 und 9.0 sowie für Fedora Core 5.
Die neue Version unterstützt Rautenhaus SLX852.
Da kommt neue Arbeit (Testen) auf mich zu.

http://sourceforge.net/project/showfiles.php?group_id=29376

LG Wally

Beitrag editiert am 27. 01. 2008 23:29.

Hallo Wally,

bin auf die Ergebnisse gespannt. Wenn die Quellen auch veröffentlicht wurden, sollte sich das auch auf FreeBSD kompilieren lassen. Da ich jetzt die ganze Woche unterwegs bin, kann das leider noch nicht ausprobieren.

Gruß
Daniel

An Alle

Ich habe die neue Version 2.0.11 von SRCPD einem Kurztest unterzogen.
Folgende Interfaces wurden getestet und funktionieren.
Uwe Magnus Interface2,
MTTM Advanced Computer Interface II
Eigenbau Interface (im Prinzip wie Magnus)
Trix 66842
Es wurde mit folgenden Baudraten getestet: 19200 und 57600

System
SUSE LINUX 10.3 Kernel 2.6.22.13-0.3
Server: SRCPD Vers. 2.0.11
Clients: SpDRS60 Vers.0.5.2 und SRCPTERMINAL von Thomas Borrmann
Zentale: Trix CC2000

LG Wally.


Beitrag editiert am 28. 01. 2008 08:42.

Hallo Walter,

... endlich... meine Lok fährt..., hält zwar nicht mehr an, aber das kriege ich wohl noch hin.

der Umweg zum Erfolg führte über mein Laptop mit folgender Konfiguration:

- USB/RS232 Konverter mit FTDI-Chip an WinXP als Basissystem
- SuSE Linux 10.0 auf VMWare (COM-Port des Konverters als serielle Schnittstelle in der Hardware-Konfiguration übergeben und von dort als /dev/ttyS0 angesprochen)
- SRCPD 2.0.11
- Interface Rautenhaus SLX852 an CC2000

Ich habe mir auf Deinen Tipp hin auch mal den neuen Quellcode angesehen. Es scheint dort tatsächlich sowohl das Rautenhaus-Befehlsformat als auch der Zugriff auf zwei Busse implementiert zu sein. Leider ist das in der README noch nicht dokumentiert, es gibt dafür aber offenbar einen neuen Knoten <interface> in der Konfigurationsdatei.  Wenn es tatsächlich möglich ist, mit einem Befehl den gesamten Bus abzufragen bzw. Änderungen automatisch zu empfangen, steht der Entwicklung meines Web-Interfaces nun nichts mehr im Wege.

Ich werde versuchen, die Rautenhaus-Funktionalität baldmöglichst zu testen.

Viele Grüße


Michael

An Alle

Ich habe es aufgegeben das SpDRS60 und SRCPD an einer Selectrix-Anlage sauber
zum  laufen zu bringen. Anstatt dessen habe ich mich hingesetzt und ein Programm geschrieben. Dieses Programm (6051SX) läuft auf einem alten 486er unter MsDos.
Es dient als Converter. Ich lasse jetzt SpDRS60 und SRCPD unter Märklin/Motorola
Modus laufen und der dazwischen geschaltete Rechner mit meinem neuen Programm
setzt die Märklinbefehle in Selectrix um und liefert sie über das Interface an die Anlage.
Es arbeitet alles prima. Damit bin ich jetzt in der Lage jede Software die für Märklin/Motorola geschrieben wurde, auch an meiner Selectrixanlage einzusetzen.

Schönen Sonntag.
LG Wally.

Hallo Wally,

wäre es möglich, das Programm zu bekommen? Habe ich es richtig verstanden, dass es auf einem COM-Port ein Märklin/Motorola-Interface emuliert und die nach SX übersetzten Befehle auf einem zweiten COM-Port an das SX-Interface ausgibt?
Es dürfte wohl sehr sparsam mit Systemressourcen umgehen, daher stünde bestimmt auch einem Betrieb mit Bochs (http://bochs.sourceforge.net/) oder VMWare nichts entgegen, oder?

Grüße
Daniel

Hallo Daniel,

Du hast es genau richtig verstanden. Es emuliert auf einem Com-Port das Märklin/Motorola Interface und gibt die übersetzten Befehle auf dem anderen Com-Port an das SX-Interface aus. Genauso werden die Rückmeldungen für BMs in Gegenrichtung übersetzt.

Ich glaube nicht, dass das Programm unter Bochs oder VMWare laufen wird. Das Programm ist in Assembler geschrieben und greift direkt auf die Hardware (Com-Ports) zu. Was die Resourcen angeht, ist es sparsam. Das Programm hat zur Zeit nur eine Größe von 753 Bytes. Es ist allerdings noch im Beta-Status und wird wohl auch noch etwas wachsen. Wenn es ausgereift ist, schwebt mir eine Black-Box auf Microcontrollerbasis vor. Da ich aber genügend alte PCs habe, probiere ich solche Sachen immer erst auf denen aus.

Falls Du weiteres Interesse hast, kontaktiere mich über die N-Liste.

LG Wally.

Hallo Wally, Du hast Post!
Grüße Daniel