TIA Problem bei Aufbau der I-Device-Kommunikation

Berako

Level-2
Beiträge
37
Reaktionspunkte
3
Zuviel Werbung?
-> Hier kostenlos registrieren
Guten Morgen in die Runde,
Ich bekomme die Kommunikation einer CPU S7-1512C-1 PN und einer CPU1510SP-1 PN nicht hin.
Die 1510SP-1 ist das I-Device von einem Zulieferer das ich mit einer mitgelieferten GSD-Datei eingebunden habe.
Diese Datei zeigte einen Fehler bei importieren in TIA an und so habe mir selber diese Steuerung in TIA nachgebildet und die GSD-Datei
dort exportiert und in meinem Projekt importiert. Soweit so gut. Ich sehe die Steuerung mit der korrekten IP-Adresse unter den Online-Zugang.
Doch auf meiner Seite im Projekt wird die Steuerung als nicht erreichbar angezeigt und auf der CPU1510SP-1 blinkt die rote "ER"-LED.
In der Diagnose auf meiner CPU wird die Fehlermeldung "Ausfall einer IO-Device - nicht unterstützte Geräteversion" angezeigt. Ich hänge mal
ein paar Screenshots an. Hat jemand von Euch eine Ahnung was das sein könnte?
 

Anhänge

  • Screenshot_1.png
    Screenshot_1.png
    79,4 KB · Aufrufe: 41
  • Screenshot_2.png
    Screenshot_2.png
    391,1 KB · Aufrufe: 42
  • Screenshot_3.png
    Screenshot_3.png
    86,3 KB · Aufrufe: 43
  • Screenshot_4.png
    Screenshot_4.png
    290,6 KB · Aufrufe: 42
  • Screenshot_5.png
    Screenshot_5.png
    65,1 KB · Aufrufe: 42
  • Screenshot_6.png
    Screenshot_6.png
    382,3 KB · Aufrufe: 40
Ich glaube nicht, dass Du die Partner-CPU bei I-Device "mal so einfach" nachbauen kannst.
Die mitgelieferte GSDML kriegst Du definitiv nicht ans laufen? Was ist hier die Fehlermeldung?
Wenn es nicht geht würde ich beim Zulieferer mal nachhaken und eine passende Datei nachfordern!
 
Ich habe der Screenshot und die Protokolldatei mal angehangen. Der Zulieferer hat mir gerade eine neu generierte GSD-Datei zugeschickt. Die verhält sich genauso, also mit der gleichen Fehlermeldung.
 

Anhänge

  • GSD-Import Protokoll.txt
    438 Bytes · Aufrufe: 15
  • Screenshot_1.png
    Screenshot_1.png
    91,8 KB · Aufrufe: 31
gsdml-v2#siemens-preconf_plc_1-20220729-165645.xml
:General GSD Error: Check-Number: 0x00001002_3,Message: Die geeignete Checker-Version konnte nicht gefunden werden. Beachten Sie, dass die GSD-Datei nicht geprüft wird.,Line: 0,XPath: ,
:General GSD Error: Check-Number: 0x00001002_1,Message: Checker couldn´t check Gsd file ('c:\users\bernd\desktop\gsdml-v2#siemens-preconf_plc_1-20220729-165645.xml') correctly!,Line: 0,XPath: ,
 
Jetzt mal eine ganz blöde Frage, warum nimmst Du denn die 1510SP nicht einfach aus dem Hardware-Katalog?
Befinden sich die CPUs im gleichen Projekt oder in getrennten Projekten?

Wenn sie sich im gleichen Projekt befinden, dann ist das Hinzufügen aus dem Hardwarekatalog die einfachste Lösung. Einfach ins Projekt hinzufügen, iDevice bei der 1510SP aktivieren, iDevice-Contoller bestimmen (1512C), Transferbereiche festlegen. Und GAAAAAANZ wichtig, die Hardware beider CPUs komplett übersetzen und anschließend alles neu in die jeweiligen CPUs laden. Ich denke das hast Du vergessen…

Befinden sich die CPUs in zwei getrennten Projekten, dann musst Du ein wenig tricksen. Gehe in das Projekt der 1510SP, füge dort aus dem Hardwarekatalog die 1512C hinzu. Aktiviere bei der 1510SP iDevice, weise sie einem Controller zu (1512C), lege die Transferbereiche fest. Anschließend löschst Du die 1512C wieder aus deinem Projekt. Nur die CPU löschen, sonst nichts verändern. Hardware komplett übersetzen. Anschließend erstellst Du eine GSD-Datei.
Diese GSD-Datei importierst Du nun ins Projekt der 1512C. Alles konfigurieren, Hardware der 1512C komplett übersetzen und alles in die CPU laden. Fertig!

Und dann sollte auch alles ohne Probleme funktionieren.
 
Also für I-Device habe ich noch nie zwangsweise beide CPUs in einem Projekt benötigt.
Alle Kombinationen durch.
Auch TIA <-> Classic
S7-1x00 <-> S7-1x00
S7-1x00 <-> S7-300
S7-300 <-> S7-300

Die GSDML muss man halt richtig generieren.

Außerdem kann @Berako schlecht die Hardware einer fremden CPU überspielen.
Bitte immer an die Nachvollziehbarkeit denken. Wer soll sich in 10 Jahren mit so einem Kuddel-Muddel noch auskennen. Bei einer HW-Änderung geht auf einmal nichts mehr...
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Also für I-Device habe ich noch nie zwangsweise beide CPUs in einem Projekt benötigt.
Alle Kombinationen durch.
Auch TIA <-> Classic
S7-1x00 <-> S7-1x00
S7-1x00 <-> S7-300
S7-300 <-> S7-300

Die GSDML muss man halt richtig generieren.

Außerdem kann @Berako schlecht die Hardware einer fremden CPU überspielen.
Bitte immer an die Nachvollziehbarkeit denken. Wer soll sich in 10 Jahren mit so einem Kuddel-Muddel noch auskennen. Bei einer HW-Änderung geht auf einmal nichts mehr...

Da hast Du Recht, ich habe überlesen, dass die 1510SP eine „Fremd-CPU“ ist. Dann hat man auf diese natürlich keine Zugriff und kann entsprechend auch nichts ändern.
Dann musst Du Dich drauf verlassen, dass die GSD-Datei vom Hersteller richtig konfiguriert ist.
Wichtig ist immer das Übersetzen der Hardware, sonst geht gar nichts.
 
Wir haben ein Teil unserer Anlage zugekauft und dieser Part mit dieser CPU ist mit in unseren Schaltschrank auf einer Tafel verbaut. In der CPU ist deren Know-how integriert und das alles ist Passwort geschützt, ich habe da keinen Zugriff drauf.
 
Der Profinet-Gerätename muss vermutlich auch stimmen.
Aber muss es denn unbedingt Profinet sein? Zwischen SPSn ist man m.E. mit S7-Kommunikation flexibler.
Da hast Du Recht! Gerade bei größeren Datenpaketen ist Put/Get bzw. OUC wesentlich besser, flexibler und übersichtlicher. Allerdings muss auch in den jeweiligen Projekten mehr herumgewurstelt werden. Die Frage ist daher auch in welchem Umfang die beiden CPUs miteinander sprechen müssen.
 
Ich wollte Euch mal über das Ergebnis informieren.
Wir haben es mehrfach probiert die bei mir fehlerhafte GSD-Datei zu importieren. Ich habe TIA V16 UPD6. Führte nicht zum Erfolg.
Es an einem zweiten Rechner TIA V16 UPD5 probiert, das gleich Ergebnis. Dann habe ich mein gesamtes Projekt dem Zulieferer
geschickt. Er importierte es auf seinem Rechner und fügte es ein, er hat TIA V16 UPD3, alles kein Problem, schickte es mir zurück
und ich spielte die Hardeware-Konifig ein. Dann lief alles. Also gibt es anscheinend Probleme dabei bei unterschiedlichen TIA-Ständen. 🤷‍♂️🤦‍♂️😂
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Also für I-Device habe ich noch nie zwangsweise beide CPUs in einem Projekt benötigt.
Alle Kombinationen durch.
Auch TIA <-> Classic
S7-1x00 <-> S7-1x00
S7-1x00 <-> S7-300
S7-300 <-> S7-300

Die GSDML muss man halt richtig generieren.

Außerdem kann @Berako schlecht die Hardware einer fremden CPU überspielen.
Bitte immer an die Nachvollziehbarkeit denken. Wer soll sich in 10 Jahren mit so einem Kuddel-Muddel noch auskennen. Bei einer HW-Änderung geht auf einmal nichts mehr...
Bei F-I-Device gehts zB nicht ohne beide im Projekt
 
Guten Abend,
Ich kenne das Problem auch, dass die Fremd GSD mit einer aktuelleren Version erzeugt worden ist. Ich konnte bisher mir die GSD File meist selbst "nachbauen". Dafür habe ich einfach eine neue CPU in einem Projekt erzeugt in der das I Device aktiv ist. Dann die Transferbereiche eingestellt (können aus der GSDML einfach per Texteditor gelesen werden) und diese File dann exportiert und in meinem Projekt mit IO Controller importiert. Solange PN Name, IP Adresse und die Bereichen stimmen hat das immer gut geklappt. Meiner Meinung nach geht auch I Device F Kommunikation ohne Device CPU im Gleichen Projekt.

Grüße
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ich hatte so etwas ähnliches auch mal. Da stimmte der Name der GSDML-Datei nicht mit den internen Vorgaben überein.
Mal den Namen auf GSDML-V2.35-#SIEMENS..... ändern bzw. einfach nur einen Bindestrich vor der Raute ergänzen, das war es damals bei mir.
 
Zurück
Oben