Kommunikation SPS mittels PUT/GET

[Senia]

Zuviel Werbung?
-> Hier kostenlos registrieren

Moin Moin aus dem Norden,

Ich habe folgendes Problem und ich hoffe Ihr könnt mir hierbei helfen.
Zuerst einmal die Ausgangssituation:

Es soll eine Kommunikation zwischen 2 Maschinen hergestellt werden die im Kontinuebetrieb laufen sollen. Dabei soll Maschine A der Master sein.

Die Hardwarekonfigurationen sollen nicht verändert werden, d.h. die beiden CPUs kennen sich nicht, deswegen habe nun mich für eine einfachere Variante mittels PUT/GET entschieden.

Nachdem laden der jeweiligen Bausteine die zur Kommunikation dienen passiert nun folgendes:

Die Verbindung baut sich auf und die Kommunikation funktioniert, da dachte ich schon super klappt ja alles prima. Nachdem ich alles RAM nach ROM kopiert habe, dachte ich mein Job wäre damit erledigt. Am nächsten Tag passiert nun allerdings folgendes. Beim Einschalten des Hauptschalters ( beide Maschinen laufen über einen Hauptschalter ), bekomme ich die Fehlermeldung 0001, keine Verbindung. Erst dachte ich ich hätte etwas falsch programmiert, aber nach durchforsten dieses Forums und Siemens, habe ich festgestellt das es an sich korrekt war, was ich dort gemacht habe.

Jetzt das Merkwürdige, was ich ganz und gar nicht verstehe... Wenn ich den Hauptschalter einschalte und die Maschine hochgefahren ist und ich die Master CPU ( Maschine A ) auf "STOP" setze und anschließend wieder auf "RUN" schalte funktioniert die Kommunikation wieder sofort.
Ich muss also jetzt jedes mal wenn ich Netz AUS-> Netz EIN habe, die CPU nach dem Hochfahren einmal auf STOP und dann auf RUN setzen. Weiß irgendjemand Rat?

Nun zu dem eingesetzten System:
- Es wurde alles im TIA-Portal V15 programmiert
- In beiden System wird die gleich CPU verwendet:
VIPA 315-4PN33
- Die Kommunikation findet nur einseitig statt, d.h. Maschine A, ist derjenige der PUT/GET abläuft, die Maschine B hat nur einen DB.

Im Anhang findet ihr die Parameter der CPU ( bei beiden die identischen )
ebenso der Programmteil der für die Kommunikation verantwortlich ist

Erläuterung zum Programm:
Der Aufruf des FBs befindet sich im OB1, der mit einer einmaligen Verzögerung von 4 Minuten aufgerufen wird
#EN1 wird im OB100 gesetzt.

Ich danke euch schon mal für eure Rateschläge

 

[PN/DP]

"SS_KONTI".PN_REQ_PUT und "SS_KONTI".PN_REQ_GET im ersten OB1-Zyklus (oder im OB100) und/oder bei zu langem Ausbleiben (Timeout) von DONE und ERROR zurücksetzen.

#EN1 wird im OB100 gesetzt.

Wird der auch irgendwann zurückgesetzt?
Dein "EN_1" schaut wie eine Verzweiflungstat aus. Im Setz-Zweig nützt er allerdings nichts. Er gehört in den Rücksetz-Zweig: O "EN_1"

Harald

 

[JesperMP]

Zuviel Werbung?
-> Hier kostenlos registrieren

In den unwahrscheinliche Fall dass Haralds Hinweis nicht helft, was meldet die STATUS Ausgänge von PUT und GET ?

 

[Senia]

"SS_KONTI".PN_REQ_PUT und "SS_KONTI".PN_REQ_GET im ersten OB1-Zyklus (oder im OB100) und/oder bei zu langem Ausbleiben (Timeout) von DONE und ERROR zurücksetzen.

Ok, das werde ich gleich mal ausprobieren

Wird der auch irgendwann zurückgesetzt?
Dein "EN_1" schaut wie eine Verzweiflungstat aus. Im Setz-Zweig nützt er allerdings nichts. Er gehört in den Rücksetz-Zweig: O "EN_1"

Harald

Moin, ja der wird zurücksetzt, sobald der FB einmalig durchlaufen wird

 

[PN/DP]

Deine Verknüpfung des 1Hz-Taktmerkers "TAKT_1HZ" führt (wahrscheinlich) dazu, daß eine halbe Sekunde lang PUT+GET-Aufträge mehrmals ausgeführt werden und eine halbe Sekunde lang gar nicht. Ist das so gewollt?

Wenn Du nur jede Sekunde je einmal PUT und GET ausführen willst, dann kannst Du die ganzen Verknüpfungen und S/R für die REQ komplett weglassen und direkt "TAKT_1HZ" an den GET.REQ anschalten und "SS_KONTI".PN_DONE_GET (oder "GET_DB".NDR) an PUT.REQ anschalten

Harald

 

[Senia]

Zuviel Werbung?
-> Hier kostenlos registrieren

Deine Verknüpfung des 1Hz-Taktmerkers "TAKT_1HZ" führt (wahrscheinlich) dazu, daß eine halbe Sekunde lang PUT+GET-Aufträge mehrmals ausgeführt werden und eine halbe Sekunde lang gar nicht. Ist das so gewollt?

Wenn Du nur jede Sekunde je einmal PUT und GET ausführen willst, dann kannst Du die ganzen Verknüpfungen und S/R für die REQ komplett weglassen und direkt "TAKT_1HZ" an den GET.REQ anschalten und "SS_KONTI".PN_DONE_GET (oder "GET_DB".NDR) an PUT.REQ anschalten

Harald

Die Kommunikation genügt wenn sie jede Sekunde abgefragt werden. Hier werden keine Sicherheitsrelvanten Bytes übertragen, die Kommunikation dient nur zum Informationsaustausch.

Ich hatte das bei PUT/GET aber so verstanden, das der REQ nach dem Aufruf durch DONE oder ERROR zurückgesetzt werden muss?

Zurzeit haben wir leider Verbindungsprobleme zum Kunden, werde dann erst heute Mittag alles testen können.
Aber vielen Dank schon mal für die schnelle Antwort

 

[PN/DP]

Ich hatte das bei PUT/GET aber so verstanden, das der REQ nach dem Aufruf durch DONE oder ERROR zurückgesetzt werden muss?

Ein PUT/GET-Auftrag wird bei der steigenden Flanke von REQ ausgelöst. Wie lange REQ dann anliegt ist völlig egal, das kann 1 Zyklus lang sein oder auch länger als bis zur Fertigmeldung. Der nächste Auftrag wird erst dann ausgelöst, wenn REQ mal auf 0 und dann wieder auf 1 geht (das sollte aber nicht passieren, solange der aktuelle Auftrag noch bearbeitet wird).

Dein Problem mit Power Off hat die Ursache, das quasi immer einer der beiden REQ-Bits aktiv ist und remanent, und nach dem Aus- und wieder Einschalten deshalb keine steigende Flanke erkannt wird und sich das Programm "totwartet" weil kein DONE und kein ERROR kommt. Deshalb ist es notwendig, nach Power On die REQ-Bits zurückzusetzen. Die in meinem Beitrag #5 beschriebene ganz einfache Lösung mit der direkten Verschaltung des Taktmerkers "heilt" sich selber nach spätestens einer Sekunde.

Harald

 

[Senia]

Ich habe das Programm jetzt dementsprechend angepasst wie du gesagt hast.

Ich habe jetzt den Programmteil nochmals hier rangehängt.
Wenn ich die Bausteine beobachte, sehe ich auch am GET Baustein das der REQ alle 1s wechselt von TRUE auf FALSE und wieder von FALSE auf TRUE, jedoch bleibt der Baustein auf ERROR bestehen?!
Der REQ von PUT, startet natürlich nicht, da er kein DONE-Signal von GET bekommt.

Zur Info:
Das Status Wort zeigt immernoch 16#0001 an ( PUT&GET )

 

[Senia]

Zuviel Werbung?
-> Hier kostenlos registrieren

Dein Problem mit Power Off hat die Ursache, das quasi immer einer der beiden REQ-Bits aktiv ist und remanent, und nach dem Aus- und wieder Einschalten deshalb keine steigende Flanke erkannt wird und sich das Programm "totwartet" weil kein DONE und kein ERROR kommt. Deshalb ist es notwendig, nach Power On die REQ-Bits zurückzusetzen. Die in meinem Beitrag #5 beschriebene ganz einfache Lösung mit der direkten Verschaltung des Taktmerkers "heilt" sich selber nach spätestens einer Sekunde.

Harald

alle REQ-Bits werden im OB100 einmalig zurückgesetzt, daran hatte ich nämlich auch schon gedacht.

Ergänzende Anmerkung:
und wenn ich selbst mit der Variablen beobachten/steuern selbst den REQ auf TRUE/FALSE setze, bleibt der Statuswort auf 0001 und keine Verbindung kommt zustande
Die Datenbausteine (PUT/GET) von Siemens, dort befindet sich auch kein Harken bei Remanenz

 

[JesperMP]

ERROR ist TRUE, und STATUS ist #0001.
Aus die Hilfe zu PUT und GET:

Communications problems, for example:-
Connection description not loaded (local or remote)-
Connection interrupted (for example: cable, CPU off, CP in STOP mode)-
Connection to partner not yet established-
FB cannot be run on an S7-400-CPU-
Also for S7-300:· Maximum number to parallel jobs/instances exceeded

Ich schlage vor, den ganze Code weck.
Dann ein VAT erstellen mit die relevante Variabeln, und dann manuell experimentieren mit die REQ bits. Vielleicht erkennt man davon wie es funktionieren muss.
Dass es um eine VIPA handelt kann es auch etwas komplizieren. Hat die STATUS genau denselbe Funktion wie auf ein Siemens CPU ?

 

[Senia]

Ich schlage vor, den ganze Code weck.
Dann ein VAT erstellen mit die relevante Variabeln, und dann manuell experimentieren mit die REQ bits. Vielleicht erkennt man davon wie es funktionieren muss.
Dass es um eine VIPA handelt kann es auch etwas komplizieren. Hat die STATUS genau denselbe Funktion wie auf ein Siemens CPU ?

Aber wie kann es dann sein, dass der Code funktioniert, sobald man die CPU in STOP versetzt und anschließend in RUN. Da kann doch nicht der Code dann falsch sein?
Wie das bei VIPA genau ist, müsste ich erstmal im Handbuch nach schauen, aber wie gesagt, eigentlich läuft der Code ja. Nur beim erstmaligen Hochfahren der CPU, kommt diese Verbindung nicht zustande.

Ergänzende Bemerkung:
Sind in den Verbindungsparameter evtl. noch Fehler?

 

[JesperMP]

Zuviel Werbung?
-> Hier kostenlos registrieren

Aber wie kann es dann sein, dass der Code funktioniert, sobald man die CPU in STOP versetzt und anschließend in RUN. Da kann doch nicht der Code dann falsch sein?

Kann ich nicht erklären. Ich habe den Gefühl dass bei eine normalen Start wird die CP von Aufträge überflutet. Du hast eine Verzögerung von 4 Minuten bei CPU start. Ich wurde denken es wäre mehr als genug, aber vielleicht nicht. Funktioniert diese Verzögerung ?

 

[JesperMP]

Du kannst auch checken ob die Ursache ist das keine Verbindungen frei sind. Glaube es eigentlich nicht, weil erstens es sollte es dann kein Unterschied machen dass der CPU manuell neu gestartet wird. Und zweitens sollte es eine andere STATUS Meldung erzeugen. Aber vielleicht funktioniert ein VIPA anders.

 

[Senia]

Kann ich nicht erklären. Ich habe den Gefühl dass bei eine normalen Start wird die CP von Aufträge überflutet. Du hast eine Verzögerung von 4 Minuten bei CPU start. Ich wurde denken es wäre mehr als genug, aber vielleicht nicht. Funktioniert diese Verzögerung ?

Der Aufruf der Bausteine PUT/GET wird erfolgreich übersprungen, innerhalb der 4 Minuten ist das Statuswort bei 16#0000

 

[Senia]

Zuviel Werbung?
-> Hier kostenlos registrieren

Du kannst auch checken ob die Ursache ist das keine Verbindungen frei sind. Glaube es eigentlich nicht, weil erstens es sollte es dann kein Unterschied machen dass der CPU manuell neu gestartet wird. Und zweitens sollte es eine andere STATUS Meldung erzeugen. Aber vielleicht funktioniert ein VIPA anders.

Wie kann ich nachschauen ob Verbindungen frei sind oder nicht?

 

[JesperMP]

In STEP7 Classic: CPU Eigenschaften online öffnen. Dann taucht ein Dialogfeld auf mit ein Reiter "Kommunikation", unterdies findet man die reservierte und die belegte Verbindungen.
in TIA: Auf die CPU online gehen. In das Projektbaum auf die CPU rechtscliken und Online & Diagnostics wählen. Es taucht ein Dialog auf, unter "Diagnose" gibs es einen Ordner "Kommunikation", unterdies findet man die reservierte und die belegte Verbindungen.

edit: PUT/GEt verwendet S7-Verbindungen.
Es wird nicht angezeigt wie viele Freie S7-Verbindungen es gibt, ausser den totalen Anzahl von alle Typen. Du musst die belegte S7-verbinden finden, und mit die von VIPA erwähnte Anzahl dass unterstützt wird für genau diesen CPU.

 

[PN/DP]

Der Aufruf der Bausteine PUT/GET wird erfolgreich übersprungen, innerhalb der 4 Minuten ist das Statuswort bei 16#0000

Na wenn ein Baustein gar nicht aufgerufen wird, dann ändert sich der Status auch nicht, weil dann gar kein Wert in die Statusvariable geschrieben wird.

Was für ein Baustein ist PUT bzw. GET? Wo kommen die her? Könnte es sein, daß bei VIPA-CPU spezielle Bausteine oder SFC von VIPA verwendet werden müssen?

Harald

 

[PN/DP]

Zuviel Werbung?
-> Hier kostenlos registrieren

Sind in den Verbindungsparameter evtl. noch Fehler?

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

 

[JesperMP]

Was für ein Baustein ist PUT bzw. GET? Wo kommen die her? Könnte es sein, daß bei VIPA-CPU spezielle Bausteine oder SFC von VIPA verwendet werden müssen?

+1. Gute Frage.
Selbst für eine Siemens S7 gibt es 2 Varianten.
Für eine S7-300 und integrierte Schnittstelle oder S7-400 und ein CP. PUT/GET aus das Standardbibliotek.
Für S7-300 und ein CP. PUT/GET aus das SIMATIC_NET_CP Bibliotek, und CP300 Unterordner.

edit: Habe was falsch geschrieben über 3 Varianten.

 

[PN/DP]

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)

Für Siemens S7-Verbindungen sind für den Datenaustausch die FB/SFB-VIPA-Hantierungsbausteine zu verwenden, deren Gebrauch im Handbuch "Operationsliste" Ihrer CPU näher beschrieben ist.

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

Harald