Werte von Master-SPS auf mehrere Slave-SPS verteilen

lance

Level-2
Beiträge
18
Reaktionspunkte
0
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo, ich versuche mich an einem kleinen Projekt und komme leider nicht weiter.
Ich möchte einen INT Wert den ich auf einem HMI eintippe in ein DB schreiben, dieser Wert soll von dort aus auf mehrere (ca. 32) Slave-SPS "verteilt" werden.
Welche Möglichkeiten zur Übertragung von Master auf Slave gibt es?
Ist es ohne weiteres überhaupt möglich eine Verbindung von einer Master-SPS auf ca. 32 Slaves-SPS herzustellen?
Auf welche Besonderheiten muss ich wohl möglich achten?

Bin hier noch sehr neu und unerfahren, also seht mir meine Dummheit bitte nach.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Also Prinzipiell gibt es hier mehrere Möglichkeiten.

Es kommt ganz darauf an was für Hardware du einsetzt, wie der Netzwerkaufbau ist etc.
Vielleicht kannst du ja mal eine Skizze dazu zeichnen und spezifizieren ob du Rückmeldungen brauchst etc.

Als Beispiel nutze ich aktuell eine Steuerung für einen anderen Anwendungsfall die RFC1006 Slots bereitstellt auf Port 102 wo aktuell ca. 30 Steuerungen verbunden sind und 800Byte an Daten austauschen.
Ich habe ISOonTCP gewählt, damit nicht in den Projekten die IP Adressen in der Hardware gepflegt werden müssen und dass in der Firewall nur ein Port gepflegt werden muss.

Edit:

Was auch noch interessant wäre, wie Zeitkritisch die Übertagung ist etc.
 
Welche Möglichkeiten zur Übertragung von Master auf Slave gibt es?
Ist es ohne weiteres überhaupt möglich eine Verbindung von einer Master-SPS auf ca. 32 Slaves-SPS herzustellen?
Auf welche Besonderheiten muss ich wohl möglich achten?
Bei TwinCAT könnte man dafür die Netzwerkvariablen nehmen. Wie hier schon geschrieben wurde wäre mal interessant welche Hard- und Software zum Einsatz kommt.
 
Ich benutze TIA-Portal V17, eine Simatic S7-1200 CPU 1214C als Master und momentan zum testen zwei CPU 1212C als Slaves.
Die Slave CPU's dienen als Steuerung für Spulköpfe und sollen nur die Startwerte vom Master vor dem Start bekommen, Zeitkritisch ist das ganze also gar nicht.
 
I-Device wäre eine Möglichkeit, damit wird die Slave CPU quasi zu einem Profinet Teilnehmer der Master CPU.
Bei I-Device müssen alle CPU's im gleichen Subnetz liegen und können dann im Profinet Takt Daten austauschen auf IO Bereichen.

S7-Verbindung wäre eine Möglichkeit, dort kann zyklisch oder Event getriggert Daten ausgetauscht werden und mit einem Handshake die Übernahme bestätigt werden.
ISOonTCP etwa das gleiche wie bei S7 Verbindung
TCP/IP etwa das gleiche wie bei S7 Verbindung


Bei der S7 Verbindung müssten alle Verbindungen auf der Master CPU und jeweils eine auf der Slave CPU angelegt werden.
ISOonTCP oder TCP/IP bei Programmierter Verbindung, könnte über eine Verbindung eine Slave CPU nach der anderen ansprechen und die Werte übertragen und nach Handshake zur nächsten CPU gehen. Wenn es nicht zeitkritisch ist wäre dass eine Ressourcen schonende Variante.
 
Von Siemens gibt es da auch ein Beispiel für UDP Brodcast:


20983558_MasterSlave_UDP-Broadcast_02_de.png



//Edit: Link auf den deutschen Beitrag abgeändert. //CM
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
Von Siemens gibt es da auch ein Beispiel für UDP Brodcast:


20983558_MasterSlave_UDP-Broadcast_02_de.png

Die Option habe ich bewusst weggelassen, da es hier keine Übertagungskontrolle aufgrund des Protokolls gibt. Und wenn einer Rückmeldung gewünscht ist diese auch separat generiert werden muss.
Aber stimmt das geht auch wenn alle Geräte im gleichen Subnetz sind. Ist auch schön wenn Geräte die Adressen wechseln um diese zu suchen. (z.B. DHCP)
 
Die Option habe ich bewusst weggelassen, da es hier keine Übertagungskontrolle aufgrund des Protokolls gibt. Und wenn einer Rückmeldung gewünscht ist diese auch separat generiert werden muss.
Aber stimmt das geht auch wenn alle Geräte im gleichen Subnetz sind. Ist auch schön wenn Geräte die Adressen wechseln um diese zu suchen. (z.B. DHCP)
Alles hat für und wider. Allerdings verlangen alle die Lösungen ein gewisses Maß an Einarbeitung und lesen von Dokus.
Pro für die Verwendung der verlinkten Siemens-Lösung ist:
Für die Kommunikation wird das UDP-Protokoll verwendet. Das hat den Vorteil, dass so die Verbindungen nicht statisch projektiert werden müssen, sondern programmgesteuert eingerichtet und verwaltet werden können. Dadurch müssen sich die teilnehmenden Stationen bei der Projektierung nicht gegenseitig bekannt sein. Dieses Vorgehen ermöglicht die flexibelste Lösung um das System fast beliebig zu erweitern.
Gerade der Punkt, dass man am Master nicht mehr angreifen muss, wenn ein neuer Salve hinzugefügt wird, ist schon sehr nice.
Wenn eine Quittierung der Daten erforderlich ist, muss man diese unabhängig vom verwendeten Protokoll von Hand zu Fuß programmieren und auch melden. Die Übertragungskontrolle, dass nicht Paket 3 vor Paket 2 ankommt, ist in dem geschilderten Fall (IMHO) zu vernachlässigen, die Wertänderung wird nicht im ms Bereich liegen.
 
Schonmal herzlichen Dank für die schnellen Antworten, ich werde mich jetzt erstmal mit ein paar Lösungsvorschlägen befassen um dann Rückmeldung zu geben was und wie ich mein Problem vielleicht gelöst habe.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Moin, habe mich mit der Thematik beschäftigt und bin mit IO-Device zum gewünschten Ergebnis gekommen.
Werde mich trotzdem noch mit TSEND_C und TRCV_C beschäftigen, kann nicht schaden.
Danke für die Hilfe
 
Zurück
Oben