Hallo in die Runde,

wir stehen gerade auf dem Schlauch und kommen nicht weiter.

Änderungen in der Unternehmens-IT gaben vor, dass wir den IP-Adressbereich unseres Prozessbusses wechseln mussten.
Nicht schön, aber machbar.

Unser Vorgehen war folgendes:
0. In der Netzwerkkarte der ES als zweite IP eine IP im neuen Adressbereich hinterlegt
1. im Offline-Projekt alle IPs der ASn und Teilnehmer im Prozessbus angepasst
2. Nacheinander Netpro übersetzt, alle Stationen im Stop geladen
3. Netpro der Server-Paare auch übersetzt und geladen
4. IP der Netzwerkkarte der Server angepasst
5. Netpro des ES-Projekts übersetzt + geladen
6. Die IP der ES auf die neue IP geändert und die zweite IP aus der Netzwerkkarte entfernt.
7. alles einmal sauber rebootet

Bis Punkt 5. funktioniert alles.
Prinzipiell läuft und funktioniert auch alles.
Jedoch hängt sich der Simatic-Manager nun auf, sobald man das Server-Projekt übersetzen will.
Der Übersetzen-Assistent öffnet nicht, stattdessen sieht man für sehr lange Zeit eine Sanduhr.

Wenn man dann die alte IP wieder als zweite IP in der Netzwerkkarte des Prozessbus auf der ES hinterlegt, dauert es 5-10s und der Assistent zum übersetzen ploppt auf.
(Das kann man sogar tun, während sich der Simatic-Manager gerade "tot lädt" um den Assistenten zu öffnen)
Man kann nun auch übersetzen und anschließend die Server laden -> funktioniert alles einwandfrei, solange die alte IP zusätzlich in der Netzwerkkarte hinterlegt ist.
Nimmt man sie wieder raus, reproduziert sich das Problem

Irgendwas haben wir wohl vergessen und wir kommen nicht drauf was.

Auch ist nicht nachvollziehbar, wieso dieses Phänomen eindeutig mit der IP zusammenhängt, denn das Übersetzen funktioniert üblicherweise auch, wenn man komplett offline ist und/oder die ES gar keine IP im Prozessbus hat
(getestet mit dem gleichen Projekt in einer Test-VM, in der ich alle Netzwerkkarten entfernt habe)

Hat jemand eine Idee, wo man hier noch ansetzen könnte oder weiß spontan, was wir vergessen haben könnten?

(In der Shell sind alle Teilnehmer mit korrekter (neuer) IP sichtbar, pingen lassen sich auch alle Teilnehmer, wenn nur noch die neue ES-IP eingetragen ist)

Danke vorweg und Grüße

[EDIT]

Das scheint wohl mit dem Simatic-Manager per se zusammen zu hängen.
Das gleiche Projekt auf einer anderen ES lässt sich problemlos übersetzen.

Ebenso funktioniert alles, wenn man über "AS-OS-Engineering" das Übersetzen anstößt 

weitere erfolglose Versuche:

- (vorher einen Snapshot der VM gemacht und angefangen zu "spielen")

- SimaticManager neu installiert (SIMATIC_STEP7_V56_SP2_HF3) -> kein Unterschied

- "\HKEY_CURRENT_USER\Software\SIEMENS\STEP7\2.0" gelöscht (enthält Einstellungen vom SimaticManager und wird neu erstellt, wenn nicht vorhanden) -> kein Unterschied

- alle Netzwerkkarten deaktiviert -> kein Unterschied

- Prozessbus-Netzwerkkarte komplett gelöscht -> kein Unterschied

- Neue Prozessbus-Netzwerkkarte angelegt -> kein Unterschied

- Projekt-Ordner komplett geleert und das letzte Archiv, welches sich auf anderen ESn problemlos auch komplett ohne Netzwerkanbindung übersetzen lässt (gemeint ist das Übersetzen des OS-Servers zum Erzeugen der WinCC-Variablen) -> kein Erfolg

- Registry nach der alten Prozessbus-IP der ES (192.168.10.100) durchsucht und zwei Netzwerkkarten-Einträge gelöscht -> kein Unterschied

- Versucht irgendwelche anderen Projekte und alte Backups zu übersetzen -> kein Unterschied.

- zwischendurch natürlich immer wieder mal neu gebootet, wo es Sinn machte.

Weitere Erkenntnisse:

- es ist egal, in welcher Netzwerkkarte ich die alte IP eintrage, es genügt auch, wenn ich die irgendwo nur als zweite IP eintrage -> sobald die IP irgendwo drin steht, öffnet sich der Übersetzen-Assistent

- Es muss explizit die 192.168.10.100 sein, die dem Prozessbus der ES vorher zugeteilt war - eine andere IP im gleichen Subnet (z.B. 192.168.10.101) funktioniert auch nicht

- Seltsamerweise funktioniert alles auch ohne die alte IP, wenn man direkt das AS-OS-Engineering öffnet und damit übersetzt.

Irgendwo hängt hier eine hartnäckige Leiche in den Einstellungen oder der SQL-Datenbank, die wohl in der Schnittstelle zwischen Simatic-Manager und AS-OS-Engineering abgefragt wird.
Erklären kann ich mir das nicht, da man natürlich mit DNS-Namen und named connections arbeitet.

Bleiben mir/uns wohl nur zwei Optionen

- ES neue aufsetzen oder auf den Siemens-Support hoffen...was wohl wie gewohnt langwierig und teuer wird.
Oder als unschöne Notlösung damit leben, dass die alte IP einfach irgendwo als zweite IP eingetragen ist

Falls doch noch jemand eine Idee hat, bin ich für jeden Vorschlag dankbar.

HI MarHar,

eine wirkliche Lösung habe ich nicht, aber mögliche Idee was vielleicht helfen kann.

Einmal könntest du mal versuchen das Projekt mit Speicher unter und der Option Reorganisieren neu abzuspeichern, denn mit der Option wird das Projekt komplett neu erzeugt. Leider wird dadurch auch einen Gesamtladen notwendig.

Kannst du mal unter "Extras > PG/PC-Schnittstelle einstellen..." gucken ob da noch irgendwo die Netzwerkkarte mit der alten Adresse auftaucht?

Und falls du als PG/PC-Schnittstelle "PC internal local" verwendest hast du auch die ES neu konfiguriert?

Schöne Grüße
Heisenberg

Hallo Heisenberg2,

danke für deine Anregung!

- Reorganisieren werde ich gleich mal mit einem Backup testen.
Hier mache ich mir wenig Hoffnung, da das Projekt selbst ja in einer anderen ES-VM übersetzbar bleibt (aber man weiß ja nie)

- in den PG/PC-Einstellungen habe ich tatsächlich auch schon geguckt und gesucht, weil das Problem genau hier gut reinpassen könnte.
Verwendet wird in der Tat die "PC internal local" Schnittstelle. dort in den Einstellungen sind auch nach wie vor alle Netzwerkkarten drin.
Die IP wurde über die Windows-Einstellungen geändert und weiterhin im NetPro der "PC-Station" der ES im Multiprojekt bzw. im "IE Allgemein"-Objekt. anschließend wurde das Netpro nochmal auf die ES geladen.

Ich vermute genau hier könnten wir irgendwas vergessen haben.
Was konkret meinst du mit "hast du auch die ES neu konfiguriert?"?

Viele Grüße
MarHar

Leider brachte das Speichern unter mit Reorganisation (langsam) keinen Erfolg.

Die ES habe ich erneut konfiguriert bzw. die Einstellungen kontrolliert, übersetzt und geladen -> auch leider ohne Erfolg.

Kurios bleibt weiterhin: Ich kann alle AS online sehen, ich kann im CFC online gehen und sehe online-Werte, im Shell ist alles verfügbar und im Komponenten-Konfigurator wird auch alles offensichtlich korrekt angezeigt.

(Und zum Glück funktioniert offensichtlich alles weiterhin - bis auf's Übersetzen
selbst wenn ich die Server lade, läuft alles weiter)

Mir erscheint an dem Vorgehen auch grundlegend nichts verkehrt - genau darum wird doch mit Computernamen statt festen IPs gearbeitet.

Den Windows-DNS-Cache habe ich spaßeshalber auch mal geleert (ipconfig /flushdns)

Auch habe ich mal Wireshark installiert und kontrolliert, ob überhaupt was durch das alte, tote Subnet funkt -> kein einziges Paket nach der Broadcast-Anmeldung der Netzwerkkarte
Ebenso habe ich das komplette Subnet angepingt -> kein einziger Teilnehmer mehr erreichbar.

Mittlerweile habe ich eine Dummy-Netzwerkkarte angelegt (dank VM kein Problem) und dieser die alte IP gegeben - das macht das Triggern des Problems einfacher als jedes mal die komplette IP mit in die Prozessbus-Netzwerkkarte einzutragen.

Bzgl. des AS-OS-Engineering-Tool habe ich folgendes feststellen können.

1. NW-Karte deaktiviert -> AS-OS-Eng. öffnen -> übersetzen
-> lädt sich tot
2. NW-Karte während des Ladens aktiviert
-> 20s Später ploppt der Wizard auf
3. Abbruch
4. NW-Karte wieder deaktiviert -> übersetzen neu angestoßen
-> Wizard öffnet sich trotz deaktivierter NW-Karte

Bei der Ersten Verbindung zum Wizzard prüft der also auch noch irgendwo die alte IP

hmpfs...bei der Änderung des Computernamens könnte ich noch nachvollziehen, dass hier irgendwas zickt - bei einer simplen IP hätte ich das nicht erwartet.

Ich würd's echt ungern vermeiden die komplette ES neu aufsetzen zu müssen - das gibt nur wieder neue Probleme.

Was passiert eigentlich wenn du nicht die PG/PC-Schnittstelle "PC internal local" verwendest sondern die direkt zu weißt? Hast du dann auch den Fehler oder nicht mehr?

Aber eigentlich ist das sehr seltsam, da ich schon öfter die IP-Adresse bei der ES umgestellt habe und nie wirklich Probleme hatte. Erst recht nicht so spezifische wie du sie beschreibst. 

Da habe ich allerhand Auswahlmöglichkeiten:

Wobei ich jetzt doch etwas ins Grübeln komme...

Müsst die ES sich selbst nicht unter Rechtsklick -> Zielsystem -> Konfigurieren sehen können?
Das oben ist die Vorwahl ...  wäre nachvollziehbar, wenn sie dort nicht drin ist, weil sie unten schon eingetragen ist.
Interessanter ist, wieso sie sich selbst unten als "Zielrechner ist nicht verfügbar" beschreibt und bei den anderen Stationen nicht in der Vorwahl auftaucht.
Hierdran ändert sich auch nichts, wenn ich die dummy-NW-Karte aktiviere oder deaktiviere.

(siehe Anhang)

Wenn ich den Haken "Projektierten Rechnernamen verwenden" entferne, kann ich sie konfigurieren und danach auch laden - das läuft augenscheinlich auch sauber durch.

Ich habe nun (bei deaktivierter dummy-Netzwerkkarte) beide ES und alle 6 Server nochmal "konfiguriert" und geladen.
> ändert nichts am Übersetzungs-Assistent-Phänomen.

Für die Nachwelt: 
Vom Support kam heute der freundliche und entscheidende Hinweis:

unknown user

1. Simatic Manager schließen
2. Löschen aller asasrv.ini im Projektpfad
3. Löschen aller asasrv.ini im Installationsverzeichnis auf LW C
4. Start des Simatic Managers.
Beim Öffnen des Projektes wird die asasrv.ini automatisch systemseitig neu angelegt. Sie enthält dann nur den aktuellen Eintrag bezüglich Netzwerkkarte und ähnlichem.

Ganz so einfach hat's bei uns nicht geklappt -> nach dem Löschen der 146 asasrv.ini Dateien wurden bei Neustart keine neuen erzeugt und nichts ging mehr.
Also alle Dateien aus dem Papierkorb wiederhergestellt und dann Datei für Datei durchgegangen.
In rund 60 Dateien war noch die alte IP drin -> diese haben wir auf die neue IP geupdatet und voila - nun funktioniert auch alles ohne dummy-Netzwerkkarte.

auch wurde beigefügt:

unknown user

dass dies keine "offizielle" Lösung ist, lediglich ein Trick welcher sich hier beim TS bewährt hat.

 Nun wird noch geklärt, wieso die Dateien bei uns nicht automatisch neu erstellt werden (ist für uns in der Test-VM reproduzierbar) - aber solange nun alles funktioniert, geben wir uns damit zufrieden.
Irgendwann werden wir sowieso auf V9.1, V10 oder neo upgraden müssen, dann kommt sowieso mal wieder alles komplett neu 

Viele Grüße
MarHar