# TCP-SOCKET Kommunikation mit WinAC RTX



## rostiger Nagel (10 Oktober 2012)

Hallo Kollegen,
ich bräuchte ein wenig unterstützung bei den oben gennanten Thema....

Also ich muß bei einen Kunden Daten von meiner Maschine zu einer folgenden übermitteln, dort wurde dann eine TCP-Socket Kommunikation vorgegeben.
Auf meiner Seite habe ich einen IPC477C mit der Soft SPS WinLC RTX F auf der gegenseite ist ein Beckhoff (glaube ich)
Da dieses Kommunikation völliges Neuland für mich ist, habe ich erstmal eine Testumgebung aufgesetzt, wo ich an den IPC einen Notebook über ein gekreutzets
Kabel angehängt habe, siehe Screenshot.




Den IPC kann ich vom Notebook aus anpingen, anderherum geht es nicht, da der IE-Allgemein  in Subnet 2 den Betriebssystem des IPC nicht mehr zur verfügung
steht, dieser wird von der RTX in beschlag genommen.



Mein Gedanke ist jetzt ersteinmal eine Verbindung aus der RTX <-> Notebook mit den FB65 "TCON" aufzubauen, dazu habe ich als erstes mittels den Open Communication
Wizard den UDT für den FB65 erstellt, siehe folgende Screenshot.









Der UDT65 sieht wie folgt aus;

```
TYPE "TCON_PAR"
TITLE =Connection Parameters for TCON
AUTHOR : SIMATIC
FAMILY : COMM
NAME : TCON_PAR
VERSION : 2.1

  STRUCT  
   block_length : WORD  := W#16#40; //#!Portal!#
   id : WORD  := W#16#1; 
   connection_type : BYTE  := B#16#11; 
   active_est : BOOL  := TRUE; 
   local_device_id : BYTE  := B#16#6; 
   local_tsap_id_len : BYTE ; 
   rem_subnet_id_len : BYTE ; 
   rem_staddr_len : BYTE  := B#16#4; 
   rem_tsap_id_len : BYTE  := B#16#2; 
   next_staddr_len : BYTE ; 
   local_tsap_id : ARRAY  [1 .. 16 ] OF BYTE  := B#16#0, B#16#0, B#16#0, B#16#0, B#16#0, B#16#0, B#16#0, B#16#0, B#16#0, B#16#0, B#16#0, B#16#0, B#16#0, B#16#0, B#16#0, B#16#0; 
   rem_subnet_id : ARRAY  [1 .. 6 ] OF BYTE  := B#16#0, B#16#0, B#16#0, B#16#0, B#16#0, B#16#0; 
   rem_staddr : ARRAY  [1 .. 6 ] OF BYTE  := B#16#A, B#16#1, B#16#2, B#16#AD, B#16#0, B#16#0; 
   rem_tsap_id : ARRAY  [1 .. 16 ] OF BYTE  := B#16#7, B#16#D0, B#16#0, B#16#0, B#16#0, B#16#0, B#16#0, B#16#0, B#16#0, B#16#0, B#16#0, B#16#0, B#16#0, B#16#0, B#16#0, B#16#0; 
   next_staddr : ARRAY  [1 .. 6 ] OF BYTE  := B#16#0, B#16#0, B#16#0, B#16#0, B#16#0, B#16#0; 
   spare : WORD ; //#!Portal!#
  END_STRUCT ; 
END_TYPE
```


Den FB65 rufe ich dann aus den im FB1 aus wo ich den FB65 und den UDT65 als Instanz eingefügt habe.
Das ganze beobachtet und gesteuert wird mit dem Instanz DB vom FB1


```
FUNCTION_BLOCK FB 1
TITLE =
VERSION : 0.1

VAR
  TCON : "TCON"; 
  TCON_PAR : "TCON_PAR"; 
END_VAR
BEGIN
NETWORK
TITLE =
      CALL #TCON (
           ID                       := W#16#1,
           CONNECT                  := #TCON_PAR);
END_FUNCTION_BLOCK
```


Wenn ich den Auftrag anstosse ist der Status 7000 (keine Auftragsbearbeitung aktiv) und geht auf 7002 (Verbindung wird aufgebaut, dann passiert nichts mehr.

Meine Fragen sind:
Bin ich erstmal grundsätzlich richtig vorgegangen?
Bestätigt das Notebook den aufbau der Verbindung eigenständig oder muß da ein wenig mehr getan werden?
Wie kann ich Eigentlich mit den Hyperterminal (auf Notebookseite) feststellen ob die Verbindung aufgebaut ist
und später auch gesendete Daten beobachten?
Für Hilfe wäre ich sehr Dankbar, weitere Fragen folgen bestimmt 

gruß RN


----------



## J.Hinz (10 Oktober 2012)

1. Ja, Bist du. Parameter sehen correct aus. Anstoßen funktioniert ja auch.
2. Wenn du es nicht vergessen hast zu erwähnen, Denke ich brauchst du noch ein Socket server in irgendeiner Form das dir dann auch den Socket Connection aufbau bestätigt. Die reine TCPIP Windows Schnittstelle reicht da ja nicht. 

3. Ein solcher Server sollte dir dann auch den verbindungsstatus sagen. 

Achja: active_est ist bei einem Teilnehmer True bei dem anderen False


----------



## rostiger Nagel (10 Oktober 2012)

Danke J.Hinz,
tja wo bekomme ich den jetzt so ein Tool zum testen des Socket Server her, ich wollte ja ganz
gerne hier im Büro die Kommunikation testen und nicht auf der Baustelle.

Dieser Parameter "active_est" kann ich doch nur auf meiner Seiter auf TRUE stellen, einen gleich-
wertigen Partner der Step 7 spricht habe ich ja nicht.


----------



## SoftMachine (10 Oktober 2012)

.
vielleicht HIER ?

Gruss


----------



## J.Hinz (10 Oktober 2012)

Ja leider hab ich Sockets immer nur selber in C eingesetzt und daher jetzt so spontan keine Programme zur hand(müßte es aber geben).
Als Source codes gibts da genug Beispiele zum schnell selber compilieren. aber das hilft dir eher weniger,....
Hast du nicht zufällig ne kleine S7 zum testen sozussagen als ersatz für die Beckhof?

Edit: Sotmachines Prog sieht ja richtig aus... für einzelene dateien, dauerhafte kommunikation?


----------



## MBr (10 Oktober 2012)

Ich hab mal ein Testprogamm vom diesem Nutzer verwendet.

Ist auf seiner Webseite unter Tools zu finden.


----------



## rostiger Nagel (10 Oktober 2012)

Dann muß ich doch mal schauen ob ich damit klar komme...

DANKE


----------



## SoftMachine (10 Oktober 2012)

.
Viel Erfolg !

Eine kleine Rückmeldung wäre klasse !

Gruss


----------



## Ralle (10 Oktober 2012)

Was ich nicht verstehe, warum wird bei dir die Local_Device_ID 0B hex verwendet? Ich habe das gerade gestern mit einem microbox-PC von Siemens gemacht. Da ich uralt bin hab ich nicht den Wizard verwendet, sondern mache das zu Fuß (FC97 aus einem Siemens-Beispiel). Nach langem Suchen kam ich erst mal darauf, dass ich noch die zweite Schnittstelle ie-allgemein installieren muß, die ie-general geht da nicht. Aber ich habe als lokal_device_id 06hex für IF2 angegeben.

Lt. Siemens-Hilfe zum FB TCON:

local_device_id    BYTE    B#16#02    ·    
B#16#00: Kommunikation über CP 443-1 (nur bei S7-400 und connection_type = B#16#12). Zulässige CPs: CP443-1EX4x, CP443-1EX20, CP443-1GX20, CP443-1EX30, CP443-1GX30·    
B#16#01: Kommunikation über die IE-Schnittstelle auf Interface-Steckplatz 1 (IF1) bei WinAC RTX (nur TCP)·    
B#16#02: Kommunikation über die integrierte IE-Schnittstelle bei den CPUs 315-2 PN/DP und 317-2 PN/DP·    
B#16#03: Kommunikation über die integrierte IE-Schnittstelle bei der CPU 319-3 PN/DP·    B#16#05: Kommunikation über die integrierte IE-Schnittstelle bei den CPUs 414-3 PN/DP, 416-3 PN/DP, 416-3F PN/DP und 41x-5H PN/DP (Rack 0)·    
*B#16#06: Kommunikation über die IE-Schnittstelle auf Interface-Steckplatz 2 (IF2) bei WinAC RTX (nur TCP)·* 
B#16#0B. Kommunikation über die IE-Schnittstelle auf Interface-Steckplatz 3 (IF3) bei WinAC RTX (nur TCP)·    
B#16#0F: Kommunikation über die IE-Schnittstelle auf Interface-Steckplatz 4 (IF4) bei WinAC RTX (nur TCP)·    
B#16#10: Kommunikation über CP 443-1 (nur bei S7-400H und connection_type = B#16#12), falls der CP in Rack 1 oder einem zugehörigen Erweiterungs-Rack steckt·    
B#16#15: Kommunikation über die integrierte IE-Schnittstelle bei den CPUs 41x-5H PN/DP (Rack 1)


----------



## rostiger Nagel (10 Oktober 2012)

Hallo Ralle, 
6 steht drin, ist nur bei mir im Beispiel falsch, warum weiß ich jetzt auch nicht (wird geändert).
Das mit der Schnittstelle hatte ich relativ schnell hinbekommen, nur halt das andere nicht.

Die Verbindung kann ich jetzt aufbauen und wieder abbauen.....schön 

Nach der Mittagspause, werde ich mal daran machen ein paar Daten wegzuschreiben.
Danke nocheinmal für die Hilfen bis hier, das kleine Tool aus dem Link von Softmaschine ist
ein tolles Tool, funktioniert gut.


----------



## rostiger Nagel (10 Oktober 2012)

Wenn ich eine Verbindung aufgebaut habe Daten mit dem "TSEND" senden möchte bekomme ich eine Fehlermeldung mit dem Status "80C4"
Temponären Kommunikationsfehler, wie kann ich das in den Griff bekommen?


----------



## Lipperlandstern (10 Oktober 2012)

> 80C4    Temporärer Kommunikationsfehler:·    Die Verbindung zum Kommunikationspartner kann momentan nicht aufgebaut werden.·    Die Schnittstelle wird neu parametriert bzw. die Verbindung wird gerade aufgebaut.




Bist du sicher das die Verbindung aufgebaut ist ? Nach der Fehlermeldung ist sie es noch nicht


----------



## rostiger Nagel (10 Oktober 2012)

Ich bin da schon sicher, über den Progrämchen, was Softmaschine verlinkt hat, bekomme
ich von FB65 das die Verbindung aufgebaut wurde. Sende ich Daten melde dieses einen
Verbindungsabbruch mit lauten Getöse.


----------



## Ralle (10 Oktober 2012)

Leg doch auch mal für deine SPS einen Port fest, also z.Bsp. Port 2000, wie beim Partner.


----------



## rostiger Nagel (10 Oktober 2012)

Da muss ich morgen mal schauen ob irgendwo eine PN CPU rumliegen habe,
ansonsten muß ich einen Kollegen eine aus der Maschine Klauen.


----------



## Ralle (10 Oktober 2012)

Ne, das muß mit WINLC RTX gehen, ich habs doch hier auch am Laufen mit dem Microbox-PC und einer TCP-Kamera.


----------



## rostiger Nagel (10 Oktober 2012)

Ach so, ja ich werde mal morgen etwas für den Port eintragen. Ich bin mit gar nicht sicher ob ich das nicht sowieso schon gemacht habe. 

Das niemand eine Tool geschrieben hat wo man das mit S7 testen könnte, wundert mich schon.


----------



## Larry Laffer (10 Oktober 2012)

Hallo Helmut,

ich habe so etwas für meine Kommunikation mit unserem Beschriftungs-Laser. Die hat allerdings der Laser-Hersteller geschrieben und ist somit auf die Datenbreite, die mit ihm vereinbart ist / war zurechtgeschnitten. Wenn dich das allerdings nicht stört ... (bei mir wäre es 66 Bytes und der Port war 12500 - glaube ich - aber das ist ja nicht so relevant).

Gruß
Larry


----------



## rostiger Nagel (10 Oktober 2012)

Larry Laffer schrieb:


> Hallo Helmut,
> 
> ich habe so etwas für meine Kommunikation mit unserem Beschriftungs-Laser. Die hat allerdings der Laser-Hersteller geschrieben und ist somit auf die Datenbreite, die mit ihm vereinbart ist / war zurechtgeschnitten. Wenn dich das allerdings nicht stört ... (bei mir wäre es 66 Bytes und der Port war 12500 - glaube ich - aber das ist ja nicht so relevant).
> 
> ...



Ralf, das hört ich ja gut an immer her damit, E-Mail hast du j!

Gruß zuück


----------



## Thomas_v2.1 (10 Oktober 2012)

Huhu, dein Posteingang ist voll ;-)

Was bei den Testprogrammen (das von Softmaschine verlinkte oder z.B. Herkules zu beachten ist):
Du musst natürlich die IP-Adresse des Rechners auf dem der Herkules läuft auf die entsprechende IP-Adresse einstellen.
Laut deinen Screenshots also auf 10.1.2.173. Dann bei Herkules den TCP-Server auf Port 2000 stellen und auf "Listen" klicken.

Wenn du eine aktiv Firewall hast musst du den Port 2000 für eingehende Verbindungen freigeben.
Bei Windows 7 wird (meistens zumindest) beim Start erkannt wenn ein Programm einen Server starten möchte, und fragt ob es in der Firewall diese Ausnahme eintragen soll.
Oder du stellst für die Dauer der Tests die Firewall aus.

Zum Testen des Programms ohne SPS kannst du auch auf einem anderen PC ebenfalls den Herkules starten, dort aber als TCP-Client mit den Adressdaten / Port des anderen PCs. Wenn alles freigegeben ist kannst du darüber mit dir selber Chatten ;-)


----------



## rostiger Nagel (10 Oktober 2012)

Danke Thomas, ja mit meinen Posteingang ist so ein Problem 

Ich gehe das morgen mal an, Firewall ist auch so ein Thema, habe ich noch garnicht nach geschaut...

Als Adresse bei Herkules (auf den Notebook)  hab ich immer die IP des IPC eingestellt, dumm auch!


----------



## Jochen Kühner (10 Oktober 2012)

Also auf meiner Homepage bekommst du unter http://jochensserver.no-ip.org/wordpress/?page_id=58 ein kleines Tool TCPTest, welches ein Socket Server oder Client sein kann..

In diesem Thread ist auch noch einer von mir verlinkt: http://www.sps-forum.de/showthread.php/45126-Telegrammverkehr-PC-SPS-CPU-315-2DP?p=332104#post332104


----------



## rostiger Nagel (10 Oktober 2012)

Danke Jochen,
auch das werde ich morgen testen, Blicke ich da durch?
Du hast ja immer sehr anspruchsvolle Sachen


----------



## Jochen Kühner (10 Oktober 2012)

rostiger Nagel schrieb:


> Danke Jochen,
> auch das werde ich morgen testen, Blicke ich da durch?
> Du hast ja immer sehr anspruchsvolle Sachen



Wenn nicht... Schreib einfach...


----------



## SoftMachine (10 Oktober 2012)

.


rostiger Nagel schrieb:


> Danke Thomas, ja mit meinen Posteingang ist so ein Problem



Hi, RN
richtig, über deinen Posteingang bin ja nun nicht nur ich schon gestolpert... 




rostiger Nagel schrieb:


> ... das kleine Tool aus dem Link von Softmaschine ist ein tolles Tool, funktioniert gut.



Danke dafür, ich sehe, es hat geholfen. 


Der Jochen hat aber sicherlich auch eine pfiffige Lösung umgesetzt. 

Gruss an alle


----------



## rostiger Nagel (11 Oktober 2012)

Also mit dem Herkules Programm bekomme ich jetzt Daten, schön...

@Jochen,
dein Programm habe ich runtergeladen, dort bekomme ich eine Fehlermeldung das "Winsock.oxx nicht richtig installiert ist" oder so ähnlich.


----------



## Jochen Kühner (11 Oktober 2012)

Die ocx Datei ist nun mit im Zip File.

Auch hab ich auf meine Homepage eine neue Version des Kopplungstesters gelegt!


----------



## rostiger Nagel (11 Oktober 2012)

So Jochen jetzt geht es, dein Program ist auch ganz nett


----------



## Larry Laffer (11 Oktober 2012)

OK ... dann muß ich jetzt wohl nicht mehr 
Sorry - bin erst jetzt wieder am Draht ...


----------



## Lipperlandstern (11 Oktober 2012)

Und woran lag es jetzt ?


----------



## rostiger Nagel (11 Oktober 2012)

Ja wenn ich das wüsste, erstmal hatte das ich auf den Notebook keinen Empfänger,
das hab ich dann mit den Tool von Softmaschine hinbekommen. Dann hat er es ja immer
die Verbindung verworfen wenn ich was gesendet habe. Dann habe ich es Heute morgen
mit Herkules versucht und dann funktionierte es. 

Könnte daran liegen das ich die Rechner neu gebootet habe, da ich ja auch an den 
IP Adressen rumgespielt hatte, vlt war dieser Neustart erforderlich. 

Aber ich bin ein großes Stück weiter und bedanke mich bei allen für die Hilfreiche Unterstützung.


----------



## SoftMachine (12 Oktober 2012)

rostiger Nagel schrieb:


> .... das hab ich dann mit den Tool von SoftMachine hinbekommen.....
> Aber ich bin ein großes Stück weiter und bedanke mich bei allen für die Hilfreiche Unterstützung.



Na, das zählt auf jeden Fall. So soll es sein ! 
Ich denke, du wirst den (kleinen) Rest deines Problems bestimmt auch noch lösen ! 

Gruss

P.S. Und natürlich noch viel Erfolg !  
Gruss nach NRW


----------



## rostiger Nagel (12 Dezember 2012)

Ich hätte da noch einmal eine Frage, es sind beim Empfänger 3 Steuerzeichen zu sehen,
also vor den Gesendeten String. Wo kommen diese her oder wie bekomme ich diese weg?


----------



## Thomas_v2.1 (12 Dezember 2012)

Was sind das denn für Steuerzeichen?
Wenn es zwei Zeichen wären wäre meine Vermutung dass du evtl. einen String inkl. String-Kopfinformationen verschickst.


----------



## Lipperlandstern (12 Dezember 2012)

Sind bei einem String nicht immer 2 Steuerzeichen dabei ? (Stringlänge) Für das 3. hätte ich dann aber auch keine Erklärung. Wie empfängst du denn ? Kann das an der Software liegen ?


----------



## rostiger Nagel (12 Dezember 2012)

Am Empfänger liegt es nicht, das mit der Kopfinformation hört sich gut an.
Wie bekomme ich die weg? Ich habe an den TSEND einfach einen String, wo
Ich aus der HMI was reinschreibe und dann versende.

Gehört habe ich mit der Herkules Software, da hatte ich mir noch nichts dabei
gedacht, aber jetzt auf de Kundenmaschine waren die Zeichen auch da.


----------



## Lipperlandstern (12 Dezember 2012)

Also.... hast du in einem DB eine String deklariert ? Dann stell bei DATA (TSEND) mal den Zeiger auf 2 Byte später


----------



## rostiger Nagel (13 Dezember 2012)

ok das mit Axel seinen Tip geht...DANKE. So wie ich es mache finde
ich es zur Zeit nicht sehr schön, da ich immer versuche Symbolisch
zu Programmieren. 

Vorher sah es so aus.

```
CALL  #TSEND
       REQ   :=
       ID    :=#TCON_PAR.id
       LEN   :=#TCP.Laenge
       DONE  :=
       BUSY  :=
       ERROR :=
       STATUS:=
       DATA  :=[COLOR=#ff0000]#TCP.Daten[/COLOR]
```


jetzt sieht es so aus, was mir garnicht gefällt.

```
CALL  #TSEND
       REQ   :=
       ID    :=#TCON_PAR.id
       LEN   :=#TCP.Laenge
       DONE  :=
       BUSY  :=
       ERROR :=
       STATUS:=
       DATA  :=[COLOR=#ff0000]P#DB1921.DBX318.0 BYTE 254[/COLOR]
```

Ich habe den Kopf gerade wo anders und komme nicht drauf,
wie ich das Eleganter lösen kann. Hat da jemand einen Tip für
mich?


----------



## Ralle (13 Dezember 2012)

Also wenn du es sauber symbolisch machen willst, dann mußt du zumindest in einem Netzwerk den Any deines Strings (nichts anderes ist ja #TCP.Daten) auseinanderlegen, das Ganze auf eine Temp-Any legen und bei der Startadresse dann halt 2 Zähler dazuaddieren, um den Kopf wegzubekommen.


----------



## rostiger Nagel (13 Dezember 2012)

ja das habe ich befürchtet, dann will ich das mal so machen....puh


----------



## Larry Laffer (13 Dezember 2012)

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


----------



## rostiger Nagel (13 Dezember 2012)

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...


----------



## Larry Laffer (13 Dezember 2012)

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


----------



## rostiger Nagel (13 Dezember 2012)

Hi Ralf

String Char habe ich heute Nachmittag bei Flex nicht gefunden.

Wie so etwas in SCL aussieht würde mich schon Interessen.


----------



## Larry Laffer (13 Dezember 2012)

In etwa so :
	
	



```
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


----------



## rostiger Nagel (13 Dezember 2012)

Das gefällt mir, muß ich probieren.


----------



## Lipperlandstern (13 Dezember 2012)

rostiger Nagel schrieb:


> ok das mit Axel seinen Tip geht...DANKE. So wie ich es mache finde
> ich es zur Zeit nicht sehr schön, da ich immer versuche Symbolisch
> zu Programmieren.



Sind mit diesem "Trick" jetzt alle 3 Steuerzeichen weg ?


----------



## rostiger Nagel (13 Dezember 2012)

Ja sind Sie, die zwei.


----------



## rostiger Nagel (26 Januar 2013)

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.


----------



## Thomas_v2.1 (26 Januar 2013)

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.


----------



## RobiHerb (27 Januar 2013)

*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.


----------



## rostiger Nagel (27 Januar 2013)

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.


----------



## Larry Laffer (27 Januar 2013)

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


----------



## rostiger Nagel (27 Januar 2013)

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?


----------



## Thomas_v2.1 (27 Januar 2013)

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?



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.


----------



## Thomas_v2.1 (27 Januar 2013)

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.


----------



## NochEinProgrammierer (27 Januar 2013)

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.


----------



## Larry Laffer (27 Januar 2013)

... 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 ...


----------



## Thomas_v2.1 (27 Januar 2013)

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.


----------



## Larry Laffer (27 Januar 2013)

... 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 ...


----------



## Thomas_v2.1 (27 Januar 2013)

Bei so einem Verhalten der Send-Bausteine ist es sogar durchaus sinnvoll für jeden Sendevorgang eine neue Verbindung aufzubauen, so bekommt man wenigstens beim Verbindungsaufbau eine zuverlässige Aussage über den Zustand. Löst aber nicht das eigentliche Problem dass die 1200 eigentlich kein TCP beherrscht, zumindest spricht sich das nicht bis ins SPS Programm durch.


----------



## rostiger Nagel (27 Januar 2013)

Sehr Interessant, 
ich mache morgen auch mal die Tests
mit Herkules, WinAC und Step 7 Classic. 
Mal schauen was da heraus kommt. 

Danke für die Hilfe


----------



## dalbi (27 Januar 2013)

Hi Helmut,

hab das mal probiert auf einer Win AC.

Ergebnis war der T_SEND (Version 2.1) liefert sofort nach dem senden einen Fehler (ERROR = TRUE) (STATUS = 80C4).

80C4: Temporärer Kommunikationsfehler
- Die Verbindung zum Kommunikationspartner kann momentan nicht aufgebaut werden.
- Die Schnittstelle wird neu parametriert bzw. die Verbindung wird gerade aufgebaut.

Wenn der T_RECV (Version 2.2) am EN_R immer auf TRUE steht so gibt auch dieser nach ca. 30 Sekunden eine Meldung (ERROR = TRUE) (STATUS = 80C4).

Gruss Daniel


----------



## rostiger Nagel (29 Januar 2013)

dalbi schrieb:


> Hi Helmut,
> 
> hab das mal probiert auf einer Win AC.
> 
> ...



Also es ist so wenn die Gegenseite abgeschaltet ist (in meinen Testaufbau, das "Herkules" Tool) bekommt man die Fehlermeldung 80C4.
Zieht man aber den Stecker ab, werden die Daten rausgerotzt ohne Fehlermeldung und das DONE-Bit wird gesetzt. Das ist doch irgendwie
Käse.


----------



## Thomas_v2.1 (29 Januar 2013)

Was hast du denn für einen Rechner auf dem die WinAC läuft? Mit Windows XP, oder CE? Vielleicht gibt es da betriebssystemabhängige Unterschiede.
Und mal die Bausteinversionen vergleichen, ob du da auf dem aktuellen Stand bist.


----------



## dalbi (29 Januar 2013)

Hi Helmut,

ich hatte auch das Netzwerkkabel abgezogen. Allerdings geht es bei mir über einen Switch sollte aber eigentlich egal sein.
Was macht T_RECV kommt da ein Fehler?

Gruss Daniel


----------



## rostiger Nagel (29 Januar 2013)

Also Rechner ist es ein IPC 477C mit XP, Siemens Standard, da du Thomas ja das selbe Problem
bei eine 1200er hast, würde ich auf ein Siemns Bug tippen. 

Den T_REC verwende ich garnicht, da nur ich sende.


----------



## Matze001 (29 Januar 2013)

Ich möchte mich hier auch mal einklinken, da ich gerade mit etwas ähnlichem Beschäftigt bin.

Aufgabenstellung: HTTP-GET mit ner IM151-8F PN/DP.

Mit dem T_SEND, Wireshark und etlichen Litern Cola hat das ganze funktioniert. 

Ein paar Fragen sind trotzdem hängen geblieben:

T_RECV: Wenn ich als LEN einen Wert > 0 angebe werden die Daten erst in den DB kopiert wenn sie die angegebene Größe erreichen. Wenn ich LEN = 0 angebe, wird nach jeden "Übertragung fertig" vom Partner der Datensatz übernommen.

Da die Länge bei mir variabel ist, würde ich gern LEN = 0 nutzen, aber dann kommen immer nur 280 Byte an, ganz selten mal (alle 2-3min) kommen mal die vollen rund 800 Byte... Vielleicht muss ich mir nochmal eine "Fangschaltung" bauen, und gucken ob das stimmt, oder ob ich mit meinem Beobachten einfach nur zu langsam bin. Aber kennt ggf. jemand dieses Phänomen?

Da wie schon mal erwähnt ca. 800 Byte ankommen, zwingt die Auswerterei meine CPU in die Knie. Bis jetzt hab ich es sehr unelegant gemacht: Eine FOR-Schleife die von 0..799 durch mein Array of CHAR wuselt und dann mit IF CHAR(for_var) = 'a' THEN etc. nach bestimmten Zeichenfolgen gesucht und Anschließend in einer weiteren Schleife zu einem String zusammengebaut. Ein weiterer Ansatz wäre es dieses Array of Char mit einer AT-Ansicht auf mehrere String aufzuteilen und dann einen FIND(); drauf loszulassen. Gibt es hier einen eleganteren Ansatz (in SCL?).

Ach noch ne Info hinten dran:

Gegenseite Ausschalten gibt bei mir 80C4, Kabel ziehen habe ich noch nicht probiert, sollte aber auch das gleiche Verhalten haben (kann ich ggf. Morgen früh schnell nachstellen).

Grüße

Marcel


----------



## rostiger Nagel (29 Januar 2013)

Marcel du könntest auch die Cola in die
Steuerung kippen, aber melde dich trotzdem 
mal.


----------



## rostiger Nagel (30 Januar 2013)

Hallo Marcel,
ich habe mir deinen Beitrag noch einmal durchgelesen, also da ich ja weiß das du
auch den IPC einsetzt würde ich die String Auswertung nach Flex verlegen und das ganze
in einen Script machen, da sind die Möglichkeiten ganz andere, wie auf Steuerungsseite. 

Zu den Problem mit deinen Datenhandling, da du ja beide Steuerungen hast. Kannst du nicht 
Zwei Telegramme schicken, das erste mit 'Hallo gleich kommt ein Telegramm mit 3xyz Zeichen'
und dieses bestätigst du mit 'ja Schick mal los', dann wird erst das eigentliche Telegramm gesendet.


----------



## Matze001 (30 Januar 2013)

Hallo Helmut,

leider ist das nicht so einfach wie ich es gern hätte!

Die IM151-8F PN/DP ist an einer Maschine mit einem Webserver, aus welcher ich bestimmte Stati auslesen möchte.
Der IPC wird "nur" mitverkauft, wenn der Kunde eine Roboterzelle mit Palettierung etc. erwirbt. Somit habe ich nicht 
immer den IPC zur Verfügung, und versuche meinen Weg direkt in der IM151-8F PN/DP zu gehen.

Wenn das nicht zufriedenstellend klappen sollte, wird dieses "Feature" nur für Anlagen mit IPC zur Verfügung stehen, aber ich versuche es erstmal so!

Grüße

Marcel


----------



## rostiger Nagel (30 Januar 2013)

Aber das mit den Handshake würde ich mir mal überlegen, also das du im einen ersten Telegramm, erstmal die
zu erwartenede Länge schreibst und dann das zweite eigentliche Telegramm. Ich könnte mir vorstellen das dann
das DONE-Bit erst kommt wenn das ganze Telegramm eingeflogen ist. 

Und schon den Stecker gezogen....?


----------



## Matze001 (30 Januar 2013)

Guten Morgen,

mein Partner ist fix, an dem kann ich nix schrauben... leider!

Stecker ist noch nicht gezogen, bin Heute per Alarmstart unterwegs und werde das Geschäft gleich nur vom Parkplatz aus sehen...

Grüße

Marcel


----------



## rostiger Nagel (30 Januar 2013)

jetzt mal wieder zu meinen Problem, weiß den jemand wie man feststellen kann ob eine Verbindung noch besteht, vlt. irgend einen schönen SFB / SFC.
Was ich sehen kann ist das die Busfehler LED kommt, die könnte man ja zb auch auswerten.


----------



## rostiger Nagel (30 Januar 2013)

So jetzt habe ich es auch einmal mit dem Siemens Support versucht....betonung liegt auf Versucht.

Dort war ein sehr unfreundlicher Herr der noch nicht einmal meine Sprache gesprochen hat, es war
eine Mischung aus Bayerisch und Fachidiotie. Ich habe ihn versucht mein Problem auf Hochdeutsch
zu erklären, ich glaube nicht das er mich richtig verstanden hat. Das was ich verstanden habe das 
die TCP Verbindung Normen Komform wäre und der Baustein das 'DONE' Bit setzt wenn das Telegramm
abgesetzt wurde. Als ich den Einwand bringen wollte, das der Baustein erkennen würde das wenn die
Anwendung auf der Gegenseite nicht bereit ist, eine Fehlermeldung bringt, dieses aber nicht tut wenn
ich den Stecker ziehe, hörte ich wieder das alles Normenkomform sei, woher soll der Baustein wissen
das der Stecker gezogen würde und das die Fehlermeldung kommen würde weil wahrscheinlich der 
Sendepufffer voll ist. Ich sagte, das ich aber nur ein kurzes Telegramm von 50 Zeichen habe, das müsste
er doch locker speichern können und die Fehlermeldung* sagt doch etwas völlig anderes aus, des weiteren
bekommt doch die Steuerung mit das etwas nicht stimmt und zeigt dieses durch einen Busfehler an,
aber er ließ meinen Einwand nicht gelten.
Meine Frage war, ob er mir bei meinen Problem auch nicht weiterhelfen kann, er erwiderte Nein.
Dann habe ich mich verabschiedet und das Gespräch beendet.

*


> Fehler hex 80C4
> 
> Temporärer Kommunikationsfehler:· Die Verbindung zum Kommunikationspartner kann momentan nicht aufgebaut werden.
> 
> Die Schnittstelle wird neu parametriert bzw. die Verbindung wird gerade aufgebaut.




Danke sehr ..... :evil:


----------



## Larry Laffer (30 Januar 2013)

Aber nicht das du jetzt auch noch einen "so langsam reicht es"-Thread aufmachst ... 

In dem Fall wäre jetzt vielleicht doch ein Handshake angebracht.
So würdest du dann ja dadurch, dass du nach Zeit x keine Antwort erhältst, dann doch wissen, dass etwas nicht stimmt ...

Gruß
Larry


----------



## rostiger Nagel (30 Januar 2013)

neh Ralf,
das mit den Thread lass ich mal...mit den Handshake wird auch wohl nichts werden, die 
Gegenseite ist ein größerer Maschinenbauer die eine Standardanwendung am laufen haben,
die werden nicht auf meine Probleme eingehen.

Ich werde versuchen das ständige Verbindung auf und wieder Abbauen raus zu nehmen, wie du
es mir schon empfholen hast. Ich denke da liegt der Hase begraben, ich baue dann immer in
der Initalisierungsphase der Schrittkette die Verbindung auf, wenn Sie schon steht bekomme 
ich ja durch den Status des TCON eine rückmeldung ob Sie schon aufgebaut ist und baue Sie erst
garnicht mehr ab. Und dann heißt es beobachten.....


----------



## dalbi (30 Januar 2013)

Hi Helmut,

ja die BF Lampe kann man auch auswerten. 
Das geht mit dem SFC51 "RDSYSST" SZL_ID W#16#19 INDEX 0.

Rufe doch einfach den T_RECV mit dauer TRUE auf dieser sollte zwar etwas verzögert auch einen Fehler bringen.

Gruss Daniel


----------



## rostiger Nagel (30 Januar 2013)

Hi Daniel,
die Auswertung ist Standard mäßig in meinen Projekt schon drin, 
ich geplannt diese auch zu nutzen.

gruß


----------



## Thomas_v2.1 (30 Januar 2013)

Ich habe nochmal das Verhalten bei der 1200 überprüft, nach einiger Zeit kommt dort auch ein Fehler beim Senden wenn die Verbindung nicht mehr steht. 
Das ist am PC bei einer winsock Verbindung vom Prinzip her sogar genauso, wobei man dort die Zeiten und das Verhalten genauer einstellen kann. Ist also durchaus Ansichtssache wie sich die T-Bausteine verhalten sollten.

Wenn du eine Verbindung aufbaust, den Tsend aufrufst und danach direkt wieder abbaust bekommst du einen Fehler beim Tsend wahrscheinlich nie zu Gesicht.
Ob das Ganze mit einer dauerhaften Verbindung zuverlässiger wird, hängt davon ab wie oft du Daten sendest und wie lange es letztendlich dauert bis der Tsend einen Timeout meldet.
Wenn du beispielsweise auf der Dauerverbindung sekündlich ein Telegramm abschickst, aber erst nach 30 Sekunden einen Timeout gemeldet bekommst sind schon 30 Telegramme verloren gegangen.
Wenn du nur minütlich schickst geht maximal eines verloren. Ein Telegramm geht auf jeden Fall immer flöten, da der Tsend ja erstmal mit Done Erfolg meldet und du davon ausgehst dass die Daten erfolgreich abgeschickt wurden.

Wenn das wichtig ist dass jedes Telegramm auf alle Fälle ankommen muss, kommst du wohl nicht umhin auf Anwendungsebene noch ein Handshake einzurichten.


----------



## rostiger Nagel (30 Januar 2013)

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.


----------



## Thomas_v2.1 (30 Januar 2013)

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?


----------



## rostiger Nagel (30 Januar 2013)

Da muß ich morgen mal schauen....Fortsetzung folgt....!


----------



## rostiger Nagel (4 Februar 2013)

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.


----------



## PN/DP (4 Februar 2013)

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


----------



## rostiger Nagel (4 Februar 2013)

Wie bereits geschrieben, die Lämpchen werden *noch* ausgewertet. Handshake ist auch mein 
Primärer Wunsch, leider geht der externe Maschinenbauer nicht darauf ein.


----------



## NochEinProgrammierer (4 Februar 2013)

rostiger Nagel schrieb:


> 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.




rostiger Nagel schrieb:


> 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.


----------



## MBr (4 Februar 2013)

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.


----------



## rostiger Nagel (4 Februar 2013)

NochEinProgrammierer schrieb:


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



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.


----------



## NochEinProgrammierer (4 Februar 2013)

Autsch, also das allseits bekannte "Haben wir schon immer so gemacht und diskutieren da nicht drüber"-Argument.


----------



## rostiger Nagel (4 Februar 2013)

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.


----------



## Larry Laffer (4 Februar 2013)

@RN:
Ein in deiner Branche recht bekannter Maschinen-Hersteller aus dem Schwarzwald ?


----------



## rostiger Nagel (4 Februar 2013)

Larry Laffer schrieb:


> @RN:
> Ein in deiner Branche recht bekannter Maschinen-Hersteller aus dem Schwarzwald ?



Ja genau der H...g, und das Projekt wurde mit einer Tochter W...e aus OWL gemacht.


----------



## Thomas_v2.1 (4 Februar 2013)

PN/DP schrieb:


> 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.


----------



## rostiger Nagel (4 Februar 2013)

Die Leitung Siemens <-> Beckhoff ist direkt, jeder hat dem anderen eine eigene
Netzwerkkarte zugestanden, es kann niemand dazwischen Funken.


----------



## rostiger Nagel (11 Februar 2013)

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.


----------



## Matze001 (11 Februar 2013)

sieht echt chick aus!

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

Grüße

Marcel


----------



## rostiger Nagel (11 Februar 2013)

Das mit dem Profibus habe ich erst nach dem hochladen gesehen, ist aber schon geändert.


----------

