TwinCAT 2 - TS6310 - TCP/IP-Ansteuerung eines Remote-Clients

AirHubi

Level-1
Beiträge
5
Reaktionspunkte
2
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo liebe Community,

ich versuche gerade, eine TCP/IP-Ansteuerung eines Remote Clients (Programmierbare Stromversorgung vom Typ Delta Elektronika SM66-AR-110) mithilfe des TwinCAT-2-Supplements TS6310 zu realisieren.

Dazu habe ich folgenden Testaufbau hergestellt (siehe auch Anhang):
  • Mein Programmierlaptop (mit Programmierumgebung TwinCAT 2, Supplement „TS6310-0001 | TwinCAT TCP/IP Server“ installiert) dient zum Schreiben des Quellcodes.
  • Der Quellcode wird anschließend auf dem Zielsystem (CP6207, Windows CE6.0, Supplement „TS6310-0001-0030 | TwinCAT-TCP/IP-Server-CE“ installiert) aufgespielt.
  • Das Zielsystem soll dann mit dem Remote Client über TCP/IP kommunizieren können.
Jetzt meine Frage:
Ich habe es bisher leider nicht geschafft, eine erfolgreiche Kommunikation aufzubauen.
Hat jemand eine Idee, wo mein Fehler liegen könnte? Ich bin für jeden Hinweis dankbar.

Quellcode siehe Anhang.
Hierzu noch folgende Anmerkungen:
  • Der Funktionsbaustein „FB_SocketListen“ funktioniert meiner Meinung nach, da nach dessen Ausführung die entsprechende „handle“-Variable (fbSocketListen.hListener.handle) einen Wert ungleich 0 annimmt (siehe auch Anhang).
  • Was nicht funktioniert, ist, dass der Funktionsbaustein „FB_SocketAccept“, welcher gemäß des TS6310-Handbuchs zyklisch aufgerufen werden soll, die entsprechende „handle“-Variable (fbSocketAccept.hSocket.handle) erzeugt. Der Wert bleibt bei 0 (siehe auch Anhang). Somit hat nach meinem Verständnis kein erfolgreicher Aufbau einer TCP/IP-Verbindung stattgefunden.
  • Was ich auch nicht verstehe: Gemäß der Dokumentation des Herstellers der programmierbaren Stromversorgung gibt es zwei wichtige Einstellungen, um sauber mit der Stromversorgung kommunizieren zu können: 1.) IP-Adresse (eingestellt gemäß Anhang) und 2.) Port = 8462. In keinem meiner verwendeten Funktionsbausteine aus dem Supplement übergebe ich diese Daten. Es werden bei allen verwendeten Funktionsbausteinen immer nur die Daten des TwinCAT TCP/IP Connection Servers/ des Local-Servers benötigt, was nach meinem Verständnis die Daten des Zielsystems (CP6207) sind. Kann das sein?
Beste Grüße
AirHubi
 

Anhänge

  • 2023-03-29_Entwicklungstopologie_TCP-IP.pdf
    214,3 KB · Aufrufe: 12
  • Quellcode.pdf
    333,8 KB · Aufrufe: 13
Ich würde erwarten, dass das Netzteil der Server ist (führt Anweisungen aus) und deine SPS ist der Client (erteilt die Anweisungen/Anfragen).

Bei dir ist die SPS der Server.

Gruß Illi
 
Zuviel Werbung?
-> Hier kostenlos registrieren
@illi:
Vielen Dank für deinen Hinweis, du hast vollkommen Recht :)
Ich hatte ein komplett falsches Verständnis, wer hier Server und wer hier Client ist.
Mit FB_SocketConnect funktioniert jetzt alles.

Gruß
AirHubi
 
Hallo AirHubi,
ich habe evtl. ein ähnliches Problem.
Verwende folgende Komponenten:
Beckhoff Steuerung
Twincat 3
Delta Elektronika SM66-AR-110

Als Grundlage habe ich das Beispielprogramm von Beckhoff genommen das auf Github verfügbar ist (Beckhoff/TF6310 Samples).
Der Verbindungsaufbau mit FB_SocketConnect scheint zu funktionieren, jedenfalls habe ich im Handler vom SocketConnect einen Wert <>0 (Siehe Bild).
Allerdings funktionieren die Befehle FB_SocketSend/FB_Receive nicht. Da kann ich leider auch nicht nachvollziehen woran es liegt.
Mit einem Tool "SocketTest" kann ich befehle an das Netzteil senden und auch Nachrichten vom Netzteil lesen.

Über Tipps wäre ich dankbar.
 

Anhänge

  • FB_SocketConnect.PNG
    FB_SocketConnect.PNG
    16,3 KB · Aufrufe: 9
  • SendReceive.PNG
    SendReceive.PNG
    21,1 KB · Aufrufe: 9
  • TCPIPMAin.PNG
    TCPIPMAin.PNG
    35,9 KB · Aufrufe: 9
Mit diesen Screenshots lässt sich nicht viel anfangen, gesendet werden soll mit fbTimer.Q. Auf dem anderen Screenshot ist ein fbTimer1.Q.

Soll das beides mal der gleiche Timer sein? Falls nein fehlen noch ein paar Screenshots.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Beim senden musst Du "nur" eine positive Flanke an bExecute legen, danach kann er bis zum nächsten Senden FALSE sein.
Am Baustein FB_SocketReceive darf der Eingang bExecute nicht dauerhaft auf TRUE sein, sondern muss zyklisch auf TRUE und FALSE gesetzt werden. Das kannst Du auch im Infosys nachlesen, was Du dringendst tun solltest, dann wird Dir auch einiges klarer.
Ansonsten schau Dir mal dieses Beispiel an, aber bitte nimm Dir kein Beispiel an dem Aufruf der FBs innerhalb einer CASE-Anweisung, das ist nämlich bei FBs die zyklisch aufgerufen werden sollen/müssen eigentlich ein NoGo und kann zu erheblichen Fehlern führen.

1706765725066.png

Übrigens wäre es gut gewesen, Du hättest einen neuen Thread aufgemacht und diesen nicht gekapert, TC2 und TC3 sind dann doch zwei paar Schuhe, die nur bedingt zueinander passen.
 
Zuletzt bearbeitet:
Danke für die Rückmeldung,
Wie schon beschrieben habe ich mir die Funktion bei dem Beispiel auf https://github.com/Beckhoff/TF6310_Samples
abgeschaut.
Beim senden musst Du "nur" eine positive Flanke an bExecute legen, danach kann er bis zum nächsten Senden FALSE sein.
1706770770811.png

Das mache ich zum testen aktuell so, das ich die Variable "bTestTrigger" online true/false Force um das Senden durchzuführen.
(Das ist der Bausteinaufruf, in dem ich alle weiteren FB_Socket Bausteine Aufrufe)
Am Baustein FB_SocketReceive darf der Eingang bExecute nicht dauerhaft auf TRUE sein, sondern muss zyklisch auf TRUE und FALSE gesetzt werden. Das kannst Du auch im Infosys nachlesen, was Du dringendst tun solltest, dann wird Dir auch einiges klarer.
1706771141473.png
Die "btest_receiveexecute" hatte ich nur zum Test eingebaut, das Execute wird aber eig. getoggelt.
Allerdings in Abhängigkeit zu dem Busy des FB_SocketReceive, ob das ein Problem ist weiß ich ehrlich gesagt nicht.
Ansonsten schau Dir mal dieses Beispiel an, aber bitte nimm Dir kein Beispiel an dem Aufruf der FBs innerhalb einer CASE-Anweisung, das ist nämlich bei FBs die zyklisch aufgerufen werden sollen/müssen eigentlich ein NoGo und kann zu erheblichen Fehlern führen.
Das Aufrufen der FBs in der Case Anweisung habe ich natürlich genau wie in dem Beispiel gemacht...
1706771526643.png
1706771956106.png
Anhang anzeigen 74918

Übrigens wäre es gut gewesen, Du hättest einen neuen Thread aufgemacht und diesen nicht gekapert, TC2 und TC3 sind dann doch zwei paar Schuhe, die nur bedingt zueinander passen.
Mein Aufbau So aus:
1.Programmier Laptop
2. Beckhoff Rechner
3. Delta Elektronika SM66-AR-110

Was ich gestern Nachmittag getestet habe:
1.Ich habe auf meinem Laptop mit der Software "SocketTest v 3.0.0" als Client eine Verbindung zu dem Netzteil aufgebaut und mit den Befehlen aus der Betriebsanleitung des Herstellers Anfragen gesendet und auch Rückmeldungen bekommen.

2. Auf dem Beckhoff Rechner ebenfalls die Software installiert und den Austausch getestet, hat auch funktioniert.

3.Auf meinem Laptop "SocketTest v 3.0.0" als Server laufen lassen. Im TwinCat die Verbindung zu dem Server auf meinem Laptop aufgebaut und Daten aus dem Programm an den Server gesendet und auch vom Server empfangen.
Das bedeutet für mich dass das Programm an sich funktioniert oder?

Die Frage ist nur, wieso es mit dem Netzteil nicht hin haut.
 
Danke für die Rückmeldung,
Wie schon beschrieben habe ich mir die Funktion bei dem Beispiel auf https://github.com/Beckhoff/TF6310_Samples
abgeschaut.

Anhang anzeigen 74920

Das mache ich zum testen aktuell so, das ich die Variable "bTestTrigger" online true/false Force um das Senden durchzuführen.
(Das ist der Bausteinaufruf, in dem ich alle weiteren FB_Socket Bausteine Aufrufe)

Anhang anzeigen 74921
Die "btest_receiveexecute" hatte ich nur zum Test eingebaut, das Execute wird aber eig. getoggelt.
Allerdings in Abhängigkeit zu dem Busy des FB_SocketReceive, ob das ein Problem ist weiß ich ehrlich gesagt nicht.

Das Aufrufen der FBs in der Case Anweisung habe ich natürlich genau wie in dem Beispiel gemacht...
Anhang anzeigen 74923
Anhang anzeigen 74924

Mein Aufbau So aus:
1.Programmier Laptop
2. Beckhoff Rechner
3. Delta Elektronika SM66-AR-110

Was ich gestern Nachmittag getestet habe:
1.Ich habe auf meinem Laptop mit der Software "SocketTest v 3.0.0" als Client eine Verbindung zu dem Netzteil aufgebaut und mit den Befehlen aus der Betriebsanleitung des Herstellers Anfragen gesendet und auch Rückmeldungen bekommen.

2. Auf dem Beckhoff Rechner ebenfalls die Software installiert und den Austausch getestet, hat auch funktioniert.

3.Auf meinem Laptop "SocketTest v 3.0.0" als Server laufen lassen. Im TwinCat die Verbindung zu dem Server auf meinem Laptop aufgebaut und Daten aus dem Programm an den Server gesendet und auch vom Server empfangen.
Das bedeutet für mich dass das Programm an sich funktioniert oder?

Die Frage ist nur, wieso es mit dem Netzteil nicht hin haut.
Nochmals ein paar Worte zum Aufruf von FBs die zyklisch aufgerufen werden, wie Timer, Flankenbausteine und andere, innerhalb von CASE-Anweisungen und IF-Abfragen. Ja, Beckhoff macht dies in seinen Beispielen und da diese an alles gedacht haben läuft es auch, trotzdem bleibe ich bei meiner Aussage, dass so etwas ein NoGo ist und Du wirst hier im Forum etliche finden, die das bestätigen werden.
Stell Dir bitte einmal folgendes Szenario vor, über einen Taster soll eine Einschaltverzögerung von, z.B. 10s gestartet werden und aktiv bleiben. Also wird über eine IF-Abfrage geprüft, ob dieser Taster gedrückt wurde, ist dies der Fall, wird in der IF-Abfrage der Timer FB mit IN := TRUE aufgerufen. In einer anderen IF-Abfrage wird geprüft, ob der Ausgang Q des Timer FBs TRUE ist. Wenn jetzt der Taster losgelassen wird erfolgt kein weiterer Aufruf des Timer FBs, dadurch wird auch der Ausgang Q nie gesetzt. Dies stellt einen klassischen Fehler da, der hier im Forum immer wieder für einen neuen Thread sorgt, weswegen ein solcher Aufruf auch vermieden werden sollte und innerhalb einer CASE-Anweisung oder einer IF-Abfrage nur der oder die Eingänge des FBs gesetzt werden sollte/n, der Aufruf aber außerhalb erfolgt. Eine Ausnahme ist z.B., wenn ein Timer FB zurückgesetzt und gleich wieder gestartet werden soll, dann kann der FB mit IN := FALSE einmalig aufgerufen werden.
Wenn Du mit Deinem Test-Programm eine Kommunikation hinbekommst, also der Server Daten empfängt und Dein SPS-Programm Antworten, sollte Dein SPS-Programm funktionieren. Fügt doch bitte hier einmal die Befehle an die Du schickst, ansonsten kannst Du die Kommunikation auch mal mit Wireshark beobachten, soweit Deine SPS ein WES hat und Du Wireshark auf der SPS installieren kannst.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
OK,
Test mittels "SocketTest v 3.0.0" (auf dem Beckhoff Rechner)
das einfachste Beispiel ist, das ich einen String sende: 'MEASure:pOWer?'
Das Feedback von dem Netzteil ist dann z.B. : '-0.24'
1706782102889.png
Beobachtung via Wireshark :
1706782223404.png
1706782255521.png
Es werden "2 Packete" gesendet mit einer Länge von 16/bzw. 0


Wenn ich allerdings von dem Programm heraus versuche den geleichen Befehl an das Netzteil zu senden, sieht es folgendermaßen aus.
1706782529571.png
Die Länge ist 81
Evtl ist hier das Problem?
 
Das er immer die maximale Länge des Strings schickt kann tatsächlich ein Problem sein. In dem Fall anstatt SIZEOF den Befehl LEN nutzen.
Dann bleibst Du immer noch die Antwort auf die Frage schuldig, welchen String genau Du mit dem SPS-Programm schickst. Zeig doch bitte mal den entsprechenden Code. An das Ende Zeichen hast Du gedacht?
 
Mit LEN als hat es funktioniert.
Den String den ich sende sieht folgendermaßen aus 'MEASure:pOWer?'
1706784825999.png
1706784797641.png
Das Ende Zeichen habe ich hier noch nicht drin.
Weiß da ehrlich gesagt nicht wie es aussehen muss...
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Mit LEN als hat es funktioniert.
Den String den ich sende sieht folgendermaßen aus 'MEASure:pOWer?'
Anhang anzeigen 74940
Anhang anzeigen 74939
Das Ende Zeichen habe ich hier noch nicht drin.
Und genau da wird die Ursache für Dein Problem liegen, ohne dieses verarbeitet das Netzteil Deinen Befehl nähmlich nicht.
Weiß da ehrlich gesagt nicht wie es aussehen muss...
Da hätte ein Blick ins Handbuch gereicht.
1706785923069.png
Du musst am Ende Deines Befehlsstring noch $L oder $N oder $0A anfügen, dann sollte es klappen.
Die String Konstanten findest Du übrigens hier in englisch und hier in Deutsch.
 
Zuletzt bearbeitet:
Jap, das hat noch gefehlt.
Zu meiner Verteidigung muss ich sagen das ich mir in dem Handbuch angeschaut habe, ich aber nicht darauf gekommen bin das es sich dabei um eine Konstante im TC3 handelt, sondern dachte es wäre eine Vorgabe des Herstellers...

Vielen Dank für deine Hilfe.
 
Jap, das hat noch gefehlt.
Zu meiner Verteidigung muss ich sagen das ich mir in dem Handbuch angeschaut habe, ich aber nicht darauf gekommen bin das es sich dabei um eine Konstante im TC3 handelt, sondern dachte es wäre eine Vorgabe des Herstellers...

Vielen Dank für deine Hilfe.
Naja, das ist ja schon eine Vorgabe des Herstellers, dieser gibt vor das jeder Befehl und jede Abfrage mit Linefeed abgeschlossen werden muss. Da dies ein nicht druckbares Zeichen ist muss dieses auf besonderem Wege bei TwinCAT hinzugefügt werden, dafür sind dann die String Konstanten da.
 
Zurück
Oben