TIA Redundante CPUs S7-1500R

Zuviel Werbung?
-> Hier kostenlos registrieren
Schaun wir mal, ob der Ruf wieder aufgebaut werden kann...
Ein weiterer Schritt vorwärts ist, wohl die Möglichkeit einen Syncup auch mit offenem MRP Ring auf X1 auszulösen. Das stört mich schon ewig. dass eine H mit Sync modulen sich nicht aufsynchronisieren lies wenn der MRP Ring nicht geschlossen war.

Jetzt funktioniert das. Wenn man die MRP Prüfung ausschaltet, hat man aber die Rote LED und den Diagnoseeintrag. Und das lässt sich glaub ich auch nicht ausschalten.
Wiedermal etwas wo Siemens meint, man muss dem Entwickler vor sich selber schützen.
1708074585010.png
 
Es gab noch eine weitere verbesserung die ich nicht mitgeschnitten hatte.
Man kann die H CPU jetzt auch ohne MRP Ring konfigurieren. Das heisst man kann von X1 einfach einen Stich auf z.B. je einen Switch machen und nur die Switches im Ring verbinden. Dadurch wird das gesamte System wesentlich flexibler und IMHO stabiler.
 
Okay ich bin erstmal begeistert ;) . Das muss ich mir mal zusammenbauen. Mich irritiert das man nur einen CP auswählen muss in der W1 Konfiguration. Woher weiss er welche CPs der SystemIP zugeordnet werden soll? Hast du das schon versucht?
Ich glaub ich muss mir das Handbuch nochmal unters Kopfkissen legen, hat sich doch einiges weiterentwickelt das ich nicht so mitgekriegt habe.
 
Zuletzt bearbeitet:
20240305_102510.jpg
Mittlerweile ist das H System eingebaut. Ich dachte das sind cpu's mit monsterelektronik drin. Hälfte ist nur Kühlkörper😅. Und die beue Generation Bedienpanel ist auch noch nicht drauf.. Ich lege mir das Handbuch auch mal unters Kissen. Nächste Woche dran..
 
Es gab noch eine weitere verbesserung die ich nicht mitgeschnitten hatte.
Man kann die H CPU jetzt auch ohne MRP Ring konfigurieren. Das heisst man kann von X1 einfach einen Stich auf z.B. je einen Switch machen und nur die Switches im Ring verbinden. Dadurch wird das gesamte System wesentlich flexibler und IMHO stabiler.
naja, diese Netzwerktopologie ist nicht ganz trivial, wenn man das aus Redundanz sicht betrachtet. Da muss man mal intensiver drüber nachdenken.
Natürlich müssen beide H-CPUs dann mit dem Switch verbunden werden... Dann hast aus Sicht der CPU nen offenen Ring und aus Sicht des Switches zu den Geräten MRP...
Bei den 400H war das ja schon immer nen offener Ring und kein MRP aus Sicht der CPU... Wenn das jetzt bei 1500H auch so ist, wär ja mal nen Vorteil weil einheitlich...

Mal schaun, wann ich meine erste 1500H Anlage krig...
 
Zuviel Werbung?
-> Hier kostenlos registrieren
naja, diese Netzwerktopologie ist nicht ganz trivial, wenn man das aus Redundanz sicht betrachtet. Da muss man mal intensiver drüber nachdenken.
Natürlich müssen beide H-CPUs dann mit dem Switch verbunden werden... Dann hast aus Sicht der CPU nen offenen Ring und aus Sicht des Switches zu den Geräten MRP...
Bei den 400H war das ja schon immer nen offener Ring und kein MRP aus Sicht der CPU... Wenn das jetzt bei 1500H auch so ist, wär ja mal nen Vorteil weil einheitlich...
Natürlich muss man sich über die Topologie trotzdem Gedanken machen. Allerdings wenn der MRP Zwang entfällt. Kann man auch auf andere Switches umschwenken. 400H habe ich nie PN IOs oder dergleichen eingesetzt. Die haben normal über Switches und Co mit anderen CPUs kommuniziert, Ethernet war nur für Kommunikation und HMI da.
RIOs wurden dann über Profibus angebunden und da halt zwei Ringe Kopf1 und Kopf 2 und dann mit YKopplern oder Aktiven 200M Baugruppen angebunden.

Redundante Peripherie an H habe ich nie gebraucht, Das habe ich immer anders gelöst.
 
Natürlich muss man sich über die Topologie trotzdem Gedanken machen. Allerdings wenn der MRP Zwang entfällt. Kann man auch auf andere Switches umschwenken. 400H habe ich nie PN IOs oder dergleichen eingesetzt. Die haben normal über Switches und Co mit anderen CPUs kommuniziert, Ethernet war nur für Kommunikation und HMI da.
RIOs wurden dann über Profibus angebunden und da halt zwei Ringe Kopf1 und Kopf 2 und dann mit YKopplern oder Aktiven 200M Baugruppen angebunden.

Redundante Peripherie an H habe ich nie gebraucht, Das habe ich immer anders gelöst.
Für größere Anlagen hab ich mit den PNIO-Ringen grundsätzlich nen Problem. Egal ob H-CPU oder nicht... 50 Teilnehmer in nem MRP-Ring macht ganz andere Sorgen...
Keine Ahnung, ob man jetzt mehrere MRP-Ringe projektieren kann? Jedenfalls mit Stichen und Sternen oder Bäumen hat man schnell Single-Point of Failure, die man dann irgendwie anderweitig durch redundante Feldgeräte o.ä. kompensieren muss...
 
Ein weiterer Schritt vorwärts ist, wohl die Möglichkeit einen Syncup auch mit offenem MRP Ring auf X1 auszulösen. Das stört mich schon ewig. dass eine H mit Sync modulen sich nicht aufsynchronisieren lies wenn der MRP Ring nicht geschlossen war.

Jetzt funktioniert das. Wenn man die MRP Prüfung ausschaltet, hat man aber die Rote LED und den Diagnoseeintrag. Und das lässt sich glaub ich auch nicht ausschalten.
Wiedermal etwas wo Siemens meint, man muss dem Entwickler vor sich selber schützen.
Anhang anzeigen 75517
Da bin ich heute auf die Schnautze gefallen. Hab noch kein Firmware Hochrüstung gemacht..

Sonnst habe ich die 1500H jetzt am laufen.
War ausendlich recht einfach.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Jetzt funktioniert das. Wenn man die MRP Prüfung ausschaltet, hat man aber die Rote LED und den Diagnoseeintrag. Und das lässt sich glaub ich auch nicht ausschalten.
Wiedermal etwas wo Siemens meint, man muss dem Entwickler vor sich selber schützen.
Das ist ein Fehler, das sollte nur die gelbe LED angehen. So steht es in der Online-hilfe zum SFC RH_CTRL.
Das wird in einer der nächsten Patch-versionen behoben.

Gar keine LED ist nicht gewollt, denn bei offenem Ring ist das System grundsätzlich in der Gefahr, dass beim Syncup Devices ausfallen (genau deshalb wird der Syncup ja defaultmäßig verhindert). Darum soll das System nicht dauerhaft mit deaktivierter MRP-Prüfung betrieben werden. Das ist nur für die Inbetriebnahme gedacht.
 
Ich binn mal gespannt was mir die 1500H Kommunikationstechnisch gibt.. Einfache S7 SPS Kommunikation ist schon ein Ding /kein ding..

Für die Modbus TCP/IP Kommunikation mit das übergeordnete Leitsystem (Einfach) traue ich die Siemens redconnect Bausteine auch nicht.
Wir setzen jetzt auf eine PtP Karte in ein ET200MP, die S2 am 1500H hängt. Und dann ein RTU TCP/IP Wandler. (Musst du nicht konfigurieren)
Die Art von Verbindung haben wir schon in Betrieb gesetzt.
Das muss später ohne viel Aufwand funktionieren. Die Anlage steht später in der Hölle. (Wüste Algeriens)
Da muss ich mich selbst heute mal wiedersprechen.

Heute Morgen habe ich eine der SPS-Verbindungen in Betrieb gesetzt auf Basis Open User Communication, OUC.
Und die Parametrierung und Verwendung ist zig mal einfacher wie eine S7 Verbindung.

Ich verwende die System IP-Adresse des H-Systems.

Nach einfügen TSEND_C diese Parameterieren über den Werkzeugkasten.
Bei Gegenstelle SPS wird ein Baustein generiert (Im SystembausteinOrdner) mit Vebindungsdaten.
Diese am Connect der gegenstelle TRCV_C ) per drag und drop.
Die Kommunikationsdatenbaustein per drag und drop am Data. Und fertig ist.
Verwendung NICHT optimierte Datenbauseinen.

Dann habe ich auch ein bischen mehr vertrauen in die Modbus TCP/IP.

Jetzt mal voll gass weiter. Ich muss fertig werden..
 
Zurück
Oben