TIA Firmware passt nicht ????? Oh mann...

Tmbiz

Level-2
Beiträge
583
Reaktionspunkte
15
Zuviel Werbung?
-> Hier kostenlos registrieren
Hey, ich habe hier eine CPU 511-1ck01-0ab0 V2.5 aber die kann ich im Hardwarekatalog in TIA 14 nicht finden. Dann habe ich versucht eine Update zu machen aber auch das ging nicht. Siemens meinte, dass die Version nur unter TIA 15 geht. Ich könnte aber die CPU auf eine andere Version runtersetzen. Aber wie geht das?

Wie kann ich die genannte CPU mit TIA 14 SP Update2 Step7 Version14 SP1 Update 2 Projektieren?
 
Du kannst die CPU prinzipiell auch mit einer älteren Firmware in TIA V14 projektieren und die "zu neue" CPU damit in betrieb nehmen. TIA weisst dich zwar darauf hin, dass die Firmware unterschiedlich ist, aber es funktioniert trotzdem.
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
Moin,
Ich hatte das Problem das ich eine CPU1214C V4.2 6ES7214-1AG40-0XB0 habe und TIA V13 nur bis V4.1 geht. Beim übertragen merkte TIA zwar das die projektierte CPU nicht mit der verbauten übereinstimmt aber die Übertragung lief trotzdem durch und das Programm läuft, das inzwischen auf drei Anlagen.

Sofern die vordere Zahl passt einfach mal ausprobieren. ;)
 
Siemens meinte, dass die Version nur unter TIA 15 geht. Ich könnte aber die CPU auf eine andere Version runtersetzen. Aber wie geht das?

Firmwareupdate auf ne niedrigere Version... aber wie schon geschrieben, kannst auch die Version so lassen und die Meldung ignorieren, falls der Kunde das nicht bemängelt...

gruß.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Mal unabhängig davon, dass man diese CPU sowieso nicht runterrüsten kann. Wenn man sich durchliest, was in den FW-Ständen alles behoben wurde, würde es wohl grundsätzlich Sinn machen,
mit der Warnung zu leben anstatt die FW falls es möglich ist, runter zu rüsten.

Hier mal ein Auszug der FW´s


Folgendes Verhalten wurde mit der FW 2.1 geändert:


  • Peripheriedirektzugriffe, die als Eingangsparameter an Bausteinen verschaltet sind, führen beim Auftreten eines Peripheriezugriffsfehlers nicht mehr dazu, dass der Baustein nicht mehr durchlaufen wird. Stattdessen wird mit dem Ersatzwert des Signals im Baustein gearbeitet.
Folgendes Verhalten wurde mit FW 2.1 überarbeitet:

  • Beim online Beobachten eines Bausteins kommt es nicht mehr zum STOP der CPU aufgrund von Bereichslängenfehlern.
  • Bei der Generierung von Alarmtexten mithilfe des Bausteins „Get_Alarm“ wurde das Verhalten in Bezug auf Alarmtexte verbessert.
  • Bei dem Baustein „Get_Alarm“ kommt es nicht mehr zu der Statusmeldung „W#16#8003 – der Parameter Lcid ist ungültig oder eine am Parameter Lcid gewählte Sprache ist nicht geladen“, wenn beim Datentyp „Alarm_Data“ der Parameter „InfoText“ leer ist.
  • Das Verhalten der Anweisung „Get_Alarm“ wurde bezüglich des Aufrufs aus mehreren OB-Prioritäten heraus verbessert.
  • Das Verhalten der Anweisung „STP“, während gleichzeitig über das TIA Portal „online beobachten“ durchgeführt wird, wurde verbessert.
  • Das Verhalten beim Download von Datalogs über den Webserver der CPU wurde verbessert.
  • Es kommt beim „online beobachten“ von Bausteinen nicht mehr zu dem Verhalten, dass beim Scrollen das TIA Portal einfriert, wenn dieser Baustein aus mehreren OBs mit unterschiedlicher Priorität aufgerufen wird.
  • Das Startverhalten des OPC UA Servers insbesondere bei großen Datenmengen wurde verbessert.
Folgendes Verhalten wurde mit FW 2.1 behoben:


  • Die CPU geht nicht mehr in STOP, wenn große Strukturen mit der Anweisung „MOV_BLK_VARIANT“ kopiert werden.
  • Folgende sporadischen Meldung: “Schwerwiegender Firmware-Ausnahmefehler (nicht anwenderrelevanter Systemcode: 16#00000000 16#10020000 16#00000000)“ tritt nicht mehr auf, wenn eine große Anzahl von Diagnose-Ereignissen über AS-i gemeldet werden.

oder

Folgendes Verhalten wurde mit FW 2.0.5 überarbeitet:

  • Kommt es beim online Beobachten eines Bausteins zur Meldung (0604:000255) „Es stehen nicht genügend Ressourcen für die Funktion „Beobachten“ zur Verfügung“ , so ist die CPU weiterhin erreichbar, sobald wieder genügend Ressourcen zur Verfügung stehen.
  • Die Funktion des SPLIT Befehls im Zusammenhang mit Strukturen mit zwei oder mehr Unterstrukturen wurde verbessert.
  • Wird in zwei OBs mit unterschiedlichen Prioritäten der Befehl DPWR_DAT oder DPRD_DAT verwendet so kommt es nicht mehr hochsporadisch zu inkonsistenten Datenablagen durch den verwendeten Befehl im niederprioren OB.
  • Wenn die CPU bei Motion Control Anwendungen sehr stark ausgelastet wird, kann es zum CPU STOP durch einen Überlauf von MC-Interpolator (OB92) bzw. MC-Servo (OB91) kommen.
    Bei anschließendem CPU RUN kommt es nicht mehr sporadisch zur unkontrollierten Achsbewegungen.

usw.
 
Zuletzt bearbeitet:
Mal unabhängig davon, dass man diese CPU sowieso nicht runterrüsten kann. Wenn man sich durchliest, was in den FW-Ständen alles behoben wurde, würde es wohl grundsätzlich Sinn machen,
mit der Warnung zu leben anstatt die FW falls es möglich ist, runter zu rüsten.

Wie ist das? Wenn man die Firmware hochrüstet aber aus Kompatiblitätsgründen (man kann z.B. nur mit V13 arbeiten nicht mit V15) in der Software mit einer alten Firmware arbeitet. Profitiert man dann trotzdem von der neuen Firmware was die Stabilität angeht und z.B. dem nichtdurchlaufen des Bausteins bei Peripheriefehlern?

Das müsste ja schon irgendwo klar beschrieben sein.
 
Profitiert man dann trotzdem von der neuen Firmware was die Stabilität angeht und z.B. dem nichtdurchlaufen des Bausteins bei Peripheriefehlern?

Das ist eine gute und berechtigte Frage. Ich gehe einmal davon aus, dass die Bugs weg sind, wenn die hohe FW geladen ist. So ist es ja auch auf der Siemens
Seite dokumentiert ( Behobene Fehler in V2.5.2 und nicht in V14 SP1 HF4 ). Ob allerdings ein anderer Code compiliert wird, wenn man eine andere FW wählt
kann ich nicht sagen.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Also ich habe es nun geschafft, die SPS wurde nun als eine "alte" unter V14 erkannt und ich kann die Programme darauf spielen. Es kommt zwar immer eine Warnung aber egal. Es funktioniert. Danke an alle.
 
Das ist eine gute und berechtigte Frage. Ich gehe einmal davon aus, dass die Bugs weg sind, wenn die hohe FW geladen ist.

Dafür sind dann neue drin ;)

Wir rüsten immer runter, da Einheitlichkeit für uns wichtiger ist... Die beschriebenen behobenen Bugs sind für uns unrelevant, für das PEW Problem haben wir nen Workaround gebaut...

Nen Kollege hatte schon mal nen Problem mit ner hohen FW-Version unter TIA V13. Irgendwie ging die Einbindung eines TP1500 als PN-IO-Teilnehmer nicht richtig (Direkttasten)

Gruß.
 
Wir rüsten immer runter, da Einheitlichkeit für uns wichtiger ist...
Immer schwierig zu entscheiden. Wie man´s macht ist es falsch. Runter rüsten kann aus den von dir genannten Gründen sinnvoll sein,
hochrüsten aber um die "hochsporadischen" Fehler weg zu bekommen. Zumindest die bekannten. Was auch immer hochsporadisch bedeutet ( jedes fünfte mal ? )
 
Zurück
Oben