Zusi-Forum

Bono hat geschrieben:wie das legendäre BAHN.EXE, wenn sich jemand an das noch erinnern kann

Wieso erinnern? Das gibts doch heute noch und es wird immer noch entwickelt. Version 3.8 ist von August 2003.

http://www.jbss.de/

Daniel

Dieses Wochenende auf der FUNTEC/Modellbaumesse habe ich ein interessantes Teil gesehen (vielleicht ist das sowieso allen seit langem bekannt, für mich war es neu):
Es handelt sich dabei um ein Cockpitgerät für den FSIM und es besteht aus 2 Teilen:
1. einer Konsole mit jeder Menge Schalter und Regler und
2. aus einer Plastikabdeckung für den Bildschirm mit runden ca. 8-15cm großen Löchern an den richtigen Stellen, durch die die am Bildschirm dargestellten Rundinstrumente (Höhenmesser, künstl. Horizont etc.) tatsächlich fast so wie Einzelinstrumente aussehen.

Eine allgemein verwendbare Anwendung für den Datenaustausch wäre daher ein "Zusi-Instrumentenslave". D.h. der FstEditor könnte ja z.B. wahlweise einen konventionellen Führerstand erzeugen oder die Instrumente in einen solchen SLAVE legen.
Anders gesagt: Man fährt Zusi im "reinen Landschaftsblick" bzw. in einem Fst Blick, der im wesentlichen nur die Fensterumrahmungen rund um das 3D Fenster darstellt.
Und die Instumente werden in einem Slave Programm dargestellt (die neueste Ebula Version ist eigentlich schon genau so etwas). - und mithilfe einer wie oben beschriebenen "Lochscheibe" lässt sich dann schon ein recht gut aussehender Fst aufbauen.

Ideas?

Hallo,

ich will eine GPS-Ausgabe für den Zusi schreiben. Dann könnte man z. B. einen Routenplaner anschliessen und die aktuelle Position der Lok auf der Karte beobachten.
Optimal wäre eine TCP-Ausgabe in Länge, Breite, Höhe in WGS84 oder in UTM Koordinaten.
Ich nehme an, das ist zu aufwändig. Ausreichend wäre auch die Position in xyz und der Dateiname (inkl. Pfad) der aktuellen Strecken-Datei. Dann kann ich die Umrechnung selber machen.

Joachim

die Daten müßte Zusi aber zur Verfügung stellen, was im Moment nicht passiert.
Eine Nachrüstung (x-, y-, z-Koordinaten der Zugspitze so wie es Streckeneditor steht, also mit Offset gegenüber UTM) wäre schon vorstellbar, aber welchen Sinn soll das denn haben? Wer schaut sich seine Fahrt schon parallel auf der Landkarte an?

Carsten

noch einmal die Frage nach den Strings (nächstes Signal). Jörg Petri hatte ja in anderem Thread Probleme gemeldet. Wenn ich die Beiträge hier lese, dann scheint es aber schon zum Laufen gebracht worden sein. Kann da mal jemand was zu sagen?
Sonst bräuchte ich bitte mal eine Anwendung, die strings anfordert und darstellt. Sonst ist es für mich nur schwer zu debuggen (ich nehme an, jemand hat sowas?

Carsten

Carsten Hölscher hat geschrieben:noch einmal die Frage nach den Strings (nächstes Signal). Jörg Petri hatte ja in anderem Thread Probleme gemeldet. (...)

Hallo,
ich prüfe die String-Geschichte heute mal ausführlich. Ergebnisse dann heute Abend.

MfG Jens

ich prüfe die String-Geschichte heute mal ausführlich. Ergebnisse dann heute Abend.

Hallo,
hier die Ergebnisse:

1.) Datenübertragung via TCP-Server 1.1:
- String-Datentypen angefordert
- korrekte Anzeige im Zusifenster
- keine Übermittlung dieser Datentypen

2.) Datenübertragung direkt mit Zusi:
- String-Datentypen angefordert
- korrekte Anzeige im Zusifenster
- ebenfalls keine Übermittlung dieser Datentypen

Ich habe extra einen Führerstand eingesetzt der die passenden Melder enthielt.

==> Zusi sendet keine Daten von Stringdatentypen.

MfG Jens

Ich bekam eben auch ein email von einem "Forum-Nicht-Schreiber", daß ab Zusi V 2.4.3.5 keine strings mehr gesendet werden. Mir war das Problem nicht bewußt Das erklärt die älteren Beiträge mit funktionierenden strings.
Kannst Du mir bitte ein Programm mit string-Anforderung zum Debuggen geben?

Carsten

Carsten Hölscher hat geschrieben:Kannst Du mir bitte ein Programm mit string-Anforderung zum Debuggen geben?

Wird gemacht.

MfG Jens

Hallo Leute,
ich programmiere ein Zusi-TCP Client in Python. Ich kann Zusi um Daten bitten, und ich bekomme z.B. die folgende hexadezimale Daten:
vakt = 1 km/h ---> 0x57, 0x76, 0x16, 0x3F.
Wie kann ich die aktuelle Geschwindigkeit von diesen Daten ausrechnen? Und wie funktionert das Methode mit anderen Daten (z.B. Motordrehzahl, PZB LM, Sifa LM, u.s.w.)?
Ich habe schon viel über das Thema gelesen, aber es ist schwer mir auf Deutsch lesen, und ich habe kein Hilfe finden gekonnt…
Ich hoffe, mein Problem lässt sich gut verstanden, und Entschuldigung für alle grammatisch Fehler!
Vielen Dank, und herzliche Grüße aus Ungarn!

Die Daten ist auf IEEE-754 in 32-bits codiert(ein 'float' in C/C++). In C, können Sie einfach die Binärdaten in ein float umwandeln, aber in Python Ich glaube, dass es nicht so einfach ist.

Ich glaube nicht, dass ich das Ganze des Zusi TCP-Format zu erklären können. Die genaue Datentyp und Format aller Daten ist in der Zusi-Dokumentation.
Ich denke, dass die Motordrezahl auch IEEE-754 ist. PZB LM sind in einer speziellen Struktur.

Es könnte hilfreich sein, TCP-Clients in anderen Sprachen zu sehen: http://forum.zusi.de/viewtopic.php?f=73&t=12650" target="_blank

In Python benutzt man dazu struct.unpack.

Ich habe schon die IEEE Struktur auspropiert, aber ich habe große Nummern bekommen (z.B. v = 10 km/h ---> 1,5 * 10⁸). Ich habe aufsteigende Nummern erwartet, aber das seht ganz random aus. Ich habe das Exponent und Mantissa auch betrachtet – das ist auch nich so hilfreich gewessen.
Ich habe dieses Programm (http://forum.zusi.de/viewtopic.php?f=25&t=11754) als Programmbeispiel benutzen. Das ist am hilfreichsten gewessen.

Das ist kompliziert, in Python in IEEE 754 zu konvertieren, aber numpy hat float32 Datatyp.

Benutzen die Struct Klasse ist kompliziert. Man muss die Länge des Datas wissen. Das ist einfacher, bytearray() und map() Befehlen zu benutzen. Z.B. bytearray(data) für schicken und map(ord,data) für bekommen.

Einfacher als mit der Struct-Klasse geht es ja nun wirklich nicht. Die Laenge eines Floats ist immer 4 Byte.

Das Arduino-Beispiel nutzt Casts, was in Python so nicht geht und ausserdem annimmt, dass der Prozessor Intel-Byte-Order verwendet.

Hier ein Python-Beispiel, in dem man auch die Nutzung der Struct-Klasse sieht.

Hallo,
ich habe das Wurzel des Problems entdeckt! Euere Antworten hat mir nicht gepasst, weil ich habe das schon gewisst. Deshalb ich habe die numpy float32 Konvertierung übergeprüft. Ich finde numpy tut nicht, was ich erwartet habe. Deswegen habe ich ein kurzes Programm für IEEE 754 Konvertierung geschreiben und das funktioniert! Jetz alle Daten sind korrekt!

Na ja, mit struct scheint das wirklich einfacher. Man kann viele übrige Rechnungen vermeiden. Später ersetze ich das in meinem Programm.

Ich danke alles!