TwinCAT 2: Vermischen von Empfangsbuffern bei TCP Client Verbindungen

[ADS_0x1]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo Forum,

ich habe vielleicht ein allgemeines Verständnisproblem bei TCP/IP Verbindungen aus TwinCAT heraus, daher möchte ich lieber noch einmal euch fragen. Folgende Situation:

Auf meiner CX9020 läuft TwinCAT 2 und des TCP/IP Supplement, ich kann erfolgreich Verbindungen aufbauen und Daten abfragen. Bisher im Einsatz ist das ganze um folgende Geräte anzusprechen:

- rPI mit node-sonos-http-api zum Anbinden der Steuerung an meine Musikanlage
- TCP-IP to RS485 Umsetzer zum Anbinden einer Wetterstation
- TCP-IP Gateway zur Abfrage von 1wire Temperaturdaten

Verbindung mit dem rPI und dem 1wire-Gateway laufen über OSCAT - Bausteine (HTTP_GET), die Wetterstation wird über einen eigenen Baustein abgefragt, der mit den vier Bausteinen von Beckhoff arbeitet (SocketConnect, SocketReceive, SocketSend sowie SocketClose - wobei Send nicht verwendet wird).

Da das 1wire Gateway mit mehr und mehr Sensoren die abgefragte XML-Datei ab absurdum wachsen lässt, bin ich gerade dabei die Abfrage zu Ändern, das HTTP Get herauszunehmen und stattdessen über das 'Low Level 1wire Interface' zu gehen. Ich bin gerade dabei den Baustein dafür zu entwickeln und stoße da auf ein paar Ungereimtheiten:

Im Empfangsstring für die 1wire Verbindung habe ich die gewünschten Ergebnisse drin stehen ('?$R?N' bei erfolgreicher Verbindung, 'N$R?N' bzw. 'P$R?N' bei Reset des Bus). Allerdings sind an diese Ergebnisse immer noch irgendwelche Zeichen angehangen gewesen. Ich konnte dies erst nicht zuordnen, merkte dann aber, dass dies Zeichen eines Requests oder einer Antwort nach HTTP Get waren ('http/1.1 ...'). Gut, hab mir gedacht, dass ich so doof war und die vorherige Abfrage über HTTP Get nicht auskommentiert hätte - dem war aber nicht so. Ich hab dann schließlich sogar in den 'alten' Bausteinen alle Zeilen auskommentiert und anschließend sogar die Bausteine gelöscht und das Phänomen tritt weiterhin auf.

Schlimmer noch: Teilweise sind sogar Elemente aus der Kommunikation mit dem Sonos rPI vorhanden, Beispiel: 'P$R$Nuerklingel.mp3/45'

Bisher dachte ich, dass bei jedem Aufruf von SocketConnect ein unique handle für die session erstellt wird und dann für dieses handle -jeweils- Empfangs- und Sendebuffer existiert. Scheinbar werden diese Sachen aber nun in ein Buffer geworfen.

Nun die konkrete Frage: Existiert für TCP Verbindungen nur jeweils ein Sende- und Empfangsbuffer und ich lag bisher in meinen Annahmen falsch?

Vielen Dank für eure Hilfe!

 

[oliver.tonn]

Hallo ADS_0x1,
es kann sein, dass Du Dich aber auch ins Bockshorn hast jagen lassen. Ich hatte die Tage einen ähnlichen Fall, wo bei einer seriellen Übertragung im Puffer anscheinend auf einmal unsinnige Daten drin standen, was aber nicht der Fall war. Der Puffer wurde an mehreren Stellen im Projekt allerdings nicht gleichzeitig verwendet und so habe ich beim Beobachten an einer Stelle im Projekt auch immer die Daten angezeigt bekommen wenn der Puffer gerade woanders verwendet wurde. Entscheidend ist, dass er zu dem Zeitpunkt wo der beobachtete Code ausgeführt wird den richtigen Inhalt hat.
Handle und Puffer sind zwei paar Schuhe Du kannst verschiedene TCP-Verbindungen aufmachen und somit mehrere Handles haben, aber die Bausteine für den Empfang und das Senden können trotzdem den selben Puffer verwenden, das ist ja abhängig davon, ob Du jedem Baustein wirklich einen eigenen Buffer zuweist oder halt einen globalen nutzt.

 

[ADS_0x1]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo und Danke für die Antwort Oliver,

Ich habe bewusst lokal in der Instanz den Buffer definiert:

	TCP_Receive		: 	FB_SocketReceive;	s_s_receive_buffer	: 	STRING[512];
	s_b_receive_execute	: 	BOOL;
	s_b_receive_busy		: 	BOOL;
	s_b_receive_error		: 	BOOL;
	s_n_receive_recBytes	: 	UDINT;
	s_n_bytecount		: 	INT;


	TCP_Send			: 	FB_SocketSend;
	s_n_send_cbLen		: 	UDINT;
	s_s_send_befehl		: 	STRING[512];
	s_b_send_execute	: 	BOOL;
	s_b_send_busy		: 	BOOL;
	s_b_send_error		: 	BOOL;
	s_b_befehl_senden	:	BOOL;

Und im Code auch genau diesen aufgerufen:

TCP_Receive(	sSrvNetId:= ,
	hSocket:= s_hSocket,
	cbLen:= 512,
	pDest:= ADR(s_s_receive_buffer),
	bExecute:= s_b_receive_execute,
	tTimeout:= T#5S,
	bBusy=> s_b_receive_busy,
	bError=> s_b_receive_error,
	nErrId=> ,
	nRecBytes=> s_n_receive_recBytes);


TCP_Send(
	sSrvNetId:= ,
	hSocket:= s_hSocket,
	cbLen:= INT_TO_UDINT(LEN(s_s_send_befehl)),
	pSrc:= ADR(s_s_send_befehl),
	bExecute:= s_b_send_execute,
	tTimeout:= ,
	bBusy=> s_b_send_busy,
	bError=> s_b_send_error,
	nErrId=> );

Das irritiert mich halt. Problem ist: Was ist, wenn ich mal eine TCP-Verbindung habe, bei der Variable Längen zurückgegeben werden können? Dann bin ich schnell aufgeschmissen, wenn ich irgendeinen "Müll" da mit drin stehen habe. Ich habe gerade extra noch einmal eine Crossref Suche durchgeführt und geschaut, ob ich mir eventuell irgendwo Müll da reinschreibe, allerdings wird die nur an der zwei Stellen geschrieben: Einmal im TCP_Receive und einmal nach Verarbeitung des Befehls mit s_s_receive_buffer = ''.

Viele Grüße!

 

[oliver.tonn]

Wo erstellst Du denn die Handle über FB_SocketConnect und wie?

 

[ADS_0x1]

Ein paar Zeilen höher:

	TCP_Connect			: 	FB_SocketConnect;
	s_b_connect_execute	:	BOOL;
	s_b_connect_busy	: 	BOOL;
	s_b_connect_error		: 	BOOL;
	s_hSocket			: 	T_HSOCKET;

und im Code direkt über dem TCP_Receive:

TCP_Connect(	sSrvNetId:= ,
	sRemoteHost:= '10.1.1.15',
	nRemotePort:= 8080,
	bExecute:= s_b_connect_execute,
	tTimeout:= ,
	bBusy=> s_b_connect_busy,
	bError=> s_b_connect_error,
	nErrId=> ,
	hSocket=> s_hSocket);

 

[oliver.tonn]

Zuviel Werbung?
-> Hier kostenlos registrieren

Das ist allerdings seltsam, jede Instanz von SocketConnect sollte wirklich einen individuellen Handle erzeugen und es sollte auch nicht zu Vermischungen bei den Puffern kommen.

 

[ADS_0x1]

Ich bin erst Ende der Woche wieder zu Hause, da kann ich das ganze noch einmal Testen und bewerten. Ich hab mir aber gerade noch einmal den IP_Control von OSCAT angeschaut und da wird der Empfangs- und Sendebuffer als IN_OUT übergeben, im aufrufenden Programm sind diese ebenfalls "nur" lokal definiert und nicht als global.

In der Oscat-Hilfe steht drin, dass manche Steuerungen die Verbindungen beschränken und der IP_Control eine Verwaltung der Verbindungen macht - wenn ich nun aber mehrere Instanzen dessen (in meinem Fall ehemals zwei, jetzt nur noch eine) habe, dann sollte das doch über die Socket handles geregelt werden, sprich genau NICHT das gezeigte, sondern das von mir vermutete Verhalten?