TIA Datenaustausch über CP (put/get)

Alex17

Level-1
Beiträge
50
Reaktionspunkte
2
Zuviel Werbung?
-> Hier kostenlos registrieren
Moin zusammen,

ich habe nicht genau dieses Problem im Forum gefunden, deswegen hoffe ich, dass es noch nichts genaues dazugibt.

Folgendes Problem:

Unsere Steuerung:
- TIA V16
- S7 1511F 2PN
- CP 1543-1 V2.2

- Ich möchte via PUT und GET den Signalaustausch realisiere (Kundenwunsch).
- Der Kunde hat eine SPPA-T3000 für Leitsysteme (Kraftwerk).

Wie muss nun die CPU und die CP in TIA konfiguriert werden um diesen Austausch zu realisieren? Ich habe bisher nur Put/get aktiviert in der CPU und in der CP die vom Kunden vorgegebene IP Adresse eingestellt.

Online zeigt mir die CP an, dass ein Partner vorhanden ist, jedoch werden keine Signale bei ihm oder mir empfangen/gesendet.

MfG.

Alex
 
Zuletzt bearbeitet:
Was für ein Gerät ist denn Dein Partner? Sollst Du in diesem Gerät 'rum-put-en/get-en oder soll das Gerät in Deiner SPS Daten put-en/get-en?
Warum willst Du PUT/GET für den Signalaustausch verwenden?

Harald
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Es ist eine Art Steuerung auch von Siemens. (Siehe Screenshot).

Der Kunde möchte per PUT und GET auf unsere Steuerung zugreifen. Sprich er will Daten aus einem DB lesen und Daten in einen anderen DB schreiben. (Sprich Kundenvorgabe)
 

Anhänge

  • Screenshot_20210705-211639_Adobe Acrobat.jpg
    Screenshot_20210705-211639_Adobe Acrobat.jpg
    703,1 KB · Aufrufe: 67
Wurden die Bausteine, auf die zugegriffen werden sollen, als standard eingestellt (also Optimierter Baustein deaktiviert)?

Weitere Erkenntnisse bringt der Status des GET Bausteins im Programm.

MfG Michi
 

Anhänge

  • PLC_1500-Put_Get_deaktOptBausteine.PNG
    PLC_1500-Put_Get_deaktOptBausteine.PNG
    34,1 KB · Aufrufe: 36
Zuviel Werbung?
-> Hier kostenlos registrieren
Wenn dein Kunde das mit Put und Get übernimmt brauchst du nur PUT/GET freischalten in der SPS Konfig und die Bausteine dürfen nicht optimiert sein. Den Rest macht dann dein Kunde. Damit er nicht irgendwelche Daten zieht solltest du ihm noch mitteilen in welchem DB die Daten zu finden sind.

2 Hauptprobleme hat PUT/GET:

1. Man kann den Zugriff weder bestimmen noch kontrollieren. Sobald du den Haken setzt kann er auf alle DBs zugreifen was ein enormes Sicherheitsrisiko darstellt. Wenn zum Beispiel in Zukunft was falsch läuft, weil er in einem DB was geschrieben hat wo von du nichts weißt kann man es nicht nach vollziehen.

2. Watchdog: Die Kommunikation wird nicht auf Funktion überwacht. Daher bei ausfällen kann es ggf. nicht sauber erkannt werden.

Der einzige Vorteile von PUT/GET ist das es super einfach eingerichtet werden kann.


Wenn man Verantwortung übernehmen will oder sollte für sein Produkt ist PUT/GET einfach nicht zulässig.
Stand der Technik ist eine Open user communication.
Dort wird beim Konfigurieren festgelegt auf beiden Seiten welche daten genutzt werden dürfen. Desweiterem ist der gesamte Weg überwacht und wird zurückgemeldet.
 
Wenn dein Kunde das mit Put und Get übernimmt brauchst du nur PUT/GET freischalten in der SPS Konfig und die Bausteine dürfen nicht optimiert sein. Den Rest macht dann dein Kunde. Damit er nicht irgendwelche Daten zieht solltest du ihm noch mitteilen in welchem DB die Daten zu finden sind.

2 Hauptprobleme hat PUT/GET:

1. Man kann den Zugriff weder bestimmen noch kontrollieren. Sobald du den Haken setzt kann er auf alle DBs zugreifen was ein enormes Sicherheitsrisiko darstellt. Wenn zum Beispiel in Zukunft was falsch läuft, weil er in einem DB was geschrieben hat wo von du nichts weißt kann man es nicht nach vollziehen.

2. Watchdog: Die Kommunikation wird nicht auf Funktion überwacht. Daher bei ausfällen kann es ggf. nicht sauber erkannt werden.

Der einzige Vorteile von PUT/GET ist das es super einfach eingerichtet werden kann.


Wenn man Verantwortung übernehmen will oder sollte für sein Produkt ist PUT/GET einfach nicht zulässig.
Stand der Technik ist eine Open user communication.
Dort wird beim Konfigurieren festgelegt auf beiden Seiten welche daten genutzt werden dürfen. Desweiterem ist der gesamte Weg überwacht und wird zurückgemeldet.
3. Konsistenzproblemchen :)
 
So ein kleines Update. Der Kunde hatte wohl die Verbindung gesperrt und deswegen hatten wir keine Daten empfangen bzw. senden können.

Auf unserer Seite ist der Kunden Switch erreichbar und auch sichtbar auf welchem Port wir angesteckt sind. Auch die Info auf welche DB's er zugreifen darf hat er.

Wir haben ein Lifebit was mit 1 Hz von 0 auf 1 und wieder auf 0 taktet. Dieses Signal wird beim Kunden wieder zurückgeschickt zu uns. Es kommt auch bei uns in der Steuerung wieder an, also besteht eine Verbindung über die Daten gesendet werden ins Programm. Jedoch besteht angeblich ein Kommunikationsfehler auf der Kundenseite und er sagt er würde nichts empfangen, was ja eig. nicht sein kann, da wir sonst ebenfalls nicht erhalten würden.

Ich gehe davon aus, dass auf unserer Seite demnach alles richtig eingestellt ist? Und der Kunde nun bei sich suchen muss.

LG
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Jedoch besteht angeblich ein Kommunikationsfehler auf der Kundenseite und er sagt er würde nichts empfangen, was ja eig. nicht sein kann, da wir sonst ebenfalls nicht erhalten würden.

Ich gehe davon aus, dass auf unserer Seite demnach alles richtig eingestellt ist? Und der Kunde nun bei sich suchen muss.
Vielleicht hat sich der Kunde bei einer Adresse vertippt und sein Programm will auf Adressen zugreifen, die es in Deiner SPS nicht gibt oder in "optimierten" DB liegen (also für PUT/GET nicht freigegeben sind)? Oder er will absichtlich auf Adressen zugreifen, die mit Euch nicht vereinbart sind? Genau das ist das gefährliche bei PUT/GET, daß der Client unsichtbar sonstwo im SPS-Variablenspeicher rumstochern kann, wenn er nicht sehr sorgfältig arbeitet.

Harald
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Moin,

m.E. ist ein Toggle-Bit am besten so einzusetzen:

Ein Partner empfängt ein Bit, deren Information er 1:1 wieder zurücksendet. Der andere Partner sendet die invertierte Bitinformation wieder zurück.
Im folgenden bezeichne ich den Partner, der die Bitinformation 1:1 zurücksendet als Server, den anderen Partner als Client.

Der Server stellt Daten bereit, der Client überwacht die Verbindung.

Der Client kann:
- überwachen, ob die Verbindung aufgebaut ist (Information des Empfangsbits ändern sich)
- die Signallaufzeit messen, um festzustellen, wie schnell die Verbindung ist (Startzeitstempel bei senden, Endezeitstempel bei empfangen)

Der Server kann:
- überwachen, ob die Verbindung aufgebaut ist (Information des Empfangsbits ändert sich)

Dazu geht kein Zustandswechsel verloren, da ereignisgetrigger und nicht zeitgetriggert getoggelt wird.

---

Livebit takten würde ich auch nicht machen. Erstens muss der Takt abgesprochen und kleiner als der Requesttakt des Empfangsbausteins sein und zweitens können trotzdem Signalwechsel "verschluckt" werden. Dann muss die Überwachungszeit hochgestellt werden.
Also entweder erfasst man Verbindungsabbrüche, die gar nicht da sind oder die Auswertung dauert (zu?) lange.

Ein Int geht auch, habe ich bisher auch gemacht, aber es ist immer noch zeitgetriggert und man kann die Laufzeit nicht messen.

VG

MFreiberger
 
Ein Int geht auch, habe ich bisher auch gemacht, aber es ist immer noch zeitgetriggert und man kann die Laufzeit nicht messen.
Wenn der INT mit dem Sendetakt (REQ/DONE) incrementiert wird, dann kann man die Laufzeit messen. Mit so einem INT hat man einen prima Nachrichtenzähler und sieht beim blosen beobachten des Wertes schon, ob/wie flott die Kommunikation läuft.

Harald
 
Moin PN/DP,

Wenn der INT mit dem Sendetakt (REQ/DONE) incrementiert wird, dann kann man die Laufzeit messen. Mit so einem INT hat man einen prima Nachrichtenzähler und sieht beim blosen beobachten des Wertes schon, ob/wie flott die Kommunikation läuft.

Harald
ja, das stimmt. Im Prinzip wie bei dem ToggleBit, nur dass man noch einen Nachrichtenzähler hat. Danke für den Hinweis (y).

Da wir mit der MoviC von SEW ins Rennen gehen, sei mir aber noch der Hinweis gestattet, dass SEW das Durchreichen eines Togglebits (1:1 vom empfangenen zum gesendeten Bit) bei allen Antriebsprozessdaten in Steuer-/Statuswort implementiert hat.

Aber egal, wie man es macht. Das wichtigste ist, dass das Inkrementieren oder Toggeln nicht zeit- sondern ereignisgesteuert erfolgt.

VG

MFreiberger
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Moin PN/DP,


ja, das stimmt. Im Prinzip wie bei dem ToggleBit, nur dass man noch einen Nachrichtenzähler hat. Danke für den Hinweis (y).
Jein,
bei einem ToggleBit kann u.U. bei entsprechend langsamer Kommunikation das ToggleBit Dauertrue oder Dauerfalse bleiben.
 
Moin,

ich wollte gerade bei SIEMENS recherchieren, ob es irgend welche Hardwarevoraussetzungen (CPU-Schnittstellen (1515), CPs, CMs) gibt, um die PUT/GET-Kommunikation einsetzen zu können.
Leider sind die SIEMENS-Seiten gerade unheimlich langsam (besodners die Mall).

Kann mir Jemand von Euch sagen, ob es entsprechende Voraussetzungen gibt. Oder noch konkreter gefragt: kann ich eine PUT/GET-Kommunikation auch über ein CM1542-1 laufen lassen?

VG

MFreiberger
 
Zuviel Werbung?
-> Hier kostenlos registrieren
PUT/GET sollte gehen (falls etwas besseres nicht möglich ist). Das "Kompendium CPU-CPU Kommunikation mit SIMATIC Controllern" (siehe Seite 302) wird anscheinend von Siemens nicht mehr gepflegt, aber in der Betriebsanleitung des CM 1542-1 steht:

Das CM unterstützt folgende Kommunikationsdienste:
  • S7-Kommunikation
    – ...
    – Datenaustausch über S7-Verbindungen

Probiere doch einfach in TIA, ob Du eine S7-Verbindung projektieren kannst.

Harald
 
Moin Harald,

ja, das werde ich ausprobieren. Leider ist nichts besseres möglich, da es ein RetroFit ist und der Partner nichts machen kann/soll.

VG

Mario
 
Zurück
Oben