Der falsche Ansatz ...
Hallo,
MW" schrieb:
dann kann man aber auch gleich die erste Verbindung FETCH passiv machen und alles vom PC machen lassen.
Genau richtig... Wir reden hier von einer Kopplung PC <--> SPS.
Die SPS hat die Fresse zu halten, die Kommunikation sollte hier durch den PC bestimmt werden. Wenn beide Verbindungspartner munter drauf los senden, wird man ganz schnell Probleme bei der Kommunikation bekommen. Die Kommunikation sollte nur vom PC bestimmt werden. Wenn die SPS neue Daten für den PC bereit hat, darf die SPS mir durch das Setzen z.B. eines Merkers mitteilen. Der OPC-Server teilt durch einen Event meiner Applikation auf dem PC mit, dass die SPS neue Daten hat, die lese ich dann mit meiner Applikation aus dem vereinbarten Datenbereich der SPS aus und verarbeite diese (z.B. Weitergabe an die BDE-Datenbank etc.).
Umgekehrt schreibe ich neue Daten ungefragt in die SPS, ich erwarte von der SPS dass sie diese Daten entsprechend verarbeitet.
Dafür sind in der S7-SPS für die Kommunikation keine zusätzlichen FBs, FCs, SFBs, SFCs und Konsorten aufzurufen, egal ob welches Protokoll. Nur bei der Kommunikation mit einer S5 müssen die HTB's "SEND-ALL" und "RECV_ALL" im S5-AG aufgerufen werden.
Bei der Kommunikation zwischen zwei oder mehreren Koppelpartnern (egal ob z.B. SPS <--> SPS oder SPS <--> PC) darf nur ein Partner die Kommunikation koordinieren, sonst gibt es immer Probleme. Von daher ist hier schon völlig falsch an die Aufgabenlösung herangegangen worden, bei der Kopplung SPS <--> PC sollte immer der PC die Kommunikation koordinieren. Aber einfach nur, weil man das auf dem PC z. Zt. mit geringerem Aufwand realisieren kann.
MW" schrieb:
Bei FETCH/WRITE muss man aber auch noch den Telegrammkopf zusammenbauen damit die SPS weiß was man von ihr will.
Nööö, eigentlich nicht ...
Und UDP sollte man bei dieser Art von Kommunikation sowieso vergessen, UDP ist im Gegensatz zu TCP verbindungslos. Ist ungefähr so, als wenn ich einen Brief nicht in den Briefkasten werfe sondern auf der Strasse ablege. Wenn jemand den Brief findet und bei der Post einwirft, habe ich Glück gehabt. Aber was noch schlimmer ist, ich werde nie erfahren, ob der Brief angekommen ist.
Als Kommunikationstreiber auf dem PC sind bei mir aus langer Erfahrung folgende Produkte zu empfehlen :
1) OPC-Server z.B. Simatic-Net oder Deltalogic
Vorteil : Events in meiner Applikation, wenn sich Daten in der SPS ändern
Nachteil : Projektierung in der SPS(z.B. NetPro) erforderlich
2) AG-Link 4.0 von Deltalogic
Vorteil : Keine Projektierung in der SPS erforderlich, du bist sozusagen "on the fly" auf der SPS
Nachteil : Evtl. Änderungen in der SPS müssen durch Polling erfasst werden.
Beide Varianten funktionieren aber bei meinen abgewickelten Projekten schon jahrelang in der Industrie ohne Probleme.
Gruß
Question_mark