TIA Empfehlung für Kommunikation S7-1500 zu bis zu 32 unterlagerten S7-1200 á 1000Byte

ErwinZobel

Level-1
Beiträge
2
Reaktionspunkte
0
Zuviel Werbung?
-> Hier kostenlos registrieren
Wir errichten Anlagen, die aus einer oder mehrerer ähnlicher Teilmaschinen (Gasmotoren/Stromerzeugung) bestehen. Für die Vorplanung gehe ich von max. 32 Maschinen aus.
In den Maschinen kommen externe Steuerungen des Motorherstellers zum Einsatz, die wir nicht "umprogrammieren" können. Deren Schnittstelle ist ModbusRTU/TCP-Slave.

Wir setzen je Maschine eine S7-1200 CPU ein, um die Daten per Modbus auszulesen und ggf. zusätzliche lokale Steuerungsaufgaben zu realisieren, die in der original Maschinensteuerung "fehlen". Die per Modbus gelesenen Prozessdaten liegen in der S7-1200 in einem optimierten DB per UDT. Der Datenumfang beträgt ca. 600 bis 1000Byte. Als zentrale Steuerung soll je Anlage eine S7-1500 fungieren. Die Daten der einzelnen Maschinen sollen in der zentralen S7-1500 aggregiert werden. Eine Aktuallisierungsrate von 1s (ggf. auch langsamer) ist ausreichend. Der Datenumfang der einzelnen Maschinen variiert leider zum Teil, da unterschiedliche Steuerungen eingesetzt werden, bzw. Maschinentypenreihen. Prozesskritische Daten, welche einen geringen Umfang haben, werden wir per Profinet IO übertragen.

In den bisherigen Anlagen hatten wir S7-300 CPU eingesetzt und die Daten per PUT/GET geholt. Mit der Umstellung auf die S7-1200 möchte ich dies gern vermeiden.

Welche Kommunikationslösung wäre hierfür vorteilhaft? ggf. können wir die Daten in den S7-1200 CPU auch in einem nicht optimierten DB ablegen. Es gibt ja viele verschiedene Varianten, leider fehlt mir derzeit die Zeit die einzelnen Varianten zu untersuchen/auszuprobieren. Vielleicht könnt Ihr mir helfen? Danke!
 
Ich kann leider nicht helfen, aber ich weiss das s-1200 OB 's nur in optimerten Attribute arbeien.Ich würde T-send T_receive anwenden statt Put/get. S-1200 tendiert ständig zum Baustein-schreibschutz(read_only)..
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
Oder du stopfst die gewünschten Austauschdaten der 1200er in i-Device und hast auf der 1500er dann "quasi bis zu 32 IM-Baugruppen" als dezentrale Peripherie...

Solange du bei der 1500er dann unter den 32k für input und 32k für output bleibst, sollte das kein Problem sein...

MfG Fabsi
 
Oder du stopfst die gewünschten Austauschdaten der 1200er in i-Device und hast auf der 1500er dann "quasi bis zu 32 IM-Baugruppen" als dezentrale Peripherie...

Solange du bei der 1500er dann unter den 32k für input und 32k für output bleibst, sollte das kein Problem sein...

MfG Fabsi

Genau so einen Aufbau haben wir 2017/2018 bei einer großen Roboteranlage (allerdings mit 300er CPUs) mit 14 I-Device (315/317er) und einer Master CPU (317er) eingesetzt. Das hat sehr gut funktionert. Ich vermute aber, dass dafür der DB in den 1200ern auf nicht optimiert geändert werden müsste. Da ich das mit den neuen CPUs noch nicht gemacht habe kann ich dies allerdings nur vermuten.

Gruß Christian

EDIT: Wir hatten ca. 6.000 Byte E/As. Bei 32.000 Byte E/As sollte man sich auf jeden Fall die Performance der SPS ansehen.
 
Zuletzt bearbeitet:
quote_icon.png
Zitat von Fabpicard
Oder du stopfst die gewünschten Austauschdaten der 1200er in i-Device und hast auf der 1500er dann "quasi bis zu 32 IM-Baugruppen" als dezentrale Peripherie...

Solange du bei der 1500er dann unter den 32k für input und 32k für output bleibst, sollte das kein Problem sein...

MfG Fabsi"

Die einfachste Variante , aber nach meiner Meinung die langsamste. Ich habe vor 2 Monate ein S7-1500er als

I-Conroller und andere S-1500 er als Io-devie programmiert und muss feststellen das die signale fast 4 Sekunden

dauerten , deshalb ist es ratsam parallel ein Verbindung herzustellen. mit TCon oder mit Send/Receive.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Die einfachste Variante , aber nach meiner Meinung die langsamste. Ich habe vor 2 Monate ein S7-1500er als

I-Conroller und andere S-1500 er als Io-devie programmiert und muss feststellen das die signale fast 4 Sekunden

dauerten , deshalb ist es ratsam parallel ein Verbindung herzustellen. mit TCon oder mit Send/Receive.

Ich weiß nicht, ob du IO-Device meinst (wie du schreibst) oder dich verschrieben hast, aber beim I-Device haben wir Kommunikationszeiten von ~100ms für eine Struktur von 50 Byte gehabt. Ich gehe davon aus, dass dies bei 1500er CPUs noch etwas schneller ist, wir hatten auch CPU Zykluszeiten von 10-20ms, was da ja auch noch reinspielt. Wir haben mittels I-Device Teiledaten von Paletten auf fünf Produktionslinien in jeder der über 50 Bearbeitungsstationen von der Master CPU angefragt und hinterher wieder weggeschrieben. Das war zeitkritisch und hat trotzdem problemlos geklappt. Ich wundere mich über so hohe Zeiten, das kenne ich eigentlich nur von der T-CPU.
 
Ich habe vor 2 Monate ein S7-1500er als

I-Conroller und andere S-1500 er als Io-devie programmiert und muss feststellen das die signale fast 4 Sekunden

dauerten , deshalb ist es ratsam parallel ein Verbindung herzustellen. mit TCon oder mit Send/Receive.
:confused: Das ist nicht normal und nicht akzeptierbar, da ist vermutlich irgendwas nicht in Ordnung, vielleicht was falsch eingestellt oder ungeeignete Netzkomponenten (z.B. Switche) verwendet? Wieviele i-Devices waren das, wieviele IO-Devices insgesamt? Wie groß waren die Transferbereiche?
Ich meine, Profinet-IO/i-Device-Kommunikation kann/darf nicht langsamer sein als "offene" Kommunikation (z.B. TCP-Verbindung).

Harald
 
Ja Sorry habe mich verschrieben , bei mir lage es nicht an Zykluszeiten sondern an die TCP/IP-Verbindung obwohl ich nur in Intranet-Bereich gearbeitet habe.
 
Was wäre mit OPC-UA. In der FW 2.6 kann ja die CPU auch Client sein. Dann könntest du ggf. sogar recht einfach während der Laufzeit eine neue Verbindung aufbauen.
 
Vielen Dank für die Antworten!

An die Möglichkeit, dass alles per Profinet IO zu übertragen habe ich auch schon gedacht. Allerdings würde ich ungern den Realtime-Kanal mit den zeitlich unkritischen Signalen zuballern, auch wenn es gerade da 32x1000Byte ziemlich na an der Systemgrenze ist.

ich hatte eher an S7 Kommunikation oder OUC (Open User Communication), da gibt es aber relative viele verschiedene Varianten und bin mir unsicher, was da am besten passt.

Bei OPC.UA wäre ja je S7-1200 je eine Server Lizenz fällig. Nicht so toll.
 
Zurück
Oben