Hallo Martin,

(Ohne Zitat) Danke für deine Nette Antwort.
Die Umsetzung und das gesamten Prinzip Deines neu System ist Genial ohne viel Kabelsalat, davon gibt es genug.

Freischaltcode z21 ect. unnötige Wlan Router IP Adressen ect... App starten und gleich Absturz NEIN DANKE!
Power On Regler On und lost gehts, meine Kids bekommen die Lenz Compact zum Spielen in Z.

MOBA Senioren sind mit den ganzen Neumodischen Digital auch überfordert und darum bleiben Sie auch
bei den "Knopf Tasten Systemen".

Den Rest Bitte per PN oder Email, Fertigungstechnik Konstruktion CAD RP reichlich Erfahrung, nur wenn ich
einen Lötkolben SMD LED sehe "Gänsehaut"

Grüß Andre Stefan

Edit: Display 2,8" Querformat ist schon etwas heftig, der Handregler müßte dann sehr flach ausfallen, hab das am alten Tasten Nokia angesehen.

Hallo Martin,

Zitat

---

Auf Messen oder Ausstellungen war ich bis jetzt nicht und es ist auch nichts der gleichen in Sicht. Aber man kann mit uns jeder Zeit gerne einen Termin vereinbaren und dann bei uns vorbeikommen und sich das ein oder andere vorführen lassen.

---

Alles klar. Vielleicht komme ich darauf einmal zurück.

Guten Abend Andre,

Zitat

---

Display 2,8" Querformat ist schon etwas heftig, der Handregler müßte dann sehr flach ausfallen, hab das am alten Tasten Nokia angesehen.

---

Ja, eigentlich hatte ich eher an 2,2" gedacht. Das wäre auch vom Stromverbrauch im Akkubetrieb besser.

Zitat

---

Fertigungstechnik Konstruktion CAD RP reichlich Erfahrung

---

Klasse! In dem Bereich habe ich eigentlich gar keine Erfahrung. Wenn sich bei mir Fragen auftun, melde ich mich bei dir per PN oder Mail.


@Stephan

Zitat

---

Alles klar. Vielleicht komme ich darauf einmal zurück.

---

Gerne. Nur bitte frühzeitig melden, damit ich mir die Zeit dann auch freischaufeln kann.

Hallo Hermann,

Hier bist du richtig...

Zitat

---

Wie man hier lesen kann, hat Martin seine Regelung wirklich entwickelt, wie man das als Ingenieur lernt. Das Ergebnis ist also keine Zauberei. Erstaunlicher finde ich, dass das die anderen großen Hersteller allem Anschein nach nicht so gemacht haben.
Ich finde den D&H auch gut, er hat aber auch so seine Schwächen.

---

Was hast du beim D&H für Schwächen festgestellt? Mir, und wie es scheint auch schon anderen, ist aufgefallen, dass die Regelung der D&Hs in Kombination z.B. mit den GFN Rundmotoren manchmal nicht genügent stark ist. Die Power mit der die Regelung nacharbeitet ist zu wenig und der Zug die Lok wird bei Belastung langsamer.

Ob die Hersteller so entwickelt haben oder nicht, entzieht sich meiner Kenntnis.

Vorsicht: Alles reine SPEKULATION:
Ich bin mir da insgesamt nicht sicher, ob sich da überhaupt ein E-Technik oder Maschinenbau Ingenieur hingesetzt hat um die Regelung zu entwickeln? Ich meine man könnte auch einfach einem Programmiere oder Informatiker o.ä. die Aufgabe übereignen. Die gehen so eine Aufgabe in der Regel dann etwas anders an.
Ein Fach genannt "Regelungstechnik" haben viele in ihrem Studiengang. Ich spreche da aus eigener Erfahrung. Mein Neffe macht gerade seinen Master in Informatik, meine Nichte studiert Architektur und mein Bruder hat seiner Zeit Physik und dann Biophysik studiert, ich selbst E-Technik. Wir alle hatten oder haben Regelungstechnik, sogar meine Nichte.
Der Anspruch, die Fertigkeiten und das Spektrum in den unterschiedlichen VLs unterscheiden sich doch deutlich. Ich hatte z.B. Grundlagen der Regelungstechnik, Regelungstechnik, Systemtheorie, Modellbildung, Automatisierungstechnik mit Regelungskonstruktion (über mehrere Semester). Wenn man das mit dem Fach Regelungstechnik meines Neffen (Informatik) oder meiner Nichte (Architektur) vergleicht sieht man, dass das jeweils nur "abgespeckte" Versionen davon sind und der Fokus da auch wo ganz anders liegt (wobei zw. dem in Informatik und Architektur nochmals ein großer Unterschied ist).
Bei meinem Bruder (Physik) war das fast so wie bei mir, nur noch stärker theoretisch und viel weniger Anwendungsorientiert (viel mehr Systemtheorie & Modellbildung).
Ich möchte damit sagen, vielleicht hat man sich auch einfach einen Informatiker geholt, der einem die ganze Dekodersoftware programmiert und der natürlich auch etwas von Regelungstechnik versteht, aber i.d.R. nicht in dem Maß, wie das vielleicht ein Physiker, E-Tchnik Ingenieur tut? Folglich wird die ganze Regelung auch anders "entwickelt" und ist elektormechanisch nicht so entworfen, wie das z.B. ein E-Technik Ingenieur machen würde. :
SPEKULATION Ende

Zitat

---

Ich habe hier etwas von einer SUSI-Adapterplatine mit Martins Motorsteuerung gelesen. Hat er sich in der Frage schon entschieden?

---

Ne, das dauert wohl noch.

Guten Abend,

@Marius:
Du fährst ja mit Martins C-Digital. Wie sieht es bei dir in der Praxis mit dem Verschleiß der Radschleifer aus?
Hast du evtl. einen Vergleich zu anderen Modellbahneren die mit den üblichen Digitalsystemen unterwegs sind?

@Martin:
Du hattest doch einmal erwähnt, dass sich das TTL Signal, wie bei DCC usw üblich, schlechter auf den Verschleiß der Radstromabnehmer auswirkt.

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

---

Dann gibt es noch einen positiven Nebeneffekt was den Kontaktverschleiß von Schleifern betrifft, der (zwar sehr geringfügig) schwächer ausfällt. Normalerweise ist das im Vergleich zw. Wechsel- und Gleichspannung genau umgekehrt, hier ist das aber anders, weil die Schaltspitzenspannung mit etwa ±18V Digitalsignal deutlich höher ist als die 15V DC und man nicht davon ausgehen kann, dass die meisten Schleifer-Kontaktimpulse direkt oder nahe am Nulldurchgang der Wechselspannung passieren.

---

Morgen Klaus,

Ich habe leider keine Vergleiche und Zahlen zu DCC etc.. Ist auch irgendwie nachvollziehbar, oder...

Zitat

---

Von DC über AC bis zu Dreieck und Rechteck. Ich glaube es war so, dass tatsächlich beim Rechtecksignal der Verschleiß deutlich zunahm (bin mir nicht mehr sicher: 30 bis 40% ? höher gegenüber DC) und die Begründung fand sich irgendwie in den beim Rechteck am stärksten vorhandenen Oberwellen.

---

Das ist in etwa richtig. Der Verschleiß von Feder-Schleif-Kontakten ändert sich mit unterschiedlichen Signalen, die darüber geleitet werden aber auch mit der Frequenz und der Stromhöhe.
Im übrigen gilt das z.B. auch für den Verschleiß von Schleifern oder Kohlen bei Motoren. Stephan-Alexander "SAH" hat dazu schon eine Untersuchung bei Motoren angestellt: Im Forum
Interessant zum Nachlesen bei Motoren: Dietmar Berghänel
Der Verschleißunterschied bei den Radschleifern fällt deutlich geringer aus, als bei Motoren. Da muss man sich auch im DCC-Betrieb nicht wirklich Sorgen machen. Nach meinen statistischen Abschätzungen hält sich der "höhere" Verschleiß unter 1,5%.
(Bei einer durchschnittlichen Lebensdauer von 10000h, etwas über 1 Jahr, macht das am Ende nicht mal 1 Woche aus)

Bei den Radschleifern geht es primär um kurze Kontaktunterbrechungen, wie diese beim Fahren leicht entstehen (Durch Vibration, Verschmutzung, Weichenübergänge, Kurvenfahrten, ...). Je nachdem wie sich die Spannung und in Folge dessen der Stromfluss im Moment der wieder entstehenden Kontaktierung (nach einer Kontaktunterbrechung) ändert, desto höher oder geringer ist die Belastung des Schleifers, was auf dessen Verschleiß wirkt.
Bei einem "scharfen" Rechteck (mit vielen Oberwellen) von +-18V, kann die Änderung im ungünstigsten Fall im letzten Moment der Kontaktierung noch +18V haben, dann kurzer Kontaktverlust und bei der Wiederkontaktierung dann -18V. Wenn der Wechsel schnell genug geht, ist der Schleifer und Decodereingang noch nicht potentialfrei und es kann zu Lichtbögen, Funkenschlag kommen zwischen -18 und vielleicht +5V oder höher. Also an einem Potential von ungefähr 20 bis 30V.

Der viel viel größere Fakor für den Verschleiß ist allerdnigs die Betriebszeit und die Stromaufnahme. => Man täte gut daran, die Stromaufnahme der Funktionen und damit der Decoder und letzten Endes der Schleifer möglichst gering zu halten. Das wirkt sich auch positiv auf die anderen el. Bauteile aus.
-> Motoren mit geringer Stromaufnahme tortz ausreichend Drehmoment, also mit hohem Wirkungsgrad > 50%, (>100mA in Nennbetrieb)
-> Birnchen durch LEDs tauschen
-> Pufferkondensatoren nur mit Ladeschaltung
(-> Sound nicht auf voller Lautstärke laufen lassen ?)

Guten Abend Klaus,

Zitat

---

Guten Abend,

@Marius:
Du fährst ja mit Martins C-Digital. Wie sieht es bei dir in der Praxis mit dem Verschleiß der Radschleifer aus?
Hast du evtl. einen Vergleich zu anderen Modellbahneren die mit den üblichen Digitalsystemen unterwegs sind?

---

Ich hatte in der Hinsicht noch nie Probleme und kenne auch unter meinen Mobakollegen keinen der bei Märklin oder DCC da Probleme hätte. Ich denke, dass es hier keinen erkennbaren Unterschied zwischen C-Digital und den anderen Systemen gibt. Mir ist aufjeden Fall noch nie etwas aufgefallen.

Gruß,
Marius

Hallo Klaus, Martin, Stephan und andere interessierte Teilnehmer und Mitleser,

Ich werde dieses Forum wieder verlassen. Das ist einfach doch nicht die richtige Plattform für jemanden wie mich...
Ich bedanke mich für die bisweilen interessante Disskussion und wünsche weiterhin noch viel Spaß.

@Hermann: Falls du noch mit C-Digital fährst oder fahren willst, kannst du mich bei Bedarf gerne per Mail kontaktieren. ->PN

Freundliche Grüße,
Marius

Hallo Marius,

Zitat

---

Ich werde dieses Forum wieder verlassen. Das ist einfach doch nicht die richtige Plattform für jemanden wie mich...

---

Das erste würde ich bedauern, das zweite bestreite ich entschieden. Du bist im Gegenteil eine Bereicherung.
Lass dich von Alf nicht ins Bockshorn jagen; er hat offensichtlich zitiert, ohne richtig zu lesen, und vielleicht ist er mondfühlig - es war eben erst Neumond, und da geht es im Forum (ebenso wie zu Vollmond) schon mal etwas turbulenter zu.

Hallo,

das würde ich auch bedauern.

Ich habe diesen, sowie den anderen Fred, mit Interesse gelesen. Kann zwar nicht viel dazu beitragen.
War aber sehr informativ soviel über die einzelnen Protokolle zu erfahren.

Ich fahre zwar mit DCC und werde auch nicht auf C-Digital umsteigen (vlt. doch ), weil ich eh mit PC steuere.

Aber dennoch lese ich sowas gerne.

Hallo Martin,

Marius haben wir nun leider doch verloren... schade! Manchmal ist das hier ein ziemlich raues Pflaster.


Ich hätte da mal ein paar Fragen an dich, nur so aus grundlegendem Interesse, weil mehrere zuletzt darüber diskutiert hatten, und zwar:
Was verstehst du unter einem Konzept für eine Digitalsteuerung? Und weiter, was sollte deiner Meinung nach das zugrundeliegende Prinzip einer Digitalsteuerung sein?

Welches Konzept und Prinzip verfolgst du mit C-Digital und warum?


Dann habe ich noch eine Frage zu deinen Dekodern. Was würdest du sagen, oder was glaubst du, ist der Hauptunterschied deiner Motorregelung zu derer anderer Dekoderhersteller?
Ich meine, ich habe schon verstanden, dass du dich bei deiner Regelung deutlich stärker nach den Bedürfnisse von Glockenankermotoren gerichtet hast, aber ist das der große Unterschied oder eigentlich doch etwas anderes?
Bei den D&H Dekodern bspw. unterscheidet sich die komplette Regelung und auch die technische Umsetztung deutlich von allen anderen mir bekannten Dekodern.
Wie siehst du das? Hast du nun bei deinen Dekodern noch ein anderes Konzept bei der Regelung oder ist es - aus dieser Sicht - gleich mit anderen Herstellern?

Freundliche Grüße,
Stephan

Grüß dich Stephan,

Ich habe gerade etwas wenig Zeit, darum gibt es nur relativ knappe Antworten.
Wenn du etwas genauer wissen willst, frag mich bei Zeiten einfach noch einmal.

Zitat

---

Ich hätte da mal ein paar Fragen an dich, nur so aus grundlegendem Interesse, weil mehrere zuletzt darüber diskutiert hatten, und zwar:

---

Ach darum wollte Marius wohl kürzlich so genau von mir wissen, was wie mit dem C-Digitalprotokoll möglich ist... :

Zitat

---

Was verstehst du unter einem Konzept für eine Digitalsteuerung? Und weiter, was sollte deiner Meinung nach das zugrundeliegende Prinzip einer Digitalsteuerung sein?

---

Bin mir nicht sicher, ob ich deine Frage richtig verstehe...
Unter einem Konzept verstehe ich die Struktur, den Aufbau eines Steuerungssystems. Hier wäre das dann was für Komponenten, wie miteinander vernetzt werden und was für ein Informationsfluss entsteht bzw. entstehen soll. (abstrakte Frage -> abstrakte Antwort )
"zugrundeliegende Prinzip einer Digitalsteuerung": Wäre für mich, einfach, dass ein Informationsfluss ausschließlich auf digitalem Weg erfolgt, Informationsfluss und Energeiversorgung und Steuerung von einander getrennt, also unabhängig, erfolgen.
Sieh dir digitale Geräte an die du kennst, die sind fast alle so aufgebaut (Handy, PC, Fernseher, Waschmaschine, Auto, E-Herd, ...).

Zitat

---

Welches Konzept und Prinzip verfolgst du mit C-Digital und warum?

---

Naja, C-Digital soll und ist eben ein digitales Steuerungssystem vornehmlich genutzt für Modellbahnen. Es richtet sich genau nach dem oben genannten und vielfach bewährten "zugrundeliegenden Prinzip einer Digitalsteuerung". Bei allen Mehr-Komponenten (digitalen) Systemen mit HI = "human interaction" hat sich so eine Struktur bewährt. Letztlich entsteht mit dem Digitalsystem so etwas wie ein interaktiver "Roboter" (el.-mech. Maschine mit HI/UI).

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)

Zitat

---

Dann habe ich noch eine Frage zu deinen Dekodern. Was würdest du sagen, oder was glaubst du, ist der Hauptunterschied deiner Motorregelung zu derer anderer Dekoderhersteller?
Ich meine, ich habe schon verstanden, dass du dich bei deiner Regelung deutlich stärker nach den Bedürfnisse von Glockenankermotoren gerichtet hast, aber ist das der große Unterschied oder eigentlich doch etwas anderes?

---

Ja, ich weiß nicht so ganz, was ich hier antworten soll. Ich weiß ja nicht genau, was andere Hersteller genau bei ihren Decodern und deren Regelung gemacht haben. Mein Decoder beinhaltet z.b. "Machine Learning", also praktisch eine "KI", die es ermöglicht, dass der Decoder einiges selbst optimieren kann (Regelung, Datenempfang, ...). Das ist evtl. der größte Unterschied, auch wenn ich meine, dass es auch noch andere Sachen gibt, wie die Ansteuerung des Motors mit max. 14.8V Impulsen und eben der hohen Regelungsfrequenz.

Zitat

---

Bei den D&H Dekodern bspw. unterscheidet sich die komplette Regelung und auch die technische Umsetztung deutlich von allen anderen mir bekannten Dekodern.
Wie siehst du das? Hast du nun bei deinen Dekodern noch ein anderes Konzept bei der Regelung oder ist es - aus dieser Sicht - gleich mit anderen Herstellern?

---

Ich weiß nicht, ob man mein "Konzept" hier als etwas grundlegend anderes oder als so eine Art Sondernummer betrachten kann. Alle Decoder bewerten in irgendeiner Form die Gegen-EMK (nutzten also den Dynamoeffekt eines DC-Motors), auch meiner. Wie die EMK bewertet wird unterscheidet sich halt. D&Hs Regelung ist -im Bezug auf die anderen bekannten Decoder- etwas exotisch, weil die über einen Komparator die EMK in einer Pause dauerhaft messen und dann u.a. über die Länge der Pause regeln. Das bringt einige Vorteile mit sich. Dafür kann man bei solchen Regelungen keine vollständig frei wählbaren Fahrstufenkurven haben (wie auch bei meinem Decoder) und ein Betrieb ohne Regelung kann es so auch nicht geben. (Kommutierungsspitzen wirken sich i.a. negativ aus)

Ich hoffe meine Antworten, können dich trotz der knappen Form zufriedenstellen.

Hallo Martin,

Zitat

---

Ich habe gerade etwas wenig Zeit, darum gibt es nur relativ knappe Antworten.
Wenn du etwas genauer wissen willst, frag mich bei Zeiten einfach noch einmal.

---

Alles in Ordnung. Ich danke dir für die schnelle Antwort.

Zitat

---

Zitat

---

Ich hätte da mal ein paar Fragen an dich, nur so aus grundlegendem Interesse, weil mehrere zuletzt darüber diskutiert hatten, und zwar:

---

Ach darum wollte Marius wohl kürzlich so genau von mir wissen, was wie mit dem C-Digitalprotokoll möglich ist... :

---

Wir hatten hier über die verschiedenen Protokolle und auch über digitale Steuerungssysteme diskutiert.

Zitat

---

Zitat

---

Was verstehst du unter einem Konzept für eine Digitalsteuerung? Und weiter, was sollte deiner Meinung nach das zugrundeliegende Prinzip einer Digitalsteuerung sein?

---

Bin mir nicht sicher, ob ich deine Frage richtig verstehe...
Unter einem Konzept verstehe ich die Struktur, den Aufbau eines Steuerungssystems. Hier wäre das dann was für Komponenten, wie miteinander vernetzt werden und was für ein Informationsfluss entsteht bzw. entstehen soll. (abstrakte Frage -> abstrakte Antwort )
"zugrundeliegende Prinzip einer Digitalsteuerung": Wäre für mich, einfach, dass ein Informationsfluss ausschließlich auf digitalem Weg erfolgt, Informationsfluss und Energeiversorgung und Steuerung von einander getrennt, also unabhängig, erfolgen.
Sieh dir digitale Geräte an die du kennst, die sind fast alle so aufgebaut (Handy, PC, Fernseher, Waschmaschine, Auto, E-Herd, ...).

---

Alles klar.
Verstehe ich dich richtig, dass du damit verlangst, dass ALLE Steuerungsinformationen auf digitalem Weg erfolgen müssen? Das würde dann bedeuten, dass alle Informationen, die zu einer Modellbahnsteuerung gehören, in digitaler Form vorliegen müssen, also im Datenprotokoll integriert sein müssen.
Genau das war dann nämlich Streitpunkt, was denn nun zu den Informationen einer Modellbahnsteuerung gehört und was nicht.
Was für Information gehört denn deiner Meinung nach dazu, und warum?

Weiter würde ich gerne wissen, warum der Informationsfluss, die Energieversorung und die Steuerung von einander getrennt erfolgen können sollte? (Also warum bei der Modellbahn? Ich weiß auch, dass das in anderen techn. Anwendungen notwendig und sinnvoll ist.)

Zitat

---

Zitat

---

Welches Konzept und Prinzip verfolgst du mit C-Digital und warum?

---

Naja, C-Digital soll und ist eben ein digitales Steuerungssystem vornehmlich genutzt für Modellbahnen. Es richtet sich genau nach dem oben genannten und vielfach bewährten "zugrundeliegenden Prinzip einer Digitalsteuerung". Bei allen Mehr-Komponenten (digitalen) Systemen mit HI = "human interaction" hat sich so eine Struktur bewährt. Letztlich entsteht mit dem Digitalsystem so etwas wie ein interaktiver "Roboter" (el.-mech. Maschine mit HI/UI).

---

Du betrachtest also die Anlage und die Steuerung als einen "Roboter", der mit den steuernden Mobahnern interagiert? Auch nicht schlecht ...
Findet sich diese Denkweise dann auch in deiner Steuerung wieder? Wenn ja, in welcher Form?

Zitat

---

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)

---

Soetwas kenne ich zu genüge. (bin ja Mikrosystemtechniker)
Hier erkenne ich den Bezug zu "Robotern" . Interessant ist, dass du so ein Prinzip bei deiner Mobasteuerung verlangst.
Ein "bel. Interakteur" muss ja nicht einmal zwingend ein Mensch sein, sondern könnte auch eine andere Maschine sein.
Ein "bel. Human Interface Device / User Interface" bedeutet, dass ich mir mein "Tool" zur Steuerung nach meinem Geschack aussuchen kann, ohne dass das die Funktion der Anlage bedingt : . Dann braucht man eine oder mehrere genormte Standardschnittstelle/n, damit das Problemlos geht. Finde ich toll, diese Herangehensweise... Was für HIDs sind denn bei C-Digital möglich? Hast du dann eigene Treiber geschrieben und in dein System integriert?

Zitat

---

Zitat

---

Dann habe ich noch eine Frage zu deinen Dekodern. Was würdest du sagen, oder was glaubst du, ist der Hauptunterschied deiner Motorregelung zu derer anderer Dekoderhersteller?
Ich meine, ich habe schon verstanden, dass du dich bei deiner Regelung deutlich stärker nach den Bedürfnisse von Glockenankermotoren gerichtet hast, aber ist das der große Unterschied oder eigentlich doch etwas anderes?

---

Ja, ich weiß nicht so ganz, was ich hier antworten soll. Ich weiß ja nicht genau, was andere Hersteller genau bei ihren Decodern und deren Regelung gemacht haben. Mein Decoder beinhaltet z.b. "Machine Learning", also praktisch eine "KI", die es ermöglicht, dass der Decoder einiges selbst optimieren kann (Regelung, Datenempfang, ...). Das ist evtl. der größte Unterschied, auch wenn ich meine, dass es auch noch andere Sachen gibt, wie die Ansteuerung des Motors mit max. 14.8V Impulsen und eben der hohen Regelungsfrequenz.

---

Was? Willst du damit sagen, dass in deinen Dekodern eine KI arbeitet? Kein Scherz? Lastet das denn deinen uC nicht recht stark aus? Warum bist du diesen Weg gegangen? (Warum siehst du hier eine Notwendigkeit?)

Was ist das besondere an den 14.8V Impulsspannung für den Motor? - Das verstehe ich nicht...
Das mit der hohen Regelungsfrequenz für die Glockenankermotoren habe ich ja verstanden .

Zitat

---

Ich weiß nicht, ob man mein "Konzept" hier als etwas grundlegend anderes oder als so eine Art Sondernummer betrachten kann. Alle Decoder bewerten in irgendeiner Form die Gegen-EMK (nutzten also den Dynamoeffekt eines DC-Motors), auch meiner. Wie die EMK bewertet wird unterscheidet sich halt. D&Hs Regelung ist -im Bezug auf die anderen bekannten Decoder- etwas exotisch, weil die über einen Komparator die EMK in einer Pause dauerhaft messen und dann u.a. über die Länge der Pause regeln. Das bringt einige Vorteile mit sich. Dafür kann man bei solchen Regelungen keine vollständig frei wählbaren Fahrstufenkurven haben (wie auch bei meinem Decoder) und ein Betrieb ohne Regelung kann es so auch nicht geben. (Kommutierungsspitzen wirken sich i.a. negativ aus)

---

Klar werten alle irgendwie die Gegen-EMK aus. Früher gab es einmal Dekoder, die direkt mit einem Sensor am Motor zur Drehzahlmessung gearbeitet haben. Heute gibt es da aber meines Wissens nach nichts mehr.
Auch wenn alle über die Gegen-EMK regeln, ist doch deine Regelung ziemlich anders als andere, ebenso wie die von D&H. Oder nicht?
Bei dir kann man auch keine Fahrstufen einstellen? Bei D&H geht das doch, nur nicht jeder FS ein beliebigen Wert zuordenen geht nicht. Was kann man bei dir dann überhaupt ändern? Ich fand es bis jetzt bei all meinen DCC Dekodern sehr wichtig, dass ich auch meine Fahrstufekurve anpassen kann. Das wäre doch ein recht starkes Mako.

Freundliche Grüße,
Stephan

Guten Abend Stephan,

Zitat

---

Wir hatten hier über die verschiedenen Protokolle und auch über digitale Steuerungssysteme diskutiert.

---

Ah, evtl. werde ich bei Zeiten einmal reinlesen, danke.

Zitat

---

Verstehe ich dich richtig, dass du damit verlangst, dass ALLE Steuerungsinformationen auf digitalem Weg erfolgen müssen? Das würde dann bedeuten, dass alle Informationen, die zu einer Modellbahnsteuerung gehören, in digitaler Form vorliegen müssen, also im Datenprotokoll integriert sein müssen.

---

Korrekt. Warum auch nicht? Warum sollte das anders sein? Es soll doch eine digitale Steuerung sein!

Zitat

---

Genau das war dann nämlich Streitpunkt, was denn nun zu den Informationen einer Modellbahnsteuerung gehört und was nicht.
Was für Information gehört denn deiner Meinung nach dazu, und warum?

---

Ja, all die, die man für den Bahnbetrieb braucht eben.
Als Lokführer kann ich ein Schienenfahrzeug in beide Fahrrichtungen beschleunigen und bremsen, Signale und andere Zeichen an der Strecke wahrnehmen und darauf reagieren, die Beschleunigung je nach angehängter Zuglast steuern (Beschleunigungsverhalten), damit es keinen Schlupf gibt, dann kann ich noch Sanden, um die Traktion zu erhöhen, Lichter schalten, pfeifen und ggf. noch ein paar andere Sachen schalten (z.B. Pantograph auf/ab, Feststellbremse, manche haben eine AK (Automatikkupplung) usw) und ich kann die Lok abschalten und aussteigen, außerdem kann ich noch Informationen an die Leitstelle senden (Zugfunk, heute GSM-R).
Das dürfte so das wichtigste sein, denke ich.
Dies gilt es nun in digitaler Form einem Decoder = "Lokführer" mitzuteilen, damit dieser auch als solcher tätig werden kann.
Ich liste das mal eben auf, was wie im Protokoll dann vorkommt:
"ein Schienenfahrzeug" = Adressierung (Lokadresse)
"beide Fahrrichtungen" = Fahrrichtung
"beschleunigen und bremsen" = Fahrstufen rauf/runter
"auf Signale und Zeichen reagieren" = Fahrinformation (Halt/Langsamfahrt/freie Fahrt)
"Beschleunigung nach Zuglast richten" = Beschleunigungsverhalten (Massensimulation) rauf/runter
"Sanden" = Funktion
"Lichter schalten" = Funktion
"Pfeifen" = Funktion
"Pantograph auf/ab" = Funktion
"Feststellbremse" = Funktion
"AK" = Funktion
.... = Funktion
"Lok abschalten und abstellen" = Abadressierung
"Informationen an die Leitstelle senden" = autarke Rückmeldung

Diese Informationen sind in exakt oder in ziemlich ähnlicher Form im C-Digitalprotokoll enthalten (Soundfunktionen gibt es halt nicht/noch nicht?). Es gibt hier und da noch etwas mehr, wie z.B. bei den Funktionen, wo momentan max. 13 mitgesendet werden.
Bei den Fahrstufen sind es z.Z. 31 vorwärts/rückwärts plus die FS0. Für das Beschleunigungs- und Bremsverhalten gibt es aktuell 4 Stufen plus 1 (Aus).
Die Rückmeldung funktioniert auch vollkommen unabhängig vom Datensignal.
Und da kommen wir gleich zu deiner anderen Frage:

Zitat

---

Weiter würde ich gerne wissen, warum der Informationsfluss, die Energieversorung und die Steuerung von einander getrennt erfolgen können sollte? (Also warum bei der Modellbahn? Ich weiß auch, dass das in anderen techn. Anwendungen notwendig und sinnvoll ist.)

---

Wenn die Energieversorgung getrennt vom Informationsfluss ist, so ist es dem Empfäger bspw. möglich einen Fehler oder das nicht vorhanden sein des Datenempfangs zu melden.
Wenn eine Steuerung unabhngig von einer Antwort erfolgen kann, dann kann auch bei einer Sende-Störung die entsprechende Hardware neu konfiguriert oder kallibriert werden.
Wenn es hier Abhängigkeiten gäbe, wäre das ganze System störanfälliger und sowas wird einfach nicht gebaut. Das ist eine Art Grundregel.
Stell dir z.B. einmal vor beim Auto wäre der Austausch zw. 2 Sensoren gestört, diese können es jedoch nicht mitteilen, weil die Möglichkeit einer Mitteilung an einen zuvor korrekten Informationsempfang geknüpft ist.
Oder anderes Bsp. wenn eine schlechte Energieversorgung vorliegt (zu niedriger Pegel, zu starke Schwankungen ...), kann das nicht gemeldet werden, weil ein Informationsaustausch zu stark an die Energieversorgung gekoppelt ist. Klar kann keine Hardware mehr etwas machen, wenn die Energieversorgung komplett ausfällt, das merkt aber dann auch die umliegende Hardware und kann eine entsprechende Störung melden.
Noch ein Bsp.: Eine Hardware, bei der ein Software-Update bei einer Empfangskomponente vorgenommen werden soll. Hier ist es nötig, dass das Gerät auch bei abgeschaltete Empfang nicht seine Energieversorgung verliert.
Aber als Mikrosystemtechniker, wird dir das sicher alles bekannt sein.

Zitat

---

Du betrachtest also die Anlage und die Steuerung als einen "Roboter", der mit den steuernden Mobahnern interagiert? Auch nicht schlecht ...
Findet sich diese Denkweise dann auch in deiner Steuerung wieder? Wenn ja, in welcher Form?

---

Ja, in der Struktur der Komponenten und dem Informationsfluss zw. Sensorik, Aktorik und Steuerung.

Zitat

---

Hier erkenne ich den Bezug zu "Robotern" . Interessant ist, dass du so ein Prinzip bei deiner Mobasteuerung verlangst.

---

Was für andere Steuerungsanlagen und Informationssysteme gut ist, kann doch für die Moba nicht schlecht sein.

Zitat

---

Ein "bel. Interakteur" muss ja nicht einmal zwingend ein Mensch sein, sondern könnte auch eine andere Maschine sein.

---

Richtig, du könntest diese Rolle auch von einer weiteren Maschine übernehmen lassen.

Zitat

---

Ein "bel. Human Interface Device / User Interface" bedeutet, dass ich mir mein "Tool" zur Steuerung nach meinem Geschack aussuchen kann, ohne dass das die Funktion der Anlage bedingt : . Dann braucht man eine oder mehrere genormte Standardschnittstelle/n, damit das Problemlos geht. Finde ich toll, diese Herangehensweise... Was für HIDs sind denn bei C-Digital möglich? Hast du dann eigene Treiber geschrieben und in dein System integriert?

---

Was heißt hier beliebig. Es funktionieren Devices mit USB, Bluetooth, oder C-Digital-BUS. Damit kann der Anwender frei zwischen, Smartphone, Tablett, PC, embedded PC, C-Digital Controller und weiterer beliebiger Hardware mit C-Digital-Interface (z.B. für Bildstellwerk) wählen.
Die Funktion der Steuerung ist in jedem Fall voll vorhanden. (weil Forderung, dass Steuerung unabhängig vom Rest!)

Zitat

---

Was? Willst du damit sagen, dass in deinen Dekodern eine KI arbeitet? Kein Scherz? Lastet das denn deinen uC nicht recht stark aus? Warum bist du diesen Weg gegangen? (Warum siehst du hier eine Notwendigkeit?)

---

Das ist recht aufwändig zu erklären. Es lässt sich auf diese Weise die Regelung automatisch sehr gut optimieren, ohne dass der Anwender Fachwissen bezüglich einer Regelung oder der in der Lok verbauten Hardware haben muss. Auch die verbauten Motoren unterliegen Schwankungen und Getriebe sind auch nicht gleich.

Zitat

---

Was ist das besondere an den 14.8V Impulsspannung für den Motor? - Das verstehe ich nicht...
Das mit der hohen Regelungsfrequenz für die Glockenankermotoren habe ich ja verstanden .

---

Die meisten Motoren die in den Fahrzeugen verbaut werden sind 12V oder 15V Typen und hier wird also die Nennspannung wenn überhaupt dann nur geringfügig überschritten, was sich auf den Verschleiß und die Lebesdauer auswirkt. Es ist nicht so toll, wenn man z.B. einen 12V Faulhabermotor mit 20V Impulsen "beschießt" (das sind fast 170% der Nennspannung!).

Zitat

---

Klar werten alle irgendwie die Gegen-EMK aus. Früher gab es einmal Dekoder, die direkt mit einem Sensor am Motor zur Drehzahlmessung gearbeitet haben. Heute gibt es da aber meines Wissens nach nichts mehr.
Auch wenn alle über die Gegen-EMK regeln, ist doch deine Regelung ziemlich anders als andere, ebenso wie die von D&H. Oder nicht?

---

Ja, ok sie ist vielleicht im Mobabereich nicht gewöhnlich, aber was heißt das schon...

Zitat

---

Bei dir kann man auch keine Fahrstufen einstellen? Bei D&H geht das doch, nur nicht jeder FS ein beliebigen Wert zuordenen geht nicht. Was kann man bei dir dann überhaupt ändern? Ich fand es bis jetzt bei all meinen DCC Dekodern sehr wichtig, dass ich auch meine Fahrstufekurve anpassen kann. Das wäre doch ein recht starkes Mako.

---

Also ich habe doch nie gesagt, dass sich garnichts bei den Fahrstufen ändern lässt, nur eine komplett freie Fahrstufenkurve geht eben nicht. Das kann bei meiner Regelung nicht funktionieren.
Bei mir gibt es 3 Parameter über die sich eine Fahrstufenkurve anpassen lässt. Geschwindigkeit bei FS1, Höchstgeschwindigkeit und die Bauchigkeit/Krümmung der FS-Kurve.


Hier noch ein Beispiel mit konkaver Kurve und leicht angehobener FS1 sowie abgesenkter FS31.


Grüße,
Martin

Guten Abend Martin,

Sehr interessant zu lesen, was du da schreibst. Ich finde deine Herangehensweise und Betrachtungsweise einer digitalen Mobasteuerung sehr ansprechend. Sie scheint mir logisch und konsequent, das gefällt mir! Ich sehe das ziemlich ähnlich wie du.
Ein echt tolles System, dass du da auf die Beine stellen willst.


Die beiden Screenshots deines Fahrstufenkurve-Einstelltools sind soweit selbsterklärend. Was ist mit der Geschwindigkeitsangabe in km/h gemeint? Wird die Lok hier auf einem Prüfstand eingemessen oder mittels Lichtschranke oder wie?
Mir persönlich würde noch eine Sache bei deiner Kurve fehlen. Könnte man nicht noch andere Kurventypen vorsehen? z.B. Sigmoidfunktionen
Beim Anfahren beschleunigt der Zug zunächst langsamer, dann schneller und später, je näher er sich der Vmax nähert desto langsamer wird dann das Beschleunigen wieder.

Dann noch eine Frage: Hast du zum Programmieren der Dekoder lauter "kleine" Progrämmchen, die man zum Einstellen ausführt? Also eines für die Fahrstufenkurve, eines für Funktionen usw. ? Das fände ich unübersichtlich und etwas unpraktisch.

Liebe Grüße,
Klaus

Hallo Martin,

Zitat

---

Zitat

---

Verstehe ich dich richtig, dass du damit verlangst, dass ALLE Steuerungsinformationen auf digitalem Weg erfolgen müssen? Das würde dann bedeuten, dass alle Informationen, die zu einer Modellbahnsteuerung gehören, in digitaler Form vorliegen müssen, also im Datenprotokoll integriert sein müssen.

---

Korrekt. Warum auch nicht? Warum sollte das anders sein? Es soll doch eine digitale Steuerung sein!

---

Ja schon. Es gibt Mobahner, die bestreiten, dass eine Information zum Signalhalt/Langsamfahrt usw. grundlegend in ein Digitalprotokoll gehört. Mit der Begründung, dass der Eigentliche Lokführer man selbst sei und darum man auch grundsätzlich ersteinmal selbst für das Halten vor einem roten Signal zuständig ist. Will man eine "Automation" (so wurde das dann bezeichnet), dann sollte die so erfolgen, dass die komplette Lok von einem Automaten gesteuert wird. In den meisten Fällen ist das dann ein Rechner mit entsprechender Software, der das für x Loks übernimmt, als würden diese von Hand gesteuert. Bei einem gewünschten Signalhalt, fährt die Software dann Lok x auf Fahrstufe 0 runter.

Was sagst du dazu?

Zitat

---

Wenn die Energieversorgung getrennt vom Informationsfluss ist, so ist es dem Empfäger bspw. möglich einen Fehler oder das nicht vorhanden sein des Datenempfangs zu melden.
Wenn eine Steuerung unabhngig von einer Antwort erfolgen kann, dann kann auch bei einer Sende-Störung die entsprechende Hardware neu konfiguriert oder kallibriert werden.
Wenn es hier Abhängigkeiten gäbe, wäre das ganze System störanfälliger und sowas wird einfach nicht gebaut. Das ist eine Art Grundregel.
Stell dir z.B. einmal vor beim Auto wäre der Austausch zw. 2 Sensoren gestört, diese können es jedoch nicht mitteilen, weil die Möglichkeit einer Mitteilung an einen zuvor korrekten Informationsempfang geknüpft ist.
Oder anderes Bsp. wenn eine schlechte Energieversorgung vorliegt (zu niedriger Pegel, zu starke Schwankungen ...), kann das nicht gemeldet werden, weil ein Informationsaustausch zu stark an die Energieversorgung gekoppelt ist. Klar kann keine Hardware mehr etwas machen, wenn die Energieversorgung komplett ausfällt, das merkt aber dann auch die umliegende Hardware und kann eine entsprechende Störung melden.
Noch ein Bsp.: Eine Hardware, bei der ein Software-Update bei einer Empfangskomponente vorgenommen werden soll. Hier ist es nötig, dass das Gerät auch bei abgeschaltete Empfang nicht seine Energieversorgung verliert.
Aber als Mikrosystemtechniker, wird dir das sicher alles bekannt sein.

---

Ja, das ist und war mir alles schon klar. Ich weiß schon, dass man das in der Industrie bei Steuerungsanlagen usw so macht. Mich hätte nur interessiert, warum du das auch bei deiner Modellbahnsteuerung so machen willst. :
Aber gut, ich denke es ist schon klar geworden, warum. Eigentlich genau aus den Gründen, wesshalb man das auch in anderen Bereichen so macht.

Zitat

---

Zitat

---

Du betrachtest also die Anlage und die Steuerung als einen "Roboter", der mit den steuernden Mobahnern interagiert? Auch nicht schlecht ...
Findet sich diese Denkweise dann auch in deiner Steuerung wieder? Wenn ja, in welcher Form?

---

Ja, in der Struktur der Komponenten und dem Informationsfluss zw. Sensorik, Aktorik und Steuerung.

---

Interessant. Auch hier gibt es die Meinung, dass die Intelligenz einer Steuerung alleine an einem Punkt im System sein darf/sollte. Demzufolge sollte es also keine "intelligenten" Baugruppen an mehreren Stellen geben.
Was meinst du dazu?

Zitat

---

Zitat

---

Hier erkenne ich den Bezug zu "Robotern" . Interessant ist, dass du so ein Prinzip bei deiner Mobasteuerung verlangst.

---

Was für andere Steuerungsanlagen und Informationssysteme gut ist, kann doch für die Moba nicht schlecht sein.

---

Manche werden halt sagen, es sei unnötig und zu kostenintensiv.

Zitat

---

Was heißt hier beliebig. Es funktionieren Devices mit USB, Bluetooth, oder C-Digital-BUS. Damit kann der Anwender frei zwischen, Smartphone, Tablett, PC, embedded PC, C-Digital Controller und weiterer beliebiger Hardware mit C-Digital-Interface (z.B. für Bildstellwerk) wählen.
Die Funktion der Steuerung ist in jedem Fall voll vorhanden. (weil Forderung, dass Steuerung unabhängig vom Rest!)

---

Super, diese Denkweise gefällt mir. Das - finde ich - ist der richtige Weg.

Zitat

---

Also ich habe doch nie gesagt, dass sich garnichts bei den Fahrstufen ändern lässt, nur eine komplett freie Fahrstufenkurve geht eben nicht. Das kann bei meiner Regelung nicht funktionieren.
Bei mir gibt es 3 Parameter über die sich eine Fahrstufenkurve anpassen lässt. Geschwindigkeit bei FS1, Höchstgeschwindigkeit und die Bauchigkeit/Krümmung der FS-Kurve.

---

Ah, alles klar, danke für die Bilder. Das sieht ansprechend aus. Wie fein ist die Auflösung deiner Fahrstufenkurve dann?


Weil wir gerade wo anders darüber diskutieren: Wie würdest du sagen, sollte eine Software-Automatik in eine Mobasteuerung integriert sein?
Im "normalen" Moba-Bereich ist es so, dass die Software mit Protokollumsetzter die Steuerung darstellt und andere Funktionen dann in diese Software integriert sind (Vollautomatik, Halbautomatik, Fahrdienstleiter-Automatik, komplett manueller Betrieb,...). Ich habe dich so verstanden, dass du das anders möchtest. Wie und warum?

Freundliche Grüße,
Stephan L.

Hallo Klaus, (der andere Klaus )

Entschuldige, aber ich hatte übersehen, dass du hier geschrieben hattest... ops:

Zitat

---

Ich habe diesen, sowie den anderen Fred, mit Interesse gelesen. Kann zwar nicht viel dazu beitragen.
War aber sehr informativ soviel über die einzelnen Protokolle zu erfahren.

---

Auch wenn Marius das Forum aus persönlichen Gründen wieder verlassen hat, steht es dir gerne frei, mir Fragen zu stellen, sofern dich etwas besonders interessiert.

Zitat

---

Ich fahre zwar mit DCC und werde auch nicht auf C-Digital umsteigen (vlt. doch ), weil ich eh mit PC steuere.

---

Da du bei DCC bereits mit PC-Software (& wahrscheinlich Sensorik an der Anlage) unterwegs bist, würde ich dir auch von einem Umstieg abraten. (Außer du willst es unbedingt! )
Die Günde dafür sind einfach: Der Kostenaufwand und wahrscheinlich auch der Rück- bzw. Umbau wäre zu groß. Das stünde in keinem Verhältnis zum Nutzen.
Dann wäre auch noch wichtig, was du für ein "Spieltyp" bei der Moba bist.

Wie gesagt: Sollte dich ein Detail besonders interessieren, kannst du mir natürlich jederzeit Fragen stellen.

Hallo Klaus K. und Stephan L.,

Ich möchte mich hier nicht auf einen Streit (C-Digital gegen die restlichen Steuerungen) einlassen. Meine Aussagen, warum ich etwas so oder so mache bedeuten NICHT im Umkehrschluss, dass ich sagen will: "... und wer es anders macht, macht es falsch, oder ist dumm." Damit das gleich klar ist.

So jetzt beantworte ich gerne weiter Fragen mit Antworten, die bitte alle in obigem Kontext zu verstehen sind. Ich begründe meine Sichtweise natürlich auch und es steht jedem frei seine persönlichen Schlüsse zu ziehen, ok?!

Zitat

---

Ja schon. Es gibt Mobahner, die bestreiten, dass eine Information zum Signalhalt/Langsamfahrt usw. grundlegend in ein Digitalprotokoll gehört. Mit der Begründung, dass der Eigentliche Lokführer man selbst sei und darum man auch grundsätzlich ersteinmal selbst für das Halten vor einem roten Signal zuständig ist. Will man eine "Automation" (so wurde das dann bezeichnet), dann sollte die so erfolgen, dass die komplette Lok von einem Automaten gesteuert wird. In den meisten Fällen ist das dann ein Rechner mit entsprechender Software, der das für x Loks übernimmt, als würden diese von Hand gesteuert. Bei einem gewünschten Signalhalt, fährt die Software dann Lok x auf Fahrstufe 0 runter.

Was sagst du dazu?

---

Wo fange ich an...
Im manuellen Betrieb ist man selbst der Lokführer, dass sehe ich auch so. Das heißt aber, dass man mit dem Lokdecoder, mittels eines Steuergeräts, eine Einheit bilden muss (Mensch-Decoder = Lokführer). Jetzt ist die Frage: Kann man das ohne Einschränkungen?
Hier sage ich nein, da man als Lokführer hinter dem Steuergerät bei einer gewissen Anlagentopologie nicht immer alles so wahrnehmen kann, wie wenn man sich tatsächlich auf dem Führerstand der Lok befindet. Es entstehen Informationslecks, die geschlossen werden müssen.
Bspw. einen Signalhalt, der mir durch ein Lichtsignal angezeigt wird, sehe ich nur aus einem bstimmten Blickwinkel. Wenn ich den im richtigen Moment nicht habe, oder garnicht einnehmen kann, dann ist es mir auch nicht möglich als Lokführer adäquat zu reagieren.
Als Lösung der Problematik, dass man nicht wirklich (in vollem Umfang) die Position des Lokführers einnehmen kann, benötigt man eine Information, die sich an eine Signalstellung koppeln lässt und zumindest dem anderen Teil des Lokführers (Decoder) mitgeteilt werden kann. Im Fall einer digitalen Moba Steuerung sollte diese Information auch eine digitale sein.
Folglich integriert man diese in das Protokoll.
Das gilt im übringen für viele Dinge bei Steuerungen. Immer wenn man etwas aus mangelden Informationen dem Fahrer nicht überlassen kann, muss ein autom. System einspringen um die Lücke zu füllen. (avionische Systeme im Flugzeug, Systeme im Auto etc.)
Das Protokoll muss also die Informationen bereitstellen, damit ein tatsächlicher Lokführerbetrieb überhaupt immer gewährleistet ist.
Wie diese zusätzliche Information (im Fall des Signalhalt) im Protokoll nun genutzt wird, also ob eine Lok dann selbstständig Anhält oder man es dem Lokführer nur auf seinem Steuergerät anzeigt, dass ein Halt vorliegt, ist dann wieder ein anderes Thema und kann auch einstellbar sein. Aber hier ging es ja um das Vorhandensein dieser Information im Protokoll.

Eine Softwaresteuerung sollte meiner Meinung nach nur immer auf gegebenes Aufsetzen. Das heißt die grundlegende Funktionalität einer Steuerung liegt bei der Steuerung selbst und die Software macht diese nur bedien- und programmierbar.
Warum das u.a. wichtig ist, sieht man z.B. wenn man teilweise in eine Automation eingreifen will. Dazu komme ich bei deiner anderen Frage gleich noch zu.

Zitat

---

Zitat

---

Zitat

---

Du betrachtest also die Anlage und die Steuerung als einen "Roboter", der mit den steuernden Mobahnern interagiert? Auch nicht schlecht ...
Findet sich diese Denkweise dann auch in deiner Steuerung wieder? Wenn ja, in welcher Form?

---

Ja, in der Struktur der Komponenten und dem Informationsfluss zw. Sensorik, Aktorik und Steuerung.

---

Interessant. Auch hier gibt es die Meinung, dass die Intelligenz einer Steuerung alleine an einem Punkt im System sein darf/sollte. Demzufolge sollte es also keine "intelligenten" Baugruppen an mehreren Stellen geben.
Was meinst du dazu?

---

Ich verstehe diese Aussage nicht? Viele Baugruppen haben eine gewisse Intelligenz eingebaut und werden dann vernetzt und evtl. von einem oder mehreren zentralen Knotenpunkten überwacht. Das ist doch immer so. Ich verstehe nicht, was man hier in Frage stellen will. Will man die Intelligenz aus den Decodern nehmen und von einem Rechner alles bearbeiten lassen, dann müssten bspw. ständig alle Motordaten von jeder Lok zu diesem Rechner geschickt, dort bearbeitet und dann entsprechende Daten bspw. für die Lastregelung zurück geschickt werden. Das ist doch Käse... Ich glaube nicht, dass das ernsthaft jemand so behauptet. Da hast du bestimmt was falsch verstanden
Es gibt immer gewisse Intelligenzen in Teilsystemen (schau dir den menschlichen Körper an, ein sehr komplexes System, da steuert das Hirn doch nicht jede Zelle und selbst die, die als Sensoren für das Hirn dienen, unterliegen einem Informationsfilter/Prioritätsfilter. Wir könnten unsere Aufmerksamkeit sonst auch nicht gezielt auf etwas richten.) In der Robotik geht man ähnlich vor, v.a. bei humanoiden Robotern.

Wenn mich nicht alles täuscht gibt es bei der Moba sogar tatsächlich Systeme, bei denen z.B. eine ABV nicht vom Decoder übernommen wird, sondern von einer externen, zentalen Software. Das halte ich aus vielen Gründen für keine gute Lösung (milde Ausgedrückt).
Wenn man davon ausgeht, dass der Decoder der verlängerte Arm des Fahrers ist, damit sich in Kombination ein Lokführer ergibt, dann gehört eine ABV in das System Lokdecoder-Motor-Zug, die auch hier bedient werden sollte. Gleiches gilt für die Lastregelung (siehe oben) und anderes.
Außerdem wird ein Daten-BUS so sehr stark belastet und kommt bei einer gewissen Anzahl an Loks auch schnell an seine Grenzen.
Auch das ist eine Grundregel für Steuerungssysteme, dass man Informationen nur dort zur Verfügung stellt, wo diese auch hingehören.

Zitat

---

Zitat

---

Zitat

---

Hier erkenne ich den Bezug zu "Robotern" . Interessant ist, dass du so ein Prinzip bei deiner Mobasteuerung verlangst.

---

Was für andere Steuerungsanlagen und Informationssysteme gut ist, kann doch für die Moba nicht schlecht sein.

---

Manche werden halt sagen, es sei unnötig und zu kostenintensiv.

---

Zu kostenintensiv für was? Hier müsste man dann schon eine Relation nennen, sonst ist diese Aussage wertlos. Und auch für "unnötig" bräuchte ich schon eine Begründung.

Zitat

---

Zitat

---

Was heißt hier beliebig. Es funktionieren Devices mit USB, Bluetooth, oder C-Digital-BUS. Damit kann der Anwender frei zwischen, Smartphone, Tablett, PC, embedded PC, C-Digital Controller und weiterer beliebiger Hardware mit C-Digital-Interface (z.B. für Bildstellwerk) wählen.
Die Funktion der Steuerung ist in jedem Fall voll vorhanden. (weil Forderung, dass Steuerung unabhängig vom Rest!)

---

Super, diese Denkweise gefällt mir. Das - finde ich - ist der richtige Weg.

---

Ja, das sehe ich auch so. Hier wären wir dann an dem Punkt den ich oben schon angedeutet hatte.
Wenn das Halten vor einem Signal unabhängig vom Steuergerät geschehen können soll, dann muss das System, die Steuerung selbst, das schon mitbringen. (Steuerung unabhängig vom Steuergerät)

Zitat

---

Weil wir gerade wo anders darüber diskutieren: Wie würdest du sagen, sollte eine Software-Automatik in eine Mobasteuerung integriert sein?
Im "normalen" Moba-Bereich ist es so, dass die Software mit Protokollumsetzter die Steuerung darstellt und andere Funktionen dann in diese Software integriert sind (Vollautomatik, Halbautomatik, Fahrdienstleiter-Automatik, komplett manueller Betrieb,...). Ich habe dich so verstanden, dass du das anders möchtest. Wie und warum?

---

Ja, siehe oben.
Wie gesagt stellt eine zusätzliche, externe Rechner-Software-Lösung für mich nur ein komplexes Steuergerät da, mit dem sich große komplexe Abläufe programmieren lassen usw.. Es stellt aber NICHT einen festen Bestandteil der Steuerung dar, ohne den diese nicht funktioniert. Die Steuerung funktioniert immer für sich selbst. Ein zusätzlicher Rechner mit starker Software ist für mich nur ein multidimensionales Steuergerät, das in der Lage ist viele virtuelle Lokführer zu stellen und damit entsprechend programmierte Abläufe zu gewährleisten, bei gleichzeitiger Einhaltung der vom System geforderten Sicherheiten.
Viele Steuerungen der großen Hersteller beinhalten ja einen Rechner&Software schon (Ecos, CS1/2/3), oder? Ein zusätzliches Gerät, wäre dann in meinen Augen eben nur ein Steuergerät.

Ich möchte in der Lage sein, jeder Zeit den ein oder anderen Zug manuell mit einem Steuergerät zu steuern, bei einem Zugwechsel diesen in eine Automatik zu übergeben und das ohne großen Aufwand. Also einfach so im laufenden Betrieb, nur durch abadressieren bspw..("Abadressieren" = "Ich steige als Lokführer aus der Lok aus" , so hatte ich das ja erklärt)

Damit das möglich ist, muss eine Software-Automatik
a) in der Lage sein, für einen Zug den Lokführerposten abzugeben und nur den Fahrdienstleiter weiter zu stellen und
b)muss dem Lokführer (Mensch+Decoder) z.B. mitgeteilt werden können, wann und wo er zu halten hat.
(Das bringt uns dann wieder zum Anfang mit der Frage nach den Infos im Protokoll)

Zitat

---

Ah, alles klar, danke für die Bilder. Das sieht ansprechend aus. Wie fein ist die Auflösung deiner Fahrstufenkurve dann?

---

Aktuell 12Bit = 4096 Werte.

Zitat

---

Ein echt tolles System, dass du da auf die Beine stellen willst.

---

Freut mich, dass es dir gefällt.

Zitat

---

Was ist mit der Geschwindigkeitsangabe in km/h gemeint? Wird die Lok hier auf einem Prüfstand eingemessen oder mittels Lichtschranke oder wie?

---

Das ist dem Anwender überlassen. Hier ist bis jetzt kein fester automatischer Einmessvorgang vorgesehen.
Man kann bspw. einfach ein Maßband an ein Stück Strecke legen und dann mit der Stoppuhr die Zeit messen. Das trägt man dann ein und bekommt die Geschwindigkeit in 1:1. Dann kann man sich die Vmax so einstellen, dass es in etwa dem Vorbild entspricht und auch die anderen Geschwindigkeiten zu jeder Fahrstufe kann man sich anzeigen lassen. (FS1, FS15 und FS31 werden immer angezeigt)

Zitat

---

Mir persönlich würde noch eine Sache bei deiner Kurve fehlen. Könnte man nicht noch andere Kurventypen vorsehen? z.B. Sigmoidfunktionen
Beim Anfahren beschleunigt der Zug zunächst langsamer, dann schneller und später, je näher er sich der Vmax nähert desto langsamer wird dann das Beschleunigen wieder.

---

Ich denke dir ist hier ein kleiner Denkfehler unterlaufen? Die Fahrstufenkurve steht nur indirekt in Zusammenhang zur Beschläunigung, da die Fahrstufenkurve nicht v(t) darstellt, sondern lediglich eine Zuordnung zw. der Fahrstufe des Steuergeräts (1 bis 31) und den 4095 Geschwindigkeitsstufen der Lok ( v(FSx) wenn man so will ). Die Beschleunigung kann gesondert eingestellt werden. Das Fenster sieht so ähnlich aus und man stellt dann über eine Kurve die Zeit ein, die der Decoder von Geschwindigkeitsstufe x nach y verstreichen lässt. Also delta v / delta t was dann der Beschleunigung entspricht. Die Funktion die es hier gibt, kann genau das erfüllen, was du verlangst. (sigmodialen Verlauf der Beschleunigung)

Zitat

---

Dann noch eine Frage: Hast du zum Programmieren der Dekoder lauter "kleine" Progrämmchen, die man zum Einstellen ausführt? Also eines für die Fahrstufenkurve, eines für Funktionen usw. ? Das fände ich unübersichtlich und etwas unpraktisch.

---

Nein, nein. Ich habe das Fenster nur aus dem Programmierfenster abgedockt, damit man bei einem Screenshot besser sieht und sich das hier im Forum anzeigen lässt. Aus der Programmieroberfläche lassen sich einige Fenster an- und abdocken, wie man das von anderen Programmen kennt (z.B. Toolbars).

Grüße,
Martin

Hallo Martin,

Zitat

---

Ich möchte mich hier nicht auf einen Streit (C-Digital gegen die restlichen Steuerungen) einlassen. Meine Aussagen, warum ich etwas so oder so mache bedeuten NICHT im Umkehrschluss, dass ich sagen will: "... und wer es anders macht, macht es falsch, oder ist dumm." Damit das gleich klar ist.

So jetzt beantworte ich gerne weiter Fragen mit Antworten, die bitte alle in obigem Kontext zu verstehen sind. Ich begründe meine Sichtweise natürlich auch und es steht jedem frei seine persönlichen Schlüsse zu ziehen, ok?!

---

Bitte verstehe mich nicht falsch, das war auch nicht meine Absicht dich hier in einen Streit zu verwickeln. Ich habe durch Marius' Aussagen in einer anderen Diskussion nur gesehen, dass vieles was ich mir so gedacht habe nur daher rührt, weil ich es eben nur so kenne. Der "normale" Digitalfahrer kennt doch kein C-Digital und ist damit mit der enthaltenen Philosophie nicht vertraut. Eine Bewertung, ob die eine oder eine andere nun die "bessere" ist, muss doch eh jeder für sich persönlich entscheiden. Dafür kann man ja sachliche Argumente nennen, um eine Sicht zu begründen, mehr auch nicht.
Man neigt eben schnell dazu etwas als "muss" oder "... das gehört so und nicht anders" zu sehen, nur weil man es eben nur so kennt. So hat man nämlich Marius gegenüber teilweise "argumentiert".
Ich für meinen Teil fand es sehr interessant und eigentlich auch inspirierend, wie er hier und da anders gedacht hat und eben eine andere Sicht auf gewisse Dinge hatte. Da seine Sichtweise zweifelsohne von seinem Umgang mit deinem System her rührt, habe ich mir gedacht dir die ein oder andere Frage zu stellen, um zu sehen, wie du darüber denkst.

Erstaunlicherweise kann ich dein Sicht sehr gut nachvollziehen und auch nichts "falsches" darin sehen, auch wenn ich einiges von DCC-Systemen eben anders gewohnt bin.

Freundliche Grüße,
Stephan L.

Hallo Martin,

Zitat

---

Im manuellen Betrieb ist man selbst der Lokführer, dass sehe ich auch so. Das heißt aber, dass man mit dem Lokdecoder, mittels eines Steuergeräts, eine Einheit bilden muss (Mensch-Decoder = Lokführer). Jetzt ist die Frage: Kann man das ohne Einschränkungen?
Hier sage ich nein, da man als Lokführer hinter dem Steuergerät bei einer gewissen Anlagentopologie nicht immer alles so wahrnehmen kann, wie wenn man sich tatsächlich auf dem Führerstand der Lok befindet. Es entstehen Informationslecks, die geschlossen werden müssen.
Bspw. einen Signalhalt, der mir durch ein Lichtsignal angezeigt wird, sehe ich nur aus einem bstimmten Blickwinkel. Wenn ich den im richtigen Moment nicht habe, oder garnicht einnehmen kann, dann ist es mir auch nicht möglich als Lokführer adäquat zu reagieren.
Als Lösung der Problematik, dass man nicht wirklich (in vollem Umfang) die Position des Lokführers einnehmen kann, benötigt man eine Information, die sich an eine Signalstellung koppeln lässt und zumindest dem anderen Teil des Lokführers (Decoder) mitgeteilt werden kann. Im Fall einer digitalen Moba Steuerung sollte diese Information auch eine digitale sein.
Folglich integriert man diese in das Protokoll.

---

Das kann ich alles gut nachvollziehen und ich kann dir auch voll zustimmen. Ich sehe keinen "Fehler" darin, eine Halteinformation im Protokoll zu haben.
Auch die Notwendigkeit im Zusammenhang mit einer Automatik, so wie du sie dir vorstellst, ist klar ersichtlich.

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

---

Eine Softwaresteuerung sollte meiner Meinung nach nur immer auf gegebenes Aufsetzen. Das heißt die grundlegende Funktionalität einer Steuerung liegt bei der Steuerung selbst und die Software macht diese nur bedien- und programmierbar.

---

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)

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

---

Ich verstehe diese Aussage nicht? Viele Baugruppen haben eine gewisse Intelligenz eingebaut und werden dann vernetzt und evtl. von einem oder mehreren zentralen Knotenpunkten überwacht. Das ist doch immer so. Ich verstehe nicht, was man hier in Frage stellen will. Will man die Intelligenz aus den Decodern nehmen und von einem Rechner alles bearbeiten lassen, dann müssten bspw. ständig alle Motordaten von jeder Lok zu diesem Rechner geschickt, dort bearbeitet und dann entsprechende Daten bspw. für die Lastregelung zurück geschickt werden. Das ist doch Käse... Ich glaube nicht, dass das ernsthaft jemand so behauptet. Da hast du bestimmt was falsch verstanden

---

Kann schon sein, dass ich hier dann etwas falsch verstanden habe, bzw. derjenige das anders gemeint hat.
Ich hatte es so verstanden, dass 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. Aber gut seis drum, meine Ansicht ist das eh nicht!

Zitat

---

Wenn mich nicht alles täuscht gibt es bei der Moba sogar tatsächlich Systeme, bei denen z.B. eine ABV nicht vom Decoder übernommen wird, sondern von einer externen, zentalen Software. Das halte ich aus vielen Gründen für keine gute Lösung (milde Ausgedrückt).
Wenn man davon ausgeht, dass der Decoder der verlängerte Arm des Fahrers ist, damit sich in Kombination ein Lokführer ergibt, dann gehört eine ABV in das System Lokdecoder-Motor-Zug, die auch hier bedient werden sollte. Gleiches gilt für die Lastregelung (siehe oben) und anderes.
Außerdem wird ein Daten-BUS so sehr stark belastet und kommt bei einer gewissen Anzahl an Loks auch schnell an seine Grenzen.
Auch das ist eine Grundregel für Steuerungssysteme, dass man Informationen nur dort zur Verfügung stellt, wo diese auch hingehören.

---

Das verstehe ich auch. Mir ist auch bekannt, dass man Informationen nur dort zur verfügung stellt, wo diese auch hingehören. Also alles klar, soweit. Ich kann dir voll zustimmen.

Zitat

---

Zu kostenintensiv für was? Hier müsste man dann schon eine Relation nennen, sonst ist diese Aussage wertlos. Und auch für "unnötig" bräuchte ich schon eine Begründung.

---

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

---

Ja, siehe oben.
Wie gesagt stellt eine zusätzliche, externe Rechner-Software-Lösung für mich nur ein komplexes Steuergerät da, mit dem sich große komplexe Abläufe programmieren lassen usw.. Es stellt aber NICHT einen festen Bestandteil der Steuerung dar, ohne den diese nicht funktioniert. Die Steuerung funktioniert immer für sich selbst. Ein zusätzlicher Rechner mit starker Software ist für mich nur ein multidimensionales Steuergerät, das in der Lage ist viele virtuelle Lokführer zu stellen und damit entsprechend programmierte Abläufe zu gewährleisten, bei gleichzeitiger Einhaltung der vom System geforderten Sicherheiten.

---

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

---

Viele Steuerungen der großen Hersteller beinhalten ja einen Rechner&Software schon (Ecos, CS1/2/3), oder? Ein zusätzliches Gerät, wäre dann in meinen Augen eben nur ein Steuergerät.

---

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

---

Ich möchte in der Lage sein, jeder Zeit den ein oder anderen Zug manuell mit einem Steuergerät zu steuern, bei einem Zugwechsel diesen in eine Automatik zu übergeben und das ohne großen Aufwand. Also einfach so im laufenden Betrieb, nur durch abadressieren bspw..("Abadressieren" = "Ich steige als Lokführer aus der Lok aus" , so hatte ich das ja erklärt)

---

Das fände ich auch toll. Das würde mir im Spielbetrieb sicher Spaß machen v.a. auch wenn man mit Kindern oder Enkeln spielt. 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

---

Damit das möglich ist, muss eine Software-Automatik
a) in der Lage sein, für einen Zug den Lokführerposten abzugeben und nur den Fahrdienstleiter weiter zu stellen und
b)muss dem Lokführer (Mensch+Decoder) z.B. mitgeteilt werden können, wann und wo er zu halten hat.
(Das bringt uns dann wieder zum Anfang mit der Frage nach den Infos im Protokoll)

---

Dieses Problem kommt dann noch hinzu und wahrscheinlich noch andere. Aber auch dieses Problem hast du ja anscheinend nicht, das habe ich verstanden.

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

---

Zitat

---

Ein echt tolles System, dass du da auf die Beine stellen willst.

---

---

Das finde ich übrigens auch. Es ist wirklich interessant zu lesen, was auch ganz anders möglch sein kann, als man das kennt.

Zitat

---

Ich denke dir ist hier ein kleiner Denkfehler unterlaufen? Die Fahrstufenkurve steht nur indirekt in Zusammenhang zur Beschläunigung, da die Fahrstufenkurve nicht v(t) darstellt, sondern lediglich eine Zuordnung zw. der Fahrstufe des Steuergeräts (1 bis 31) und den 4095 Geschwindigkeitsstufen der Lok ( v(FSx) wenn man so will ). Die Beschleunigung kann gesondert eingestellt werden. Das Fenster sieht so ähnlich aus und man stellt dann über eine Kurve die Zeit ein, die der Decoder von Geschwindigkeitsstufe x nach y verstreichen lässt. Also delta v / delta t was dann der Beschleunigung entspricht. Die Funktion die es hier gibt, kann genau das erfüllen, was du verlangst. (sigmodialen Verlauf der Beschleunigung)

---

Das finde ich auch toll. Ist mir so auch von keinem anderen Dekoder bekannt. Eigentlich hast du mit deiner Ansicht aber total Recht, die Beschleunigung ist das eine, die Geschwindigkeit das andere und die Fahrstufenkurve noch etwas anderes. Deine geradlinige, logische Denkweise hier gefällt mir.


Freundliche Grüße,
Stephan L.

Guten Abend Martin und Stephan,

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.
Wer weiß wer da alles mitliest. 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
Aber zurück zum Thema...

@Martin:

Zitat

---

Das ist dem Anwender überlassen. Hier ist bis jetzt kein fester automatischer Einmessvorgang vorgesehen.
Man kann bspw. einfach ein Maßband an ein Stück Strecke legen und dann mit der Stoppuhr die Zeit messen. Das trägt man dann ein und bekommt die Geschwindigkeit in 1:1. Dann kann man sich die Vmax so einstellen, dass es in etwa dem Vorbild entspricht und auch die anderen Geschwindigkeiten zu jeder Fahrstufe kann man sich anzeigen lassen. (FS1, FS15 und FS31 werden immer angezeigt)

---

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

---

Ich denke dir ist hier ein kleiner Denkfehler unterlaufen? Die Fahrstufenkurve steht nur indirekt in Zusammenhang zur Beschläunigung, da die Fahrstufenkurve nicht v(t) darstellt, sondern lediglich eine Zuordnung zw. der Fahrstufe des Steuergeräts (1 bis 31) und den 4095 Geschwindigkeitsstufen der Lok ( v(FSx) wenn man so will ). Die Beschleunigung kann gesondert eingestellt werden. Das Fenster sieht so ähnlich aus und man stellt dann über eine Kurve die Zeit ein, die der Decoder von Geschwindigkeitsstufe x nach y verstreichen lässt. Also delta v / delta t was dann der Beschleunigung entspricht. Die Funktion die es hier gibt, kann genau das erfüllen, was du verlangst. (sigmodialen Verlauf der Beschleunigung)

---

Ja, da habe ich mich tatsächlich etwas aufs Glatteis führen lassen ops: Das kommt hier wieder daher, weil ich es von meinen DCC-Decodern nicht anders kenne. Da stellt man mit der ABV die Beschleunigungszeit bis Vmax ein und in Kombination mit der gewählten Fahrstufentabelle ergibt sich dann ein bestimmtes Beschleunigungsverhalten.
Wenn man hier möchte, dass eine Lok im unteren Fahrstufenbereich zunächst langsamer beschleunigt, so muss man einfach den Abstand der unteren FS zueinander veringern.
Wieder ein Bsp. wo man sieht, wie man beeinflusst wird, wenn man eine Sache nur auf eine Weise kennt.

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.

Das mit der Signalhaltinformation sehe ich übrigens ganz genauso wie du. Ich finde auch nicht, dass, nur weil es am restlichen Markt so üblich war, man sagen kann, dass soetwas nicht ins Protokoll gehört. Es gäbe sogar noch weitere Begründungen, warum derartige Informationen in einem Protokoll durchaus Sinn machen.
Für DCC und auch andere -Systeme hätte und hat es ja auch keinen Sinn gemacht so eine Information aufzunehmen, die sich dann lokal (eben bei einem Haltabschnitt) von der auf der Strecke unterschieden hätte. Beim Einfahren von der Strecke in einen halt-zeigenden Abschnitt würde es ja laufend zu enormen Kurzschlüssen an 30 bis 40V kommen.
Es war also technisch bedingt nicht möglich und damit wäre es auch völlig sinnfrei gewesen.
Aus diesem "Missstand" (wenn man es so sehen will) dann eine Tugend zu machen halte ich für kompletten Nonsens.

Klar, durch eine Steuerung mit einer entsprechenden Software braucht man evtl. keine Halteabschnitte mehr. Für den Betrieb, wie du ihn dir vorstellst, mit Automation, in die während des Betriebs eingegriffen werden kann, braucht man es allerdings doch wieder. Das hast du ja gut veranschaulicht.

Ich finde deine Denkweise im Bezug auf den strukturellen Aufbau einer Digitalsteuerung sehr gut. Ich würde es auch eher so sehen, dass man zunächst eine Steuerung braucht, die einem alle Funktionen liefert, die das System am Ende haben soll (-> Informationsbereitstellung). Ein Teil das diese Funktionen dann in irgendeiner Form nutzt und weiterverwertet, ist erst der nächste Schritt.
Es sollte also nicht so sein, dass sich durch eine zusätzlich Softwaresteuerung überhaupt erst der voll Funktionsumfang ergibt. Eine größere kombinatorische Vielfalt und steigerung der komplexität von Verknüpfungen, sollte das Ziel sein.

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.


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?

Übrigens ist es leider so, dass man bei der Umsetztung der großen Zentralen, die ja nichts anderes als ein Rechner mit Software sind, nicht immer ganz konsequent vorgegangen ist. Einen zusätzlichen Rechner mit entsprechender Software können diese nicht ersetzen. Ich steuere selbst seit kurzem zusätzlich mit einem Raspberry und einem F&S embedded Rechner an meiner Anlage und da geht dann schon richtig viel, dank der Software, was ohne eben nicht möglich wäre.


@Stephan L.:

Zitat

---

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

---

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.

Zitat

---

Ich hatte es so verstanden, dass 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. Aber gut seis drum, meine Ansicht ist das eh nicht!

---

Das ist auch richtig, weil derjenige ausschließlich mit seiner DCC-Sichtweise argumentiert hat. Da stimmt es dann auch, dass es ein Nachteil sein kann, weil der Decoder eben enstprechendes Bremssignal verstehen können muss. Hast du ja selbst auch oben geschrieben.
Im Fall von C-Digital ist diese Denkweise natürlich falsch, weil es keine besondere zusätzliche Sache eines Decoders und anderer Hardware ist, sondern Teil des Protokolls. Damit kann das jeder Decoder der das Protokoll versteht, also alle C-Digitaldecoder! Wäre das im Fall von DCC auch so, ergäbe sich hier auch kein Nachteil. Da es aber nun einmal nicht so ist, gibt es eben diesen Nachteil, aus dem dann leicht die Forderung entsteht, derartige ZUSÄTZLICHE "Intelligenz" am besten nicht in den Decoder sondern in eine externe Software auszulagern, wodurch man dann unabhängiger wird.

Hier haben wir wieder das gleiche: Durch einen "Missstand" der sich z.B. bei DCC ergibt, grundsätzlich zu fordern, dass derartige Intelligenz nicht in einem Decoder sein sollte, ist halt falsch. Für DCC mag die Forderung berechtigt sein, für C-Digital aber eben nicht.
Ich kann mir im Übrigen nicht vorstellen, dass ein Decoder tatsächlich spürbar günsitger wird, wenn man soetwas wie ABC nicht Implementiert hat. Ein Preislicher unteschied ergibt sich doch höchstens nur, weil die Hersteller aus jedem Feature Profit schlagen wollen.
Wo man sich allerdings etwas spart ist bei der zusätzlich Hardware für die Halteabschnitte. Das ist aber auch nicht die Welt.

Liebe Grüße,
Klaus K.

Guten Abend Klaus K.,

Zitat

---

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.

---

Mich persönlich wundert das nicht besonders.

Zitat

---

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

---

Das ist auch richtig, weil derjenige ausschließlich mit seiner DCC-Sichtweise argumentiert hat. Da stimmt es dann auch, dass es ein Nachteil sein kann, weil der Decoder eben enstprechendes Bremssignal verstehen können muss. Hast du ja selbst auch oben geschrieben.
Im Fall von C-Digital ist diese Denkweise natürlich falsch, weil es keine besondere zusätzliche Sache eines Decoders und anderer Hardware ist, sondern Teil des Protokolls. Damit kann das jeder Decoder der das Protokoll versteht, also alle C-Digitaldecoder! Wäre das im Fall von DCC auch so, ergäbe sich hier auch kein Nachteil. Da es aber nun einmal nicht so ist, gibt es eben diesen Nachteil, aus dem dann leicht die Forderung entsteht, derartige ZUSÄTZLICHE "Intelligenz" am besten nicht in den Decoder sondern in eine externe Software auszulagern, wodurch man dann unabhängiger wird.

Hier haben wir wieder das gleiche: Durch einen "Missstand" der sich z.B. bei DCC ergibt, grundsätzlich zu fordern, dass derartige Intelligenz nicht in einem Decoder sein sollte, ist halt falsch. Für DCC mag die Forderung berechtigt sein, für C-Digital aber eben nicht.

---

Ah, alles klar, jetzt versteh ich. Es liegt eben wieder einmal daran, dass man alles nur aus einem bekannten Erfahrungsschatz und Blickwinkel betrachtet hat.
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.

Gute Nacht,
Stephan L.

Morgen Klaus K. und Stephan L.,

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

---

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.

Grüße,
Martin

Hallo zusammen

ich bin einer der stillen Mitleser und verfolge das hier sehr interessiert.

Da ich ein reiner "Handfahrer" bin finde ich besonders die Ausführungen über die Regelung der Motoren sehr spannend.

Ich werde auf jeden Fall weiter mitlesen und vielleicht..... (im Hinterkopf brodelt es).

Hallo
Ich bin auch einer der stillen Mitleser obwohl ich das System ehh nicht einsetzen kann da ich N-Bahner bin. Aber ich kann mich ja schlau machen und wer weiß was die Zukunft bringt. Vlt. werden die Decoder doch noch kleiner so das sie in meine Loks passen. Bis dahin fahre ich eben weiter mit der Oldschooltechnik. Funzt ja bestens
Ciao
Micha