Zitat

---

Franks Idee war ja nun, dass ein lokaler Detektor dynamisch entscheidet ob er das Signal asymmetrisch verändert je nachdem welche Lok vorbeikommt. So könnte man z.B. Personenzüge im Bahnhof anhalten lassen und Güterzüge durchfahren, unabhängig von der Signalstellung.
Da er aber gerne mehr Einfluss auf den Lokdekoder haben wollte, dann die Idee anstelle von ABC eine Infrarot Kommunikation. Also Lok wird durch lokalen Detektor erkannt und dementsprechend werden über Infrarot dann entsprechende Befehle ein paar cm weiter übertragen. Hier ließen sich neben Geschwindigkeitsänderungen z.B. Funktionsbefehle übertragen.

Wie schon geschrieben, halte ich persönlich von der Infrarot Methode nicht sonderlich viel, da sie zusätzlichen Mehraufwand bedeutet. Und auch auf ABC würde ich verzichten wollen.

---

Richtig: ABC fürs lebensnotwendige in Sachen lokale Beeinflussung, und Infrarot für den grenzenlosen Luxus.

Bedueted Mehraufwand den keiner will, aber die Funktionalität fänd ich toll. Wenn jemand eh auf und absteigende Oberleitungs-Stromabnemhmer und abschaltbare Dampf-Heitzung hat, mach der Aufwand den brei auch nicht mehr Fett.

Duck und Wech
Frank.

Keine Angst Oliver, dass verkrafte ich schon.

Frank hatte ja schon was zu dem "Befehlssatz" geschrieben und meiner Meinung nach bedeutet dieses Wort halt eine Sammlung von Befehlen unabhängig von Protokoll/Technologie und so trifft es ja auch auf ABC zu.

Das ich kein Fan von ABC, Infrarot und Co bin sollte inzwischen auch durchgedrungen sein, auch wenn der minimale Hardwareaufwand für eine ABC Lösung schon verlockend ist. Allerdings halt leider nicht allgemein unter den Dekodern verbreitet. Ich hatte ja auch lediglich versucht Franks Ideen zu verstehen und weiterzuspinnen.

Mit den Andwendungsfällen hatte ich ja nur versucht zu belegen wofür man die von mir erdachten Messages Types gebrauchen kann. Dass sich dies heute bereits auf andere Weise und in Zukunft auch weiterhin mit den herkömmlichen Mitteln günstiger lösen lässt, bestreite ich nicht. Aber ich denke es gibt bestimmt noch mehr spannende Anwendungsfälle.

Ich wollte eigentlich nur meine zwei Ideen für Messagetypes nach RP 2.3.9.Fvorstellen:
Identified Adress - also die von einem lokaler Detektor empfangene Adresse. So kann man bei einer zentralen Intelligenz ohne zusätzlichen Bus, die Informationen der lokalen Detektoren auswerten. Dies ließe sich vielleicht auch durch missbräuchliche Nutzung der Messages F.1, F.2 nutzen, doch verstehe ich die eher so, dass diese die eigene Dekoderadresse enthält.

DCC Command - In einer oder mehreren aufeinanderfolgenden Messages wird ein DCC Befehl übermittelt. Die Zentrale setzt diesen dann um. Auch hier die Idee ohne zusätzliches Bussystem auszukommen.

Natürlich ist mir bewusst, dass dies Bandbreite kostet und man bei größeren Anlagen wohl sinnvollerweise ein separates Bussystem dazu verwendet, doch bei kleinen Anlagen oder speziellen Anwendungsbereichen (Teppichbahning) sehe ich für solche Messages einen großen Nutzen.

Gruß
Michael

Hallo Oliver,

Zitat

---

Mit derzeitigen Decodern und CPUs , Speicher etc. ist das SO nicht möglich.

---

Die Leistungsfähigkeit vom ersten uP zu DCC-Zeiten bis zum vergleichbaren heutigen hat scih schätzungsweise verhundertfacht.
Gut zu sehen der Tams-MC, die lt. Hören-Sagen x Protokolle mit einem uP macht.

Zitat

---

Obwohl ja Uhlenbrock mit der Pendelautomatik die Intelligenz dafür in den Decoer gepackt hat, was ZIMO zb. in der Zentrale abwickelt, ist das nicht vergleichbar.

---

Die ABC-"Befehle" kann man auch zum Pendelzug-Fahren umdefinieren.
Anstatt HP0 macht die Lok dann "Halt", "Wenden", "Warten" und "Abfahren" .

Zitat

---

Vorstellbar wäre, dass eine "Teilintelligenz" an den Dedektor abgegeben wird, der eben bei Erkennen bestimmter DCC-Adressen das "ABC-Signal" anlegt.

---

Volle Zustimmung!

Zitat

---

Dieser Dedektor ist wie ein Decoder konfigurierbar. Ich schreibe also in seine CVs auf welche Adressen er wie reagieren soll.

---

Genau!

Zitat

---

Er kann aber keine Befehle selbst absetzten - das sieht die Technik derzeit nicht vor.

---

Wieso nicht? Er könnte z.B. vier Schaltausgänge implementieren , mit denen man dann wahweise eine Weichen oder ein Signal oder ein ABC-Modul oder Relais betätigt ?

Damit wäre ich schon mal zufrieden. dann bräuchte meine Verein jetzt keine Magntcodeauswertung "entwickeln"und wir könnten die gesamte Straba-Anlage (ca13 ABC-Blöcke ) allein mit käuflichen Produkten lokal steuern.

Man könnte sogar eine Infraotanschluss anbringen der genauso CV konfiguriert Infrarot-Befehle aussendet (Bimmeln, Ansage machen).
In vielen Fällen würde diesbezüglich sogar eine Konstant-Befehl-Sender ausreichen. Bimmeln am Bahnübergang oder Ansagen der Abfahrt rtg. 123 müssten an den meisten Stellen sowieso allen Züge machen. Und gerade diese Verwendung ist doch fürchterlich einfach zu handhaben.

Derzeit würde ich mit dem Infrarot-Feature dabei auch einen 3-stelligen Preis je Detector befürchten, was sich dann schon Richtung MX9 bewegen würde, und das würde mein Verein wohl nicht mehr mitmachen.

Aber bei ausreichender Verbreitung würde auch dieser billiger werden.
Als Hinderungsgrund für die ausreichende Verbreitung würde ich allerdings noch eher die Komplexität der CV-Programmierung des Bausteins sehen, als sonstige technische Grenzen . Und würde man das über eine PC-GUI lösen, bräuchte man wieder den PC, denn wir wir alle wissen,: Ein gutes Windows braucht 10 Minuten" .

Viele Grüße
Frank

Hallo Frank,

da du ja wohl bereit bist Infrarot Module zu verbauen, dann würde das von Uhlenbrock angebotene Lissy deine genannten Anwendungen komplett erfüllen. Schon mal drüber nachgedacht?

Gruß
Michael

Ja, Aber bei Lissy sendet doch die Lok ins "Gleis" , bzw. via Loconet in die IB.

Trotzdem könnte Lissy sowohl ABC wie Infrarot erstzen. Aber sehr hoher Aufwand: Für Richtunganhängige Auswertung bräuchte man je Entscheidungsstelle immer zwie Infrarot-Empfänger. Jetzt noch ein Päärchen zum Triggern des Bremsens und eines zum Halten.

Das Ganze wird dann von der IB mittels zentraler Logik koordiniert, und wäre damals durchkalkuliert doppelt so teuer wie ABC mit BM3 Blockstellenlogik. und auch nicht so "robust" gegen Hand- oder Fehlfahrten, da die IB dann auch immer aus dem Programmierten Kontext reagiert. Bei ABC kann man mit geringem Aufwand lokal einfach die Straba-Ampel auch händisch auf Rot stellen , und manuell den Zug anhalten und anfahren , und die ABC-Bremse wirkt auch dann, wenn jemand händisch gegen den "Strich" fährt. Es sei denn er übersteuert bewusst.

Er stimmt allerdings wirklich: Die IB hat sogar genau 4 Linien in Ihrer internen Logik vorgesehen, so das man die Weichen wirklich mit zentraler IB-Logik hätte stellen können, was nur mit ABC und Railcom noch nicht geht.


Trotzdem Danke für den Tipp und Grüße
Frank

p.S. eine andere Idee war, RailCom-Anzeige-Ansteuerungen anzuzapfen, und mir Diodenmatrix eine hard-Wired Zuordnung Der Display-Ziffern zur Strabalinie zu machen, wäre aber zu kriminell und auch teuer geworden. Un wer kauft schon gerne solche Module, um sie selbst um- oder kaputt zu löten .

Nochmal zum ABC. ich glaube das überzeugenste Argument in der Diskussion im Verein war, das man ja mit der ABC-Lösung auch eine komplette Belegtmeldung hat, und immer noch eine hoch-differenzierende PC-Steuerung (Windigipet) drübersetzten kann. "Fallback-Lösung wenn nicht klappt" oder "Upgrade" wenn doch mal mehr gewünscht.

Frank,

also jetzt verstehe ich deine Argumentation nicht mehr so ganz. Du würdest Railcom Detektoren mit ABC und zusätzlichem Infrarot verbauen, aber zwei einzelne Infrarotmodule für richtungsabhängige Entscheidungen sind dir zuviel?

Außerdem funktioniert das System ähnlich wie ein Railcom Broadcast. Der Sender in der Lok sendet kontinuierlich seine Adresse und Zugkategorie. Der Empfänger, der übrigens lokal die Intelligenz programmiert bekommt. Lässt dann seine Logik ablaufen und kann alle anderen am Lokonet hängenden Elemente (z.B. Signale) direkt ansprechen. Reagiert auch auf deren Veränderung, also "händisches" Verstellen über Lokonet Befehle aus anderen Quellen. Nur für Lokbefehle (Geschwindigkeit, Funktionen auslösen) geht er über die IB oder eine andere Lokonet Zentrale.
Also im Prinzip nicht anders als dein Railcom/ABC/Infrarot Baustein.

Der einzige Punkt ist, dass hier die Bremsfunktion nur punktuell wirkt und man wie du gesagt hast von Hand gegensteuern kann.

Vlt. wäre es ja trotzdem eine Alternative zu eurer Magnetkodierung? Denn man könnte die Infrarotmodule ja auch nur zur Funktionsauslösung bzw. zum Fahrstraßen schalten verwenden. Aber dazu sollten wir dann wohl lieber einen anderen Thread aufmachen, sonst schweifen wir hier noch mehr ab.

Gruß
Michael

PS: Das mit den Rückmeldern verstehe ich auch nicht so ganz. Okay du kannst am BM3 Rückmeldemodule anschließen, bei Lissy könntest du diese Informationen direkt in einer Software auswerten falls gewünscht. Natürlich mit der Einschränkung, dass diese Information nur punktuell und nicht einen ganzen Block umfasst. Das kommt aber bei einer virtuellen Wegverfolgung im PC aufs gleiche raus, dürfte sogar noch besser sein, da man ja rein theoretisch von Modul zu Modul feste Kalibrierungswerte hat.

PPS: Um wieder OnTopic zu werden, gerade zum weiter dran rumbasteln müsste man ja keine gekauften Anzeigedisplays für Railcom zerlegen. Bei Paco gibt es ein Anleitung für ein entsprechendes Display und mit etwas Geschick könnte man sich eigentlich auch gleich einen entsprechenden Controller für eine Fahrstraßensteuerung programmieren und muss nicht den Weg über die Displayanzeige gehen.

Zitat

---

also jetzt verstehe ich deine Argumentation nicht mehr so ganz. Du würdest Railcom Detektoren mit ABC und zusätzlichem Infrarot verbauen, aber zwei einzelne Infrarotmodule für richtungsabhängige Entscheidungen sind dir zuviel?

---

Es hätte 13 oder 26 Doppellissies (1 oder 2 für einen BM3), je nachdem ob konstanter Bremsweg im Decoder ist oder nicht, gebraucht. Die Doppellissies waren auch Doppelteuer.

Wie hätten mit den Lissies eine recht unbeirrbare zentrale "Vollautomatik" gehabt, die wir nicht wollten und mehr als das doppelte bezahlt. So kann jetzt ein einfacher Öffner jederzeit eine Ampel auf Rot stellen , für manuelle Rangierfahrten etc.

Der Preis dafür, ist das wie die lokale Zugabhängige Weichenschaltung selber löten, weil in Railcom so nicht verfügbar.

Jetzt aber wirklich Schluss mit PFE

Zitat

---

PPS: Um wieder OnTopic zu werden, gerade zum weiter dran rumbasteln müsste man ja keine gekauften Anzeigedisplays für Railcom zerlegen. Bei Paco gibt es ein Anleitung für ein entsprechendes Display und mit etwas Geschick könnte man sich eigentlich auch gleich einen entsprechenden Controller für eine Fahrstraßensteuerung programmieren und muss nicht den Weg über die Displayanzeige gehen.

---

Macht mich fertig. Jetzt wo ich gerade die Teile für die erste Erkennungsschaltung bestellt habe , gibt es Doch ne RailCom-Lösung : Und woher krieg ich den Source-Code, damit ich nicht wirklich aus dem Display lesen muss Und der Verein lüncht mich, wenn ich jetzt sage, Silvers raus, Gold rein. Kommt zu spät, Basta Aus

Paco hat nur die fertigen Hex Files veröffentlicht. Wenn du also nicht die Daten vom Display auslesen möchtest, müsstest du wohl die ganze Software selber schreiben. Also von daher, die ganz perfekte Lösung gibt es von dort noch nicht. Wobei ich denke das er in Zukunft uns sicher noch mit ein paar Projekten beglücken wird.

Gruß
Michael

Hallo,

nach einem umfangreichen (und interessanten) Ausflug in die Welt von ABC, HLU und verschiedenen Moeglichkeiten hier mal ein ganz einfaches und kostenguenstiges Anwendungsbeispiel fuer RailCom mit (teils demnaechst) vorhandenen Komponenten.

Ich habe eine Drehscheibe mit vier Abstellungen und zwei Zufahrtsgleisen. Die Drehscheibe wird ueber einen lokalen Detektor mit Bahnstrom versorgt, die Zufahrtsgleise sind unmittelbar nach der DS elektronisch getrennt. Das Gleis, welches von der Drehbuehne angefahren wird, wird ueber diese mit Bahnstrom, also ueber den Detektor, versorgt, die Anzeige fuer den Detektor befindet sich auf der "Tafel", auf der auch meine Zentrale untergebracht ist.

Nun muss ich nicht mehr jedes Tuerchen des (zugegeben, nicht vorhandenen) Lokschuppens oeffnen, um zu sehen, was drinsteht. Ich fahre einfach mit der DS die Anschlussgleise ab und da wo eine RailCom-Lok steht, zeigt mir das Modul an, welche das ist.

Kleiner Tipp, falls das fuer jemanden interessant ist: Unterhalb der Drehscheibe, in der Mitte, an der Stelle, an der die Kabel in die Drehscheibe gehen, befindet sich ein Kondensator, welcher Mittelleiter und Aussenschiene brueckt. Dieser ist zu entfernen, da er die RailCom-Messages quasi aus dem Gleis filtert.

Hallo Leute!

ACHTUNG - Bitte bleibt den den üblichen Konventionen!

Ein BEFEHL im Digitalbereich ist immer ein DCC-Befehl, der entweder am BUS (Kabel oder Funk), oder am GLEIS versendet wird.

Wenn ich also davon spreche dass die Railcom Technik derzeit nicht vorsieht, dass ein Dedector einen *Befehl* absetzt, so meine ich, dass kein DCC-Befehl über das Gleis an einen Decoder AUTARK, also nicht im Zusammenspiel mit der Zentrale, abgesetzt wird.

HP0, HP1 HP2 sind keine BEFEHLE das sind Signalzustände und allerhöchsten für den Lokführer ein "Befehl".
HLU setzt DCC Befehle ab, ein Bremsgenerator setzt DCC-Befehle ab - aber nicht ABC!

Ein Pendelzugbetrieb mit ABC ist eine reine autarke Decoderangelegenheit - da wird kein einziger DCC Befehl über das Gleis zum Decoder versendet. Und das funktioniert auch nur mit Decoder, die ABC können - ok HLU geht auch nur mit Decoder, die HLU können ...
Aber ein "Bremsgenerator" für DCC ist Systemunabhängig.

Das darf man bitte nicht miteinander vermischen!

Wenn ich den Strom vor einem roten Signal abschalte, dann sende ich ja auch keinen BEFEHL ... auch wenn das Signal Rot zeigt und die Lok - weil kein Strom - stehen bleibt (Hp0)- es ist KEIN Befehl!
Im Gegenteil ich entziehe eine Lok auf einem stromlosen Abschnitt quasi der Kontrolle der Gleisbesetztmeldung (wenn ich keine Hilfsspanung dafür habe), Ich entziehe die Lok überhaupt der Digital-Kontrolle. Keinerlei Befehle, Rückmeldungen etc. sind dann möglich.

RAILCOM lebt aber davon, dass IMMER eine "digitale Kontrolle" vorhanden ist. Dass also immer DCC- Befehle vom Decoder empfangen werden können und dieser via Railcom eben diverse Rückmeldungen über das Gleis an die Zentrale und oder passende Dedektoren tätigen kann.
Der dann, wie schon mal beschrieben, möglicherweise nun autarke SCHALTAUFGABEN (HP0, HP1 etc.) vornehmen könnte.

Alternativ ist denkbar, dass so ein Dedector nun anstelle von ABC (mit dem ja wie erwähnt keine DCC-Befehle abgesetzt werden können) HLU-Befehle ans Gleis sendet.
Sprich: Die DCC-Spannung bleibt unverändert (bei ABC würde sie symetrisch/asymetrisch via Dioden und Relais geschalten werden), es würden nur DCC-Befehle für F/HLU ausgesendet werden, die aber nur von einigen Decoder ausgewertet werden können (ZIMO, TRAN, ESU).
GLEICHZEITIG wäre es wünschenswert, wenn nun der Dedektor via Railcom (also über das Gleis) den F/HLU an die Zentrale rückmelden würde.
Ohne Railcom macht das jetzt schon das MX9 ... eben über den CAN-Bus.
Die einzelnen Technologien und Vorgehensweise bitte also nicht vermischen. Die unterscheiden sich einfach zu sehr.
AUch muss man unterscheiden, ob man nun von einem DCC-Befehl soricht, oder ob ein "Fahrbefehl" gemeint ist.
Ersteres ist klar definiert, zweiteres kann alles möglich sein ...

Hallo Oliver,

so ein Modul in ähnlicher Bauform hatte Kühn zum zweiten Mal auf der Messe in Nürnberg ausgestellt gehabt (diesmal soll es aber in Serie gehen, bei der ersten Variante reichte der Speicherplatz und die Leistung des Prozessors nicht aus). Es ersetzt den Fahrstufenbefehl der Loks durch einen definierten Fahrstufenbefehl und das abhängig vom Schaltzustand z.B. eines Signals. Alle anderen Bewfehle laufen durch. Ähnlich könnte man das auch bei den Abschnitten regeln, wobei da dann die Abhängigkeit von der rückgemeldeten Adresse ist. Ein Beispiel: Der Zug fährt in einen Tunnel ein und schaltet die Beleuchtung ein und hinterher wieder aus.

Wolfgang

Tschuldigung, dass ich hier so reinplatze, aber kann man mit Railcom z.B. ein Signal bei Überfahren auf Rot stellen? Wie bei UB Lissy?

Hallo Robin,

mit Railcom geht das nicht, aber das braucht es nicht, das geht ja auch mit Schaltgleisen oder mit Rückmeldung an programmierbare Zentralen wie IB, Memory oder PC.

Grüße
Frank

Zitat von Centralstation

---

Tschuldigung, dass ich hier so reinplatze, aber kann man mit Railcom z.B. ein Signal bei Überfahren auf Rot stellen? Wie bei UB Lissy?

---

Hallo Robin,

dafuer reicht Dir auch ein Kontaktgleis und evt. eine kleine Schaltung (je nachdem, mit welchem Ereignis das Signal wieder auf Gruen gestellt werden soll)

Beachte bitte, dass sich RailCom und Lissy nicht unbedingt vergleichen lassen. Die Konzepte sind sehr unterschiedlich. Waehrend z.B. RailCom im entsprechenden Decoder bereits integriert ist, musst Du fuer Lissy einen Sender unter dem Fahrzeug montieren.
Auch gibt es, soviel ich weis, bei Lissy keine globale Rueckmeldung, mit der Du z.B. zu einem beliebigen Zeitpunkt oder gar dauerhaft (z.B. Ist-Geschwindigkeit) einen Speicherinhalt auslesen kannst.

Ausserdem ist Lissy eine Ein-Hersteller-Insel, waehrend an RailCom mehrere beteiligt sind.

Ich will Dich nicht von Lissy abhalten, ich finde das Konzept an sich nicht schlecht, halte es aber persoenlich fuer ueberholt.

Hallo zusammen:

Mir fällt jetz aber noch was ein, das ich für einen RailCom Kandidaten halte:

Bei automatisierten Abläufen zur Drehscheibe haben PC-Fahrer oftmals den Wunsch, eine ansonsten gut steuerbare Drehscheibe, mit einer Positionsrückmledung der Lok zwecks automatischen Abläufen nachzurüsten.

Man denkt sich, eine Belegtmeldung des Gleises sowie 2 Lichtschranken an den Enden der Bühne dewcken ausreichend den Informationsbedarf jeder PC- oder sonstigen Ablaufsteuerung .

Nun hat man in dieser Situation meist alle schwierig erstellbaren Zuleitungen zur Bühne (via Schleifkontaktringen) schon belegt.

Da bietet sich Railcom als durchs Gleis rückmeldende Protokoll doch theoretisch erst mal an , die auf der Bühne ruhig konvetnionell detectierte Belegtinfo von Lichtschranken und Gleis durch die beiden Gleisanschlüsse als Rückkanal an globalen oder lokalen Detector zu leiten.

Vielleicht kennt da jemand einen Ansatz, einen Loco- oder Funktions-Decoder oder sonst was zur Codierung der Bits in der DS zu gebrauchen :

Viele Grüße
Frank