TIA S7-1500H ohne Projektzugriff, CPU in TIA zurückladen

vollmi

Level-3
Beiträge
5.735
Reaktionspunkte
1.675
Zuviel Werbung?
-> Hier kostenlos registrieren
Ich habe gerade ein Projekt in dem mehrere S7-1518H (geladen mit TIA V17) verbaut sind. Leider ist hier das Projektfile nicht verfügbar und der Kunde wünscht Änderungen.

Mein Gedanke war erstmal die CPUs wieder in TIA einzulesen. Aber das scheint irgendwie nicht zu gehen. Die der Upload bringt ein paar warnungen wegen nicht installierter GSD. Aber sonst keine Fehler. Trotzdem taucht die CPU nicht im Ordner auf.

Kennt jemand das Verhalten? Oder habt ihr eine idee wie ich sonst vorgehen könnte?
 
Ich hab letztens ein Projekt rekursiv geladen, IP und FW der CPU über Proneta ausgelesen => Projekt erstellt mit der gleichen IP Adresse und dem passenden Firmware Stand und dann ging das ganze sauber rekursiv in mein leeres Projekt.
 
Ich hab letztens ein Projekt rekursiv geladen, IP und FW der CPU über Proneta ausgelesen => Projekt erstellt mit der gleichen IP Adresse und dem passenden Firmware Stand und dann ging das ganze sauber rekursiv in mein leeres Projekt.
Jetzt hat es geklappt, da waren noch nicht installierte GSDML Dateien in der CPU. welche ich erst im PG installieren musste bevor er mir auch nur ein RIO rücklädt. Mit allen GSD verfügbar hat mir TIA direkt die gesamte Topologie erstellt.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Naja wenn man keinen Zugriff auf ein Projektfile hat, wird einem nur das übrig bleiben und hoffen das nix schlimmes verloren geht.
ja... aber erstens würd ich mir das gut bezahlen lassen und vor allem für die Arbeiten auch ordentlich Zeit einfordern. Ob man sich dann den Ärger freiwillig antuen will, wenn man sonst genug Arbeit hat, muss jeder selbst entscheiden ;)

Ich hab jetzt nirgendwo gelesen, dass ein Rücklesen aus ner 1500H nicht gehen sollte. Aber am Ende brauchst ne Test-SPS (für 20.000€ und nem Jahr Lieferzeit) im Büro um zu experimentieren.

Jugend forscht halt...
 
ich hatte vor nem Jahr mal mit dem Rücklesen und Online/Offline Vergleich unter V17 experimentiert und u.a. festgestellt, dass z.B. die Einstellungen der Systemmerker nicht richtig rückgelesen werden...

Sowas bei ner H-Steuerung die ja vermutlich für etwas "wichtiges" benutzt wird, würd ich nicht freiwillig haben wollen...
 
ja... aber erstens würd ich mir das gut bezahlen lassen und vor allem für die Arbeiten auch ordentlich Zeit einfordern. Ob man sich dann den Ärger freiwillig antuen will, wenn man sonst genug Arbeit hat, muss jeder selbst entscheiden ;)

Ich hab jetzt nirgendwo gelesen, dass ein Rücklesen aus ner 1500H nicht gehen sollte. Aber am Ende brauchst ne Test-SPS (für 20.000€ und nem Jahr Lieferzeit) im Büro um zu experimentieren.

Jugend forscht halt...
Och Geld kommt dafür genug rein. Und um mal einen legalen Blick in fremde Software zu kriegen ^^
Der Download hat nun geklappt. Ich musste erstmal alle im Projekt verwendeten GSD dateien zusammentragen (Schiebel, AUMA, Siemens etc.) und zwar in exakt der Version in der sie verwendet werden.
Danach hat der Download funktioniert. Ich hab dann noch auf Plausiblisierung geprüft und dann wieder einen Upload durchgeführt. Mit anschliessendem Anlagentest. Hat einwandfrei funktioniert.

Ich hatte mir vom Programm aber mehr erhofft. Das ist wiedermal ein Beispiel von über Jahrzehnte weiterkopiert und nichts an neue Steuerungen angepasst. Da wird noch wild rumgepointert und nichtoptimiert übersetzt. UDTs gibts praktisch gar keine. Und das auf zwei fetten 1517Hs (Hab im Ursprungsposting 1518 geschrieben)
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Der Download hat nun geklappt. Ich musste erstmal alle im Projekt verwendeten GSD dateien zusammentragen (Schiebel, AUMA, Siemens etc.) und zwar in exakt der Version in der sie verwendet werden.
Meckert der die richtige GSD-Version an, oder wie krigst das raus?
Danach hat der Download funktioniert. Ich hab dann noch auf Plausiblisierung geprüft und dann wieder einen Upload durchgeführt. Mit anschliessendem Anlagentest. Hat einwandfrei funktioniert.
Der Teufel steckt sicherlich irgendwo im Details ;)
Ich hatte mir vom Programm aber mehr erhofft. Das ist wiedermal ein Beispiel von über Jahrzehnte weiterkopiert und nichts an neue Steuerungen angepasst. Da wird noch wild rumgepointert und nichtoptimiert übersetzt. UDTs gibts praktisch gar keine. Und das auf zwei fetten 1517Hs (Hab im Ursprungsposting 1518 geschrieben)
Naja, über Programmierstile kann man streiten ;) Ich verwende auch in S7-300/400 schon immer Symboliken, Strukturen und UDTs. Pointern versuche ich zu vermeiden ebenso unsymbolische absolute Adressierung.
Nichtoptimierte Bausteine in S7-1500 stören mich überhaupt nicht. Bin eher ein Freund von Einheitlichkeit, also alles nichtoptimiert und gut ;)
In S7-1500 kannst das Pointern nochmal einschränken, da in AWL indizierter variabler Zugriff auf Arrayelemente möglich ist.
Warum man mit S7-1500 sich keine neue Softwarestruktur überlegt hat, kann ja jetzt viele Ursachen haben...
Wichtig ist vor allem, dass es ordentlich funktioniert ;) Und einigermaßen überschaubar strukturiert ist...
 
Zuletzt bearbeitet:
Meckert der die richtige GSD-Version an, oder wie krist das raus?

Ja die fehlenden GSD werden in gelben Warnungen ausgegeben. Sobald man diese eliminiert hat, taucht die CPU dann auch im Projekt auf.

Der Teufel steckt sicherlich irgendwo im Details ;)

Aber nicht doch!
Naja eine andere Möglichkeit war nicht greifbar und jeden Tag ohne fertiges System kostete ja auch eine höhere 5stellige Summe.

Naja, über Programmierstile kann man streiten ;) Ich verwende auch in S7-300/400 schon immer Symboliken, Strukturen und UDTs. Pointern versuche ich zu vermeiden ebenso unsymbolische absolute Adressierung.
Nichtoptimierte Bausteine in S7-1500 stören mich überhaupt nicht. Bin eher ein freund von Einheitlichkeit, also alles nichtoptimiert und gut ;)
In S7-1500 kannst das Pointern nochmal einschränken, da in AWL indizierter variabler Zugriff auf Arrayelemente möglich ist.
Warum man mit S7-1500 sich keine neue Softwarestruktur überlegt hat, kann ja jetzt viele Ursachen haben...
Wichtig ist vor allem, dass es ordentlich funktioniert ;) Und einigermaßen überschaubar strukturiert ist...

Ich denke hier waren es fehlende Zeit und vorgaben der Leitung. Weiterentwicklung kostet Geld, und das war wohl nicht mehr ausreichend vorhanden.

Das Problem an Pointern ist. Vor allem wenn man sie nicht verinnerlicht hat, Fehler zu finden und zu korrigieren. Das ist auch bei indirekten Arrayzugriffen ein Problem. Aber IMHO ein kleineres. Erst recht wenn man ein System im Zugriffsfehlerfall nicht einfach in Stopp befördern kann.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
wie läuft denn die 1500H allgemein so?

Ansich stabil. 5ms Zykluszeit mit nem recht grossen Programm.
Zähe Kommunikation. Da hat man vermutlich Lizenzkosten für Datenpunkte sparen wollen, indem man alles über einen Austauschdatenpunkt schickt. Befehle werden also als String von WinCC OA geschickt, auf der CPU ausgewertet und entsprechend auf einen DP gemappt. umgekehrt für Meldungen isses ähnlich. Diese werden einzeln auf einen DP geschrieben vom WinCC OA quittiert und dann mit der nächsten Meldung versehen.
Ich nehme da den S7+ Treiber von WinCC OA oder OPC und abonniere alle genutzten DP. Aber sind dann halt doch einige tausend Euros an Lizenzkosten. Dafür läufts und man spart sich die Zeit das selbst zu zusammenzuknödeln.
 
aja, diese Datenpunktsparaktionen... Bei ner hochverügbaren Anlage...

Ich hasse diese Aktionen, wo mit 128 WinCC-Variablen ne Monsteranlage gefahren wird... Da blickt irgendwann kein Mensch mehr durch...
 
Zurück
Oben