[suffix]

Hallo Erich,

es ist im Prinzip ein UART/RS232 mit Start- und Stopbit und 4us Bitdauer, also wie die Protokolle zum Dekoder auch ein "normales" Rechtecksignal. Hinzu kommt aber dass die Spannung am Gleis während der Railcom-Phase deutlich niedriger ist als im Normalbetrieb, sie ergibt sich aus den paar mA die die Dekoder schicken und dem Sense-Widerstand im Detektor (sehr niederohmig). Ist kein Detektor verbaut und die Zentrale schliesst lediglich die Anschlüsse ans Gleis kurz, passiert am Gleis gar nichts, Spannung (fast) gleich 0 (zumindest nichts messbares, und schon gar nichts was irgendein Dekoder als Flanke am Dateneingang interpretieren sollte).

Probleme aus dieser Ecke kann man komplett ausschliessen indem man sicher stellt, dass kein Railcom-Sender auf der Anlage ist, dann ist während der Lücke mit Sicherheit komplett Ruhe.

Auch ich wundere mich über das von dir zitierte, wenn Railcom wirklich ein Problem ist sollte mittels DCC an der Lok gar nichts funktionieren und sicher nicht nur ein paar Funktionstasten/Fu-Ausgänge nicht. Die Railcom-Pause wird nach jedem DCC Paket eingebaut, völlig egal ob für Fahren oder Funktionen.
Das einzige was ich mir vorstellen kann: Märklin hat als "Sicherheits"-Feature für die empfindliche Kupplung eingebaut, dass der entsprechende Fu-Ausgang nur aktiviert wird, wenn ein "stabiles" Gleissignal anliegt. Wenn nun die Railcom-Pausen als ständige Strom-/Kontaktunterbrechungen interpretiert werden und das wiederum als instabiles Gleissignal.. Dann ja dann könnte das Beschriebene passieren. Evtl ist es ungesund für die Kupplungen wenn der Strom wegbricht während sie sich grade verformt.. Das wäre aber unter allen Umständen nicht sehr betriebssicher.

Du musst übrigens nicht jeders mal ein "R" setzen wenn du Railcom erwähnst.. siehe hier http://normen.railcommunity.de/RCN-217.pdf

[hu.ms]

Zitat von Modelleisenbahnfan im Beitrag Frage zu Märklin 36344 (BR 333) Funktion Telexkupplung

---

Hallo Rüdiger,

warum soll das ein ESU - Problem sein? Railcom ist korrekt implementiert und funktioniert.
Das ist ein Märklin - Problem, wenn Modelle oder Dekoder designt werden, die mit Railcom inkompatibel sind.
Heutzutage - als angeblicher oder tatsächlicher Marktführer und selbsternannter Innovationstreiber - ein Modell mit Dekoder herauszubringen, welches in einer Railcomumgebung nicht funktioniert, ist schon ein Armutszeugnis und zeugt von einer gewissen Ignoranz. Zumal die aktuellen Märklin - Dekoder ja DCC beherrschen und Märklin mit der Marke Trix ja auch das DCC - Segment bedient.
Freundliche Grüße
Jürgen

---

Wieso soll das ein mä-problem sein ?
Railcom interessiert mä vermutlich nicht.
Genauso wenig wie div. andere steuerprotokolle bzw. besonderheiten, die ebenfalls nicht in der produktbeschreibung geannt sind.
Einfach die lok zurückgeben, wenn sie in der eigenen umgebung nicht funktioniert.
Vielleicht machen das noch 10 andere auch aus diesem grund.
Ob das allerdings mätrix dazu bewegt anpassungen vorzunehmen halte ich für unwahrscheindlich.
Muss man einfach unter "dumm gelaufen" verbuchen - bei rückgabe ohne finanziellen schaden verschmerzbar.

Hubert

[Badaboba]

Zitat von Modelleisenbahnfan im Beitrag Frage zu Märklin 36344 (BR 333) Funktion Telexkupplung

---

Hallo Rüdiger,

warum soll das ein ESU - Problem sein? Railcom ist korrekt implementiert und funktioniert.
Das ist ein Märklin - Problem, wenn Modelle oder Dekoder designt werden, die mit Railcom inkompatibel sind.

---

Hallo Jürgen,
definitiv hast aktuell Du das Problem, nicht Märklin. Wahrscheinlich bekommt auch ESU Probleme, denn deren Zentrale kaufen doch primär "AC-Bahner", denn die harten DCCler wollen keine Ecos mit mfx-Gedöhns. Wenn selbiges nicht mehr so richtig funktioniert mit den neuen Kupplungen, den vielen Funktionen etc., dann bekommt ESU richtig Probleme, denn wer kauft dann noch deren Zentrale? Die CS3 soll ja auch deutlich mderner und leistungsfähiger sein. Jetzt kommt auch noch ein erwachsener Funkhandregler...
Ich würde also ESU über das Problem informieren und ein update abwarten, denn das wird/muss kommen....
"Marktpolitisch" macht Märklin aktuell alles richtig. Kann man beklagen und/oder bedauern, muss man aber nicht.

[DeMorpheus]

Zitat

---

definitiv hast aktuell Du das Problem, nicht Märklin. Wahrscheinlich bekommt auch ESU Probleme, [...] dann bekommt ESU richtig Probleme [...]
Ich würde also ESU über das Problem informieren und ein update abwarten, denn das wird/muss kommen....

---

Du möchtest ein bestehendes, genormtes Protokoll ändern, weil Märklin nicht in der Lage oder nicht Willens ist, seine Decoder kompatibel zu bauen?

Zitat

---

"Marktpolitisch" macht Märklin aktuell alles richtig. Kann man beklagen und/oder bedauern, muss man aber nicht.

---

"Märklin weiß, was sie tun" hieß es auch immer, als die Decoder in den Märklin-Loks noch kein DCC konnten, die gleiche Hardware in den Trix-Loks aber schon. Und oh Wunder, heute bekommen beide identische Decoder mit DCC. Denn sie wussten ja so gut, was sie tun.

[Badaboba]

Zitat

---

"Märklin weiß, was sie tun" hieß es auch immer, als die Decoder in den Märklin-Loks noch kein DCC konnten, die gleiche Hardware in den Trix-Loks aber schon. Und oh Wunder, heute bekommen beide identische Decoder mit DCC. Denn sie wussten ja so gut, was sie tun.

---

Hallo Moritz,
das ist Deine Lesart.
Man sollte die aktuellen Veränderungen schon wahrnehmen, dann passen auch die Schlussfolgerungen...

[OttRudi]

Zitat

---

Zitat

---

definitiv hast aktuell Du das Problem, nicht Märklin. Wahrscheinlich bekommt auch ESU Probleme, [...] dann bekommt ESU richtig Probleme [...]
Ich würde also ESU über das Problem informieren und ein update abwarten, denn das wird/muss kommen....

---

Du möchtest ein bestehendes, genormtes Protokoll ändern, weil Märklin nicht in der Lage oder nicht Willens ist, seine Decoder kompatibel zu bauen?

---

Warum ändern, bis jetzt ist es ein ESU - Problem, da es nicht bekannt ist, dass dies Problem z.B. mit einer TAMS-Zentrale auftritt.
Falls die Kupplung aus technischen Gründen nicht mit Railcom kompatibel ist, was ja durchaus sein kann, ist es halt so. Die Modelle sind halt für einen bestimmten Kundenkreis nicht geeignet. Es gibt doch keinen Kaufzwang.

Auch es wenn ein wenig OT ist. Mercedes Autos sind sicher sehr gute Autos, aber entsprechen nicht meinen Vorstellungen. Deswegen ist Daimler keine schlechte Firma und ich akzeptiere es ganz einfach, dass ich nicht Zielkunde von dieser Firma bin. OT Ende.

[suffix]

Sorry, aber einige die hier mitschreiben scheinen nicht wirklich über Railcom Bescheid zu wissen (was es ist und wie es implementiert ist).

Railcom ist KEIN Steuerprotokoll! Es ist der RÜCKkanal von DCC, damit gesprochen wird muss der Decoder etwas tun! Aktiviertes Railcom auf der Anlage hat erstmal keinerlei Auswirkungen auf Dekoder die kein Railcom können, für die sieht es einfach wie eine kurze Stromunterbrechung aus - das hatte ich weiter oben schon lang und breit erklärt aber irgendwie scheint das niemand zu lesen

Daher würde mich auch mal für Statements wie dieses hier

Zitat

---

Falls die Kupplung aus technischen Gründen nicht mit Railcom kompatibel ist, was ja durchaus sein kann, ist es halt so.

---

brennend die technische Erklärung interessieren. Die neue Kupplung ist nichts anderes als eine an einen Aux-Ausgang angeschlossene Peripherie, so wie LEDs oder Rauchgeneratoren zB auch. Es gibt keinen nachvollziehbaren Grund wieso genau diese Peripherie mit irgendwelche Protokollen nicht funktionieren sollte.

Sehr traurig finde ich die Einstellung mancher hier Märklin von jeder Verantwortung freizusprechen und die Käufer/ESU als schuldig zu erachten nur weil Railcom nicht in der Produktbeschreibung steht. Niemand verlangt dass die Lok Railcom SPRICHT - sie soll die Sendepause der Zentrale einfach IGNORIEREN so wie es jeder Uralt-Dekoder eben auch macht.

Zitat

---

Warum ändern, bis jetzt ist es ein ESU - Problem, da es nicht bekannt ist, dass dies Problem z.B. mit einer TAMS-Zentrale auftritt.

---

Sobald die Lok bei Meise mal eintrifft kann ich berichten wie es sich mit der Intellibox 2 und der Zentrale von openDCC/Fichtelbahn (Hardcore-Railcom Unterstützer) verhält.

[OttRudi]

Zitat

---

Zitat

---

Falls die Kupplung aus technischen Gründen nicht mit Railcom kompatibel ist, was ja durchaus sein kann, ist es halt so.

---

brennend die technische Erklärung interessieren. Die neue Kupplung ist nichts anderes als eine an einen Aux-Ausgang angeschlossene Peripherie, so wie LEDs oder Rauchgeneratoren zB auch. Es gibt keinen nachvollziehbaren Grund wieso genau diese Peripherie mit irgendwelche Protokollen nicht funktionieren sollte.

---

Ich habe mich auf Deine Spekulation von #26 bezogen.

Zitat

---

Das einzige was ich mir vorstellen kann: Märklin hat als "Sicherheits"-Feature für die empfindliche Kupplung eingebaut, dass der entsprechende Fu-Ausgang nur aktiviert wird, wenn ein "stabiles" Gleissignal anliegt. Wenn nun die Railcom-Pausen als ständige Strom-/Kontaktunterbrechungen interpretiert werden und das wiederum als instabiles Gleissignal.. Dann ja dann könnte das Beschriebene passieren. Evtl ist es ungesund für die Kupplungen wenn der Strom wegbricht während sie sich grade verformt.. Das wäre aber unter allen Umständen nicht sehr betriebssicher.

---

Für mich könnte dies durchaus plausibel sein.

Zitat

---

Sehr traurig finde ich die Einstellung mancher hier Märklin von jeder Verantwortung freizusprechen und die Käufer/ESU als schuldig zu erachten nur weil Railcom nicht in der Produktbeschreibung steht. Niemand verlangt dass die Lok Railcom SPRICHT - sie soll die Sendepause der Zentrale einfach IGNORIEREN so wie es jeder Uralt-Dekoder eben auch macht.

---

Das sehe ich etwas anders, es wird von einem Hersteller verlangt, dass er zu etwas kompatibel ist, was er nicht in seinem Programm hat.

Zitat

---

Warum ändern, bis jetzt ist es ein ESU - Problem, da es nicht bekannt ist, dass dies Problem z.B. mit einer TAMS-Zentrale auftritt.

Zitat

---

Sobald die Lok bei Meise mal eintrifft kann ich berichten wie es sich mit der Intellibox 2 und der Zentrale von openDCC/Fichtelbahn (Hardcore-Railcom Unterstützer) verhält.

---

---

Dann läßt sich das Ganze besser einordnen.

[bbornemann]

Hallo zusammen,
ich betreibe die Lok auch mit einer ECoS.
Alles funzt wunderbar.
Was ich aber festgestellt habe das bei der Adressprogrammierung unter DCC einige andere CV verschoben werden, da ESU und M* eine andere Codierung nutzen.
Also setzt bitte alle mal Eure Lok zurück, meldet diese dann unter DCC mit Adresse 3 an, schaltet vorher alle Protokolle außer DCC ab und schreibt eine 0 in CV 59.
danach alle anderen Protokolle wieder an und testen.

Evtl. liegt es daran das ich ein ESU RC-Sendemodul in der Lok verbaut habe ?!!

Gruß
Bernd

[suffix]

Also zur Klarstellung: Du hast Railcom an der Ecos (welche Ecos?) aktiviert und in die neue Köf ein RC-Modul eingebaut? Und sämtliche Funktionen der Köf sowie die RC-Rückmeldung funktionieren?

CVs haben eigentlich keine Codierung, nur Adressen. Und wenn CVs direkt per Adresse anspricht sollte da eigentlich keine Unterschiede zwischen Herstellern bestehen.

[bbornemann]

Zitat

---

Also zur Klarstellung: Du hast Railcom an der Ecos (welche Ecos?) aktiviert und in die neue Köf ein RC-Modul eingebaut? Und sämtliche Funktionen der Köf sowie die RC-Rückmeldung funktionieren?

CVs haben eigentlich keine Codierung, nur Adressen. Und wenn CVs direkt per Adresse anspricht sollte da eigentlich keine Unterschiede zwischen Herstellern bestehen.

---

Hallo Florian,
ich habe es nicht auf den Punkt gebracht:
Lange Adressen werden unter DCC (gibt es da ja nur) bei ESU anders programmiert als bei Märklin.
Wer also mittels ECoS eine lange Adresse in einen Märklin Decoder programmiert wiedererstehen das es nicht wie gewünscht klappt.
Da habe ich auch einige Fehlfunktionen der AUXe festgestellt.

Also testet bitte ausschließlich unter Adresse 3.

Gruß
Bernd

[Modelleisenbahnfan]

Hallo Bernd,
auch bei Märklindekodern, die DCC beherrschen, wird eine lange Adresse in CV 17 und CV 18 eingetragen und mit CV 29, Bit 5 =1 aktiviert. Da gibt es keine Unterschiede zu anderen DCC - Dekodern und die ECoS programmiert da auch nichts falsch.
Ich vermute die von Dir geschilderten Probleme eher im Zusammenhang mit dem von Dir genannten Einbau des Railcom - Sendemoduls.
Ich habe neben der hier in Rede stehenden Köf schon diverse andere Märklinmodelle mit Original - Märklindekoder in DCC mit langer Adresse gestestet bzw. in Betrieb, ohne daß dabei Änderungen an der Funktionsausgängen etc. aufgetreten wären.
Die von mir geschilderten Probleme (Telexkupplung funktioniert nicht bei aktiviertem Railcom) bestanden bereits seit den ersten Tests der Lok noch unter M4 als auch unter DCC mit Standardadresse 3, haben also mit langer Adresse unter DCC nichts zu tun. Die Lok funktioniert übrigens auch mit über die ECoS eingestellter langer DCC Adresse und abgeschaltetem Railcom einwandfrei. Mit Railcom funktionieren die Telexkupplungen nicht, weder mit M4 noch mit DCC und unabhängig ob lange oder kurze Adresse.
Ein Railcom - Sendemodul habe ich nicht verfügbar. Nach Deinen Erfahrungen scheint es ja so zu sein, daß damit Railcom und die Telexkupplung funktionieren, aber die Programmierung von langen Adressen Probleme macht.

Freundliche Grüße
Jürgen

[suffix]

Ich kann leider immer noch keine eigenen Erkenntnisse beisteuern, da mein Händler (Meise) die Lok noch immer nicht erhalten/lieferbar hat. Hat jemand hier Infos zum Fortschritt/Verteilung der Auslieferung?

[WolfiR]

Hallo,

ich habe den Versuch mit der Köf gemacht (CS2 mit Booster Tams B2/Railcom-Erweiterung).

- Auf dem Programmiergleis der CS2 funktioniert die Kupplung normal.
- Am Booster hebt sich die Kupplung träge innerhalb etwa 2-3 Sekunden. Sieht für mich aus, als sei die Spannung zu niedrig, die Kupplung ausreichend anzusteuern.

Gleiche Versuche mit dem Rangierkrokodil, das ja auch über die Kupplung verfügt: Alles normal.

Gruß
Wolfgang

[CS3plus]

Schönen guten Morgen zusammen,
ich habe die KÖF seit vorgestern in meinem Bestand.
Gut habe kein Railcom, da ich mit der CS3plus steuere, aber mir ist auf gefallen das die Kupplungen bei leichten Wagen gar nicht ankuppelt. An dem Set mit den Eaos das mit Schrott beladen (46914) muss ich auch mit erhöhter Geschwindigkeit dran fahren.

Hat jemand das Problem bei seiner KÖF auch, dass bei leichteren Wagen oder überhaupt das ankuppeln sehr schlecht ist?

Vielen Dank für eure Antworten!

[JoMa]

Hallo Zusammen,

hatten nicht die Märklin-Zentralen ein spezielles Update bekommen, kurz bevor die Kupplung erstmalig von Märklin ausgeliefert wurde? Ich meine, mich daran zu erinnern. Wenn dem so war, müßte das nicht auch bei Fremdherstellern geschehen? Könnte daraus die Inkompatibilität hervorgehen? Nur eine nicht von Wissen, sondern aus Schlußfolgerungen getriebene Idee.

LG Stefan aus BaWü

[Badaboba]

Zitat

---

mir ist auf gefallen das die Kupplungen bei leichten Wagen gar nicht ankuppelt. An dem Set mit den Eaos das mit Schrott beladen (46914) muss ich auch mit erhöhter Geschwindigkeit dran fahren.

---

Hallo Timo,
kannst Du das Problem ein wenig eingrenzen/genauer beschreiben?

[roschi]

Hallo,

auch bei mir ist es so, mit der ECoS2 funzen die Kupplungen nur, wenn railcom ausgeschaltet ist. Das ist schon verwunderlich. Die im letzten Jahr ausgesandte Köf 2 mit Sound in der Zugpackung 26605 und den alten Telexkupplungen kann die Lok auch im DCC Modus mit railcom funzen. Das ist schon hammerärgerlich, dass es bei der neuen anders ist. Das Problem hatte ich schon ja im Vergleich des älteren Turmtriebwagen zum TVT 39974 beschrieben. Und bei der älteren Insiderlok BR 39 besteht das Problem auch. Auf Anfragen reagiert Märklin da nur achselzuckend. `ist halt so´ - so so.

LG Roschi

[Erich Müller]

Zitat

---

auch bei mir ist es so, mit der ECoS2 funzen die Kupplungen nur, wenn railcom ausgeschaltet ist. Das ist schon verwunderlich. Die im letzten Jahr ausgesandte Köf 2 mit Sound in der Zugpackung 26605 und den alten Telexkupplungen kann die Lok auch im DCC Modus mit railcom funzen.

---

Hallo Roschi,

na das ist doch mal ein Indiz dafür, dass das hier Beanstandete technische Gründe hat und nicht aus einem "Wir wollen nicht kompatibel sein" - Bock entspringt.

[DeMorpheus]

Moin,

es gibt natürlich allerhand technische Ursachen, aber keinen notwendigen technischen Grund, aus dem ein Decoder bei RailCom am Gleis einige Funktionen nicht mehr richtig ausführen könnte. Da es bei anderen (älteren) Modellen mit dieser Telex-Kupplung ja auch funktioniert ist davon auszugehen, dass das hier diskutierte Phänomen bei einer Änderung von Hard- und/oder Software des Decoders sozusagen neu eingebaut wurde. Ob das jetzt Absicht ist (eher nicht) oder einfach nur ein Versehen weil man das Thema überhaupt nicht auf dem Schirm hat oder was ganz anderes bleibt erstmal Spekulation - eins aber ist ziemlich sicher: wenn Märklin möchte, kann die Inkompatibilität mit einer zukünftigen Version auch wieder ausgebaut werden.
Für die aktuellen Modelle sehe ich allerdings wenig Hoffnung auf Nachbesserung, denn die RailCom-Kompatibilität ist keine zugesicherte Eigenschaft.

[Erich Müller]

Hallo Moritz,

Zitat

---

Da es bei anderen (älteren) Modellen mit dieser Telex-Kupplung ja auch funktioniert ist davon auszugehen, dass das hier diskutierte Phänomen bei einer Änderung von Hard- und/oder Software des Decoders sozusagen neu eingebaut wurde.

---

Ähmd nüsch, wie der berühmte Sachse sagt (Sam Hawkins nämlich).
Denn die älteren Modelle haben gerade nicht diese Telex-Kupplung.

Das steht in der Produktbeschreibung bei Märklin und wird hier im Forum seit Wochen zu allen Modellen mit der neuen Kupplung diskutiert.

[DeMorpheus]

Mööp, eben doch. Das erste Modell mit der neuen Memory-Metall-Telex war das Rangierkrokodil 39567, und das funktioniert:

Zitat

---

Gleiche Versuche mit dem Rangierkrokodil, das ja auch über die Kupplung verfügt: Alles normal.

---

(gut, das ist nur ein Modell. Aber mal wieder schön, wie schnell man hier für blöd gehalten wird)

[suffix]

Zitat

---

es gibt natürlich allerhand technische Ursachen [..]

---

Na die würden mich sehr interessieren. Wieso genau alles andere funktionier, nur die Telex nicht.

Zitat

---

Für die aktuellen Modelle sehe ich allerdings wenig Hoffnung auf Nachbesserung, denn die RailCom-Kompatibilität ist keine zugesicherte Eigenschaft.

---

Kompatibilität würde heissen dass die Köf zumindest ihre Adresse auf RC-Kanal 1 meldet. Das verlangt niemand. Momentan haben wir aber den Zustand, dass sie sich von periodischen Stromunterbrechungen, die sehr kurz sind, durcheinander bringen lässt.

[DeMorpheus]

Zitat

---

Zitat

---

es gibt natürlich allerhand technische Ursachen [..]

---

Na die würden mich sehr interessieren. Wieso genau alles andere funktionier, nur die Telex nicht.

---

Eine Möglichkeit hast du weiter oben doch selber schon genannt: ein übereifriger Schutzmechanismus vor schlechtem Gleissignal. Eine andere Möglichkeit ist zu geringe Pufferkapazität auf dem Decoder. Das wären Ursachen für die Nichtfunktion - aber, und das hast du im Zitat weggekürzt, keine technisch notwendige Eigenschaft.

Zitat

---

Zitat

---

Für die aktuellen Modelle sehe ich allerdings wenig Hoffnung auf Nachbesserung, denn die RailCom-Kompatibilität ist keine zugesicherte Eigenschaft.

---

Kompatibilität würde heissen dass die Köf zumindest ihre Adresse auf RC-Kanal 1 meldet. Das verlangt niemand.

---

Das verlangt niemand, richtig. Ich auch nicht, wie man meinen Beiträgen hätte entnehmen können. Kompatibilität wurde hier im Thread dafür verwendet, dass der Decoder sich nicht durch RailCom durcheinander bringen lässt. Ein Decoder, der tatsächlich RailCom beherrscht, wäre für mich RailCom-fähig. Aber solche Wortklauberei hilft hier nicht weiter.

[JoMa]

Hallo Zusammen,

kein Mensch weiß - außer betraute Märklin-Mitarbeiter - was wirklich Phase ist, aber es ist klar, daß Märklin geschlampert hat oder - richtig fies - Railcom jetzt mal richtig zeigt, wo der Hammer hängt. Um das zu vertuschen, schickt man den verwirrten Decoder ins Rennen. Okay, das ist eine Sichtweise. Dann beschwert sich ein Kollege, daß man in diesem Forum nur an Nebel und keinem Wissen interessiert ist, wenn man die menschlichen Vorsätzlichkeiten, die Märklin vorgeworfen werden, erst einmal bis zu deren eindeutigen Bestätigung als unwahrscheinlich einstuft.

Märklin hat diese neue Kupplung erst in wenigen Modellen eingebaut. Man wird wie bei allen Neuerungen Erfahrungen damit sammeln wollen und diese nach und nach sicherlich berücksichtigen, das hat Märklin immer wieder so gemacht. Neuentwicklungen kosten Geld. Das muß so schnell es geht wieder eingespielt werden. Da bringt man zunächst das eigene System ordentlich zum Laufen und geht auf den Markt und bedient wahrscheinlich mehr als 80 % der Kunden zufriedenstellend. Damit prüft man gleich die Akzeptanz und findet versteckte Mängel. Sorry, Orchideen müssen bei jedem Produkt jeder Branche erst einmal warten. Ich gehe davon aber aus, daß Märklin langfristig auch die Kunden mit den in Bezug auf potentielle Kundschaft selteneren Konfigurationen in den Blick nimmt. Das geschieht sicher nicht mit Priorität...
Jetzt sind ja alle Railcom-Anwender vorgewarnt, entweder man kauft und akzeptiert oder man nimmt Modelle anderer Hersteller. Da man eh DCC verwendet, stehen doch eher Dreileitermodelle der traditionellen Zweileiterhersteller im Fokus. Weshalb dann diese Welle?

Wieviele Zweileitermodelle gibt es, die sich nur schlecht auf Dreileiter umbauen lassen. Da hätte ich auch gerne das ein oder andere, muß aber verzichten. Oder Zweileitermodelle mit tiefliegenden Getriebekästen, wo kein Schleifer drunter paßt, sind das alles Fehlkonstruktionen? Und immer das Totschlagargument, wieviele Modelle Märklin zusätzlich verkaufen könnte... Vielleicht kostet das ein Vielfaches als es einbringt?

Natürlich wünsche ich allen Railcom-Nutzern, daß Märklin-Modelle gut bei ihnen funktionieren, aber nicht alles, was auf Anhieb nicht geht, ist Absicht oder Unfähigkeit. Und bedenkt das u. U. nötige Update, um die neue Kupplung zu betreiben. Vielleicht fehlt so eine Maßnahme bei Fremdherstellern...

Diesen Beitrag würde ich genauso für PIKO oder Roco oder wen auch immer schreiben... Das ständige Gejammere nervt halt schon ein bißchen.

Meint Stefan aus BaWü

Korrektur in Satzbau