TIA TP900 Datei mit VBS löschen -> geht nicht, weil Datei verwendet!?

[Heinileini]

Zuviel Werbung?
-> Hier kostenlos registrieren

Sowas habe ich mit Absicht nicht vorgeschlagen, weil das hat vor allem den "Charme" daß solange keine anderen Skripte ausgeführt werden können

Hmmm, was habe ich jetzt falsch verstanden?
Wir haben z.Z. 4 WorkAroundAnsätze vorliegen:
- 60 s warten, weil 30 s plausibel sind und man auf der sicheren Seite sein möchte,
- in einer Schleife alle 3 s abfragen, ob sich die DateiLänge noch ändert,
- in einer Schleife abfragen, wann zwei DatumsAngaben sich auseinanderentwickeln,
- in einer Schleife abwarten, wann das ArchiveAttribute erscheint bzw. rekonstruiert wird.
Allen Ansätzen ist aber doch gemeinsam, dass in einer Programmschleife gewartet wird und somit andere Scripts auf Eis gelegt werden.
Die beiden letztgenannten Varianten wären die schönsten, weil sie ja eine Art Rückmeldung darstellen würden, wenn sie denn so logisch funktionieren würden, wie man es erwartet. Tun sie aber anscheinend nicht.
Der einzige "Charme" besteht darin, dass man die Schuld auf MicroSoft abschieben kann, sofern die Probleme nicht auf das ZusammenStreichen der VBS-Möglichkeiten auf das Siemens-Mass zurückzuführen sind.

In #1 hiess es noch, dass die pdfs erfolgreich kopiert werden, sich die QuellDateien aber danach nicht löschen lassen.
Mittlerweile sieht es aber doch so aus, dass in dem Script sogar an zwei Stellen gewartet werden muss.
1. Warten, bis die pdf fertig erzeugt und geschlossen wurde, um dann den KopierVorgang zu starten.
2. Warten, bis die pdf fertig kopiert wurde, um die QuellDatei dann erst löschen zu können.

 

[DeltaMikeAir]

Allen Ansätzen ist aber doch gemeinsam, dass in einer Programmschleife gewartet wird und somit andere Scripts auf Eis gelegt werden.

Nein, ich hatte damals den Print SPS-Seitig angetriggert, dann Zeit auf SPS ablaufen lassen und dann SPS seitig ein weiteres Skript angetriggert.
Also keine Warte-Schleifen in Skripten

 

[Heinileini]

Zuviel Werbung?
-> Hier kostenlos registrieren

Nein, ich hatte damals den Print SPS-Seitig angetriggert, dann Zeit auf SPS ablaufen lassen und dann SPS seitig ein weiteres Skript angetriggert.
Also keine Warte-Schleifen in Skripten

Ja, prima. Aber dieser Lösungsweg wäre bei den anderen Ansätzen ebenso machbar. Wobei sich der Aufwand im Vergleich zu Deiner Anwendung, Michael, verdoppelt durch das Abwarten beim pdf-Erzeugen UND beim Kopieren.
Und durch wiederholtes Durchlaufen der ProgrammSchleife in der SPS zwecks "Polling" des ausgeguckten Kriteriums im Scrpt würde sich der Aufwand nochmals vervielfachen ...

 

[faust]

...
Besser als Schleife: ein Ereignis, das wünschenswert alle paar Sekunden kommt, die Abfrage auslösen lassen. Das geht allerdings in dem WinCC Comfort/Adv nur unter Mithilfe eines externen Ereignis-Auslösers, z.B. eine PLC-Variable die in einer PLC alle paar Sekunden geändert/hochgezählt wird und das Ereignis "Wertänderung" auslöst. Wenn keine Verbindung zu der PLC besteht, dann fallen allerdings diese Ereignisse aus. Innerhalb der HMI kann man nur minimal jede Minute ein (zyklisches) Ereignis auslösen (im Aufgabenplaner).
...

Hallo Harald (und alle anderen),

es gibt noch die HMI-Systemfunktion "SimuliereVariable", damit lassen sich Werte von Variablen mit Steuerungsanbindung zyklisch verändern. Funktioniert sogar, wenn man den Variablensimulator verwendet oder die Variable temporär keine Verbindung hat (dann kommt z.B. die Systemmeldung "Wertübernahme in Steuerung nicht möglich").

Ich realisiere so z.B. die Aktualisierung meines Maschinenstatusbildes per Script in einem 10-Sekunden-Intervall.
Habe dazu die o.g. Funktion an den Bildaufbau projektiert. Die notwendige Variable mit Steuerungsanbindung steht auf Erfassungsart "Zyklisch bei Verwendung" und Aktualisierungszeit "1 h". Bei Wertänderung der Variable wird das Script ausgelöst.

Ist vielleicht ein Weg, eine Warteschleife "ohne" Steuerungsbeteiligung zu realisieren. Wobei dies ja nichts am eigentlichen Problem ändert.


Gruß, Fred

 

[PN/DP]

Hallo Fred, die Systemfunktion "SimuliereVariable" ist hier ziemlich nutzlos, weil Variablenänderungen an internen Variablen keine Ereignisse auslösen, und wenn man "SimuliereVariable" mit PLC-Variablen verwendet, dann kann man auch gleich die PLC-Variable in der PLC ganz ohne "SimuliereVariable" ändern... Eine Warteschleife ohne Steuerung geht nur als (blockierende) Warteschleife in einem Skript oder als "Weck-mich-etwa-1Minute-später"-Ereignis per Aufgabenplaner.

PS: Noch einmal genauer gelesen

Funktioniert sogar, wenn man den Variablensimulator verwendet oder die Variable temporär keine Verbindung hat (dann kommt z.B. die Systemmeldung "Wertübernahme in Steuerung nicht möglich").

Wenn keine Verbindung zur Steuerung besteht und deshalb keine Wertübernahme in die Steuerung möglich ist, kommt dann trotzdem das Ereignis "Wertänderung" der Variable? Dann wäre "SimuliereVariable" wohl doch interessant.

Harald

 

[PN/DP]

Zuviel Werbung?
-> Hier kostenlos registrieren

Mittlerweile sieht es aber doch so aus, dass in dem Script sogar an zwei Stellen gewartet werden muss.
1. Warten, bis die pdf fertig erzeugt und geschlossen wurde, um dann den KopierVorgang zu starten.
2. Warten, bis die pdf fertig kopiert wurde, um die QuellDatei dann erst löschen zu können.

Ich bin mir ziemlich sicher daß man das zweite Warten nicht braucht. Ich meine, die Methode FileCopy kommt erst ins Skript zurück, wenn der Kopiervorgang fertig ist oder ein Runtime-Error auftrat.

Harald

 

[faust]

...
Wenn keine Verbindung zur Steuerung besteht und deshalb keine Wertübernahme in die Steuerung möglich ist, kommt dann trotzdem das Ereignis "Wertänderung" der Variable? Dann wäre "SimuliereVariable" wohl doch interessant.
...

Probiere ich morgen früh zur Sicherheit noch einmal aus


Gruß, Fred

 

[PN/DP]

Funktioniert sogar, wenn man den Variablensimulator verwendet oder die Variable temporär keine Verbindung hat (dann kommt z.B. die Systemmeldung "Wertübernahme in Steuerung nicht möglich").

Wenn keine Verbindung zur Steuerung besteht und deshalb keine Wertübernahme in die Steuerung möglich ist, kommt dann trotzdem das Ereignis "Wertänderung" der Variable? Dann wäre "SimuliereVariable" wohl doch interessant.

Wenn bei einem so projektierten SimuliereVariable die Verbindung zur Steuerung fehlt, dann wird der Meldepuffer mit Systemmeldungen "Wertübernahme nicht möglich" überflutet - aber keine Ereignisse ausgelöst. :sad:


Ich habe nun endlich gefunden, wie man mit SimuliereVariable zyklische/verzögerte/"Wiedervorlage"-Ereignisse auslösen kann ohne Hilfssteuerung, als Vielfache von 200ms... Überraschend: die Lösung steht hier im SPS-Forum schon seit 2010 ... Warum steht die Lösung in keinem Siemens Handbuch oder FAQ?

Bedingungen:
- es kann keine interne Variable sein - da werden keine Ereignisse ausgelöst
- es soll keine Variable in einer Steuerung sein - da werden keine Ereignisse ausgelöst wenn die Verbindung nicht besteht (dafür aber unschöne Systemfehlermeldungen)
Lösung: es muß eine Variable in einer Verbindung ohne Steuerungsanbindung sein - in einer deaktivierten Verbindung

So wird's gemacht:
Im HMI im Editor "Verbindungen" eine Verbindung (Stichwort "Nicht integrierte Verbindung") anlegen und die Verbindung "Offline" schalten. (Welcher Kommunikationstreiber ist unerheblich, er muß lediglich absoluten Zugriff auf Variablen-Adressen zulassen.)
Jetzt können auf diese Verbindung Variablen projektiert werden, mit Aktionen beim Ereignis "Wertänderung", die auch bei SimuliereVariable und bei Wertzuweisungen aus der Runtime die Aktionen beim Ereignisse "Wertänderung" ausführen (kein Loop Breaker!)

Zumindest in der Simulation eines Comfort Panels mit TIA V15.1 funktioniert das, auf einem realen Panel habe ich das noch nicht getestet.

Harald

 

[MFreiberger]

Zuviel Werbung?
-> Hier kostenlos registrieren

Moin,

Sowas habe ich mit Absicht nicht vorgeschlagen, weil das hat vor allem den "Charme" daß solange keine anderen Skripte ausgeführt werden können

Das stimmt, aber da ich keine Skripte habe, die weiterlaufen sollen und die Maschine durch ein laufendes Skript auf dem Panel nicht gestört wird, ist das nicht so wichtig.


@Heinileini: ich habe mal Deine Zusammenfassung genommen, um zu den einzelnen Punkten Stellung zu nehmen. Die Antworten beziehen sich daher nicht unbedingt auf Dich

- 60 s warten, weil 30 s plausibel sind und man auf der sicheren Seite sein möchte,

Das geht, aber wer sagt mir, dass der Ausdruck eines großen Protokolls nicht auch mal >60s dauern kann?

- in einer Schleife alle 3 s abfragen, ob sich die DateiLänge noch ändert,

Inzwischen habe ich ein bisschen experimentiert und 1s Wartezeit bei einem Schleifendurchlauf reicht auch. Zumindest scheint mir dies das sicherste zeitgesteuerte "Ereignis" zu sein

- in einer Schleife abfragen, wann zwei DatumsAngaben sich auseinanderentwickeln,

Die Datumsangaben entwickeln sich wirklich auseinander. Das könnte man wahrscheinlich auch nehmen. Allerdings habe ich es nicht getestet und weiß nicht, wie oft das Datum aktualisiert wird.

- in einer Schleife abwarten, wann das ArchiveAttribute erscheint bzw. rekonstruiert wird.

Das funktioniert leider nicht, da das Archivattribut einmal beim Erstellen der Datei geschrieben wird und danach nicht wieder aktualisiert wird.

Ich bin mir ziemlich sicher daß man das zweite Warten nicht braucht. Ich meine, die Methode FileCopy kommt erst ins Skript zurück, wenn der Kopiervorgang fertig ist oder ein Runtime-Error auftrat.

Das stimmt. Das war eine Fehlinterpretation meinerseits.
Dazu kam es, weil ich zunächst die erstellte Datei nicht kopieren konnte, bis ich ein paar Sekunden gewartet habe. Danach ging das kopieren, allerdings war der Druck noch nicht beendet und es wurde eine fehlerhafte Datei kopiert. Weil aber das Kopieren funktionierte und danach das Löschen der Datei einen Fehler produziert hatte, dachte ich, dass das Kopieren auch den Zugriff nicht freigibt (genauso wie das Drucken).


Komisch finde ich allerdings, dass (wie Harald schon einmal angemerkt hat) das Kopieren, Attribut setzen usw. funktioniert, das Löschen aber mit Zugriffsfehler verweigert wird...



Inzwischen hatte ich auch schon darüber nachgedacht, ein Skript für das Kopieren zu nehmen und dann zu beenden. Die Dateiänderung (Größe oder Änderungsdatum) würde ich dann prüfen, indem ich mit der Steuerung ein Triggerbit für die Dateienprüfung sende. Wenn das Drucken abgeschlossen ist, hätte ich dann ein Kopierauftrag angestossen.

Insgesamt kann ich aber mir dem derzeitigen Stand gut leben.

Vielen Dank an Alle, die mich mit Ideen, Anregungen, Hinweisen, etc. versorgt haben! :s22:

VG

Mario