TIA Script aus PLC-Programm starten

[ZottelMD]

Zuviel Werbung?
-> Hier kostenlos registrieren

Huhu,

muss einfach nach Rat fragen, auch wenn ich viele Threads gelesen habe und immer wieder die gleichen Antworten kommen:
- im HMI die Variable mit Wertänderungseigenschaft auf zyklisch fortlaufend stellen
- Variable im Programm z. B. auf HIGH setzen und am Script Ende dann LOW setzen

IF XYZ THEN
- Code hier bla bla - 
XYZ = 0
END IF

Ich bin der Meinung, ich mache genau das, aber es geht halt nicht ^^

1. konkret geht es um die Variable in der folgenden Abbildung mit dem Namen

"Vars".SQL.dbActionByte.%X4

(bzw. ein bestimmtes Bit in dieser)


In einer Case Anweisung setze ich das 5. Bit in der Variablen auf HIGH. Das Zurücksetzen in Case 9 habe ich auskommentiert. Heißt das Bit bleibt auch nach dem Baustein die ganze Zeit, wenn keine weitere Aktion folgt.

2. In der Beobachtungstabelle kann ich genau das beobachten:
Vor dem Ausführen des Bausteins steht der Wert 0 in der Variable, also ist auch das Bit 5 LOW

Nach einer Messfahrt steht, wie beschrieben, das 5. Bit auf HIGH, was HEX 0 ergibt oder eben BIN 0001 000


3. Die benannte Variable, deren Bit ich scannen will, ist in der HMI Variablen Tabelle regulär angelegt und pauschal habe ich die 1 s Erfassungszeit auf 500 ms geändert


4. Markiere ich die Variable in der HMI-Variablen Tabelle und gehe unter Eigenschaften, dann stelle ich die Erfassungsart auf zyklisch forlaufend und wähle die zweitniedrigste Zeit. in der v15.1 kann ich minimal auf 100 ms stellen. Danach ist 500 ms verfügbar. Bin bescheiden, deswegen 500 ms.


- kurzer Cut, weil ich nicht mehr Bilde hochladen darf - bin gleich zurück !

 

[ZottelMD]

5. Unter Ereignisse der HMI-Variable prjektiere ich bei Wertänderung entweder NUR die gewünschte Funktion oder - wie hier abgebildet - zum Testen noch zusätzlich Variable aktualisieren. Beide Fälle funktionieren nicht.


6. Gleichzeitig kann ich genau das gleiche Wunsch-Script im HMI per Taste drücken, was hervorragend funktioniert


7. Im Script selbst lese ich das gesamte Byte der "dbActionByte"-Variable ein und scanne das 5. Bit ab. Wenn das 5. Bit HIGH ist, dann darf das weitere Script ausgeführt werden. Falls nicht, gehe nicht über LOS und ziehe keine 5000 $ ein -> End Sub

Guuuut, ich habe oben übertrieben... Ich setze das Byte/Bit gleich nach Eintritt zurück und nicht erst am Ende. Aber das spielt keine Rolle.

Das Script wird bei Wertänderung nicht automatisch abgearbeitet. Die Variable bleibt die ganze Zeit auf HEX 10. Erst wenn es mir auf den Sack geht und ich manuell den Knopf zum Ausführen der Funktion drücke, dann wird die Variable zurückgesetzt und das Script ausgeführt.

Bevor ihr es verlinkt, die Hinweise unter
https://support.industry.siemens.co...skripten-in-wincc-(tia-portal)?dti=0&lc=de-DE
habe ich gelesen und theoretisch tue ich genau das nicht. Ich setze in einem Case eine globale Variable genau einmal auf HIGH, bzw. ein Bit von ihr und führe die Variable dann direkt ins HMI und will die scannen mir Wertänderung.


Theoretisch kein Zirkelbezug oder ich sehe den Wald vor laute Bäumen nicht.

Entdeckt jemand den Fehler?

VG

 

[Matze001]

Zuviel Werbung?
-> Hier kostenlos registrieren

Sieht erstmal nicht schlecht aus.

Was macht denn "Aktualisiere Variable" bei der Wertänderung.
Der Alarm "Script durch bit ausgeführt" sollte ja auch beim Button-Click kommen, und auch unabhängig vom Status des Bit.

Was sein könnte: Was für ein Panel hast Du denn? Es können nicht unendlich viele Scripts gleichzeitig ausgeführt werden.
Vielleicht scriptest Du ja schon so viel durch die Gegend, dass das Script gar nicht los rennt? (dann sollte es aber auch nicht mit dem Button gehen)

Grüße

Marcel

 

[DeltaMikeAir]

Projekt hast du einmal komplett übersetzt und geladen? Also nicht nur teilübersetzt? Startet du mehrere Skripte?
Hast du evtl auch While Schleifen in Skripten?

 

[PN/DP]

Um unsere Glaskugeln zu bestätigen: Teile uns zuerst einmal mit, welche WinCC RT auf welchem Gerät Du da programmierst. TIA verwendest Du anscheinend Version V15.1?

In WinCC Comfort/Advanced kann nur genau 1 Skript "gleichzeitig" laufen.
Wenn Du Skripte mit Buttons aufrufen kannst, bei anderen Ereignissen werden die Skripte aber nicht aufgerufen, dann kommt meistens das Ereignis nicht. Entweder wird die Variable gar nicht aktualisiert, die den Skript-Aufruf triggern soll, oder das gewünschte Ereignis wird generell nicht ausgelöst, z.B. Wertänderungen durch Zuweisungen an interne Variablen lösen keine Ereignisse aus (Loop-Breaker).
Warum setzt Du den einen "Zyklisch fortlaufend"-Erfassungszyklus auf 500ms? Ist das was Du tun willst irgendwie zeitkritisch?
Was erhoffst Du Dir mit dem Aufruf von "AktualisiereVariable"?
Hast Du in irgendeinem Bild eine Meldeanzeige, die (auch) Meldungen der Meldeklasse "System" anzeigt? Die wirst Du brauchen um Runtime Error Meldungen rund um das Skripten überhaupt mitzukriegen, und um mit ShowSystemAlarm Testausgaben zum Debugging sehen zu können.

Harald

 

[Aweeller]

Zuviel Werbung?
-> Hier kostenlos registrieren

Guten Morgen,

Wenn das Script über den Button gestartet wird und funktioniert, dann muss es auch über einer Wertänderung der Variable getriggert werden können.
Hast Du schon mal versucht, die Variable in ein Ausgabefeld eines Bildes zu setzen und bleibst einfach testweise in dem Bild, damit Du zum einen sehen kannst, wie sich die Variable ändert und ob dann das Script getriggert wird.
Wir verwenden so ein Handling (zyklisch fortlaufend lesen im Hintergrund) auch schon seit längerem und das funktioniert eigentlich problemlos...

Früher habe ich auch oft parallel "DebugView" von Sysinternals laufen lassen.
Dann kann man im Script mit dem Befehl "HmiRuntime.Trace" eine Ausgabe von Texten und auch Variablenwerten in den Debugger schreiben.
Das finde ich praktischer als die Verwendung von "ShowSystemAlarm", da man dann in einem separaten Fenster die Ereignisse mit Zeitstempel gelistet bekommt und das dann in Ruhe anschauen kann, was genau wann passiert ist!

Entgegen der Aussage von SIEMENS funktioniert das auch bei "ADVANCED", zumindest wenn ich zum Test die Runtime auf dem Erstell-PC starte (da will ich ja auch testen). Sollte aber auf dem Zielsystem (Windows) genauso funktionieren.



P.S.: nimm doch "Aktualisiere Variable" aus der Funktionsliste raus. Das mach überhaupt keinen Sinn. Die Variable wurde doch soeben aktualisiert (zyklisch lesen) und hat damit die Wertänderungsereignisse getriggert. Hat ja auch schon PN/DP gemeint...

Grüße

 

[JesperMP]

Früher habe ich auch oft parallel "DebugView" von Sysinternals laufen lassen.
Dann kann man im Script mit dem Befehl "HmiRuntime.Trace" eine Ausgabe von Texten und auch Variablenwerten in den Debugger schreiben.
Das finde ich praktischer als die Verwendung von "ShowSystemAlarm", da man dann in einem separaten Fenster die Ereignisse mit Zeitstempel gelistet bekommt und das dann in Ruhe anschauen kann, was genau wann passiert ist!

Nur als kommentar, die Meldungen die man mit ShowSystemAlarm auslöst werden auch in ein gepufferte Meldanzeige mit Zeitstempel gespeichert.

 

[Aweeller]

Nur als kommentar, die Meldungen die man mit ShowSystemAlarm auslöst werden auch in ein gepufferte Meldanzeige mit Zeitstempel gespeichert.

Ja das stimmt.
Mit DebugView muss ich halt in der Runtime nicht extra eine Meldeanzeige für die Systemfehler projektieren, welche später der Kunde nicht sehen soll...
Jeder hat seine Vorlieben in der Arbeitsweise

 

[ZottelMD]

Zuviel Werbung?
-> Hier kostenlos registrieren

Huhu,

erst einmal vielen Dank für die zügige, rege Unterstützung. Ich versuche mal, alles nach und nach abzuarbeiten und zu beantworten. Bitte seht mir aber nach, wenn ich nicht ganz auf Augenhöhe mitreden kann. Ich bin absolute Laie und wende TIA und Zubehör nur seit einem 3/4 Jahre im Rahmen meiner Masterarbeit an. Das ist aber ganz weit weg von professionell und alle Zusammenhänge verstehen.

Initial kurz reingegrätscht:
1. Bitte hängt euch nicht an "Variable aktualisieren auf". Diese Funktion habe ich wie beschrieben nur kurz zum Debuggen der Variable angeheftet, aus der Verzweiflung heraus. Wie ich beschrieben habe, funktioniert das automatische Ausführen des Scriptes, wenn ich den Schnodder weglasse.

2. Der schon mehrfach aufgetauchte Hinweis, wenn der Button klappt, dann müsste das Script auch klappen. Das kann ich so unterschreiben. Das ist auch meine Logik.

3. Jegliche showSystemAlert-Meldungen/Zeilen im Script fliegen wieder raus. Das ist nur zum debuggen drin, damit ich unterscheiden kann: wird ein Script geöffnet, wird der IF Fall abgearbeitet, wird der Else Fall abgearbeitet. Hinweise/Kritik dieser Art, sofern ich nicht komplett etwas falsch mache und/oder damit etwas behindere, bringen uns nicht weiter. Das sind nur kleine Mini-Wege, die ich versuche zu gehen, um mich irgendwie an den Fehler heran zu tasten. Vergleichsweise mit eine seiner serial print-Anweisung bei Microcontrollern

 

[ZottelMD]

Was macht denn "Aktualisiere Variable" bei der Wertänderung.

Wie ich drauf hingewiesen habe, nur in der Verzweifelung kurz hinzugefügt, um zu sehen, ob das was verändert/verbessert/verschlimmbessert. Funktionieren tut es auch ohne "Aktualisiere Variable" nicht.

Der Alarm "Script durch bit ausgeführt" sollte ja auch beim Button-Click kommen, und auch unabhängig vom Status des Bit.

Genau, dem ist auch so. Schon das manuelle Öffnen triggert die Meldung. Aus debuggin Sicht auch genau deswegen an der Stelle hinzugefügt.

Was sein könnte: Was für ein Panel hast Du denn? Es können nicht unendlich viele Scripts gleichzeitig ausgeführt werden.
Vielleicht scriptest Du ja schon so viel durch die Gegend, dass das Script gar nicht los rennt? (dann sollte es aber auch nicht mit dem Button gehen)

Ich habe ein IPC377E im Einsatz auf dem von Hause aus W10 installiert war und auf dem wir eine WinCC RT advanced mit 128er Tag-Lizenz installiert haben.

Ich werde einfach mal, um den Gesamtzusammenhand nachvollziehbar machen, im nächsten Post meine Anlage kurz vorstellen und das was ich machen will.

 

[ZottelMD]

"Meine" Anlage ist der Versuch eines Leistungsprüfstandes für Kleinfahrzeuge (Gokarts). Im Rahmen einer Projektarbeit, haben ein Kommilitone und ich die Anlage Konzeptioniert, aufgebaut und teilweise in Betrieb genommen:
- ich hatte hier jetzt 12 mal versucht einen Bildschirmausschnitt hochzuladen, ganz genau, wie ich es bei allen vorherigen Abbildungen gemacht habe, und bekomme jetzt IMMER vom Forum die Medlung: Geht nicht. Zu Groß! Das kann aber nicht sein, weil der mittlerweile kleiner ist, als alles von gestern. -
Ich kann es also schienbar leider nur mit Worten beschreiben.

Ich habe einen großen Schaltschrank, da haben wir die SIEMENS Automatisierungstechnik untergebracht:
1516 PLC, CU320, Rückspeiseeinheit, 2 x Single Motor Module, 2 x S120 1FT7-...PSM

Rechts daneben hab ich die beiden Servos gegenüberstehend montiert, sodass sich beide Wellen-Stummel anschauen. Dazwischen wird ein Gokart mit seiner starren Hinterachse montiert (Stehlager, Drehmomentmesswelle etc. inbegriffen).

Im Rahmen von studentischen Prjekten an unserer Hochschule sollen künftig mehrere Gokarts mit mehreren Antriebssystemen ausgestattet werden:
1 Verbrenner Gokart (max. 4.8 kW)
1 Elektro Gokart (Bosch-Antriebsstrang mit max 8.3 kW)
1 Brennstoffzellen Gokart (max. 1 kW)
1 hydrostatischer Antrieb

All diese Fahrzeuge sollen auf "meinem" Prüfstand untersucht werden können. Ein Teil meiner Masterarbeit ist es nun, meinem Prüfstand eine dafür ausreichende Grundfunktionalität zu geben. Ich sitze schon sehr lange dran und erreiche das einfach nicht ohne Probleme (über ein Jahr schon).

Vor kurzem musste ich das erste Ziel etwas zurücknehmen und bin zur Umsetzung von klassischen Leistungsmessungen hin gewechselt. Die Abbildungen der dabei notwendigen Messmodi hatte ich bereits in diesem Thread vorgestellt:
Problem beim Wechsel von lagegeregelt und nicht lagegeregeltDie schwarzen Abbildungen mit den bunten Kurven, spiegeln immer genau einen der 3 gewünschten Messmodi wieder.

Messung 1: konstante Drehzahl.

Der Benutzer sitzt im Kart, auf dem Prüfstand eingespannt und gibt via Tastatur eine Wunschdrehzahl vor. Die Antriebe (Servos) Fahren mit MCMoveJog die Solldrehzahl an, sodass sich die Hinterachse des Gokart zwangsweise dreht. Bei dem Verbrenner Gokart (das einzige, was von Hause aus schon läuft) koppelt die verbrennungsmotorische Kraft durch eine Fliehkraft-Kupplung ein, also erst wenn man aktiv Gas gibt. Hat der Prüfstand seine gewählte Solldrehzahl erreicht, wir am KArt z. B. Vollgas gegeben. Die Servos dürfen alles Moment, was sie brauchen, dafür nutzen, um diese Stögröße auszuregeln.
Theoretisch muss ich beide Achsen mit Lageregelung betreiben, was leider noch nicht klappt (verlinkter Thread). Auf jeden Fall sind so theoretisch statonäre BEtriebspunkte zu messen und ein Motordiagramm kann rekonstruiert werden.

Messung 2: konstante Last
In diesem Modus limittiere ich das maximale Drehmoment in den Lastmaschinen (Servos) mit MC_TorqueLimitting bei einer konstanten Solldrehzahl von 0 rpm. Gibt man jetzt am Gokart z. B. Vollgas, so wird man diese konstante Last je nach momentaner Motorkennlinie mal mehr oder weniger schnell beschleunigen. Das hängt davon ab, wie sehr das Drehmoment vom Verbrennungsmotor an der Hinterachse, die Summe der beiden Servo-Lastmomente übersteigt (nichtlineare Motorkennlinie eben). Ist der Drehmomentüberschuss in einer Sekunde hoch, ist die Beschleunigung groß, ist der Drehmomentüberschuss in der nächsten Sekunde geringer, so ist die Beschleunigung etwas geringer. Aus dem Verlauf der sich einstellenden Drehzahl und der konstanten Last kann man dann ebenfalls die Leistung des Prüflings ermitteln.
- Hinweis: wie gesagt, die schwarzen Abbildungen im verlinkten Thread zeigen das, was ich hier beschreibe sehr intuitiv, schaut da rein ! =) -

Messung 3: konstante Beschleunigung
Im dritten Messmodus will ich eine konstante BEschleunigung der Hinterachse einstellen. Heißt die Servos bekommen z. B. den Auftrag: beschleunigt von 0 rpm auf 950 rpm in 10 Sekunden. Kurz nach Andrehen gibt man dann wieder mit dem Kart z. B. Vollgas und speilt so wieder die Störgröße ein. Auch hier dürfen die Servos alles Moment, was sie zur Verfügung haben nutzen, um die Störgröße auszuregeln und die lineare Sollrampe einzuhalten. Aus dem Drehzahlverlauf und der messbaren Servomomente kann man dann wieder auf die Leistung des DUT schließen

Diese 3 Messmodi will ich in den gestern angerissen/teilweise gezeigten CASE OF Anweisung umsetzen.

 

[ZottelMD]

Zuviel Werbung?
-> Hier kostenlos registrieren

Durch einen Fehler bei der Benutzerverwaltung, scheinbar meinerseits, kann ich mich derzeit nicht mehr ins HMI / IPC einloggen und lasse die Runtime derzeit auf meinem privaten Laptop laufen. Heißt PC/PG und HMI sind ein Gerät und neben mit befindet sich die Anlage (PLC) oder an Wochenenden eben über PLC Simulieren. Auf dem IPC muss ich erst wieder Windows drüber bügeln (Windows Restore DVD) und dann alles neu einrichten.

 

[ZottelMD]

Projekt hast du einmal komplett übersetzt und geladen? Also nicht nur teilübersetzt? Startet du mehrere Skripte?
Hast du evtl auch While Schleifen in Skripten?

Auf jeeeeeden Fall, ich mache es sicherheitshalber noch einmal aber in der Regel Übersetze ich immer komplett, weil ich immer auf Nummer sicher gehen will und die Zusammenhänge zu wenig verstehe ^^

Theoretisch starte ich zwei Scripte. Ich habe ein sehr ähnliches Script für eine Ampelanzeige, bzw ein Pop Up mit Ampelanzeige, was dem Benutzer im Kart Sitzend signalisieren soll, wann er Gas geben muss und wann nicht. Dieses Pop Up starte ich ganz analog mit Wertänderung einer Variablen, die ebenfalls zyklisch fortlaufend projektiert ist. Wenn in dieser Variablen wieder ein bestimmtes Bit gesetzt ist, ploppt die Ampel auf

Mein Prjektbaum zeigt alle Scripte die ich zukünftige gern benutzen will


Alle Scrippte mit der Kennzeichnung S01 oder S02 oder S03 beschäftigen sich mit dem Datenexport meiner Prozesswerte in eine MS SQL Datenbank. Die gestern vorgestellte Variable
"Vars".SQL.dbActionBytesoll bitweise genau das Ausführen der EInzelnen Scripte triggern. Die Scripte kommen nicht von mir, ich habe die aus einem Anwendungsbeispiel kopiert und bearbeite die so, dass ich sie "programmatisch" benutzen kann. Ursprünglich will jedes Script durch einen Tastendruck ausgeführt werden, was ohne Probleme funktioniert, wie gestern beschrieben. Ich hatte vor durch das besagte Byte z. B. mit 0000 0001 eine Datenbank zu erstellen, mit 0000 0010 eine Datenbank zu löschen, mit 0000 0100 eine Tabelle zu erstellen, .. usw. Mit dem 5. Bit, das was ich gestern vorstellte, will ich Werte in die Tabelle schreiben.

NAch den bisherigen Hinweisen von mehreren Scripten, der Probleme, die das mit sich bringt, könnte ich natürlich mindestens ALLE Datenbank scripte zu einem langen verwursten und mit mehreren Fallunterscheidungen im Script arbeiten, um die verschiedenen Aktionen zu triggern. Das würde ich auch umsetzen, wenn wir hier das Problem gelöst haben. Das "S03_bit_triggered_write"-Script ist das erste, was ich von der Vorlage adaptiert habe, bzw es versuche. Wenn das also mal funktioniert fliegt das normale unveränderte Script aus der Übersicht wieder heraus (S03_Write_data_into_base). Nur das Ampel-Sscript und das S03_bit_triggered-Script werden aktuell über Wertänderung ausgeführt

Das Ampel-Script benutzt den gleichen, gestern vorgestellten Bit-Scan:

Sub S00_AmpelPopUp()
'
'
'
'
'
'0. Variable deklarieren
Dim w

'1. obools-Variable im Gesamten lesen
Set w = SmartTags("Measmnt_DB_obools")

'2. Variable auf bestimmtes Bit prüfen
If (w And 2^10) > 0 Then
  ' Vergleich ergibt WAHR, wenn das Bit 10 in w gesetzt ist
  ' -> folgende Akion wird ausgeführt:
  ' Ampel popt auf
  ShowPopupScreen "Ampel", 1050, 380, hmiOn, hmiAnimationOff, hmiMedium
Else
  ' Vergleich ergibt FALSE, wenn Bit 10 in w nicht gesetzt ist
  ' -> dann diese Aktion:
  ' Ampel verschwindet
  ShowPopupScreen "Ampel", 1050, 380, hmiOff, hmiAnimationOff, hmiMedium
End If

' Hinweis: "If (w And (1 << 9)) > 0 Then" wirft einen Fehler.
' Scheinbar kennt die SIEMENS-Syntax den links-shift Befehl aus VB
' nicht. Deswegen mit "... And 2^10" gelöst

End Sub

Die zugehörigen Einstellungen der zugehörigen HMI-Variable sind wieder erwartungsgemäß einfach.

 

[ZottelMD]

und


Eine weitere Frage von DeltaMike war, ob ich Schleifen benutze. Nein sowas vermeide ich eigentlich immer, weil ich da ganz schnell die Übersicht verliere, wann ich in welcher Schleife feststecke. Am liebsten nutze ich analog der Programmier-Empfehlung von Siemens (SCL) immer Case Of oder If ELse

 

[PN/DP]

Zuviel Werbung?
-> Hier kostenlos registrieren

' Hinweis: "If (w And (1 << 9)) > 0 Then" wirft einen Fehler.
' Scheinbar kennt die SIEMENS-Syntax den links-shift Befehl aus VB
' nicht. Deswegen mit "... And 2^10" gelöst

Das liegt nicht an Siemens, weil die Skripte verwenden das Microsoft VBS und nicht VB. Zwischen VBS und VB bestehen doch eine ganze Menge auch größere Unterschiede, das muß man immer bedenken. Du müsstest Dich an die Dokumentation von VBS halten.

Harald

 

[ZottelMD]

Um unsere Glaskugeln zu bestätigen: Teile uns zuerst einmal mit, welche WinCC RT auf welchem Gerät Du da programmierst. TIA verwendest Du anscheinend Version V15.1?
...
Harald

Huhu,

genau ich benutze TIA v15.1, glaube sogar, dass ich vor wenigen Wochen auf Update 5 hochgerüstet habe.
Gleichzeitig benutze ich WinCC RT Advanced. Auf der zugehörigen Installations CD steht ebenfalls v15.1 drauf. Falls noch mehr Detail-Informationen über Version oder wasauchimmer notwendig sind, müsstest du noch einmal schreien. Bis jetzt wüsste ich nicht, wie ich die ohne Weiteres einsehen kann.

In WinCC Comfort/Advanced kann nur genau 1 Skript "gleichzeitig" laufen.
Wenn Du Skripte mit Buttons aufrufen kannst, bei anderen Ereignissen werden die Skripte aber nicht aufgerufen, dann kommt meistens das Ereignis nicht. Entweder wird die Variable gar nicht aktualisiert, die den Skript-Aufruf triggern soll, oder das gewünschte Ereignis wird generell nicht ausgelöst, z.B. Wertänderungen durch Zuweisungen an interne Variablen lösen keine Ereignisse aus (Loop-Breaker).

Wenn das so ist, dann muss ich auf jeden Fall versuchen, bzw umsetzen, dass ich im Gesamten nur ein Script mit Wertänderung-Funktionalität habe. Ich könnte das vorhin vorgestellt Bit, zum Triggern des Ampel-PopUps eventuell mit ins Byte zum Triggern der Datenbank-Scripte hereinnehmen. In der "ActionByte"-Variable habe ich ja 8 Bits, wovon, nach den bisherigen Überlegungen 5 Bit für die Datenbank-Anweisungen genutzt werden, dann könnte ich die Aampel auf Bit 6, 7 oder 8 packen.
Das probiere ich auf jeden Fall gleich aus. Falls das irgendwas ändert, melde ich mich sofort.

Warum setzt Du den einen "Zyklisch fortlaufend"-Erfassungszyklus auf 500ms? Ist das was Du tun willst irgendwie zeitkritisch?
Was erhoffst Du Dir mit dem Aufruf von "AktualisiereVariable"?

Zweites zuerst: wie gesagt, das AktualisiereVariable war nur aus der Verzweifulung ausprobiert wurden. Schon im Eingangspost hab ich ja erwähnt, dass es auch ohne die zweite Funktion AktualisiereVariable nicht funktioniert.
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. Geringer kann ich nur mit 500 ms und 100 ms wählen, wie ich eingangs beschrieben hatte. Um nicht ganz aggressiv an wirklich fortlaufend heran zu gehen, habe ich defensiv 500 ms statt 100 ms gewählt, um eine mögliche Kommunikationslast nicht zu sehe hochzutreiben. ?!?!?

Etwas zeitkritisches? Ich weiß nicht. Mir fehlt das know how, um darauf qualitativ antworten zu können.
Ich kann nur sagen, dass meine Servos mit DSC laufen sollen und spätestens wenn ich irgendwann mal die Lageregelung hinbekomme (siehe verlinkter Thread 4 oder 5 Post zuor), dann wird DSC genutzt. Generell arbeiten Antriebe und Steuerung somit also zeitsynchron, wenn ich das richtig verstehe. Man wird gezwungen Taktsychronität zu projektieren. Insofern denke ich, dass alles, was nicht mit Antriebsbefehlen zwischen PLC und CU oder zwischen CU und Servos zu tun hat, irgendwie stört und die Kommunikationslast erhöht.

Ich beobachte z. B. wenn ich Messwerte aus den Servo-TOs "abtasten will", dass mich Weckalarm OB's absolut nur sehr schlechte zeit-äquidistante Abstände realisieren kann. Sage ich z. B. Weckalarm alle 10 ms, dann beobachte ich im Trace mal 10 ms, dann 8 ms, dann 18 ms, dann 2 ms usw. Obwohl mein Programm nun wirklich nicht groß ist oder Schelifen enthält oder sowas. Kann das Projekt auch gern mal teilen, falls jemand interesse hat.
Mit einem time-delay interrupt den ich mit der Anweisung SRT_DINT im OB1 starte und die sich dann im OB20 immer selbst aufruft fahre ich etwas besser und kriege bessere äquidistante "Abtastungen". Gleichzeitig habe ich die Prioritäten stets hoch gesetzt auf 15, 16, 17 usw. Meine eingestellte Mindestzykluszeit ist 2 ms. In Diagrnose ansicht sehe ich aber immer wieder, dass der maximale Zyklus irgendwo bei 30 - 70 ms Sekunden liegt.

Bei all dem versteh ich aber die Zusammenhänge stets zu wenig, was genau man darf und was genau man muss um super performante Steuerungen zu realisieren.

 

[ZottelMD]

Ich hasse es, wie mich das Forum immer während des SChreibens ausloggt. Beim Absenden plobbt dann der Anmeldebildschirm auf, man klickt auf anmelden und PAM alle Umlaute sind falsch kodiert und werden falsch angezeigt. Sorry dafür !!!

 

[ZottelMD]

Zuviel Werbung?
-> Hier kostenlos registrieren

Das liegt nicht an Siemens, weil die Skripte verwenden das Microsoft VBS und nicht VB. Zwischen VBS und VB bestehen doch eine ganze Menge auch größere Unterschiede, das muß man immer bedenken. Du müsstest Dich an die Dokumentation von VBS halten.

Harald

Das ist auf jeden Fall ein sehr guter Hinweis, das schreib ich mir hinter die Ohren und speichere mir gleich mal ein neues Lesezeichen ab. Danke

 

[DeltaMikeAir]

Bis jetzt wüsste ich nicht, wie ich die ohne Weiteres einsehen kann.

..........

 

[ZottelMD]

Guten Morgen,

Wenn das Script über den Button gestartet wird und funktioniert, dann muss es auch über einer Wertänderung der Variable getriggert werden können.
Hast Du schon mal versucht, die Variable in ein Ausgabefeld eines Bildes zu setzen und bleibst einfach testweise in dem Bild, damit Du zum einen sehen kannst, wie sich die Variable ändert und ob dann das Script getriggert wird.
Wir verwenden so ein Handling (zyklisch fortlaufend lesen im Hintergrund) auch schon seit längerem und das funktioniert eigentlich problemlos...

Nein das habe ich afaik noch nicht versucht, das probiereich auch gleich einmal aus. Ich füge die gestern Vorgestellte Variable ..ActionByte.. einfach mal durch ein EA-Feld in jene HMI Abbildung ein, in der ich die Messung 1 starte. Das ist dann jene Messung in der das Bit ...ActionByte.%X4 HIGH gesetzt wird. Das müsste dann als Wertänderung erkannt werden und automatisch im E/A-Feld mit HEX#10 angezeigt werden. Möglicherweise hilft das vorhanden Sein dieser Varible auf dem aktuellen Bild schon, um die Wertänderung korrekt zu tracken. Ich gebe Rückmeldung

Früher habe ich auch oft parallel "DebugView" von Sysinternals laufen lassen.
Dann kann man im Script mit dem Befehl "HmiRuntime.Trace" eine Ausgabe von Texten und auch Variablenwerten in den Debugger schreiben.
Das finde ich praktischer als die Verwendung von "ShowSystemAlarm", da man dann in einem separaten Fenster die Ereignisse mit Zeitstempel gelistet bekommt und das dann in Ruhe anschauen kann, was genau wann passiert ist!

Stimme ich vermutlich vollkommen zu. Aber ich befürchte dafür fehlt mir die Zeit, um mich da noch einzuarbeiten und das richtig zu gebrauchen. Ich bin schon über 1 Jahr an der Masterarbeit dran, habe viel gemacht, was man nicht sieht, was nicht wirklich reprsäentaitv ist oder vom Hocker haut, aber notwendig war. Allerdings muss ich die Funktionalität der 3 Messungen so schnell wie möglich zum Laufen bekommen, am besten gerstern. Die sind ein bisschen verkaufbarer und Werten meine Arbeit auf. Theoretisch sollte ich am 31.03.21 fertig sein. Ich denke aus diesem Grund reicht mir der Meldungsbefehl in meinem Script völlig aus, zumal er eh wieder rausfliegt, wenn alles läuft. =)

Entgegen der Aussage von SIEMENS funktioniert das auch bei "ADVANCED", zumindest wenn ich zum Test die Runtime auf dem Erstell-PC starte (da will ich ja auch testen). Sollte aber auf dem Zielsystem (Windows) genauso funktionieren.

Anhang anzeigen 54311

P.S.: nimm doch "Aktualisiere Variable" aus der Funktionsliste raus. Das mach überhaupt keinen Sinn. Die Variable wurde doch soeben aktualisiert (zyklisch lesen) und hat damit die Wertänderungsereignisse getriggert. Hat ja auch schon PN/DP gemeint...
Grüße

Zu Ersterem: wohl möglich =) aber hier gilt gleiches wie zuvor. Lieber den uncooleren Weg, sofern er nicht andere Sachen behindert.
zu Zweiterem: kann mich nur wiederholen "Aktualisiere Variable" war zu Beginnn nicht drin und ist nur aus der Verzweifelung, weil irgendwie in irgendeinem Fred aufgeschnappt, herein gerutscht. Reiner Test-Zweck. Die Diagnose und das Fehlerbild ist mit und ohne gleich. Ich bestehe nicht darauf, dass es drin bleiben muss, ganz und gar nicht, aber versucht nicht immer wieder über offensichtliche Sachen zu stolpern, wenn ich eingangs dazu schrieb a la "mit und ohne wurden überprüft, beides klappt nicht. war nur testweise drin ..." Das müsste eigentlich suggerieren, dass es nur ein debuggin versuch ist.

Grüße zurück