TCP-SOCKET Kommunikation mit WinAC RTX

Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo Helmut,

ich vermute, dass du in AWL programmierst ...
IN SCL hättest du die Möglichkeit, mit einer AT-Sicht dir den Nutzdatenteil deines Strings zu isolieren (ohne weiteren Programm-Code).

Aber noch andere Idee : Es gibt doch bei FLex außer dem Datentyp String (der ja die beiden Header-Bytes hat) noch einen Byte-String oder so ähnlich (hab gerade keine Visu zur Hand), der als Zieldatentyp dann ein Array of Byte hat, dass du dann ja direkt übergeben könntest ...

Gruß
Larry
 
Du meinst Char, aber das hat den Nachteil das ich in der HMI nichts anderes wie
einen Manuellen eingestellten Zeiger machen muß. Das ist auch nicht so toll, mir
geht es ja darum das ich bei Veränderung, der Datenstruktur weder auf Steuerungsseite
noch auf HMI Seite, etwas manuell nachführen muß.

Ich glaube ich nehme die methode vom Ralle, die bekomme ich hin, es ist ja bald Weinachten,
da habe ich ja Zeit, während ich auf das Essen warte ;)

PS. die SCL Methode, kannst du ja mal anführen...
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo Helmut,

ich meinte StringChar - der funktioniert innerhalb der Visu wie ein String ... adressiert aber ein Array of Byte.

Bezüglich des SCL-Ansatzes : was möchtest du da wissen ? Wie man eine andere Sicht auf einen String erstellt ?

Gruß
Larry
 
In etwa so :
Code: 
im Deklarationsbereich :
myString : STRING[50] ;
at_myString : struct
   Header     : array [0..1] of byte ;
   ByteArray : array [1..50] of byte ;
end_struct ;
Das Ganze ist jetzt aus dem Gedächtnis entstanden.
Die verwendeten Namen sind natürlich beliebig ...
Die Variable "at_myString" ist keine neue Variable sondern lediglich eine andere Sicht auf die Variable "myString". Das heißt, dass wenn du in dem Einem etwas änderst dann ändert es das Andere gleich mit ...

Gruß
Larry
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ich würde hier noch einmal gerne mein Frage erweitern, die Kommunikation mit der Fremdmaschine läuft
eigentlich ganz gut....nur Leider nicht immer. Ich kann wochenlang 300-400 Telegramme ohne Störung schicken
nur hin und wieder, wird ein Telegramm verschluckt.

Der Ablauf des Senden muß man sich so Vorstellen, ich habe zwei Telegramme die hintereinander geschickt
werden, jedes Telegramm entspricht ein Werkstück. Die ganze Prozedur wird über eine Schrittkette gesteuert
und ist nach Vorgaben des Fremdmaschinen Herstellers durchgeführt ( deshalb der merkwürdige Ablauf )

erstes Werkstück senden
Verbindung aufbauen
warten bis die Verbindung steht
ich bastel in der HMI mit einen Script das Telegramm zusammen und trage diese ein
ich warte 750ms das alle Daten sauber eingetragen sind ( triggertakt der HMI 500ms )
Der Auftrag wird gestartet
Auswertung durch Done und Busy Bit, ob der Auftrag abgeschlossen ist
Verbindung abbauen
warten bis Verbindung abgebaut
750ms Wartezeit bis zum nächsten Auftrag ( Vorgabe externe Maschinenbauer )

zweites Werkstück senden
Verbindung aufbauen
warten bis die Verbindung steht
ich bastel in der HMI mit einen Script das Telegramm zusammen und trage diese ein
ich warte 750ms das alle Daten sauber eingetragen sind ( triggertakt der HMI 500ms )
Der Auftrag wird gestartet
Auswertung durch Done und Busy Bit, ob der Auftrag abgeschlossen ist
Verbindung abbauen
warten bis Verbindung abgebaut


So jetzt ist ja hin und wieder ein Werkstück verloren gegangen, der externe Maschinenbauer hat eine
Logdatei, wo der Ablauf der WinSock Kommunikation protokolliert wird. Da steht schon einmal nach jeden
senden der Abbau der Verbindung ein WinSock error 10053 drin, er kann sich diesen nicht erklären, nach
Google Recherche, ist das doch nichts anderes als eine Rückmeldung für den Abbau der Verbindung...na ja.

Wenn ein Werkstück nicht erkannt wird hat er einen WinSock error 10054, was ja auch auf eine gestörte
Verbindung hinweist. Meine frage wäre jetzt wie sicher sind die Siemens Bausteine, bei ihrer Abarbeitung.
Wenn diese keinen Fehler melden und die Abarbeitung mit den 'Done' Bit abgeschlossen ist, kann man sich
darauf verlassen, das diese sauber gearbeitet haben. Auf jeden fall Loge ich auf meiner Seite die Tele-
gramme nach erfolgreicher Fertigmeldung der Siemens Bausteine mit und kann erkennen das die Daten
sauber in der Formatierung stimmen und gesendet sind.
 
Wenn über eine TCP-Verbindung ein Datenpaket gesendet wird, muss der Empfang des Pakets vom Partner mit ACK bestätigt werden. Wird nach einer Zeit x kein ACK empfangen, so wird das Paket erneut auf die Reise geschickt (Retransmission).
Jetzt ist aber aus der Siemens Dokumentation nicht bekannt, wann der TSEND-Baustein seinen Ausgang DONE auf true setzt: Wenn die Daten abgeschickt wurden, oder wenn vom Partner ein ACK empfangen wurde.
Man sollte davon ausgehen dass dieses erst bei einem erhaltenen ACK der Fall ist. Wenn das so sein sollte kannst du bei deinem Programm davon ausgehen dass wenn du ein DONE erhältst die Daten auch beim Partner angekommen sind, denn dieser hat es ja bestätigt.

Ich würde es bei Siemens mal nachfragen ob die Bausteine wirklich so arbeiten.
 
Verbindung abbauen?

Ich verstehe nicht, warum die Verbindung nach jedem Datenaustausch wieder abgebaut wird.

Die Verbindung sollte meiner Meinung nach beim Start der Maschine einmal aufgebaut werden und dann bestehen bleiben.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Weil der externe es so wollte, ich hätte
es auch gern anders gelöst, verstehen
muß man das nicht :(

Eine Begründung war, ich müsste vor den
Senden sicherstellen ob die Verbindung
besteht.

Mir wäre es auch lieber gewesen wir hätten
einen 'Shake Hand' da eingebaut und wenn
es nur Digitale Signale gewesen wären. Zu
nichts ist der externe bereit, da die WinSock
Application eine Konzern weite ist und immer
funktionieren würde.

Ich brauche jetzt einfach Futter um diesen Typen
den Wind aus den Segel zu nehmen.
 
Ich muss RobiHerb da zustimmen.
Mit einem Laser habe ich eine ähnliche Kommunikation am Laufen.
Über die Visu kann ich den Laser an- und abwählen. Bei Anwählen Connecte ich den Laser und bei Abwählen disconnecte ich ihn. Ansonsten steht die Verbindung über Stunden.
Es gibt da bezüglich der Kommunikation (SPS <-> Laser-Control) keine Schwierigkeiten.

Gruß
Larry
 
Ich bin ja jetzt nicht so Sattelfest, bei der TCP Kommunikation, aber was ich festgestellt habe
ist das der Verbindungsbaustein über den Fehlercode zurückmeldet ob die Verbindung steht.
Wäre das eine Möglichkeit, dieses als Prüfung der bestehenden Verbindung zu nutzen oder gibt
es da eine andere Möglichkeit?
 
Zuviel Werbung?
-> Hier kostenlos registrieren
rostiger Nagel schrieb:
Ich bin ja jetzt nicht so Sattelfest, bei der TCP Kommunikation, aber was ich festgestellt habe
ist das der Verbindungsbaustein über den Fehlercode zurückmeldet ob die Verbindung steht.
Wäre das eine Möglichkeit, dieses als Prüfung der bestehenden Verbindung zu nutzen oder gibt
es da eine andere Möglichkeit?
Zum Vergrößern anklicken....

Wenn du keine Daten austauschst kannst du auch nicht feststellen ob die Verbindung noch besteht.
Es gibt noch sogenannte Keep-Alive Telegramme. Werden keine Daten ausgetauscht, so werden in bestimmten Abständen "leere Pakete" geschickt eben um nachzuprüfen ob die Verbindung noch funktionsfähig ist. Bei einem Programm auf einem PC-Betriebssystem kann man bei einer TCP-Verbindung einstellen ob man Keep-Alive Telegramme möchte. Voreinstellung ist dass dieses nicht gemacht wird, und davon würde ich bei den T-Bausteinen auch ausgehen - ansonsten bei Siemens nachfragen.

Ich glaube auch nicht dass die pauschale Aussage "lass die Verbingung immer bestehen" das Problem behebt. Die einzige Problematik die es damit geben könnte ist, wenn du sagen wir mal pro Sekunde 100 Verbindungen auf- und wieder abbaust. Das mögen manche Betriebssysteme nicht so gerne und nehmen irgendwann keine Verbindungen mehr an. Dann müsstest du aber bei deinem Connect einen Fehler bekommen.

Vielleicht kannst du das Verhalten mal im Büro versuchen nachzustellen. Dazu z.B. zu diesem Hercules Programm als TCP-Server von der SPS aus eine Verbindung aufbauen lassen. Steht die Verbindung, so ziehst du das Netzwerkkabel an dem Rechner auf dem der TCP-Server läuft ab, und prüfst was dein T-Send Baustein sagt wenn du dann Daten schicken willst.
Durch das Ziehen des Netzwerkkabels sollte die SPS nicht mitbekommen dass die Verbindung getrennt wurde, außer es werden a) Keep-Alive Telegramme geschickt oder b) der T-Send wartet das ACK des Partners ab bis er Done auf true setzt.
Wenn du den TCP-Server hingegen manuell beendest, wird an den Partner noch ein Telegramm abgesetzt dass die Verbindung beendet wurde. Dann muss T-Send bei Sendeversuchen auf jeden Fall einen Fehler ausgeben.
 
Da mir hier nur eine 1200er Steuerung mit dem TIA-Portal zur Verfügung steht habe ich das Verhalten des TSEND mal bei dieser Steuerung geprüft.

Und alle Achtung:
Wenn ich den TSEND bei gezogenem Netzwerkkabel anstoße, geht DONE auf true obwohl die Daten überhaupt nicht versendet wurden!
Der eigentliche Sinn von TCP, nämlich die Quittierung des Empfangs, wird von Siemens ignoriert. Ich kann den Send sogar mehrmals auf einer toten Verbindung anstoßen, der Baustein bestätigt immer mit DONE=true.
Wie gesagt bei einer 1200 und TIA-Portal, da liegen ja noch mehr Dinge im Argen. Würde mich aber nicht wundern wenn das bei den anderen Steuerungen auch so umgesetzt wurde.
 
Es würde mich nicht wundern wenn der TSEND die Daten nur aufbereitet und an einen Buffer des IP-Stacks übergibt (von diesem eine Quittung erhält) aber keine Informationen über den Status der physikalischen Verbindung bekommt.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
... ich habe das mit dem Laser-Hersteller so gelößt, dass hier ein zyklischer Datenaustausch stattfindet - im Prinzip wie bei dezentraler Perepherie. Ich schicke im Sekundentakt ein Telegramm mit einem festgelegten Aufbau - er schickt mir postwendendend seinen Status zurück. Auf diese Weise hat man auch einen Handshake, der es einen erkennen läßt ob noch alles läuft ...
 
So könnte ich mir das auch vorstellen - auch wenn es trotzdem nicht Sinn einer TCP-Verbindung ist. Aber spätestens nach dem ersten fehlgeschlagenen Sendeversuch müsste intern die Verbindung als ungültig gekennzeichnet werden. So kann man tagelang auf einer nichtexistenden Verbindung Daten schicken, und alles sieht aus als ob es läuft.
Aber erstmal abwarten ob sich die 300er und WinAC genauso verhalten. Wenn das der Fall ist kann man auf TCP gleich ganz verzichten und auf UDP mit einem Software-Handshake wechseln.
 
... da kann ich jetzt leider weiter nichts dazu sagen, da der von mir genannte Weg so zumindestens über viele Stunden ohne weitere Probleme funktioniert.
Es müßte es aber auch mit dem Verbindungs-Aufbau und anschließenden -Abbau - wenn das auch aus meiner Sicht unnötig ist ...

Ich vermute, dass es da noch ein anderes Problem gibt ...
 

Similar threads

G
Step 7 SNMP auf CPU 317F-2PN/DP deaktivieren (Simatic Manager)
Antworten
10
Aufrufe
605
Gamexter
G
I
TIA S7-1517 MB_Client verschiedene Adressbereiche auslesen,
Antworten
13
Aufrufe
851
NOBS
N
DeltaMikeAir
TIA Neue Firmware V2.9.7 für 1500ér CPU´s ( nicht für 6ES751x-xxx03-0AB0 )
Antworten
3
Aufrufe
2K
maxder2te
M
Bitte ein Bit
TIA TIA V17 For Schleife mit 2 Dimensionen
2
Antworten
22
Aufrufe
1K
Heinileini
Heinileini
K
TIA SINUMERIK ONE Open User Communication mit Datalogic BC8190 Handscanner
Antworten
2
Aufrufe
849
Kleinerwolf
K
Zurück
Oben