TIA Vor-/Nachteile Verbindungsmöglichkeiten SPS zu SPS

Ich muss in naher Zukunft für nen Auftrag mehrere Transportfahrzeuge mit jeweils ner eigenen SPS aussteuern (Positionsfindung, Greifer aussteuern Fahren, etc). Die Fahraufträge kommen von einer einzelnen SPS die mit dem überlagerten Rechnersystem telefonieren, und die Ansteuerung der Hubkräne und die Koordinierung der Fördertechnik übernehmen soll.
Die Fahrzeuge senden ihren aktuellen Status an die Haupt- SPS zurück, an der auch die Bedienterminals und die Hauptvisualisierung hängen.

Nun bin ich am suchen wie ich die Verbindung zwischen den einzelnen SPSen bewerkstelligen kann. Mein Problem liegt aktuell darin, dass ich, da ich bisher nie mehr als zwei SPSen miteinander habe kommunizieren lassen, den Aufwand nicht abschätzen kann den es brauchen würde um das mit drei oder mit 70 Fahrzeugen auf die gleiche Art und Weise zu erledigen. Ich hoffe ihr könnt mir da ein wenig mehr erzählen.

Unter Step7 hab ich das schon mit Put/Get und Telegrammen erledigt. Bei TIA (korrigiert mich wenn ich falsch liege), gibt es die Einbindung als I- Device in die HW Konfig der Haupt- SPS.
Gibt es noch weitere Varianten Daten von einer SPS auf eine andere zu bekommen?

Alle Varianten machen ja eigentlich das gleiche. Daten werden hier abgesendet und kommen auf der anderen SPS an nur der Aufwand auf den SPSen ist unterschiedlich, deshalb wollte ich zusätzlich mal fragen wie die Meinungen zu den Varianten liegen.

I- Device: Hab ich bisher noch nie gemacht, aber was ich aus der Doku von Siemens herausgelesen habe ist, dass die I- Device Steuerung als vorverarbeitende Einheit für die Haupt SPS dient. Ich könnte wie bei einem PN/PN Koppler also einen E/A Bereich definieren (Sagen wir mal 10 Worte) über den die beiden Steuerungen Daten austauschen können. Wenn die Hauptsteuerung einen Befehl gibt, führt die Steuerung den Befehl aus und meldet dies zurück. Nachteil wäre zum einen der hohe Verbrauch von E/A Adressen der Hauptsteuerung zum anderen wäre die Variante nicht skalierbar wenn die Anzahl der Fahrzeuge irgendwann steigt, Vorteil zweifellos die Einfachheit des ganzen bei der Projektierung.

Put/Get: Hauptsteuerung wäre dann der Master und würde über X Verbindungen Daten in den Speicher der Fahrzeugsteuerung kopieren und sich die Informationen holen. Alternativ würde sich die Fahrzeugsteuerung die Daten holen und in die Hauptsteuerung schreiben. Wieviele Put/Get Verbindungen kann man parallel zu einer einzelnen Steuerung aufbauen? Müssen die Steuerungen dafür immer noch im gleichen Projekt sein?

Telegramm: Alle Informationen werden als dediziertes Telegramm verpackt und über eine eigene Verbindung zwischen den Fahrzeugen und der Hauptsteuerung transportiert. Braucht zur Identifikationen einen größeren Overhead mit Telegrammkopf und Prüfsumme sowie viel Programmierung zur Auswertung der Telegramme. Ist nicht mein Favorit, erscheint mir aber aktuell als das am besten skalierbar.

Steuerungen für die Fahrzeuge sind aktuell 1214er im Gespräch und die Haupt-SPS soll eine 1517-3 werden. Programmiert wird vermutlich mit V14 und noch nicht mit V15.

Ich würde die I Device der S7 Kommunikation immer vorziehen.

• I Device ist extrem schnell( PN Zyklus )
• I Device gibt es auch als F I Device
• Failsafe
• Profinet Teilnehmer Überwachung
• Du kannst viel mehr Daten übertragen als mit der S7 Kommunikation
• ....

Gruß

Die Anzahl der PN-Devices ist sicher auch höher als die max. Anzahl von NetPro Verbindungen.

Grüße

Marcel

Die Projektierung eines Profinet-iDevice ist viel weniger aufwändig als die Projektierung + Programmierung von Verbindungen. Man muß allerdings planvoll vorgehen, weil die Projektierung im laufenden Betrieb nicht geändert werden kann (Änderung der Geräte/Hardware-Konfig erfordert CPU-Stop).

iDevices: Der Verbrauch von E/A-Adressen ist bei S7-1500 in der Regel kein Begrenzungsfaktor, es stehen 32kByte E-Adressen und 32kByte A-Adressen zur Verfügung, das reicht z.B. bei 50 Byte Eingang und 50 Byte Ausgang je iDevice für mehr als 640 iDevices. Es kann mit viel mehr Geräten Daten ausgetauscht werden als über programmierte Verbindungen. Im Betrieb kümmert sich das Betriebssystem der CPU vollständig um Verbindungsaufbau, konsistenten Datenaustausch, Fehlererkennung.

Einzelne Verbindungen: Die 1517F hat zwar ziemlich reichlich Verbindungsressourcen (über die CPU-integrierten Schnittstellen können Verbindungen zu ca. 150 Kommunikationspartnern gleichzeitig unterhalten werden), die müssen aber alle projektiert werden und für jede Verbindung müssen im Programm ein/zwei Kommunikationsbausteine aufgerufen werden.

Harald

In diesem Fall (Fahrzeuge evtl. über WLAN angebunden) könnte das Nichtverwenden von iDevice aber auch Vorteile haben.
Z.B. hast du bei einer anderen Verbindungsart die volle Kontrolle darüber, wann ein Verbindungsausfall gemeldet wird und zu einer Systemstörung führt. Außerdem bleiben z.B. bei einer Put/Get Verbindung auch bei Ausfall der Verbindung die letzten Empfangsdaten im Zielbereich bestehen, bei iDevice gehen dir alle Signale auf Null. Hängt davon ab ob und wie Teile bei Verbindungsausfall auch autark zumindest zeitweise weiterfunktionieren sollen.

Hi, Frohes Neues an alle und danke für die Antworten.

Ich habe vollkommen vergessen zu sagen, dass die Fahrzeuge mit WLAN mit der Hauptsteuerung verbunden sind.

Ja, der Verbindungsabbruch ist ein Problem. Aktuell hab ich das so gedacht, dass ich bei Verbindungsabbruch nicht sofort eine Störung möchte, sondern das Fahrzeug erstmal weiterfahren soll, weshalb wir eine eigene Steuerung pro Fahrzeug vorsehen wollen.

In der Strecke sind lange gerade Strecken vorhanden, an denen wir die WLAN Antennen weiter auseinander setzen wollten, da dort keine Daten ausgetauscht werden müssten.
Wenn es da zu einem Abbruch kommt, könnten die Steuerungen also mit I-Device nicht mehr weiterfahren, wenn ich den Einwand richtig verstanden habe.
Irgendwie hatte ich das so drin, dass I-Device so ein Mittelding ist, durch welches die beiden Steuerungen auch noch autark funktionieren könnten wenn keine Verbindung zwischen ihnen besteht.

Ich fasse also mal zusammen:
I-Device ist "einfach(er)" als die anderen Verbindungsarten (Yayy)
Mit der Zusammenstellung aus 1500ern und 1200ern kann ich >100 Fahrzeuge ansteuern (Doppel- Yayy)
Kommt es aber zu einem Verbindungsabbruch, wars das (Mist)

Danke an alle die hier geantwortet haben, ihr habt mich echt weitergebracht.

Du kannst dein Fahrzeug natürlich auch bei I-Device bei Wegfall der Verbindung weiterfahren lassen. Nur musst du die Daten aus dem Schnittstellenbereich vorher umkopieren und den Zustand dann irgendwie abfangen.

Wenn du beide Seiten programmierst, dann ist es aber kein sonderlich großer Aufwand das zu realisieren. Problematisch wird das z.B., wenn dir eine andere Steuerung die du nicht verwaltest Sollwerte sendet dich sich ändern. Dann musst du jeden Wert auf Änderung prüfen usw., da ist eine Put/Get- oder andere zweiseitige Verbindung einfacher handzuhaben,

Hi,

Ja, ich kann beide Seiten frei (um)programmieren. Die Steuerdaten umzukopieren wäre also kein Problem.

Zu dem trotzdem weiterfahren hab ich noch eine Frage:
Ist das nicht so, dass die Steuerungen als Bauteil im Hardwaremanager der CPU drinhängen?
Wenn also eine nicht erreichbar ist, würde die Steuerung dann den OB86/83 aufrufen? Meintest du das mit "Zustand abfangen"?

Danke soweit.

Wie machst Du denn die Sicherheitstechnik?

Über Profisafe oder "klassisch" ?

Da wäre dann auch noch etwas zu beachten.

Grüße

Marcel

Die Fahrzeuge fahren in einer Zwischendecke über der Fabrikhalle deswegen ist da nicht viel. Nur wenn alle Fahrzeuge angehalten haben, darf Wartungspersonal rein. Dort ist auch die Fördertechnik aufgebaut.
Es gibt zwei Türen die über Türkontakte abgefragt werden.
Wenn das Bit an der stationären Steuerung da ist, wird ein True Bit an die Steuerungen der Fahrzeuge geschickt dass das Fahrzeug fahren darf, liegt das Bit nicht an halten die Fahrzeuge an und melden das an die stationäre Steuerung zurück, die dann die Türen freigibt. Vorher muss man über den Sicherheitszaun klettern um reinzukommen. Die Fahrzeuge haben noch einen Sensor an der Front der einen Aufprall erkennt und jedes Fahrzeug unabhängig voneinander anhalten lässt, falls Ware von einem Fahrzeug fällt oder jemand Dummheiten macht. Zusätzlich fahren die Fahrzeuge sehr langsam sodass der Sensor auf jeden Fall schnell genug reagiert um Schaden an Menschen zu verhindern.

Zombie schrieb:

Es gibt zwei Türen die über Türkontakte abgefragt werden.
Wenn das Bit an der stationären Steuerung da ist, wird ein True Bit an die Steuerungen der Fahrzeuge geschickt dass das Fahrzeug fahren darf, liegt das Bit nicht an halten die Fahrzeuge an und melden das an die stationäre Steuerung zurück, die dann die Türen freigibt. Vorher muss man über den Sicherheitszaun klettern um reinzukommen. Die Fahrzeuge haben noch einen Sensor an der Front der einen Aufprall erkennt und jedes Fahrzeug unabhängig voneinander anhalten lässt, falls Ware von einem Fahrzeug fällt oder jemand Dummheiten macht. Zusätzlich fahren die Fahrzeuge sehr langsam sodass der Sensor auf jeden Fall schnell genug reagiert um Schaden an Menschen zu verhindern.

Zum Vergrößern anklicken....

Also die Kopplung mit dem "Bit an die Fahrzeuge senden" ist über Put/Get auf gar keinen Fall eine sichere Information. Das ist dann einfach nur ein "Merker" und würde keine Sicherheits-Betrachtung standhalten.
Das sähe dann mit einem I-Device (je nach Ausführung) ggf. schon anders aus.
Die Frage, die sich hier aber stellt ist, ob deine Fahrzeuge, wenn sie einen Laser-Bereichsscanner haben und dieser dann sicher ist (z.B. ein Sick S300 oder S3000) und seine Funktion auch "sicher" verschaltet ist nicht schon ausreicht. Dann wäre deine Türmeldung als Information an das FTS nämlich auch ausreichend - das Gerät in sich ist sicher ...

Gruß
Larry

Hi,

was mir negativ an iDevices aufgefallen ist:

Wenn irgendwann mal ein Systemupdate der SPSen gemacht werden soll, z.B. V14 auf V14 SP1, dann ändern sich die iDevices! D.h. die iDevices der Fahrzeuge müssen dann alle neu erzeugt und in der Haupt SPS gelöscht und neu angelegt werden. Gerät "tauschen" gibt es bei iDevices nicht.

:-(