Über 70zig SPSen über Ethernet an einer S7-300 ?

[Kieler]

Zuviel Werbung?
-> Hier kostenlos registrieren

Meßlatte liegt bei 72 !

Interessant. Werde das mal bei diversen CPUs prüfen, wie die sich verhalten.

Ja interessant ist das schon. Aber hier weiß ich ja eigentlich, das es geht. Man beachte auch, dass ich ja auch mehr 16 Verbindungen mit nur einem CP nutze. Was sicherlich an den Unterschiedlichen Verbindungsarten liegt.

Aber eigentlich wollte ich ja nicht die Funktion schon bestehender Anlagen in Frage stellen, sondern die Teilnehmerzahl noch deutlich erhöhen. Gibt es unter uns wirklich niemanden, der schon mit entsprechenden Teilnehmerzahlen gearbeitet hat ??

 

[Onkel Dagobert]

Hallo Kieler,

"o_prang" hat mir neulich eine "DSP" (Daten Station Plus) von Wachendorf bzw. von "Red Lion Controls" für eine Modbus-S7 Kommunikation empfohlen. Das Ding scheint so eine Art eierlegende Wollmichsau in Sachen Kommunikation zu sein, und es kann noch einiges mehr. Die dazugehörige Software Crimson 2.0 kann kostenlos herunter geladen werden.

Unbedingt mal ansehen!

http://www.wachendorff.de/wp/pgr_gpw_dsp_dsp.html


Gruß, Onkel

 

[maxi]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich habe eine frage.
Warum eine 300er als Koppler?

Da gibt es doch tolle fertige PC Lösungen von Siemens.

Wir hatten da mal 192 CPU`s und konnte mit den PG auf jede zugreiffen.

 

[Thomas_v2.1]

Also wenn ich mir das Netpro so ansehe sind das ja alles mehr oder weniger lokale Stationen.
Ist denn der einzige Grund warum die Kopfstation eine SPS sein muss, dass du das Mosaikschaltbild ansteuern willst?
Das könntest du doch auch so machen, dass der PC die entsprechenden Daten zusammensammelt und dann in die Mosaik-SPS überträgt.

Vorteil der SPS Lösung wäre natürlich dass das Mosaik auch weiterläuft wenn der Rechner mal wegen Problemen unten sein sollte.

 

[Markus]

wieviel daten müssen denn durch?
machbar wäre das vielleicht über das prozessabbild z.b. mit PN/PN-Couplern.

aber so richtig elegant ist das auch nicht...

 

[Maxl]

Zuviel Werbung?
-> Hier kostenlos registrieren

wieviel daten müssen denn durch?
machbar wäre das vielleicht über das prozessabbild z.b. mit PN/PN-Couplern.

aber so richtig elegant ist das auch nicht...

Mir schwebt da auch eine ähnliche Lösung vor.

Ich dachte dabei eher daran, bei allen "Slave"-Stationen einen CP343-1 Lean einzubauen, und diesen als PN-Device (Slave) zu betreiben. Hiermit können pro Richtung 256 Bytes übertragen werden. Vorausgesetzt, dass die Switches QoS unterstützen, ist das ganze auch sehr schnell. Ist das zu wenig, dann man die Daten entweder multiplexen oder einen zusätzlichen CP343-1 Lean in die Slave-Station einbauen.

Als Master kann dann eine S7-300 oder 400 dienen (je nach Datenmenge kann es notwendig sein, zusätzliche Ethernet-CPs als PN-Controller zu verwenden).

Der Nachteil an der ganzen Lösung - es muss in jede CPU eingegriffen werden (was Du aber wohl ohnehin machen must).


mfg Maxl

 

[Kieler]

Erstmal vielen Dank für Eure Ideen. Das gibt meinen Gedanken schon die entsprechende Richtung.

Also jetzt sieht es so aus. Das wir eine S7-300 als Sinaut Zentrale mit zwei analogen Wählmodems haben. Darüber/daneben sitzt ein WinCC Server (mit ein paar Clients) mit ST7CC. Der Großteil der Stationen sendet 6 Doppelwörter, eine sendet 24 Doppelwörter.

In Zukunft erhalten alle Unterstation einen Lean CP anstelle der TIM33. Die Programme der Unterstation mache ich, zumindestens den Kommunikationsteil neu. Die zentrale 300terter CPU steuert zwei Mosaikbilder an und macht auch sonst noch ein bischen Alarm (Hupe, Rundumleuchte, ...)

Nach dem jetzigen Stand der Diskussion sehe ich zwei Lösungsansätze:

1. PN/PN
Habe ich noch nie gemacht, aber das sollte ja kein Grund sein.
- Kann dann WinCC trotzdem noch direkt auf die Unterstationen zugreifen?
- Stellt das irgendwelche Anforderungen an die untergelagerten CPU'en
oder reichen neue Lean-CP's ?

2. über WinCC
Ich lasse meine Kopfstation nicht mehr direkt mit den Unterstation kommunizieren, sondern schiebe es über WinCC wieder zurück. In diesem Fall sehe ich mich aber gezwungen, mein WinCC redundant aufzubauen. Was vielleicht sowieso sinnvoll wäre.

 

[Kieler]

Ich habe eine frage.
Warum eine 300er als Koppler?

Da gibt es doch tolle fertige PC Lösungen von Siemens.

Wir hatten da mal 192 CPU`s und konnte mit den PG auf jede zugreiffen.

Was genau hast Du bei fertigen PC Lösungen im Kopf ??

 

[Maxl]

Zuviel Werbung?
-> Hier kostenlos registrieren

Also jetzt sieht es so aus. Das wir eine S7-300 als Sinaut Zentrale mit zwei analogen Wählmodems haben. Darüber/daneben sitzt ein WinCC Server (mit ein paar Clients) mit ST7CC. Der Großteil der Stationen sendet 6 Doppelwörter, eine sendet 24 Doppelwörter.

In Zukunft erhalten alle Unterstation einen Lean CP anstelle der TIM33. Die Programme der Unterstation mache ich, zumindestens den Kommunikationsteil neu. Die zentrale 300terter CPU steuert zwei Mosaikbilder an und macht auch sonst noch ein bischen Alarm (Hupe, Rundumleuchte, ...)

Nach dem jetzigen Stand der Diskussion sehe ich zwei Lösungsansätze:

1. PN/PN
Habe ich noch nie gemacht, aber das sollte ja kein Grund sein.
- Kann dann WinCC trotzdem noch direkt auf die Unterstationen zugreifen?
- Stellt das irgendwelche Anforderungen an die untergelagerten CPU'en
oder reichen neue Lean-CP's ?

PN/PN-Koppler setzen auf beiden Seiten einen Profinet-IO Controller (CP oder PN-CPU) voraus - ein Lean-CP kann nicht Controller sein, sondern nur Device (du bräuchtest also in jeder Unterstation einen CP343-1 (ohne Lean) oder eine PN-CPU - zusätzlich wären noch 70 PN/PN-Koppler notwendig)

Es st aber durchaus denkbar, dass man in alle Unterstationen Lean-CPs einbaut, und diese als Device an einem Controller betreibt (z.B. 317-2PN/DP oder 319-3PN/DP).
Die Datenmenge müsste noch kontrolliert werden (ca. 2400 Byte) - aber ich denke das sollte bei PN-IO kein Problem sein.

Ach ja - Zugriff auf die Unterstationen hast Du in jedem Fall auch mit WinCC.

 

[Kieler]

Es st aber durchaus denkbar, dass man in alle Unterstationen Lean-CPs einbaut, und diese als Device an einem Controller betreibt (z.B. 317-2PN/DP oder 319-3PN/DP).
Die Datenmenge müsste noch kontrolliert werden (ca. 2400 Byte) - aber ich denke das sollte bei PN-IO kein Problem sein.

Ach ja - Zugriff auf die Unterstationen hast Du in jedem Fall auch mit WinCC.

Das heißt meine Kopfstation wäre eine 317-2PN/DB und meine 72 UST sind Slave an dem PN Netz. Richtig ? Was ist eigentlich, wenn mein Ethernet nur ein 1MB/s macht? ist das ein Problem.

 

[Maxl]

Das heißt meine Kopfstation wäre eine 317-2PN/DB und meine 72 UST sind Slave an dem PN Netz. Richtig ?

richtig!

Was ist eigentlich, wenn mein Ethernet nur ein 1MB/s macht? ist das ein Problem.

grundsätzlich schreibt PN-IO 100 MBit/s vor. Um welche Art von Ethernet handelt es sich? Sind da Router dazwischen? und sind die Unterstationen auf mehrere Standorte verteilt?

Ach ja: welche Aktualisierzungszeiten werden überhaupt benötigt? Die Modem-Lösung wird ja Aktualisierungszeiten im Minuten-Bereich gehabt haben, oder?

 

[Kieler]

Zuviel Werbung?
-> Hier kostenlos registrieren

richtig!
grundsätzlich schreibt PN-IO 100 MBit/s vor. Um welche Art von Ethernet handelt es sich? Sind da Router dazwischen? und sind die Unterstationen auf mehrere Standorte verteilt?

Ach ja: welche Aktualisierzungszeiten werden überhaupt benötigt? Die Modem-Lösung wird ja Aktualisierungszeiten im Minuten-Bereich gehabt haben, oder?

Durch die TIM's haben wir jetzt ein Raster von ca. 5 Minuten. Die Zeit spielt also nicht die entscheidende Rolle. Die Unterstationen sind auf 72 Standorte verteilt und es sind auch Router im Netz. Bei dem Ethernet handelt es sich um ein langsames DSL Netz.

 

[Maxl]

Durch die TIM's haben wir jetzt ein Raster von ca. 5 Minuten. Die Zeit spielt also nicht die entscheidende Rolle. Die Unterstationen sind auf 72 Standorte verteilt und es sind auch Router im Netz. Bei dem Ethernet handelt es sich um ein langsames DSL Netz.

Ok, wenn das so ist, scheidet eine Profinet-Lösung völlig aus.

In dem Fall ist eine Lösung angebracht, welche im Prinzip ähnlich funktioniert wie die TIM-Lösung. Ich könnte mir z.B. vorstellen, dass die Haupt-CPU eine einfache PN-CPU oder irgend was anderes mit einem Ethernet-CP ist.
In allen Unterstationen wird trotzdem ein Lean-CP verbaut.


In der Master-CPU projektierst Du nun aber keine Verbindungen, sondern baust die Verbindungen dynamisch mit Hilfe der "Offenen Kommunikation über Industrial Ethernet" dynamisch auf und ab. Im einfachsten Fall "klapperst" Du alle Stationen nacheinander ab. Eine 317er-CPU sollte aber durchaus in der Lage sein, mehrere Verbindungen parallel aufzubauen - was eine Lösung mit 4 oder 8 "Kreisen" ermöglichen sollte.

Als Verbindungstyp wählst Du am besten Iso-on-TCP - da musst Du Dich nicht um die Datenintegrität kümmern (was spezielle bei Verbindungen übers Internet wichtig ist). Die Unterstationen sind dabei die passiven Verbindungsteilnehmer, die Hauptstation der aktive.


mfg Maxl

 

[Jenser]

Hallo @all,

ich habe da ein ähnliches Konstrukt. Es handelt sich um 14 * 317-2 PN/DP FW 2.5. Diese sind über Ethernet miteinander verbunden.
Jede der SPS'n hat eine dauerhafte, offene TCP Verbindung (FB63/64/65/66) zu einem Leitrechner.
2 davon haben zusätzlich noch eine Verbindung zu einem Visionsystem sowie einem Drucker.

Um nun an einer selbstgewählten "Master"-CPU den Zustand aller anderen Module anzeigen zulassen, baue ich von einer CPU (Master) im Reih-um-Verfahren zu jeder anderen SPS (13) eine Verbindung auf (Master = aktiver Verbindungsaufbau, alle anderen sind passiv parametriert),
Tausche einen Datenblock von 174 Byte in beide Richtungen aus und trenne die Verbindung wieder. usw.
Dies funktioniert teilweise!

Mein Problem: Die 2 SPS'n mit Verbindung zum Leitrechner und Zusatzgerät, scheinen sporatisch das Polling zu "bevorzugen" und unterbrechen ihre Kommunikation (zumin. mit den Zusatzgeräten). Grundsätzlich steht aber im technischen Handbuch, dass max 8 offene Verbindungen realisiert werden können. Daher verstehe ich nicht wieso das ganze eine Weile funktioniert und dann der TCON einfach in ein Dauer-"busy" geht.

Falls jemand eine Idee/Ursache für dieses Verhalten hat, wäre ich sehr dankbar.

Mfg Jenser

PS: Sorry für das Beitragsrecyling