Kommunikation SPS mittels PUT/GET

Zuviel Werbung?
-> Hier kostenlos registrieren
Eher unwahrscheinlich. Denn dann würde es nie funktionieren.
Bei S7-Verbindungen ist der TSAP wichtig, der ist auf Deinem Bild aber gar nicht zu sehen.

Harald

Meinst du dieses Bild?

Genutzt werden wie lt. Handbuch von VIPA SFB14/SFB15

Muss die Verbindung für Maschine B auch in die Hardwarekonfiguration? ( die ich in der Netzansicht für Maschine A angelegt habe ).
Bin davon ausgegangen das es genügt wenn alles nur auf der Maschine A programmiert wird.
 

Anhänge

  • S7-Verbindung.jpg
    S7-Verbindung.jpg
    87,8 KB · Aufrufe: 20
Es reicht, nur in Maschine A eine "einseitige" Verbindung zu projektieren zum TSAP 03.02 der Maschine B, und auch nur in Maschine A zu programmieren.
Hauptsache Du verwendest die Bausteine aus der VIPA-Bibliothek. Warum verwendest Du die SFB 14/15? Die funktionieren S7-400-kompatibel. Versuche mal die FB 14/15

Harald
 
Zuviel Werbung?
-> Hier kostenlos registrieren
In diesen Handbuch (für VIPA 315-4PN12, aber ich vermute es gelt auch für VIPA 315-4PN33)
http://www.vipa.com/uploads/tx_sbdownloader_new/HB140E_CPU_315-4PN12_14-29_01.pdf
Steht dies:
For data transfer with Siemens S7 connections the FB/SFB VIPAhandling blocks are necessary; the deployment is described in themanual "Operation list" of your CPU.

verdammt. Wieder war Harald schneller !
 
Bei der VIPA-CPU 315-4PN33 müssen spezielle FB aus einer VIPA-Bibliothek verwendet werden. Die VIPA-FB/SFB 14/15 rufen intern spezielle SFC200 AG_GET und SFC201 AG_PUT auf.
CPU 315-4PN33 - SPEED7 CPU 315SN/PN ECO Handbuch (pdf)

CPU 31xS(C) - SPEED7 - Operationsliste (pdf)

Harald

Also Stand ist folgender:

Ich habe anscheinenden die Siemens PUT/GET-Bausteine benutzt.
Nachdem ich die Bibliothek von VIPA runtergeladen habe und mit dessen PUT/GET gearbeitet habe. Bleibt das Problem immer noch bestehen.
Zum Testen der neuen Bausteine habe ich die CPU von STOP auf RUN gesetzt und die Verbindung funktioniert.
Allerdings nach dem Netz-AUS -> Netz-EIN, funktioniert sie wieder nicht.

Meine Frage bezieht sich auf das angehängte Bild. Wenn ich eine S7-Verbindung zu einem Unbekannten Partner aufbaue, ist es dann wichtig das die Baugruppenträger / Steckplatz die sein müssen wie sie in der anderen Maschine konfiguriert sind oder spielt das keine Rolle?
Falls ja Frage ich mich, warum nach STOP/RUN die Verbindung dennoch funktioniert.

So langsam bin ich echt ratlos und weiß nicht wo ich noch suchen soll :confused:
 

Anhänge

  • S7-Verbindung2.jpg
    S7-Verbindung2.jpg
    83,3 KB · Aufrufe: 18
Rack/Slot ist bei Siemens S7-300 immer 0/2. Egal ob über CP oder integrierte Schnittstelle.
Ein VIPA ist Prinzipiell kompatibel mit ein S7-300 + CP, aber ob da trotzdem ein Unterschied ist oder nicht ? Steht was im Handbuch ?

edit: Die Lokale CPU hat 0/2. Da es auch um eine VIPA handelt muss der Partner auch die 0/2 haben.

Ob es mit diesen Problem zu tun hat ist aber unklar. Eigentlich nicht, weil dann wurde die Verbindung gar nicht funktionieren.
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
Probier trotzdem meinen Vorschlag, die ganze code auskommentieren.
Wenn es dir gelingt in ein Beobachtungstabelle durch REQ die DONE von FALSE auf TRUE zu wechseln ohne die CPU ein Stop und Start zu machen, dann weis du wie die Code funktionieren muss.
 
Rack/Slot ist bei Siemens S7-300 immer 0/2. Egal ob über CP oder integrierte Schnittstelle.
Ein VIPA ist Prinzipiell kompatibel mit ein S7-300 + CP, aber ob da trotzdem ein Unterschied ist oder nicht ? Steht was im Handbuch ?

edit: Die Lokale CPU hat 0/2. Da es auch um eine VIPA handelt muss der Partner auch die 0/2 haben.

Ob es mit diesen Problem zu tun hat ist aber unklar. Eigentlich nicht, weil dann wurde die Verbindung gar nicht funktionieren.

Ja genau, das denke ich nämlich auch.
Ich habe anbei die Kommunkations-Diagnose angehängt.

Das verändern der HW-Konfig, dass der Partner auch 0/2 kann ich erst morgen machen, die Maschine muss wieder in Produktion.

Ich glaube kaum das das den versprechenden Erfolg bringt, ihr hättet jetzt so langsam auch keine Ansätze mehr wo ich suchen könnte?!
 

Anhänge

  • Kommunikationsdiagnose.jpg
    Kommunikationsdiagnose.jpg
    137,7 KB · Aufrufe: 18
Probier trotzdem meinen Vorschlag, die ganze code auskommentieren.
Wenn es dir gelingt in ein Beobachtungstabelle durch REQ die DONE von FALSE auf TRUE zu wechseln ohne die CPU ein Stop und Start zu machen, dann weis du wie die Code funktionieren muss.

Das habe ich bereits gemacht, auch hier startet die Verbindung nicht. Erst nach dem STOP/RUN geht es auch mit der VAT-Tabelle.

Edit: Irgendwo in der Initialisierung muss ein Fehler drin sein, anders kann ich es mir nicht erklären
 
Ich glaube dass der Ethernet Schnittstelle auf ein VIPA ist wie ein Siemens CP343-1, obwohl es ist in den CPU integriert.
In den Fall hat der 'CP' ein interne Diagnose-Puffer. Vielleicht steht da was.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ich glaube dass der Ethernet Schnittstelle auf ein VIPA ist wie ein Siemens CP343-1, obwohl es ist in den CPU integriert.
In den Fall hat der 'CP' ein interne Diagnose-Puffer. Vielleicht steht da was.

Ja das stimmt, nur dort sind die Felder leider leer, darin steht nichts. Morgen ist auch noch ein Arbeitstag, vielleicht habe ich ja eine Eingebung bis morgen
 
Das ist von der lokalen CPU ( Maschine A ).
Die Kommunikationsdiagnose nachdem STOP/RUN-Verfahren, zeigt genau die gleichen Werte an wie vorher
Das sollte nicht möglich sein. Wenn du eine Verbindung konfiguriert hast, und es passiert Datenverkehr über diese Verbindung, dann muss die Zähler den belegten Verbindung zeigen.

Ich denke dies ist ein Fall für VIPA Support.
Zum glück hast du VIPA als beide Partner. Siemens wurde dich nicht helfen mit ein VIPA, und VIPA wurde dich nicht helfen mit ein Siemens.
 
Bei einer S7-300 geht eine einseitig projektierte S7-Verbindung zur Ressource 03 immer zum Steckplatz der CPU (also TSAP 03.02), egal ob die Verbindung über einen CP oder eine CPU-Schnittstelle geht. Bei einer CPU die so tut als wäre sie eine S7-300 sollte das ebenfalls so sein.

Mir gehen jetzt auch die Ideen aus und würde den VIPA Support fragen.

Harald
 
Zuviel Werbung?
-> Hier kostenlos registrieren
So wie ich kürzlich mitbekommen habe, ist bei einigen Vipa CPUs eine der Ethernet-Schnittstellen sehr eingeschränkt ist und kann nur 1 Verbindungen verwalten. Wenn dort z.B. schon ein HMI angeschlossen ist, dann bekommt kein anderer einen Zugriff. Das ist eben Vipa: alles ist anders, alles ist spezial. Ich sehe zu, dass ich möglichst weit weg von deren Zeuchs bin.
 
Ist es denn überhaupt möglich, für PUT und GET verschiedene Verbindungs-IDs zu verwenden (siehe Grafiken vom TE)? Ich meine, immer die selbe ID für beide Richtungen verwendet zu haben, selbst bei mehreren PUT/GET-Paaren zu der selben Steuerung.


PS:
PUT/GET-Kommunikation kann man übrigens auch simulieren, zumindest mit Simatic-CPUs, selbst zwischen Classic und TIA.
 
Zuletzt bearbeitet:
Baut sich eine der S7-Verbindungen überhaupt auf?
Ich würde kontrollieren ob sich immer beide verbinden aufbauen.

Ich hab bei S7-Verbindungen auch immer zwei erstellt. Bei einem cp musst du aber den richtigen Steckplatz angeben.


Gesendet von iPhone mit Tapatalk
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ich hab bei S7-Verbindungen auch immer zwei erstellt. Bei einem cp musst du aber den richtigen Steckplatz angeben.
2 Verbindungen sind unnötiger Luxus. PUT+GET (und auch z.B. BSEND+BRCV) kann man mit der selben Verbindung ausführen.
Den richtigen Steckplatz muß man immer angeben ... ;) Falls Du meinst den Steckplatz des CP angeben: das gilt nur für beidseitig projektierte Verbindungen zu Ressourcen ab 10 (hex) zu S7-300. Bei einseitig projektierten Verbindungen zur Ressource 03 ist immer der Steckplatz der CPU anzugeben.

Das der TE hier PUT und GET auf 2 Verbindungen ausführt ist nicht nötig. Das geht auch auf nur einer Verbindung. Ich glaube daß die PUT- und GET-Aufträge auch nicht verriegelt werden müssen, sondern gleichzeitig ausgeführt werden könnten (bei 1x PUT+GET je Sekunde aber nicht nötig).

Harald
 
Das der TE hier PUT und GET auf 2 Verbindungen ausführt ist nicht nötig. Das geht auch auf nur einer Verbindung. Ich glaube daß die PUT- und GET-Aufträge auch nicht verriegelt werden müssen, sondern gleichzeitig ausgeführt werden könnten (bei 1x PUT+GET je Sekunde aber nicht nötig).

Harald

Nur zur Info:
Das habe ich bereits auch wieder geändert, es gibt jetzt nur noch 1 Verbindung. Problem bleibt bestehen, VIPA-Support ist kontaktiert jetzt heißt es abwarten.
 
Was mir gerade noch aufgefallen ist, bei beiden Maschinen, ist der Profinet-Subnet identisch.
Name und S7-Subnetz-ID ( beide : PN/IE_1 und 56DB-2 ) müssen diese evtl unterschiedlich sein?

Bei der Erstellung bin ich davon ausgegangen das diese gleich sein müssen, wie bei IP-Adressen, wo die Subnetzmaske ja auch identisch sein sollte.

Dazu fällt mir gerade noch auf das unter Besondere Verbindungseigenschaften nur ein Harken bei "Aktiver Verbindungsaubau" gesetzt ist, hätte nicht hier auch der Harken für "Einseitig" gesetzt werden müssen?

Aus dem Handbuch von VIPA steht dazu folgendes:
Hier können Sie angeben, wie Ihre Verbindung aufgebaut werden soll. Da der Siemens SIMATIC Manager die Kommunikationsmöglichkeiten anhand der Endpunkteidentifizieren kann, sind manche Optionen schon vorbelegt und können nicht geändert werden.– Aktiver Verbindungsaufbau:Für die Datenübertragung muss eine Verbindung aufgebaut sein. Durch Aktivierung der Option Aktiver Verbindungsaufbau übernimmt die lokale Station den Verbindungsaufbau. Bitte beachten Sie, dass nicht jede Station aktiv eine Verbindungaufbauen kann. In diesem Fall hat diese Aufgabe die Gegenstation zu übernehmen.– Einseitig:Im aktivierten Zustand sind nur einseitige Kommunikationsbausteine wie PUT undGET im Anwenderprogramm der CPU zur Nutzung dieser Verbindung möglich.Hier dient der Verbindungspartner als Server, der weder aktiv senden noch aktivempfangen kann.



Edit: Auch der Harken bei "Einseitig" hat das Problem leider nicht behoben
 
Zuletzt bearbeitet:
Zurück
Oben