1zu160 - Forum



Anzeige:


THEMA: RailCom -- was geht schon, was noch nicht

THEMA: RailCom -- was geht schon, was noch nicht
Startbeitrag
BE44 - 05.09.11 14:47
Hallo zusammen,

nach mehr als 2 Jahren Abstinenz von der Modellbahn, habe ich heute Morgen versucht, den Themenkomplex intelligente Rückmelder zu studieren. Zu RailCom habe ich folgende Fragen:

1) RailCom ist aktuell (noch) nicht in der Lage, einer Zentrale oder einem Rechner zu melden, wo sich eine Lok gerade aufhält, richtig?

2) Das heißt dann, falls das stimmt, nach wie vor muss die Zentrale oder der Rechner die eingerichteten Blockstrecken sehr gut kennen, um die Lok nach einmaliger Positionsangabe weiterverfolgen zu können?

3) Soweit ich mich erinnere, hatte Fleischmann (Trainnavigation) ebenso wie Uhlenbrock (Lissy) ein System entwickelt, um bestimmen zu können, wo sich ein Lok aufhält.
Würdet Ihr die Anschaffung solcher Systeme heute noch empfehlen?

4) Oder sollte man schon mit RailCom beginnen?
Das heutige System ist dann bislang im Prinzip ein reines (unintelligentes) Rückmeldesystem, wenn man einmal davon absieht, dass es wohl diesen Anzeigebaustein gibt, der mir sagt, dass eine bestimmte Lok gerade im kontrollierten Abschnitt war?

Wäre toll, wenn Ihr mich erhellen könntet,
viele Grüße,
Boris.

Hallo,

vergiss Lissy. Es ist eine Entwicklung von Uhlenbrock, die Fleischmann seinerzeit eingekauft hatte. Nachdem der Roco-Fleischmann Konzern nun keine Uhlenbrock Technik mehr im Programm hat, ist das gestorben.

Informationen zum Thema Railcom findest Du am besten bei Lenz:
http://digital-plus.de/digitalplus-railcom.php#lrc110

Da wird es vernetzte lokale Detektoren geben, mit einer USB-Anbindung zum Rechner.

Grüße, Peter W.
Hallo Boris,

zu 1: die Ecos und Ihr zugehöriger Detector melden eine mit Railcom plus Decoder ausgerüstete
Lok  im überwachten Bereich.

zu 2: ergibt sich aus 1

zu 3: ich für meinen Teil nicht ( arbeite mit der Ecos )

zu 4: ja und intelligent

generell melden alle Gleisbesetztmelder den Standpunkt einer Lok in einem rechnergesteuerten Programm nach positionieren auf diesem .

Gruß Richie
Hallo Peter, hallo Richie,

danke für die Antworten!

@ Richie: Muss noch mal genau nachfragen:
Wenn Du meinetwegen eine Lok von den Schienen hebst und ganz woanders wieder auf die Schienen setzt, wird RailCom dann heute schon erkennen, dass es sich um eben diese Lok handelt (= intelligente Rückmeldung) oder musst Du das dem System erst wieder beibringen und solange wird einfach nur erkannt, dass da ein Stromabnehmer auf die Schienen gekommen ist (einfache / unintelligente Rückmeldung)?

VG, Boris.
Hallo Boris

Railcom ist eine schöne Spielerei.

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Überleg mal, ob Du das wirklich brauchst.. ???.
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

Und Dich eventuell an einige Hersteller bindest, mit allen Loks und Rückmeldern....
Google auch mal unter Railcom Plus... da gibt es nämlich schon wieder was Neues...

Gruß Thomas (der auch so weiß, wo seine Loks stehen)
Hallo,
ich hänge mich hier mal mit einem speziellen Wunsch rein, den ich gegenüber Railcom oder einem anderen denkbaren BiDi-System gegenüber hege.
Ich fahre mit Lenz und den Traincontroller. Letzterer steuert automatische Zugfahrten und verfolgt die auch. Wenn es keine Fehler in der Hardware gibt, weiß das System immer, wo welche Lok ist. Aber, Shit happens, manchmal klemmt eine Weiche und dann ist der TC ausgetrickst.
Beispiel: Der Zug1 fährt von Block A über B und C nach D. Eine Weiche zwischen C und D klemmt und Zug 1 landet in Block E. Block E wird dann belegt gemeldet von einem unbekannten Zug, der vom Himmel gefallen ist. Der TC wartet auf Zug1 in Block D und hält diesen Block reserviert. Zug1 fährt unverdrossen weiter und nur ein Beenden dieser Zugfahrt und eventuell anderer kann Unglücke verhüten. Anschließend sind dann Fahrten zum Aufräumen angesagt, damit alles wieder so ist, wie es sein soll, also Realität und Programm übereinstimmen.
Wenn nun Zug1 sich in Block E melden könnte, wäre es ja möglich, dass der TC, eventuell nach einem Programmupdate, sich so verhalten kann, wie ein Navi, bei dem der Autofahrer sich verfahren hat, also einfach eine neue korrekte Fahrstrasse anlegen und andere Züge anhalten oder umleiten oder was auch immer. Das System könnte dann auf das unerwartete Auftauchen von Zug1 in E statt in D reagieren.
Dazu müsste nach meiner Ansicht die Railcom-Information durch die jeweiligen Belegtmelder weiter gegeben werden. Ist so etwas geplant? Oder sehe die Notwendigkeit, die Information über die Belegtmelder weiter geben zu müssen, falsch?
Viele Grüße
Friedhelm  
Hallo Friedhelm,

aus meiner Sicht soll das bei RailCom so kommen.

VG, Boris.
Hallo Friedhelm

Ich würde lieber die Ursache beheben ("klemmende" Weiche) als zu versuchen, mit Railcom die Fehler auszubügeln

Mit "klemmenden" Weichen würde ich niemals einen Automatikbetrieb fahren.

Gruß
Thomas
Hallo Thomas,
ich arbeite durchaus an den Ursachen. Es ist auch nicht so, dass es täglich passiert. Aber es kommt eben vor, da reicht ja ein Schotterkörnchen. Solange die Möglichkeit über Railcom nicht besteht, gibt es für mich keinen Grund, mich ernsthaft mit Railcom zu beschäftigen. Wenn das geht, würde ich darüber nachdenken. Wobei angesichts der Anzahl umzurüstender Loks und auszutauschender Belegtmelder das Ergebnis durchaus offen ist.
Viele Grüße
Friedhelm
Ja, mit RailCom sollte der Steuerungscomputer genau wissen welcher Decoder in welchem Block Strom zieht. Doch gibt es noch nicht so viele RaiCom Detektormodule (also Produkte) und die Frage ist mit welchem Bus die Meldungen dem PC-Program übergeben werden sollen. Siehe u.a. http://www.opendcc.com/s88/gbm_bidi/gbm_bidi.html Wie melden eure Melder dem Computer oder der Zentrale?

Gruß,
Harald.
Hallo,
ich würde erstmal abwarten wie es in Sachen Railcom und anderer Rückmeldesysteme weitergeht. Perfekt wäre es wohl, wenn es auch kleine Sender geben würde, mit denen man nicht rückmeldefähige Decoder nachrüsten kann. Mit dem Tams FD-R Basic geht das schon, aber der ist ziemlich riesig. Für mich wäre diese Nachrüstbarkeit ein Killerargument für ein bestimmtes System.
Hallo
Mir geht das mit Railcom schon zu lange auf den Keks.Wurde zu lange gezögert mit der kompletten Umsetzung. Habe ausserdem ne menge Rückmelder und Decoder verbaut, die tausche ich doch nicht alle wieder aus. Das hatt sich somit für meine Anlage erledigt, zumal alles perfekt läuft. Und wenn  im Autobetrieb mal extrem  selten ne Weiche klemmt, na gut. Wird der Zug per Regler zurückgesetzt.

Gruß Herbert
> Perfekt wäre es wohl, wenn es auch kleine Sender geben würde,
> mit denen man nicht rückmeldefähige Decoder nachrüsten kann.

Gibt es im proprietären Digitrax transponding System.

> Wurde zu lange gezögert mit der kompletten Umsetzung.

http://de.wikipedia.org/wiki/Time-to-Market

Das BiDi wäre toll für überwachtes Fahren bei Modultreffen. Für Heimanlagen ist es wohl so wie Herbert schreibt: Zu wenig und zu spät.

Gruß,
Harald.
Zitat

die Frage ist mit welchem Bus die Meldungen dem PC-Program übergeben werden sollen.

dazu gibts z.B. auf der Seite von Lenz eine Antwort.

Zitat

Habe ausserdem ne menge Rückmelder und Decoder verbaut, die tausche ich doch nicht alle wieder aus.

muss auch nicht sein. Könnte theoretisch auch parallel laufen oder aber durch nachgeschaltete Module eine Weitergabe der Daten ermöglicht werden.

Zitat

Für mich wäre diese Nachrüstbarkeit ein Killerargument für ein bestimmtes System.

Es wird Nachrüstmöglichkeiten geben. Unabhängig davon muss man aber auch die Neueinsteiger berücksichtigen. Irgendwann kommt nunmal etwas neues auf den Markt. Und eine Railcom-Fähigkeit muss noch lange nicht das Ende der "Nicht-Railcom-Produkte" bedeuten.

Zitat

Ja, mit RailCom sollte der Steuerungscomputer genau wissen welcher Decoder in welchem Block Strom zieht.

so ist es. Und wenn man sich etwas näher mit dem Thema Railcom beschäftigt, wird man feststellen, dass das nur ein Bruchteil von dem ist, was möglich ist. Wer mehr wissen möchte, kann sich ja mal mit dem globalen Railcom-Detektor beschäftigen. Hier wird nicht jeder einzelne Abschnitt überwacht sondern ganze Boosterbereiche bzw. ganze Anlagen.

Zitat

Wenn Du meinetwegen eine Lok von den Schienen hebst und ganz woanders wieder auf die Schienen setzt, wird RailCom dann heute schon erkennen, dass es sich um eben diese Lok handelt

klar. Darüber wurde ja auch schon einiges geschrieben.

Gruß
Tomi
Guten Abend zusammen,

vielen Dank für die Antworten.

@ Tomi: Vielleicht bin ich ja begriffsstutzig, aber gerade das Weiterverarbeiten der ausgelesenen Adresse scheint ja bei RailCom noch nicht zu laufen.
Lenz hat den dafür notwendigen "Lokaler RailCom Detektor LRC130" ja noch gar nicht im Vertrieb.
Oder verstehe ich was falsch, geht es auch über andere Geräte?

Und von daher auch noch mal meine Frage:
Wäre so etwas wie Lissy dann keine Alternative? Oder Trainnavigation von Fleischmann?

VG, Boris.
> dazu gibts z.B. auf der Seite von Lenz eine Antwort.

Dazu sagt Lenz: Zuerst brauch ich ein XpressNet dass "demnächst" auf 128 Teilnehmer erweitert wird. Auch habe ich schon einen Boosterbus verlegt.  Dann brauch ich einen RailComBus (max 256 Module) der wahrscheinlich den RS-Bus obsolet macht. Dann noch einen Computer der Windows XP (alleiniges unterstütztes OS) fahren muss. Irgendwie bin ich von den Antworten nicht total überzeugt, vor allem nicht dass es nicht besser gehen könnte.

Gruß,
Harald.
Hallo Boris
Zitat

Vielleicht bin ich ja begriffsstutzig, aber gerade das Weiterverarbeiten der ausgelesenen Adresse scheint ja bei RailCom noch nicht zu laufen.

wie kommst du zu dieser Aussage?

Zitat

Oder verstehe ich was falsch, geht es auch über andere Geräte?

Tams bietet z.B. auch schon Railcom-Bausteine an.

Zitat

Wäre so etwas wie Lissy dann keine Alternative? Oder Trainnavigation von Fleischmann?

vergiss das. Hier kommst du ganz schnell an die Grenzen des Möglichen. Prinzipiell ist das System gar nicht mal so schlecht, jedoch müssen auch hier spezielle Bausteine zusätzlich verbaut werden (sowohl an der Lok als auch auf der Anlage). Da hier eine Übertragung der Daten nur immer dann funktioniert, wenn die Lok exakt über der in der Anlage befindlichen Empfängerbausteine fährt bzw. steht, ist das eher schlecht, was die Datenmenge angeht.
Bei Railcom kann so lange übertragen werden, wie die Lok im entsprechend überwachten Abschnitt steht.

Hallo Harald

man muss hier auch verschiedene Konstellationen berücksichtigen bzw. betrachten. Wenn z.B. schon eine vorhandene Belegtmeldung inkl. Rückmeldung vorhanden ist (egal über welchen Bus), dann brauchts den Railcom-Bus. Dieser verbindet alle Detektoren (wenn es sich um lokale Detektoren handelt). Dann wird von jedem Detektor ein entsprechender Abschnitt (oder mehrere) angeschlossen. Möchte man nur die Lokadressen anzeigen, so benötigt man lediglich noch ein Anzeigemodul. Möchte man aber die Daten in einem PC auswerten bzw. die Daten zur Steuerung der Züge mit einbeziehen, so muss natürlich noch eine Verbindung zum PC erfolgen. Diese wird dann über eine Art "Interface" an den PC weitergegeben. Im Falle Lenz wird das dann das Railcom-USB-Gateway sein.
Ist keine Belegmeldung vorhanden, so gibt es auch die Möglichkeit, Detektoren inkl. Belegtmeldung zu verbauen. Das ist besonders interessant für Neueinsteiger, die noch keine Anlage haben. Da wäre es ja Blödsinn, erst "weniger intelligente" Belegtmelder einzubauen um dann zusätzlich die Intelligenz des Railcom-Systems "aufzupfropfen".

Noch etwas Allgemeines:
Man muss auch hier, wie bei vielen anderen Dingen, ganz klar erst einmal eingrenzen, was ich mit dem System bewirken möchte. Ist es nur an bestimmten Stellen die Adresse zu übertragen? Bei Anlagen, die nicht per PC gesteuert werden, kann das schon mal von Vorteil sein, wenn man z.B. im Sbhf jede Lok bzw. Adresse auf einer Anzeige dargestellt bekommt. Dass so etwas bei größeren Sbhf (viele Gleise) auch ins Geld gehen kann, ist klar. Aber darum gehts hier ja erst einmal nicht. Im genannten Fall wären also alle Sbhf-Gleise mit einem Detektor zu überwachen.

Möchte man aber mit weiteren Daten "arbeiten", die vom System übertragen werden können (die Zukunft wird zeigen, was hier alles möglich ist), muss natürlich entsprechend mehr überwacht werden. So kann es dann sein, dass man seine ganze Anlage (alle Abschnitte) mit lokalen Detektoren überwacht. Oder aber dann über globale Detektoren alle in diesem überwachten Bereich befindlichen Daten "abrufen" kann.

Ich hoffe, ich konnte ein bisschen weiter helfen.

Gruß
Tomi

Eine Programmierung vom TC die z.B. bei der Automobilindustrie nicht akzeptiert würde (keine Fehlermeldung) mit eine unreichende Rückmeldung hat nicts zu tun. Wenn  Zug 1 in Block 4 erwartet wird, aber in Block 5 fährt, bedeutet es entweder das die Weiche klemmt oder das es irgend einen Gegenstand "im Weg" gefallen ist.

Mit eine Bidirektionale unterhaltung zwischen Anlage und Zentrale bzw. PC stelle ich mir viel mer for, als nur das die Loks sich identifizieren. Die Decodern können viele mehr Daten speichern (z.B. die Speed Profile) und bei bedarf mitteilen. Und warum eigentlich nur die Loks? Warum nicht auch die restlichen Decodern? Die Weichendekodern könnten z.B. eine bestätigung abgeben, wenn eine Weiche betätigt wurde (z.B. nach bemessung des Stromverbrauchs).


Hallo zusammen,

wieder vielen Dank für die Beiträge.

@ Tomi:
War auf jeden Fall hilfreich!
Interessant finde ich ja schon, dass Lenz als Lizenzgeber von RailCom dieses im Prinzip bislang kaum ausschöpfen kann (da der notwendige Detektor und der Bus fehlen), Tams das aber offenbar kann (habe mich gerade auf deren Seite informiert, scheint ja alles Notwendige vorhanden zu sein; danke noch mal für den Hinweis, hätte ich natürlich selbst schon mal schauen können).

Tomi, fährst Du denn mit RailCom, kannst Du uns mal sagen, was genau Du installiert hast??

VG, Boris.
Hallo Boris

auch wenn noch nicht alle Produkte auf dem Markt sind heißt das noch lange nicht, dass Lenz das nicht ausschöpfen kann, was da entwickelt wurde.

Mit Railcom bzw. BiDi beschäftige ich mich schon einige Zeit. Werde dazu demnächst mal einen extra Thread aufmachen, wobei ich da momentan immer etwas vorsichtig bin, da hier sehr schnell ein Thema "zerrissen" wird und dann macht das weniger Spaß.

Viele Grüße
Tomi
...
wäre aber echt hilfreich Tomi, wenn jemand Wissendes mal was Zusammenhängendes zu dem Thema schreiben würde. Ansonsten muss man nämlich echt in den Brocken suchen und jeder Beitrag erzeugt neue Fragezeichen, die man dann wieder klären muss.

VG, Boris.
Hallo,
da muss ich Boris zustimmen...
Hallo Frank

hier wurde schon oft was über Railcom geschrieben. Aber mich nervt einfach das ewige gemotze und gelästere von "Kollegen", die damit einfach noch nicht so viel Erfahrung haben bzw. sich damit nur am Rande beschäftigt haben und deshalb auch viele Dinge in Frage stellen, was sie gerne machen können. Nur von vornherein, ohne jeglichen Einblick in die Materie gleich über alles negativ urteilen, das geht mir halt auf den Senkel.
Gerne kann ich aber auf gezielte Fragen eingehen. Etwas zusammenhängendes schreiben? Da könnte ich Bücher mit füllen. Schau doch mal auf verschiedenen Internetseiten, was es da so über Railcom bzw. BiDi gibt. Auch Arnold Hübsch hat schon einiges auf seinen Seiten stehen. Wenn dazu noch weitere Fragen sind, wird hier sicher der ein oder andere noch etwas schreiben. Soweit es mir möglich ist, gebe auch ich gerne Auskunft.

Viele Grüße
Tomi
Nachtrag:
Ausserdem dachte ich, dass ich schon so einiges in @16 geschrieben habe?
...keine Frage, hast Du!!
Hallo Boris,

wurde zwar schon beantwortet ,aber es ist so ,daß man eine Lok in einem überwachten Bereich vom Gleis nimmt und sie an anderer Stelle wieder aufs Gleis bringt ,sie sich sofort in dem neuen Bereich meldet. Es ist egal mit welcher Lok man dies tut, solange sie mit einem Railcom Plus Decoder ausgestattet ist. Der Lokpilot micro V 4.0 von Esu ist 100% zuverlässig darin.

Die Weichendecoder ( Switchpilot ) sind ebenso in der Lage eine nichtgestellte Weiche an die Ecos zu melden ( Stromflussüberwachung bei endabgeschalteten Weichen ).

Gruß Richie
Zitat

1) RailCom ist aktuell (noch) nicht in der Lage, einer Zentrale oder einem Rechner zu melden, wo sich eine Lok gerade aufhält, richtig?

2) Das heißt dann, falls das stimmt, nach wie vor muss die Zentrale oder der Rechner die eingerichteten Blockstrecken sehr gut kennen, um die Lok nach einmaliger Positionsangabe weiterverfolgen zu können?



Ich verstehe die vorzüge von RailCom nicht.
Da ich nun auf RailWare umgestiegen bin, weiß ich wie "genau" so eine Rückmeldung sein muss. Es sind deutlich weniger Rückmelder erforderlich, als manch einer glauben mag.

Wenn ich mir die ganzen RailCom Komponenten + Aufwand anguckt, dann sehe ich auch kostentechnisch kaum ein unterscheid zwischen steuerung mit PC und über RailCom.

RailCom mag vielleicht automatisch wissen, wo welche Lok aufgegleist wird, aber ob das ein Mehraufwand rechtfertigt ?

Gruß,
Basti
In diesen Tagen findet der Kongress der MOROP statt.

Ein Bekanter erzählt mir das am vergangenen Wochenende haben sie über die Normen debatiert. Hauptsächlich haben sie sich um Digitaltechnik gekümmert (Normen 6xx).

Unsere deutschen Kollegen scheinen auf Lissy und Loconet zu stehen wärend unsere französischen Nachbarn eher für RailCom sind.

Mein Fazit: wartet lieber dass die Amerikaner (NMRA) sich entscheiden und die Herstellern entsprechend handeln.
Servus,

vielleicht muss man einfach mal zusammentragen was eigentlich gewünscht wird. Ziel muss sein die bestehende Technik zu vereinfachen, nicht noch zusätzliche Freiheitsgrade hinzuzufügen. Ich skizziere mal eine Idee...

Ich will eine (!!) Kiste mit 16 Anschlüsse für Blöcke dran sind, ein Anschluss für Dekoder (DCC out) und ein Netzkabel. Das Ding ist Zentrale, Booster und Rückmelder in einem und kann feststellen welche Lok auf welchem Block welche Eigenschaften hat.

PC Anbindung über WLAN, LAN oder USB. Beliebig kaskadierbar im 16er Raster. Die Slaves identische Teile. Darüber hinaus werden nur noch Weichendekoder benötigt, daran ändert sich nichts.

Mit 16 Blöcken kann ich schon eine ordentliche Anlage mit beispielsweise 4 Gleisen im Bahnhof, 8 im Schattenbahnhof betreiben. Die restlichen 4 Blöcke für Abstellgleise oder ähnliches. Mit 32 Blöcken kann man schon richtig dicke Anlagen betreiben. Darüber hinaus werden hier nur wenige kommen...

Zum Vergleich brauch ich heute dafür eine Zentrale (ca. 300 EUR) und Belegtmelder (ca. 130 EUR je 16er). Booster ist meist in der Zentrale, aber ich würde auch mal alle 16 Blöcke einen vorsehen. Da hat man doch auch preislich etwas spielraum!

Grüßle
Elvis



> aber ob das ein Mehraufwand rechtfertigt ?

Das ist ja relativ. Also wenn die Rückmelder relativ billig wären (*) und ich sie einfach an den schon vorhandenen Bus (könnte man mit LocoNet) anhängen könnte wäre der Aufwand ja nicht so hoch.

> kostentechnisch kaum ein unterscheid zwischen steuerung mit PC und über RailCom

Ich glaube nicht dass BiDi/RailCom/Transponding ohne ein Computerprogram wirklich zum Tragen kommt. Da bekäme man Anmeldung des Decoders in der Zentrale und besseres PoM. Für Steuerung braucht man auf alle Fälle ein Interface vom Detektor zum Computer (direkt oder via Zentrale) und vom Computer zur Zentrale und ein "intelligentes" Program im Computer.

Tams hat auch einen eigenen Bus zwischen den Rückmeldemodulen der nach http://www.tams-online.de/htmls/download/RC-Talk-Protokoll.txt ein RS485 ist. Dann kann man nach http://www.tams-online.de/htmls/produkte/RC-Link/produkte_RC-Link.html maximal 24 RDC-2 auslesen, also 48 Blocks. Oder nur 24 wenn man die Spezifikation von RC-Talk durchliest  (0xFC DD* A1* A2* 0xFF DD = Detektoradresse (0x01 - 0x18)) weil
RC-Talk nicht mehrere Blocks per Detektor kennt. Also noch etwas unklar das Ganze.

Gruß,
Harald.


(*) Bei tams sind wir bei EUR 20 / Block, bei Digitrax $30 / Block. Leider scheint man auch vor der Einführung nicht analysiert zu haben welcher Preis der Markt annimmt. Bei EUR 5 / Block wäre man bestimmt unter det Schmerzgrenze vieler. Frage ist ob die Elektronik wirklich so teuer ist oder was wir zahlen. Also ein Bar-code reader kostet $30. Wenn ich so einen einbaue wäre die Ablesung zwar nur punktuell, aber sehr billig bei den Fahrzeugen nachzurüsten. Blipp-blipp-blipp....

pro Block oder pro Modul ?

20 - 30 Euro PRO BLOCK ist mal häftig. DIe Uhlenbrock-RM die ich verwende kosten 60-70Euro das Stück, das bei 8 Blöcken pro Modul doch noch recht Günstig.

Ich meinte mit vergleich zur PC-Steuerung, dass man quasie ein echtes Gleisbidlstellwerk hat und diese hier mit einbaut: RailCom Adressanzeige LRC120

Ähnlich bei Lissy mit dem Gleisbildstellwerk von Uhlenbrock.

Daher der kostenvergleich. Die Module müssten sonst schon für 5 Euro rausgehen, damit man sich sowas leisten kann.

Gruß,
Basti
@ 28

Hallo Elvis,

Du wirst es kaum glauben, aber genau so etwas ist bereits in der Denke und es existieren dazu schon erste Pläne. Empfehle Dir dazu mal die Seite www.opendcc.de und dann dazu das Forum.
Dort findet man auch schon, neben Blücher, einen fertig entwickelten und funktionierenden BiDi-16 Fach Rückmelder.

Gruß aus Hamburg

Thorsten
Hallo Thorsten,
man muss aber dazu sagen, dass BiDiB nicht identisch mit Railcom ist. Aber ich bin sehr gespannt drauf, da ich die OpenDCC benutze, wär das wohl das ideale System für mich...
Hallo msfrog,

das stimmt, hatte ich aber auch nicht erwähnt.
Zur Zeit kann der 16-Fach BiDi-Melder von Herrn Kufer ja auch noch nicht über BiDiB melden.
Weil gibt noch keine Zentrale dafür.
Der 16-Fach BiDi-Melder von Blücher kann aber dieses schon übers Loconet melden und dort kann z.B. Traincontroller diese auch auswerten.

Gruß

Thorsten
Hallo Thorsten,
sollte auch nur nochmal auf den kleinen Unterschied hinweisen ;)
Wobei auf http://www.opendcc.de/s88/gbm_bidi/gbm_bidi.html wird auch ein Nicht-Problem gelöst:
"...Jetzt stürzt das PC-Programm ab ..." Ein gescheites PC-Program schreibt seinen Zustand regelmäßig in einen Statusfile so daß bei einem Absturz vielleicht 10 Sekunden verloren gehen. Die Programmänderung wäre wahrscheinlich billiger als BiDi.

Doch zum GBM16: Der GBM16 ist wahrscheinlich das "Produkt", dass einem reellen Bedarf am ehesten deckt. Wenn ein oder mehrere Hersteller sich zu OpenDCC bekennen würden und Produkte herausbringen.... Aber nur mit proprietärem Zeugs kann man Geld scheffeln, oder?

Gruß,
Harald.
Hallo Harald,
DCC ist ein offener Standard, und damit verdienen so einige Firmen Geld. Deine letzte Aussage ist also ein wenig polemisch.
Hallo,

Zitat

zu OpenDCC bekennen


Wie soll sich ein Dritter zu etwas "bekennen" was er nicht selbst entwickelt hat?

Grüße, Peter W.
Servus

@Thorsten: Ja... und nein. OpenDCC ist eine Lösung, aber halt nicht für den Otto-Normal-Modellbahner!

Ich selber kann wohl schon eine OpenDCC-Zentrale mit dem Rückmelder in ein Gehäuse nageln. Ich bin aber auch ein Nerd!

Wichtig ist letzlich aber das es das fertig und erschwinglich am Tresen des Modellbahnfachhändlers geben muss. Und am besten steht da auch noch Trix/RoFl oder sonstwas drauf. Es geht um das Gesamtkunstwerk.

Denn der Kunde steht halt immer noch am Tresen und versteht Bahnhof! :o)

Grüßle
Elvis

P.S.: mal ehrlich, der Print auf SMD Basis ist schon Hardcore. Respekt! Aber das ist nichts mehr für Hobbylöter...



> Wie soll sich ein Dritter zu etwas "bekennen" was er nicht selbst entwickelt hat?

Siehe RedHat, SuSE etc, die packetieren und verkaufen auch die Entwicklung von anderen nachdem sie für den Verbraucher etwas Mehrwert hinzufügen (und sei es nur der Karton).

Gruß,
Harald.
Zitat

P.S.: mal ehrlich, der Print auf SMD Basis ist schon Hardcore. Respekt! Aber das ist nichts mehr für Hobbylöter...



Da sind die Baugruppen die ich in unserer SMD-Fertigung mit bearbeite meistens "grober scheiss" gegen

Aber schön mal nen abgerauchten Decoder unterm Mikroskop zu bewundern

Gruß,
Basti
@ Elvis,

moin Elvis, daher ja auch mein Hinweis auf den Blücher 16-Fach GBM mit Loconet-Interface.
Übers Loconet mit Loconetbuffer soll der schon in Zusammenhang mit Traincontroller Loknummer und Fahrtrichtung melden können.

Was Opendcc angeht, da ziehe ich auch echt meinen Hut.
Man kann kaum glauben, das Herr Kufer und einige seiner Mitstreiter das nur als Hobby machen.

. War auch nur als Hinweis gedacht das es Eigenentwicklern gelingt etwas zu entwickeln, was die "Profis" seit der Ankündigung von BiDi nicht schaffen..

Gruß

Thorsten
Hallo,

sehr schön, den Blücher Gleisbesetzmelder kannte ich bisher nicht:
http://www.bluecher-elektronik.de/index.php/produkte/gleisbesetztmelder/gmb16xn

Und die Kommunikation mit Rocrail scheint auch kein Problem zu sein - Rocrail ist zudem kostenlos:
http://wiki.rocrail.net/doku.php?id=bidib-de
http://forum.rocrail.net/viewtopic.php?t=3073

>>
Macht für eine Grundausstattung mit 16 Gleisbesetzmeldern, vorausgesetzt man hat eine Zentrale mit (USB-)Anschluss zum PC:
1x GBM16XN  >> 148€
1x dazugehöriges LocoNet-Interface >> 19,25€
1x Rocrail >> kostenlos

Macht 10,46€ pro RailCom-überwachten Gleisabschnitt.

Oder ist da noch ein Haken bzgl. GBM16XN > LocoNet-Interface > USB-Interface > PC.
Da bin ich noch nicht ganz schlau draus geworden ...


Gruß
Ulrich

Hallo zusammen,
bei aller Freude über OpenDCC - aber in der FAQ http://www.opendcc.de/s88/gbm_bidi/gbm_faq.html lese ich zumindest raus, daß wegen der unklaren Lizenzsituation BiDi/RailCom eben nicht mehr unterstützt wird. Schade, muß ich sagen.

Die SMD-Platine finde ich persönlich noch ganz moderat (sowas haben wir hier auch bei handbestückten Mustern). Klar, das ist nix für das 80W Brateisen mit Netzstecker und ohne Regelung, und wer irgendwelche Handycaps hat wird da sicherlich auch seine Probleme bekommen.

Viele Grüße,
Torsten
Hallo Torsten,

ja, das stimmt leider. Es gibt keine offizielle Unterstützung mehr und keinen öffentlichen Support über Herrn Kufer. Verwendbar ist es trotzdem und es funktioniert.
Laut Aussagen von Herrn Kufer ist da aber wieder etwas Bewegung in die Sache gekommen und da die Lizenzen für BiDi ja kostenfrei sind sollte es in naher Zukunft wohl wieder auch offiziell unterstützt werden. Auch wenn Firma Lenz und Esu sich natürlich nicht vor Begeisterung auf die Schenkel klopfen werden. Aber wenn man einfach dann mal den Kauf von ESU und Lenz-Decodern boykotiert, kommt vielleicht Bewegung in die Sache
Auf jeden Fall gibt die werte Opendcc- Gemeinde da nicht auf.  Wie heißt es doch so schön: die Hoffnung stirbt zu letzt.

Gruß

Thorsten
  
Hallo Thorsten

Zitat

Aber wenn man einfach dann mal den Kauf von ESU und Lenz-Decodern boykotiert, kommt vielleicht Bewegung in die Sache


Das mach ich bereits seit geraumer Zeit. ESU hat sich mit der miesen Regelung aus dem Rennen geworfen und Lenz durch die zu hohe Kriechgeschwindigkeit.
Hi Basti
Zitat

Wenn ich mir die ganzen RailCom Komponenten + Aufwand anguckt, dann sehe ich auch kostentechnisch kaum ein unterscheid zwischen steuerung mit PC und über RailCom.

Wieso "+ Aufwand"? Da gibts nicht viel mehr Aufwand, zumindest dann nicht, wenn man neu anfängt.
Die Steuerung mit dem PC schließt Railcom keineswegs aus und anders herum auch nicht.

Zitat

RailCom mag vielleicht automatisch wissen, wo welche Lok aufgegleist wird, aber ob das ein Mehraufwand rechtfertigt ?

Mit Railcom kann man nicht nur wissen, wo welche Lok aufgegleist ist sondern auch, wo sich welche Lok im Betrieb befindet. Und schonmal darüber nachgedacht, welche Möglichkeiten plötzlich vorhanden sind, wenn eine Lok "mitteilen" könnte, wieviele Millimeter sie gefahren ist???

Hallo Elvis
Zitat

Das Ding ist Zentrale, Booster und Rückmelder in einem und kann feststellen welche Lok auf welchem Block welche Eigenschaften hat.

Railcom ..., ich sage nur: globale Detektoren!!!!

Hallo Harald
Zitat

Also ein Bar-code reader kostet $30. Wenn ich so einen einbaue wäre die Ablesung zwar nur punktuell, aber sehr billig bei den Fahrzeugen nachzurüsten.

billig ja, keine Frage. Und funktioniert auch. Aber nicht mit dem möglichen Funktionsumfang des diskutierten zu vergleichen.

Viele Grüße
Tomi


Nur registrierte und eingeloggte User können Antworten schreiben.
Einloggen ->

Noch nicht registriert? Hier können Sie Ihren kostenlosen Account anlegen: Neuer N-Liste Account





Zum Seitenanfang

© by 1zu160.net;