Zusi 3 Problem mit Tastatureingaben über Arduino

[Arne aus dem Norden]

Moin,

ein seltsames Problem tritt bei mir auf.
Ich habe seit drei Jahren mehrere Arduino Leonardos für Tastatureingaben am Pult in Betrieb.
Das funktionierte bislang an Zusi 2 völlig problemlos.
Auch die Zusi 3 Demo konnte ich all die Jahre damit übers Pult fahren.
Jetzt bei der Zusi 3 Vollversion gibt es einen neuen Effekt: es gehen nur noch die Tasteneingaben, die über Tastaturfeuer programmiert sind, also für die Zeit der Betätigung dauerhaft sendende.
Logisch ausgewertete und deswegen nur einmal gesendete Tastendrücke werden von Zusi 3 jetzt nicht mehr erkannt.
Bzw. schon erkannt, aber vielleicht nur noch in einem von 30 Fällen.
Somit gehen Fahrschalter, Bremsventile und Schnellaus nun praktisch nicht mehr.
Ich hab schon diverse Versuche gemacht, Keyboard.press oder .write, delays eingebaut um die Betätigungszeit zu verlängern usw. Ergebnis: in Zusi 3: nichts. Überall anders (Texteditoren/Schreibprogramme, Zusi 2, Zusi 3 DEMO werden ALLE gesendeten Zeichen einwandfrei empfangen.
Gibt es irgendwas, womit man in Zusi 3 die "Inputempfindlichkeit" verändern kann?
Ich kann mich dunkel daran erinnern, das es irgendwann mal ne Demo gab, bei der die Tastatureingaben auch schlechter erkannt wurden...

[Carsten Hölscher]

Der Immediate-Modus in den Sim-Einstellungen hat einen Einfluss.

Carsten

[Arne aus dem Norden]

Der Immediate-Modus in den Sim-Einstellungen hat einen Einfluss.

Hi,

in diesem Fall leider nicht. Es verhält sich genau wie vorher, drei oder viermal den Fahrschalter voll aufdrehen schaltet auch im genannten Modus mit Glück nur eine Fahrstufe auf. In der Demo hingegen läuft der Fahrschalter fast synchron mit...

LG, Arne

[Carsten Hölscher]

Andere erreichte fps vielleicht?
Es sollte hier (im immediate Modus) keine wesentlichen Unterschiede zur Demo geben.

Carsten

[Gero]

Hast du schon versucht im Fahrzeugeditor die Auf- und Abschaltsperren der einzelnen Kombischalter rauszulöschen? Wäre vielleicht einen Versuch wert
Sicher aber vorher die ursprüngliche Datei oder lege dir eine Kopie an, die du dann umbaust - macht keinen Spaß das am Ende wieder zurückzusetzen

Gero

[Arne aus dem Norden]

Andere erreichte fps vielleicht?
Es sollte hier (im immediate Modus) keine wesentlichen Unterschiede zur Demo geben.

Also,

Demo recht konstante 39 bis 40 fps ohne Framebremse (Immediate aus), läuft einwandfrei.
Vollversion schwankt eher zwischen 20 und 72 fps (Marschbahn).

Immediate an oder aus ist kein Unterscheid, recht schnelles aufschalten bringt in der Vollversion noch am ehesten irgendein Ergebnis (also eine oder zwei Fahrstufen bei 15 geschalteten). Aber nicht immer.

[Carsten Hölscher]

Bin gerade nicht ganz sicher, ob sich der Immediate-Modus erst nach dem nächsten Neustart auswirkt.
Carsten

[Arne aus dem Norden]

Bin gerade nicht ganz sicher, ob sich der Immediate-Modus erst nach dem nächsten Neustart auswirkt.

Gerade nochmal probiert - die Kiste war zwischendurch komplett aus. Jetzt nochmal neu hochgefahren mit zuletzt aktiviertem Immediate-Modus: keine Veränderung. Nur ein Impuls von 15 wird erkannt in der Vollversion.

Zur Sicherheit hab ich es auch nochmal mit dem Fst. der 216 probiert und nicht nur der 218. Kein Unterschied, Demo läuft, Vollversion nicht.

[Carsten Hölscher]

Dazu fällt mir jetzt auch nichts mehr ein.

Carsten

[Arne aus dem Norden]

Ich wäre ja sonst schon an der Version TCP in, das ist vermutlich leichter mit dem senden als mit dem auslesen der Struktur. Aber nach Michaels Meldung mit den Problemen der H-Bremse etc. dachte ich es wäre erstmal der einfachere Weg, für den Moment noch bei der bislang eigentlich funkionierenden Leonardo-Lösung zu bleiben...

Zumal die abwärtskompatibilität mit Zusi 2 beim Pult so gegeben wäre, da alle Arduinos mit ihren alten Scripten weiterlaufen könnten. Aber dann muß ich testen mit TCP Eingaben...

[Michael_Poschmann]

Grundsätzlich läuft TCP ja bei uns schön stabil. Die wenigen Detailfehler (Angleicher, H-Bremse) werden sicherlich auch gelegentlich mal von Carsten analysiert, bis dahin üben wir uns halt ein wenig in Geduld.

Grüße
Michael

[Carsten Hölscher]

Was stabil läuft, ist auf jeden Fall der Direct-Input-Weg. H-Bremse wird schwer zu analysieren sein ohne die Hardware vor Ort. Für den Angleicher gibt es einen simplen Workaround, der aber aus irgendwelchen Gründen nicht zum Einsatz kommen sollte.

Carsten

[F. Schn.]

-Bremse wird schwer zu analysieren sein ohne die Hardware vor Ort.

Vorschlag: Michael verbindet sich mit einem Rechner deiner Wahl über Internet. Dazu musst du nur im Router eine Portweiterleitung erstellen und Micheal deine IP-Addresse geben.

mit Zusi 2 beim Pult so gegeben wäre

Ich habe vor, sobald ich in die .Net-TCP-DLL die Möglichkeit der Tastendrücke habe, einen Umgekehrten Konverter Zusi2=>Zusi3 zu bauen, der dann über Windows-Messages die Tastendrücke direkt an Zusi 2 weitergibt.

[Michael_Poschmann]

Hallo Carsten,

H-Bremse wird schwer zu analysieren sein ohne die Hardware vor Ort.

Die Hardware sollte eigentlich nicht erforderlich sein, so nicht vorhanden. Olis Software sendet schließlich Daten über die Schnittstelle, keine Ströme. Sicherlich kann Herr Lamm bei Bedarf noch mal rückmelden, wie seine Datentelegramme aussehen, sofern erforderlich - bei Bedarf bitte fragen.
Aber dass sich der Hebel im Zusi3-Grafikführerstand bewegt, ist ja schon mal ein dickes Indiz dafür, dass ein Kommando übertragen wird, das die H-Bremse ansteuert. Und bisweilen kommt ja wie beschrieben auch die Bremsleistung inkl. LM mit.

Für den Angleicher gibt es einen simplen Workaround, der aber aus irgendwelchen Gründen nicht zum Einsatz kommen sollte.

Wie sähe denn der Workaround aus? Alles was irgendwie Abhilfe schaffen könnte, ist zumindest zur Überbrückung der Zeit bis zur finalen Behebung willkommen.

Grüße
Michael

[Oliver Lamm]

Hi,

hatte ich schon mal geschrieben, aber gerne nochmal:

Ich sende absolute Werte der Stellung der H-Bremse von 0 - 9 (wobei 9 Fahrtstellung ist)

Code: Alles auswählen

        /* Now we determine the nine steps of the H-Bremse */
	GSList *ptr = NULL;
	for ( n = 0; n < i2ccon->points; n++ ) {
		ptr = g_slist_nth( i2ccon->point, n );
		if ( i2cdata == GPOINTER_TO_INT( ptr->data ) ) hbremse = n;
	}
	zusiSetHBremse( hbremse ); 

Die neun Positionen sind als Liste in der Konfiguration abgelegt. Ich lese über i2c einen gesamten Port aus, maskiere die Bits und dieser Wert wird benutzt.

Code: Alles auswählen

/*
 * Function to set the H-Bremse in Zusi
 */
void zusiSetHBremse( int value ) {
	if ( value > brake_state->hbrake ) {
		zusiSendCommand( KEY_ASSIGNMENT_DYNBREMSE, KEY_COMMAND_DYNBREMSE_AUF_DOWN, KEY_ACTION_ABSOLUT, value ); /* Key pressed */
		zusiSendCommand( KEY_ASSIGNMENT_DYNBREMSE, KEY_COMMAND_DYNBREMSE_AUF_UP, KEY_ACTION_ABSOLUT, value ); /* Key released */
		brake_state->hbrake++;
		zusiSetHBremse( value );
	}
	else if ( value < brake_state->hbrake ) {
		zusiSendCommand( KEY_ASSIGNMENT_DYNBREMSE, KEY_COMMAND_DYNBREMSE_AB_DOWN, KEY_ACTION_ABSOLUT, value ); /* Key pressed */
		zusiSendCommand( KEY_ASSIGNMENT_DYNBREMSE, KEY_COMMAND_DYNBREMSE_AB_UP, KEY_ACTION_ABSOLUT, value ); /* Key released */
		brake_state->hbrake--;
		zusiSetHBremse( value );
	}
}

Der ausgelesene Wert wird mit dem letzten Wert verglichen und entsprechend neu gesendet.

Code: Alles auswählen

...
               char send_cmd[] = { 0x00, 0x00, 0x00, 0x00, 0x02, 0x00, 0x00, 0x00, 0x00, 0x00, 0x0a, 0x01, 0x00, 0x00, 0x00, 0x00, 0x01, 0x00, 0x04, 0x00, 0x00, 0x00,
				0x01, 0x00, 'k', 0x00, 0x04, 0x00, 0x00, 0x00, 0x02, 0x00, 'c', 0x00, 0x04, 0x00, 0x00, 0x00, 0x03, 0x00, 'a', 0x00, 0x04, 0x00, 0x00, 0x00,
				0x04, 0x00, 'v', 0x00, 0x06, 0x00, 0x00, 0x00, 0x05, 0x00, 0x00, 0x00, 0x00, 0x00, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
				0xff, 0xff };

		*len = sizeof( send_cmd );
		char *data = g_new0( char, *len );
		if ( data == NULL ) g_error( "%20s:%d - Error allocating data structure to send (Length: %d)", __FILE__, __LINE__, *len );

		memcpy( data, send_cmd, *len );
		data[24] = zd->key;      // Tastaturzuordnung
		data[32] = zd->cmd;      // Tastaturkommando
		data[40] = zd->act;      // Tastaturaktion
		data[48] = zd->value;    // Wert
...

Anschliessend werden die Werte in die Sendestruktur eingebettet und das ganze an Zusi zurückgesendet. Läuft ja für alle anderen Befehle auch sehr stabil.

Oli

[Carsten Hölscher]

Die Angleicherfunktion auf eine andere Tastaturzuordnung legen, wie seinerzeit schon mal vorgeschlagen.

Die H-Bremse hört sich größerer Analyse an. Im Moment hab ich dazu keine Zeit. Wenn ich das Ganze live sehen würde, würde mir möglicherweise eine Idee kommen. Vielleicht wär ja mal ein kleines Video machbar.

Carsten

[Michael_Poschmann]

Was das Video zeigen würde - ich versuche es demnächst mal mit dem smarten Phone:

- Zug fährt mit > ca. 50 km/h
- Bremsbedienung, wahlweise gekoppelt oder nur H-Bremse
- Führerstandsgrafik zeigt insbesondere beim ersten Bremsversuch korrektes Verhalten, d.h. H-Bremssteller "kommt mit" in den passenden Stufen, LM H-Bremse leuchtet, Verzögerung des Zuges entsprechend der gewählten Bremsstufe

Weiter Variante A
- Auslösen der Bremse
- LM erlischt
- Bremssteller in Zusi-Grafik geht wieder in Fahrtstellung
- H-Bremswirkung entfällt.

Oder Variante B
- Abbremsen in Richtung Stillstand
- Bei Unterschreiten der Umschaltgeschwindigkeit fällt H-Bremse ab, LM erlischt, H-Brems-Wirkung entfällt

Bei einem zweiten, dritten oder vierten Bremsversuch (meist schon beim zweiten, vielleicht ist das ein Ansatzpunkt?!) bleibt LM H-Bremse aus und die Bremswirkung fehlt. Der H-Brems-Griff in der Führerstandsgrafik bewegt sich jedoch analog zur Bremsstufe des Hardware-Bremsstellers und des detektierten Schaltlogik-Signals.

Grüße
Michael

[Carsten Hölscher]

Zeigt der Zugstatus dann was Rotes an?

Und dasselbe per Tastatur nachgespielt ist i.o.?

Carsten

[Michael_Poschmann]

Zugstatus meint Fehlermeldungen? Muss ich dieser Tage mal prüfen.

Heute hatte ich den Fall, dass nach dem Aussetzen der H-Bremse am Fahrpult sich diese auch per Tastatur nicht mehr zum Leben erwecken ließ. Auch da werde ich versuchen, das nachzustellen und eine Gesetzmäßigkeit abzuleiten.

Nachtrag: Tests gerade mit mehrfachem Bremsen ausschließlich per Tastatur verliefen unauffällig, alles korrekt. Da scheint also initial von Seiten der TCP-Schnittstelle irgendetwas zu kommen, was den Simulator außer Tritt bringt.

Grüße
Michael

[Michael_Poschmann]

Die Angleicherfunktion auf eine andere Tastaturzuordnung legen, wie seinerzeit schon mal vorgeschlagen.

Wäre das ohne Änderung an der Fahrzeugdatei machbar? Vermutlich ja. Sonst müsste ich ja ebenfalls wieder (wie beim aktuellen Auskommentieren des Angleichers) in der Bestands-Konfiguration herumwerkeln. Davon wollten wir eigentlich wegkommen.
Aber was ist der Unterschied, ob Angleicher auf Taste X oder Y liegt? Zusi-seitig wird das, sofern ich es nicht mißverstehe, ja doch wieder auf das gleiche Eingangssignal zusammengeführt. Das dürfte an dem simulatorseitigen Fehlverhalten dann doch nichts ändern?

Grüße
Michael