TIA Profibus nicht erreichbar nach Hardwarekonfiguration einspielen

guten Morgen miteinander =)
das könnte aber an unterschielichen HW Konfigurationen liegen z.B.
Deswegen speziell der Punkt HW Config im projektvergleich mal interessant.

Auch mal ein HW (Alles Übersetzen) probieren.
Die Projekte sind im vergleich in allen Punkten identisch.

Wir kopieren ja einfach das Projekt von Arbeitslaptop auf einen Stick und laden das Projekt vom Stick auf den Servicelaptop und laden dann nur die HW config.

nein das siehste Falsch, da spuckt dir allerweil die Windows Benutzerverwaltung rein.
Mit welchem Account wurde TIA installiert?
Wurde TIA immer nur mit dem Adminaccount gestartet (niemals mit dem normalen)?

Deswegen nochmal ein test mit einem komplett neuen frischen lokalen Adminaccount.

Von der IT kam zurück das wir das normale Benutzerkonto nehmen sollen, damit wir im Netzwerk nichts "kaputt" machen können... IT halt :D

Wir starten das TIA Portal im normalen Benutzerkonto mit "als Administrator ausführen" und melden uns dann mit dem Lokalen Administrator an. Sonst würden wir auch auf keine Projekte zugreifen können usw.

Mal grundsätzlich wieder ein Fall für VMs 😉

Wenn das alles so stimmt, würd ich mal sagen, wenn der Laptop ins Firmennetz geht, werden da Domänenbenutzer angelegt, oder irgendwelche Windowseinstellungen verbogen, oder irgendwelche IT-Tools inst... welche TIA nicht verträgt.

Komisch, dass sich sowas ohne Fehlermeldung nur auf HW-Übersetzen oder HW-Laden auswirken sollte...

Aber wer steckt da im TIA schon drinn 😂

Die Idee mit der VM ist keine schlecht, da ist dann nur die Frage wie wir dann unsere Projekte aus dem Firmennetzwerk bekommen :D

Ich weiß nicht. Profibus hat doch nichts damit zu tun über welche Schnittstelle man die Hardware einspielt.
Die GSD-Dateien kommen ja normalerweise mit dem Projekt, ist das auch so, wenn die schon auf dem Rechner vorhanden sind?
Evtl. stimmt da etwas grundsätzlich nicht und das hat gar nichts mit dem Firmennetz zu tun.

Wir kopieren den gesamten Projektordner und somit sind ja auch die GSDs dabei. Wir haben bisher noch keine GSD Dateien extra auf den Servicelaptop gezogen.

Ich hatte so etwas auch mal.
Mit Notebook A die HW-Config geladen, --> lief .
Projekt von Notebook A mit Stick auf Notebook B übertragen , Hardware von B eingespielt-- > CPU in Stopp.

Grund :
Auf den Notebooks war jeweils eine GSD von PILZ für ein PNOZ-Multi, die zwar den gleichen Namen hatten aber inhaltlich
unterschiedlich waren.
Die von Notebook B passte nicht zur neuen Pnoz-Multi. GSD erneuert --> alles OK.

Unser CPU geht nicht in Stop nur die Verbindung zu den Profibus Teilnehmer ist dann nicht mehr gegeben. Wie oben ja geschrieben haben wir keine anderen GSDs die diesen Fehler herbeiführt.


Ist auf den Laptops exakt dieselbe TIA-Version installiert? Welche Version genau? (wir haben hier schon mehr als 35 Beiträge und das wurde noch nicht geklärt!)
Wird vielleicht ein spezielles Konfigurations-Tool von Festo oder für den Drucksensor benötigt und das fehlt auf den Arbeits-Laptops oder ist eine andere Version?
Sind alle Laptops die gleichen Modelle? Oder ist der Service-Laptop ein anderes Modell? Ist einer ein HP?

Ja es laufen auf allen Laptops die gleiche TIA Version

1677652175173.png

Nein es gibt kein extra Konfigurations-Tool von Festo oder dem Drucksensor lediglich die beiden GSDs die im Projekt hinterlegt sind.

Wenn auf den normalen Arbeits-PC die HW Konfig komplett übersetzt wurde und in die SPS geladen wurde, dann geht die Kommunikation nicht mehr. Jetzt archiviert und kopiert Ihr das TIA-Projekt auf den Service-Laptop und spielt die HW Konfig mit dem direkt in die SPS. Dann geht die Kommunikation wieder? Muß da die Hardware Konfig erneut übersetzt werden? Gibt es bei dem fehlerhaften Laden irgendwelche Meldungen oder Fehler-Anzeigen vom TIA?

Genau so, jetzt laden wir zwar gleich das ganze Projekt direkt mit dem Servicelaptop hoch und nicht erst mit dem Arbeitslaptop aber Änderungen im Programm NICHT in der HWkonfig können wir dann per Arbeitslaptop einspielen.

Meldungen gibt's da keine bei beinen Laptops wird alles ohne Fehler geladen, man merkt es dann erst da die Profibus Geschichte dann nicht mehr funktioniert.

Liegt das TIA-Projekt beim Arbeiten auf einem Server? Wird Multiuser-Engineering verwendet?

Die Projekte liegt als lokale Session auf dem Arbeitslaptop, wir nutzen den Multiuser-Server. Daran kann es aber auch nicht liegen, denn wir haben einen Testaufbau aufgebaut, in diesem Projekt ist die CPU (6ES7 214-1AG31-0XB0) + Profibusmodul (6GK7 243-5DX30-0XE0), Festoinsel (Festo CTEU-PB FEST0D67) und Drucksensor (BCG450-SP) projektiert und kein weiterer Inhalt. Diese Projekt liegt nicht auf dem Multiuser-Server und das funktioniert ja auch nicht.

1677652797224.png

Auch noch nicht erwähnt: Was für ein Gerät genau ist der Profibus-Master?
Mit "Einspielen der Hardwarekonfiguration" ist gemeint, die Gerätekonfig mit TIA in die SPS laden?
Wurde nach dem fehlerhaften Übertragen schon mal die SPS ausgeschaltet und wieder eingeschaltet?

Harald

Profibus-Master ist das Profibus-Modul (6GK7 243-5DX30-0XE0), ja wir haben auch schon mal die CPU gestoppt und gestartet, aus- und wieder eingeschaltet ohne Erfolg

Ich hab das Problem des TE so verstanden:
Er installiert einen Laptop (ohne Firmennetzwerk) neu, kann damit die SPS laden und Profibus funktioniert.
Jetzt steckt er den Laptop erstmalig ans Firmennetz, dabei passiert etwas mysteriöses. Dann geht er mit dem Laptop wieder zur SPS, läd die HW-Konfig nochmal und der Profibus geht nicht mehr...

Kann natürlich sein, dass ganz etwas anderes die Ursache ist und der TE sich gedanklich in ne ganz falsche Richtung verrannt hat...

Vielleicht installiert sich auch beim Anstecken ans Firmennetz nen TIA Update... oder sonstirgendwas...

genau das ist das Problem, wir wissen nicht was passiert wenn der Laptop ans das Firmennetzwerk angeschlossen wird und die IT kann es uns auch nicht sagen. Nun ist die fragen was wird da im Hintergrund eingestellt, umgestellt oder installiert das es nicht mehr geht.

@ducati : das hast du aus meiner Sicht falsch verstanden ...
Nicht das Anstecken an das Firmen-Netzwerk erzeugt das Problem sondern das im Firmen-Netzwerk abgemeldet sein - das ist ein Unterschied ...
In dem Moment, wo du an einem Netzwerk angemeldet bist, bezieht dein Rechner unter Umständen aus dem Netzwerk komplett neue Einstellungen für alles mögliche - in aller Regel hat es eigentlich immer mit Berechtigungen (oder besser gesagt Beschränkungen) zu tun. Auf diese Weise kann im Grunde wirklich alles, was du irgendwie in der Systemsteuerung oder dem Geräte-Manager einstellen kannst, umgestellt werden.

Ich denke schon das er es richtig verstanden hat. Es reicht das bloße anstecken an das Firmennetzwerk, wir sind als Benutzer oder sogar am Servicelaptop als Admin angemeldet stecken das Lan-Kabel an was zum Firmennetzwerk geht und schon haben wir das Problem, dass die HW nicht mehr zu laden geht.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Wir kopieren den gesamten Projektordner und somit sind ja auch die GSDs dabei. Wir haben bisher noch keine GSD Dateien extra auf den Servicelaptop gezogen.
Das siehst du falsch, die GSD wird nur mit genommen und auf den anderen Rechner übertragen wenn sie da nicht vorhanden war.
Ansonsten wird die auf dem Rechner vorhandene GSD genommen .
Siehe mein Beitrag #35.
 
kannst du mal einen Screenshot machen vom Vergleich?
Und auch mal einen Diagnosepufferabzug nach dem laden der HW vom Arbeitslaptop, wenn der Fehler ansteht?
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Die Idee mit der VM ist keine schlecht, da ist dann nur die Frage wie wir dann unsere Projekte aus dem Firmennetzwerk bekommen :D

Geht meiner Meinung nach am saubersten, wenn ihr die Archive und die Projektarbeitsverzeichnisse auf der richtigen Maschine lasst und in der VM einen gemeinsamen Ordner einrichtet.

Code:
z.B.
c:\Daten                              gemeinsamer Ordner
c:\Daten\Projekte_Kunden            Archive und zusätzliche Informationen z.B.
c:\Daten\Projekte_Kunden\Kunde_A\Projekt_1\SPS
c:\Daten\Projekte_Kunden\Kunde_A\Projekt_1\Info
c:\Daten\ProgramData\TIA            Arbeitsverzeichnisse TIA z.B.
c:\Daten\ProgramData\TIA\Projekt_1
c:\Daten\ProgramData\Step7            Arbeitsverzeichnisse S7-classic

Das hat verschiedene Vorteile:
  • VM bläht sich nicht unnötig auf
  • SPS Daten sind noch vorhanden wenn VM auf älteren Stand gesetzt wird
  • man kommt auch ohne VM an die Daten
 
Hallo Leute, danke für die vielen Beiträge ich bin derzeit an allen Infos zusammen zu sammeln und Berichte dann hier weiter!

Nicht das Ihr denkt ich antworte nicht mehr :D
 
Zuviel Werbung?
-> Hier kostenlos registrieren
guten Morgen!

Also ich habe gestern den ganzen Tag mit unserem Testplatz tausende versuche gemacht und wohl den Fehler gefunden! Leider hat sich Siemens noch nicht gemeldet sonst hätte ich das Problem mal mit diesem besprochen.

So nun zur Lösung ;)

Ich hatte so etwas auch mal.
Mit Notebook A die HW-Config geladen, --> lief .
Projekt von Notebook A mit Stick auf Notebook B übertragen , Hardware von B eingespielt-- > CPU in Stopp.

Grund :
Auf den Notebooks war jeweils eine GSD von PILZ für ein PNOZ-Multi, die zwar den gleichen Namen hatten aber inhaltlich
unterschiedlich waren.
Die von Notebook B passte nicht zur neuen Pnoz-Multi. GSD erneuert --> alles OK.
Da mein Kollege das Thema GSD bereits ausgeschlossen hatte, hatte ich zu diesem Beitrag ja geschrieben das es daran nicht liegt. ABER jetzt kommt der Clou! Ich habe einfach mal alle GSD Dateien aus dem Testprojekt gelöscht und mir die GSD neu auf den Firmenseiten gezogen und installiert, siehe da Laptop mit Firmennetz funktioniert Servicelaptop funktioniert das auch mit mehrere Laptops ausprobiert ohne Probleme.

Wenn es mal nicht funktioniert hat, habe ich die GSD gelöscht und einfach die "neue" installiert danach lief es!

Da die GSD Dateien ja im Projekt mit liegen und wenn diese nicht installiert sind, installiert TIA diese ja dann automatisch. Konnten wir uns das nicht erklären, bis der eine Kollege nun sagte "naja bei mir steht in den Projekten unter Kataloginformation der Festo nicht fest0d67.gsd sondern fest0d67.gse".

Daher habe ich nun getestet was ist wenn man im Projekt die .GSE statt .GSD installiert und damit Projektiert! und ja unser Fehler tritt wieder auf!

Warum jetzt bei dem einen Kollegen (der schon länger da ist!) diese GSE Datei hat wissen wir nicht. Das würde ich gerne nun mal mit Siemens abklären.
 
Das war früher noch viel schlimmer, da haben Firmen die Hardware geändert, die GSD angepasst aber den selben Namen
für die Datei belassen. Dann kam es zu solchen Problemen.
Siemens kann da nichts dafür. Ausnahmsweise.

Ergänzung:

"Da die GSD Dateien ja im Projekt mit liegen und wenn diese nicht installiert sind, installiert TIA diese ja dann automatisch. Konnten wir uns das nicht erklären, bis der eine Kollege nun sagte "naja bei mir steht in den Projekten unter Kataloginformation der Festo nicht fest0d67.gsd sondern fest0d67.gse"."


Siehe meinen Beitrag #46
 
Zuletzt bearbeitet:
Die unterschiedlichen Versionen der installierten GSD-Dateien wirken sich aber nur aus, wenn die Hardware Konfig vor dem einspielen erneut übersetzt wird. Meine diesbezügliche Frage vor 3 Tagen wurde leider nicht beantwortet, sonst wäre man vielleicht schon früher drauf gekommen, daß die Hardware auf den verschiedenen PC unterschiedlich übersetzt wird (und es gar nicht am Netzwerk liegt).

Jetzt archiviert und kopiert Ihr das TIA-Projekt auf den Service-Laptop und spielt die HW Konfig mit dem direkt in die SPS. (...) Muß da die Hardware Konfig erneut übersetzt werden?

Harald
 
Die unterschiedlichen Versionen der installierten GSD-Dateien wirken sich aber nur aus, wenn die Hardware Konfig vor dem einspielen erneut übersetzt wird. Meine diesbezügliche Frage vor 3 Tagen wurde leider nicht beantwortet, sonst wäre man vielleicht schon früher drauf gekommen, daß die Hardware auf den verschiedenen PC unterschiedlich übersetzt wird (und es gar nicht am Netzwerk liegt).



Harald
Sorry das habe ich dann wohl übersehen! Wir haben es dann immer so gemacht das wir auf die CPU geklickt haben und dann Laden in Gerät -> Hardwarekonfiguration angeklickt haben. Wird dadurch die HW neu übersetzt, ich dache nicht. =)

Richtig. Ich würd die beiden Dateien mal vergelichen. Möglichst mit dem GSD-Editor.
Im Vergleich sind Revision Nr. z.B. unterschiedlich aber noch viele andere Punkte. Versucht man eine der beiden über die vorhandene GS Datei zu installieren, sagt TIA bereits das es unterschiede gibt und löscht die andere Datei.

-----------------

Komischerweise haben wir aber jetzt das Phänomen das beide GS Dateien installiert werden also GSD und GSE wenn man das Projekt öffnet! Ist ein ganz komisches Ding bei uns wohl... Da werde ich mich wohl hinsetzten müssen und alle Projekte kontrollieren welche GSD Datei genutzt wurde! Da der "alte" Kollege alle GS Datei (GSD, GSE, GSF) installiert hatte und wir nun nicht wissen welche GS Datei das Projekt nutzt :(
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Da es mich interessiert hat, habe ich mal einen Versuchsaufbau gemacht:

S7-300 <= Profibus => ASM456 Moby Firmware 3.0 <=> RF685R Reader

Zusatzinfo:
Der ASM456 läuft mit der V3.0 nicht mit der GSD V4.0. Da kommt dann kein "Soll<=>Ist ungleich" sondern "Teilnehmer nicht erreichbar".

Versuchsaufbau: TIA V16, CPU315-2EH14, ASM456 V3.0 montiert und GSD V3.0 installiert:

>> Alles projektiert, Projekt auf CPU geladen, ASM456 läuft ohne Fehler an, Reader kann angesprochen werden.
>> Nun die GSD V4.0 installiert ( nur installiert, nichts übersetzt ).
>> Projekt noch mal geladen, alles geht.
>> Jetzt Hardware einmal übersetzt und Projekt geladen => Teilnehmer ist nicht erreichbar.
>> Jetzt TIA geschlossen, nicht gespeichert, wieder geöffnet, geladen => funktioniert alles wieder.

Soweit so gut, aber:
Speichere ich das Projekt nun per "Speichern unter" von Testprojekt1 auf Testprojekt2 und klicke dann auf Laden ( also ich habe nicht übersetzen angewählt ) => Teilnehmer wird nicht mehr erkannt.

D.h. nachdem ein Projekt unter einem anderen Namen gespeichert wurde, wird alles übersetzt. Mindestens mal die HW-Konfig. Warum auch immer.

Ich mache Montag mal Versuche, ob das auch so ist, wenn man archiviert/dearchiviert und berichte dann.


Fazit:
Der TE hat vermutlich oder vielleicht die Hardware auf den anderen Rechnern gar nicht übersetzt sondern TIA selbst automatisch.
 
Zurück
Oben