TCP-SOCKET Kommunikation mit WinAC RTX

Zuviel Werbung?
-> Hier kostenlos registrieren
Hi Thomas,
das mit den Senden und Verbindung bekomme ich bei mir nicht nachgestellt.
Ich habe einige Sachen im Büro versucht, also gesendet und die Verbindung
stehen gelassen, ich bekam bei abgesteckten Stecker keinerlei Fehler.

Wie geschrieben, denke ich das die Gegenseite mit den Auf und wieder Abbauen nicht
klarkommt. Ein Handshake habe ich ja schon vorgeschlagen, dann kam ich sollte die Daten
bei denen in eine Datei schreiben. Nur was ist wenn da wieder neue Probleme auftauchen.

Was mich so ärgert, die CPU bekomm dieses ja mit, da die Diagnose Lampe angeht.
Wir bewegen uns ja in der Automatisierungstechnik, da hätte ich erwartet das Siemens
sich da bei Erstellung solcher Bausteine etwas professioneller verhält. Entweder Werten
die einen solchen Ausfall aus oder die geben ein die Möglichkeit über ein paar Parameter
da etwas zu stellen.
 
Wenn du den Stecker gezogen hast, warte einfach mal bis zu einer Minute und versuch dann nochmal zu senden (ohne die Verbindung zu trennen). Vielleicht gibt es dann einen Fehler am Tsend-Baustein.
Durch das TCP wird ein Paket das nicht bestätigt wurde automatisch nach einiger Zeit erneut versendet (glaub bis zu drei Versuche, die Zeit zwischen den Versuchen verlängert sich dabei). Wie Siemens die Zeiten eingestellt hat lässt sich aber in keinem Dokument finden.

Bei Dalbi kommt ja unmittelbar ein Fehler, der hat aber auch soweit ich weiß eine Intel Netzwerkkarte. In der Step 7 Hardwarekonfiguration kann man bei der Netzwerkkarte die für die SPS zuständig ist nichts dergleichen einstellen. Auf der anderen Karte kann man hingegen die TCP-Keepalives oder auch den Timeout für den Verbindungsaufbau einstellen.

Was steht denn im Diagnosepuffer wenn die SF Lampe angeht?
 
so jetzt habe ich mal beobachtet, wann die Fehlermeldung kommt bei gezogenen Stecker, es dauert ca. 30sec., in
dieser Zeit kann ich fröhlich senden und bekomme einen erfolgreichen Auftrag gemeldet.
 
Die roten SF- und BF-LED sollten aber sofort angehen bei Kabel abziehen. (?) Dann sollte das also auch irgendwie auswertbar sein ...

Ich vertraue diesen Diagnosemeldungen aber ebenfalls nicht und lege mir immer noch irgendein Handshake oder Lifebit über die Kommunikation.

Harald
 
so jetzt habe ich mal beobachtet, wann die Fehlermeldung kommt bei gezogenen Stecker, es dauert ca. 30sec., in
dieser Zeit kann ich fröhlich senden
und bekomme einen erfolgreichen Auftrag gemeldet.

Eine Situation die am Ende zu einem fatalen Ereignis führen kann....und damit ein Argument für ein Handshake sein sollte.


Handshake ist auch mein
Primärer Wunsch, leider geht der externe Maschinenbauer nicht darauf ein.

Kann der Maschinenbauer seine (Verweigerungs-)Haltung denn einigermassen Begründen?

Egal, für zukünftige Investitionen solltet Ihr überlegen ob in die technischen Vorgaben für den Datenaustausch ein Handshake vorschreibt.
 
In einer Anwendung bei mir habe ich es so gemacht, dass ich den Status des TRCV-Bausteins (FB64) auswerte und dort auf W#16#80A1 vergleiche, ein Status der eintritt, wenn man das Kabel rauszieht.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Eine Situation die am Ende zu einem fatalen Ereignis führen kann....und damit ein Argument für ein Handshake sein sollte.




Kann der Maschinenbauer seine (Verweigerungs-)Haltung denn einigermassen Begründen?

Egal, für zukünftige Investitionen solltet Ihr überlegen ob in die technischen Vorgaben für den Datenaustausch ein Handshake vorschreibt.

Der andere Maschinenbauer hat eine andere Dimension, deren Open Socket Anwendung ist eine eigene in Hochsprache geschriebene Anwendung
auf einen Beckhoff Rechner, diese wird in deren Konzern, bei allen Töchtern eingesetzt. Da schrauben die nichts dran rum, auch wenn ich mich auf dem Kopf stelle.
 
Die haben schon ein anderes Nivau, die bauen zum Teil ihre SPS'en selber, haben
von 3S irgend etwas eigenes entwickeln lassen, anstatt Twincat zu nutzen. In deren
Haus funktioniert das dann auch, wenn Tochter 1 etwas an Tochter 2 sendet. Warum
sollten die dann eine vlt teuere Applikation umstricken, nur weil Siemens keine vernünftige
Fehlerauswertung hat. Würde ich doch auch nicht machen.
 
Die roten SF- und BF-LED sollten aber sofort angehen bei Kabel abziehen. (?) Dann sollte das also auch irgendwie auswertbar sein ...

Ich vertraue diesen Diagnosemeldungen aber ebenfalls nicht und lege mir immer noch irgendein Handshake oder Lifebit über die Kommunikation.

Vor allem fängt man damit auch nur ab wenn der Link auf der Strecke von der SPS zum nächsten Punkt unterbrochen wurde.
Meine ursprüngliche Idee war darum das Netzwerkkabel am Partner abzuziehen, dadurch bekommt die SPS den Verlust des Link nicht mit - vorausgesetzt ein Switch/Router/Hub hängt dazwischen.
 
So jetzt mal das Programm umgestrickt, die Verbindung wird nur einmal aufgebaut.
Bei Störungen wird dieses Angezeigt und zusätzlich habe ich noch eine Diagnose Seite erstellt.
Jetzt muß ich es nur noch irgendwann beim Kunden aufspielen.

TCP diag.JPG
 
sieht echt chick aus!

Mich irritiert zwar das oben Profibus drüber steht... aber sonst richtig nett gemacht!

Grüße

Marcel
 
Zurück
Oben