• Hallo TT-Modellbahner, schön, dass du zu uns gefunden hast.
    Um alle Funktionen nutzen zu können, empfehlen wir dir, dich anzumelden. Denn vieles, was das Board zu bieten hat, ist ausschließlich angemeldeten Nutzern vorbehalten. Du benötigst nur eine gültige E-Mail-Adresse und schon kannst du dich registrieren.
    Deine Mailadresse wird für nichts Anderes verwendet als zur Kommunikation zwischen uns.
    Die Crew des TT-Boardes

Digital Funktions-Anforderung für Z21 App

Mitropa

Foriker
Beiträge
1.212
Reaktionen
785 18
Ort
Berlin / Prerow
Hallo,
Wir nutzen die Z21 App als Stellwerk und Steuerpult (fahren zumeist mit WLAN-Maus und schalten per APP Weichen und Signale) und das funktioniert im Großen und Ganzen sehr gut, besonders Dinge wie "Fahrstraßen" sind ungemein praktisch.
Nun haben wir bei unserer Anlagenerweiterung die ersten Belegt-/Rückmelder (Roco 10808 mit Railcom-Rückmeldung via CAN-Bus) verbaut und dabei ist uns aufgefallen, dass die App zwar die Fahrzeuge korrekt und sogar mit Bild anzeigt, mit dem logischen Baustein "Belegtmelder" aber rein gar nichts weiter zu veranstalten ist. Dabei wäre es doch genial, einen Belegtmelder vor einem Signal mit selbigem zu verknüpfen:

Signal wird digital auf Halt gestellt, Fahrzeug erreicht den RM davor - die APP "weiß" nun
a) Signal ist auf Halt
b) welches Fahrzeug nähert sich

Nun könnte sie doch FS 0 an das erkannte Fahrzeug senden. Das wäre sicherlich für alle, die zwar digital fahren, jedoch noch keine Computersteuerung haben / wollen eine große Erleichterung:
- Keine ABC-Bremsstrecken oder
- keine extra Bremsmodule od. dergleichen

Einfach "konstanten Bremsweg" aktivieren, sollte dann reichen.


Ich werde noch mal bei Roco anfragen, ob sie diese kleine geniale Verknüpfung nicht in die App bauen möchten.


Und da ich nicht der Einzige bin der die App benutzt, habe ich eine Idee:

Könnten nicht alle, die Interesse an der Funktion haben, auch ein Ticket bei Roco aufmachen?

Vielleicht steigt dann die Motivation beim Entwickler, da mal ein Stündchen dran zu verschwenden.


PS:
Klar, das funktioniert erst mal nur in eine Fahrtrichtung, aber das kann man ja im laufenden Spielbetrieb berücksichtigen, indem grundsätzlich Signale "grün sind" und wirklich nur bei Bedarf auf "rot" geschaltet wird, so wie früher im einfachen Analogbetrieb. Ging auch sehr gut und war praktisch, um Weichen/Kreuzungen/"Blöcke" zu schützen.
 
Was Du da vor hast ist, aus einer reinen App zum steuern von Fahrzeugen und Zubehör ein Computerprogramm zu machen.
In dem Augenblick, wo logische Verknügfungen und ins Spiel kommen, wird es komplex und das ist nicht das Ziel der App.
Woher zum Beispiel soll die App wissen, aus welcher Richtiung Deine Lok in einen Belegtmeldeabschnitt eingefahren ist und ob bzw. ab wann sie mit dem Bremsen der Lok beginnen soll? Hier braucht es dann Weg-Zeit-Berechnungen und eine möglichst lückenlose Überwachung der Anlage mit Belegtmeldern.
Ich kann mir nicht vorstellen, dass sich Roco soetwas ans Bein binden wird, denn dafür gibt es ausgereifte Software, die auch mit Steuerungsmöglichkeiten per App aufwarten können.
 
Nein, so kompliziert ist es nicht. Man braucht keine Weg-Zeit-Berechnungen. Wenn man seine Rückmeldeabschnitte vor Signalen einheitlich baut, reicht für den Hausgebrauch der konstante Bremsweg (ESU zb. CV 254)
Das es nur einseitig so funktioniert, hatte ich ja ebenfalls geschrieben und auch, wie man das "Problem" umgehen könnte.

M.E.n. würde diese kleine Funktion eine große Lücke schließen zwischen
1) Ich fahre nur analog
...
10). Alles ist Digital und Vollautomatisch per Computer


Viele mir bekannte MoBa-Freunde starten nicht von 1 direkt auf 10 durch - aber alle müssen sich Dinge ausdenken, um digital vor Signalen anzuhalten, weil es so, wie analog, also mittels stromlos schalten, nicht mehr Sinn macht.
Und dann werden ABC-Bausteine aller Arten verbaut, Bremsmodule, usw. - alles Krempel, den man wieder wegwerfen kann, wenn man weiter Richtung 10.) baut.

Wenn man gleich stattdessen rückmeldefähige Belegtmelder verbaut, welche per App mit dem Signal verheiratet werden können, dann hätten alle was davon:

a) Der aufstrebende Modellbahner, der den Vollausbau nicht sofort will, ihn aber vielleicht irgendwann anstrebt, hat einen wunderbaren Upgradepfad und:
b) Roco. Denn dann hätten die ein nettes Alleinstellungsmerkmal.

Und so hoch ist der Programmieraufwand dafür nicht.
 
Dafür gibt es doch ABC?!
oder Bremsbausteine, oder Zimo-Bremsen, oder Fichtelbahn, Bogobit, oder, oder, usw. etc., pp. - alles Sachen, die separat zu kaufen, zu verstehen und zu bauen sind, die alle ihre Eigenarten haben. ABC z.B. wird mit manchen Triebzügen schwierig (z.B. Piko Talent2, klar, kann man alles ABC-gerecht umbauen - aber wozu?), ABC funktioniert auf etlichen Anlagen nicht 100% zuverlässig und fliegt in dem Moment raus, wo man die ersten Teile der Anlage dem PC zur Steuerung mittels RM/BM übergibt. Das ist alles andere als nachhaltig und unnötig zusätzlicher Aufwand.

Ich behaupte ja auch nicht, dass es NUR so geht, wie von mir vorgeschlagen. Im Gegenteil, es führen unendlich viele Wege nach Rom.

Meiner wäre eben einer, bei dem man wirklich charmant nur mit den Roco-Komponenten auskäme.
Ich steuere und schalte per APP und sehe dank der RM, wo welche Fahrzeuge sind, wie die Weichenstellung ist und welche Signale gerade welche Begriffe darstellen - prima! Jetzt fehlt nur die Entlastung, Züge auch ohne permanente Beaufsichtigung fahren lassen zu können und trotzdem sicher zu sein, dass sie nicht irgendwo reinrauschen, wo sie nicht durchrauschen dürfen.
Und:
Ich mochte bereits vor 45 Jahren die Spielweise: Gibt den Fahrzeugen Strom und steuere den Ablauf mittels Weichen- und Signalschaltungen. Losfahren und Anhalten tun die imaginären kleinen Lokführerlein. :)
 
Spätestens wenn Du Deinen ersten geschobenen Zug auf die Anlage stellst, oder gar einen ICE, zerplatzt der Traum per ABC bremsen zu können: Die für den BM2-Modus notwendigen Fahrstecken sind auf kaum einer Heimanlage unterzubringen. ABC ist eine wunderbare Idee, die jedoch an der Realität scheitert.
 
Ob die Roco RM + App mit geschobenen oder diagonal verkabelten Zügen mit entsprechend unterschiedlich langer Stromabnahmebasis mit konstanten Bremswegen klar kommt, ist auch noch nicht raus. Beliebig kompliziert geht es immer, aber hier soll es ja einfach und trotzdem universell sein.

Nebenbei: ich mag kein ABC, weil ich (!) keine breite Anwendung sehe und es zuviele Einschränkungen (Fahrzeuge, Decoder, Strecke) hat.
 
Zuletzt bearbeitet:
Ganz ehrlich:
Solange die App nicht mal die einfachste Grundfunktion, eine Lok zu steuern ohne sie vorher umständlich erst in die Datenbank einpflegen zu müssen, beherrscht sind solche Funktionen zweitrangig.
Einfach eine Adresse eingeben und losfahren und dann eine Funktion schalten kann diese App nicht.… Dafür sollten mal „alle“ ein Ticket bei Roco aufmachen.
 
@Svies Da hast Du nicht Unrecht - allerdings ist das bei der Multimaus ja auch nicht anders, da muss ich auch eine Lok anlegen, um sie steuern zu können, oder habe ich etwas übersehen? Jedoch welch ein Zufall: Derselbe Hersteller -- dasselbe Ticketsystem :)

Nur um das noch mal zu betonen: Ich möchte niemandem sein gewähltes Bremssystem madig machen.
Mir geht es um eine programmiertechnisch mit minimalstem Aufwand zu realisierende Möglichkeit, welche für alle aufstrebenden Volldigitalfahrer in spe eine nicht unerhebliche Erleichterung darstellen könnte, da es potentiell unnötige Umwege und Sackgassen wie ABC, Bogobit & Co. von vornherein vermeidet:

1x mit RM gebaut, könnte man jederzeit zur Vollautomatik erweitern.
 
Hi,
Die Diskussion gab es auch schon bei der Esu Ecos. Da hatten damals die Entwickler abgewunken. Obwohl die Ecos eine minimale Logik unterstützt.

In der Z21 (oder jede andere Modellbahnsteuerung) eine Logik einzubauen klingt einfach ist es aber nicht.
Eine Softwarelösung in der Z21 müsste regelmäßig den Zustand aller angeschlossenen Einheiten abfragen/bewerten. Dann müsste er überprüfen ob Schaltbedingungen erfüllt sind.
Da stellt sich schon die Frage in welcher Reihenfolge?
Was passiert wenn zwei Schaltbedingungen gleichzeitig erfüllt sind?
Was passiert wenn eine Schaltbedingung den Zustand so verändert , das die andere Schaltbedingung nicht mehr erfüllt ist?
Da kann man sehr schnell logische Fehler einbauen.
Dann zu guter letzt muss man diese Komplexität dem “Otto Normalmodellbahner” vermitteln.
Die “richtige” Modellbahnsteuerung braucht zu Recht einen Computer.

Gruß

Matthias
 
Bei der Multimaus muss man keine Lok extra anlegen. Adresse einstellen und losfahren (im "Nicht-Bibliotheks-Modus).
Jörg
Wieder was gelernt - allerdings ist der Komfortgewinn dadurch für mich eher rein akademisch:

Seitdem ich digital fahre, war ich immer im Bibliotheksmodus und es ist auch noch nie der Fall aufgetreten, dass jemand mit einem DCC Fahrzeug mit einer Adresse ungleich "3" zu mir auf den Dachboden kam. (Wenn jemand kam, dann immer mit einem Problemdecoder oder dergl., die sind zumeist auf "3" oder werden sowieso resettet...)
 
Hi,
Die Diskussion gab es auch schon bei der Esu Ecos. Da hatten damals die Entwickler abgewunken. Obwohl die Ecos eine minimale Logik unterstützt.

In der Z21 (oder jede andere Modellbahnsteuerung) eine Logik einzubauen klingt einfach ist es aber nicht.
Eine Softwarelösung in der Z21 müsste regelmäßig den Zustand aller angeschlossenen Einheiten abfragen/bewerten. Dann müsste er überprüfen ob Schaltbedingungen erfüllt sind.
Da stellt sich schon die Frage in welcher Reihenfolge?
Was passiert wenn zwei Schaltbedingungen gleichzeitig erfüllt sind?
Was passiert wenn eine Schaltbedingung den Zustand so verändert , das die andere Schaltbedingung nicht mehr erfüllt ist?
Da kann man sehr schnell logische Fehler einbauen.
Dann zu guter letzt muss man diese Komplexität dem “Otto Normalmodellbahner” vermitteln.
Die “richtige” Modellbahnsteuerung braucht zu Recht einen Computer.

Gruß

Matthias

Viel zu kompliziert:

Versuch mal, "analog" zu denken und du wirst sehen, in diesem Lösungsraum trifft nicht ein einziger deiner Einwände auf die Situation "Signal steht auf Halt" + "Lok fährt auf dieses zu".

Klar, in der vollautomatisierten Denke gibt es da sicherlich 1000 "Wenns" und "Abers" - jedoch geht es mir ja genau darum, mittels vorhandener digitaler Komponenten: "Signaldecoder + RM geschaltet per ein und derselben App" einen kategorischen Imperativ: "HALT!" an einer bestimmten Stelle zu formulieren. Mehr nicht. Keine Weiteren Bedingungen und Schaltzustände. Wie damals vor dem per SIBA-Signal stromlos geschalteten Gleisabschnitt. Einfach und auch für den Digitaleinsteiger ohne weitere Kenntnisse diverser Bremssysteme umsetzbar.

Und wenn später die "Wenns" und "Abers" wichtig werden (Fahrtrichtung z.B., unterschiedliche Bremswege und Berücksichtigung unterschiedlicher Zuglängen usw.) - dann wird nichts weggeworfen und neu verkabelt, weil der PC dazu kommt, sondern per Software verfeinert (und ggf. der eine oder andere RM / BM hinzugefügt).
 
Die “richtige” Modellbahnsteuerung braucht zu Recht einen Computer.
Heutige SmartPhones sind richtige Computer. Mit mehren GiB Arbeitsspeicher, mehreren Kernen und Taktfrequenzen im GHz Bereich hätten diese Prozessoren uns Anfang des Jahrtausends zum Träumen gebracht. So ein Kirin 970 z.B., wie er in vielen billigen China-Telefonen verbaut ist, ist schneller als Intels i7-930 aus dem Jahr 2010. Nur dass er statt der 130 Watt des i7 maximal 9 Watt verbrät und deshalb komplett ohne Lüfter auskommt.

Zurück zur Idee von @Mitropa: Der Z21 Detector ist ganz schön teuer 126,90 € UVP für einen 8-fach GBM. Wow! Ein schöner, durchdachter GBM mit Railcom sogar und eventuell sogar ohne Spannungsabfall. Trotzdem: Heftig. Weiß jemand, ob das CAN-Protokoll, welches der Detector spricht Roco-spezifisch ist? Oder ist das ein NMRA-Protokoll?

Aber egal: Die Nachrichten, die eine Z21 übers LAN schickt, wenn der Detector Loks findet, sind dokumentiert. Vielleicht an der Zeit, Mitropas Idee in meinem persönlichen Z21-Client zu testen?

1673344457923.png 1673344560439.png 1673344593258.png 1673344691264.png
 
@Mitropa
Es wurde ja schon geschrieben das dies die Multimaus kann. Ich nutze diese Funktion ausschließlich. Bei mittlerweile mehr als 150 Triebfahrzeugen ist mir der Aufwand zu hoch alles in die Datenbank einzupflegen. Ich hatte vorher Lenz. Da ging das nicht. Daher habe ich alle Tfz mit Funktionstastenbelegung im Kopf. Auch bei einem Stammtisch wo “jeder“ sein Handy zückt um auch mal ein anderes Tfz zu steuern wäre das sehr hilfreich. Das nächst ist das ein einmal angelegtes Tfz nicht mehr aus der Datenbank entfernt werden kann. Oder vielleicht doch?! Ich habe keine Möglichkeit gefunden.
Was mich weiter stört ist das die Z21/z21 sich nicht den letzten Zustand merken kann wenn man die Zentrale vom Strom trennt. Das konnte meine fast 30 Jahre alte Lenz-Zentrale schon damals. Wenn ich, angenommen 10-15, Tfz im Bw stehen habe und den Rangiergang aktiviert habe muss ich das nach dem einschalten der Roco-Zentrale bei allen Tfz wieder aktivieren. Und das jedes Mal.
Auch da wundert es mich das dies offensichtlich niemanden stört.

Wenn das gekommen ist unterstütze ich gerne weitere Erweiterungen um das Maximum aus der Technik heraus zu holen. Denn wie du dargelegt hast ist da noch sehr viel Potential.
 
@Svies Alles richtig, aber, frei nach Wolfgang Borchert in "Draußen vor der Tür": "Irgendwann muß ein Anfänger ja mal anfangen!"

Sprich: Wenn wir alle einfach nur warten, bis alle Vorbedingungen erfüllt sind, bis wir aktiv werden wollen, werden wir nichts bewirken.


Wir können es ja kollektiv angehen:
Du formulierst Deine Wünsche und ich gebe die per Feature-Request an Roco weiter - und andersherum. Zusammen erreicht man vielleicht mehr, als die üblichen Textbausteinantworten. :)
 
HWeiß jemand, ob das CAN-Protokoll, welches der Detector spricht Roco-spezifisch ist? Oder ist das ein NMRA-Protokoll?

Aber egal: Die Nachrichten, die eine Z21 übers LAN schickt, wenn der Detector Loks findet, sind dokumentiert. Vielleicht an der Zeit, Mitropas Idee in meinem persönlichen Z21-Client zu testen?

Es handelt sich um den Dialekt "ZCAN", diese und weitere Fragen werden hier ausführlich behandelt.
 
So ein Kirin 970 z.B., wie er in vielen billigen China-Telefonen verbaut ist, ist schneller als Intels i7-930 aus dem Jahr 2010.
Tja das würde bedeuten das es nur noch Kirin Prozessoren gibt. Offensichtlich ja nicht. Smartphone Prozessoren können nicht alles besser. Es gibt noch Fälle wo sich Smartphone Prozessoren schwertun( vor allem bei großen komplexen Berechnungen)
Versuch mal, "analog" zu denken und du wirst sehen, in diesem Lösungsraum trifft nicht ein einziger deiner Einwände auf die Situation "Signal steht auf Halt" + "Lok fährt auf dieses zu".
Alleine die Aussage”Lok fährt auf dieses zu” ist nicht ganz einfach.
Du brauchst zwei Melder um die Fahrtrichtung rauszubekommen. Das Signal braucht in der Software eine Definition der Ausrichtung. Die zwei Melder und das Signal müssen on der App eine Ortsbeziehung untereinander haben.
Bei Esu gibt es nur eine Minimallösung Von Roco würde ich wenn überhaupt auch nur eine Minimallösung erwarten.

Gruß

Matthias
 
Zuletzt bearbeitet:
Tja das würde bedeuten das es nur noch Kirin Prozessoren gibt. Offensichtlich ja nicht. Smartphone Prozessoren können nicht alles besser. Es gibt noch Fälle wo sich Smartphone Prozessoren schwertun( vor allem bei großen komplexen Berechnungen)

Nach dieser deiner Logik dürfte es keinerlei Prozessorweiterentwicklung geben, nur, weil jemand wie @Taschentroll vollkommen zu Recht feststellt, das es eine alternative Bauart gibt, die den Leistungsbereich einer Vorgängerversion erreicht hat? :fasziniert:

Und:
Finde den Fehler:
Unterscheidung von Zustand "0" oder "1" an einer endlichen zweistelligen Anzahl von Übertragungspunkten vs.
"große komplexe Berechnungen"




Alleine die Aussage”Lok fährt auf dieses zu” ist nicht ganz einfach.
Du brauchst zwei Melder um die Fahrtrichtung rauszubekommen.

Nein, brauche ich nicht. Dazu ist weiter oben mehr als einmal alles gesagt. Ich will anhalten können, wie einst analog. Punkt.
Mehr nicht. Keine "komplexen Berechnungen" notwendig.
 
Es gibt noch Fälle wo sich Smartphone Prozessoren schwertun (vor allem bei großen komplexen Berechnungen)
Nur wenn man in den 1990ern stehen gebleiben ist und versucht, hochkomplexe Probleme linear zu lösen, indem man tief verschachtelte Schleifen (oder Rekursionen) durchläuft. Im Jahr 2023 löst man hochkomplexe Probleme, indem man hochparallel rechnet: Man bildet das hochkomplexe Problem auf vieldimensionale mathematische Räume ab, codiert diese als Textur und jagt diese Textur durch die Shader-Units der GPU (fahrlässig vereinfacht).

Deshalb können ARM-Prozessoren bestimmte Algorithmen nicht. Weil diese Algorithmen hoffnungslos veraltet sind.

Und nein: Werte in eine zweidimensionale Matrix hoher Dimension eintragen und dann von Null verschiedene Werte in dieser Matrix zu suchen (darauf läuft Modellbahnsteuerung hinaus), ist kein hochkomplexes Problem. Die Rechner unserer Jugend waren lächerlich klein. Deshalb erschienen dieses trivialen Problem komplex.

@Mitropa: Habe jetzt auch die ZCAN-Spezifikation gefunden. Die übliche kaum verständliche Zimo-Lektüre. Aber es ist dokumentiert. Es sollte also möglich sein, zur 10808 kompatible Detectoren zu bauen. Finde ich gut.

Problem: Ich besitze weder einen Z21 Detector, noch eine schwarze Z21 (nur diese hat CAN und empfängt Railcom-Informationen vom Detector). Beides ist auch viel zu groß für meine Zwecke, weshalb ich zumindest kurzfristig nicht plane, gut fünfhundert Euro in solche Technik zu investieren. Lass uns man privat drüber reden, ob und wie wir diese Idee trotzdem weiterverfolgen können: Wenn wir das hier offen diskutieren kommt einfach zu viel vom üblichen "das geht nicht" Spam.
 
Zurück
Oben