PZB Würfel

  • Hi, mir ist da was im Gedanken rumgeschwirrt das ich gleich hier zur Frage stelle bevor ich es vergesse.. :)
    So wie ich das bis jetzt verstanden habe gibt es kein PZB Grundprogramm im TS, dh die PZB's der verschiedenen Loks funktionieren nur so gut bzw genau wie der Erbauer der Lok es programmiert hat.
    Kann man das ganze nicht so Programmieren das wenn zb eine Beeinflussumg stattfindet im Hintergrund des Pc ( also nicht vom Spiel aus) das Programm des Arduino angesteuert wird das mir den BZP Block zum leuchten bringt? Ich weis der TS gibt nichts aus und Zusi kann es, aber ich wrde gern wissen ob das vielleicht möglich währe.. Könnte man dann ja auch mit verschiedenen anderen Anzeigeelementen machen.. lg

  • Der TS hat Standarts, nur die kennen wenige.
    Was ALLE Signale an ALLE PZB auch unterschiedlicher Hersteller senden (siehe Signalteam-Docus) und was dann da an die Loks gesendet wird, ist bekannt (KUJU_PZB Luas sind lesbar und da stehen die Meldungsvariablen drin) und überall gleich, also Standart.


    Nur in den Loks wirds danach unterschiedlich verarbeitet. Von nix bis die irrsten Sachen gibts die volle Bandbreite.
    Da was zu machen, das das ergänzt, viel Spass.
    StS

    Keine Hilfe und Auskunft per PN, da meist von allgemeinem Interesse. Diese Fragen bitte im Forum stellen.

  • Dazu müsste je ein Client für deinen Arduino und deinen PC -auf dem der TS läuft- programmiert werden.
    Am besten mit TCP/IP-Protokoll.
    Wie man den Kram auf der TS-Seite allerdings auslesen will, so dass der PC-Client das dann an den Arduino-Client schicken kann, ist ne andere Geschichte, und müsste vermutlich von jeder einzelnen Lok unterstützt werden.


    Kurz:
    Vergiss es!

    Egal, wie weit Draußen man die Wahrheit über Bord wirft, irgendwann wird sie irgendwo an Land gespült.

  • Natürlich kann er das nicht.


    Daher müsste das ja von der Lok durch deren Script erledigt werden, indem es eine Datei ablegt, deren Existenz dann möglichst zeitnah von dem (zu programmierenden) PC-Client erfasst und deren Inhalt ausgewertet wird, der wiederrum mittels z.B. TCP den Arduino anspricht.
    Eine andere Möglichkeit sehe ich nicht.


    Kurz: Total sinnlos... allein das dadurch entstandene Lag wegen des Umwegs über eine Dateiausgabe lässt das Ganze schon scheitern.
    Und sonderlich performant wäre das auch nicht, weil der Client dauernd pollen müsste: Ist da jetzt eine Datei für mich? Nein, 1 Sekunde warten. Ist da jetzt eine Datei für mich? Nein, 1 Sekunde warten.Ist da jetzt eine Datei für mich? Nein, 1 Sekunde warten....


    Anders sähe es aus, wenn das kastrierte LUA des TS selbst in der Lage wäre, TCP (oder ein anderes netzwerkprotokoll) zu handhaben. Wäre mir aber neu dass LUA das kann.

    Egal, wie weit Draußen man die Wahrheit über Bord wirft, irgendwann wird sie irgendwo an Land gespült.

    Einmal editiert, zuletzt von Prelli ()

  • Ja das der Ts nicht ausgibt hab ich auch schon gehört.. Aber ich denke mir da eher sowas wie @Prelli schreibt das das Skript der Lok das ganze erledigt. Einfach gesagt die Lok bekommt eine Beeinflussung die bestätigt wird und mit der Bestätigung löst das Skript der Lok einen Befehl im Hintergrund aus (was auch immer) der dann das Arduino mit Daten versorgt.. Allerdings war das auch schon ein Gedanke meinerseits, das es dann immer ein wenig hinten nach hinkt.. Wie viel das dann im Endeffekt ausmacht und ob es störend ist mit komplettem Fahrpult sieht man dann eh..
    Aber ob es in der Praxis so funktioniert wie ich es mit in der Theorie vorstelle ist hald auch ne andere Frage :lolx2:

  • und mit der Bestätigung löst das Skript der Lok einen Befehl im Hintergrund aus (was auch immer) der dann das Arduino mit Daten versorgt.

    "was auch immer" gefällt mir. :D Mit Magie vielleicht?

    Egal, wie weit Draußen man die Wahrheit über Bord wirft, irgendwann wird sie irgendwo an Land gespült.

    Einmal editiert, zuletzt von Prelli ()

  • Ja ich könnt mal Uri Geller anrufen ;) Nein mal im ernst hab ja keine Ahnung davon.. Aber ich bin dabei mir ein Führerpult zu bauen und hab mir da so ein paar Gedanken gemacht.. Später hab ich auch mal in Planung ein paar Loks zu bauen und dann dacht ich mir mal ich frage ob es so vielleicht möglich währe Daten aus dem Ts zu bekommen..

  • Vielleicht solltest du mal Maik Goltz kontaktieren. Ich könnte mir vorstellen das der dir genaueres sagen kann ob so etwas überhaupt mit dem TS machbar ist.
    Vorausgesetzt er hat überhaupt die Zeit und Interesse auf so etwas zu antworten. Ein Versuch ist es ja wert bevor man hier irgendwelche Luftschlösser baut die dann hinterher wie eine Seifenblase zerplatzen.

  • Die RailDriver API ist ja relativ neu, was ich weiß... ab TS2015? TS2016?
    Insofern könnte vielleicht -wenn man einen geeigneten Client für das zweite Gerät (hier Arduino) hätte, es durchaus möglich sein, diverse Sachen ansteuern/anzeigen zu lassen.


    Vielleicht kann man sogar Zusi-Display dafür missbrauchen?


    Vielleicht ist das Ganze ja doch nicht so sehr abwegig?

    Egal, wie weit Draußen man die Wahrheit über Bord wirft, irgendwann wird sie irgendwo an Land gespült.

  • Train Maps werde ich mir morgen mal anschauen, runtergeladen habe ich es mal. Maik Goltz habe ich auch geschrieben.


    Eingaben sind kein Problem, werden einfach über das Arduino Programmiert.. Nur das mit den Ausgaben wird ein heikles Thema :ugly:


    Antwort von Maik:


    Hallo StefanDa geht schon was aber ganz so einfach ist das nicht, denn das will wohl überlegt sein. Dein Ansatz ist nicht zu machen. Datenaustausch über Dateien (was aus dem Script heraus nur so gehen würde) ist nicht gut und inperformant. Was man machen muss ist einen Client für die API des TS zu schreiben. Viele gehen davon aus, dass die Raildriver.dll im TS nur für den Raildriver wäre. Dem ist nicht so. Das ist eine normale API die man auch anders verwenden kann. Diese API wurde vor kurzen sogar deutlich erweitert und nun kann man alle Controllerdaten einer Lok ein- und ausgeben über die API. Man kann nicht auf das Script eines Fahrzeugs direkt zugreifen. Man muss die zu lesenden und schreibenden Daten über Controller im Blueprint der Lok steuern. Das jetzt genau hier auszuführen geht zu weit. Da muss erst mal ein Konzept her. Auch müssen die Fahrzeuge dazu angepasst werden, zumeist. Da ist eine gehörige Logik von Nöten. Nachhaltigkeit ist das Zauberwort.Ein, und der einzige Ansatz den ich sehe, ist einen TCP Client zu programmieren. So wie bei ZUSI auch. Der Client greift sich die API und gibt die Daten dann ein und aus. TCP deswegen, weil man dann einige weitere Möglichkeiten hat, wie Tablets als Displays und eingens gebaute Fahrtische als Eingabe/Ausgabe zu verwenden. Alles machbar in gewissen Grenzen. Das Problem ist, dass man Jemanden braucht der in C++ einen solchen Client schreiben kann und zwar sauber und ordentlich. An sich keine große Sache für einen der das kann. Das TCP muss dann natürlich sauber dokumentiert und Beispielanwendungen vorgezeigt werden. Ich habe irgendwo von DTG auch ein winziges Paper wo drin steht was die neue API kann und wie man sie verwendet.Soweit dazu. Du kannst den Text hier im Forum auch ausbreiten. Ich wäre sogar bereit jemanden der sich zutraut so einen Client zu schreiben unter die Arme zu greifen mit Wissen um den TS und auch Geld. Es muss halt nutzbringend sein. Eigene Süppchen sollten hier nicht gekocht werden.Gruß Maik

  • Ich habe die Doku gefunden. :) Aber irgendwie hatte ich in Erinnerung das da mehr drin stand... Naja, ein Anfang ist es. Ist im Anhang.


    Den alten Artikel habe ich auch hier im Archiv gefunden.


    Edit: Einen TCP Client in .NET zu programmieren würde ich mir auch zutrauen, aber mir fehlt da einfach die Zeit in naher Zukunft etwas vorzeigen zu können.