TIA Script aus PLC-Programm starten

[ZottelMD]

Zuviel Werbung?
-> Hier kostenlos registrieren

Anhang anzeigen 54329..........

Erschreckend einfach und brachial effizient ^^ Danke

Wenn ich das richtig kontrolliere, müsste sich das mit meinem Vermutungen decken:

 

[JSEngineering]

Auf was soll ich zyklisch fortlaufend denn setzen? Das ist z. B. eine Einstellung, wo mir die Erfahrung und das Verständnis fehlt. Intuitiv erwarte ich bei zyklisch fortlaufend, eine Kommunikation in jedem Zyklus des Programms (also OB1 ???). Keine Ahnung, warum man bei zyklisch fortlaufend Zeiten auswählen kann. Das klingt für mich eh wie ein Paradoxon. Fortlaufend ist ebennicht diskret, man soll aber eine diskrete Zeit auswählen. Keine Ahnung, warum ich 500 ms wähle.
Die Standardeinstellung ist 1 s.

Also HMI und Programm laufen nicht synchron. Das sind beides eigene Prozesse.

Smit mußt Du die auch getrennt betrachten.
SPS läuft mit seinen Einstellungen. - auch ohne HMI.
HMI läuft mit seinen Einstellungen - und holt sich zyklisch die Daten von der SPS.
Dabei heißt zyklisch: In dem Abstand, den Du zeitlich eingestellt hast: 1s, 500ms, 100ms.
Die Alternative zu zyklisch ist: Nur bei Bedarf. Also bei Verwendung: Es werden im Normalfall immer nur die Variablen abgefragt (neben Alarmen und Bereichszeigern), die auch im Bild angezeigt werden. Um eben nicht 3000 Variablen abzufragen, während nur 10 für den Betrachter von Interesse sind. Hier wird der Zyklus, in dem sie abgefragt werden, im Bild eingestellt, für alle im Bild verwendeten Variablen.

Daher werden Variablen, die nirgendwo angezeigt werden (und z.B. nur in Skripten verwendet werden) auch nicht aktualisiert. Deshalb gibt es die Funktion "Variable aktualisieren". Die Variable wird eben nicht fortlaufend abgefragt, sondern nur auf Anforderung.
Und daher auch der Vorschlag in einem vorhergehenden Post, die Variable mal in einem Ausgabefeld anzuzeigen.


1s ist erst einmal Standard, weil das ausreichend schnell (in der Regel) für eine Anzeige am Bildschirm ist.

Und zeitkritsch heißt dann in diesem Zusammenhang z.B. daß Du im Panel eine Archivierung machen würdest, die schneller als 1s aufzeichnen soll.

 

[PN/DP]

Zuviel Werbung?
-> Hier kostenlos registrieren

Variablen-Aktualisierung in WinCC Comfort/Advanced: In der HMI werden HMI-Variablen verwendet. Das sind entweder HMI-interne Variablen (die sind immer aktualisiert, weil in der HMI), oder sie sind Kopien von externen PLC-Variablen, die in PLC liegen. Nun müssen die Werte der HMI-Variablen mit den Werten der verbundenen PLC-Variablen synchronisiert werden - das Erfassen/Lesen der PLC-Variablen und die Werte den verbundenen HMI-Variablen zuweisen nennt man Aktualisieren. Aus Performance-Gründen werden mit externen PLC-Variablen verbundene HMI-Variablen nur aktualisiert, solange die HMI-Variable auch verwendet wird. (Wozu die Werte von Variablen zyklisch lesen, wenn sie im aktuellen Bild eh nicht verwendet/angezeigt werden? Das würde nur die Kommunikation sinnlos belasten.) Diese Aktualisierung "nur bei Bedarf" nennt Siemens "Zyklisch im Betrieb". Will man die Wertänderung einer PLC-Variable auch mitkriegen, wenn die verbundene HMI-Variable nicht im Bild verwendet wird, dann muß man deren Erfassungsart auf "Zyklisch fortlaufend" einstellen. Dann wird die WinCC RT diese Variablen auch aktualisieren wenn sie nicht offensichtlich verwendet werden. Es wäre nun allerdings nicht hilfreich für die Performance der HMI, wenn man nun sehr viele Variablen auf "Zyklisch fortlaufend" einstellt... also auf die unbedingt notwendigen Variablen beschränken.

siehe auch die TIA Hilfe "Aktualisieren des Variablenwerts in Runtime"

Harald

 

[Aweeller]

Noch eine Idee:

du verwendest ein "ActionByte" zum Triggern diverser Scripts.
Wenn nun eines der Scripts, welche eventuell ja alle auf das ActionByte lauschen (aber dann nur bei einem bestimmten Bit was tun) hängt, weil da irgendein Fehler drin ist, Dann kommt dein momentan getestetes Script nicht zum Zug, weil es zwar auf dem Script Stack liegt, aber eben noch nicht dran ist.
Es wird immer nur ein Script nach dem anderen abgearbeitet!
Somit meinst Du, dass dein Script nicht getriggert wird. In Wirklichkeit liegt es aber auf dem Stack und kommt einfach nicht dran...

Vielleicht probierst Du mal eine neu deklarierte Variable rein zum Triggern dieses einen Scriptes?

Grüße

 

[JSEngineering]

Hab ich mich vorhin schon gefragt: Die Variable ist doch vermutlich das ganze Wort. Wenn sich da ein Bit drin ändert, hat sich der Wert der Variablen geändert. Das bedeutet doch, daß alls Scripte getriggert werden, die an der Variable hängen und nicht nur das eine, das auf ein bestimmtes Bit hört!? Das Bit kann ich doch erst im Script auswerten. Oder täusche ich mich da gerade? Hab gerade kein TIA laufen...

 

[ZottelMD]

Zuviel Werbung?
-> Hier kostenlos registrieren

SOOOOOOO ich habe neue Erkenntnisse. Aber zuerst möchte ich zum letzten Beitrag Stellung nehmen.

Noch eine Idee:

du verwendest ein "ActionByte" zum Triggern diverser Scripts.
Wenn nun eines der Scripts, welche eventuell ja alle auf das ActionByte lauschen (aber dann nur bei einem bestimmten Bit was tun) hängt, weil da irgendein Fehler drin ist, Dann kommt dein momentan getestetes Script nicht zum Zug, weil es zwar auf dem Script Stack liegt, aber eben noch nicht dran ist.
Es wird immer nur ein Script nach dem anderen abgearbeitet!
Somit meinst Du, dass dein Script nicht getriggert wird. In Wirklichkeit liegt es aber auf dem Stack und kommt einfach nicht dran...

Vielleicht probierst Du mal eine neu deklarierte Variable rein zum Triggern dieses einen Scriptes?

Grüße

Vielen Dank für den Vorschlag, das klingt für mich absolut plausibel. Aaaaaaaber, ich weiß gar nicht, ob ich es bisher gesagt habe, aber das das ActionByte trigert aktuell nur genau 1 Script. Nämlich dieses, was auf ActionByte's Bit 4 lauscht. Tendenziell wirst du recht haben, wenn man wirklich mehrere Scripts startet. Aber das kann ich noch gar nicht beobachten, weil ich explizit mit diesem Byte ja immer nur ein Script starte. Alle anderen Lauschangriffe auf andere Bits aus ActionByte sind noch nicht projektiert und folgen erst, wenn das hier vorgestellte eine Script erfolgreich läuft.

Was mich den Bogen schlagen lässt ...

IHR SEID genial. Es geht nun. Ich habe mich sukzessive versucht daran zu halten, was hier im Forum für Vorschläge gekommen sind.

 

[JSEngineering]

Und? Nun erzähl auch, woran es lag...

 

[ZottelMD]

Mein erster Versuch greift das Statement auf, dass womöglich nur ein Script mit Wertänderung genutzt werden kann / sollte. Ich habe darauf hin das bereits funktionierende Script mit der Ampel bzw dem Ampel PopUp mal deaktiviert. Die Wertänderungs-Option da herausgelöscht. Dann war nur das Datenbank-Tabelle-Wert-Eintragen Skript noch im Projekt möglich und aktiv. Die Eigenschaften standen zu dem Zeitpunkt noch auf "Aktualisiere Variable" UND "Führe Script blabla aus"

Das Ergebnis war kein Ergebnis. Nur das Löschen der AMpel-Script-Funktion brachte keine Änderung.

Zweiter Versuch: Ich habe ein E/A-Feld in das Bild gelegt, in dem ich die Messrampe starte. Das E/A-Feld zeigt den ActionByte Wert korrekt an, führte aber ebenfalls zu keinem anderen Verhalten, zusammen mit den bisheren Einstellungen


Das zusätzliche E/A Feld ist das unten links mit der 16. Wurde Das 5. Bit im Programm erfolgreich gesetzt, plobbt korrekterweise die 16 auf. Die wurde aber nicht automatisch wieder zu 0, weil das gewünschte Script erfolgreich aufgerufen wurde. Mission also immernoch nicht erfüllt.

Versuch 3 - kontrollierter Rückbau: In diesem Versuch schmiss ich mein debugging Versuch "Aktualisiere Variable" wieder heraus, sodass NUR NOCH Wertänderung des ActionBytes zur Scriptausführung führen soll. Gleichzeitig habe ich die HMI-Eigenschaft des ActionBytes von zyklisch fortlaufend auf zyklisch im Betieb und auf 1 s zurückgesetzt. DAs greift wieder die E/A Feld geschichte auf und berücksichtigt die 2 letzten Erläuterungen von Harald und JSEngineering auf

 

[ZottelMD]

Zuviel Werbung?
-> Hier kostenlos registrieren

Und? Nun erzähl auch, woran es lag...

HAHAHA Geduld, bin nicht so schnell mitm Tippen ^^

Aber es geht endlich. Also Ihr müsst quasi meine Inkonstanz entschuldigen, theoretisch hätte ich nach Versuch 2 immer nur eine Teilaktion ausführen sollen, und dann testen. Ich hab dann zwei drei Schritte zusammen gemacht. Deswegen kann ich nicht 100 % sagen, woran es von denen genau liegt. Vermutlich an allen. Auf jeden Fall bekommt meine Datenbank nun wunderbare automatisierte, scriptgesteuerte Einträge



Von hier aus kann ich nun wunderbr weitermachen. Füge ich zum Beispiel die Ampel-Script-Funktionalität wieder hinzu und stelle fest - geht nicht mehr, na dann integriere ich das Ampel Byte in mein Action Byte und scanne wieder nur eine Variable auf Wertänderung.

Gleiches gilt für alles anderen Scripte die ich jetzt mit Bit-Lauschangriff auf ActionByte starten will (Datenbank erstellen, Datenbank löschen etc). Wenn das Dediziert nicht geht, dann integriere ich es in das jetzige funktionierende Script mit else if oder mit case of anweisungen, soddass ich ein langes script habe.

In jedem Fall seid ihr genial, geduldig und habt es zum Laufen gebracht. Ich denke von hier aus kann ich erst einmal weitermachen. Bis ich dann wieder zum Lageregelungsproblem komme (siehe verlinkter thread) =D aber das gehört nicht hier her.

 

[ZottelMD]

Variablen-Aktualisierung in WinCC Comfort/Advanced: In der HMI werden HMI-Variablen verwendet. Das sind entweder HMI-interne Variablen (die sind immer aktualisiert, weil in der HMI), oder sie sind Kopien von externen PLC-Variablen, die in PLC liegen. Nun müssen die Werte der HMI-Variablen mit den Werten der verbundenen PLC-Variablen synchronisiert werden - das Erfassen/Lesen der PLC-Variablen und die Werte den verbundenen HMI-Variablen zuweisen nennt man Aktualisieren. Aus Performance-Gründen werden mit externen PLC-Variablen verbundene HMI-Variablen nur aktualisiert, solange die HMI-Variable auch verwendet wird. (Wozu die Werte von Variablen zyklisch lesen, wenn sie im aktuellen Bild eh nicht verwendet/angezeigt werden? Das würde nur die Kommunikation sinnlos belasten.) Diese Aktualisierung "nur bei Bedarf" nennt Siemens "Zyklisch im Betrieb". Will man die Wertänderung einer PLC-Variable auch mitkriegen, wenn die verbundene HMI-Variable nicht im Bild verwendet wird, dann muß man deren Erfassungsart auf "Zyklisch fortlaufend" einstellen. Dann wird die WinCC RT diese Variablen auch aktualisieren wenn sie nicht offensichtlich verwendet werden. Es wäre nun allerdings nicht hilfreich für die Performance der HMI, wenn man nun sehr viele Variablen auf "Zyklisch fortlaufend" einstellt... also auf die unbedingt notwendigen Variablen beschränken.

siehe auch die TIA Hilfe "Aktualisieren des Variablenwerts in Runtime"

Harald

Also HMI und Programm laufen nicht synchron. Das sind beides eigene Prozesse.

Smit mußt Du die auch getrennt betrachten.
SPS läuft mit seinen Einstellungen. - auch ohne HMI.
HMI läuft mit seinen Einstellungen - und holt sich zyklisch die Daten von der SPS.
Dabei heißt zyklisch: In dem Abstand, den Du zeitlich eingestellt hast: 1s, 500ms, 100ms.
Die Alternative zu zyklisch ist: Nur bei Bedarf. Also bei Verwendung: Es werden im Normalfall immer nur die Variablen abgefragt (neben Alarmen und Bereichszeigern), die auch im Bild angezeigt werden. Um eben nicht 3000 Variablen abzufragen, während nur 10 für den Betrachter von Interesse sind. Hier wird der Zyklus, in dem sie abgefragt werden, im Bild eingestellt, für alle im Bild verwendeten Variablen.

Daher werden Variablen, die nirgendwo angezeigt werden (und z.B. nur in Skripten verwendet werden) auch nicht aktualisiert. Deshalb gibt es die Funktion "Variable aktualisieren". Die Variable wird eben nicht fortlaufend abgefragt, sondern nur auf Anforderung.
Und daher auch der Vorschlag in einem vorhergehenden Post, die Variable mal in einem Ausgabefeld anzuzeigen.


1s ist erst einmal Standard, weil das ausreichend schnell (in der Regel) für eine Anzeige am Bildschirm ist.

Und zeitkritsch heißt dann in diesem Zusammenhang z.B. daß Du im Panel eine Archivierung machen würdest, die schneller als 1s aufzeichnen soll.

Vielen Dank euch beiden für das Erklären mit einfachen Worten. Das macht für mich jetzt absolut Sinn. Ich werde mir auf jeden Fall hinter die Ohren schreiben, dass ich zyklisch fortlaufend gar nicht oder äußerst selten benutze. Das Work-Around mit dem E/A-Feld und der standardmäßigen Aktualisierung, weil sichtbar, greife ich da viel lieber auf. Auf jeden Fall helfen mir solche Beiträge massiv mehr weiter, als stundenlanges, ineffizientes Manual blättern. Klar ohne gehts auch nicht - aka "RTFM" - aber meistens find ich es schwer in SIEMENS Dokumentationen gezielte, aufs Einfachste herunter gebrochene Informationen zu entnehmen. Ich den meisten SIEMENS sätzen interpretiere ich irgendwas rein, was mich verunsichert. Vielen Dank für eure Geduld und Hinweise

 

[ZottelMD]

Am liebsten würde ich fast alle eure ANtworten als "hilfreichste Antwort markieren" ... welche nehme ich nur ...

 

[ZottelMD]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hab ich mich vorhin schon gefragt: Die Variable ist doch vermutlich das ganze Wort. Wenn sich da ein Bit drin ändert, hat sich der Wert der Variablen geändert. Das bedeutet doch, daß alls Scripte getriggert werden, die an der Variable hängen und nicht nur das eine, das auf ein bestimmtes Bit hört!? Das Bit kann ich doch erst im Script auswerten. Oder täusche ich mich da gerade? Hab gerade kein TIA laufen...

Vermutlich hast du damit recht. Für mich wäre es so logisch. Was mich bestärkt in dem Vorhaben, alle Lauschangriffe auf ActionByste's Bits in ein Script und somit einem Wertänderungs-Ereignis zu packen.
Das ist vermutlich wirklich cleverer. Je nach dem, welches Bit sich ändert, wird dann eine Fallunterscheidung im längeren Script aufgerufen

 

[ZottelMD]

Ich glaube ich markiere Beitrag #6 als hilfreichsten. Zwar entspricht das nicht 100 % der Wahrheit, weil ich Wahrheit ists ja eine Mischung aus allen, gerade die Hinweise mit der HMI-Kommunikation, aber aus dem Beitrag entspringt zum ersten Mal die Idee mit dem E/A-Feld, die zusammen mit den Ausführungen der folgenden Posts ja auch am wahrscheinlichsten erscheint.

Ich fasse das somit für kommende Lese mal als Erstidee zusammen:
" Wollt ihr ein Script automatisch ausführen, was auf Wertänderung reagiert, dann platziert die gescannte Variable als E/A-Feld irgendwie/irgendwo ins aktive Bild, in dem die Aktion ausgeführt werden soll. Dazu die Einstellungen zyklisch in Betrieb und die Erfassungszeit kann man auf standard lassen, wenn man keine besonderen Ansprüche hat. Das spart sozusagen HMI-Ressourchen und ist besser als 120 Variablen auf zyklisch fortlaufend "

Wenn ihr nichts dagegen habt, markier ich also Beitrag 6 als hilfreichsten (unter den genannten uns bewussten Zusammenhängen).