TIA Gerätetausch ET200SP CPU gegen andere Bauform

[Oje]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo zusammen,
folgendes Problem habe ich. Anlage im Ausland mit extrem schwankenden Zykluszeiten (zw. 20-50ms). Die Zykluszeiten fallen unter anderem an einem Taktband durch unterschiedliche Positionierungen (Taktlippe) auf. Ich denke der Haupteinfluss der Sprünge ist Safety (Eingestellte Zykluszeit 50ms, auch schon mit der Phasenverschiebung Versuche gemacht). Bedingte Aufrufe sind nicht vorhanden. Schleifen (2 Stück) laufen in jedem Zyklus gleich ab. Ein FW Upgrade brachte nur bedingte Besserung (Projekt wurde dabei von V15 auf V16 hochgerüstet). Meine Ideen sind langsam am Ende.
Denkbar wäre prinzipiel noch eine aktuellere FW und die Kommunikationslast (50% aktuell) zu verringern. Eine Erhöhung der Taktsynchronität (4ms) habe ich noch nicht in Betracht gezogen, da ich die Auswirkungen nicht abschätzen kann. Das sind aber alles Arbeiten die ich, wenn überhaupt, nur vor Ort machen würde.
Daher wollte ich direkt die CPU gegen ein größeres Modell tauschen. Leider geht das über die Option Gerätetausch nicht.

verbaut: CPU 1512SP-F (FW2.5)
Ziel: 1515F-2PN +Kopfmodul für die an die bisherige CPU angebunden EA-Karten.
Im Projekt sind aktuell 16 PN Teilnehmer, darunter ein S120 CU mit Profisave (Telegramm 30, 105 und 390). Programmierung der Achsen (3) über Technologieobjekte.
Dazu noch ein Mobil Panel mit F-Konfiguration.

Wie gehe ich jetzt vor um den Aufwand abschätzbar zu machen? Neue CPU einfügen und alles per Copy-Paste in die neue CPU? Aktualwerte natürlich vorher als Startwerte eintragen? Hat hier jemand Erfahrungswerte?

 

[Larry Laffer]

Wie gehe ich jetzt vor um den Aufwand abschätzbar zu machen? Neue CPU einfügen und alles per Copy-Paste in die neue CPU? Aktualwerte natürlich vorher als Startwerte eintragen?

Genau so ...

 

[Oje]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hatte eigentlich auf eine detaillierte Siemens Anleitung gehofft.
Mein Bauchgefühl sagt mir, dass selbst mit fehlerfreier Übersetzung hier am Tisch, dass Ganze unkontrollierbare Zeitfenster an der Anlage erfordert.
Ich werde mich mal daran versuchen, eine bespielte SPS mitnehmen und einfach mal machen. Wann es soweit ist steht aber noch nicht fest. Könnte frühestens in KW36 passieren.

 

[Larry Laffer]

Aber es ist ja tatsächlich genau so wie du es schreibst ...
Sowohl auf der Hardware-Seite wie auch auf der Software-Seite - das Einzige : du hast das Panel noch vergessen ...
Ein bisschen Fleißarbeit ist es also schon ... Aber wenn du zuhause das Projekt konsistent umgeschaufelt bekommst dann brauchst du es tatsächlich nur noch (nach dem Umbau) einspielen ...
Was vielleicht zu sagen wäre ist, dass eine CPU 1512 bei der genannten Hardware von Anfang an schon recht sportlich war ...

Gruß
Larry

 

[rostiger Nagel]

Wenn du in der Bauform bleiben möchtest und nichts gegen Soft-SPS hast,
bietet sich da der Open Controller an. Dann hast du auch stabile Zykluszeiten
von 1ms und nicht höher.

 

[Oje]

Zuviel Werbung?
-> Hier kostenlos registrieren

Was vielleicht zu sagen wäre ist, dass eine CPU 1512 bei der genannten Hardware von Anfang an schon recht sportlich war ...

Es war leider so ein typisches "Wachstumsprojekt". Fing klein an und wurde immer größer.
Rein vom Datenblatt hätte ich da ehrlicherweise aber auch kein Problem gesehen.

bietet sich da der Open Controller an

Den darf ich leider nicht verbauen. Wäre aber im Zielwerk aber auch zuviel des Guten. Instandhaltung ist da nicht so fit.


Frage am Rande:
Kann man abschätzen, was die IRT Zykluszeit von 4 auf 8ms für Auswirkungen auf die SPS-Zykluszeit hätte? Für die Sicherheitsbewertung wäre mir das Schnuppe. Anlage ist komplett eingezäunt und bei den jetzigen SPS Zyklen bringt mir die schnelle Aktualisierung doch eh nichts.


Kleine Ergänzung:
Mittlerweile setzen wir die SP CPUen aber nicht mehr ein. Neben den unkalkulierbaren Zykluszeiten fehlt uns auch die zweite Netzwerkkarte für das Firmennetz.

 

[Hohlkörper]

Kleine Ergänzung:
Mittlerweile setzen wir die SP CPUen aber nicht mehr ein. Neben den unkalkulierbaren Zykluszeiten fehlt uns auch die zweite Netzwerkkarte für das Firmennetz.

Sind denn die "goßen" 1500er stabiler bei den Zykluszeiten?

 

[Larry Laffer]

Nein ... die sind nur einfach leistungsfähiger.
Es ist so wie bei der "guten alten" Classic-Welt - da konntest du eine CPU 314 auch nicht mit einer 318 oder 319 vergleichen ...
Die Zykluszeiten ergeben sich ja aus dem SPS-Programm und was das so zu machen hat ...

 

[Oje]

Zuviel Werbung?
-> Hier kostenlos registrieren

Das ist zumindest meine Erfahrung. Gerade im Zusammenhang mit Safety. In den Aufrufen des Sicherheitsprogramms knickt die Zykluszeit ein.
Habe sicher aber keine statistisch relavanten Größen an Projekten gesehen.

 

[Oje]

Nochmal zurück zu meinem Ursprungsproblem. Was mache ich denn mit den ganzen Konfigurationen der SPS in der Hardware.
Muss ich das nebeneinander aufmachen und die Haken 1:1 händisch übernehmen?

Mein Leitfaden sähe dann so aus:

1. CPU ins Projekt einfügen
2. Sämtliche Einstellungen der alten CPU im Gerätemanager händisch übertragen. Bei Überschneidung "alte" CPU abändern.
3. Alles in der Netzsicht wieder verbinden, alte CPU aussen vor lassen
4. Sämtliche Einstellungen der HMI im Gerätemanager händisch anpassen
5. Technologieobjekte, Sicherheitsprogramm und Programmordner umkopieren.
6. Übersetzen und Fehler nach und nach beheben.
7. Alte CPU löschen
8. Abenteuer Inbetriebnahme starten.

Ergänzungen/ Tipps eurerseits?

 

[blackpeat]

Ich würde mit zwei Projekten arbeiten, einmal Original als Referenz öffnen und dann im zweiten (Kopie) die ganzen Änderungen. Die Alte CPU dann aus dem zweiten Projekt löschen und alle Infos aus der Referenz holen. Dann gibt es keine Überschneidung und geänderte Safetyadressen wo man es nicht erwartet usw..

Wichtig die MC_Servo und MC_Interpolator nicht kopieren das geht schief aber meldet erst mal keinen Fehler. TO's kann man aber kopieren, dann werden die OB's angelegt.

 

[SPS-freak1]

Zuviel Werbung?
-> Hier kostenlos registrieren

Guten Abend,

Vielleicht Stelle ich mir das auch zu einfach vor, aber reicht nicht in diesem Fall einfach ein "Gerät tauschen" und alle Einstellungen etc werden in das neue Gerät übernommen?!
Das ist doch wirklich besser als zur Classic Zeit. Da hatte ich oft Mal Angst, ob das alles so klappt.
Natürlich müssen die F Daten neu geprüft werden, aber das war's ja dann schon meiner Meinungen nach.

 

[Michitronik]

HI Oje, leider ist der Tausch von PLC zwischen den Bauformen eine Farce.

Ich habe es des Öfteren so gemacht, dass ich mein Ursprungsprojekt kopiert habe. Die Kopie geöffnet, dort die PLC ausgetauscht habe und dann das Original als Referenzprojekt geöffnet und dann einen vergleich der PLCs offline zu offline gestartet. Leider funktioniert der Hardware vergleich so nicht. Mir hat geholfen, dass ich die Module der SP PLC manuell in die Konfiguration des IO_Devices kopiert, so bleiben die Tags und Konfiguration der Module erhalten.



Man kann für die einzelnen Bausteine auch einen Detailvergleich starten und den Inhalt der FBs usw. genauer prüfen.

 

[Oje]

Morgen,
Die IO-Devices will ich ja behalten und mit einem neuen PN-Kopfmodul anstatt der SP-CPU anbinden. Oder meinst du etwas anderes?
@SPS-freak1: Gerätetausch geht eben nicht. Nur innerhalb der selben Bauform, sprich SP gegen SP oder "Fullsize gegen Fullsize".

 

[Larry Laffer]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich würde hier auch wie Blackpeat (Beitrag #11) vorgehen - das beinhaltet aus meiner Sicht die wenigsten "Reibungsverluste" ... und du kannst immer in dem "alten" Projekt noch wieder nachschauen ...

 

[Windoze]

Ich habe das auch schonmal gemacht (SP-CPU gegen eine in voller Größe). Ich habe auch das Projekt kopiert, die SP-CPU gelöscht und die Konfiguration und Bausteine manuell übertragen.
Was aber geht, ist das du nur die CPU aus der Station löschst und durch einen PN-Buskoppler ersetzt. Dann sparst du dir zumindest die E/A-Module neu zu konfigurieren.

 

[Oje]

Das mit dem PN-Buskoppler (Kopfmodul) habe ich genau so vor .
Ich denke, da muss ich jetzt einfach ins kalte Wasser springen und loslegen. Hinterher kann ich dann sagen wie lange es gedauert hat.
Vielleicht funktioniert es ja auch direkt.

 

[Oje]

Zuviel Werbung?
-> Hier kostenlos registrieren

So,habe das mal Offline probiert. Ich habe ca. 4h gebraucht bis ich Hard- und Software wieder fehlerfrei übersetzen konnte. Getauscht habe ich sogar gegen eine 1516 F-3 PN/DP. Das Selection Tool war bei der Berechnung der Auslastung mehr verwirrend als hilfreich. Da in Zukunft hier noch größere Updates anstehen könnten (zusätzliche Achsen), bin ich lieber "dick genug" rangegangen.

Was war auffällig beim Ändern der CPU:

Safety:
Safety musste neu aktiviert werden.
Den Main-Safety konnte ich nicht kopieren, musste ich neu anlegen und die Netzwerke dann kopieren.
Der RTG1_GLOB_FIO_STATUS musste einmal kontrolliert werden.

Hardware:
Die Gerätenummern waren total falsch und mussten händisch kontolliert und wieder gerade gezogen werden.
Ebenso hatte sich eine HW-Adresse geändert.

Motion Control:
MC-Servo musste händisch wieder auf Taktsynchroin gestellt werden. Dazu gab es aber eine Warnung
Die Telegramm UDTs waren nach dem Tausch 3x in der Variablenliste drin. Habe jeweils die beiden Kopien händisch gelöscht.

Programm:
Eigentlich keine Probleme.

Jetzt muss es nur noch in der Praxis funktionieren.

 

[Oje]

So, das Ganze hat nicht funktioniert! Wir haben vor Ort rückgebaut auf 1512SP und können die im folgenden beschriebenen Probleme auch am Schreibtisch reproduzieren.
Vorab: Da die 1516 nicht lieferbar war, wurde eine 1513F (6ES71513-1FL02-0AB0) FW2.6 bis 2.9 verbaut. Das HMI ist auf Imageversion 14.000 bis 16.005 getestet.

Problem:
Anlage lief eigentlich komplett, nur der rote Button des HMI (Emergency Stop over Profisave) leuchtete einfach nicht. Das Problem ist hier am Schreibtisch reproduzierbar. Nach Neugenerierung und Übertragen der CPU und HMI leuchtet dann der Button bis zum Nächsten stromabschalten (aber auch nur in 3 von 5 Fällen). Auch Werksreset des Panels und teilweise Ein-/Abziehen des Panels stellt die Verbindung manchmal her.
Mittlerweile habe ich alle erdenklichen Kombinationen an FW und Images untereinander probiert. Grundsätzlich sollte auch die Konfigurierung in TIA stimmen, sonst würde es ja nicht ab und an funktionieren.
Wir haben schon diverse Werte für die F-Überwachungszeit und Kommunikationslast getestet, da wir hier das Problem vermutet haben, konnten aber nie eine zuverlässige Lösung finden.
Wir sind etwas ratlos. Nächster Schritt wäre ein Ticket bei Siemens direkt. Ehrlicherweise erhoffe ich mir hier aber schnellere Tipps.
Jemand noch Ideen was es sein könnte?

 

[ducati]

der rote Button des HMI (Emergency Stop over Profisave) leuchtete einfach nicht.

Panel wirklich gesamtübersetzt, bzw.mal diese komischen temporären Dateien des Panel gelöscht?