# Update 3 (Hotfix) für WinCC flexible 2008 Service Pack 2



## IBFS (9 September 2010)

Update 3 (Hotfix) für WinCC flexible 2008 Service Pack 2

http://support.automation.siemens.com/WW/view/de/43412059

Gruß

Frank


----------



## rostiger Nagel (9 September 2010)

die Update Zyklen werden ja immer kleiner, ich
komme mit den installieren garnicht mehr nach!


----------



## IBFS (9 September 2010)

```

```



Helmut_von_der_Reparatur schrieb:


> die Update Zyklen werden ja immer kleiner, ich
> komme mit den installieren garnicht mehr nach!



Man sollte aber immer die Doku lesen.
Wenn einen die HF-Änderungen (noch) nicht
betreffen, würde ich es (noch) nicht installieren.

Frank


----------



## PN/DP (9 September 2010)

WinCC flexible 2008 SP2 Update 3 - Liesmich - Behobene Probleme:


> Einige Bediengeräte senden im Netzwerk nicht nur Pakete mit Ihrer MAC-Adresse,
> sondern auch Pakete mit der MAC-Adresse 00-01-00-00-00-00.


Solche "Mülleffekte" (by Perfektionist) zeigen mir ganz deutlich, mit welcher Sorgfalt da programmiert und 
Produkte auf den Markt geschmissen werden. Leider. 
	

	
	
		
		

		
			





So, wie bedeutende Bugs zur "Systemeigenschaft" erklärt werden, so ist auch diese Formulierung genial:


> Wenn Sie [...] ändern, kann es zu einem Beenden von WinCC flexible kommen.


*ROFL*
Schaffte es das WCCflex ES bei diesem Bug nicht mal mehr, den berühmten Entschuldigungs-Dialog anzuzeigen?

Harald


----------



## Perfektionist (9 September 2010)

PN/DP schrieb:


> "Mülleffekte" (by Perfektionist)


Nach dem Studium des Liesmich wollte ich mich auch schon drüber auslassen, dass es da Effekte gibt, die sich mit gesundem Menschenverstand (hab ich den?) nicht nachvollziehen lassen. Gut, jetzt bin ich es losgeworden. Weswegen ich poste, ist, dass ich über die Herkunft des Begriffs "Mülleffekt" nachgedacht habe.

Ich glaube mich zu erinnern, dass mein bester Freund, der ein oder zwei Klassenstufen über mir das Gymnasium besuchte (das mit dem Klassenstufenabstand änderte sich mal zwischendurch), mir eines Tages erzählte, was Chemiker unter "Dreckeffekt" einordnen: unerwartete Ergebnisse einer Reaktion / eines Nachweises, weil Verschmutzungen an der Reaktion beteiligt sind (auch die Physiker benutzen wohl den Begriff - mir ist nun nicht mehr recht gegenwärtig, was an physikalischen Versuchen an Dreck scheiterte). Ich glaube, zeitgleich brachte er auch den Begriff des "Mülleffekts" vom technischen Gymnasium mit nach Hause. Kann aber auch sein, dass das während seiner Studienzeit war. Müll ist eine deutliche Steigerung gegenüber Dreck - ist es ja eine Ansammlung von Dreck.

Den Begriff der schmutzigen Programmierung gibt es ja bereits. Das steht ja in meiner Begriffswelt für Algorithmen, die halt nicht zu 100% sicher funktionieren, sondern nur das Brauchbarkeitskriterium erfüllen (und ja - auch wenn ich mich Perfektionist nenne, nehme ich für mich in Anspruch, meine Codesequenzen bisweilen auch nur bis zu Brauchbarkeit zu entwickeln - das Problem Perfektion ist, dass es nichts gibt, was man nicht noch verbessern könnte). Wenn also die Software etwas unerwartetes tut - man nennt es Dreckeffekt.

Was also qualifiziert den Dreckeffekt zum Mülleffekt? Wie schon angedeutet: die Anhäufung. Beim Dreckeffekt kann man noch zuordnen, welchem Dreck man den Effekt zu verdanken hat. Oder zumindest mal erkennt, woher die Verschmutzung stammt. Bei den Mülleffekten ist zumindest mir als Flex-Anwender vollständig schleierhaft, wie diese entstehen, warum nur spezielle Geräte betroffen sind, z.T. sehr nahe Verwandte nicht, sie sich von einer Version zur nächsten einschleichen. Und mir ist schleierhaft, dass diese Effekte in einem Haufen von Müll überhaupt noch seitens ihrer Ursache auffindbar und behebbar sind.

Liebe Flex-Entwickler: die Software ist (inzwischen) einsatztauglich (wenn man mal davon absieht, dass man zwischen Start der Software bis zur Betriebsbereitschaft bisweilen mal vergisst, was man denn eigentlich tun wollte - oder man auch schonmal sicherheitshalber das Projekt zweimal generiert und überträgt, weil man sich nicht ganz sicher ist, ob man denn nun wirklich den allerletzen Stand schon übertragen hatte). Wenn man sich nicht immer wieder über Bugs wundern müsste. Dass mir das Step7 abgestürzt ist, ist mir mit V5.4 höchstens einmal passiert. Und mit dessen Vorgängerversionen bis 3.2 nicht öfter. Bei Flex bin ich übermütig geworden. Und prompt hab ich die bei mir gesunkene Sicherungsfrequenz neulich bereut.


----------



## PN/DP (10 September 2010)

Hallo Perfektionist,

Danke für Deine ausführliche Erklärung des Begriffes "Mülleffekte". Ich hätte nicht gedacht, daß der Begriff bei Dir so eine ausgefeilte Bedeutung hat. Als Du ihn hier in einem Beitrag verwendet hast, fand ich ihn einfach nur "passend". Nach Deiner Erklärung finde ich, der Begriff passt absolut.
*ACK*

Wie es zu solchen Mülleffekten bei der Programmierung kommt, kann ich mir schon grob vorstellen. Eine Hauptrolle spielt dabei sicher diese schmutzige Programmierung, daß Programmteile implementiert werden, die nur in einem begrenzten Wertebereich funktionieren, dieser Fakt aber im Quelltext nicht deutlich genug dokumentiert und kommentiert wird und ein paar Monate später dieser Programmteil mit ungeeigneten Werten genutzt wird, in der Annahme, der Programmteil wäre für den kompletten Wertebereich gründlich getestet worden. Dazu kommt, daß Siemens ja viele Panele hat, deren Firmware nicht nur von einem Programmierer geschrieben wird und die auch fremden Code (teils Freeware) enthält und auch das WCCflex ES wird sicher von vielen Programmierern "gemeinsam" programmiert. Wenn dann keine strikten Schnittstellen existieren oder einzelne Programmierer zu dämlich sind oder es cool finden, sich nicht exakt daran zu halten, dann kommt eben irgendwann solcher Müll bei 'raus.

Wobei das nun längst nicht alle Gründe sind, die mir einfallen. Doch die alle aufzuzählen würde einen gesonderten Thread erfordern.

Um den Bogen zu einem anderen Thema zu schließen: solche Mülleffekte - gerade bei der Zusammenarbeit mehrerer Programmierer - sind auch ein Grund, warum ich so strikt an der Verwendung von HMI-Schnittstellen-DB festhalte. 

Gute Nacht
Harald


----------



## M-Ott (10 September 2010)

Was mich bei den Service Packs und Hotfixes von Siemens am meisten stört, ist, dass es häufig Änderungen gibt, die nicht im Readme stehen, aber für die Projektierung relevant sind, zum Beispiel hatte ich das Problem, dass nach einem der letzten Updates die LEDs der K-Tasten an einem OP77A nicht mehr leuchteten. Der Grund: Siemens hat die gültigen Datentypen für die LED-Variable geändert. Byte darf plötzlich nicht mehr verwendet werden, es muss jetzt eine 16-Bit-Variable sein. Informationen im ReadMe? Fehlanzeige!

Bin mal gespannt, was sich diesmal alles ändert.
So ein Hotfix ist wie eine Pralinenschachtel....


----------

