TCP-Protokoll nicht mehr sinnvoll interpretierbar

Das Unterforum für Diskussionen rund um die Technik, Bedienung, Konfiguration usw. Das ist auch die erste Anlaufstelle für Bastler mit Fragen zu den Editoren.
Antworten
Nachricht
Autor
Benutzeravatar
Holger Maaß
Beiträge: 1037
Registriert: 18.07.2016 16:56:45
Aktuelle Projekte: TriFan/ZusiOSBridge
ZusiMeter 2021
ZusiStart
ZusiObjektAlbum
nette Tools für nette Zusianer
Wohnort: Berlin

TCP-Protokoll nicht mehr sinnvoll interpretierbar

#1 Beitrag von Holger Maaß »

Moin,

die Übertragung des Knotens 2.A.65.3 für LZB-Bauarten scheint mir völlig aus dem Ruder gelaufen zu sein. Ab dem Attribut 0x20 (Melder Prüf/Stör an) kommen keine sinnvollen Daten mehr vom Zusi. Ich habe mal versucht, die Daten manuell zu interpretieren:

Code: Alles auswählen

            00 00 00 00
            03 00
            	... 
                20 00 03 00				// falsche Reihenfolge, Attribut-ID kommt vor Länge
                00 00
                00
		
		// ok
                06 00 00 00
                21 00
                00 00 80 BF
				
                06 00 00 00				// Länge stimmt nicht mit den übertragenen Daten überein. Der Wert (Zielgeschwindgkeit (Single, 4 Byte) wird nicht übertragen
                22 00
				
                06 00 00 00				// Länge stimmt nicht mit den übertragenen Daten überein. Erwartet wird ein Single (4 Byte), übertragen wird ein Double (8 Byte)
                23 00
                00 00 00 00 00 00 80 BF
			
		// ok	
                03 00 00 00
                24 00
                00
				
                25 00 03 00				// falsche Reihenfolge, Attribut-ID kommt vor Länge. Datenwert wird überhaupt nicht übertragen, Länge ist somit falsch
                00 00
			
		// ok	
                03 00 00 00
                26 00
                00

		// ok
                03 00 00 00
                27 00
                00
				
                03 00 00 00
                38 00 
                00 
		
		// die folgenden 6 Byte ergeben keinen Sinn
		00
		03 00 00 00 
		00 

		39 00 03 00				// falsche Reihenfolge, Attribut-ID kommt vor Länge
		00 00 
		00 
				
		03 00 00 00				// falsche Reihenfolge, Attribut-ID kommt vor Länge. Datenwert wird überhaupt nicht übertragen, Länge ist somit falsch
		3B 00 
			
		3A 00 					// Reihenfolge komplett vertauscht (ID, Daten, Länge?)
		00 
		03 00 00 00 
				
		3C 00 					// Reihenfolge komplett vertauscht (ID, Daten, Länge?)
		00 
		03 00 00 00 
		
		00 						// alleinstehendes 0-Byte
				
		// ok, aber nicht dokumentiert
		03 00 00 00 
		4E 00 
		00 
				
		// ok, aber nicht dokumentiert
		03 00 00 00 
		4F 00 
		00 
            FF FF FF FF 
Ist das wirklich so, oder ist mein Code kaputt?

Gruß
Holger
If you can't fix it with a hammer, it might be an electrical problem ...
Wenn es auch das nicht ist, schreibe an service ät zusi-tools punkt org.

Benutzeravatar
Carsten Hölscher
Administrator
Beiträge: 33384
Registriert: 04.07.2002 00:14:42
Wohnort: Braunschweig
Kontaktdaten:

Re: TCP-Protokoll nicht mehr sinnvoll interpretierbar

#2 Beitrag von Carsten Hölscher »

Was sagt denn das Demotool aus dem Zusi-Umfang?

Carsten

Benutzeravatar
Holger Maaß
Beiträge: 1037
Registriert: 18.07.2016 16:56:45
Aktuelle Projekte: TriFan/ZusiOSBridge
ZusiMeter 2021
ZusiStart
ZusiObjektAlbum
nette Tools für nette Zusianer
Wohnort: Berlin

Re: TCP-Protokoll nicht mehr sinnvoll interpretierbar

#3 Beitrag von Holger Maaß »

Oh je, das hat mich etwas Schlaf gekostet. Ich muss alles zurück nehmen. Das soll ja jetzt nicht das Programmiererforum werden, aber für die, die es interessiert, eine kurze Zusammenfassung, was passiert ist. Im Rahmen der Aufarbeitung der Programme bin ich endlich von Visual Studio 2015 auf Visual Studio 2019 umgestiegen. Der Quellcode für den Teil, der die TCP-Daten empfängt und ins Programm bringt, habe ich (noch) nicht verändert. Also seit es ZusiMeter gibt, hat der Code so funktioniert. Damit ein Programm bedienbar bleibt, während es auf Daten vom Netzwerk wartet, geschieht diese Datenverarbeitung in einem Nebenthread. Erst wenn die Daten im Fenster des Programmes sichtbar gemacht werden sollen, müssen die in den Hauptthread gebracht werden. Alles für den Benutzer sichtbare kann nur im Hauptthread erledigt werden. In der von mir verwendeten Programmiersprache C# schreibt man dazu

Code: Alles auswählen

Dispatcher.Invoke(new Action(() => ...));
Die drei Punkte symbolisieren die Aktion, die man durchführen möchte. Der Aufruf Dispatcher.Invoke war bisher immer synchron. Das ist er nun ganz offensichtlich nicht mehr. Dadurch, dass Dispatcher.Invoke nun asynchron arbeitet, kommt es zum willkürlichen Vertauschen der vom Zusi gesendeten Daten. Ein Datenpaket, was vom Nebenthread früher als ein anderes abgeschickt wurde, kommt nun plötzlich später im Hauptthread an. Das ist ein Katastrophe!

Entschuldigt bitte, dass ich das gestern noch nicht gesehen und deshalb diesen Thread eröffnet habe.

Gruß
Holger
If you can't fix it with a hammer, it might be an electrical problem ...
Wenn es auch das nicht ist, schreibe an service ät zusi-tools punkt org.

Antworten