Hallo,

in den letzten Beiträgen ging es ja nicht mehr um technische Lösungen, sondern eher um das Prinzip dahinter - die Philosophie gewissermaßen. Und da könnten mehr Leute mitreden, wenn weniger Wissen stillschweigend vorausgesetzt wäre...

beispielsweise würde ich gern verstehen:
Wenn ich eine Lok manuell fahre, dann sehe ich: der Zug kommt ins Bahnsteiggleis. Ich verringere die Geschwindigkeit und lasse den Zug am gewünschten Platz ausrollen.
In einer klassischen Automatik (die ich als analog gedacht bezeichne: es wird nutzerunabhängig und ohne "Wissen" der Zentrale oder der steuernden Einheit, außerdem ohne Ansehen der Pers... äh des Zuges eine stets gleiche Reaktion ausgelöst) wird der Zug durch eine am Gleis angebrachte Einrichtung zum Halten gebracht: stromloser Abschnitt, ABC-Baustein, Gleichstrom statt digitalem Signal, ... Das entspricht in etwa der PZB bei der großen Bahn: Lok überfährt einen "scharfen" Magneten, der bringt die Lok zum Halten.
In einer PC-gesteuerten Umgebung löst der Zug am Eingang des Bahnsteiggleises einen Melder aus. Der PC "weiß", welcher Zug es ist, "weiß" auch, ob der Zug dort halten soll oder durchfahren und an welcher Stelle er halten soll, und löst - wie ich beim manuellen Fahren - durch die Zentrale hindurch die Bremsung aus. Kann auch die Bremskurve individuell gestalten, falls gewünscht. (Die Hei-Ent-Zentralen lasse ich aus meiner Betrachtung mal heraus, weil meines Wissens keine von ihnen zugspezifische Reaktionen automatisch auslösen kann.)
In all diesen Konfigurationen gehe ich davon aus, dass der Lokführer derjenige ist, der der Zentraleinheit sagt, "gib diesen oder jenen Fahrbefehl an Lok x": der Mensch am Human-Interface (Regler), oder der Rechner hinter dem Interface der Zentrale. Der Decoder steht quasi für die Technik, die bei der großen Lok unter und hinter dem Bedienpult steht: Bremsen, Fahrstufenregler, ggfs. auch "Tempomat" (ich hab vergessen, wie das Ding auf der Lok heißt), ... aber eben nicht als Lokführer, denn der sitzt ja am Interface der Zentrale.

Wie macht das jetzt C-Digital? Wer kommuniziert da mit wem? Wer "führt" die Lok?

Mahlzeit,

Zitat von StephanLeist im Beitrag C-Digital System ???

---

Einen kleinen Ausweg gäbe es vielleicht: Jede Lok braucht 2 Kameras, dann ist es so, also ob man sich wirklich auf dem Führerstand befindet

---

Zitat von StephanLeist im Beitrag C-Digital System ???

---

Das ist bei Softwaresteuerungen für DCC oder Märklin-Systeme ganz anders. Ein automatischer digitaler Signalhalt oder Langsamfahrt, wird erst mit der Software möglich. Will man es ohne Software, dann geht das nur mit entsprechender zusätzlicher Hardware aus der Analogzeit. Also Bremsen durch stromlos schalten, oder Diodenbremsen usw.
Es braucht dann also immer entsprechende zusätzliche Bausteine und das Verständnis des Dekoders dafür.
Wenn man es von Anfang an beim Kauf der Hardware beachtet, ist es kein großes Problem, besonders anwenderfreundlich usw. ist es aber nicht. Es bedeutet auch immer einen gewissen Zusatzaufwand und man muss darauf achten, dass es im Betrieb relativ sicher ist. (Ich nutzte ABC)

---

Zitat von StephanLeist im Beitrag C-Digital System ???

---

Im Fall von C-Digital, wird doch auch keine Anlagenperipherie zwingend mit dem digitalen System geschaltet, oder?
Wie löst du das dann, wenn du eine Teil- oder Vollautomation ablaufen lassen willst?

---

Zitat von StephanLeist im Beitrag C-Digital System ???

---

z.B. die Intelligenz die ein Dekoder benötigt, einen Signalhalt oder Langsamfahrt zu erkennen und entsprechend darauf zu reagieren nichts im Dekoder zu suchen hätte. Als Vorteil wurde dann noch genannt, dass ein Dekoder so billiger werden könnte.

---

Zitat von StephanLeist im Beitrag C-Digital System ???

---

Ja, das weiß ich leider auch nicht so genau. Aber ich denke einige meinen, dass dein System, um es mit dieser Funktionalität zu haben, teurer ist, als wenn man im Fall von DCC eine einfache Blackbox-Zentrale verwendet und dann ein leistungsstarke Software dazu?

---

Zitat von StephanLeist im Beitrag C-Digital System ???

---

Im Fall von den mir bekannten Softwaresteuerungen, nimmt eine vorhandene Zentrale, egal wieviel Intelligenz diese schon besitzt, mehr oder weniger nur noch den Job wahr, die Steuerungsinformationen in Form des Gleisprotokolls auf selbigem zu erzeugen und als Interface für verschiedene Bus-Systeme zu fungieren.
Da gehört der Rechner mit Software als fester Bestandteil zur Steuerung, weil die komplette Intelligenz dann auch hier liegt. In diesem Fall kann man die Software dann nicht nur als ein weiteres komplexes Steuergerät sehen.
Dadurch sind dann manche Funktionen wie du sie dir wünschst bzw. hast, nicht möglich. Zumindest nach meinem Kenntnisstand.

---

Zitat von StephanLeist im Beitrag C-Digital System ???

---

Das wäre aber falsch, sieh meine Erklärung oben. Eine EcoS etc. wird in Kombination mit einer Softwareautomation zur "Dummheit" degradiert. Und ja, diese großen Zentralen sind praktisch kleine Rechner. Da arbeitet irgendeine embedded Maschine drin mit einem embedded Linux oder so.

---

Zitat von StephanLeist im Beitrag C-Digital System ???

---

Leider kenne ich kein System, bei dem das so möglich wäre. Da ist ein gemischter Betrieb zw. Vollautomation Teilautomtion und Manuell nicht einfach wärend des Betriebs wählbar.
Ein Grund warum das nicht geht dürfte sein, dass eine Software, in der die Automatik und der Fahrdienstleiter Steckt, nicht weiß, was gerade mit einem Handsteuergerät gemacht wird.
Das scheint bei dir also schon mal kein Problem darzustellen? Wahrscheinlich, weil bei dir eine Softwareautomation "nur" ein zusätzliches Steuergerät darstellt?

---

Zitat von StephanLeist im Beitrag C-Digital System ???

---

Mal ganz ehrlich, hast du dir bzw. hat man sich das wirklich alles schon bei der Entwicklung des C-Digital in den 90ern so gedacht und das Konzept desshalb so gewählt?

---

Zitat von StephanLeist im Beitrag C-Digital System ???

---

Klaus_K hat geschrieben: ↑
Di 24. Apr 2018, 20:21
Selbst wenn, wäre das dann ein Mobaspielen über den Bildschirm. Das stelle ich mir nicht besonders reitzvoll vor, aufjeden Fall nicht auf Dauer. Die meisten wollen doch eher ihren Zügen zusehen, sonst könnte ich doch glaich nur mit einem Simulator am PC spielen. Martin sieht das glaube ich genauso, wie ich es verstanden habe. Darum auch der wireless Handregeler, an dem man auch ohne darauf sehen zu müssen steuern kann.

Das ist auch ein Thema, was mir besonder wichtig ist. Ich möchte beim Eisenbahnspielen die meiste Zeit den Fokus auf der Anlage bzw. den Zügen haben und nicht viel auf ein Display o.ä. starren müssen.

---

Zitat von StephanLeist im Beitrag C-Digital System ???

---

Ob es ein Missstand ist, da wäre ich nicht so sicher. Man ist im Fall von DCC eben einen ganz andern Weg gegangen, naja.

---

Zitat von Klaus_K im Beitrag C-Digital System ???

---

Vielleicht findet sich die ein oder andere Lösung oder Teil der Steuerungsphilosophie von C-Digital in nicht allzu ferner Zukunft aufeinmal auch bei anderen Systemen

---

Zitat von Klaus_K im Beitrag C-Digital System ???

---

Wie bist du darauf gekommen, das so zu machen und nicht wie die anderen? Ich meine jetzt im Nachhinein betrachtet muss ich sagen: Ja logisch, ist ja naheliegend

---

Zitat von Klaus_K im Beitrag C-Digital System ???

---

Alles klar. Dann handelt es sich bei den Geschwindigkeiten zu konkreten Fahrstufen nur um ungefähre, rechnerische Schätzwerte, denn die Motoren usw. verhalten sich meines Wissens nach ja nicht absolut linear, die Gleichungen aber schon.
Nur so als Richtwerte reicht diese Bestimmung sicher aus.

---

Zitat von Klaus_K im Beitrag C-Digital System ???

---

Wenn man sich an so eine Struktur hält, dann ist auch ein "Mischbetrieb" ohne Probleme und große Hürden möglich. So hattest du das ja auch beschrieben. Dann ist nämlich der Zugriff auf die komplette Funktionalität für alle in gelichem Maß gegeben. Ob nun BSW, Handregeler, Tablett oder Software ...
Auch bei der Wahl des Steuergeräts ist man so frei, ohne auf Funktionen verzichten zu müssen

---

Zitat von Klaus_K im Beitrag C-Digital System ???

---

Wie funktioniert das jetzt noch einmal genau mit dem Signalhalt bei C-Digital? Brauche ich dafür die Rückmeldung, nein oder? Brauche ich überhaupt zwingend eine Rückmledung für das neue C-System?

---

Hallo an alle,

Ich habe gerade gesehen, dass schon wieder neue Fragen aufgetaucht sind. Ich habe im Moment leider keine Zeit mehr, diese zu beantworten. Ich denke ich werde heute Abend den Rest beantworten können, danke für euer Verständniss.

Guten Abend Erich,

[quote="Erich Müller" post_id=1825772 time=1524649531 user_id=26147]
in den letzten Beiträgen ging es ja nicht mehr um technische Lösungen, sondern eher um das Prinzip dahinter - die Philosophie gewissermaßen. Und da könnten mehr Leute mitreden, wenn weniger Wissen stillschweigend vorausgesetzt wäre...[/quote]Ich hätte da nichts gegen, solange es nicht dazu kommt, dass man falsche Dinge behauptet.



Ok, ich versuche es noch etwas genauer und gleich auf deine Aussagen hin bezogen, zu erklären. Einiges hatte ich ja schon erklärt.
[quote="Erich Müller" post_id=1825772 time=1524649531 user_id=26147]
beispielsweise würde ich gern verstehen:
Wenn ich eine Lok manuell fahre, dann sehe ich: der Zug kommt ins Bahnsteiggleis. Ich verringere die Geschwindigkeit und lasse den Zug am gewünschten Platz ausrollen.
[/quote] Ok. Ich kenne Anlagen, da sieht man nicht jedes Bahnsteiggleis und jeden Haltepunkt usw. so ein, dass man sieht, ob ein Zug hier evtl. Halten muss, weil z.B. das Signal von der Steuerung das so vorgibt oder es grundsätzlich schlecht einsehbare Stellen gibt.
Hier entsteht dann ein Informationsleck, wie ich es schon erklärt hatte... oder man arbeitet mit Kameras

Denn für mein Verständnis ist es nicht so, dass der Decoder nur dafür da ist die Maschine (Lok) zu bedienen, so wie es der "Lokführer" wünscht, wie es ja z.T. in echt der Fall wäre. Der "Lokführer" hinter seinem Steuergerät befindet sich ja auch nicht auf dem Steuerstand der Lok, wie das in echt der Fall wäre. Damit sind manche Informationen für ihn nicht oder nicht immer einsehbar (Bspw. ein rotes Signal, das ein Lokführer in echt natürlich sieht).

Auf einer Lok in echt gilt das auf andere Dinge bezogen, wo dem Lokführer gewisse Informationen fehlen oder er diese nicht schnell genug verarbeiten könnte, ebenso. Ein Beispiel wäre die LZB, wo dem Lokführer bestimmte Aufgaben abgenommen, und manches (z.B. Höchstgeschwindigkeit) eingeschränkt oder unterbunden werden kann, wenn der Lokführer mit seinen Sinnen nicht mehr in der Lage ist, die Informationen zu verarbeiten (z.B. ab einer bestimmten Geschwindigkeit, Witterungsverhältnissen). Den Eindruck, dass man immer und in jedem Fall die Lok vollständig steuert ist in echt nicht so gegeben, wie du das hier darstellst. (Bei modernen Autos und anderen Fahrzeugen ist das übrigens genauso)
Immer wenn Informationslücken aus besagten Gründen entstehen, werden diese häufig durch autom. Eingriffe geschlossen. So ähnlich ist das auch im Fall meiner Steuerung.


[quote="Erich Müller" post_id=1825772 time=1524649531 user_id=26147]
In einer klassischen Automatik (die ich als analog gedacht bezeichne: es wird nutzerunabhängig und ohne "Wissen" der Zentrale oder der steuernden Einheit, außerdem ohne Ansehen der Pers... äh des Zuges eine stets gleiche Reaktion ausgelöst) wird der Zug durch eine am Gleis angebrachte Einrichtung zum Halten gebracht: stromloser Abschnitt, ABC-Baustein, Gleichstrom statt digitalem Signal, ... Das entspricht in etwa der PZB bei der großen Bahn: Lok überfährt einen "scharfen" Magneten, der bringt die Lok zum Halten.[/quote]
Ja, das kann man bei C-Digital in etwa so haben, obgleich dafür keine Einrichtung am Gleis verantwortlich ist, sondern das Datensignal. Und die Instanz, die das Datensignal an eine bestimmte Stelle bringt, weiß das natürlich. (Es kann als nie ohne "Wissen" einer steuernden Einheit geschehen. Klar, das Datensignal wird ja auch nicht lokal erzeugt)
So wurde das auch schon von Beginn an bei Conrad Digital und dann bei C-Digital gemacht.
Die Reaktion eines Zuges erfolgte und erfolgt auch heute zunächt einmal unabhängig vom Zug, weil darüber keine Information vorliegt. Allerdings, im Fall von C-Digital, auf digitalem Weg (über das Datensignal).
Möchte man hier eine Abhängigkeit zu bestimmten Zügen mit einbauen, so muss man eine zugabhängige Information der Steuerung zur Verfügung stellen. Da gibt es nun viele verschiedene Möglichkeiten dies zu bewerkstelligen. Angefangen von Barcode-Lesern bis hin zur Decoder-Adress-Rückmeldung.
(Alle Systeme die hier keine wirkliche Information zurückliefern, klammere ich jetzt einmal bewusst aus, weil diese nur Informationen durch Wahrscheinlichkeiten aus dem Kontext selbst generieren. Ich weiß schon, dass das bei der Moba gerne gemacht wird.)


[quote="Erich Müller" post_id=1825772 time=1524649531 user_id=26147]
In einer PC-gesteuerten Umgebung löst der Zug am Eingang des Bahnsteiggleises einen Melder aus. Der PC "weiß", welcher Zug es ist, "weiß" auch, ob der Zug dort halten soll oder durchfahren und an welcher Stelle er halten soll, und löst - wie ich beim manuellen Fahren - durch die Zentrale hindurch die Bremsung aus. Kann auch die Bremskurve individuell gestalten, falls gewünscht. (Die Hei-Ent-Zentralen lasse ich aus meiner Betrachtung mal heraus, weil meines Wissens keine von ihnen zugspezifische Reaktionen automatisch auslösen kann.)
[/quote]So, kann man das auch bei C-Digital haben. Nur ist dafür, wie oben erklärt, eine Rückmeldung nötig. Es muss also immer entsprechende Hardware an der Strecke integriert werden, und - im Fall einer echten Zugverfolgung - auch jeder Zug eindeutig identifizierbar sein. Also z.B. Barcode-Leser o.ä.
Im Fall von C-Digital würde ich die autom. Decoderrückmeldung empfehlen, weil sich durch deren Verwendung gleich auch noch andere Vorteile ergeben, wie das Auslesen der Decoder auf der Anlage oder auch das Mitteilen anderer betrieblicher Informationen.
Die Art und Weise wie gebremst wird, wird im Fall von C-Digital immer vom Lokführer "Mensch-Decoder" übernommen. Dabei lässt sich die Bremskurve zuvor natürlich auch individuell festlegen.


[quote="Erich Müller" post_id=1825772 time=1524649531 user_id=26147]
In all diesen Konfigurationen gehe ich davon aus, dass der Lokführer derjenige ist, der der Zentraleinheit sagt, "gib diesen oder jenen Fahrbefehl an Lok x": der Mensch am Human-Interface (Regler), oder der Rechner hinter dem Interface der Zentrale. Der Decoder steht quasi für die Technik, die bei der großen Lok unter und hinter dem Bedienpult steht: Bremsen, Fahrstufenregler, ggfs. auch "Tempomat" (ich hab vergessen, wie das Ding auf der Lok heißt), ... aber eben nicht als Lokführer, denn der sitzt ja am Interface der Zentrale.[/quote]
Zunächst stimmt das aus meiner Sicht nur bedingt. Warum, habe ich oben versucht zu erklären.
Auf der anderen Seite ist es so, dass in jedem Fall NICHT der Decoder einfach alleine Lokführer wird und selbst entscheidet. Er reagiert nur auf digitale Befehle. Im Fall des autom. Haltens, ohne dass der Mensch tätig wird, hat die Software/Zentrale/BSW-Automatik dafür gesorgt, dass an der Stelle x zu halten ist (Datensignal Halt in Abschnitt x). (Mit Rückmeldung kann dies zugspezifisch geschehen, wie gesagt...)
Die Art und Weise des Bremsens geschieht dann softwaregesteuert, je nachdem wie man das im Decoder eingestellt hat.
Im anderen Fall kann der Fahrer am Handsteuergerät entweder:
- sich den geforderten Halt anzeigen lassen und vollständig eigenverantwortlich halten
- oder das autom. Bremsen von der Software übernehmen lassen, z.B. gerade wenn sich der Zug an einer nicht oder schlecht einsehbaren Stelle befindet.
- oder das autom. Bremsen immer von der Software übernehmen lassen (sieht meistens auch besser aus).


[quote="Erich Müller" post_id=1825772 time=1524649531 user_id=26147]
Wer kommuniziert da mit wem? Wer "führt" die Lok?
[/quote]Immer der der fragt.
Die Lok führt, je nachdem wie man das einstellt und was an der Anlage vorhanden ist (Rückmeldung ja/nein), eine Automatik eines BSW, eine Software, eine Blockstellenautomatik oder ein Mensch an einem Steuergerät vollständig oder verschiedene Kombinationen dauraus jeweils zu einem Teil.
Bspw. könnte eine BSW-Automatik den Zug führen, in dem es ihm ganz bestimmte Fahrstraßen passieren lässt und an bestimmten Stellen einen Halt vorschreibt, gleichzeitig wird der Zug, respektive die Lok des Zuges, aber von einem Menschen mit Handgerät gesteuert.
In einem anderen Bsp. könnte die Rolle der BSW-Automatik auch von einem anderen menschlichen Mitstreiter übernommen werden. Hier gehörten dann zur Führung des Zuges zwei Menschen, wobei es sein kann, dass bestimmte Sicherungen im BSW dem Bediener manche Aktionen natürlich verbietet. Da wäre dann also praktisch noch ein Mitstreiter, die automtische Sicherung.
Das könnte man jetzt immer so weiterspinnen, ich hoffe aber es ist alles klar geworden und ich konnte deine Fragen beantworten.

Grüße,
Martin

Guten Abend,

@Micha:
C-Digital ist doch nichts großartig neues, also von der Technik her, das ist da mindestens so "Oldschool" wie die bekannten DCC-Systeme. Märklin mfx ist auf jeden Fall jünger. Ich überarbeite es nur gerde und setzte alte Ideen in die Tat um, sofern mir das gelingt.
Bezüglich der Nenngröße N kann ich dir momentan keine großen Hoffnungen machen. Das liegt einfach daran, dass wir nicht industriell fertigen lassen (zu geringe Stückzahlen). Die Decoder werden von Hand bestückt und können schon aus diesem Grund eine bestimmte Mindestgröße nicht unterschreiten.
Das ist im H0 Segment schon teilweise grenzwertig.

Aber sollte es dazu kommen, dass wir einmal eine größere Menge vollständig herstellen lassen, dann werden die H0 Decoder schon etwa 1/3tel kleiner werden, wenn nicht mehr.

Viel Spaß weiterhin beim Mitlesen.


@Alexus:
Auch dir viel Spaß beim Mitlesen. Solltest du einmal eine konkrete Frage haben, kannst du sie mir gerne stellen. Du kannst frei wählen, was dir am liebsten ist PN, Mail, direkt im Forum oder Telefon.

Grüße,
Martin

Morgen,

Zitat

---

Ja, die Entwickler vom heutigen DCC oder den Märklin-Protokollen sind eben mit anderen Prioritäten an das Thema digitale Mobasteuerung herangegangen, denke ich.

---

Das höre/lese ich nicht zum ersten Mal. Sagst du das einfach nur so, oder weißt du das, oder wie?

Zitat

---

Wir bieten das momentan noch nicht "aus einem Guss" an. Ich habe noch genügend Entwicklungsarbeit mit dem Rest an der Backe.
Es ist jedoch durch die Struktur des Systems jedem freigestellt, sein eigenes BSW mit analoger oder digitaler Steuerung zu verwenden oder eine Software mit Interface für die Peripherie. Je nachdem was demjenigen sein Peripher-Steuergerät kann, kann eine vollständige Automation oder nur eine Teilautomation realisiert werden. Die nötigen Informationen können vom System abgerufen werden und entsprechend verwendet.
Die minimalste Automation die das C-Digitalsystem mit sich bringt, ist eine Blockstellenautomatik. Für eine Vollautomation wäre halt eine vollständige Rückmeldung auf der Anlage zwingend notwendig.

---

Ok. Das hört sich so an, als seien konkrete Lösungen dann immer recht "speziell", sagen wir auf einen Fall individuell zugeschnitten? Evtl. müsste ich mir das doch einmal an einem Beispiel "live" ansehen. Ist es denn geplant - ich sag mal so - "in deiner Vision", am Ende etwas aus "einem Guss" zu haben?

Zitat

---

Hier ein konkretes Bsp eines Kunden:
Dieser nutzt noch keine Rückmeldung sondern nur Schaltbaugruppen für Signale+Halteabschnitt. Seine Weichen schaltet er an seinem analogen BSW mit einfachen Tastern. Momentan nutzt er die minimalste Automationsstufe die so möglich ist.

---

Ich bin auch stolzer Besitzer eines BSWs, allerdings mit eingebauter Digitaltechnik (embedded PC), wodurch sich verschiedene Sicherheitsstufen, automatische Plausibilitätsprüfungen usw. und komplexere autom. Abläufe programmieren lassen.
Bis vor kurzem hatte ich die Steuerung alleine mit Besetztmeldern (Stromfühlern) und Punktkontakten (Reedkontakten) realisiert. Heute nutzte ich an manchen Stellen (im Bahnhof) auch RailCom, um eine Lok eindeutig autom. identifizieren zu können. Mein BSW schaltet mir ggf. auch einzelne Abschnitte vom "reinen" DCC-Signal über Diodenbaugruppen um. Damit lassen sich die Züge auch automatisch mit ABC halten. Das läuft bisweilen ganz gut, nur ist ABC nicht immer so ganz exakt, was mich persönlich jetzt nich so stört. Ich bekomme so +-4cm, das reicht mir.
Ein größeres Problem hatte ich mit der Zuverlässigkeit der ABC erkennung der Dekoder, aber auch das lies sich in den Griff bekommen.
Nur einmal so hypothetisch: Wenn ich jetzt auf C-Digital umsteigen würde (ich denke es lohnt sich für mich nicht), wie sähe die Umsetztung dann mit einbeziehen meines BSWs aus?

Zitat

---

Zitat von StephanLeist im Beitrag C-Digital System ???

---

z.B. die Intelligenz die ein Dekoder benötigt, einen Signalhalt oder Langsamfahrt zu erkennen und entsprechend darauf zu reagieren nichts im Dekoder zu suchen hätte. Als Vorteil wurde dann noch genannt, dass ein Dekoder so billiger werden könnte.

---

Für meinen Decoder kann ich dir sagen, dass dieser dadurch keinen Cent günstiger wäre.

---

Ok. Man könnte sowas natürlich fordern, wenn man ausschließlich mit einer Software fährt. Die Frage ist halt dann auch, wo man die Grenze zieht. : Was soll dann alles aus dem Dekoder raus und in die Software eingelagert werden... (Das beträfe doch sicherlich nicht nur die Halt-auswertung)
Da ein automtischer Signalhalt nicht per se bei DCC im Konzept enthalten ist, könnte die Forderung durchaus berechtigt sein, so eine Funktion dann von einer zusätzlichen Steuerung übernehmen zu lassen.
Ich wäre dann allerdings wohl nicht bei einem DCC-System geblieben, weil sich meine Steuerung mit meinem "intelligenten" BSW dann garnicht hätte realisieren lassen (keine ABC-Erkennung).
(Da hätte ich zwingend immer eine Softwareanbindung benötigt.)

Mir drängt sich langsam der Verdacht auf, dass ein automatisches Halten eher mehr zu einer Digitalsteuerung gehört als es das nicht tut.

Zitat

---

Gut in dem Fall wie du es beschreibst, ist die Software dann der Zentrale Bestandteil der Steuerung. Das ist dann eben eine andere Möglichkeit, ein anderes Konzept. Wer das so möchte, ist da ja gut bedient.
Ist dieses Konzept bei den großen immer so, oder gibts auch etwas anderes?

---

Naja, also man muss nicht immer den vollen Umfang eine Software nutzen. Man kann sich mit ihr auch nur ein digitales "BSW" in die Software bauen, und diese dann nur zum Fahrstraßen Schalten nutzen. (Es gibt auch noch andere Beispiele.)
Da würde man dann trotzdem weiterhin mit seinem normalen Steuergerät fahren und die Software macht dann im Grunde nur den Fahrdienstleiter (automatisch oder manuell durch eine Person vor dem Bildschirm).
Der, der die Lok fährt, muss dann allerdings die Signalvorgaben der Software beachten. Wenn man keine Einrichtung am Gleis hat, die ein Fehlverhalten des Fahrers unterbindet, gibt es ggf. einen Crash.


Einige mit denen ich mich über Softwaresteuerungen unterhalten hatte haben immer dazu geraten, erst eine Vollautomation aufzubauen. Also sowohl die Hardwareseite in der Anlage (überall Rückmelder, punktuell und als Stromfühler z.B.), als auch die Softwareseite im Rechner. Wenn das zuverlässig läuft, ist ein Schritt von der Vollautomationsstufe runter leicht möglich und es bleiben trotzdem die ganzen Sicherheiten.

Summa summarum ist es durchaus möglich eine Software nur begrenzt zu nutzen, jedoch empfiehlt es sich, gleich die "volle" Ausbaustufe in die Anlage einzubauen, wodurch eine mehr oder minder intelligente Zentrale dann eben degradiert wird.

Zitat

---

Ok. Das habe ich jetzt auch verstanden. Wie gesagt, das ist dann eben ein anderes Konzept. Die Frage ist dann nur, warum sollte ich mir dann überhaupt so eine Zentrale kaufen, wenn es auch mit einer viel, viel günstigeren geht (Protokollumsetzer) und man eben nur ein kleines embedded-Teil für 30, 40€ braucht, auf dem die Software dann alles regelt. ?
Aber gut, vielleicht will der ein oder andere mal so, mal so steuern. Dann kauft er sich natürlich so eine multifunktionale Zentrale.

---

Ja oder man hat eben erst ohne Software gesteuert (z.B. nur mit der Ecos) und ist erst später auf Software umgestiegen, dann schmeißt man die Zentrale natürlich nicht weg.

Zitat

---

Nicht alles, natürlich. Aber die Struktur des Systems, und die Technik zur Informationsübertragung hat man ganz bewusst so gewählt, damit sich bestimmte Schwierigkeiten gar nicht erst ergeben können. Und vieles was ich heute mache ist auch nur aus diesem Grund, überhaupt so problemlos möglich.
- Fast beliebige Erweiterung des Protokolls ohne Kompatibilitätsprobleme.
- Integration einer Rückmledung ohne Kompatibilitätsprobleme.
- Einfacher wechsel zw. manueller und autom. Steuerung im Betrieb.
- Wendezugautomatik ohne Zusatzhardware
- Problemlose verwendung verschiedener Streckensignale (Halt, Langsamfahrt,...)
usw.

---

Alles klar. Dann kann ich jetzt Klaus K.'s Aussage "... mit Weitsicht entwickelt" auch besser verstehen.

Zitat

---

Ja, da hast du mich richtig verstanden, Klaus. Mir ist das auch sehr wichtig, dass man sich beim "Spielen" intensiv mit seinen Zügen auseinandersetzen kann und nicht die meiste Zeit auf einen Bildschirm kuckt.
Kabelloses Steuergerät, dass sich bei den Standardfunktionen praktisch blind bedienen lässt, damit man sich frei an seiner Anlage bewegen kann.

---

Das geht mir genauso. Ich war kürzlich bei einem Mobaverein und v.a. die jüngere Fraktion der Mitglieder, haben mir ziemlich das gleiche zu verstehen gegeben. Man wolle lieber "aktiv" mit einem Zug fahren oder ein Stellwerk bedienen und dabei nicht vor einem Bildschirm sitzen (dafür gäbe es Modellbahnsimulatoren)...

Zitat

---

Ich habe bei der Entwicklung meiner Decoder nie geschaut was andere irgendwie machen.

---

Und das ist im Fall deiner Dekoder bestimmt auch gut so. Evtl. hättest du sonst eine ganz andere Motorregelung gebaut...?


Freundliche Grüße,
Stephan L.

Hallo Martin,

Zitat von Martin_G im Beitrag C-Digital System ???

---

Man ihr schreibt so schnell, da komme ich ja kaum hinterher.

Eure neuen Fragen werde ich heut in der Mittagspause vorraussichtlich beantworten können.

---

Zitat von Martin_G im Beitrag C-Digital System ???

---

Zitat von Klaus_K im Beitrag C-Digital System ???

---

Nachden Zugriffszahlen zu urteilen, scheint es doch einige zu interessieren, was hier über das C-Digitalsystem berichtet wird, obwohl im Großen und Ganzen nur 3 bis 4 Leute diskutieren.

---

Das freut mich, wenn man so zahlreich an meinem System interessiert ist. Leider kann nur kaum ein anderer noch mitdiskutieren. Der einzige, der das neue C-Digital hier kannte war ja Marius und der ist leider wieder gegangen.

---

Hallo Martin,

Zitat

---

ich hoffe aber es ist alles klar geworden und ich konnte deine Fragen beantworten.

---

Nein, leider nicht. Ich lese da, zusammengefasst, "das geht bei C-Digital auch so, wenn man will, aber auch anders" - aber WIE anders, schreibst du nicht, jedenfalls nicht so, dass ich es verstehe.

Weißt du, ich bin vermutlich einige Jahre älter als du, ich habe in der Schule nicht programmieren gelernt, aber ich weiß, was ein Algorithmus ist, und ich kann Flussdiagramme lesen - und im Prinzip hätte ich mir so etwas gewünscht.
So wie man - aber du brauchst das nun nicht erneut zu kommentieren, das ist nur ein Beispiel! - die Abfolge einer (manuell gefahrenen) Zugbewegung in Rocrail etwa so beschreiben kann:

• bekannt ist, Zug 1 in Block A.
• Programm stellt Fahrstraße nach Block B ein. Darin enthalten, Hp1: Programm gibt Schaltaufträge an Zentrale => Zentrale gibt Schaltaufträge an Decoder.
• Modellbahner fährt (am Handgerät, an der Zentrale, am Tablet...) den Zug an: Modellbahner betätigt Regler => Zentrale gibt entsprechenden Fahrauftrag an Decoder.
• Zug löst Melder ENTER von Block B aus. => Melder meldet "belegt" an Zentrale. => Zentrale meldet "belegt" an Rocrail.
• Hauptsignal fällt auf Hp0 zurück: Programm gibt Schaltauftrag an Zentrale => Zentrale gibt Schaltauftrag an Decoder.
• Modellbahner regelt Geschwindigkeit zurück (bremst): Modellbahner betätigt Regler => Zentrale gibt entsprechenden Fahrauftrag an Decoder.
• Zug löst Melder IN von Block B aus. => Melder meldet "belegt" an Zentrale. => Zentrale meldet "belegt" an Rocrail.
• Fahrstraße wird aufgelöst, Block A freigemeldet.
• Modellbahner dreht Regler auf 0 und hält Zug an: Modellbahner betätigt Regler => Zentrale gibt entsprechenden Fahrauftrag an Decoder.

Hallo Martin,

Danke für die schnelle Antwort.

Zitat

---

Ja, die Entwickler vom heutigen DCC oder den Märklin-Protokollen sind eben mit anderen Prioritäten an das Thema digitale Mobasteuerung herangegangen, denke ich.

---

Diesbezüglich bin ich mir sogar sicher.

Zu deinen letzt Beschreibungen möchte ich sagen:
Ich für meinen Teil halte es für ein sehr wichtiges Argument, dass ein System so beständig ist, dass man nicht gezwungen ist alle 10 Jahre die komplette Hardware zu tauschen, wenn man auch neue Dinge integrieren will. Auch ein analoges BSW, was man sich wahrscheinlich sehr zeitintesiv selbst gebaut hat, wirft man nicht so gerne einfach weg.
Ich denke es ist wichtig, wenn sich alte, eben bestehende Technik in neuere relativ unproblematisch integrieren lässt. Ich hoffe z.B., dass es nicht in naher Zukunft wieder dazu kommt, dass es eine Änderung des DCC-Protokolls gibt, welches dann wieder gesondert angesprochen werden muss. Auch bei der Unterstützung von ABC musste ich vor paar Jahren schon mehrere Decoder tauschen. Sowas nervt einfach nur und man verliert ein bischen die Lust.
Ich bin da sicher nicht der einzige der so darüber denkt, wie man hier lesen kann.
Man kann sich ein wenig selbst vor soetwas "retten", indem man auf eine vollwertige Softwaresteuerung setzt. Diese Funktioniert unabhängig vom Protokoll und alte sowie neue Hardware lässt sich leichter kombinieren. Im Fall eines autom. Haltens auf jeden Fall. Bei einer Protokolländerung, Neuerung oder Erweiterung muss natürlich die Zentrale/Protokollumsetzer das "neu" Fromat dann können, und darf gleichzeitig beim "alten" keine Probleme hervorrufen. Da muss man halt die Zentrale ggf. trotzdem tauschen, da hilft dann auch die beste Software nichts.
Ich befürchte ja, das wir bei den Protokollen irgendwann genauso einen Wildwuchs wie bei den Digitalschnittstellen bekommen. Da nimmt die Vielfalt ja auch zu anstatt ab.
Es gibt mittlerweile 3 oder 4 Ausbaustufen von RailCom? DCC alt, DCC neu, SX1, SX2, MM1/2, mfx, mfx+ ?
Bei diesem Wust an Protkollen, wo es für fast jedes (SX2, DCC neu, mfx) untereinander auch Vor- und Nachteile gibt, muss man sich das "richtige" für einen aussuchen und hoffen, dass es so möglichst lange gültig bleibt. Die unterschiedlichen Rückmeldesysteme und Ausbaustufen kommen dann noch oben drauf.

Ich halte es für etwas realitätsfern zu sagen, die Decoder seien mit bestimmten Features zu sehr belastet und es sollte nicht so viel Intelligez im Decoder sein. Was einen Decoder wirklich "belastet" und Speicher usw. kostet ist z.B. eine Multiprotokollfähigkeit von X-Protokollen und evtl. X-Rückmeldesystemen.
Hier ist was zu holen wenn man sparen will aber doch nicht bei so einer "lächerlichen" Funktion wie z.B. eine Asymmetrie am DCC-Pegel festzustellen oder noch lächerlicher, bei deinem C-Digital, wo die Halte-Information mit 2Bit sowieso im Protokoll enthalten ist. Auch eine einstellbare Bremskurve ist winzing im Vergleich zur Multiprotokollfähigkeit. Wobei man in diesem Fall auch nicht vergessen darf, dass ein Auslagern einen Datenbus zur Software (aus meiner Sicht) völlig unnötig belastet.
Stell dir einmal vor, die Software würde mit der gleichen Auflösung die Fahrstufen beim Bremsen abfahren, wie das dein Decoder bspw. macht. Da müssten im schlimmsten Fall 4096 Werte über den Bus zum Decoder gejagt werden bis die Lok steht.

Zitat

---

Ist dieses Konzept bei den großen immer so, oder gibts auch etwas anderes?

---

Ich sehe es so, dass eine Softwaresteuerung eigentlich nur in der "vollen Ausbaustufe" richtig Sinn macht. Erst dann wird man von anderen Dingen unabhängiger und ist nicht so betroffen, sollte es irgendwo Neuerungen geben. Ein Rückmeldesystem über S88 hält sich schon seit über 30 Jahren und wird das voraussichtlich noch länger tun. Wer weiß ob RailCom(+) oder mfx(+) da irgendwann einmal mithalten kann?
Ich selbst nutzte Software momentan nur am Rande und taste mich da langsam heran (wie schon gesagt mit embedded Komponenten). Einen autom Halt gibt es bei mir über ABC zur sicherheit mit 2 Abschnitten. Hier bin ich natürlich auf bestimmte Decoder angewiesen und "anfällig" bei Neuerungen.

Würde ich als Mobahner heute erst beginnen und unbedingt mit DCC oder mfx fahren wollen, würde ich mir selbst gleich zur Softwaresteuerung raten. Alles andere ist mehr oder weniger gemurxe bis man früher oder später sowieso bei der Software landet, eben auch aus dem Grund weil man sich Inkompatibilitätsproblemen und Problemen durch Neuerungen zum Teil entziehen kann.

Zitat

---

Aber die Struktur des Systems, und die Technik zur Informationsübertragung hat man ganz bewusst so gewählt, damit sich bestimmte Schwierigkeiten gar nicht erst ergeben können. Und vieles was ich heute mache ist auch nur aus diesem Grund, überhaupt so problemlos möglich.
- Fast beliebige Erweiterung des Protokolls ohne Kompatibilitätsprobleme.
- Integration einer Rückmledung ohne Kompatibilitätsprobleme.
- Einfacher wechsel zw. manueller und autom. Steuerung im Betrieb.
- Wendezugautomatik ohne Zusatzhardware
- Problemlose verwendung verschiedener Streckensignale (Halt, Langsamfahrt,...)
usw.

---

Und genau das finde ich an deinem System sehr ansprechend und durchdacht. Durch diese Struktur wird man nicht "gezwungen" auf vollkommene Softwaresteuerungen zu setzten.

Zitat

---

Ja, da hast du mich richtig verstanden, Klaus. Mir ist das auch sehr wichtig, dass man sich beim "Spielen" intensiv mit seinen Zügen auseinandersetzen kann und nicht die meiste Zeit auf einen Bildschirm kuckt.
Kabelloses Steuergerät, dass sich bei den Standardfunktionen praktisch blind bedienen lässt, damit man sich frei an seiner Anlage bewegen kann.

---

Sowas brauche ich auch noch und es muss sich halt in meine zukünftige Steuerung integrieren lassen.

Zitat

---

Zitat von StephanLeist im Beitrag C-Digital System ???

---

Ob es ein Missstand ist, da wäre ich nicht so sicher. Man ist im Fall von DCC eben einen ganz andern Weg gegangen, naja.

---

Das würde ich auch so sehen. Nur lässt sich damit eben auch keine grundsätzliche Forderung für digitale Mobasteuerungen ableiten, da hat Klaus absolut recht, finde ich.

---

Das mit dem "Missstand" kommt doch immer auf den Blickwinkel an. Aus sicht eines Softwarefahrers ist es natürlich kein Missstand, weil dieser eine derartige Funktion auch nicht vermisst.

Zitat

---

Zitat von Klaus_K im Beitrag C-Digital System ???

---

Wie bist du darauf gekommen, das so zu machen und nicht wie die anderen? Ich meine jetzt im Nachhinein betrachtet muss ich sagen: Ja logisch, ist ja naheliegend

---

Ich habe bei der Entwicklung meiner Decoder nie geschaut was andere irgendwie machen. Erst durch Hermann (CDC-User) habe ich mich auch einmal damit beschäftigt, wie z.B. die Regelung bei anderen Decodern umgesetzt wird.
Ja, und weil mir nicht bewusst war, wie das andere machen, habe ich es mir eben so überlegt, weil es mir als das naheliegenste und logisch erschien. Freut mich, dass du das gut findest.

---

Gute Einstellung. Du kannst das für dich so machen, die großen Hersteller aber nicht, weil sie sich je gewissermaßen gegenseitig bedingen.



Danke für die Erklärung über das Halten bei C-Digital, jetzt habe ich es noch etwas besser verstanden. Dieses Konzept und die Funktionalität gefällt mir.

Zitat

---

Für das neue C-System ist die Rückmeldung nicht zwingend, aber empfehlenswert. Ich würde beides verwenden, sowohl eine allgemeine Halteinformation, als auch eine adressbezogene mittels Rückmeldung. Was dann wie genutzt wird, bleibt dann Einstellungssache der Decoder und alte Decoder (auch die ganz alten aus den 90ern) können weiter ohne Fehler im Betrieb mitlaufen und autom. halten.
Zumal kann man durch die Rückmeldung die Decoderprogrammierung auf der Anlage auslesen, was ich auch für empfehlenswert halte. Man kann sich dafür natürlich auch einen bestimmten Abschnitt einrichten, - wie man will eben.

---

Das geht bei dir halt alles, weil sich das C-Digitalprotokoll abschnittsweise in einzelnen Bits unterscheiden kann, ohne dass es beim Überfahren zu Kurzschlüssen kommt.


Liebe Grüße,
Klaus K.

Hallo Erich,

[quote="Erich Müller" post_id=1826082 time=1524734907 user_id=26147]

Zitat

---

ich hoffe aber es ist alles klar geworden und ich konnte deine Fragen beantworten.

---

Nein, leider nicht. Ich lese da, zusammengefasst, "das geht bei C-Digital auch so, wenn man will, aber auch anders" - aber WIE anders, schreibst du nicht, jedenfalls nicht so, dass ich es verstehe.
[/quote]Ok. schade. Ich dachte es sei klar, was ich geschrieben habe.
Du hast mir aber auch keinen konkreten Weg aufgezeigt, den du erklärt haben willst, sonder du wolltest es doch allgemein wissen. So war meine Antwort dann eben auch allgemein.

[quote="Erich Müller" post_id=1826082 time=1524734907 user_id=26147]
Weißt du, ich bin vermutlich einige Jahre älter als du, ich habe in der Schule nicht programmieren gelernt, aber ich weiß, was ein Algorithmus ist, und ich kann Flussdiagramme lesen - und im Prinzip hätte ich mir so etwas gewünscht.
[/quote] Wenn du älter als 27 bist, dann auf jeden Fall. Ich habe das Programmieren übrigens auch nicht in der Schule gelernt, da hängt unser Bildungssystem massiv hinterher. Ich habe mir vieles wärend der Schulzeit selbst beigebracht und im Studium kam das dann sowieso.

Du suchst also in etwa sowas?

Zitat von Martin_G im Beitrag C-Digital System ???

---

bel. Interakteur -> bel. Human Interface Device / User Interface -> Befehlsauswertung&Bewertung -> Befehlsvergabe an diverse Hardwarekomponenten -> Befehlsauswertung&Bewertung -> Befehlsvergabe an diverse -> ... -> Befehlsumsetzung / Ausführung -> Feedback -> Feedback Auswertung&Bewertung -> ... -> Aufbereitung für bel. HID/UI -> bel. Interakteur -> ... (und alles beginnt von vorne)

---

• Anlage die komplett mit Rückmeldung ausgestattet ist
• Anlage in der sämtliche Peripherie (minimum Weichen) digital in Software integriert ist
• Software, in der die komplette Anlage schematisch angelegt ist
• Software, in der die Fahrzeuge angelegt sind
• Software in der du einen Ausgangspunkt festgelegt hast

Guten Abend Stephan,

Zitat

---

Zitat

---

Ja, die Entwickler vom heutigen DCC oder den Märklin-Protokollen sind eben mit anderen Prioritäten an das Thema digitale Mobasteuerung herangegangen, denke ich.

---

Das höre/lese ich nicht zum ersten Mal. Sagst du das einfach nur so, oder weißt du das, oder wie?

---

Nein, ich weiß da nichts genaues. Ich schließe hier nur aus dem Kontext. Wären die Prioritäten anders gelegen, würden die Protokolle doch anders aussehen, - logisch.

Zitat

---

Ok. Das hört sich so an, als seien konkrete Lösungen dann immer recht "speziell", sagen wir auf einen Fall individuell zugeschnitten? Evtl. müsste ich mir das doch einmal an einem Beispiel "live" ansehen. Ist es denn geplant - ich sag mal so - "in deiner Vision", am Ende etwas aus "einem Guss" zu haben?

---

Das kann ich zum jetzigen Zeitpunkt weder bestätigen noch dementieren. Dazu muss ich erst sehen, wie sich alles entwickelt.
Ja, die meisten Lösungen sind recht individuell, weil man fast an jeder Anlage eine andere Ausgangssituation vorfindet.

Zitat

---

Nur einmal so hypothetisch: Wenn ich jetzt auf C-Digital umsteigen würde (ich denke es lohnt sich für mich nicht), wie sähe die Umsetztung dann mit einbeziehen meines BSWs aus?

---

Wenn du schon so eine komplexe Lösung dein Eigen nennst, denke ich auch, dass sich ein Umstieg kaum lohnt.

Willst du dein BSW mit einbeziehen, müsstest du die Information vom Interface der Zentral von deinem BSW abrufen. Wie du diese dann verwendest ist dir überlassen. In deinem Fall ist durch die ABC-Bremsabschnitte und durch die Stromfühler die Strecke schon in Abschnitte unterteilt. Damit bietet es sich an, diese Abschnitte mit Rückmeldemodulen auszustatten. Dann kannst du in deinem BSW den Zustand jedes Abschnitts anzeigen wie bisher und wenn das technisch vorgesehen ist auch den Lok/Zugnahmen.
Die restliche Steuerung der Weichen und Signale kannst du praktisch unverändert weiter verwenden. Die ABC-Module an der Strecke brauchst du dann natürlich auch nicht mehr. Die Umschaltung auf Halt aus deinem BSW müsste dann ins Interface gegeben werden, wenn du autom. zugspezifisch halten willst. Brauchst du das nicht, kannst du auch direkt in den jeweiligen Abschnitten, die Streckeninformation ungeachtet einer Lokadresse umschalten. Dann geht der Umschaltebefehl übers Interface und den C-Digitalbus direkt zu der jeweiligen Rückmelderadresse.
So in etwa könnte das aussehen. Für mehr Details, bitte per PN.

Zitat

---

Ok. Man könnte sowas natürlich fordern, wenn man ausschließlich mit einer Software fährt. Die Frage ist halt dann auch, wo man die Grenze zieht. : Was soll dann alles aus dem Dekoder raus und in die Software eingelagert werden... (Das beträfe doch sicherlich nicht nur die Halt-auswertung)

---

Darüber möchte ich mir kein Urteil anmaßen.

Zitat

---

Summa summarum ist es durchaus möglich eine Software nur begrenzt zu nutzen, jedoch empfiehlt es sich, gleich die "volle" Ausbaustufe in die Anlage einzubauen, wodurch eine mehr oder minder intelligente Zentrale dann eben degradiert wird.

---

Wenn einer neu mit C-Digital beginnt, würde ich auch immer empfehlen, gleich die lückenlose Rückmeldung mit einzubauen. Es ließe sich aber auch nachträglich einbauen.

Zitat

---

Das geht mir genauso. Ich war kürzlich bei einem Mobaverein und v.a. die jüngere Fraktion der Mitglieder, haben mir ziemlich das gleiche zu verstehen gegeben. Man wolle lieber "aktiv" mit einem Zug fahren oder ein Stellwerk bedienen und dabei nicht vor einem Bildschirm sitzen (dafür gäbe es Modellbahnsimulatoren)...

---

Ich kann das durchaus nachempfinden. Es freut mich, dass auch gerade die jüngeren so denken. Denn uns jüngeren (wenn ich mich dazu noch zählen darf ) wird ja häufig nachgesagt, dass wir gerne alles am Rechner, Spielekonsole oder Smartphone usw. machen würden und nicht mehr eigenhändig kreativ zu Werke gehen wollen.

Man rekrutiert doch keinen Nachwuchs und weckt Interesse an einer Sache, indem man deren "Seele" verkauft. Wenn ich aus dem Modellbahnspielen mehr oder weniger ein Computerspiel mache, ist das sicher nicht der richtige Weg. Rechner mit Software ja, dann aber nur im Hintergrund als Teil des Ganzen.
Wenn ich mich zum spielen länger mit Software am Rechner o.ä. beschäftigen muss, dann kann ich gleich ein PC-Spiel oder so spielen.
Sonst landen wir bei der Moba irgendwann dort, wo manche Konsolenspiele heute schon sind. Dann geht man nicht mehr zum Bowlen oder Tennisspielen, man "spielt" es an der heimischen Spielekonsole virtuell vor dem Bildschrim.
Da glaube ich kaum, dass es einmal einen geben wird, der sagt: Ich habe schon ein paar mal zuhause an der Konsole gebowlt und weil es mir so spaß gemacht hat, ist mein Hobby jetzt Bowlen.
So kann man doch keine Begeisterung für etwas wecken, was in natura wieder ganz anders aussieht.

Soetwas wünsche ich mir für die Moba nicht. Wenn ich einmal am PC oder so etwas spielen will, dann mache ich das. Wenn ich aber mit der Modellbahn spielen will, dann will ich nicht am PC "spielen".

Das wäre meine Meinung dazu.
Und nein, Ich bin sicher kein Technikmuffel o.ä..

Zitat

---

Und das ist im Fall deiner Dekoder bestimmt auch gut so. Evtl. hättest du sonst eine ganz andere Motorregelung gebaut...?

---

Das glaube ich weniger. Dabei gehe ich doch danach vor, was ich gelernt habe.

Gruß,
Martin

N' Abend Erich,

[quote="Erich Müller" post_id=1826082 time=1524734907 user_id=26147]
Dieses Programm zumindest kann übrigens ohne Weiteres erkennen, wenn an der Zentrale Schaltungen vorgenommen werden.
Und: es kann mehrere "Zentralen" verwalten, eine für die Rückmeldungen, eine für die Fahrbefehle, eine für die Schaltbefehle.
[/quote]Ah, das wusste ich garnicht. Dann sollte mit Rocrail das möglich sein, was ich mir wünsche. Man müsste hier also im Betrieb einen beliebigen Zug auch mit einem an der Zentrale angeschlossenen Handsteuergerät fahren können, wärend andere Züge von Rocrail gesteuert werden. Auf Wunsch kann ich dann den Zug den ich steuern möchte auch im betrieb wechseln und praktisch an Rocrail zurückgeben, - und mir dann einen anderen auswählen. : Wenn das bei Rocrail geht, wäre das für mich die 1.Wahl.


@Martin:
So wie ich dich verstanden habe, ist ja genau das in deinem System möglich, oder? Genau so würde ich mir das bei einer Softwaresteuerung vorstellen. hier zu lesen

Ich kann übrigens auch meine Ecos als "BSW" benutzen, allerdings ist das bei weitem nicht so toll wie mit meinem.
Da hat man einfach eine andere Übersicht und Haptik.

Zitat

---

Ich kann das durchaus nachempfinden. Es freut mich, dass auch gerade die jüngeren so denken. Denn uns jüngeren (wenn ich mich dazu noch zählen darf ) wird ja häufig nachgesagt, dass wir gerne alles am Rechner, Spielekonsole oder Smartphone usw. machen würden und nicht mehr eigenhändig kreativ zu Werke gehen wollen.

Man rekrutiert doch keinen Nachwuchs und weckt Interesse an einer Sache, indem man deren "Seele" verkauft. Wenn ich aus dem Modellbahnspielen mehr oder weniger ein Computerspiel mache, ist das sicher nicht der richtige Weg. Rechner mit Software ja, dann aber nur im Hintergrund als Teil des Ganzen.

---

Das deckt sich ja total mit der Meinung der meisten jungen Vereinsmitglieder. Übrigens gibt es schon ein PC spiel, "Modellbahnsimulator", davon haben mir zwei der Jungen erzählt - wusste ich auch nicht .


Gute Nacht,
Stephan L.

Guten Abend Stephan und Erich,

Ich glaube, was ihr euch vielleicht noch nicht richtig klar gemacht habt, im Bezug auf das C-Digitalsystem, ist, dass selbst bei einer Automation eine Lok nicht fest mit Fahr- und anderen Befehlen "versorgt" werden muss.

Wenn man sich das klar macht, kann man das Ganze leichter verstehen, denke ich.

Ich will einmal versuchen das direkt gegenüberzustellen mit einer DCC-Softwareautomatik mit Railcom.

DCC in blau und C-Digital in grün:

Situation: Eine LokX soll von (A) über (B) nach (C) fahren. Sie steht im Halt bei (A), soll in (A) mit FS16 fahren, soll in (B) mit FS12 fahren, F2 aktivieren und in (C) halten.
LokX FS auf "16"

• Software hat irgendwann Meldung über LokX in besetztem Abschnitt (A) bekommen & Lok nach einer eingestellten Kurve auf FS0 gebracht
• Software hat irgendwann Meldung über LokX in besetztem Abschnitt (A) bekommen & LokX FS auf "16" vorwärts + "Halt" gesendet oder Abschnitt (A) "Halt"
  .
  .
  .
• Software schickt Befehle zum Stellen der Fahrstraße ans Interface und sperrt diese
• Software schickt Befehle welche Fahrstraße zu stellen ist ans Interface und sperrt diese
  .
• Schaltbefehle werden an Schaltbaugruppe weitergeleitet und ein Feedback geht zurück
• Schaltbefehle müssen von einem Automaten erfüllt werden und ein Feedback geht zurück
  .
• Bei pos. Feedback gibt die Software ans Interface den Befehl, LokX FS auf "1" vorwärts
• Bei pos. Feedback gibt die Software ans Interface den Befehl, LokX "Halt weg" oder Abschnitt (A) "Halt weg" und ggf. Änderung der Beschleunigung
  .
• Zentrale schickt LokX FS1 vorwärts
• Zentrale schickt LokX "Halt weg" oder Abschnitt (A) "Halt weg" und ggf. Änderung der Beschleunigung
  .
• Software schickt ans Interface LokX FS auf "2" (abhängig von eingestellter Kurve)
• Zentrale schickt LokX FS2
• ------------
  .
• Software schickt ans Interface LokX FS auf "3" (abhängig von eingestellter Kurve)
• Zentrale schickt LokX FS3
• ------------
  .
  .
  .
• Software schickt ans Interface LokX FS auf "16" (abhängig von eingestellter Kurve)
• Zentrale schickt LokX FS16
• ------------
  .
• Abschnitt (B) meldet Besetzt mit LokX
• Abschnitt (B) meldet Besetzt mit LokX
  .
• Software schickt ans Interface LokX FS auf "15" und F2 "aktiv"
• Software schickt ans Interface LokX FS auf "12" und F2 "aktiv"
  .
• Zentrale schickt LokX FS15 und F2
• Zentrale schickt LokX FS12 und F2
  .
• Software schickt ans Interface LokX FS auf "14" und F2 "aktiv"
• Zentrale schickt LokX FS14 und F2
• ------------
  .
  .
  .
• Software schickt ans Interface LokX FS auf "12" und F2 "aktiv"
• Zentrale schickt LokX FS12 und F2
• ------------
  .
• Abschnitt (C) meldet Besetzt mit LokX
• Abschnitt (C) meldet Besetzt mit LokX
  .
• Software schickt ans Interface, LokX FS auf "11"
• Software schickt ans Interface, LokX "Halt" oder Abschnitt (C) "Halt"
  .
• Zentrale schickt LokX FS11
• Zentrale schickt LokX "Halt" oder Abschnitt (C) "Halt"
  .
• Software schickt ans Interface, LokX FS auf "10" und entsperrt Fahrstraße
• Zentrale schickt LokX FS10
• Software entsperrt Fahrstraße
  .
  .
  .
• Software schickt ans Interface, LokX FS auf "0"
• Zentrale schickt LokX FS0
• --------------

Hallo Klaus,

Zitat

---

(1)
Bei C-Digital ist es so also möglich, dass man mit einem mit der Zentrale verbundenen Handregler die LokX adressiert, und diese dann von Hand weiter fährt, ohne dass es der Automation der Software in die Queere kommt, weil die Zentrale ja sowohl die Handregleraktionen, als auch die der Software "sieht" und dem Handregler den Vorrang geben kann.
Auch wenn die Softwareautomatik in Abschnitt (B) eigentlich FS12 und F2 möchte kann ich von Hand natürlich auch anders Fahren. Tortzdem kann die Software meine Lok (wenn es so eingestellt ist) weiterhin insofern dirigieren, als dass sie mir Halt vorschreibt, auf den meine Lok (je nach Einstellung autom. oder ich von Hand) reagiert / reagieren muss und mir bestimmte Fahrstraßen vorschreibt.
Nehme ich die Lok wieder vom Handregler, wird diese logischerweise automatisch wieder von der Software "übernommen".

---

So in etwa stelle ich mir das vor. Wenn ich Erich richtig verstanden habe, sollte das mit Rocrail auch möglich sein, da Rocrail auch die Steuerbefehle, die von einem Handsteuergerät an eine Zentrale geschickt werden kennt.
Damit muss ich doch Rocrail nur sagen, dass die Steuerbefehle für eine Lok, die ggf. von einem Handregler kommen, dann Vorrang haben.

Zitat

---

Das was du dir wünschst Stephan, sollte also mit C-Digital einfach möglich sein. Bei Rocrail kann das so zumindest nicht gehen, denke ich.

---

Ich bin zwar kein Experte was Rocrail angeht, aber ich kann das nicht ganz nachvollziehen, warum das nicht gehen soll. : (Wenn das so stimmt, was Erich erklärt hat.)

Zitat

---

(2)
Der Datenbus wird deutlich entlastet, ohne dass sich irgendwelche Nachteile gegenüber der DCC-Variante ergeben.

---

Nach deiner Aufzählung wird der Datenbus um gute 77% weniger belastet, das stimmt schon, aber da fehlt der Software dann doch auch die Information darüber wie schnell sich eine Lok wann bewegt. Also gibt es dann doch einen informativen Nachteil, oder?

Freundliche Grüße,
Stephan L.

Hallo Klaus,

vielen Dank erst mal für die Gegenüberstellung - die allerdings von einem Programm ausgeht, das nicht die in den Decodern (bei DCC sind das, soweit ich mich erinnere, die CV 3 und 4) eingestellten Beschleunigungskurven verwendet, sondern selbst welche errechnet. Zumindest für die Beschleunigung tut Rocrail das grundsätzlich nicht, sondern vertraut immer auf die eingestellte CV3. Bei der Bremsung kann man mit BBT etwa 10 Abstufungen errechnen lassen, das ist aber auch kein "Muss" und vom Hersteller nur unter Protest eingebaut worden. Ansonsten arbeitet Rocrail mit vier Geschwindigkeiten: Vmin, Vmid, Vcruise und Vmax, die allerdings nicht im Decoder, sondern in der Software eingestellt werden.

Dies genau aus dem Grund, den Datenbus zu entlasten - und nicht nur den, sondern auch einen eventuellen Mini-Computer, der als "Server" für das Programm dient.

Zitat

---

(2)
Der Datenbus wird deutlich entlastet, ohne dass sich irgendwelche Nachteile gegenüber der DCC-Variante ergeben.

---

Welches Protokoll dabei zwischen Zentrale und Decodern verwendet wird, ist dem Programm auch egal; für meine Loks weiß Rocrail lediglich, wie viele Fahrstufen für jede Lok verwendet werden und welche F-Tasten es ansprechen kann.

Zitat

---

(1)
Bei C-Digital ist es so also möglich, dass man mit einem mit der Zentrale verbundenen Handregler die LokX adressiert, und diese dann von Hand weiter fährt, ohne dass es der Automation der Software in die Queere kommt, weil die Zentrale ja sowohl die Handregleraktionen, als auch die der Software "sieht" und dem Handregler den Vorrang geben kann.
Auch wenn die Softwareautomatik in Abschnitt (B) eigentlich FS12 und F2 möchte kann ich von Hand natürlich auch anders Fahren. Tortzdem kann die Software meine Lok (wenn es so eingestellt ist) weiterhin insofern dirigieren, als dass sie mir Halt vorschreibt, auf den meine Lok (je nach Einstellung autom. oder ich von Hand) reagiert / reagieren muss und mir bestimmte Fahrstraßen vorschreibt.
Nehme ich die Lok wieder vom Handregler, wird diese logischerweise automatisch wieder von der Software "übernommen".

---

Auch das geht prinzipiell in Rocrail. Wenn ich nicht will, dass das Programm an einer Stelle, wo im automatischen Ablauf ein neuer Geschwindigkeitsbefehl vom Programm gegeben würde, diesen sendet, dann muss ich die Lok im Programm als "halbautomatisch" anmelden, d.h. das Programm fungiert für diese Lok lediglich als Fahrdienstleiter. Ich habe die Option (aber in den Programmoptionen), für diese halbautomatisch geführten Loks automatische Abbremsungen vor roten Signalen durchführen zu lassen oder diese Verantwortung komplett dem Spieler zu überlassen.
Ich kann natürlich auch einfach so an einer Lok "herumsteuern", ohne sie aus der Vollautomatik herauszunehmen, aber das führt u.U. zu konkurrierenden Aufträgen.

Wenn das mit einem Programm und einer Zentrale geht oder nicht geht, dann hat das auch wenig mit dem oder den verwendeten Protokollen zu tun, sondern mit der Konfiguration des Programms und auch mit der Kommunikation zwischen Zentrale und Programm, für die sehr viele Zentralen eigene, proprietäre, Protokolle aufweisen. Deshalb muss das Programm ja wissen, mit welcher oder welchen Zentrale(n) es zu tun hat. Wie einfach wäre es, wenn sie alle über das gleiche Protokoll mit dem Computer kommunizierten...
Insofern ist der Punkt "Computer" für mich hier auch gar nicht so interessant. Ein solches Programm würde mit C-DIgital auch nicht grundlegend anders umgehen - und was die Datenmenge angeht, ist zumindest Rocrail auf dem gleichen Weg wie C-Digital.

Wo es für mich interessant wird:

Zitat

---

Software hat irgendwann Meldung über LokX in besetztem Abschnitt (A) bekommen & LokX FS auf "16" vorwärts + "Halt" gesendet oder Abschnitt (A) "Halt"

---

Sehe ich das richtig, "Abschnitt (x) Halt" bedeutet, die Zentrale hat an einen lokalen elektronischen Baustein den Auftrag gegeben, der Lok im Abschnitt den Auftrag "halt" zu übermitteln?
Ich kann also entweder direkt durch die Zentrale oder mittelbar über einen Baustein der Lok Geschwindigkeitsstufen übermitteln?
Und: in der Lok bzw. richtiger im Decoder existiert so etwas wie eine Geschwindigkeitsvorwahl? Also, als Vergleich beim Auto, ich halte das Auto mit der Bremse, aber sobald ich sie loslasse und den Tempomat, der noch 100km/h im Speicher hat, wieder einschalte, beschleunigt die Fuhre wieder auf diese Geschwindigkeit?
Und der kennt auch noch mehrere Stufen, ähnlich denen, die Rocrail verwendet (das jetzt nur als Vergleich für mich)?

Jetzt wäre für mich die Frage: diese Bausteine, arbeiten die auch quasi autark, oder auf Impuls etwa durch ein Hauptsignal, aber ohne direkte Mitwirkung der Zentrale, oder muss es über die Zentrale gehen? Und wird - etwa für eine gerade nicht sichtbare Lok wäre das interessant - an der Zentrale irgendwie angezeigt, wenn die gerade auf dem Regler aktive Lok durch einen Baustein einen Haltbefehl erhält? Oder steht man im ungünstigen Fall da und wundert sich, warum der Zug nicht wiederkommt?

Für mich wird Digitalbetrieb - über die üblichen Argumente "Sound und Licht auch im Stand, keine Einschränkungen durch vorgegebene isolierte Abschnitte" hinaus selbstverständlich - gerade da interessant, wo ich automatisierte Abläufe eben nicht durch Bausteine am Gleis fest vorgebe, quasi durch Hardware "programmiere", sondern softwareseitig einstellen kann, was passiert: Dampfloks pfeifen hier, bimmeln dort, Dieselloks tuten bei beiden, ein Triebwagen hält am Haltepunkt an, während der Güterzug durchfährt, vor dem Signal im Bahnhof hält der Güterzug direkt am Signal, während der Personenzug an der H-Tafel zum Stehen kommt, etc. pp. Dazu brauche ich, nach meinem Verständnis, eine zentrale "künstliche Intelligenz", die weiß, welcher Zug bzw. welche Lok sich gerade wo befindet, und entsprechend situationsbezogen reagieren kann. Natürlich kann vieles auch in die ortsfesten und in die Lok-Decoder verlegt werden, die dann miteinander kommunizieren können, aber ich bezweifle, dass es günstiger ist, eine Informationsverarbeitung an vielen Stellen durchführen zu lassen, als das Ganze zentral zu managen. Die örtlichen Ausführenden müssen ja auch erst mal geschult - äh, programmiert werden, und jede Änderung, die ich wünsche, muss ich dann allen mitteilen statt einmal im Zentralprogramm ändern...

Zitat

---

aber da fehlt der Software dann doch auch die Information darüber wie schnell sich eine Lok wann bewegt. Also gibt es dann doch einen informativen Nachteil, oder?

---

Das ist ein klarer Fall von "je nachdem". Wenn man, wie das gern von den Nutzern der jeweiligen Programme propagiert wird, die Ortsbestimmung der Lok allein dem Rechner überlässt, der den Ort kurz gesagt aus der Fahrstufenkurve und der Zeit berechnet und nur ab und an, nämlich beim Übergang in einen neuen Überwachungsabschnitt, quasi diese Berechnung auf die Realität abgleicht, dann fehlt da schon ein wichtiges Element und kann der PC im Grunde den Zug nicht mehr sicher steuern.

Wenn man aber, wie Rocrail und wie Klaus das für C-Digital parallel auch dargestellt hat, mit mehreren Meldepunkten je Abschnitt arbeitet, dann braucht man diese berechnete Ortsbestimmung gar nicht: am ersten Melder im Abschnitt wird der Lok ein Langsamfahrbefehl gegeben, u.u. durch einen oder mehrere weitere(n) Melder noch mal abgestuft (1.Melder 60, 2.Melder 30) und am letzten Melder Haltbefehl gegeben. Das System ist sicher und zuverlässig und nicht auf die Fahrstufenkurve und die Ortsberechnung angewiesen. (Die nicht nur Traffic auf dem Gleisbus verursacht, sondern auch eine Menge Rechenleistung verlangt. Aus diesem Grund - und weil Rocrail mit Server-Client-Architektur arbeitet - kann man mit überschaubarer Rechnerleistung unter Rocrail eine Show wie MiniWorld Lyon steuern; mit TC oder WDP und im PC errechneten Bremskurven käme man schnell an die Grenzen des Rechners.)
Diese Zwei- bzw. Drei-Melder-Technik funktioniert aber auch mit andren Programmen. Sie hat noch dazu den großen Vorteil, dass Gastlokomotiven ohne zeitraubendes Einmessen sofort in Betrieb genommen werden können.

Morgen an alle,

Ich muss sagen, dass ich jetzt leider an vielen Stellen eher verwirrter bin als zuvor.
Aber vielleicht ist es das Fragezeichen kurz vor dem GROßEN Lichtblick?

Danke Erich für deine Stellungnahme und Erklärung was Rocrail angeht. Das scheint tatsächlich mein Programm zu werden.

Bei den anderen Fragen müsste Martin was zu sagen, denn so wie ich das C-Digital verstanden habe, ist es noch etwas anders, als das jetzt von euch (Klaus und Erich) geschildert wurde.


[quote="Erich Müller" post_id=1826954 time=1524953131 user_id=26147]
Dies genau aus dem Grund, den Datenbus zu entlasten - und nicht nur den, sondern auch einen eventuellen Mini-Computer, der als "Server" für das Programm dient. [/quote]Das sehe und verstehe ich auch so. Da hat Klaus schon recht, dass sich hierdurch eine relativ starke Entlastung beim Informationsfluss ergibt. Umso besser, dass sich dies bei Rocrail ähnlich verhält.

[quote="Erich Müller" post_id=1826954 time=1524953131 user_id=26147]
Bei der Bremsung kann man mit BBT etwa 10 Abstufungen errechnen lassen, das ist aber auch kein "Muss" und vom Hersteller nur unter Protest eingebaut worden. Ansonsten arbeitet Rocrail mit vier Geschwindigkeiten: Vmin, Vmid, Vcruise und Vmax, die allerdings nicht im Decoder, sondern in der Software eingestellt werden.
[/quote]Hier stellen sich mir nun einige Fragen:
Was ist BBT und was macht das? Wenn ich in Rocrail die vier Geschwindigkeiten in der Software einstelle, wie wird dann - im Fall einer autom. Bremsung - der Lok(Dekoder) über die Zentrale das Bremsen beigebracht? Was schickt die Software denn dann für Inforamtion an die Zentrale und was schickt die Zentrale dann anden Dekoder?


[quote="Erich Müller" post_id=1826954 time=1524953131 user_id=26147]

Zitat

---

(2)
Der Datenbus wird deutlich entlastet, ohne dass sich irgendwelche Nachteile gegenüber der DCC-Variante ergeben.

---

Welches Protokoll dabei zwischen Zentrale und Decodern verwendet wird, ist dem Programm auch egal; für meine Loks weiß Rocrail lediglich, wie viele Fahrstufen für jede Lok verwendet werden und welche F-Tasten es ansprechen kann.
[/quote]Eben. Mehr ist doch, oder sollte doch auch nicht nötig sein. Gut im Fall von C-Digital gibt es nunmal fest die 31 Fahrstufen, also muss man der Software hier nichts extra sagen, - aber das ist ja Pillepalle.


[quote="Erich Müller" post_id=1826954 time=1524953131 user_id=26147]
Auch das geht prinzipiell in Rocrail. Wenn ich nicht will, dass das Programm an einer Stelle, wo im automatischen Ablauf ein neuer Geschwindigkeitsbefehl vom Programm gegeben würde, diesen sendet, dann muss ich die Lok im Programm als "halbautomatisch" anmelden, d.h. das Programm fungiert für diese Lok lediglich als Fahrdienstleiter. Ich habe die Option (aber in den Programmoptionen), für diese halbautomatisch geführten Loks automatische Abbremsungen vor roten Signalen durchführen zu lassen oder diese Verantwortung komplett dem Spieler zu überlassen.
[/quote] Ah, hier werde ich gerade etwas skeptisch, ich hoffe zu Unrecht...
Verstehe ich dich hier richtig, dass ich in der Software von vornherein eine Lok als "halbautomatisch" anmelden muss, man also nicht im laufenden Betrieb einfach hin- und herwechseln kann?
Ich müsste Rocrail also vor Spielbeginn sagen, diese Lok(X) wird von einem Handregler gesteuert, mach mir bitte nur den Fahrdienstleister (autom. Bremsung - Einstellungssache). :
[quote="Erich Müller" post_id=1826954 time=1524953131 user_id=26147]
Ich kann natürlich auch einfach so an einer Lok "herumsteuern", ohne sie aus der Vollautomatik herauszunehmen, aber das führt u.U. zu konkurrierenden Aufträgen.[/quote]Neee, das geht auf keinen Fall (kommt für mich nicht in Frage meine ich). Das führt ja dauernd zu Informationskonflikten - sowas ist großer Mist.


[quote="Erich Müller" post_id=1826954 time=1524953131 user_id=26147]
Sehe ich das richtig, "Abschnitt (x) Halt" bedeutet, die Zentrale hat an einen lokalen elektronischen Baustein den Auftrag gegeben, der Lok im Abschnitt den Auftrag "halt" zu übermitteln?[/quote]
Ich beantworte das mal, obwohl das eigentlich Martins Frage ist
Jein.
Im Fall des ausschließlich lokspezifischen Halts, geht der "Halt" Befehl global über die Gleise, weil ihn ja nur die Lok(X) auswertet.
Im Fall einer Kombination aus lokspezifisch und nicht, wird der "Halt" Befehl nur lokal beim Belegtmelder-Abschnitt auf die Schiene gegeben.
Im Fall des ganz alten C-Digital, wir in einem vordefinierten Abschnitt zum Halten, bei Bedarf zwischen Datensignal ohne "Halt" auf Datensignal mit "Halt" umgeschaltet.

Ich denke ich habe das richtig verstanden Martin, oder?

[quote="Erich Müller" post_id=1826954 time=1524953131 user_id=26147]
Ich kann also entweder direkt durch die Zentrale oder mittelbar über einen Baustein der Lok Geschwindigkeitsstufen übermitteln?[/quote]Meines Erachtens nein. Du kannst dem Lokführer (Dekoder + Mensch) ungeachtet der Geschwindigkeit, die er sonst fahren würde, ein "Halt" vorschreiben. Und das macht nicht der Baustein, sondern immer die Zentrale oder eine Steuerung, die entweder einen Umschalter dazu veranlasst, von Datensignal ohne, auf Datensignal mit "Halt" umzuschalten (C-Digital alt), oder es wird von der Zentrale Global ein adressspezifisches "Halt" gesendet.

[quote="Erich Müller" post_id=1826954 time=1524953131 user_id=26147]
Und: in der Lok bzw. richtiger im Decoder existiert so etwas wie eine Geschwindigkeitsvorwahl?
Und der kennt auch noch mehrere Stufen, ähnlich denen, die Rocrail verwendet (das jetzt nur als Vergleich für mich)?
[/quote]Vielleicht könnte man das so sehen, ja? Ich verstehe Martins Prinzip und Denkweise hier so:
Über die Fahrstufe teile ich der Lok mit wie schnell diese wo fahren darf. Das macht entweder ein Mensch oder eine Maschine/Programm. Und der letzte Wert, den der Dekoder bekommen hat, entspräche also deiner "Geschwindigkeitsvorwahl", über die ich dem dekoderseitigen Teil des Lokführers mitgeteilt habe, wie schnell er aktuell fahren dürfte.
Gesetz dem Fall der Lokführer(Dekoder) sieht(empfängt) dann ein "Halt", dann gilt die erlaubte Geschwindigkeit selbstverständlich immer noch, jedoch muss er zunächst einmal halten. Dieses Halten kann dann auf manuellem oder autom. Weg erfolgen, je nach Einstellung.

Ich hoffe, dass ich auch das richtig verstanden habe, Martin.


[quote="Erich Müller" post_id=1826954 time=1524953131 user_id=26147]
Jetzt wäre für mich die Frage: diese Bausteine, arbeiten die auch quasi autark, oder auf Impuls etwa durch ein Hauptsignal, aber ohne direkte Mitwirkung der Zentrale, oder muss es über die Zentrale gehen? Und wird - etwa für eine gerade nicht sichtbare Lok wäre das interessant - an der Zentrale irgendwie angezeigt, wenn die gerade auf dem Regler aktive Lok durch einen Baustein einen Haltbefehl erhält? Oder steht man im ungünstigen Fall da und wundert sich, warum der Zug nicht wiederkommt? [/quote]
Das kann ich nicht in vollem Umfang beantworten, ich weiß nur, dass man sich einen Halt einer Lok(X), die man auf einem Handregler hat, anzeigen lassen kann. (also beim neuen C-Digital glaube ich)

[quote="Erich Müller" post_id=1826954 time=1524953131 user_id=26147]
Für mich wird Digitalbetrieb - über die üblichen Argumente "Sound und Licht auch im Stand, keine Einschränkungen durch vorgegebene isolierte Abschnitte" hinaus selbstverständlich - gerade da interessant, wo ich automatisierte Abläufe eben nicht durch Bausteine am Gleis fest vorgebe, quasi durch Hardware "programmiere", sondern softwareseitig einstellen kann, was passiert: Dampfloks pfeifen hier, bimmeln dort, Dieselloks tuten bei beiden, ein Triebwagen hält am Haltepunkt an, während der Güterzug durchfährt, vor dem Signal im Bahnhof hält der Güterzug direkt am Signal, während der Personenzug an der H-Tafel zum Stehen kommt, etc. pp. Dazu brauche ich, nach meinem Verständnis, eine zentrale "künstliche Intelligenz", die weiß, welcher Zug bzw. welche Lok sich gerade wo befindet, und entsprechend situationsbezogen reagieren kann. Natürlich kann vieles auch in die ortsfesten und in die Lok-Decoder verlegt werden, die dann miteinander kommunizieren können, aber ich bezweifle, dass es günstiger ist, eine Informationsverarbeitung an vielen Stellen durchführen zu lassen, als das Ganze zentral zu managen. Die örtlichen Ausführenden müssen ja auch erst mal geschult - äh, programmiert werden, und jede Änderung, die ich wünsche, muss ich dann allen mitteilen statt einmal im Zentralprogramm ändern... [/quote]
Das sehe ich genauso wie du. Bei einer Automation oder Halbautomation wäre mir genau das auch wichtig.


[quote="Erich Müller" post_id=1826954 time=1524953131 user_id=26147]

Zitat

---

aber da fehlt der Software dann doch auch die Information darüber wie schnell sich eine Lok wann bewegt. Also gibt es dann doch einen informativen Nachteil, oder?

---

Das ist ein klarer Fall von "je nachdem". Wenn man, wie das gern von den Nutzern der jeweiligen Programme propagiert wird, die Ortsbestimmung der Lok allein dem Rechner überlässt, der den Ort kurz gesagt aus der Fahrstufenkurve und der Zeit berechnet und nur ab und an, nämlich beim Übergang in einen neuen Überwachungsabschnitt, quasi diese Berechnung auf die Realität abgleicht, dann fehlt da schon ein wichtiges Element und kann der PC im Grunde den Zug nicht mehr sicher steuern.

Wenn man aber, wie Rocrail und wie Klaus das für C-Digital parallel auch dargestellt hat, mit mehreren Meldepunkten je Abschnitt arbeitet, dann braucht man diese berechnete Ortsbestimmung gar nicht: am ersten Melder im Abschnitt wird der Lok ein Langsamfahrbefehl gegeben, u.u. durch einen oder mehrere weitere(n) Melder noch mal abgestuft (1.Melder 60, 2.Melder 30) und am letzten Melder Haltbefehl gegeben. Das System ist sicher und zuverlässig und nicht auf die Fahrstufenkurve und die Ortsberechnung angewiesen. (Die nicht nur Traffic auf dem Gleisbus verursacht, sondern auch eine Menge Rechenleistung verlangt. Aus diesem Grund - und weil Rocrail mit Server-Client-Architektur arbeitet - kann man mit überschaubarer Rechnerleistung unter Rocrail eine Show wie MiniWorld Lyon steuern; mit TC oder WDP und im PC errechneten Bremskurven käme man schnell an die Grenzen des Rechners.)
Diese Zwei- bzw. Drei-Melder-Technik funktioniert aber auch mit andren Programmen. Sie hat noch dazu den großen Vorteil, dass Gastlokomotiven ohne zeitraubendes Einmessen sofort in Betrieb genommen werden können.
[/quote]Alles klar. Bin mir nicht sicher ob ich das jetzt alles richtig verstanden habe. Muss ich mir nochmal Gedanken zu machen, warum jetzt hier nicht weniger Information vorhanden ist.

Danke Erich und Klaus bis dahin. Ich hoffe Martin kann hier noch etwas Licht ins Dunkle bringen...

Freundliche Grüße,
Stephan L.

Schönen Sonntag an alle stillen und nicht stillen Mitleser ,

Im Folgenden werde ich nur Aussagen das C-Digital betreffend kommentieren, denen ich noch etwas hinzufügen möchte, oder die einen Fehler enthalten. Alles was ich also nicht kommentiere ist soweit korrekt beschrieben worden.

Danke Klaus für deine Gegenüberstellung. Sie ist im Prinzip korrekt. Ich möchte jedoch ausdrücklich betonen, dass sie nicht allgemein für C-Digital gilt. Sie gilt nur bei einer bestimmte Konfiguration mit lückenloser Rückmeldung.

Zitat

---

DCC in blau und C-Digital in grün:

• Schaltbefehle werden an Schaltbaugruppe weitergeleitet und ein Feedback geht zurück
• Schaltbefehle müssen von einem Automaten erfüllt werden und ein Feedback geht zurück

---

Die Schaltbefehle können, müssen aber nicht von einem Automaten erfüllt werden. Das kann auch von Hand erfolgen. Aber für den Vergleich mit einer Vollautomation, ist hier natürlich auch eine Automation zu wählen.

Zitat

---

• Bei pos. Feedback gibt die Software ans Interface den Befehl, LokX FS auf "1" vorwärts
• Bei pos. Feedback gibt die Software ans Interface den Befehl, LokX "Halt weg" oder Abschnitt (A)

"Halt weg" und ggf. Änderung der Beschleunigung

---

Eine Änderung der Beschleunigung vornehmen, kann man zwar machen, ist aber hier eigentlich nicht notwending. Ich wüsste auch nicht, wann das z.B. der Fall sein könnte.
Die Änderung der Beschleunigung ist eher für den händischen, manuellen Betrieb interessant. (variabel Bremsstärke, sofortiges Regeln der Beschleunigung beim Anfahren)

Zitat

---

(1)
Bei C-Digital ist es so also möglich, dass man mit einem mit der Zentrale verbundenen Handregler die LokX adressiert, und diese dann von Hand weiter fährt, ohne dass es der Automation der Software in die Queere kommt, weil die Zentrale ja sowohl die Handregleraktionen, als auch die der Software "sieht" und dem Handregler den Vorrang geben kann.

---

Ja, das ist richtig. Für diese Funktionalität ist bei mir jedoch aufjeden Fall das Protokll deutlich mitverantwortlich.

Zitat

---

Zitat

---

(2)
Der Datenbus wird deutlich entlastet, ohne dass sich irgendwelche Nachteile gegenüber der DCC-Variante ergeben.

---

Nach deiner Aufzählung wird der Datenbus um gute 77% weniger belastet, das stimmt schon, aber da fehlt der Software dann doch auch die Information darüber wie schnell sich eine Lok wann bewegt. Also gibt es dann doch einen informativen Nachteil, oder?

---

Zunächst einmal ist diese Entlastung des Datenbus Situationsabhängig, und kann zwischen 0% und etwa 96% schwanken. Im Mittel, bei einem durchschnittlichen Anlagenbetrieb, liegt die Entlastung bei fast 80%.
Stephan, ich denke, dass du hier evtl. aus den Augen verloren hast, dass einzellne Soll-FSen, die von der Software vorgegeben werden, zunächst überhaupt keinen zusätzlichen informativen Wert enthalten.
Dies wäre erst der Fall, wenn der Decoder der angesprochenen Lok, seine aktuelle FS zurücksendet. (Das ist hier aber nicht der Fall, denke ich)
Des Weiteren ensteht ein echter Mehrwert auch erst dann, wenn eine Lok von der Software "eingemessen" wurde, der Software also eine tatsächliche FSen-Geschwindigkeitszuordnung vorliegt.
Sind diese beiden Punkte nicht gegeben, halte ich eine Übertragung mit lauter Einzelfahrstufen für ein (mit Verlaub) datenübertragungstechnischen Unfug.


@Erich:
Ich muss dir vorweg sagen, dass ich keines der am Markt üblichen Moba-Steuerungsprogramme kenne. Ich habe mich damit auch noch nie auseinandergesetzt und kann desshalb auch kein Wissen darüber vorweisen. Ich habe mir aus ganz bestimmten Gründen für C-Digital solch ein Konzept überlegt, bzw. es ergänzt, und an das halte ich mich. Was andere machen weiß ich nicht und ist mir zunächst einmal auch egal.

Wenn wir hier jedoch Dinge vergleichen wollen und ich deine Fragen überhaupt richtig verstehen können soll, müsste ich ein paar Dinge bspw. über dein Rocrail erst verstehen, damit ich dir dann zeigen kann wo ggf. Unterschiede oder Gemeinsamkeiten liegen.

[quote="Erich Müller" post_id=1826954 time=1524953131 user_id=26147]
vielen Dank erst mal für die Gegenüberstellung - die allerdings von einem Programm ausgeht, das nicht die in den Decodern (bei DCC sind das, soweit ich mich erinnere, die CV 3 und 4) eingestellten Beschleunigungskurven verwendet, sondern selbst welche errechnet. Zumindest für die Beschleunigung tut Rocrail das grundsätzlich nicht, sondern vertraut immer auf die eingestellte CV3. Bei der Bremsung kann man mit BBT etwa 10 Abstufungen errechnen lassen, das ist aber auch kein "Muss" und vom Hersteller nur unter Protest eingebaut worden. Ansonsten arbeitet Rocrail mit vier Geschwindigkeiten: Vmin, Vmid, Vcruise und Vmax, die allerdings nicht im Decoder, sondern in der Software eingestellt werden.
[/quote] Hier würde ich gerne verstehen:
- Wenn die 4 Geschwindigkeiten in der Software eingestellt werden, wie erfährt der Decoder davon, durch Programmierung?

- Was BBT ist weiß ich leider nicht

- Wenn die Lok(x) nun im Abschnitt(A) zum Halten gebracht werden soll. Was sendet dann Rocrail an die Zentrale und was geht von der Zentrale zum Decoder?

- Ist die ABV im laufenden Betrieb (also während des Anfahrens, oder Bremsens) veränderbar?

[quote="Erich Müller" post_id=1826954 time=1524953131 user_id=26147]
Dies genau aus dem Grund, den Datenbus zu entlasten - und nicht nur den, sondern auch einen eventuellen Mini-Computer, der als "Server" für das Programm dient. [/quote]Das halte ich auch für wichtig, darum habe ich auch bei C-Digital darauf geachtet, dass keine Information unnötig zwischen verschiedenen Baugruppen herumgejagt wird und die Leitungen für wichtige zeitkritische Informationen verstopft.


[quote="Erich Müller" post_id=1826954 time=1524953131 user_id=26147]

Zitat

---

(2)
Der Datenbus wird deutlich entlastet, ohne dass sich irgendwelche Nachteile gegenüber der DCC-Variante ergeben.

---

Welches Protokoll dabei zwischen Zentrale und Decodern verwendet wird, ist dem Programm auch egal; für meine Loks weiß Rocrail lediglich, wie viele Fahrstufen für jede Lok verwendet werden und welche F-Tasten es ansprechen kann.
[/quote]Wie gesagt, ist im Fall von C-Digital das Protokoll hier auf jeden Fall mitverantwortlich.
Bei C-Digital müsste ein Programm auch nur die Funktionen kennen, sofern man sich die Loks nicht eh selbst anmelden lässt.



[quote="Erich Müller" post_id=1826954 time=1524953131 user_id=26147]
Auch das geht prinzipiell in Rocrail. Wenn ich nicht will, dass das Programm an einer Stelle, wo im automatischen Ablauf ein neuer Geschwindigkeitsbefehl vom Programm gegeben würde, diesen sendet, dann muss ich die Lok im Programm als "halbautomatisch" anmelden, d.h. das Programm fungiert für diese Lok lediglich als Fahrdienstleiter.
[/quote]Wie unterscheidet Rocrail einen automatischen von einem halbautomatischen Betrieb?
Im Fall von C-Digital unterscheidet die Software hier praktisch nicht.

[quote="Erich Müller" post_id=1826954 time=1524953131 user_id=26147]
Ich habe die Option (aber in den Programmoptionen), für diese halbautomatisch geführten Loks automatische Abbremsungen vor roten Signalen durchführen zu lassen oder diese Verantwortung komplett dem Spieler zu überlassen.
[/quote] Wie kann ein Spieler bei Rocrail darauf Einfluss nehmen, ob er von Hand abbremsen möchte, oder er es der Automatik überlassen will?
Im Fall von C-Digital, entscheidet das der Spieler bei einer beliebigen Lok(x), die er sich gerade zum manuellen Fahren durch Adressierung am Handregelr aus der Automatik zur Halbautomatik freigegeben hat, am Handregler. Er kann es auch während des Fahrens andauernd ändern.
Gibt er durch Abadressieren die Lok zurück in die Automatik, geschieht der Signalhalt immer automatisch.


[quote="Erich Müller" post_id=1826954 time=1524953131 user_id=26147]
Wenn das mit einem Programm und einer Zentrale geht oder nicht geht, dann hat das auch wenig mit dem oder den verwendeten Protokollen zu tun, sondern mit der Konfiguration des Programms und auch mit der Kommunikation zwischen Zentrale und Programm ...[/quote]Das ist mir so ohne Weiteres nicht klar, weil bei mir einige Dinge nur durch das Protokoll so möglich sind.

[quote="Erich Müller" post_id=1826954 time=1524953131 user_id=26147]
..., für die sehr viele Zentralen eigene, proprietäre, Protokolle aufweisen. Deshalb muss das Programm ja wissen, mit welcher oder welchen Zentrale(n) es zu tun hat. Wie einfach wäre es, wenn sie alle über das gleiche Protokoll mit dem Computer kommunizierten... [/quote]Das lässt sich wahrscheinlich leider auch nie erreichen, weil jeder doch irgendwie seine eigene Philosphie verfolgt. (sieh mich an )

[quote="Erich Müller" post_id=1826954 time=1524953131 user_id=26147]
Insofern ist der Punkt "Computer" für mich hier auch gar nicht so interessant. Ein solches Programm würde mit C-DIgital auch nicht grundlegend anders umgehen - und was die Datenmenge angeht, ist zumindest Rocrail auf dem gleichen Weg wie C-Digital.[/quote]Klar sind die Programme irgendwo ähnlich. Das ist doch auch logisch. Die Grund/bzw. Ausgangssituation ist doch für alle ziemlich gleich, also gibt es auch nur eine begrenzte Anzahl an Lösungen, die sich natürlich ähneln.
Wie gesagt kenne ich Rocrail zwar nicht, jedoch kann es durchaus sein, dass man da ein ähnliches Konzept verfolgt. :

Zitat

---

Software hat irgendwann Meldung über LokX in besetztem Abschnitt (A) bekommen & LokX FS auf "16" vorwärts + "Halt" gesendet oder Abschnitt (A) "Halt"

---

[quote="Erich Müller" post_id=1826954 time=1524953131 user_id=26147]
Sehe ich das richtig, "Abschnitt (x) Halt" bedeutet, die Zentrale hat an einen lokalen elektronischen Baustein den Auftrag gegeben, der Lok im Abschnitt den Auftrag "halt" zu übermitteln?
Ich kann also entweder direkt durch die Zentrale oder mittelbar über einen Baustein der Lok Geschwindigkeitsstufen übermitteln?
Und: in der Lok bzw. richtiger im Decoder existiert so etwas wie eine Geschwindigkeitsvorwahl? Also, als Vergleich beim Auto, ich halte das Auto mit der Bremse, aber sobald ich sie loslasse und den Tempomat, der noch 100km/h im Speicher hat, wieder einschalte, beschleunigt die Fuhre wieder auf diese Geschwindigkeit?
Und der kennt auch noch mehrere Stufen, ähnlich denen, die Rocrail verwendet (das jetzt nur als Vergleich für mich)?[/quote]

Zitat

---

Jein.
Im Fall des ausschließlich lokspezifischen Halts, geht der "Halt" Befehl global über die Gleise, weil ihn ja nur die Lok(X) auswertet.
Im Fall einer Kombination aus lokspezifisch und nicht, wird der "Halt" Befehl nur lokal beim Belegtmelder-Abschnitt auf die Schiene gegeben.
Im Fall des ganz alten C-Digital, wir in einem vordefinierten Abschnitt zum Halten, bei Bedarf zwischen Datensignal ohne "Halt" auf Datensignal mit "Halt" umgeschaltet.

---

In erster Hinsicht, handelt es sich bei der gesendeten Fahrstufe um eine max. "Geschwindigkeitserlaubnis", die ein Spieler/Software der Lok gestattet. In deinem Vergleich mit dem Auto wäre das soetwas wie ein Geschwindigkeitsbegrenzungsschild z.B. 120km/h.
Wie die Lok dann genau fährt, entscheidet der Lokführer (Decoder-Mensch), wobei es hier aufgrund des Informationslecks wieder eindeutig mehr der Decoder ist. Dieser regelt den Motor, vergleicht Soll- mit Ist-"Geschwindigkeit", "spürt" die Masse der Zuglast, regelt die Stromaufnahme des Motors und und und.
(Ob sich die Lok am Ende dann auch mit "120km/h" fortbewegt, weiß weder der Mensch noch die Zentrale noch irgendeine Software. Es weiß nur der Decoder. (Außer der Decoder meldet immer seine tatsächliche FS zurück))

Die Information zu halten, was für den menschlichen Teil des Lokführers ebenfalls eine Informationslücke darstellen kann, wird ja dem Decoder über das Protokoll mitgeteilt. Der Decoder "entscheidet" (je nach Einstellung), ob er nun selbst bremsen, also die FSen verringern soll, oder ob der menschliche Teil dazu aufgefordert werden soll (-> verlangtes Halt wird am Handregeler angezeigt).

Was hier vielleicht noch interessant ist, wegen des Vergleichens:
Im Fall von den DCC-Steuerungen, mit denen hier verglichen wird, ist die Strecke der Anlage in mehrere Abschnitte unterteilt und diese werden von Besetztmeldemodulen überwacht. Zusätzlich gibt es wohl ggf. noch punktuelle Melder (Reedkontekte?).
Im Fall von C-Digital sieht das, in dem hier herangezogenen Fall, fast genauso aus. Die Anlagenstrecke ist in Abschnitte unterteilt und diese werden von den C-Digital-Rückmelde-Besetztmodulen überwacht, - und fertig.
Das was du als "lokalen elektronischen Baustein" betitelst, ist im Grunde auch nichts anderes als die stromfühlenden Besetztmelder im Fall von DCC. Bei C-Digital können diese vielleicht mehr, keine Ahnung : , - und sie sind natürlich für dieses System konzipiert und ausgelegt, aber sie sind prinzipiell eben auch nichts anderes als in deinem DCC Fall.
Wahrscheinlich sind sie so ähnlich wie ein Besetztmelder mit Railcom?

Zitat

---

Jetzt wäre für mich die Frage: diese Bausteine, arbeiten die auch quasi autark, oder auf Impuls etwa durch ein Hauptsignal, aber ohne direkte Mitwirkung der Zentrale, oder muss es über die Zentrale gehen?

---

Das kann sowohl als auch erfolgen. Man kann diese Module auch als mehr oder weniger "dumme" Umschalter einsätzen.
Der Hintergrund ist folgender:
Hat sich jemand eine Anlage mit dem alten C-Digital aufgebaut und die alte einfache Blockstellenlogik für eine Teilautomation eingebaut und möchte jetzt schrittweise auf das neue C-Digital umsteigen, so kann er zunächst beginnen, die Umschalter in den Blockstellen-Halteabschnitten durch die neuen Rückmelde-Besetztmodule (genannt Abschnittsmodule) zu ersetzen und auch die Streckenabschnitte zwischen zwei Block-Halteabschnitten durch solche Module überwachen lassen.
(Gleiches oder Ähnliches würde für jemand gelten, der noch eine analoge Anlage besitzt, mit analogen Halteabschnitten, und schrittweise mit C-Digital digitalisieren will.)

In der Zeit des Umbaus, kann der Betrieb ohne Einschränkungen mit der ganz alten Hardware ganz normal weiter erfolgen. Ist man dann so weit, dass man die Anlage nahezu vollständig mit den neuen Abschnittsmodulen überwacht und man auch die alte Zentrale und alte Handregler getauscht hat, kann man auf die "neuen" Betriebsmodi umstellen. Die Decoder müssen dafür nicht zwingend alle getauscht werden, weil sich für diese auch ein problemloser Mischbetrieb einstellen lässt. Hat man auch alle Decoder irgendwann erneuert kann man den Mischbetrieb auch abstellen.

In der finalen Ausbaustufe arbeiten die Abschnittsmodulen immer in Absprche mit der Zentrale. Die Zentrale bzw. eigentlich das C-Digital Interface, welches auch außerhalb der Zentrale genutzt werden kann, kommuniziert mit den Abschnittsmodulen über den C-Digital-Bus, an dem ggf. auch eine Software, ein BSW usw. direkt oder über ein Interface hängen müsste.

[quote="Erich Müller" post_id=1826954 time=1524953131 user_id=26147]
Und wird - etwa für eine gerade nicht sichtbare Lok wäre das interessant - an der Zentrale irgendwie angezeigt, wenn die gerade auf dem Regler aktive Lok durch einen Baustein einen Haltbefehl erhält? Oder steht man im ungünstigen Fall da und wundert sich, warum der Zug nicht wiederkommt? [/quote]
Im Fall des C-Digitals mit Abschnittsmodulen, lässt sich die Information über einen Halt immer am Bus abfragen.

Hat man alles neu (Zentrale, Handregeler, Decoder) lässt sich zusätzlich eine Halteinformation lokspezifisch auch an der Zentral abgreifen bzw. an einem Monitor anzeigen. An einem Handregeler wird es einem bei der adressierten Lok auch angezeigt.


[quote="Erich Müller" post_id=1826954 time=1524953131 user_id=26147]
Für mich wird Digitalbetrieb - über die üblichen Argumente "Sound und Licht auch im Stand, keine Einschränkungen durch vorgegebene isolierte Abschnitte" hinaus selbstverständlich - gerade da interessant, wo ich automatisierte Abläufe eben nicht durch Bausteine am Gleis fest vorgebe, quasi durch Hardware "programmiere", sondern softwareseitig einstellen kann, was passiert:[/quote]
Also Bausteine am Gleis hat man doch praktisch immer. Seien es Abschnittsmodule (C-Digital) oder Stromfühler mit oder ohne Railcom (DCC) oder Punktrückmeldemodule. Mir ist kein System bekannt, wo man keine Module am Gleis benötigt, damit man irgendwelche Abläufe oder Funktionen "einprogrammieren" kann.
Ach doch, ich glaube dieses eine System, ich glaube es heißt GamesOnTrack?, macht alles mit Ultraschall und hat keine Module am Gleis.


[quote="Erich Müller" post_id=1826954 time=1524953131 user_id=26147]
Dazu brauche ich, nach meinem Verständnis, eine zentrale "künstliche Intelligenz", die weiß, welcher Zug bzw. welche Lok sich gerade wo befindet... [/quote]
Das weiß die Zentrale doch nur, weil du entsprechende Module am Gleis in deinen Abschnitten hast.

[quote="Erich Müller" post_id=1826954 time=1524953131 user_id=26147]
...., und entsprechend situationsbezogen reagieren kann. Natürlich kann vieles auch in die ortsfesten und in die Lok-Decoder verlegt werden, die dann miteinander kommunizieren können, aber ich bezweifle, dass es günstiger ist, eine Informationsverarbeitung an vielen Stellen durchführen zu lassen, als das Ganze zentral zu managen.
[/quote]Das ist zu allgemein/pauschal formuliert, und ich kann dazu nichts sagen. Ich weiß auch nicht was hier wie "günstiger" sein soll und was du unter "zentral managen" verstehst. :

[quote="Erich Müller" post_id=1826954 time=1524953131 user_id=26147]
Die örtlichen Ausführenden müssen ja auch erst mal geschult - äh, programmiert werden, und jede Änderung, die ich wünsche, muss ich dann allen mitteilen statt einmal im Zentralprogramm ändern...[/quote]
Das verstehe ich und finde ich auch unsinnig, aber in welchem System muss man denn das bitte so machen, dass man jedes einzelene Modul gesondert einstellen muss und man das nicht über eine Software/Zentrale oder so machen kann?

Grüße,
Martin

Hallo Erich und Stephan,

Martin hat ja zu einigen der Fragen schon etwas geschrieben. An einer Stelle hast du mich aber glaube ich missverstanden.

[quote="Erich Müller" post_id=1826954 time=1524953131 user_id=26147]
Wenn man aber, wie Rocrail und wie Klaus das für C-Digital parallel auch dargestellt hat, mit mehreren Meldepunkten je Abschnitt arbeitet, dann braucht man diese berechnete Ortsbestimmung gar nicht
[/quote]
So wie ich Martin verstanden habe, wird eine Abschnitt von einer Rückmeldeleitung eines Moduls überwacht. So ein Abschnitt sollte eine maximale Länge von 4m nicht überschreiten. Mehrere Meldepunkte zusätzlich im Abschnitt - Fehlanzeige.
Er versteht also unter einem Abschnitt, eine an beiden Enden getrennten Gleisabschnitt auf der Anlage. In so einem Abschnitt gibt es keine zusätzlichen weiteren Module und Abschnitte.
Trotzdem sehe ich (ebeso wie Martin) nicht, wo sich hier bei der Übermittelung lauter Einzelfahrstufen ein informativer Vorteil ergeben soll?
Wie er schon sagt, wäre dazu deutlich mehr nötig, wie z.B. das genaue Einmessen jeder Lok und eigentlich auch eine ständige Rückmeldung der tatsächlichen FSe vom Decoder als Feedback zum verifizieren. Ohne das, wäre eine Geschwindigkeits bzw. Ortsbestimmung reine Späkulation der Software, was zum Aufwand, eines exakten Einmessens jeder Lok in die Software, in keinem Verhältnis stünde.

Wahrscheinlich ist es natürlich zusätzlich möglich überall auf der Anlage z.B. Reedkontakte zu nutzen, um an ganz bestimmten Stellen irgendetwas (z.B. Funktion) auslösen zu lassen. Das hat aber glaube ich nichts mit irgendwelchen Abschnitten zu tun, sondern kann generell überall erfolgen.
Bei C-Digital braucht man halt die Abschnitte mit den Abschnittsmodulen, damit sich z.B. das Auslösen einer Funktion auch lokspezifisch einstellen lässt.
In meiner Gegenüberstellung ist bei C-Digital jedoch kein einziger solcher punktuellen Auslöser vorgekommen, sondern nur diese Abschnittsmodule.

Was ich auch nicht ganz nachvollziehen kann ist, warum du der Meinung bist, das Protokoll hätte nichts mit einer Entlastung des Datenbus zu tun. :
Im Fall des C-Digital, sieht man doch in meiner Auflistung deutlich, dass sich eine Entlastung ergibt, weil es eine bestimmte Informationsstruktur und Informationsübertragung im Protokoll gibt.


Und auch hier:
[quote="Erich Müller" post_id=1826954 time=1524953131 user_id=26147]
Auch das geht prinzipiell in Rocrail. Wenn ich nicht will, dass das Programm an einer Stelle, wo im automatischen Ablauf ein neuer Geschwindigkeitsbefehl vom Programm gegeben würde, diesen sendet, dann muss ich die Lok im Programm als "halbautomatisch" anmelden, d.h. das Programm fungiert für diese Lok lediglich als Fahrdienstleiter. Ich habe die Option (aber in den Programmoptionen), für diese halbautomatisch geführten Loks automatische Abbremsungen vor roten Signalen durchführen zu lassen oder diese Verantwortung komplett dem Spieler zu überlassen.
[/quote]Sieht das bei C-Digital ganz anders aus und ich wage es stark zu bezweifeln, dass das so bei Rocrail möglich ist. Wenn doch, dann erkläre das doch bitte genauer wie das bei Rocrail geht.
Wann muss man was wie einstellen? Was kann ein Spieler wie im Betrieb machen?

[quote="Erich Müller" post_id=1826954 time=1524953131 user_id=26147]
Insofern ist der Punkt "Computer" für mich hier auch gar nicht so interessant. Ein solches Programm würde mit C-DIgital auch nicht grundlegend anders umgehen - und was die Datenmenge angeht, ist zumindest Rocrail auf dem gleichen Weg wie C-Digital.
[/quote]Da wäre ich mir auch nicht so sicher, beim Umgang der Programme mit C-Digital. Bei der Besetztmeldung und Rückmeldung der Adresse mag das ähnlich oder identisch sein, aber beim Rest? -Hmmm. Wohl eher nicht.
Da müsste das Programm dann schon etwas von dem C-Digitalprotokoll oder Prinzip verstehen... oder es gibt irgendwo eine Übersetzungsinstanz.



[quote="Erich Müller" post_id=1826954 time=1524953131 user_id=26147]

Zitat

---

Software hat irgendwann Meldung über LokX in besetztem Abschnitt (A) bekommen & LokX FS auf "16" vorwärts + "Halt" gesendet oder Abschnitt (A) "Halt"

---

Sehe ich das richtig, "Abschnitt (x) Halt" bedeutet, die Zentrale hat an einen lokalen elektronischen Baustein den Auftrag gegeben, der Lok im Abschnitt den Auftrag "halt" zu übermitteln?
Ich kann also entweder direkt durch die Zentrale oder mittelbar über einen Baustein der Lok Geschwindigkeitsstufen übermitteln?[/quote]
Wo liest du bei einer Information "Halt" etwas von Geschwindigkeitsstufen? Geschwindigkeitsstufen werden entweder von irgendeinem Handsteuergerät oder einer Software über die Zentrale, übers Gleis geschickt.

[quote="Erich Müller" post_id=1826954 time=1524953131 user_id=26147]
Und: in der Lok bzw. richtiger im Decoder existiert so etwas wie eine Geschwindigkeitsvorwahl?
[/quote]Geschwindigkeitsvorwahl? Wann sollte diese denn vorgewählt werden? Bei DCC und auch bei JEDEM anderen System gilt eine eingestellte Geschwindigkeit im Decoder so lang, so lang keine andere zum Decoder gesendet wird. Nennst du das Geschwindigkeitsvorwahl?

[quote="Erich Müller" post_id=1826954 time=1524953131 user_id=26147]
Also, als Vergleich beim Auto, ich halte das Auto mit der Bremse, aber sobald ich sie loslasse und den Tempomat, der noch 100km/h im Speicher hat, wieder einschalte, beschleunigt die Fuhre wieder auf diese Geschwindigkeit?
Und der kennt auch noch mehrere Stufen, ähnlich denen, die Rocrail verwendet (das jetzt nur als Vergleich für mich)?
[/quote]Die "mehreren Stufen" sind die Fahrstufen, 31 bei C-Digital. Eine "Bremse" gibt es doch bei der Moba nicht wirklich, gebremst wird indem man die FSen verringert. Das Belschleunigen erfolgt durch Hochschalten der FSen, wie bei jedem Digitalsystem.

Zitat

---

den Tempomat, der noch 100km/h im Speicher hat

---

Im Fall von DCC schicke ich über meine Lokmaus oder mit meiner EcoS oder mit meiner Software dem Decoder eine Fahrstufe X, die dieser bitteschön fahren soll, sofern er dazu in der Lage ist. Diese FS(X) ist dann im Speicher des Decoders und der versucht so gut es geht diese FSe zu erfüllen. Er erhöht z.B. "heimlich" die FSe ohne, dass du davon weißt, um nach außen den Schein der von dir eingestellten FS(X) zu wahren, wenn die Last größer ausfällt.
Was man einem Decoder also schickt, ist IMMER eine Soll- bzw. "Wunsch"-Geschwindigkeit und der Decoder entscheidet, wie und ob er diese erfüllen kann und darf (bei Überstrom, sollte der Decoder autom. abschalten).
Diese Wunschgeschwindigkeit wird vom Decoder im Speicher abgelegt und ist so lang gültig, bis eine andere Wunschgeschwindigkeit geschickt wird.

Bei C-Digital ist das denke ich genauso, nur dass der Decoder nicht nur auf Steigung, Last usw. sondern auch noch auf Streckensignale wie Halt, Langsamfahrt usw. achten kann. Darauf reagiert er und passt seine tatsächliche, interne FS an. Also vom Prinzip ganz genauso wie bei DCC oder Märklin, wo man den Decoder durch mehr Last oder Steigungsfahrt usw. dazu veranlasst, seine tatsächliche, interne FS anzupassen.

Was dir hier aus der "üblichen" Digitalwelt ungewönlich vorkommen mag, ist es nur wegen der Gewohnheit. Du denkts wahrscheinlich: "Im Fall vom "üblichem" Digital, ist die aktuelle FS nur durch die gewählte FS am Steuergerät oder Software abhängig und sonst von nichts" ?
Obwohl, nein, das ist sie ja beim "üblichen" Digital auch nicht wirklich, sobald man eine ABV einsetzt. Da wird die aktuelle FS dann auch nicht nur über die externe FS am Steuergerät vorgegeben, sondern auch noch von der ABV die man eingestellt hat und ggf. gerade verwendet.


[quote="Erich Müller" post_id=1826954 time=1524953131 user_id=26147]
Dampfloks pfeifen hier, bimmeln dort, Dieselloks tuten bei beiden, ein Triebwagen hält am Haltepunkt an, während der Güterzug durchfährt, vor dem Signal im Bahnhof hält der Güterzug direkt am Signal, während der Personenzug an der H-Tafel zum Stehen kommt, etc. pp. Dazu brauche ich, nach meinem Verständnis, eine zentrale "künstliche Intelligenz", die weiß, welcher Zug bzw. welche Lok sich gerade wo befindet, und entsprechend situationsbezogen reagieren kann.
[/quote]
Dafür braucht man halt viel Hardware am und rundums Gleis. Viele Rückmelder punktuell sowie abschnittsweise Stromfühler und eine Software, die das alles kennt, die komplette Anlage, Streckenverläufe etc. einprogrammiert hat und alle Loks, Weichen und Signale kennt.
Dann ist es natürlich ein "Leichtes" die Software mit Wenn-Dann-Funktionen zu spicken: "Wenn die LokX jetzt dort den Melder auslöst, dann lass diese die Pfeife bedienen. Wenn LokY hier den Melder auslöst, lass sie halten. Wenn LokZ den Melder auslöst lass sie schneller/früher halten." usw usf

Wie gesagt, da muss halt die Anlage zunächst mal mit allerlei Sensoren gesprickt werden. Man bringt also sehr viel zusätzliche Elektronik in die Anlage und den Streckenverlauf. Dann wird die Software aufwändig angelernt und erst dann kann man das machen, wovon du hier sprichst.
Jetzt wäre meine Frage, wie flexiebel ist so eine Steuerung mit einer Software (wie z.B. Rocrail) dann im Betrieb für einen oder mehrere Spieler einsetztbar?
Ist man bei einer Teilautomation darauf angewiesen dauerhaft oder vorab einen Spieler vor den Bildschirm mit der Software zu setzten?
Wie felxibel ist eine Teilautomation in Abwechslung mit einer Vollautomation während des Betriebs?

Zitat

---

aber da fehlt der Software dann doch auch die Information darüber wie schnell sich eine Lok wann bewegt. Also gibt es dann doch einen informativen Nachteil, oder?

---

Ich wüsste nicht, woher die Software wissen sollte, wie schnell sich eine Lok wann bewegt, wenn von dieser Lok nicht zuvor ein Geschwindigkeitsprofil per Messung in der Software angelegt wurde und die Lok auch ihre Geschwindigkeit zurückliefert, damit die Software auch sicher sein kann. (Feedback)
Man könnte halt einen Durchschnitt berechnen, indem man der Software sagt, von Melder(A) zum Melder(B) sind es exakt 55,43 cm. Die Software startet dann einen Timer in dem Moment, wo Melder(A) oder (B) ausgelöst wird und stoppt diesen wieder, wenn Melder(B) oder (A) ausgelöst wird. Und voilà 55,43 cm / Zeit und ich bekomme meine Geschwindigkeit. Das ist aber nur ein grober Durchschnitt. Damit weiß man dann auch nicht, wann sich eine Lok wie schnell bewegt.

Liebe Grüße,
Klaus K.

Hallo zusammen,

nach der Lektüre von Stephans Beitrag wollte ich eigentlich vorschlagen, für die Rocrail-Thematik einen eigenen Thread aufzumachen, weil das Programm nicht unbedingt mit dem Thema "C-Digital System" (die Fragezeichen lasse ich weg) zu tun hat. Soweit es für Martin aber wichtig ist, um mein Referenzsystem zu verstehen, muss natürlich hier darauf geantwortet werden.

Zitat

---

Hier würde ich gerne verstehen:
- Wenn die 4 Geschwindigkeiten in der Software eingestellt werden, wie erfährt der Decoder davon, durch Programmierung?

---

Im Prinzip gar nicht. Wenn für die Lok eine Karte im Programm angelegt wird, dann gibt man neben der Fahrstufenanzahl des Decoders und der Zahl der Funktionen auch diese Geschwindigkeitsstufen in der Karte ein (das kann für vorwärts und rückwärts unterschiedlich sein, z.B. bei Dampfloks, die nur vorwärts schnell fahren dürfen). Die einfache Variante ist, für jede GS eine Decoder-FS anzugeben - etwa: Vmin=2, Vmid=9, Vcruise=22, Vmax=28 (bei 28 FS). Man kann auch die Höchstgeschwindigkeit in km angeben und einer Fahrstufe zuordnen (beispielsweise Vmax=120km/h, FS2 und die anderen Geschwindigkeitsstufen dann in km/h angeben, die das Programm - von einer linearen Decodereinstellung ausgehend - in FS umsteht: Vmin=5km/h, Vmid=40km/h, Vcruise=95km/h.
Dem Decoder wird die jeweils zu fahrende Geschwindigkeit nicht in GS mitgeteilt, sondern als Fahrbefehl, der eine FS enthält. Die GS wird programmintern verwendet (und ist inzwischen auch als Stufe auf dem per Mausklick zu bedienenden Fahrregler im Programm enthalten), wird aber nicht als solche an die Zentrale weitergereicht.

Zitat

---

- Was BBT ist weiß ich leider nicht

---

http://wiki.rocrail.net/doku.php?id=loc-bbt-de erklärt es besser, als ich es könnte - zumal für jemanden mit technischem Verständnis. Wenn noch Fragen sind, gern nachfragen.

Zitat

---

- Wenn die Lok(x) nun im Abschnitt(A) zum Halten gebracht werden soll. Was sendet dann Rocrail an die Zentrale und was geht von der Zentrale zum Decoder?

---

Auch hier verweise ich gern auf die entsprechende Rocrail-Wiki-Seite. http://wiki.rocrail.net/doku.php?id=sens..._3_rueckmeldern
Wichtig ist hier allerdings nicht die Länge des Melders (da tut die Grafik zuviel des Guten), sondern der Moment, wenn er ausgelöst wird.
Wie oben gesagt, übermittelt Rocrail jeweils die der neuen GS entsprechende FS an die Zentrale, die diese FS an den Decoder weitergibt, der von der bisher verwendeten FS mit der im Decoder gespeicherten Verzögerung auf die neue FS geht.

Zitat

---

- Ist die ABV im laufenden Betrieb (also während des Anfahrens, oder Bremsens) veränderbar?

---

Im Prinzip nein. Mit BBT wird sie von einem "Lok x kommt in Block A an" zum nächsten dynamisch angepasst, aber ansonsten nicht. Die BBT-Bremsung ist auch immer linear gedacht zwischen Geschwindigkeit bei Eintritt in den Block und Vmin.
Was in Rocrail mit DCC geht, ich habe es aber noch nicht verwendet: während des Betriebs - etwa weil man einen Zug an eine bisher solo fahrende Lok angehängt hat, oder weil der Zug nun gedacht beladen ist statt leer, oder umgekehrt - die im Decoder gespeicherten Beschleunigungs- und Verzögerungseinstellungen verändern. Das geht, weil DCC es grundsätzlich ermöglicht, diese CV auf dem Betriebsgleis einzustellen, und das Programm ermöglicht den Zugriff auf diese Einstellungen. Aber keine Veränderung während einer Bremsphase oder während des Anfahrens, ich weiß auch nicht, ob die Decoder solche Veränderungen bei fahrender Lok akzeptieren würden.

(Fahrstufenzahl und Zahl der Funktionen)

Zitat

---

Wie gesagt, ist im Fall von C-Digital das Protokoll hier auf jeden Fall mitverantwortlich.
Bei C-Digital müsste ein Programm auch nur die Funktionen kennen, sofern man sich die Loks nicht eh selbst anmelden lässt.

---

Das ist logisch, schließlich ist C-Digital auch Zentrale.
Die Zentrale muss auch alle Funktionen kennen; bei Rocrail kann es ausreichen, wenn ich die Funktionen übermittle, die das Programm auch nutzt: Licht, Horn oder Pfeife, automatische Kupplung, Motorgeräusch (das schalte ich z.B. im Tunnel automatisch aus) - und Rangierfunkgespräche oder solche Sachen, die das Programm ohnehin nicht auslösen soll, braucht es nicht zu wissen.

Zitat

---

Wie unterscheidet Rocrail einen automatischen von einem halbautomatischen Betrieb?
Im Fall von C-Digital unterscheidet die Software hier praktisch nicht.

---

Das steht hier: http://wiki.rocrail.net/doku.php?id=automatic-de
Und die Umschaltung kann mit einem Mausklick (einmal rechts fürs Kontextmenü, dann links zum Auswählen) im laufenden Betrieb geschehen: http://wiki.rocrail.net/doku.php?id=loc-...ically_operated

Zitat

---

Wie kann ein Spieler bei Rocrail darauf Einfluss nehmen, ob er von Hand abbremsen möchte, oder er es der Automatik überlassen will?
Im Fall von C-Digital, entscheidet das der Spieler bei einer beliebigen Lok(x), die er sich gerade zum manuellen Fahren durch Adressierung am Handregelr aus der Automatik zur Halbautomatik freigegeben hat, am Handregler. Er kann es auch während des Fahrens andauernd ändern.
Gibt er durch Abadressieren die Lok zurück in die Automatik, geschieht der Signalhalt immer automatisch.

---

Ob Rocrail auch bei halbautomatisch geführten Zügen die Bremsung vor dem Signal vornimmt, falls nötig, kann in den Programmeinstellungen ausgewählt werden. Das kann man im laufenden Betrieb nicht ändern.
Der Übergang zwischen automatisch und halbautomatisch ist, wie gesagt, mit einem Mausklick machbar, oder entsprechend am Tablet, wenn es an das Netzwerk angeschlossen ist.

(Zur Möglichkeit, dass die Zentrale die an ihr vorgenommenen Änderungen von Fahrzeug-FS oder auch Weichenstellungen an den PC übermittelt)

Zitat

---

Das ist mir so ohne Weiteres nicht klar, weil bei mir einige Dinge nur durch das Protokoll so möglich sind.

---

Da liegt auch einer der wichtigen Unterschiede: dein System ist erst mal dreigliedrig: Eingabegerät, Zentrale (diese sind, vermute ich, in einem Gerät vereint), Anlage. Die Steuerung mit PC ist prinzipiell viergliedrig, weil der PC dazukommt; die Zentrale kann und sollte dabei auch zwischen PC und Eingabegerät vermitteln - tut das aber nicht immer.
Ob sie das tut, hängt davon ab, wie sie mit dem PC kommuniziert, und da gibt es - unabhängig von dem Protokoll, mit dem die Anlage und die Zentrale kommunizieren - leider x und noch mehr verschiedene Sprachen. Wenn man da vereinheitlichen könnte...

Zitat

---

Das lässt sich wahrscheinlich leider auch nie erreichen, weil jeder doch irgendwie seine eigene Philosphie verfolgt. (sieh mich an )

---

Na jaaaa... in vielen Dingen hat man ja mittlerweile wesentlich vereinfachte Bedingungen gegenüber dem, was vor 20 Jahren war. Damals hatte mein PC zwei verschiedene PS/2-Buchsen für Maus und Tastatur, parallel auch noch eine DIN-Buchse für ältere Tastaturen, VGA, eine neunpolige und eine 25polige serielle Schnittstelle und eine parallele, und - neu! - zwei USB. Außerdem eine Modemkarte, das war auch schon was besonderes, die hatte eine Westernbuchse fürs Telefonkabel. Drei Buchsen für Mikro, Lautsprecher und Kopfhörer, aber ohne Farbcode (die Farben kamen wenig später). Externe Laufwerke waren gar nicht vorgesehen - dafür aber zwei verschiedene Diskettengrößen, CD-Leselaufwerk und Brenner getrennt.
Und heute? sämtliche seriellen und parallelen Buchsen, PS/2 und DIN, sind durch USB ersetzt worden. CD braucht man kaum noch, Disketten erst recht nicht, und heutige USB-Sticks fassen mehr Daten als damals die eingebaute Festplatte... da hat man schon gemeinsame Standards gefunden.

Zitat

---

Klar sind die Programme irgendwo ähnlich. Das ist doch auch logisch. Die Grund/bzw. Ausgangssituation ist doch für alle ziemlich gleich, also gibt es auch nur eine begrenzte Anzahl an Lösungen, die sich natürlich ähneln.
Wie gesagt kenne ich Rocrail zwar nicht, jedoch kann es durchaus sein, dass man da ein ähnliches Konzept verfolgt. :

---

Joah - wenn man mal davon absieht, dass Rocrail sich der Lösung 2, die ich unten für Klaus noch mal skizziert habe, konsequent verweigert. (Aus nachvollziehbaren Gründen, wie gesagt.)
Dabei scheint mir, dass die hinter den Arbeiten stehende Philosophie zwischen Rob ("Mr. Rocrail") und dir recht ähnlich ist, und dass eine Rocrail-Version, die für C-Digital nicht mehr Fahrstufen, sondern die Aktivierung des Langsamfahrt- oder Halt-Bits (je nach Bedarf) als Auftrag an die Zentrale weiterreicht, sich in beides gut einfügen würde.
Wobei... technisch scheint es mir durchaus möglich zu sein, auch mit dem C-Digital-Protokoll so zu verfahren, wie es in anderen Protokollen gemacht wird, also nur durch Übermittlung von FS-Aufträgen ohne Verwendung von Langsamfahr- oder Halt-Bit. :

Zitat

---

Ich wüsste nicht, woher die Software wissen sollte, wie schnell sich eine Lok wann bewegt, wenn von dieser Lok nicht zuvor ein Geschwindigkeitsprofil per Messung in der Software angelegt wurde und die Lok auch ihre Geschwindigkeit zurückliefert, damit die Software auch sicher sein kann. (Feedback)
Man könnte halt einen Durchschnitt berechnen, indem man der Software sagt, von Melder(A) zum Melder(B) sind es exakt 55,43 cm. Die Software startet dann einen Timer in dem Moment, wo Melder(A) oder (B) ausgelöst wird und stoppt diesen wieder, wenn Melder(A) oder (B) ausgelöst wird. Und voilà 55,43 cm / Zeit und ich bekomme meine Geschwindigkeit. Das ist aber nur ein grober Durchschnitt. Damit weiß man dann auch nicht, wann sich eine Lok wie schnell bewegt.

---

Klaus, ich habe den Eindruck, bezüglich der Computerprogramme gehst du nicht von dem gleichen Wissens- oder Denkstand aus wie Stephan, Martin und ich. (Und manchmal sprechen wir verschiedene Sprachen...)
Soweit ich die Landschaft da überblicke, gibt es für die grundlegende Zugsteuerung (also fahren und halten) zwei Modelle:

1. das ältere, mit zwei oder mehr Meldern im Block. Hier wird auf die Beschleunigungs- und Verzögerungseinstellungen des Decoders zurückgegriffen, sofern vorhanden. Wenn der Zug den ersten Melder auslöst in dem Block, in dem er halten soll, dann wird ein Befehl mit verringerter Geschwindigkeit ausgelöst: nach dem 1. Melder bremst der Zug auf eine mittlere Geschwindigkeit ab, nach dem 2. Melder auf langsamste Fahrt und nach dem 3. auf Halt. Bei nur zwei Meldern bremst der Zug ab dem ersten Melder auf langsamste Fahrt ab.
   Das funktioniert mit allen Loks, sobald sie auf die Anlage gestellt wurden. Allenfalls können stufige Bremskurven entstehen, wenn die Decoderbremsung deutlich schneller erfolgt als die Fahrzeit zwischen zwei Meldern.
2. das neuere Modell, mit nur einem Melder im Block (mehr sind möglich, aber nicht notwendig). Hier wird auf die Verzögerungseinstellung des Decoders verzichtet und die Software errechnet die Bremskurve. Dazu ist zwingend notwendig, dass der Software exakt der Abstand bekannt ist zwischen dem Punkt, an dem der Melder auslöst, und dem gewünschten Haltepunkt des Zuges, und außerdem die exakte Geschwindigkeit der Lok bei jeder verwendeten Fahrstufe. Das Modell setzt also zwingend voraus, jedes verwendete Triebfahrzeug vor dem Einsatz "einzumessen".
   Einmessen bedeutet: für jede Fahrstufe wird genau gemessen, wie schnell das Fahrzeug sich tatsächlich bewegt. Das kann mit zwei genügend weit entfernten Messpunkten geschehen, so wie du es oben beschreibst, oder auch auf dem Rollenprüfstand. Da geregelte Decoder bei konstanter Gleisspannung reproduzierbar die gleiche Geschwindigkeit bei gleicher FS einregeln, kann man mit dieser Information sehr präzise Weg-Zeit-Diagramme erstellen und damit arbeiten.
   Theoretisch würde dieses System, einmal kalibriert, ohne jede weitere Hardware am Gleis funktionieren. Dass man trotzdem Melder verwendet, dient zur laufenden Rekalibrierung des Systems, weil nun mal im Fahrbetrieb Störfaktoren auftreten - ich nenne das einfach mal "Schlupf", die bei längerem Betrieb doch einen deutlichen Versatz zwischen theoretischer und realer Position erzeugen.

Zitat

---

Im Fall von DCC schicke ich über meine Lokmaus oder mit meiner EcoS oder mit meiner Software dem Decoder eine Fahrstufe X, die dieser bitteschön fahren soll, sofern er dazu in der Lage ist. Diese FS(X) ist dann im Speicher des Decoders und der versucht so gut es geht diese FSe zu erfüllen. Er erhöht z.B. "heimlich" die FSe ohne, dass du davon weißt, um nach außen den Schein der von dir eingestellten FS(X) zu wahren, wenn die Last größer ausfällt.
Was man einem Decoder also schickt, ist IMMER eine Soll- bzw. "Wunsch"-Geschwindigkeit und der Decoder entscheidet, wie und ob er diese erfüllen kann und darf (bei Überstrom, sollte der Decoder autom. abschalten).
Diese Wunschgeschwindigkeit wird vom Decoder im Speicher abgelegt und ist so lang gültig, bis eine andere Wunschgeschwindigkeit geschickt wird.

Bei C-Digital ist das denke ich genauso, nur dass der Decoder nicht nur auf Steigung, Last usw. sondern auch noch auf Streckensignale wie Halt, Langsamfahrt usw. achten kann. Darauf reagiert er und passt seine tatsächliche, interne FS an. Also vom Prinzip ganz genauso wie bei DCC oder Märklin, wo man den Decoder durch mehr Last oder Steigungsfahrt usw. dazu veranlasst, seine tatsächliche, interne FS anzupassen.

Was dir hier aus der "üblichen" Digitalwelt ungewönlich vorkommen mag, ist es nur wegen der Gewohnheit. Du denkts wahrscheinlich: "Im Fall vom "üblichem" Digital, ist die aktuelle FS nur durch die gewählte FS am Steuergerät oder Software abhängig und sonst von nichts" ?
Obwohl, nein, das ist sie ja beim "üblichen" Digital auch nicht wirklich, sobald man eine ABV einsetzt. Da wird die aktuelle FS dann auch nicht nur über die externe FS am Steuergerät vorgegeben, sondern auch noch von der ABV die man eingestellt hat und ggf. gerade verwendet.

---

Verschiedene Sprachen...
Der Decoder tut das ihm mögliche, um die tatsächliche Fahrgeschwindigkeit der durch die übermittelte FS (des Protokolls) vorgegebenen Geschwindigkeit anzupassen. Unter den in CV3 und 4 (bei DCC, in anderen Systemen auch anders, aber ähnlich) vorgegebenen Verzögerungen, gegebenenfalls. Das ist grundsätzlich bei allen geregelten Decodern so, und brauchen wir auch nicht zu diskutieren. Die internen Fahrstufen interessieren mich also nicht.
Was mich interessiert, ist: der Decoder bekommt bei C-Digital eine Fahrstufe angegeben, nehmen wir mal 18 an.
Nun kommt ein Langsamfahr- oder Haltbefehl. Da bleibt die Fahrstufe 18 im Speicher, wird aber nicht mehr ausgeführt, solange der Langsam- oder Haltbefehl gilt, weil der vorrangig ist.
Wird dieser Befehl aufgehoben, dann beschleunigt der Decoder wieder auf die gespeicherte Fahrstufe, die wir als 18 angenommen haben. Richtig?

Zitat

---

Dafür braucht man halt viel Hardware am und rundums Gleis. Viele Rückmelder punktuell sowie abschnittsweise Stromfühler und eine Software, die das alles kennt, die komplette Anlage, Streckenverläufe etc. einprogrammiert hat und alle Loks, Weichen und Signale kennt.
Dann ist es natürlich ein "Leichtes" die Software mit Wenn-Dann-Funktionen zu spicken: "Wenn die LokX jetzt dort den Melder auslöst, dann lass diese die Pfeife bedienen. Wenn LokY hier den Melder auslöst, lass sie halten. Wenn LokZ den Melder auslöst lass sie schneller/früher halten." usw usf

---

Prinzipiell unbestritten - wobei, je nach Ausführung der Software, sie einiges an (anlagenseitiger) Hardware durch Rechenleistung substituieren kann.
Wenn ein Programm, das Loks einmisst und darum ihre Position zu jedem Moment auf einen Millimeter genau berechnen kann, an einem bestimmten Punkt auf der Anlage eine Funktion auslösen soll, dann reicht es aus, diesen Punkt zu definieren; das Programm errechnet aus den ihm zur Verfügung stehenden Daten (speziell Geschwindigkeitsstufen) präzise, wann die Funktion ausgelöst werden muss, weil die entsprechende Lok sich am richtigen Punkt befindet. Natürlich erfordert das einen entsprechend leistungsfähigen Rechner, man stelle sich das für 40 gleichzeitig fahrende Züge vor...

Zitat

---

Was ich auch nicht ganz nachvollziehen kann ist, warum du der Meinung bist, das Protokoll hätte nichts mit einer Entlastung des Datenbus zu tun. :
Im Fall des C-Digital, sieht man doch in meiner Auflistung deutlich, dass sich eine Entlastung ergibt, weil es eine bestimmte Informationsstruktur und Informationsübertragung im Protokoll gibt.

---

Im ersten Semester sagte uns ein Prof: "Seien Sie vorsichtig, wenn Sie auf Formulierungen treffen wie 'wie jedermann erkennt' oder auch 'ganz offensichtlich' oder 'ohne jeden möglichen Zweifel' - das sind Indikatoren für eine ganz schwache Argumentation, die sich auf wenig Fakten stützt." Er hatte bisher noch immer Recht... und hier hast du die falschen Vergleichsparameter.
Die Entlastung stimmt, wo - Modell 2 - der PC die komplette Berechnung der Bremskurve übernimmt und deshalb eine ganze Reihe von Fahrstufenbefehlen senden muss.
Im Modell 1 stimmt die Entlastung nicht. (Jeweils mit C-Digital verglichen.) Denn ob ich einen Befehl sende, der den Flag Langsamfahrt enthält, oder einen (1!) Befehl mit einer veränderten Fahrgeschwindigkeit, macht keinen großen Unterschied.

Mahlzeit Erich,

Entschuldige, aber wir scheinen wirklich in zwei verschiedene "Sprachen" zu sprechen. Glaub mir, das ist nicht meine Absicht.
Danke für die ganzen Links zu Rocrail. Ich habe mich damit bis jetzt noch nicht so stark auseinandergesetzt. Aber das kommt noch Dann kann ich evtl. auch noch was konkret zum "Vergleich" der Philosophien bzw. der Umsetzung verschiedener funktionaler Wünsche bei der Mobasteuerung beitragen.

Zunächst aber gleich noch einmal hierzu:
[quote="Erich Müller" post_id=1827397 time=1525080514 user_id=26147]

Zitat

---

Was ich auch nicht ganz nachvollziehen kann ist, warum du der Meinung bist, das Protokoll hätte nichts mit einer Entlastung des Datenbus zu tun. :
Im Fall des C-Digital, sieht man doch in meiner Auflistung deutlich, dass sich eine Entlastung ergibt, weil es eine bestimmte Informationsstruktur und Informationsübertragung im Protokoll gibt.

---

... hier hast du die falschen Vergleichsparameter.
Die Entlastung stimmt, wo - Modell 2 - der PC die komplette Berechnung der Bremskurve übernimmt und deshalb eine ganze Reihe von Fahrstufenbefehlen senden muss.
Im Modell 1 stimmt die Entlastung nicht. (Jeweils mit C-Digital verglichen.) Denn ob ich einen Befehl sende, der den Flag Langsamfahrt enthält, oder einen (1!) Befehl mit einer veränderten Fahrgeschwindigkeit, macht keinen großen Unterschied.
[/quote]
Ich verstehe, und du hast absolut recht, für das von dir genannte - Modell 2- gilt diese Entlastung nicht! Das war aber auch nicht der Kern meiner Aussage, wann und wo so eine Entlastung zu Tage tritt, sondern was dafür größten Teils verantwortlich ist, wenn diese Entlastung zu Tage tritt.
Außerdem habe ich in meinem Vergleich ja auch nicht dein - Modell 2- herangezogen, sondern eines, wo die Lok eben über jede FS direkt an der Software hängt. BBT kannte ich doch nicht.


[quote="Erich Müller" post_id=1827397 time=1525080514 user_id=26147]
Soweit ich die Landschaft da überblicke, gibt es für die grundlegende Zugsteuerung (also fahren und halten) zwei Modelle:

1. das ältere, mit zwei oder mehr Meldern im Block. Hier wird auf die Beschleunigungs- und Verzögerungseinstellungen des Decoders zurückgegriffen, sofern vorhanden. Wenn der Zug den ersten Melder auslöst in dem Block, in dem er halten soll, dann wird ein Befehl mit verringerter Geschwindigkeit ausgelöst: nach dem 1. Melder bremst der Zug auf eine mittlere Geschwindigkeit ab, nach dem 2. Melder auf langsamste Fahrt und nach dem 3. auf Halt. Bei nur zwei Meldern bremst der Zug ab dem ersten Melder auf langsamste Fahrt ab.
   Das funktioniert mit allen Loks, sobald sie auf die Anlage gestellt wurden. Allenfalls können stufige Bremskurven entstehen, wenn die Decoderbremsung deutlich schneller erfolgt als die Fahrzeit zwischen zwei Meldern.
2. das neuere Modell, mit nur einem Melder im Block (mehr sind möglich, aber nicht notwendig). Hier wird auf die Verzögerungseinstellung des Decoders verzichtet und die Software errechnet die Bremskurve. Dazu ist zwingend notwendig, dass der Software exakt der Abstand bekannt ist zwischen dem Punkt, an dem der Melder auslöst, und dem gewünschten Haltepunkt des Zuges, und außerdem die exakte Geschwindigkeit der Lok bei jeder verwendeten Fahrstufe. Das Modell setzt also zwingend voraus, jedes verwendete Triebfahrzeug vor dem Einsatz "einzumessen".
   Einmessen bedeutet: für jede Fahrstufe wird genau gemessen, wie schnell das Fahrzeug sich tatsächlich bewegt. Das kann mit zwei genügend weit entfernten Messpunkten geschehen, so wie du es oben beschreibst, oder auch auf dem Rollenprüfstand. Da geregelte Decoder bei konstanter Gleisspannung reproduzierbar die gleiche Geschwindigkeit bei gleicher FS einregeln, kann man mit dieser Information sehr präzise Weg-Zeit-Diagramme erstellen und damit arbeiten.
   Theoretisch würde dieses System, einmal kalibriert, ohne jede weitere Hardware am Gleis funktionieren. Dass man trotzdem Melder verwendet, dient zur laufenden Rekalibrierung des Systems, weil nun mal im Fahrbetrieb Störfaktoren auftreten - ich nenne das einfach mal "Schlupf", die bei längerem Betrieb doch einen deutlichen Versatz zwischen theoretischer und realer Position erzeugen.

Hallo Erich,

Echt klasse von dir, die Links zu nennen. Das macht es mir viel viel leichter zu verstehen was du kennst, wovon du redest und damit letzten Endes zu verstehen was du mir sagen willst.

Ich habe mich nun interessiert ein wenig durch die Internetseiten von Rocrail gelesen und hoffe, nun zu einigen deiner Themen exakter Stellung beziehen zu können. Danke!

Ich versuche die Zitate in Grenzen zu halten...


[quote="Erich Müller" post_id=1827397 time=1525080514 user_id=26147]
Man kann auch die Höchstgeschwindigkeit in km angeben und einer Fahrstufe zuordnen (beispielsweise Vmax=120km/h, FS2 und die anderen Geschwindigkeitsstufen dann in km/h angeben, die das Programm - von einer linearen Decodereinstellung ausgehend - in FS umsteht: Vmin=5km/h, Vmid=40km/h, Vcruise=95km/h.
[/quote]Hey, das hört sich so ähnlich an wie bei der Konfiguration der Fahrstufenkurve bei meinen Decodern.
Durch eine Messung bekommt man die reale GS bei FS31. Sollte diese zu hoch sein, wie meistens, justiert man prozentual nach. Die GS bei FS1 lässt sich gesondert relativ fein einstellen und der Rest der FS-GS-Zuordnung ergibt sich aus dem Kurvenverlauf. Eine Liste aller FS und der zugehörigen GS kann man sich anzeigen lassen. Damit kann man auch die Geschwindigkeit für Langsamfahrt und Rangierfahrt für den Decoder festlegen.
Das gilt jetzt in meinem Fall dann natürlich wirklich fahrzeugspezifisch und ist von dem "Steuergerät" unabhänig (gilt bei Fahrt vom Handregeler ebenso wie wenn man mit Software fährt).
Einfach auch desshalb, weil für mein Verständniss Dinge wie eine Maximalgeschwindigkeit, Beschleunigungsverhalten, Fahrstufenverlauf usw. alles Eigenschaften einse Fahrzeuges sind, die dann auch dort hingehören.

(Thema BBT & autom. Halt)
Ich habe mich ein wenig eingelesen und meine es verstanden zu haben. Bitte um Korrektur, fals ich wo falsch liege.
Hier wird also eine Lok mit einer definierten Anzahl an Schritten, in welchen die FSen herabgesetzt werden, bis zu einem Meldepunkt "in" zum Stehen gebracht.
Das ist etwas was mir nicht gefallen würde, eben weil hier mehrere FSen-Befehle in bestimmten Zeitintervallen zum Decoder geschickt werden müssen, bis man bei FS0 angekommen ist.

Das unterscheidet sich von der Umsetztung deutlich von C-Digital, ist aber von der Idee vielleicht garnicht so unähnlich.
Bei C-Digital wird im Decoder für eine Lok ein Anhalteverhalten eingestellt. Dieses kann für einen nahezu konstanten Bremsweg (Bremsstärke während des Bremsens ist adaptiv) oder konstante Bremsstärke (Bremsweg variiert mit Anfangsgeschwindigkeit) sorgen. Damit ist es möglich ein realistisches Bremsverhalten für eine Lok einzustellen.
Bei Softwaresteuerung kann man auch zusätzlich die Zeit, ab wann das "Halt" gesendet und damit dieser Bremsvorgang im Decoder ausgelöst wird, lokspezifisch einstellen. Somit kann eine Lok(x) in Abschnitt(A) aus FS(n) nach 89cm zum stehen kommen, wärend sie das in Abschnitt(B) aus FS(n) nach 100cm tut. Bei anderer EintrittsFS könnte das nun tortzdem mit gleicher Bremsweglänge erfolgen, wenn im Decoder so definiert.
Meine Decoder bremsen hier aber nicht einfach linear - das kann ja jeder - sie bremsen adaptiv, verändern also die "Bremskraft" wärend des Bremsvorgangs.

Das gleiche gilt im Übrigen auch für meine Decoder beim Beschleunigen. Es wird nicht einfach linear beschleunigt, weil das in echt auch nicht so ist. Es geschieht einstellbar sigmoidal.


[quote="Erich Müller" post_id=1827397 time=1525080514 user_id=26147]

Zitat

---

- Wenn die Lok(x) nun im Abschnitt(A) zum Halten gebracht werden soll. Was sendet dann Rocrail an die Zentrale und was geht von der Zentrale zum Decoder?

---

Auch hier verweise ich gern auf die entsprechende Rocrail-Wiki-Seite. http://wiki.rocrail.net/doku.php?id=sens..._3_rueckmeldern
[/quote]Ich stelle fest, dass auch das vom Konzept her dem alten und neuen C-Digitalsystem relativ ähnlich ist.
Es gibt eine Einstellung im Decoder - hier die ABV -, die für den Verlauf des FS-Dekrementierens verantwortlich ist. Zusätzlich wird der Bremsprozess dann von der Software in 2 bis 3 Abschnitte unterteilt, damit die Software eine bessere Kontrolle über das Bremsen, die Bremsweglänge usw. bekommt.
Damit geschieht das Bremsen halt Stufenweise und linear. Es kann also sein, dass der eigentliche Bremsprozess der Lok immer wieder unterbrochen wird.

Wie geschildert ist das bei mir etwas anders:
Bei mir ist der Bremsprozess nicht in mehr als 1 Abschnitt "unterteilt" und der Prozess läuft immer aus einem Guss.
Dann ist für das Dekrementieren der FS nicht die ABV sondern die Signalhalt-Einstellungen im Decoder verantwortlich.
Für diese ergeben sich viele Einstellungsmöglichkeiten und das Bremsen muss auch nicht linear geschehen.


[quote="Erich Müller" post_id=1827397 time=1525080514 user_id=26147]

Zitat

---

- Ist die ABV im laufenden Betrieb (also während des Anfahrens, oder Bremsens) veränderbar?

---

Im Prinzip nein. Mit BBT wird sie von einem "Lok x kommt in Block A an" zum nächsten dynamisch angepasst, aber ansonsten nicht. Die BBT-Bremsung ist auch immer linear gedacht zwischen Geschwindigkeit bei Eintritt in den Block und Vmin.[/quote] Das BBT bremst laut Schematic und Youtube-Videos linear-unterbrochen. Da wird doch nicht wirklich die ABV dynamisch angepasst (wahrscheinlich lassen das die DCC-Decoder auch nicht zu : ), sondern nur "küstlich" von der Software in die Länge gezogen, indem man die ABV stufenweise einsetzt, wartet und dann die nächst Stufe herunterbremsen lässt, bis auf FS0.

Wie gesagt, brauche ich bei C-Digital die ABV nicht für den Signalhalt/autom. Halt. Die ABV ist für das Beschleunigen immer verantwortlich, egal ob Manuell- oder Automatikbetrieb und kann Situationsbedingt (Beladener Zug unbeladener Zug) im Betrieb mehrstufig verändert werden.
Beim manuellen Betrieb beim Bremsen ermöglicht es einem Spieler, der von Hand einen Zug bremst, die Bremskraft beim Bremsen zu dosieren.
(Mir macht das Spaß, auch wenn es zu Beginn etwas Übung braucht )



(Fahrstufenzahl und Zahl der Funktionen)
[quote="Erich Müller" post_id=1827397 time=1525080514 user_id=26147]
Die Zentrale muss auch alle Funktionen kennen; bei Rocrail kann es ausreichen, wenn ich die Funktionen übermittle, die das Programm auch nutzt: Licht, Horn oder Pfeife, automatische Kupplung, Motorgeräusch (das schalte ich z.B. im Tunnel automatisch aus) - und Rangierfunkgespräche oder solche Sachen, die das Programm ohnehin nicht auslösen soll, braucht es nicht zu wissen.[/quote]Das ist auch klar. Die Anzahl der FSen die eine Software intern verwendet, wäre für mein System auch egal, solage deren Anzahl >=31 sind. Man muss dann dem C-Digital-Interface nur mitteilen, wie viele Bits für die FS verwendet werden. Den Rest erledigt dann das Interface und skaliert das auf C-Digital.



(Automatik- Halbautomatikbetrieb)
Ich stelle hier fest, dass folgendes, was bei mir möglich ist in Rocrail nicht geht:

Folgendes Szenario:
Ich stelle mir in der Software einen vollautomatischen Betrieb ein. Manche Züge dürfen nur bestimmte Strecken fahren, nur an bestimmten Stellen halten, an bestimmten Stellen nur best. Geschwindigkeiten fahren, Züge werden durch Zufallsprinzip mit anderen aus dem Schattenbahnhof immer wieder einmal getauscht etc.

- Ich starte nun die Anlage, die Software läuft, es gibt nicht zwingen einen Bildschirm o.ä. (v.a. nicht, wenn auch ein oder mehrere BSW vorhanden sind.) und die eingestellte Automatik läuft, z.B. auf einem Raspberry.

- Ich (und evtl. noch andere) sehe/n den Zügen zu, wie diese von der Software herumdirigiert werden und gelegentlich einer für längere Zeit im SB verschwindet und dafür ein "neuer" auftaucht.

- Einer oder mehrere der Zuschauer möchte nun einen bestimmten Zug selbst etwas herumfahren. Also werden Handregler an die Fahrer verteilt, die gewünschten Loks darauf adressiert und der Betrieb geht einfach so weiter.

• Die anderen Züge bekommen weiter ihre FS vorgeschrieben
• Auch die Manuellen bekommen weiterhin ein "Halt" vorgeschrieben, wo der Fahrer selbst im Moment entscheiden kann, ob er selbst darauf reagieren, oder dies lieber dem Decoder überlassen möchte.

Vorab: Abschnitte in kleinerer Schrift enthalten Randgedanken, die ihr nicht unbedingt kommentieren müsst - einfach weil ich daran denken musste und denke, vielleicht hilft es zur Illustration meiner verqueren Gedankenwege. Aber es führt wohl nicht weiter zum Verständnis dessen, was wir diskutieren.

Hallo Klaus,

Zitat

---

Außerdem habe ich in meinem Vergleich ja auch nicht dein - Modell 2- herangezogen, sondern eines, wo die Lok eben über jede FS direkt an der Software hängt. BBT kannte ich doch nicht.

---

Richtig, hast du nicht. Aber ich meine, das verfälscht das Bild. Denn es ist ja eben nicht zwingend notwendig, dass die "Intelligenz hinter der Zentrale", ob PC oder Anwender, die Lok von Hand Stufe für Stufe abbremst; das kann die im DCC-Decoder (oder dem anderer Protokolle, das ist ja auch nicht protokollabhängig) integrierte ABV prinzipiell auch. Was eine PC-generierte Bremsung kann, und mit der integrierten ABV nicht möglich ist: unabhängig von der Länge der Anhaltestrecke und der Eintrittsgeschwindigkeit der Lok eine homogene und punktgenaue Bremsung hinlegen.
Kann C-Digital das, und was braucht es dazu?

Zitat

---

Dein - älteres Modell - habe ich in meiner Gegenüberstellung ja auch nicht benutzt, da ich es so beschrieben habe, dass ein Melder durch LokX ausgelöst wird und die Software dann nach einer vordefinierten Kurve FS für FS die Lok zum Stehen bringt. Über diese, in der Software vordefinierten Kurve, kann ich doch relativ genau bis zu einem bestimmten Punkt halten. Die Kurve gibt ja praktisch eine Zeit von FS(X) zu FS(X-1) vor. Also ein gezieltes Bremsverhalten, was zum Stillstand nach einer konkreten Strecke führt. Dafür muss die tatsächliche Streckenlänge garnicht mit einer Maßangabe vorhanden sein. Wenn die Lok 5cm zu früh stehen beleibt, streckt man die Bremskurve etwas, bis es passt.
Evtl. könnte man es so vergleichen, dass man die ABV zum Bremsen so verändert, bis sich aus FS(X) die gewünschte Bremsweglänge einstellt.
Das könnte man z.B. machen. Dann würde es genügen, von der Software aus einfach FS0 zu schicken und die eingestellte ABV sorgt dann dafür, dass die Lok nach Xcm steht.

---

"Konstante Bremswege" gibt es z.B. bei Esu, wenn ich richtig weiß. (Ich bin kein Fan der Neu-Ulmer Marke.) Damit wird ein immer gleicher Bremsweg erreicht vom Moment, wo der FS0-Befehl (oder auch der Bremsbefehl des Bremsbausteins, ABC beispielsweise) beim Decoder ankommt bis zum Stillstand. Einige Kollegen verwenden das wohl, indem sie vor allen Signalen exakt die gleiche Länge der Bremsstrecke einbauen.
Die dynamische Anpassung je nach Block kenne ich jetzt nur von BBT - oder eben von den komplett PC-errechneten Bremsungen, die aber die Wegstrecke zur Berechnung als bekannte Größe benötigen. In beiden Fällen geschieht die Berechnung nicht im Decoder:

Zitat

---

Ohne die ABV (von dem ich hier ausgegangen bin) muss die Software quasi über eine Kurve für die "ABV" sorgen.
So oder so ist dann nämlich nur ein Meldeereigniss zum Halten notwendig, wie bei C-Digital. Sonst kann ich ja schon garnicht vergleichen, wenn ich in der Anlage gefühlt 3, 4 oder 5 mal soviel Hardware - also Rückmelder - benötige.

---

Es kommt darauf an, was man vergleichen will: einen Funktionsablauf oder den Hardwareaufwand.
Rocrail kennt übrigens auch die Möglichkeit, mit einem "virtuellen" Melder zu arbeiten, der nur aus der seit Auslösen des Eingangsmelders vergangenen Zeit berechnet wird. Sehr präzise ist das aber nicht, und wenn man es lokspezifisch einstellen will, wird es seeeeeeeeehhhhhhhhhhhhhhhhhhhhr aufwendig.

Zitat

---

Bei C-Digital liegt das Anhalteverhalten im Decoder, weil dies ja aus einer Steuerung kommt, die auch komplett ohen PC oder eben zusätzlicher Software das alles schon können muss.

---

Richtig, und an der Stelle wird es auch höchst interessant.
Ich habe die PC-Steuerung gewählt, obwohl die Anlagengröße eigentlich für "manuell gesteuert plus eventuell Schattenbahnhofssteuerung" spricht; damit hätte ich sogar die sichtbaren Weichen in analoger Steuerung halten können. Aber ich wollte Funktionalitäten ausnutzen, die m.W. nur der Rechner herstellen kann, mit automatischen Rangierabläufen etc.
Ob C-Digital da hätte "mitbieten" können, weiß ich nicht. Dazu kommt, dass einige meiner Fahrzeuge bereits mit Decodern ausgestattet waren, auf die ich schon aus wirtschaftlichen Gründen nicht so einfach verzichten konnte.

Zitat

---

Und die interne FS interessiert vielleicht nicht quantitativ, aber doch in der Wirkung nach außen sehr wohl. Klar ist der "Wert" eigentlich uninteressant, zumindest für einen Spieler.

---

Schon. Hier sind wir aber meiner Ansicht nach in einer Ecke, die weniger dem Vergleich zwischen Protokollen zugehört als dem Vergleich verschiedener Konzeptionen des Decoders - so wie D&H, wenn ich es richtig verstehe, einen ganz anderen Ansatz hat als esu, und andere noch wieder andere Prinzipien verfolgen können.

Zitat

---

Ja, und genau so eine Lösung gefällt mir aus vielen Gründen überhaupt nicht. Eine Steuerung, die zu sehr von hypotetischen, simulierten Daten ausgeht, ist für mich keine richtige Steuerung. Das stört mich eben genauso wie: LokX müsste das jetzt sein, die diesen Melder(B) ausgelöst hat, weil ich (das Programm) sie nach (B) geschickt habe. Ich möchte aus diesem und anderen Gründen eine Belegtmeldung mit integriertem Railcom, was bei mir auch schon funktioniert.

---

Da kann und soll jeder selbst entscheiden, was ihm wichtig ist. In "meinem" Ausgangssystem, nämlich Märklin-basiert, ist Railcom nicht vorgesehen. Meine Zentrale "kann" das zwar, aber ich besitze zur Zeit keinen Decoder, der es "könnte". Ich sehe allerdings auch, dass zumindest in meiner kleinen Anlagenwelt schon einiges zusammenkommen muss, damit ein Zug unbemerkt ins falsche Gleis fährt. Das liegt sicherlich auch an der Struktur von Rocrail mit zwei (oder mehr) Meldern pro Block, wo eben auffällt, wenn ein Block von der falschen Seite angefahren wird. Das kann ich mir aber leisten, weil "mein" System wiederum eine sehr kostengünstige Meldetechnik ermöglicht, nämlich den Gleisstromkreis. Mit einem s88-3-Baustein von tams habe ich Kosten von 1,05€ (Bausatz) bis 2,20€ (Fertigbaustein) pro Meldepunkt.
Railcom wäre wesentlich teurer, und sicherlich um mehr als den Faktor 2. Dazu kommt, dass ein Railcom-Melder auch einen Moment braucht, bis er eine Lok identifiziert hat und diese Info zurückgeben kann. Ich meine was von ein bis zwei Sekunden gelesen zu haben.
Es gibt auch andere Systeme, die quasi mit einem Hardware-Addon funktionieren, ob es RFID-Leser sind (sehr schnell) oder Barcode-Leser, oder auch Uhlenbrocks Lissy. Ich sehe bisher, dass meine Installation stundenlang fehlerfrei funktioniert, und bin deshalb der Ansicht, mehr brauche ich nicht: es würde mir keinen Mehrwert geben.
Aber wie gesagt: das gilt für mich, und ich will keinesfalls unterstellen, den Stein der Weisen gefunden zu haben. Und ich bin mir auch bewusst, dass ich da mit Ablaufsprinzipien arbeite, die schon einige Jahre alt sind.
Ein System mit automatischer Zugidentifizierung würde ich beispielsweise sehr begrüßen, wenn ich eine Anlage mit zwei Themen hätte, einer Hauptstrecke mit Bahnhof und einem BW beispielsweise. Ich könnte Loks im BW manuell steuern und dann an die Automatik übergeben, die sie schlicht durch Idenfitikation der im BW-Ausfahrgleis stehenden Lok übernimmt.

Hallo Martin,

Zitat

---

Hey, das hört sich so ähnlich an wie bei der Konfiguration der Fahrstufenkurve bei meinen Decodern.
Durch eine Messung bekommt man die reale GS bei FS31. Sollte diese zu hoch sein, wie meistens, justiert man prozentual nach. Die GS bei FS1 lässt sich gesondert relativ fein einstellen und der Rest der FS-GS-Zuordnung ergibt sich aus dem Kurvenverlauf. Eine Liste aller FS und der zugehörigen GS kann man sich anzeigen lassen. Damit kann man auch die Geschwindigkeit für Langsamfahrt und Rangierfahrt für den Decoder festlegen.
Das gilt jetzt in meinem Fall dann natürlich wirklich fahrzeugspezifisch und ist von dem "Steuergerät" unabhänig (gilt bei Fahrt vom Handregeler ebenso wie wenn man mit Software fährt).
Einfach auch desshalb, weil für mein Verständniss Dinge wie eine Maximalgeschwindigkeit, Beschleunigungsverhalten, Fahrstufenverlauf usw. alles Eigenschaften einse Fahrzeuges sind, die dann auch dort hingehören.

---

Das klingt wiederum für mich hoch interessant und kommt meinem eigenen Denken einen großen Schritt weit entgegen. Höchstgeschwindigkeit, Beschleunigungsverhalten etc. gehören für mich ins Fahrzeug.
Dazu kommt dann aber auch wieder, dass das Fahrzeug eine Strecke befährt, die ihre eigenen Grenzwerte vorgibt: Streckenhöchstgeschwindigkeit, signalisierte Langsamfahrstellen. Signalisierte Geschwindigkeit bei Einfahrt in den Bahnhof, von 60 oder 40 oder 30 oder auch stellenweise noch weniger. Und das ist nicht fahrzeugspezifisch, das unterliegt der Aufmerksamkeit des Lokführers.
Schließlich ist die Dynamik des Zuges zu berücksichtigen, die wir auf der Modellbahn nur simulieren können: einen 1000t-Zug in der 1%-Steigung anfahren ist ein langwieriges Unternehmen, im Gefälle geht es schneller. Die Bremswirkung des Zuges hängt von seiner Konfiguration ab...
Das kann man nur schwer alles in den Decoder programmieren. Hier hat, denke ich, im Automatikbetrieb ein PC mit "Streckenkenntnis" die Nase vorn. Aber das kann und will eine nicht vollautomatisierte Steuerung ja wahrscheinlich auch gar nicht abbilden (von der Beschleunigungsrate vielleicht abgesehen).

Jedenfalls schätze ich Decoder, die ich fein, aber vernünftig einstellen kann. Ich habe schon Uhlenbrock- und esu-Decoder nach der für den Uhlenbrock-76200 hier im Forum veröffentlichten Anleitung eingestellt, das ist mit den mir zur Verfügung stehenden Mitteln ziemlich langwierig gewesen. Meine neuen Märklin-Decoder machen das Einstellen auf den Motor automatisch, denen gebe ich nur noch die Höchst- und Mindestgeschwindigkeit sowie die Verzögerungsfaktoren ein. (Funktionssteuerung nicht einbezogen, das ist ein eigenes Thema.)

Zitat

---

(Thema BBT & autom. Halt)
Ich habe mich ein wenig eingelesen und meine es verstanden zu haben. Bitte um Korrektur, fals ich wo falsch liege.
Hier wird also eine Lok mit einer definierten Anzahl an Schritten, in welchen die FSen herabgesetzt werden, bis zu einem Meldepunkt "in" zum Stehen gebracht.
Das ist etwas was mir nicht gefallen würde, eben weil hier mehrere FSen-Befehle in bestimmten Zeitintervallen zum Decoder geschickt werden müssen, bis man bei FS0 angekommen ist.

---

Das ist so richtig verstanden. Immerhin handelt es sich nur noch um etwa fünf bis fünfzehn Fahrstufenbefehle, wo ein PC, der die Bremskurve berechnet, bis zu 127 Befehle sendet (wenn man von Einfahrt mit höchster Fahrstufe ausgeht). Aber ja, die zu sendende Datenmenge ist höher als bei deinem System, und Rob (der Rocrail-Kopf) empfiehlt auch, BBT in Blöcken nicht zu verwenden, die man nicht sieht. Damit man weniger Rechenleistung und Datentraffic verursacht.
Für die Beschleunigung freilich setzt Rocrail komplett auf die Decodereinstellung, hier wird nur ein Befehl für die Zielfahrstufe gegeben (gegebenenfalls abgestuft, falls eine Weichenstraße mit verringerter Geschwindigkeit befahren werden soll). Das Verhalten eines Lokführers ist da natürlich auch nur sehr begrenzt nachstellbar, während die Programme, die die Geschwindigkeitsabläufe komplett "fernsteuern", ziemlich weitgehende Möglichkeiten haben.

Zitat

---

Das unterscheidet sich von der Umsetztung deutlich von C-Digital, ist aber von der Idee vielleicht garnicht so unähnlich.
Bei C-Digital wird im Decoder für eine Lok ein Anhalteverhalten eingestellt. Dieses kann für einen nahezu konstanten Bremsweg (Bremsstärke während des Bremsens ist adaptiv) oder konstante Bremsstärke (Bremsweg variiert mit Anfangsgeschwindigkeit) sorgen. Damit ist es möglich ein realistisches Bremsverhalten für eine Lok einzustellen.
Bei Softwaresteuerung kann man auch zusätzlich die Zeit, ab wann das "Halt" gesendet und damit dieser Bremsvorgang im Decoder ausgelöst wird, lokspezifisch einstellen. Somit kann eine Lok(x) in Abschnitt(A) aus FS(n) nach 89cm zum stehen kommen, wärend sie das in Abschnitt(B) aus FS(n) nach 100cm tut. Bei anderer EintrittsFS könnte das nun tortzdem mit gleicher Bremsweglänge erfolgen, wenn im Decoder so definiert.
Meine Decoder bremsen hier aber nicht einfach linear - das kann ja jeder - sie bremsen adaptiv, verändern also die "Bremskraft" wärend des Bremsvorgangs.

Das gleiche gilt im Übrigen auch für meine Decoder beim Beschleunigen. Es wird nicht einfach linear beschleunigt, weil das in echt auch nicht so ist. Es geschieht einstellbar sigmoidal.

---

Mach misch net narrisch, nachher will ich noch alles umstellen auf C-Digital, und dann krieg ich Ärger mit der Müllerin!
Vielleicht hast du gesehen, dass man bei BBT für jede Lok und jeden Block einstellen kann, ob die Verzögerungskurve sofort beginnt oder mit (zeitlicher, nicht räumlicher) Verzögerung. In der Praxis scheint mir das so auszusehen, dass die erste Verzögerungsstufe um die eingestellte Zeit verlängert wird. Davon abgesehen bleibt die Sache natürlich FS-linear, und kommt es für den Endeffekt darauf an, wie die Decoder programmiert sind. (Märklin-Decoder und esu-M4-Decoder sind dem Vernehmen nach nur mit ziemlichen Verrenkungen auf eine genau lineare FS-Kurve zu bringen...)

Zitat

---

Ich stelle fest, dass auch das vom Konzept her dem alten und neuen C-Digitalsystem relativ ähnlich ist.
Es gibt eine Einstellung im Decoder - hier die ABV -, die für den Verlauf des FS-Dekrementierens verantwortlich ist. Zusätzlich wird der Bremsprozess dann von der Software in 2 bis 3 Abschnitte unterteilt, damit die Software eine bessere Kontrolle über das Bremsen, die Bremsweglänge usw. bekommt.
Damit geschieht das Bremsen halt Stufenweise und linear. Es kann also sein, dass der eigentliche Bremsprozess der Lok immer wieder unterbrochen wird.

Wie geschildert ist das bei mir etwas anders:
Bei mir ist der Bremsprozess nicht in mehr als 1 Abschnitt "unterteilt" und der Prozess läuft immer aus einem Guss.
Dann ist für das Dekrementieren der FS nicht die ABV sondern die Signalhalt-Einstellungen im Decoder verantwortlich.
Für diese ergeben sich viele Einstellungsmöglichkeiten und das Bremsen muss auch nicht linear geschehen.

---

Das ist eine für mich unerwartete Herangehensweise - aber interessant. Muss ich mir noch durch den Kopf gehen lassen: Die Lok verhält sich also anders, wenn "Signalhalt" übermittelt wird, als wenn "Fahrstufe 0" übermittelt wird?
Du schreibst oben vom "alten und neuen C-Digitalsystem", etwas später "bei mir". Sind das nun zwei oder drei Konzeptionen?

Zitat

---

Das BBT bremst laut Schematic und Youtube-Videos linear-unterbrochen. Da wird doch nicht wirklich die ABV dynamisch angepasst (wahrscheinlich lassen das die DCC-Decoder auch nicht zu : ), sondern nur "küstlich" von der Software in die Länge gezogen, indem man die ABV stufenweise einsetzt, wartet und dann die nächst Stufe herunterbremsen lässt, bis auf FS0.

---

Richtig. Die decodereigene Einstellung wird nicht angepasst. Die BBT-Stufen sind idealerweise aber so eingestellt, dass der Eindruck einer homogenen Bremsung entsteht.

Zitat

---

Wie gesagt, brauche ich bei C-Digital die ABV nicht für den Signalhalt/autom. Halt. Die ABV ist für das Beschleunigen immer verantwortlich, egal ob Manuell- oder Automatikbetrieb und kann Situationsbedingt (Beladener Zug unbeladener Zug) im Betrieb mehrstufig verändert werden.
Beim manuellen Betrieb beim Bremsen ermöglicht es einem Spieler, der von Hand einen Zug bremst, die Bremskraft beim Bremsen zu dosieren.
(Mir macht das Spaß, auch wenn es zu Beginn etwas Übung braucht )

---

Das erinnert mich jetzt an die "Bremstaste" von zimo, wo (entsprechende Konfiguration des Decoders vorausgesetzt) das Herabsetzen der Fahrstufe nicht zur Bremsung führt, sondern den Zug rollen lässt (mit entsprechender Veränderung des abgegebenen Geräuschs, wo vorhanden), und zum Bremsen muss man eine F-Taste drücken.
Oder auch an die vor Zeiten mal angebotenen und in der Literatur beschriebenen Loks mit Fliehkraftkupplung: wenn man die bremsen wollte, musste man vorsichtig rückwärts-Strom geben.
Ich hatte mal ein Auto mit Fliehkraftkupplung. Gewöhnungsbedürftig, aber letztlich praktisch.
Beim Zimo-System frage ich mich noch, wie man das mit einer Automatik, beispielsweise im Schattenbahnhof, verbinden kann... anderes Thema, nicht hier zu besprechen.

Zitat

---

Hier muss niemand an einem Rechner irgendwas machen, jeder kann auf Wunsch am Geschehen teilnehmen.

---

Ich sehe das als verschiedene Herangehensweisen; grundsätzlich scheint mir, dass man nicht sagen kann, "eins ist besser, eins ist schlechter". Aber man kann natürlich eins bevorzugen.

[/quote]Sollte einer gerne den Fahrdienstleiter an einem Bahnhof spielen wollen und an diesem gibt es ein BSW, so kann auch das eingestellt werden. Die Schaltbefehle für Fahrstraßen und Signale dieses bestimmten BSWs (Anlagenabschnitts) werden dann nicht mehr automatisch an die Hardware-Schaltbaugruppen weitergeleitet, sondern können als Soll-Vorgabe an einem Bildschirm angezeigt werden. (z.B. Gleis 9 nach Gleis 5)
Die Person die den Fahrdienstleiter spielen will, stellt sich dann vor besagtes BSW und muss die Vorgaben der Software erfüllen. Dabei ist es einstellbar, ob einem die Software dann einen möglichen Fehler nur anzeigt und warnt, oder aber autom. korrigiert.
[/quote]

Das ist eine Funktionalität, die in Rocrail m.W. bisher nicht existiert. Wenn man Rob teasert, baut er es vielleicht ein... aber das Programm ist ohnehin schon sehr umfangreich.
Und die Zielsetzungen sind wohl auch verschieden. Viele Nutzer scheinen mir doch die Vollautomatik zu bevorzugen, oder auch den PC als Bildschirmstellwerk mit Fahrstraßeneinstellung und mit oder ohne automatisches Fahren der Züge. Man kann ja auch Rocrail ohne Zugüberwachung verwenden, dann muss man die Fahrstraßen manuell wieder auflösen wie der Fahrdienstleiter auf dem älteren Stellwerk.

Fazit, sehr vorläufig:
Ich bin beeindruckt von dem, was C-Digital alles ermöglicht. Es ist schade, dass es so ein Nischendasein führt. Schade auch, dass wenig Dokumentation dazu verfügbar ist - also die, die den Nutzer interessiert, nicht so sehr die technische Dokumentation für Ingenieure. Ich habe eine schwache Erinnerung an alte Conrad-Kataloge, wo was drin stand, noch mit dem "alten" System, aber damals war für mich Digitalbetrieb uninteressant, weil viel zu teuer, und heute ist eben der Markt zu fast 100% von den zwei, drei großen Protokollen beherrscht, die eben entweder von den Fahrzeugherstellern selbst entwickelt wurden (Märklin) oder zumindest als Standard angesehen werden, für den man dann auch die ab Werk eingebauten Decoder auslegt.

Guten Abend Erich,

[quote="Erich Müller" post_id=1828541 time=1525341165 user_id=26147]
Dazu kommt dann aber auch wieder, dass das Fahrzeug eine Strecke befährt, die ihre eigenen Grenzwerte vorgibt: Streckenhöchstgeschwindigkeit, signalisierte Langsamfahrstellen. Signalisierte Geschwindigkeit bei Einfahrt in den Bahnhof, von 60 oder 40 oder 30 oder auch stellenweise noch weniger. Und das ist nicht fahrzeugspezifisch, das unterliegt der Aufmerksamkeit des Lokführers.
[/quote]
Für die Langsamfahrt, welche man bspw. für die Bahnhofseinfahrt wählt, gibt es bei C-Digital nur einen Wert pro Decoder. Es ist ohne zusätzliche Software also nicht möglich in den einen Bahnhof autom. bspw. mit 40 einzufahren und in einen anderen mit 60.
Die alten Decoder kannten leider auch noch keine Langsamfahrt.

[quote="Erich Müller" post_id=1828541 time=1525341165 user_id=26147]
Schließlich ist die Dynamik des Zuges zu berücksichtigen, die wir auf der Modellbahn nur simulieren können: einen 1000t-Zug in der 1%-Steigung anfahren ist ein langwieriges Unternehmen, im Gefälle geht es schneller. Die Bremswirkung des Zuges hängt von seiner Konfiguration ab...
[/quote]Ganz genau, so sehe ich das auch. Darum habe ich es bei den neuen Decodern so gemacht, dass sich die Beschleunigungskurve aus dem "Traktionsverhalten" eines realen Zuges ergibt und man praktisch die angehängte Last in 100 Tonnen Schritten einstellen kann. (von <100t bis 3000t)

[quote="Erich Müller" post_id=1828541 time=1525341165 user_id=26147]
Das kann man nur schwer alles in den Decoder programmieren. Hier hat, denke ich, im Automatikbetrieb ein PC mit "Streckenkenntnis" die Nase vorn. Aber das kann und will eine nicht vollautomatisierte Steuerung ja wahrscheinlich auch gar nicht abbilden (von der Beschleunigungsrate vielleicht abgesehen).
[/quote]Naja, das kommt darauf an. Eine Streckenkenntnis lässt sich nicht in den Doceder programmieren, das ist klar.
Wie sich die Traktion bei einer bestimmten Masse-Einstellung in bestimmten Steigungen zu verändern hat, weis mein Decoder aber schon. Eine Steigungsänderung bekommt der Decoder, respektive die Lastregelung mit und mit der Einstellung der "Zugmasse" und der Traktionskurve, die das Beschleunigungsverhalten bestimmt, kann der Decoder entsprechend reagieren.
Zusätzlich lässt sich die Beschleunigung auch am Handregler 5-stufig vom Steuergerät während des Betriebs noch beeinflussen. Wie erwähnt, ich nutze das gerne zum aktiven Bremsen.

[quote="Erich Müller" post_id=1828541 time=1525341165 user_id=26147]
Meine neuen Märklin-Decoder machen das Einstellen auf den Motor automatisch, denen gebe ich nur noch die Höchst- und Mindestgeschwindigkeit sowie die Verzögerungsfaktoren ein. (Funktionssteuerung nicht einbezogen, das ist ein eigenes Thema.)[/quote]
Bei meinem Decoder kann man "nur" die Vmax (in %), die Vmin (direkt) und die Krümmung der FS-Kurve einstellen. Also 3 Parameter oder "CVs", wie man das bei DCC nennt.
Die Beschleunigung, also Traktion, ist ein anderes Thema.

[quote="Erich Müller" post_id=1828541 time=1525341165 user_id=26147]
Aber ja, die zu sendende Datenmenge ist höher als bei deinem System, und Rob (der Rocrail-Kopf) empfiehlt auch, BBT in Blöcken nicht zu verwenden, die man nicht sieht. Damit man weniger Rechenleistung und Datentraffic verursacht.
[/quote]
Ja, dieses Problem kenne ich. Wie auch schon erwähnt, fersuche ich den Informationsfluss so gering wie möglich zu halten, damit bei größeren Anlagen und einer großen Anzahl an gleichzeitig fahrenden Fahrzeugen alles reibungsfrei läuft.


[quote="Erich Müller" post_id=1828541 time=1525341165 user_id=26147]
Das Verhalten eines Lokführers ist da natürlich auch nur sehr begrenzt nachstellbar, während die Programme, die die Geschwindigkeitsabläufe komplett "fernsteuern", ziemlich weitgehende Möglichkeiten haben.
[/quote]Für mein Verständnis steht diese Methode in keiner Relation zum Nutzen / Effekt.



[quote="Erich Müller" post_id=1828541 time=1525341165 user_id=26147]
Mach misch net narrisch, nachher will ich noch alles umstellen auf C-Digital, und dann krieg ich Ärger mit der Müllerin! [/quote]
Für dich gilt das gleiche, was ich schon Stephan geschrieben habe, denke ich. Ein Umstieg, von einem bereits so ausgebauten und komplexen System, lohnt sich kaum - glaube ich.
Man müsste ja auch praktisch fast alles Tauschen (auch die ganzen Decoder).

Das Bremsen, soll bei meinen Decodern desshalb nicht ausschließlich linear funktionieren, weil ich finde, dass es dann noch realistischer aussieht. (Der Decoder startet das Bremsen mit der definierten Bremskarft in einem Moment, sondern erzeugt einen sanften übergang in die Bremsung und lässt den Bremsvorgang auch langsam ausklingen. Sollte man diese Adaptivität zu stark einstellen, verlängert sich halt die Anhalteweglänge etwas.)


[quote="Erich Müller" post_id=1828541 time=1525341165 user_id=26147]
Das ist eine für mich unerwartete Herangehensweise - aber interessant. Muss ich mir noch durch den Kopf gehen lassen: Die Lok verhält sich also anders, wenn "Signalhalt" übermittelt wird, als wenn "Fahrstufe 0" übermittelt wird?
[/quote]Exakt. Denn das Anahlteverhalten kann sich auch an einen konstanten Bremsweg unabhängig von der FS zu Beginn des Haltevorgangs einstellen und wird durch andere Bits im Datensignal ausgelöst.
Das "Bremsen" durch die ABV, ist wie in Echt nicht unabhängig von der Fahrstufe zu Beginn der Bremsung. Sie kann auch durch andere Bits im Datensignal im Betrieb beeinflusst werden und hier richtet sich das Bremsen auch immer an die "Masseeinstellung".

[quote="Erich Müller" post_id=1828541 time=1525341165 user_id=26147]
Du schreibst oben vom "alten und neuen C-Digitalsystem", etwas später "bei mir". Sind das nun zwei oder drei Konzeptionen?[/quote] Also es gibt das alte Conrad Digital = altes C-Digital, dann gibt es das alte C-Digital mit entsprechenden Updates und Erweiterungen (hier ist die Basishardware praktisch überall gleich ( Zentrale + Handregler ) und 3 Decoder-Generationen + Interface zum PC. Das neue C-Digital mit Rückmeldung, neuer Zentrale + neuen Handreglern + Abschnittsmodulen und Decoder-Generation 4, ist das woran ich arbeite und welches als "Prototyp-Version" läuft.


[quote="Erich Müller" post_id=1828541 time=1525341165 user_id=26147]
Richtig. Die decodereigene Einstellung wird nicht angepasst. Die BBT-Stufen sind idealerweise aber so eingestellt, dass der Eindruck einer homogenen Bremsung entsteht. [/quote]
Ja, das ist mir auch wichtig, dass das Anhalteverhalten homogen verläuft und man keine "Sprünge" sieht.



[quote="Erich Müller" post_id=1828541 time=1525341165 user_id=26147]
Das erinnert mich jetzt an die "Bremstaste" von zimo, wo (entsprechende Konfiguration des Decoders vorausgesetzt) das Herabsetzen der Fahrstufe nicht zur Bremsung führt, sondern den Zug rollen lässt (mit entsprechender Veränderung des abgegebenen Geräuschs, wo vorhanden), und zum Bremsen muss man eine F-Taste drücken.
[/quote] Auch eine interessante Idee, jedoch etwas anders als bei C-Digital. Es ist 4 oder 5-Stufig einstellbar und beeinflusst das Bremsen und Beschleunigen.
Das senden der FS0 führt bei C-Digital immer zu einer Verringerung der Geschwindigkeit - nur geschieht das eben nicht immer gleich schnell und ist vom Steuergerät aus, im Betrieb veränderbar.

[quote="Erich Müller" post_id=1828541 time=1525341165 user_id=26147]

Zitat

---

Hier muss niemand an einem Rechner irgendwas machen, jeder kann auf Wunsch am Geschehen teilnehmen.

---

Ich sehe das als verschiedene Herangehensweisen; grundsätzlich scheint mir, dass man nicht sagen kann, "eins ist besser, eins ist schlechter". Aber man kann natürlich eins bevorzugen.
[/quote] Absolut. So scheint mir das auch. Ich bau mir mein System natürlich so, weil mir das so gefällt...


[quote="Erich Müller" post_id=1828541 time=1525341165 user_id=26147]
Und die Zielsetzungen sind wohl auch verschieden. Viele Nutzer scheinen mir doch die Vollautomatik zu bevorzugen, oder auch den PC als Bildschirmstellwerk mit Fahrstraßeneinstellung und mit oder ohne automatisches Fahren der Züge. Man kann ja auch Rocrail ohne Zugüberwachung verwenden, dann muss man die Fahrstraßen manuell wieder auflösen wie der Fahrdienstleiter auf dem älteren Stellwerk. [/quote] Da ist doch irgendwie auch verständlich, oder? Ein "BSW" in der Software ist viel billiger und enorm flexiebler, was Änderungen betrifft und bei einer gewissen Anlagengröße, bietet sich zumindest die Option einer Vollautomation doch an - wodurch man dann bei der Software-Lösung landet.


[quote="Erich Müller" post_id=1828541 time=1525341165 user_id=26147]
Ich bin beeindruckt von dem, was C-Digital alles ermöglicht. Es ist schade, dass es so ein Nischendasein führt.
[/quote]Naja, es fristet nichteinmal wirklich ein Nieschendasein, wenn man es genau nimmt. Es existiert nur noch und wird auch nur noch weiterentwickelt, wegen des "verspielten" Interesses an Technik und der Eisenbahn, ein, zwei oder drei Leuten und der Tüftel- und Entwicklungsfreude meiner "Wenigkeit".
Einige Dinge die ich bis jetzt am Markt gesehen hatte, konnten meinen Ansprüchen einfach auch nicht Genüge leisten, - also entwickelt man selber, sofern man kann. Bei C-Digital hatten wir und habe ich einfach ein entwas anderen Gedankengang bezüglich des Konzepts usw..

Schade auch, dass wenig Dokumentation dazu verfügbar ist - also die, die den Nutzer interessiert, nicht so sehr die technische Dokumentation für Ingenieure.
[/quote]Ja, ich weis Mit der Dokumentation ist das immer so eine Sache, die ist mir - ganz ehrlich - relativ lästig. Ich möchte viel viel lieber andere Dinge tun. Und leider kostet gerade die Dokumentation auch ein Haufen Zeit.
Bei mir dauert es desshalb immer sehr lange, bis ein neues verkaufsvertiges Produkt gibt, weil hierfür ja eine Dokumentation vorhanden sein muss.
Weil ich diese oft auch im Alleingang erstelle, fallen diese ggf. manchmal zu technisch aus?
Trotzdem finde ich es schön, dass dich einige Funktionen des C-Digitals ansprechen.

[quote="Erich Müller" post_id=1828541 time=1525341165 user_id=26147]
..., und heute ist eben der Markt zu fast 100% von den zwei, drei großen Protokollen beherrscht, die eben entweder von den Fahrzeugherstellern selbst entwickelt wurden (Märklin) oder zumindest als Standard angesehen werden, für den man dann auch die ab Werk eingebauten Decoder auslegt.
[/quote]
Das könnte und ist teilweise heute für mich schon ein Problem, weil man viele Fahrzeuge garnicht mehr ohne Decoder bekommt. Da zahlt man dann für etwas, was unnötig ist. Auch macht es immer wieder Probleme, dass sich einige Hersteller nicht immer an die Normen der NEM Fahrzeugdecoder-Schnittstellen zu halten scheinen.
So schafft man eben auch eine zusätzliche Markenbindung, die -wie ich finde- für den gesamten Mobamarkt nicht gut ist. Wir sind mit C-Digital hier ja nicht wirklich ein Partizipant des Marktgeschehens und die großen Firmen verfolgen mit ihren Protokollen und anderer Hardware eben ihre eigenen Philosophien einer Modellbahnsteuerung, die sich von der unseren unterscheidet.

Grüße,
Martin

Hallo Erich,

[quote="Erich Müller" post_id=1828541 time=1525341165 user_id=26147]
Richtig, hast du nicht. Aber ich meine, das verfälscht das Bild. Denn es ist ja eben nicht zwingend notwendig, dass die "Intelligenz hinter der Zentrale", ob PC oder Anwender, die Lok von Hand Stufe für Stufe abbremst; das kann die im DCC-Decoder (oder dem anderer Protokolle, das ist ja auch nicht protokollabhängig) integrierte ABV prinzipiell auch.[/quote]
Ja, das stimmt natürlich und das ist im Fall von C-Digital nicht anders. Weil aber doch bei C-Digital das autom. Halten etwas anderes ist, als das einfache Bremsen über die ABV -das habe ich auch ersteinmal verstehen müssen- wollte ich nicht so einen Vergleich ziehen. (Eben auch, weil sonst ein falscher Eindruck entsteht, wie ich meine) Die ABV der mir bekannten Decoder liefert auch keinen konstanten Bremsweg.
Du hast aber total recht, dass so eine Lösung mit 1, 2, 3, oder 4 FS Befehle von der Software, mit Zuhilfenahme der Decoder ABV dem autom. Halten recht nahe kommt -zumindest was die BUS-Auslastung betrifft.

[quote="Erich Müller" post_id=1828541 time=1525341165 user_id=26147]
Was eine PC-generierte Bremsung kann, und mit der integrierten ABV nicht möglich ist: unabhängig von der Länge der Anhaltestrecke und der Eintrittsgeschwindigkeit der Lok eine homogene und punktgenaue Bremsung hinlegen.
Kann C-Digital das, und was braucht es dazu? [/quote]
Das hat Martin im Prinzip schon beantwortet, denke ich.
Bei C-Digital ist die Konstanz der Anhalteweglänge im Decoder einstellbar. Diese Konstanz fällt -im Rahmen des physikalische Möglichen- mit +-2cm ziemlich genau aus. Dieser konstante Anhalteweg gilt für den Decoder fest und damit ist es egal, mit was gesteuert wird.
Benutzt man zum Steuern unter anderem eine Software, so kann die Anhalteweglänge abschnittsweise, lokspezifisch, konstant verlaufaufen. In Abschnitt (A) ist sie bei Lok(x) immer ~60cm und in (B) immer ~82cm, zum Beispiel.
Was dabei aber zu beachten und von Martin nicht explizit erklärt wurde ist, dass der kürzeste Anhalteweg, den ich für einen Abschnitt wählen kann, nur minimal so kurz ausfallen kann, wie der im Decoder eingestellte konstante Anhalteweg.
Das hat einfach damit zu tun, dass im Fall der abschnittsweise abhängigen Anhalteweglänge, die Software "nur" den Zeitpunkt der Sendung für "Halt" herauszögert. Durch diese Verzögerung ergigt sich autom. ein "verlängerter" Anhalteweg.
Nach meinem Verständniss ist das jedoch nicht korrekt bezeichnet, weil der Anhalte- respektive Bremsweg immernoch der gleiche ist und dieser nur örtlich verschoben wird.

Zusätzlich Melder im Gleis, werden hier nicht benötigt. Im Fall ohne Software, genügt schon das reine Umschalten des Bits für "Halt" in einem gewünschten Abschnitt. Mit Software benötigt man die "Abschnittsmodule", die rückmelden können.



[quote="Erich Müller" post_id=1828541 time=1525341165 user_id=26147]
"Konstante Bremswege" gibt es z.B. bei Esu, wenn ich richtig weiß. (Ich bin kein Fan der Neu-Ulmer Marke.) Damit wird ein immer gleicher Bremsweg erreicht vom Moment, wo der FS0-Befehl (oder auch der Bremsbefehl des Bremsbausteins, ABC beispielsweise) beim Decoder ankommt bis zum Stillstand. Einige Kollegen verwenden das wohl, indem sie vor allen Signalen exakt die gleiche Länge der Bremsstrecke einbauen. [/quote]
Ja, ich habe das auch genutzt und tue das auch heute noch größten Teils in Verbindung mit ABC. Ich muss jedoch sagen, dass die "Konstanz" der Bremsweglänge hier schon öffter auch zu wünschen übrig lässt. In besten Fall komme ich knappt unter +-4cm bei einer Lok in etwa 2h Betrieb. Unter +-3cm habe ich bei keiner Lok und einige schwanken mit +-6cm schon sehr deutlich, bei dem "konstanten" Bremsweg.
Ja, der Anhalteabschnitt muss von der Länge her halt mindestens so lang ausfallen, wie der längste Anhalteweg, den man verwendet. Das ist im Fall von C-Digital ohne Software glaube ich genauso, oder?

[quote="Erich Müller" post_id=1828541 time=1525341165 user_id=26147]
Die dynamische Anpassung je nach Block kenne ich jetzt nur von BBT - oder eben von den komplett PC-errechneten Bremsungen, die aber die Wegstrecke zur Berechnung als bekannte Größe benötigen. In beiden Fällen geschieht die Berechnung nicht im Decoder:[/quote]
Ja, ich kenne das auch nur von Softwarelösungen. Ganz einfach auch, weil der Decoder sonst viel zu viel wissen müsste und tun müsste, damit so eine Funktion auch ohne Software läuft. Jedem Decoder müsste dann mitgeteilt werden in welchem Abschnitt er sich gerade befindet, damit er seinen Bremsweg entsprechend einstellen kann. Ich glaube das führt zu einem Supergau im ZentralenBUS und im Decoder.
Garnicht daran zu denken, was passiert, wenn man eine Lok, die auf die heimische Anlage eingestellt ist, auf einer anderen Anlage fährt.

[quote="Erich Müller" post_id=1828541 time=1525341165 user_id=26147]
Es kommt darauf an, was man vergleichen will: einen Funktionsablauf oder den Hardwareaufwand. [/quote]
Oder den Hardwareaufwand in Relation zum Funktionsumfang & Ablauf.
Einfach die Frage: "Was ist bei diesem System notwendig, wenn ich folgende Funktion haben möchte und wie ist das in einem anderen?"

[quote="Erich Müller" post_id=1828541 time=1525341165 user_id=26147]
Rocrail kennt übrigens auch die Möglichkeit, mit einem "virtuellen" Melder zu arbeiten, der nur aus der seit Auslösen des Eingangsmelders vergangenen Zeit berechnet wird. Sehr präzise ist das aber nicht, und wenn man es lokspezifisch einstellen will, wird es seeeeeeeeehhhhhhhhhhhhhhhhhhhhr aufwendig.[/quote]
Das hört sich so an wie bei C-Digital. Warum ist das lokspezifisch bei Rocrail mit so einem großen Aufwand verbunden?



[quote="Erich Müller" post_id=1828541 time=1525341165 user_id=26147]
Da kann und soll jeder selbst entscheiden, was ihm wichtig ist. In "meinem" Ausgangssystem, nämlich Märklin-basiert, ist Railcom nicht vorgesehen. Meine Zentrale "kann" das zwar, aber ich besitze zur Zeit keinen Decoder, der es "könnte". Ich sehe allerdings auch, dass zumindest in meiner kleinen Anlagenwelt schon einiges zusammenkommen muss, damit ein Zug unbemerkt ins falsche Gleis fährt. [/quote]
Natürlich ist das meiste Geschmackssache.
Das Pro für Railcom (bzw. für eine Lokspezifische Meldung) ist für mich weniger für den Fall eines aus versehen verirrten Zuges, als viel mehr auch dem Komfort, eine Lok einfach aufs Gleis stellen zu können und die Software weiß sofort über alles bescheid. Auch das Ändern einer Grundkonfiguration ist mit der physischen Änderung vollzogen und abgeschlossen und muss nicht auch noch virtuell erledigt werden. Das sind für mich die wirklich interessanten und großen Pros, für z.B. Railcom.
Klar hast du recht, billig ist das aber nicht gerade und man muss die Meldegeschwindigkeit und die Auslastung des Datenbus im Auge behalten. Das wird wohl auch erst mit zunhemend leistungsfähgerer Hardware interessanter. Hier sehe ich mit interesse auf BidiB.
Vor mehr als 10 Jahren oder so, war daran doch nicht zu denken. Das ist vielleicht auch der Grund, warum sich das Railcom noch kaum etabliert hat. :

[quote="Erich Müller" post_id=1828541 time=1525341165 user_id=26147]
Ich bin beeindruckt von dem, was C-Digital alles ermöglicht. Es ist schade, dass es so ein Nischendasein führt.
[...] heute ist eben der Markt zu fast 100% von den zwei, drei großen Protokollen beherrscht, die eben entweder von den Fahrzeugherstellern selbst entwickelt wurden (Märklin) oder zumindest als Standard angesehen werden, für den man dann auch die ab Werk eingebauten Decoder auslegt.
[/quote]Mir geht es da ähnlich wie dir. Ich finde es interessant, weil bei C-Digital (aus der "normalen" Mobahnersicht) etwas "unkonventionell" gedacht wird und die Lösungen ungewohnt erscheinen, bis man sich einmal genauer damit befasst. Danach ist man sich dann nicht mehr so sicher, in welchem System jetzt eigentlich eher "unkonventionell" und garn nicht so logisch gedacht wird.
Auch bin ich von der technischen Umsetzung und Struktur überzeugt.
Es ist aber auch so, dass zu dem Zeitpunkt, als die anderen Systeme schon fest am Markt etabliert waren, dieses System erst aufkam. Da war es dann schon zu spät, für eine große Neuerung. Leider ergibt sich durch die komplett andere techn. Umsetzung zu allen anderen Systemen auch eine unüberwindbare Hyrde bei der "Durchlässigkeit", was ein großes Problem für einen größeren Marktanteil darstellt (kein Multiprotokoll). Also kann man auch keine Digitallok von der Stange kaufen, die mit C-Digital fährt.
Ein Umstig ist also in fast allen Fällen mit enormen Kosten verbunden - wie du ja auch geschrieben hast -, und steht damit in keiner Relation zum evtl. "Zugewinnn", leider.
Ich bleibe allerdings bei meiner Aussage, die ich hier schon früher geschrieben habe: Ich halte die Ü.technik des C-Digital Protokolls und dessen Struktur für die klügere und weitsichtigere, im Bezug auf die Sache Modelleisenbahnsteuerung.

Liebe Grüße,
Klaus K.

Hallo Klaus,

Zitat

---

Zusätzlich Melder im Gleis, werden hier nicht benötigt. Im Fall ohne Software, genügt schon das reine Umschalten des Bits für "Halt" in einem gewünschten Abschnitt.

---

Damit die Lok am gewünschten Ort zum Stehen kommt, muss der Wechsel in diesem Bit aber zum richtigen Zeitpunkt bzw. auch am richtigen Ort geschehen, oder? Ist das dann vergleichbar den immer gleich lang zu haltenden ABC-Abschnitten?

Zitat

---

Warum ist das lokspezifisch bei Rocrail mit so einem großen Aufwand verbunden?

---

Weil man dann die Delays für die "virtuellen Melder", also wann wird welche Geschwindigkeitsstufe gesendet, für jede Lok gesondert ermitteln muss, und dann auch für jede Lok quasi eine spezifische Fahrstraße erstellen muss, die genau diese Delays dann enthält.
Wenn es nur genau einen Fahrweg in den fraglichen Zielblock gibt, hält sich der Aufwand noch halbwegs in Grenzen; wollte ich das aber bei einem dreigleisigen Bahnhof an eingleisiger Strecke machen, hätte ich allein für die Einfahrt in diese drei Gleise sechs Fahrstraßen multipliziert mit der Zahl der Lokomotiven zu erstellen...

Zitat

---

Das Pro für Railcom (bzw. für eine Lokspezifische Meldung) ist für mich weniger für den Fall eines aus versehen verirrten Zuges, als viel mehr auch dem Komfort, eine Lok einfach aufs Gleis stellen zu können und die Software weiß sofort über alles bescheid. Auch das Ändern einer Grundkonfiguration ist mit der physischen Änderung vollzogen und abgeschlossen und muss nicht auch noch virtuell erledigt werden. Das sind für mich die wirklich interessanten und großen Pros, für z.B. Railcom.
Klar hast du recht, billig ist das aber nicht gerade und man muss die Meldegeschwindigkeit und die Auslastung des Datenbus im Auge behalten. Das wird wohl auch erst mit zunhemend leistungsfähgerer Hardware interessanter. Hier sehe ich mit interesse auf BidiB.
Vor mehr als 10 Jahren oder so, war daran doch nicht zu denken. Das ist vielleicht auch der Grund, warum sich das Railcom noch kaum etabliert hat. :

---

Nun - bei jeder PC-Steuerung muss eine Änderung des Gleisbildes auch im Programm nachvollzogen werden, darum kommt man nicht herum. Änderungen an den Lokeinstellungen - andere Funktionsbelegungen etwa - können die mit Railcom übertragen werden? An der Stelle ist mfx klasse, wird aber (derzeit) nicht zur Verortung einer Lok benutzt, der Lokdecoder kommuniziert also nur mit der Lok direkt und nicht durch den "Vermittler" Melder am Gleis.
Für mich kommt noch ein Detail dazu: Das Programm muss wissen, wie herum eine Lok im Gleis steht, damit die gegebene Fahrtrichtungsinformation mit der gewünschten Fahrtrichtung übereinstimmt. Bei Railcom kann das, soweit ich mich erinnere, gemeldet werden, weil hier quasi durch den Decoder gemeldet werden kann, "ich hab das rote Gleis links" oder "ich hab das rote Gleis rechts". Im symmetrischen Mittelleitersystem funktioniert das nicht, und mit meinen sehr begrenzten technischen Kenntnissen sehe ich auch keine Möglichkeit, dieses Handicap zu beheben.

Martin, noch einmal vielen Dank für deine Reaktionen.
Neben der anderen Informationsübertragung, die Klaus noch einmal angesprochen hat, sehe ich da auch viel mehr "Intelligenz" in den Decodern, jedenfalls verglichen mit den handelsüblichen Decodern der marktbeherrschenden Systeme.
Wenn ich mir ansehe, wie groß ein Decoder vor 30 Jahren war, und war er konnte, und heute ist ein MLD/3 ungefähr 1/3 der Größe und kann so viel mehr - ich bin beeindruckt. Noch dazu kostete der Decoder von damals soviel wie heute zwei oder drei MLD/3. (Das ist der Märklin-Decoder neuester Generation ohne Geräuscherzeugung.) Und deine Decoder legen da noch wieder einiges an Können drauf.
Über Geld redet man nicht, man hat es, sagt der Volksmund - aber: ist das denn finanziell halbwegs machbar, zumal bei den kleinen Stückzahlen, die für C-Digital produziert werden können?