Step 7 ISO-on-TCP-Verbindung zwischen S7-400 und S7-1500

[C_wie_Cäsar]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo Zusammen,

ich habe heute folgendes Anliegen. Ich soll zwischen zwei verfahrenstechnischen Anlagen eine Verbindung aufbauen. Damit sollen die Chargennummer (10 stellige Zeichenfolge), ein Trigger (BOOL) und eine IO/NIO (BOOL) Rückmeldung übertragen werden. Kurz zum Ablauf:
- Anlage 1 pumpt Medium zu Anlage 2
- Sobald Anlage 1 den Trigger zu Anlage 2 schickt, wird die momentan übertragene Chargennummer gespeichert
- Anlage 2 schickt dann nach dem Speichervorgang eine Rückmeldung zu Anlage 1

In der Anlage 1 ist eine S7-400 CPU (mit CP 443) verbaut und in Anlage 2 eine S7-1500 CPU. Die Kommunikation soll über das Gebäude Ethernet Netz laufen. Mein Plan wäre, in der CP der S7-400 eine ISO-on-TCP-Verbindung anzulegen und die Daten mit dem AG_SEND Baustein Richtung TIA-Steuerung zu schicken und wiederum die Daten mit dem AG_RECV Baustein von der TIA-Steuerung zu erhalten. Mein Problem ist, bei der Anlage 1 laufen momentan bereits einige Ethernet-Verbindungen drüber. Ich möchte ungern mit meiner zusätzlichen Ethernet Verbindung einen Ausfall der anderen Verbindungen oder gar einen CPU Stopp provozieren. Deswegen sind meine Fragen:
1. Kann eine Fehlerhafte projektierte Ethernet Verbindung zu mehr führen als zu einer nicht aufgebauten Verbindung?
2. Kann eine zusätzliche Ethernet Verbindung zu einem Abbruch oder Beeinträchtigung der anderen Verbindungen führen?
2.1. Falls ja, ist das dann sofort ersichtlich oder kann es zu sporadischen Ausfällen führen?
3. Gibt es eine elegantere Lösung als eine nicht spezifizierte Verbindung mit AG_SEND und AG_RECV?

Vielen Dank im Voraus

Grüße, Cäsar

 

[SPS-Andy]

Hallo,
warum nicht mit S7 Kommunikation PUT/GET?

 

[C_wie_Cäsar]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo,
warum nicht mit S7 Kommunikation PUT/GET?

Ist bei uns in der Firma nicht gern gesehen.

 

[DennisBerger]

warum?

 

[Thomas_v2.1]

Prinzipiell lassen sich neue Verbindungen bei der 400er in RUN laden, und bei allem was mir bisher aufgefallen ist, werden dadurch bestehende Verbindungen nicht beeinträchtigt.

Mir ist nur kürzlich aufgefallen, dass wenn man so etwas bei einer 400er im PCS7 Umfeld macht, es zu einer kurzen Meldung auf der OS führt, dass alle Verbindungen ausgefallen wären. Seitdem bin ich mir nicht mehr ganz so sicher, ob das nicht doch evtl. zu einem kurzen Abbau führt. Aber ich denke mal eher das sind fehlerhafte Diagnosemeldungen, bei PCS7 musst du auf jeden Fall jemanden der OS vorwarnen, dass es eine Meldung gibt.

Auf jeden Fall sollte die Verbindung und auch die Programmierung beim ersten Mal sitzen. Denn bei der 400er werden beim Erstaufruf der Bausteine interne Puffer auf einer Verbindung reserviert. Also einmal aufgerufen und Datenbereich verkleinern geht, aber nicht vergrößern. Das geht nur über SPS Stopp, oder eine zusätzliche neue Verbindung, und die Verbindungs-Leiche dann wenn Stopp möglich abräumen.

 

[C_wie_Cäsar]

Zuviel Werbung?
-> Hier kostenlos registrieren

warum?

Bei uns heißt es, dass es ein unsauberer Programmierstil ist. Ich lass mich aber gern vom Gegenteil überzeugen

 

[Matze001]

Das doofe an PUT/GET ist halt, dass die Steuerung in die geschrieben wird keine Info hat das dies passiert.
Man sieht keine Verbindung, keinen Querverweis, nichts. Wenn man einen Sauberen DB macht, und dann darin zwei UDT mit PUT und GET als Namen, dann kann man schon drauf schließen was da passiert. Wenn man einfach in anderen DBs oder gar Merkern rumschreibt, wird es halt unsauber.

Grüße

Marcel

 

[SPS-Andy]

Das man das sauber am besten in einen extra DB Programmiert, ist denke ich selbstverständlich!
(Kann man dann wie E/A´s weiterverarbeiten)
Als zusätzliche Sicherheit kann noch ein Lebensbit der jeweilig anderen Steuerung ausgewertet werden.
Und sollte man in oben beschriebenem Fall immer noch Angst haben, das was verloren geht, kann die Steuerung die die Ch. Nummer empfängt als Empfangsbestätigung nicht nur mit einem Bit antworten sondern als Antwort die CH. Nummer zurücksenden.

Mittlerweile gibt es bei 1500 Steuerungen natürlich i-Device was noch komfortabler ist. Ist hier aber nicht relevant.

 

[Thomas_v2.1]

Zuviel Werbung?
-> Hier kostenlos registrieren

Mittlerweile gibt es bei 1500 Steuerungen natürlich i-Device was noch komfortabler ist. Ist hier aber nicht relevant.

Bei I-Device kannst du aber überhaupt nichts in RUN laden.

Du kannst ja auch einen Kompromiss eingehen, und zuerst die DBs in der 400er anlegen und von der 1500er darauf mit Put/Get zuzugreifen. Und wenn auch mal mit wenn auch geringster Wahrscheinlichkeit eine Unterbrechung möglich ist, stellst du dann auf zweiseitige Iso-On-TCP Verbindung um. Aber wie das so ist, wenn es einmal läuft wird das auch nicht mehr geändert.

 

[C_wie_Cäsar]

Dann spar ich mir praktisch auf der S7 Seite das Anlegen einer Ethernet Verbindung, richtig? Gibt es noch weitere Vorteile? Für mich hört sich die Idee von Thomas gut an. Als ersten "Versuch" die PUT/GET Lösung und wenn es Probleme gibt auf ISO-ON-ETHERNET umstellen. Werde mich mal mit den zwei Bausteinen auseinander setzen. Danke schon mal !

 

[Thomas_v2.1]

Einseitiges Put/Get hat eben nur den Nachteil, dass es nicht ganz so einfach nachvollziehbar ist, wer mit wem kommuniziert. Bei einem kleinen autarken Netzwerk mit einer handvoll Steuerungen kann man das mit expliziten Kommunikations-DBs meiner Meinung nach machen. Aber wenn du schreibst in der 400er sind schon mehrere Verbindungen projektiert, vielleicht auch zu Steuerungen von denen du selber nichts weißt wer das ist, dann würde ich schon darauf achten, dass Konzept auch fortzuführen und alles in NetPro zweiseitig zu konfigurieren.

 

[Matze001]

Zuviel Werbung?
-> Hier kostenlos registrieren

Oder was viele auch gemacht haben die ich kenne nie mit PUT arbeiten, sondern immer nur mit GET.
Das heißt beide Steuerungen lesen nur Daten aus der jeweils anderen. Dann hat man auch Kommunikationsbausteine in beiden Steuerungen, und kann sich dann ganz in Ruhe um die Auswertung / Diagnose / Fehlerhandling usw. kümmern.

Grüße

Marcel

 

[Holzmichl]

Ich arbeite praktisch auch nie mit PUT, sondern nur mit GET und dabei in der jeweiligen SPS immer ein DB mit "KOMM xyz GET".
Die einzige Ausnahme gibt es bei Anlagen, bei denen ein Kommunikationsparter abgeschaltet, abgesteckt etc wird, da dann dieser die PUT+GET-Aktionen ausführt. Dann entstehen keine Fehlermeldungen im Programm oder LED bei der Haupt-CPU. Die Programmsteuerung und Meldung generieren sich über ein wechselseitiges Lifesign mit Auswertung und Timeout.
In dem Fall dann 2 DBs mit KOMM xyz GET und KOMM xyz PUT.

 

[UDP]

Viele Wege führen nach Rom:

Auf der 400er mit den TCON Bausteinen (TCON, TSend, TRecv, TDiscon) einen kleinen Kommunikationsbaustein auf UDP Basis machen, schont das Netzwerk, dafür muss man den Handshake selbst basteln. Geht alles ohne die CPU in Stop zu setzen oder die anderen Verbindungen zu beeinträchtigen. So einen Baustein kann man auch als flexiblen Standardbaustein nutzen, wenn man eh häufig Kommunikationen zwischen Steuerungen hat.

Auf der 1500er Seite dann die Trecv_C und TSenc_C Bausteine, die sind noch etwas komfortabler.

 

[koderko]

Zuviel Werbung?
-> Hier kostenlos registrieren

Also...ganz ehrlich, in der heutigen Zeit sollte man versuchen, von veralteten Kommunikationsmethoden abzusehen. Dazu gehört meiner Ansicht nach PUT/GET-Kommunikation dazu. Hier kann dir jeder in der Steuerung rumpfuschen, sobald diese Option aktiviert ist. Deshalb muss sie auch bei den neuen CPUs explizit aktiviert werden:

Ich kann schon verstehen, dass das bei euch im Unternehmen nicht gerne gesehen ist.

Eine ISO-on-TCP-Verbindung halte ich auch für das Mittel der Wahl. Mit sauber definierten Austauschbereichen ist das eine zuverlässige Sache.

 

[Thomas_v2.1]

Also...ganz ehrlich, in der heutigen Zeit sollte man versuchen, von veralteten Kommunikationsmethoden abzusehen. Dazu gehört meiner Ansicht nach PUT/GET-Kommunikation dazu. Hier kann dir jeder in der Steuerung rumpfuschen, sobald diese Option aktiviert ist. Deshalb muss sie auch bei den neuen CPUs explizit aktiviert werden:

Wenn er von der 1500er nur eine Verbindung zur 400er aufbauen will, muss diese Option meiner Meinung nach nicht gesetzt werden. Auch andere S7-Kommunikationen wie BSEND oder USEND funktionieren von einer 1500er zu einer 300/400er ohne diese Option aktivieren zu müssen.

 

[ducati]

Wir verwenden in der Regel nur BSEND BRCV. Wird von den meisten CPUn unterstützt und kann viel mehr Daten übertragen als PUT GET.
Wenn man keine Verbindungen anlegen kann, wegen CPU Stopp, wäre TSEND TRCV eine Überlegung werd. Unterstützen nicht alle SPSn bzw. CPs...

Ein Großkunde von uns hatte letztens den Fall, hat ein SPS-Projekt als Vorlage benutzt, wo PUT verwendet wurde. Der Programmierer hat vergessen, das zu ändern. Danach haben dann 2 SPSn im Netztwerk auf die selbe andere CPU geschrieben Gab einen riesen Ärger und hat ewig gedauert, bis jemand das Problem gefunden hat...

Das Problem heute, dass immer mehr Kunden alle SPSn in nen gemeinsames Netzwerk hängen Da gibts mit PUT ganz schnell Ärger. Früher wo nur die 2 SPSn verbunden wurden, welche auch wirklich Daten austauschen, war PUT noch nicht so problematisch.
Heute gehört PUT verboten!

 

[Dantical]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo,
bei einer 1500er Steuerung muss doch nach anlegen einer neuen Verbindung immer die Hardwarekonfig. neu geladen werden, was einen Stopp der CPU nach sich zieht.

Oder lieg ich hier falsch?

 

[koderko]

Wenn du die Verbindung projektierst, dann ja. Es gibt allerdings auch die Möglichkeit, die Verbindung zur Laufzeit nur in der Software anzulegen. Dann ist das nicht nötig.

 

[Dantical]

Okay, ich hatte bei meiner letzten TCP Verbindung die ich bei einer 1500er hinzugefügt hatte das Problem, das diese erst nach einspielen der Hardwarekonfig. funktionierte.