Step 7 Kommunikation zwischen mehreren 315-2PN

Rici

Level-2
Beiträge
128
Reaktionspunkte
1
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo,

einer unserer Kunden hat 2 Anlagen, welche im Moment in Produktion sind.
Das Produkt dieser Anlagen soll dank zusätzlichem Equipment zusammengeführt bzw. weiterverarbeitet werden.
Die 2 Anlagen laufen bis jetzt separat und haben jeweils eine 315-2PN/DP Steuerung. Das Zusatzequipment bekommt auch eine 315-2PN/DP Steuerung.
Alles V3.2.3

Es sind einige Signale, welche ausgewechselt werden sollen, daher soll die Kommunikation über den BUS stattfinden.
Wunsch ist es eine dieser Anlagen wegzuschalten ohne dass die Prozessoren auf Stopp oder ähnliches gehen.

Ich habe einige Ansätze im Netz gefunden, weiß jedoch nicht was in diesem Fall das Beste wäre bzw. was davon funktioniert.
Es ist was neues für mich und hoffe jemand kann mir einen guten/passenden Weg vorschlagen.

Soll dies über ProfiNet oder ModBus geschehen?
Wird die Konfiguration verändert? bzw. Tauchen in jeder Steuerungskonfiguration die anderen CPU's.
Geschieht das schreiben nachher mit bestimmten Bausteinen. Sprich lesen/schreiben mit einem Aufruf?

Danke im Voraus!

Rici
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Es kann schwierig überschaubar sein.
Für die gennannt Hardware wurde ich nur diese Varianten überlegen:

  • BSEND/BRECV über eine S7-Verbindung. Wenn den S7-Verbindung projektiert und geladen ist, kann man den Kommunikation zur Laufzeit umändern. Die Daten werden Asynkron übertragen.
  • Profinet über PN/PN Koppler. Beide CPUs sind PN IO Controller. Schnell, zuverlässig, prioriziert. Aber unflexibel. Keine Änderungen in RUN.
  • Profinet über i-Device, eine CPU ist PN IO Controller, der andere CPU ist PN i-Device. Schnell, zuverlässig, prioriziert. Aber unflexibel. Keine Änderungen in RUN.
 
quick and dirty wäre put/get. (eine verbindung muss eingerichtet werden)
ähnlich wie bsend brcv aber auf der gegenseite ist nicht der korespondierende baustein nötig.

bedenken sollte man, dass wenn man in eine andere cpu putet die davon nichts mitbekommt.
dh eine andere cpu kann was in db's schreiben und du weisst nicht woher das kommt. das sollte man sauber dokumentieren.
ich halte es in der regel so, wenn ich das verwende, immer nur get verwende (wenn möglich)

also anstatt das cpu1 daten bei cpu2 abholt (get) und auch daten in cpu2 ablegt (put)
mache ich es so, dass
cpu1 getet von cpu2 und cpu2 getet von cpu1.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo, und danke schon mal für die Antworten,

@JesperMP
Die im Moment laufenden Anlagen sollen von einander nichts wissen. Daher haben diese jeweils eine CPU mit welcher diese kommunizieren.
Die PLC vom Zusatzequipment welche die Produkte zusammenführt, muss mit beiden Anlagen kommunizieren. Also Kommunikation zwischen 3 CPU's.
Eine Master CPU soll es nach Möglichkeit nicht geben, denn die Anlagen sollen bei bedarf ohne das Zusatzequipment fahren können.

@volker
die Idee finde ich gut, ich finde die sogar clean and tidy.

Alle CPU's bekommen get Bausteine und führen diese aus nur wenn die Anlagen verbunden sind. (Hardwareseitig eine Brücke wenn die Anlagen gesteckt sind)

Wie ist es mit der Projektierung? Die Bausteine benötigen eine Adresse, heißt in der Hardwarekonfiguration sind alle CPU's aufgeführt. Bzw. Bei den Anlagen eine zusätzliche, beim Folgeequipment zwei (für jede Anlage eine). Sollte die Verbindung dann getrennt werden so werden die PLC's eine rote LED leuchten haben. Das sollte jedoch verkraftbar sein.

Es werden nach der Fertigstellung 3 Projekte existieren. Mit unterschiedlichen Hardwarekonstellationen. Bei den Anlagen ist jedoch nur jeweils die IP der eigenen CPU unterschiedlich.

Sind meine Gedankengänge richtig?
 
Warum 3 separate STEP7 Projekte ?
Es ist ja sowiso eine gemeinsame Funktionalität. Dann macht es durchaus Sinn das man nur ein STEP7 Projekt anlegt, mit die 3 CPUs.
Das die CPUs auch autark funktionieren können sollen, ändert nichts dabei.

Du kannst entweder voll-spezifizierte Verbindungen oder unspezifizierte Verbindungen verwenden.
Und du kannst deine Lösung auf PUT/GET oder BSEND/BRECV bassieren.

Persönlich wurde ich für solch eine Projekt eine gemeinsame Projekt anlegen, vollspezifizierte Verbindungen konfigurieren, und BSEND/BRECV programmieren.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Persönlich wurde ich für solch eine Projekt eine gemeinsame Projekt anlegen, vollspezifizierte Verbindungen konfigurieren, und BSEND/BRECV programmieren.
Würde ich auch so machen. Geht aber manchmal nicht, wenn eine Station von einer unkooperativen Fremdfirma ist.


Wie ist es mit der Projektierung? Die Bausteine benötigen eine Adresse, heißt in der Hardwarekonfiguration sind alle CPU's aufgeführt. Bzw. Bei den Anlagen eine zusätzliche, beim Folgeequipment zwei (für jede Anlage eine). Sollte die Verbindung dann getrennt werden so werden die PLC's eine rote LED leuchten haben.
Man kann für die Übersichtlichkeit im Projekt "Platzhalter"-Stationen (ohne Programm) für die Kommunikations-Partner einfügen, muß aber nicht. Mit Platzhalter-Station kann man als Dokumentation der DatenKommunikationsSchnittstelle prima den/die Kommunikations-DB des Partners hier im Platzhalter hinterlegen.

Ohne Platzhalter-Station muß man die S7-Verbindung zu einer im Projekt "unspezifizierten" Station/Partner anlegen, da kann man für den Partner einfach die IP-Adresse angeben, und bei den Adressendetails Rack + Stackplatz der Partner-CPU. Üblicherweise verwendet man beim Partner die Verbindungsressource 03, da braucht die Verbindung im Partner nicht projektiert werden. Verbindungsressourcen >= 10 hex gehen auch, dann muß man die Verbindung auch im Partner projektieren.
Bei S7-Verbindungen für PUT/GET ohne Zutun der Partner-CPU "Aktiver Verbindungsaufbau" aktivieren.
Man sollte eine Verbindungsüberwachung (Timeout auf einen toggelnden oder inkrementierenden Wert) programmieren
Wenn eine S7-Verbindung nicht aufgebaut wird/ist, dann leuchten keine roten Status-LED.

Harald
 
Hallo Leute,

kurze Rückmeldung meinerseits.
Hatte die Umsetzung mit den Gen-Bausteinen umgesetzt. Und es funktioniert sehr gut.
Das Zusätzliche Equipment kann jederzeit abgekoppelt werden, und die Hauptanlage laufen weiter.
Das Zusatzequipment kontrolliert die Kommunikation seinerseits und gibt eine Störung raus sobald diese nicht OK ist.
Und umgesetzt ist es mit in drei Siemens Projekten.

Vielen Dank an alle.
 
Zurück
Oben