TIA Neue Firmware 1500ér ( V2.6.1 )

[DeltaMikeAir]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ok, man kann die FW über ein externes Tool laden

Man kann diese Firmware auch mit V13, V14... laden.

aber sie ist nicht im HW Katalog und es wird als "Fehler"-Meldung ausgegeben

So war es bei Step7 auch schon, dass soll natürlich nicht heißen dass es so gut ist...
Bzw. dort konnte man die CPU gar nicht bespielen und benötigte eine höhere Version von Step7 ( z.B. 315-2EH14 )
also schon ein kleiner Fortschritt

dass falsche FW-Stände vorhanden sind falls man das Update macht.

Wie dies tatsächlich ist, kann ich nicht sagen.

 

[Wincctia]

Hallo Beisammen,

der FAQ beschreibt es aus meiner Sicht recht gut.
Bugs gehen weg nur neue Fetuers gibt es nicht.

https://support.industry.siemens.co...ortal)-version-auswählbar-ist-?dti=0&lc=de-DE

mfg Tia

 

[Gelöschtes Mitglied 117942]

Zuviel Werbung?
-> Hier kostenlos registrieren

Wir setzen das produktiv ein, allerdings ausschließlich mit Basisdatentypen. Die Datenkonsistenz über ganze Blöcke stellen wir über einen entsprechenden Handshake-Mechanismus sicher.

Seit Firmware 2.8 gibt's da eigentlich nichts mehr zu meckern.

Wir setzen es auch Produktiv ein. Allerdings "nur" für eine Visualisierung, also nichts Prozesswichtiges. Und dies mit OPC UA Methoden, welche es möglich ist Timer usw. parametrieren kann.

Bis jetzt hatte ich nur einen Fall, dass sich der Server an seine Grenzen gekommen ist. Allerdings hat er dies sofort am Client gemeldet mit [FONT=Verdana,Arial,Tahoma,Calibri,Geneva,sans-serif]OpcUa_GoodOverload[/FONT].
Und dies nur will ein Client eine grössere veraltete Struktur hatte.

Ab

Firmware 2.8 ist es wirklich sehr stabil. Zum Glück


TIA16 - 2.8.3 - CPU-1517F-3 PN/DP
​

 

[Thomas_v2.1]

Ab Firmware 2.8 ist es wirklich sehr stabil. Zum Glück

Ich hoffe du hast gelesen was mit 2.8.3 behoben wurde:

Es kommt nicht mehr sporadisch zu der Meldung „Schwerwiegender Firmware-Ausnahmefehler (interner Systemcode: 16#00400001 16#10020082 16#77A2A4D4) CPU wechselt in DEFEKT-Zustand (Systemreaktion)“, wenn sich der OPC UA Client beim Beenden von Subscriptions nicht konform der OPC UA Spezifikation verhält.

Es kommt nicht mehr sporadisch zu der Meldung „Schwerwiegender Firmware-Ausnahmefehler (interner Systemcode: 16#00400001 16#1002003A 16#00010246) CPU wechselt in DEFEKT-Zustand (Systemreaktion)“, wenn der OPC UA Client auf der S7-1500 CPU versucht eine Variable zu lesen, die nicht konform der OPC UA Spezifikation als Instanz eines abstrakten Datentypen auf dem OPC UA Server angelegt worden ist.

Ich finde das schon bedenklich, wenn durch einen leicht fehlerhaften Client die ganze CPU in Stopp mit Defekt geschickt werden kann.

 

[Gelöschtes Mitglied 117942]

Ich hoffe du hast gelesen was mit 2.8.3 behoben wurde:


Ich finde das schon bedenklich, wenn durch einen leicht fehlerhaften Client die ganze CPU in Stopp mit Defekt geschickt werden kann.

Zum Glück ist es bei mir nie eingetreten. Das hätte zu grosse Diskussionen geführt.
Bin froh das ich meine CPUs mit der Firmware 2.8.3 betreibe und auch auf neuere Firmwareversionen updaten werde. (Besonders wegen OPC UA)

Sehe im OPC UA eine grosse Zukunft und bin positiv darauf eingestellt. Deshalb werde ich das Risiko weiterhin eingehen.

 

[maxder2te]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich hoffe du hast gelesen was mit 2.8.3 behoben wurde:

Ich finde das schon bedenklich, wenn durch einen leicht fehlerhaften Client die ganze CPU in Stopp mit Defekt geschickt werden kann.

Solche Probleme hatten wir aktuell auch noch nicht.
Wir setzen's übrigens für prozessrelevante Sachen ein, allerdings keine zeitkritischen, sondern lediglich Handshakes. Die Kommunikation läuft unverschlüsselt (was aber ab Firmware 2.8 auch nicht mehr das Problem sein sollte). Bis dato läuft das Ganze seit dem Winter stabil. Das Thema "GoodOverload" ist bei uns auch schon aufgepoppt. Es ist zwar kein Problem, es wird nur unnötig viel Traffic erzeugt und ließ sich in unserem Fall nur durch das Erhöhen der Mindestzykluszeit beheben.

Viel garvierender Fand ich, dass ein https-Zugriff mit Google Chrome auf den Web-Server der CPU die CPU zum Absturzt bringen konnte. Aber auch das ist seit Firmware 2.8 nicht mehr aufgetreten (auch wenn im Projekt 2.6 projektiert ist, weil 15.1).

 

[Timo3210]

Mit der aktuellen Softing Datafeed Software V5.1 habe ich noch immer alle 6h einen Verbindungsabbruch ("Eine zuvor aufgebaute Systemsitzung wurde wegen Security-Leistungen des CPU-Betriebssystems abgebrochen."). Softing baut dann anscheinend als Workaround eine neue Verbindung auf und beendet dann hoffentlich die angestoßenen Schreib- und Leseaufträge korrekt. Laut Release Historie tauchen Verbindungssabbrüche häufiger mal auf und wurden anscheinend behoben. Hat AGLink nicht dieselbe Security Problematik!? Was hindert Siemens daran, nicht nur alle 6h die Verbindung zu unterbrechen, sondern grundsätzlich einen Zugriff zu unterbinden!? In Wireshark und dem PlugIn S7Comm
(Plus) läßt sich ja alles wunderbar darstellen...

Gruss

Timo

 

[Jochen Kühner]

Bei Aglink gab es diesen Fehler auch, wurde aber in einem Update gefixt

 

[Timo3210]

Zuviel Werbung?
-> Hier kostenlos registrieren

Jochen Kühner, vielen Dank für die Info. Ich werde nochmal einen extra Thread zu diesem Thema Softing DataFeed erstellen, da dies doch auch für andere Personen relevant ist. Die hier vorhandenen Infos werde ich dann integrieren.