Eine frage ist mfx + nicht railcom aud mm format weil das ist ein ausschnitt von esu 50200 auf dcc railcom das selbe kann doch auch mfk + von Märklin
RailComPlus[REGISTERED SIGN] ist die logische Weiterentwicklung von DCC und RailCom[REGISTERED SIGN]. Es ergänzt deren Basistechnologie um ein Paket neuer Funktionen, die das Steuern von Lokomotiven, Weichen und Signalen einfacher macht. Das automatische Anmeldeverfahren RailComPlus[REGISTERED SIGN] wurde von ESU auf der Basis des von Lenz erfundenen RailCom[REGISTERED SIGN] entwickelt und ist ein weiterer Meilenstein der bidirektionalen Kommunikation. Neue RailComPlus[REGISTERED SIGN] Pakete ermöglich eine schnellere Übertragung von Befehlen an die Decoder. Dadurch verbessert sich die Bandbreite von DCC. Eine mit RailComPlus[REGISTERED SIGN] Decoder ausgestattete Lok meldet sich selbsttätig an der Zentrale an und teilt Namen und mit. Mit RailComPlus[REGISTERED SIGN] teilt der Decoder den Funktionsumfang der Lok mit. Sie erkennen um welche Funktion es sich handelt und ob es sich um eine Moment- (z.B. für eine Pfeife) oder eine Dauerfunktion (z.B. Motorgeräusch) handelt. Wenn die Lok an einer anderen Zentrale, z.B. der Vereinszentrale betrieben wird, meldet sich die Lok dort ebenfalls selbstständig an (Vereinszentrale ist RailComPlus-fähig) oder kann unter ihrer DCC-Adresse an jeder DCC-Zentrale betrieben werden
Zitat von msfrog... es sind grundsätzlich ähnliche Sachen, aber Railcom soll künftig noch ein paar Sachen mehr können als mfx. ...
Die Frage ist mir immer noch nicht ganz klar, aber mfx+(!)-Funktionen habe ich noch in keiner Railcom-Ankündigung gelesen. Auch über automatisches Anmelden von Weichen/Signalen habe ich noch nichts gehört. Ebenso beherschen auch nur Railcom plus-Zentralen die automatische Anmeldung von Loks - alleine mit Railcom klappt das nicht. Dafür ist Railcom bei der Rückmeldung/Positionsbestimmung weiter als mfx/mfx+.
Gruß Torsten
nächste MISt-OWL-Stammtische: Nächster MISt-OWL-Stammtisch siehe unter http://www.mist-owl.de
Zitat von supermoeeEs ist mir auch nicht bekannt, dass Railcom+ Führerstandsfunktionen und Vorräte an Betriebsstoffe bietet.
Moin zusammen,
bitte schmeißt hier nicht zwei Sachen zusammen. Railcom kennt bereits Betriebsstoffe usw. Railcom+ ist eine ESU spezifische Erweiterung und so wie ich es verstanden habe, umfasst es im wesentlichen die automatische Anmeldung. Die funktionale Beschreibung von Railcom ist bei Lenz nachzulesen (PDF-Dokument).
Zitat von msfrogHallo, ich schrieb ja, soll künftig mal mehr können. Was im Einzelnen von den Ideen schon umgesetzt ist müsste ich auch erst nachlesen. Solche Spielereien wie Brennstoff etc. halte ich für Kikifax, deswegen hab ich das weniger verfolgt. Was hat sowas im Decoder zu suchen? Die Steuerungssoftware kann das genausogut berechnen, ohne Bandbreite am Gleis zu verplempern. Für mich ist Railcom nur in seinen Grundfunktionen interessant. Schnelleres Auslesen (auch auf dem Hauptgleis), Rückmeldung der Adresse und vielleicht noch automatische Anmeldung etc. Wobei das auch eher eine Bequemlichkeitsfunktion ist.
Aber wie immer: Das ist meine persönliche Einstellung dazu und soll niemandem den Spaß an "seinen" Funktionen bei Railcom, mfx usw. verderben
Viele Grüße Carsten von 1001-digital.de
Hallo Carsten,
sehe ich genauso. Vor allem wegen der Bandbreite am Gleis.
MFX z.B. ist ja schon "unruhig" genug wenn jetzt noch + und demnächst ++ iund dann +++ dazukommt, fängt der Antrieb vor lauter Austastlücken noch mehr an zu ruckeln als es jetzt schon der Fall ist.
Nix für mich, wer aber nicht drauf verzichten möchte, egal ob Railcom oder MFX soll es gerne nutzen.
Da ja der Betriebsmittelverbrauch von der Last des Motors abhängt macht es wohl Sinn, das sowas im Dekoder steckt. Woher soll eine externe Software die Last des Dekoders sonst kennen?
Über Sinn oder Unsinn der Funktion ist hier überhaupt nicht die Rede, sondern über Unterschiede zwischen Railcom und mfx, bzw. deren + Varianten.
Hallo Leute! Zwei wichtige Features von Railcom sind hier noch nicht angesprochen worden, nämlich POM-Read und die Quittierung des Befehlsempfangs vom Decoder an die Zentrale ! Habe seit ca. 4 Wochen den OpenDCC - GBMBoost und empfand es beim Testen als große Erleichterung, daß ich bei der Decoderprogrammierung zum Angleichen der Fahreigenschaften von zwei Loks der BR 140 nicht mehr dauernd die Loks vom Haupt- zum Programmiergleis befördern mußte, sondern auf der Teststrecke die CVs mal der einen, mal der anderen Lok auslesen und ändern konnte. Ich habe so ein Angleichen von Fahreigenschaften bei Loks gleicher Bauart früher schon oft per Programmierung gemacht, aber das hat wesentlich länger gedauert. Zur Befehlsquittierung: Wenn man bedenkt, daß bei DCC die Befehle an die Decoder in einer Befehlsschlange ständig wiederholt werden, kann man sich ausmalen, daß bei steigender Anzahl an Loks irgendwann die Befehlsübertragung so langsam wird, daß im Automatikbetrieb ein punktgenaues Anhalten nur noch schwer möglich ist. Meldet jetzt aber der Decoder die Befehlsempfang an die Zentrale zurück, dann wird dieser Befehl nicht mehr wiederholt und die Befehlsschlange wird kürzer. Zu Bedenken ist hierbei, daß ja auch die Fahrtstufe NULL immer wiederholt wird, da die Zentrale nicht wissen kann, ob der Befehl beim Decoder angekommen ist. Hierbei sind Befehle an Weichen- oder Funktionsdecoder noch garnicht mitgerechnet. Leider ist es heute noch so, daß nicht alle Decoder, auf denen Railcom draufsteht, auch alle Möglichkeiten, die Railcom bietet ausschöpfen. Viele Grüße Heinz
MFX z.B. ist ja schon "unruhig" genug wenn jetzt noch + und demnächst ++ iund dann +++ dazukommt, fängt der Antrieb vor lauter Austastlücken noch mehr an zu ruckeln als es jetzt schon der Fall ist.
...
Gruß Markus
Hallo Markus,
die mfx Loks ruckeln doch nicht weil im Gleisprotokoll so viel "gequatscht" wird, sondern weil die Decoder des großen mfx Herstellers so beschi... regeln.
Oder eben weil da nicht ausgegorene experimentelle Motorenkonzepte drin stecken die keine Spannungsschwankungen abkönnen (aber das hört ja jetzt zum Glück auf).
Wenn ein Decoder aufgrund schlechter Kontaktsituation oder zu vieler Befehle am Gleis einfach mal keine Befehle empfängt, dann fährt die Lok einfach weiter (aber ohne Ruckeln) bis sie irgendwann einen neuen Befehl bekommt. In einer Austastlücke ist die Stromversorgung doch ganz normal (es werden ja lediglich keine Befehle von der Zentrale gesendet), wieso sollte da ein Antrieb ruckeln?
Was z. B. zu Problemen führt, sind Steuerungen per Computerprogramm, wo die Software die Lok komplett regeln will, und das möglichst noch über 128 Fahrstufen. Dann haut die Zentrale beim beschleunigen eines einzigen Zuges eine unmenge an Fahrbefehlen für diese Lok raus, und natürlich das gleiche für jeden anderen Zug auf der Anlage. Bei der Vielzahl an Befehlen kann es dann durchaus mal zu Verzögerungen kommen... (Da wäre man besser beraten, z. B. mit 28 Fahrstufen zu arbeiten, und das feine Regeln den gut eingestellten Decodern zu überlassen, die ja intern mit viel mehr Fahrstufen regeln.)
ZitatWas z. B. zu Problemen führt, sind Steuerungen per Computerprogramm, wo die Software die Lok komplett regeln will, und das möglichst noch über 128 Fahrstufen. Dann haut die Zentrale beim beschleunigen eines einzigen Zuges eine unmenge an Fahrbefehlen für diese Lok raus, und natürlich das gleiche für jeden anderen Zug auf der Anlage. Bei der Vielzahl an Befehlen kann es dann durchaus mal zu Verzögerungen kommen...
Nun, das kann man mit einem guten Algorithmus in der Zentrale vermeiden. Und wenn dann noch die Fähigkeit dazukommt, auf der ganzen Anlage die Railcom-Quittungen zu sehen, dann kann man feinfühlig mit 128 Fahrstufen fahren und hat keinerlei Performanceeinbußen. Ich habe seit dem Wochenende einen tragfähigen Vergleich vorher/nachher (wir haben unsere komplette Anlage mit 600 Meldern umgerüstet). Ja, das schaut jetzt nicht übel aus. (obwohl noch nicht alles final ausoptimiert ist).