Zusi-Forum

ich habe mit Daniel Schuhmanns Hilfe jetzt die Voraussetzungen, um Zusi in die Lage zu versetzen, Daten nach außen über einen Port ausgeben zu lassen. Damit könnte jedermann sich z.B. eine Software bauen, die ein externes Fahrpult ansteuert o.ä.

Ich würde gerne mal im Rückmeldung der konkret Interessierten Leute bitten, ob Daten interessant sind, die über die Führerstandsdarstellung hinausgehen.

Carsten

Würden die Registryausgabe wegfallen?

Dann bin ich interessiert, alles wieder zu bekommen, was ich jetzt schon habe

Andreas

Du wirst Dich mit Sockets statt Registry beschäftigen dürfen. Ich nehme an, dass Sockets auch in VB gekapselt sind. Spätestens ab .NET gibt es diverse Klassen, die alles sehr elegant verpacken, so dass man sich mit den Innereien kaum mehr auseinandersetzen muss.

Fragt sich nur, wer als erstes mit .NET anfängt. Solange noch W98 Systeme im Einsatz sind, habe ich da gewisse Bedenken, selbst wenn es von MS supported wird. Nur, wer lädt sich für diese älteren System denn die gewaltige .NET-Runtime runter?

Carsten Hölscher hat geschrieben:Damit könnte jedermann sich z.B. eine Software bauen, die ein externes Fahrpult ansteuert o.ä.

Ich werde selbstverständlich die Software für mein Fahrpult sowie die Schaltungen, die ich für die Ansteuerung des Pultes baue, im Internet mit Quellen veröffentlichen.

Carsten Hölscher hat geschrieben:Ich würde gerne mal im Rückmeldung der konkret Interessierten Leute bitten, ob Daten interessant sind, die über die Führerstandsdarstellung hinausgehen.

Also für meinen Teil genügen die Daten, die man auf dem Zusi-Führerstand sehen kann, aber ich will ja auch "nur" einen Führerstand nachbilden.

Roland Ziegler hat geschrieben:Du wirst Dich mit Sockets statt Registry beschäftigen dürfen. Ich nehme an, dass Sockets auch in VB gekapselt sind. Spätestens ab .NET gibt es diverse Klassen, die alles sehr elegant verpacken, so dass man sich mit den Innereien kaum mehr auseinandersetzen muss.

Fragt sich nur, wer als erstes mit .NET anfängt. Solange noch W98 Systeme im Einsatz sind, habe ich da gewisse Bedenken, selbst wenn es von MS supported wird. Nur, wer lädt sich für diese älteren System denn die gewaltige .NET-Runtime runter?

Meine ersten EBuLa/MMI Versuchen entstehen z.Zt. auf .net... Hat den Vorteil das du später auch z.B. nen kleinen Linuxrechner als EBuLa System hernehmen kannst, linux ist ja bekanntlich sehr genügsam.

Sockets in VB6 sind über ein COM Element gekapselt, in .net sind sie in der Klasse internet (glaub ich) vorhanden, und so Gewaltig is die Runtime nu auch wiede nich, nur 23MB groß...

Zu den Daten, da gebe man mir was ich bekommen kann... damit wird dann auch das Debugging von Strecken vieleicht einfacher werden, da mein Prog auch zur Darstellung der betriebsdaten hernehmen können wird...

Welches Format werden denn die Daten haben? XML?

MfG Merrlin

Merrlin hat geschrieben:Welches Format werden denn die Daten haben?

Es ist ein binäres Format, das über ein UDP-Socket ausgegeben wird. Die versendeten Datenpäckchen werden sich aller Wahrscheinlichkeit nach über eine Konfigurationsdatei einstellen lassen, so daß der Traffic gering bleibt und nur die Daten gesendet werden, die tatsächlich benötigt werden.

War da nicht mal was angedacht von wegen Koppelung mit ner Stellwerkssimu? (Siehe München-Stammtisch Version 1.0)

UDP? Keep it simple, wa?

Meine ersten EBuLa/MMI Versuchen entstehen z.Zt.

Cool, bald kann ich meinen Schlepptop als EBuLa-Rechner nutzen.

Stefan

die Geschichte mit der Datenausgabe wird konkreter. Vorgesehen ist bisher alles was es an "physik. Größen" gibt (das ist das was man im fst-Eddi eingeben kann, s. auch Doku) und zusätzlich Sim-Zeit, Zustand Türen und der nächste Blockname. Sind weitere Daten nötig? Wenn ja, dann bitte jetzt melden, habe keine Lust, wochenweise Kleckerupdates zu machen.

Carsten

So,
was vielleicht noch zum einbauen gut wäre wären folgende Ausgaben:
LM Notbremse (Vielleicht gibts sowas ja irgendwann mal im ZuSi)
Instrumentenbeleuchtung an/aus
Dann wäre es sicher nochmal cool wenn man in der Ausgabe bei der Traktion berücksichtigen könnte , wenn beim abschalten (0) ab und zu (wie in echt) die traktionsnadel nochmal in den 20kN Bereich auschlägt oder wie bei der 42x Serie ein leichtes "zittern" des Traktionsanzeigers...


So mehr fällt mir fürs erste nicht ein

Gruß
Hendrik

das mit der Beleuchtung kapier ich nicht ganz. Man wird doch nicht wieder zur Tastatur greifen, um sein Fahrpultlicht einzuschalten oder?

Carsten

Was ich brauche weisst du ja, eben das, was jetzt in der Reg. ist.

Zusätzlich interessant könnte noch sein:
- ist der AP gerade aktiv?
- ist der gefahrene Zug gerade ein Reise- oder Güterzug?

Andreas

Ja,
@Carsten : Das war für die gedacht , die keine Schalter haben ....

@Carsten:

Ich denke, er meint eine Ausgabe, ob der Fst die taghelle oder die tunnelabgedunkelte Situation meint. Er will dann sicherlich, daß Zusi sein Wohnzimmerlicht ausschaltet und die Rolläden runterfährt, wenn er durch einen Tunnel fährt.

@ Andreas: die Geschw. wird ja jetzt ständig ausgegeben, ich würde dann auf "Zug steht" verzichten, okay?

die Strecken-km hatte ich oben noch vergessen, die gibt's auch.

Carsten

Für mich als BR189-Nachbauer wäre natürlich noch die aktuelle Bahnverwaltung oder die gewählte Zugbeeinflussungsvariante nützlich (damit das MMI entsprechend andere Darstellungen zeigt), könnte aber in einem Header oder so übertragen werden und nicht ständig.

Danke vorab,

Robert

Hmm, Frameraten und F9/F11 währe nicht schlecht.

ja, Carsten, wenn ich das aus der Geschw rauslesen kann.

Wie hoch ist denn die refresh-Rate? Wie gehabt Streckenelementübergang?

Andreas

Frameraten und F9/F11

wofür das?

Refresh ist 1x je Bild, gedrosselt auf max 10/sec. (könnte man bei Bedarf einstellbar machen)

Carsten