# WINCC flex mit TP177 Programm vergleichen



## sirbarny (13 Mai 2010)

Manchmal ist es notwendig an vorhandenen Anlagen Änderungen vorzunehmen.
Bei S7 kann man dann mit *Extras >>>>> Bausteine vergleichen*
feststellen ob das Programm auf dem PC aktuell ist.
Gibt es für WIN CC flex eine ähnliche Funktion?

sir


----------



## netmaster (13 Mai 2010)

nicht das ich wüsste.


----------



## Paule (13 Mai 2010)

Du könntest Dir das Datum auslesen wann die letzte Programm Änderung am Panel gemacht wurde.


----------



## sirbarny (13 Mai 2010)

*test test*

Wie kann ich das Datum auslesen?

Wenn, dann weiß ich auch nur, dass was geändert wurde, aber nicht was. 

Das heißt, der Kunde muss die letzte Version bereit halten und vor einem Eingriff muss man sich diese geben lassen und verwenden.


----------



## Paule (13 Mai 2010)

sirbarny schrieb:


> Wie kann ich das Datum auslesen?


Leider doch nicht, denn Du hast ja ein TP177 und das kann keine Scripte.
Aber sonst:

```
dim s
Set fso = CreateObject ("filectl.filesystem")
s=fso.FileDateTime("\Hier den Pfad zu der Datei\???.???")
// in s steht nun das Datum
```
Pfad und Dateiname kann ich Dir erst morgen sagen, ist auch bei jedem Panel Typ unterschiedlich.


sirbarny schrieb:


> Wenn, dann weiß ich auch nur, dass was geändert wurde, aber nicht was.
> Das heißt, der Kunde muss die letzte Version bereit halten und vor einem Eingriff muss man sich diese geben lassen und verwenden.


Das ist korrekt.
Aber wenn das Datum passt kannst Du es beruhigt übertragen, wenn nicht dann bleibt meist nur > "Augen zu und klick auf Transfer"


----------



## PN/DP (13 Mai 2010)

*Achtung, böse Falle!*



sirbarny schrieb:


> Manchmal ist es notwendig an vorhandenen Anlagen Änderungen vorzunehmen.
> Bei S7 kann man dann mit *Extras >>>>> Bausteine vergleichen*
> feststellen ob das Programm auf dem PC aktuell ist.
> Gibt es für WIN CC flex eine ähnliche Funktion?


Nein, mit Siemens-Mitteln kann man NICHT feststellen, ob ein WinCCflexible-Projekt mit dem im Panel 
vorhandenen Runtime-Projekt übereinstimmt.


sirbarny schrieb:


> Das heißt, der Kunde muss die letzte Version bereit halten und vor einem Eingriff muss man sich diese geben lassen und verwenden.


Korrekt, dann ist man selbst aus dem Schneider, falls das doch nicht die letzte Version war.


Paule schrieb:


> Du könntest Dir das Datum auslesen wann die letzte Programm Änderung am Panel gemacht wurde.





Paule schrieb:


> wenn das Datum passt kannst Du es beruhigt übertragen, wenn nicht dann bleibt meist nur > "Augen zu und klick auf Transfer"


Die Runtime-Datei PDATA.FWX erhält beim Transfer auf das Panel einen Zeitstempel *von der Panel-Uhr.*
Wer kann garantieren, daß die Panel-Uhr beim Transfer auf das richtige Datum/Uhrzeit gestellt war?
Der Zeitstempel sagt also überhaupt nichts über den tatsächlichen Transfer-Zeitpunkt aus.
Erst recht nichts über das Generier-Datum. 
Und was seit dem Generieren am Projekt geändert wurde, steht in den Sternen ...

Bei jedem Panel, wo ich nicht 100% sicher bin, daß ICH den letzten Projektstand habe, mache ich VOR 
irgendwelchen Eingriffen mit dem Control-Panel ein *komplett-Backup* auf MemoryCard (oder mit ProSave, 
wenn das Panel keinen Speicherkartenschacht hat).
*Nur so kann im Ernstfall der vorherige Zustand wieder hergestellt werden!*
Mit ProSave kann das schon mal 1 Stunde dauern, doch ich will nicht dafür verantwortlich sein, daß durch 
meine Eingriffe der Prozess nicht mehr mit dem Panel bedient werden kann.


Wenn das Panel den Windows Explorer drauf hat (in der Regel Panels mit PN-Schnittstelle), dann kann man 
die PDATA.FWX auf eine MemoryCard kopieren und dann am PC mit der <projektname>.FWX vergleichen. 
Man erhält aber nur die Information "gleich" oder "nicht gleich", aber nicht ob und was geändert ist.

Das ist die einzige mir bekannte Möglichkeit, festzustellen, daß die auf dem Panel installierte Runtime 
mit einem WinCCflexible-Generierstand (<projektname>.fwx) übereinstimmt.
Das heißt aber nicht, daß es mit dem .hmi-Projekt übereinstimmt!
Das WinCCflexible-Projekt kann geändert sein, ohne daß eine Generierung durchgeführt wurde! Und weil 
WinCCflexible sowieso nach jedem Mausklick im Projekt speichern will (auch ohne Änderungen), ist es die 
Regel, daß der Zeitstempel der .hmi-Datei neuer als der der .fwx-Datei ist.
Und: bei jeder Generierung erzeugt WinCCflexible eine .fwx-Datei mit anderem Inhalt!
Es reicht schon, das Projekt auf dem PC zu simulieren und alle Vergleichsversuche sind für die Katz.

Der Speicherort der PDATA.FWX ist im Control Panel unter "Transfer Settings > Directories" zu finden, 
in der Regel der Ordner "\FLASH\Simatic\". Doch selbst das kann verstellt worden sein! z.B. um zwei 
Projektversionen auf dem Panel zu haben. So kann man einfach auf die vorherige Version zurückschalten.
(oder wenn ein tragbares Panel mit verschiedenen Projekten an verschiedenen Maschinen genutzt wird)


In meinen Panel-Projekten habe ich IMMER eine Textzeile "Builddate: xx.xx.xxxx" auf dem Startbild oder 
Info-Bild, wo ich in WinCCflexible manuell das Datum der letzten Änderung eintrage. So kann jedermann 
ohne Hilfsmittel genau sehen, welcher Projektstand auf das Panel transferiert ist. 
Leider muß man diesen Text bei jeder Projekt-Änderung selbst manuell anpassen, WinCCflexible bietet da 
keine Unterstützung für eine automatische Anpassung. Man darf es nicht vergessen!

Bei den Bediengerät-Eigenschaften kann man zwar die "Buildnummer Generator" sehen, diese Nummer kann 
aber (noch) nicht automatisch im Projekt verwendet werden.
In den Geräteeinstellungen kann man eine "Projektkennung" (0..255) eintragen, die hat aber eigentlich 
einen anderen Zweck und ich habe noch kein Projekt gesehen, wo da was anderes als 0 drinstand.

Gruß
Harald


----------



## Paule (14 Mai 2010)

PN/DP schrieb:


> Die Runtime-Datei PDATA.FWX erhält beim Transfer auf das Panel einen Zeitstempel *von der Panel-Uhr.*


Hallo Harald,
danke für den Dateinamen, jetzt muss ich nicht mehr nachschauen.

Eigentlich habe ich mit deinem Beitrag gerechnet, da ich den genialen Tipp vor knapp einem Jahr von Dir bekommen habe.


PN/DP schrieb:


> Wer kann garantieren, daß die Panel-Uhr beim Transfer auf das richtige Datum/Uhrzeit gestellt war?
> Der Zeitstempel sagt also überhaupt nichts über den tatsächlichen Transfer-Zeitpunkt aus.


OK, bei mir werden alle Panels von einer "Mutteruhr" gestellt.


PN/DP schrieb:


> In meinen Panel-Projekten habe ich IMMER eine Textzeile "Builddate: xx.xx.xxxx" auf dem Startbild oder
> Info-Bild, wo ich in WinCCflexible manuell das Datum der letzten Änderung eintrage. So kann jedermann
> ohne Hilfsmittel genau sehen, welcher Projektstand auf das Panel transferiert ist.
> Leider muß man diesen Text bei jeder Projekt-Änderung selbst manuell anpassen, WinCCflexible bietet da
> keine Unterstützung für eine automatische Anpassung. Man darf es nicht vergessen!


Das macht mein Kollege auch so, da stehen dann die wildesten Zeiten drin, manchmal aktuell, meist in der Vergangenheit, manchmal auch Zeiten in der Zukunft.
Wenn ich Ihn darauf hinweise heißt es nur: "Kann ja mal vorkommen"
Da sage ich immer: "Lieber nichts als was Falsches"


PN/DP schrieb:


> Das WinCCflexible-Projekt kann geändert sein, ohne daß eine Generierung durchgeführt wurde! Und weil
> WinCCflexible sowieso nach jedem Mausklick im Projekt speichern will (auch ohne Änderungen), ist es die
> Regel, daß der Zeitstempel der .hmi-Datei neuer als der der .fwx-Datei ist.
> Und: bei jeder Generierung erzeugt WinCCflexible eine .fwx-Datei mit anderem Inhalt!
> Es reicht schon, das Projekt auf dem PC zu simulieren und alle Vergleichsversuche sind für die Katz.


Das ist doch wie bei S7, wenn ich einen Baustein öffne, Speicher und nicht übertrage, habe ich einen Konflikt. So auch bei WinCCFlex.
Selbst wenn ich nur die Maus bewegt habe und Flex speichern will, dann sage ich doch ganz klar > NEIN, ich habe nichts geändert, sonst hätte ich es auch wohl übertragen.


----------



## sirbarny (14 Mai 2010)

Danke schon mal für die ausführlichen Infos. 
Grundsätzlich werde mir angewöhnen eine Sicherung runter zu ziehen. Dann kann ich wenigstens die Vorgängerversion wieder herstellen. 

Sir


----------



## PN/DP (15 Mai 2010)

*Nichts ist so wie es scheint*



Paule schrieb:


> OK, bei mir werden alle Panels von einer "Mutteruhr" gestellt.


Wenn Du ein defektes Panel gegen ein anderes Panel austauschst, transferierst Du dann das Projekt immer zweimal? 
Einmal vor der Uhrzeit-Synchronisation und einmal danach? 


Paule schrieb:


> Das ist doch wie bei S7, wenn ich einen Baustein öffne, Speicher und nicht übertrage, habe ich einen Konflikt. So auch bei WinCCFlex.
> Selbst wenn ich nur die Maus bewegt habe und Flex speichern will, dann sage ich doch ganz klar > NEIN, ich habe nichts geändert, sonst hätte ich es auch wohl übertragen.


Das machen Du und ich und noch ein paar andere Programmierer so. Doch weiß man das bei einem Fremd-Projekt?
Ich kenne viele Leute (darunter auch SPS-Programmierer), die gedankenlos JEDEN Dialog mit JA oder OK beklicken, 
ohne die Nachfrage gelesen oder gar verstanden zu haben.

Ich bekomme manchmal Fragen von Anlagenbedienern, die ein bestimmtes Bedienelement einfach nicht finden (wollen?).
Dann starte ich auf meinem Entwicklungs-PC mal schnell die Runtime-Simulation des Panelprojektes und kann "meinen" 
Bediener ganz genau zu dem gesuchten Bedienelement führen. Oder ich brauche einen Screenshot für das SPS-Forum. 
Manchmal starte ich dann die Runtime aus Versehen aus WCF (statt Doppelklick auf die <projekt>.fwx).
Nebeneffekt: WCF hat die Runtime (zumindest teilweise) neu generiert. Die .fwx hat nun einen neuen Zeitstempel.

In meinem Beitrag #6 wollte ich nur klarmachen, daß man sich auf keinerlei Informationen verlassen kann.
Und auf die Sorgfältigkeit anderer Programmierer erst recht nicht ...


Bei WCF-Projekten von Fremd-Programmierern schaue ich mir aber auch den Zeitstempel der PDATA.FWX, der <projekt>.fwx 
und der <projekt>.hmi an und vergleiche die PDATA.FWX mit der <projekt>.fwx. Wenn die Zeitstempel vom selben Datum 
sind und die FWX-Dateien übereinstimmen, dann ist das für mich ein sehr starkes Indiz dafür, daß das WCF-Projekt mit 
dem Panel-Inhalt übereinstimmt. Dann drücke ich viel entspannter auf den Transfer-Button und fahre anschließend auch 
viel ruhiger nach Hause.

Daß das WCF-Projekt mit dem Panel-Inhalt übereinstimmt kann man dank Siemens nicht nachweisen. Nur daß sie nicht 
übereinstimmen, wenn man einen sichtbaren Unterschied findet. Deshalb auch das "Builddate: xx.xx.xxxx" in meinen 
Panelen, obwohl auch das nicht sicher ist, weil nicht automatisch erzeugt. Es ist aber ein weiteres starkes Indiz.


Zusammenfassend kann ich nur dringend empfehlen, bei Eingriffen an Panels vorher ein komplett-Backup zu machen und 
dieses Backup sicher aufzubewaren. Jedes neu eingespielte Projekt sollte man unbedingt *sehr vorsichtig, mit einem 
Notaus-Taster in Reichweite und möglichst komplett testen.*
Wenn die vom Panel in der CPU beschriebenen Adressen nicht (mehr) zum SPS-Programm passen, dann hat im günstigsten 
Fall ein Button keine Funktion. Denn ungünstigsten Fall kann sich jeder selber ausmalen ...

Da muß noch nicht mal ein Programmierer dran schuld sein. Wenn WCF "nicht gut drauf" ist, dann kommt auch schon mal 
ein nicht ganz korrektes Kompilat raus. :-(

Gruß
Harald


----------



## Perfektionist (15 Mai 2010)

PN/DP schrieb:


> ...
> Ich kenne viele Leute (darunter auch SPS-Programmierer), die gedankenlos JEDEN Dialog mit JA oder OK beklicken, ohne die Nachfrage gelesen oder gar verstanden zu haben.
> ...


Ich will mich jetzt nicht der Gedankenlosigkeit bezichtigen - aber mir ist aufgrund der Eigenart von Flexible, dass es grundsätzlich speichern möchte, auch wenn ich nicht mehr getan habe, als die Maus zu bewegen, ist mir sowohl das eine, wie auch schon das andere passiert: ich habe gespeichert, obwohl ich es nicht wollte bzw. es nicht nötig gewesen wäre. Und ich habe auch schon nicht gespeichert, weil ich meinte, ich hätte nichts geändert. und kaum den Dialog weggeklickt, geflucht! Na, ja, meist Kleinigkeiten ...

Ja, und nach einem Komplettgenerierlauf, da speichere ich auch. Mir scheint nämlich, dass der Generierlauf ansonsten verworfen wird und beim nächsten Transfer nur der Deltalauf Stand vorletzter Generierung gemacht wird.


----------

