TIA Neue Firmware V2.9.4 für 1500ér CPU´s

DeltaMikeAir

User des Jahres 2018
Beiträge
12.965
Punkte Reaktionen
3.375
Zuviel Werbung?
->Hier kostenlos registrieren
Es ist eine neue Firmware für 1500ér erhältlich ( V2.9.4 ):
Firmware-Update S7-1500 CPUs incl. Displays und ET 200 CPUs (ET 200SP, ET 200pro)
Firmware-Update für SIMATIC Drive Controller, CPU 1504D TF und CPU 1507D TF
Update V2.9.4 CPUs
Abhängigkeiten zu STEP 7, STEP 7 Safety Advanced und Aufwärtskompatibilität:
Für die Projektierung dieses FW-Standes der CPU ist das Totally Integrated Automation Portal mit STEP 7 Professional ab V17 oder höher erforderlich.
Projektierungen mit früheren TIA Portal STEP 7 Professional Versionen sind aufwärtskompatibel einsetzbar.
Das Handling wird ausführlich in Beitrag 109744163 beschrieben.



Verbesserung der Nutzererfahrung:


Folgendes Verhalten wurde verbessert:

  • OPC UA-Server: Änderung des Verhaltens bei Verwendung von mehrdimensionalen Arrays in einem UDT:
    Ab Firmware-Version V2.9.4 kodieren S7-1500 CPUs mehrdimensionale Arrays innerhalb von Strukturen nach OPC UA-Spezifikation V1.04. CPUs mit älteren Firmware-Versionen kodieren entsprechende Strukturen in einer anderen Form. Wenn Sie mehrdimensionale Arrays innerhalb von Strukturen für CPUs mit älteren Firmware-Versionen verwendet haben und auf die aktuelle Firmware-Version hochrüsten, dann müssen Sie Ihre Client-Programme entsprechend anpassen.
  • Das Hochlaufverhalten der CPUs wurde stabilisiert
  • Das Kopieren von Daten zwischen optimierten und nicht optimierten Datenbausteinen wurde verbessert
  • Export von Rezepturen mit Strukturen und dahinterliegenden skalaren Datentypen bringt nicht mehr die Fehlermeldung 16#8091.
  • Bei den S7-1500 CPUen <=1516 kommt es nicht mehr hochsporadisch dazu, dass in sehr großen Instanz Datenbausteinen (>32kByte) eine Konstante vom Type LWORD oder LREAL nicht richtig bei Aufruf der Instanz geschrieben wird.


Folgendes Verhalten wurde behoben:
  • Bei Aufnahme der Kommunikation zu einem PROFINET Device kommt es nicht mehr zu den sporadischen Fehlermeldungen:
    • Temporärer CPU-Fehler: Schwerwiegender Firmware-Ausnahmefehler (interner Systemcode: 16#00000265 16#1002000D 16#00000000)
      CPU wechselt in DEFEKT-Zustand (Systemreaktion) oder
    • Temporärer CPU-Fehler: Schwerwiegender Firmware-Ausnahmefehler (interner Systemcode: 16#00080001 16#1002FFFF 16#00000246)
      CPU wechselt in DEFEKT-Zustand (Systemreaktion)
  • Bei gleichzeitiger Verwendung von SFB 143 “ DataLogClear mit einer Anweisung aus der Gruppe „File handling“ („FileReadC“ oder „FileWriteC“), kommt es nicht mehr zu den sporadischen Fehlermeldungen:
    • Temporärer CPU-Fehler: Schwerwiegender Firmware-Ausnahmefehler (interner Systemcode: 16#00400001 16#1002006F 16#7856D54C)
      CPU wechselt in DEFEKT-Zustand (Systemreaktion) oder
    • Temporärer CPU-Fehler: Schwerwiegender Firmware-Ausnahmefehler (interner Systemcode: 16#00400001 16#1002006F 16#00010202)
      CPU wechselt in DEFEKT-Zustand (Systemreaktion)
  • Die mit SIMATIC WinCC Unified „View of Things“ erstellten Webseiten der CPU bringen keine Fehlermeldung mehr „invalid Tagname xxx“ wenn in der symbolischen Adresse UTF-8-Zeichen, wie z.B. chinesische Schriftzeichen, enthalten sind und das Adresselement nicht durch Anführungszeichen umklammert wurde.
  • Bei Zugriffen auf den Webserver der CPU kommt es nicht mehr zu den sporadischen Fehlermeldungen:
    • Temporärer CPU-Fehler: Schwerwiegender Firmware-Ausnahmefehler (interner Systemcode: 16#00080001 16#1002007B 16#E0042DB4)
      CPU wechselt in DEFEKT-Zustand (Systemreaktion) oder
    • Temporärer CPU-Fehler: Schwerwiegender Firmware-Ausnahmefehler (interner Systemcode: 16#00000038 16#10020000 16#00000000)
      CPU wechselt in DEFEKT-Zustand (Systemreaktion) oder
    • Temporärer CPU-Fehler: Schwerwiegender Firmware-Ausnahmefehler (interner Systemcode: 16#00080001 16#1002007B 16#E0042EA4)
      CPU wechselt in DEFEKT-Zustand (Systemreaktion)
  • Bei Verwendung sehr großer Bausteine kommt es nicht mehr sporadisch zum Kompilierungsfehler beim Download auf die CPU und anschließender Fehlermeldung:
    • Temporärer CPU-Fehler: Schwerwiegender Firmware-Ausnahmefehler (interner Systemcode: 16#00400001 16#10020035 16#77D95B54)
      CPU wechselt in DEFEKT-Zustand (Systemreaktion)
  • Beim Auslösen von Alarmen kommt es nicht mehr zu sporadischen Fehlermeldungen:
    • Temporärer CPU-Fehler: Schwerwiegender Firmware-Ausnahmefehler (interner Systemcode: 16#0FFF0000 16#10020000 16#00000000) CPU wechselt in DEFEKT-Zustand (Systemreaktion)
  • Bei Verwendung der Anweisung MC_SetAxisSTW kommt es nicht mehr zum Fehler 16#8FFF, wenn das Execute-Bit mit der fallenden Flanke des MC_Power.Enable gesetzt wird.
  • Bei Verwendung des Technologieobjektes TO_CamTrack in besonderen Szenarien kommt es nicht mehr zum fehlerhaften Schalten von Nocken.
  • Bei Verwendung der Anweisungen MC_OffsetRelative oder MC_OffsetAbsolute mit einem negativen Offset, die durch einen MC_OffsetRelative abgelöst werden, kommt es nicht mehr zu unerwünschten Bewegungen der Folgeachse.
  • Nach dem Hochrüsten eines Projektes auf Motion Control Version 6.0 kommt es bei Verwendung der Anwenderdefinierten Kinematik nicht mehr zu einem Nullpointer-Zugriff im OB MC-Transformation (OB98)
  • Beim intensiven Ändern von Dynamikwerten am TO-Kinematics kommt es nicht mehr zu sporadischen Fehlermeldungen:
    • Temporärer CPU-Fehler: Schwerwiegender Firmware-Ausnahmefehler (interner Systemcode: 16#00400001 16#10020059 16#00010202)
      CPU wechselt in DEFEKT-Zustand (Systemreaktion)
 
Zuletzt bearbeitet:
OP
DeltaMikeAir

DeltaMikeAir

User des Jahres 2018
Beiträge
12.965
Punkte Reaktionen
3.375
Wenn ihr OPC UA nutzt, dann müsst ihr etwas aufpassen:
OPC UA-Server: Änderung des Verhaltens bei Verwendung von mehrdimensionalen Arrays in einem UDT:
Ab Firmware-Version V2.9.4 kodieren S7-1500 CPUs mehrdimensionale Arrays innerhalb von Strukturen nach OPC UA-Spezifikation V1.04. CPUs mit älteren Firmware-Versionen kodieren entsprechende Strukturen in einer anderen Form. Wenn Sie mehrdimensionale Arrays innerhalb von Strukturen für CPUs mit älteren Firmware-Versionen verwendet haben und auf die aktuelle Firmware-Version hochrüsten, dann müssen Sie Ihre Client-Programme entsprechend anpassen.

Das war hier im Forum ja auch schon mal Thema, interessant wäre nur: Was bedeutet verbessert?
Das Kopieren von Daten zwischen optimierten und nicht optimierten Datenbausteinen wurde verbessert
 

Onkel Dagobert

Well-known member
Beiträge
5.342
Punkte Reaktionen
1.123
Zuviel Werbung?
->Hier kostenlos registrieren
Dein link zeigt auf einen älteren Beitrag. Ist das nur bei mir so?
109478459, Beitragsdatum: 09.08.2021
Wenn ich jedoch online danach suche, dann komme ich zu der aktuellen Seite. Über den korrekten link aber nur zu dem genannten Beitragsdatum. Voll der Virus!
 
Zuletzt bearbeitet:

Oberchefe

Well-known member
Beiträge
2.441
Punkte Reaktionen
407
Nach dem Hochrüsten eines Projektes auf Motion Control Version 6.0 kommt es bei Verwendung der Anwenderdefinierten Kinematik nicht mehr zu einem Nullpointer-Zugriff im OB MC-Transformation (OB98)

Da bin ich mal gespannt. Werde ich im Januar sehen.
 

ducati

Well-known member
Beiträge
6.912
Punkte Reaktionen
1.502
Zuviel Werbung?
->Hier kostenlos registrieren
hmm, dass man mit <V17 nicht mehr an die CPU drankommt, wenn die CPU mal mit V17 geladen wurde, das wurde scheinbar nicht beseitigt...

Aber bestätigt meine Vermutung, dass die 2.9.2 echt viele Bugs hat...
 

memotech

Active member
Beiträge
37
Punkte Reaktionen
14
Bzgl. OPC UA, mehrdimensionale Arrays innerhalb von Strukturen:
Das war hier im Forum ja auch schon mal Thema, interessant wäre nur: Was bedeutet verbessert?
Puh, das ist nicht ganz einfach zu erklären.
Wer darauf Zugriff hat, siehe https://mantis.opcfoundation.org/view.php?id=7119.

Es ist wichtig zu wissen, dass man bei OPC UA Array-Werte nicht immer komplett übertragen muss. Man kann auch weniger Elemente übertragen. Bei einem eindimensionalen Array genügt hier die ArrayLength, um zu signalisieren, wieviele Elemente man hat. Bei einem mehrdimensionalen Array aber genügt die Gesamt-Anzahl der Elemente nicht. Wenn sie weniger ist als die Maximalgröße des Arrays, dann weiß man nicht, in welcher Dimension das Array um wieviel "kürzer" ist. Dazu muss zusätzlich ArrayDimensions mitgeliefert werden. Das ist eine Liste mit Größen für jede Dimension. ArrayLength ist in diesem Fall natürlich das Produkt über alle Größen in ArrayDimensions.

Wird ein Array "für sich alleine" in einem Variant transportiert, dann wird bereits in der Variant-Struktur neben ArrayLength auch ArrayDimensions mit übertragen, und somit geht das auch für mehrdimensionale Arrays.

Wird ein Array aber innerhalb einer Struktur übertragen, so gab es früher bei OPC UA Binary nur das Encoding mit Gesamtanzahl der Elemente, gefolgt von der flachen Liste der Elemente. Damit funktionieren aber mehrdimensionale Arrays nicht wirklich, wenn sie "kürzer" sein können. Zusätzlich konnte man mit den Mitteln des DataTypeDictionarys nach V1.03 auch kein anderes Binary Encoding beschreiben. Nur in OPC UA XML ging das mit der Beschreibung als Element "Matrix". D.h. ein mehrdimensionales Array in einer Struktur ging in V1.03 nicht wirklich.

Mit dem DataTypeDefinition Attribut, was in V1.04 als Ersatz für das DataTypeDictionary eingeführt wurde, kann man das nun beschreiben. Und es gibt nun auch ein Binary Encoding dafür, genannt "inline matrix representation", was denselben Aufbau wie das XML Element "Matrix" hat. Das alles gilt und funktioniert schon mit V1.04, ist jetzt aber erst im Release Candidate für V1.05 sauber beschrieben.

Die PLC hat bei einem mehrdimensionalen Array innerhalb einer Struktur bisher einfach dasselbe gemacht wie bei einem eindimensionalen Array oder einem mehrdimensionalen Array innerhalb eines Variant: Sämtliche Elemente serialisieren und die Gesamtanzahl davorschreiben. Das war nicht wirklich falsch, weil es einfach für diesen Fall keine Spezifikation gab. Und weil die PLC ja immer das gesamte Array serialisiert, konnte ein Client sogar etwas damit anfangen. Aber nun gibt es für diesen Fall eine Spezifikation, die ein anderes, nicht rückwärtskompatibles Binary Encoding vorschreibt, und das wurde nun implementiert.
Sollte ein Client das bisherige, nicht-spezifizierte Verhalten genutzt haben, muss er nun auf das standardisierte Verhalten geändert werden.
 
Oben