TIA Datenbaustein laufend erweitern und Inhalt abfragen

Zuviel Werbung?
-> Hier kostenlos registrieren
Es sind maximal 5500 Nummern mit je einem Wert dahinter.

Vielleicht zur Erläuterung:

Ich habe hierfür schon eine Rezepturverwaltung erstellt, welche andere, fest Prozessprameter für den jeweiligen Datensatz enthält. Hier habe ich 11 Rezepturen mit jeweils 500 Datensätzen in dem HMI angelegt.

Das funktioniert soweit ganz gut. Nun kam die Anforderung das das ganze um den Barcodescanner und einen weiteren Parameter ergänzt werden soll. Dieser Parameter *oben „Wert“ genannt, muss aber auf das Vorhandensein abgefragt werden. Da ich hier in dem HMI nicht weitergekommen bin, dachte ich, es wäre vielleicht eher denkbar diesen speziellen Fall in der SPS zu lösen um nachher die restliche Rezepturverwaltung ebenfalls direkt in der SPS zu lösen. Allerdings habe ich den Speicherplatz auch nicht bedacht, in dem HMI ist eine relativ große Speicherkarte vorhanden.
 
Es sind maximal 5500 Nummern mit je einem Wert dahinter.
Gut, das ist nicht viel und eine S7-1200 kommt damit relativ problemlos klar. Lege ein Array of Struct für 5500 bis 6000 Einträge in einem DB an und schreibe nach und nach die neuen Datensätze da hinein. Den DB brauchst Du dann zur Laufzeit nicht erweitern.

Wie wertvoll bzw. wichtig sind die Datensätze? Was würde passieren, wenn die Datensätze plötzlich weg/gelöscht wären? Eine SPS ist nicht für Langzeit-Speicherung von dynamisch erfassten Daten geeignet. Eventuell brauchst Du auch noch eine Lösung zur externen Sicherung/Backup der Daten?

Harald
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
Gut, das ist nicht viel und eine S7-1200 kommt damit relativ problemlos klar. Lege ein Array of Struct für 5500 bis 6000 Einträge in einem DB an und schreibe nach und nach die neuen Datensätze da hinein. Den DB brauchst Du dann zur Laufzeit nicht erweitern.

Wie wertvoll bzw. wichtig sind die Datensätze? Was würde passieren, wenn die Datensätze plötzlich weg/gelöscht wären? Eine SPS ist nicht für Langzeit-Speicherung von dynamisch erfassten Daten geeignet. Eventuell brauchst Du auch noch eine Lösung zur externen Sicherung/Backup der Daten?

Harald
Ja die Datensätze sind schon sehr wichtig. Gibt es denn eine Möglichkeit die Daten zu sichern?

Am liebsten hätte ich eine Datenbank dahinter, die extern läuft und von wo aus sich die Steuerungen über die Artikelnummern im Handshake die Daten holen. Leider übersteigt das komplett das Budget der Anlage. Oder gibt es günstige Tools die sich nur auf die Rezept Übertragung beschränken ?
 
Gut, das ist nicht viel und eine S7-1200 kommt damit relativ problemlos klar. Lege ein Array of Struct für 5500 bis 6000 Einträge in einem DB an und schreibe nach und nach die neuen Datensätze da hinein. Den DB brauchst Du dann zur Laufzeit nicht erweitern.

Wie wertvoll bzw. wichtig sind die Datensätze? Was würde passieren, wenn die Datensätze plötzlich weg/gelöscht wären? Eine SPS ist nicht für Langzeit-Speicherung von dynamisch erfassten Daten geeignet. Eventuell brauchst Du auch noch eine Lösung zur externen Sicherung/Backup der Daten?

Harald
Gibt es für solche Anwendungsfälle eine Art Rezepturmanager von Siemens der solche Aufgaben erfüllen kann? Oder wird dies immer selbst gelöst bzw. Gleich mit einem riesigen übergeordneten System? Ich meine das ändern bzw. Bereitstellen von Rezepturdaten ist doch keine Besonderheit oder ?

Hilft vielleicht eine OPC UA Software die diese Dinge managen kann? Habt ihr so etwas schon extern gelöst?
 
Das heißt, ich könnte durch eine Schleife den Datenbaustein durchsuchen und wenn die Nummer vorhanden ist, den Wert nutzen. Falls nicht, kopiere ich den Inhalt des alten DB in einen neuen DB und ergänze die neue Nummer.
Vermeintlicher Vorteil:
- der DB / die DBs wäre( n ) nie länger, als er / sie gerade benötigt wird / werden.
Nachteile:
- wenigstens kurzzeitig wird doppelt so viel Speicher benötigt, wenn nämlich die Vorlage noch vorhanden ist und die Kopie davon gerade angelegt wird.
- das Umräumen (Kopieren) der möglicherweise umfangreichen Daten beschäftigt unnötig die PLC (--> ZyklusZeit).
Wo liegt hierbei der Unterschied dazu, den Alten DB zu aktualisieren? Damit das Array nicht auf die Bsp. 10000 Plätze begrenzt ist?
Vorteile:
- Du sprichst immer nur denselben DB bzw. dasselbe Array an - dadurch ersparst Du Dir "Verrenkungen" im Programm.
- Der eine DB mit dem einen Array kann - wie oben gesagt - doppelt so gross angelegt werden.
- Die vermeintliche Verschwendung durch sehr grosse Reserven "frisst kein Brot", sondern kostet wahrscheinlich nur ein wenig Überwindung (z.B. heute entscheiden zu müssen, was sich erst viel später klären wird?).
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Gut, das ist nicht viel und eine S7-1200 kommt damit relativ problemlos klar. Lege ein Array of Struct für 5500 bis 6000 Einträge in einem DB an und schreibe nach und nach die neuen Datensätze da hinein. Den DB brauchst Du dann zur Laufzeit nicht erweitern.

Wie wertvoll bzw. wichtig sind die Datensätze? Was würde passieren, wenn die Datensätze plötzlich weg/gelöscht wären? Eine SPS ist nicht für Langzeit-Speicherung von dynamisch erfassten Daten geeignet. Eventuell brauchst Du auch noch eine Lösung zur externen Sicherung/Backup der Daten?

Harald

Hallo ich muss mich korrigieren.
Nach dem Umzug von allen Parametern aus der Rezepturverwaltung wäre. Es ca. 5500 Datensätze mit jeweils 6 Parametern.


Ich habe heute aber noch einen anderen Weg in Betracht gezogen, wäre dieser denkbar?

1. Barcode wird eingescannt und Nummer in DB geschrieben

2. Handshake:
Barcodescanner gibt Signal „Barcode gelesen“ aus und SPS senden „empfangen“ zurück (mit dem Barcodescanner möglich).

3. SPS ermittelt die richtige Rezeptur (von 11 Rezepturen) anhand von eingescannter Nummer (Rezepturen sind nach den Nummern sortiert)

4. SPS sendet den Steuerungsauftrag 70 mit der passenden Rezeptur und dem passenden Datensatznamen (=Nummer von Scanner)

5. Handshake: HMI sendet „Auftrag empfangen“ und Status (evtl. Datensatz nicht vorhanden, Kommunikationsfehler, etc.), SPS quittiert. => Ist dies möglich?

6. Wenn das Laden erfolgreich war, dann überprüft die SPS ob der dynamische „Wert“ größer als Null ist (0=nicht vorhanden).

Falls ja, kann das Produkt gefertigt werden.

Falls nein, öffnet sich eine Maske um den Wert einzugeben (E-A-Feld). Ist dies geschehen, wird der Steuerungsauftrag 69 (Datensatz speichern) angewendet, um den fertigen Datensatz abzuspeichern.

Jetzt kann das Produkt ebenfalls gefertigt werden und der fehlende Wert steht bei dem neuen auswählen gleich im Rezept.

Wenn nun ein neuer Barcode gescannt wird, geht es von vorne los.

Ist dies eine denkbare Lösung? Somit wäre der Archivierungsprozess noch in dem HMI vorhanden und die Daten durch Backups sicher.
 
5. Handshake: HMI sendet „Auftrag empfangen“ und Status (evtl. Datensatz nicht vorhanden, Kommunikationsfehler, etc.), SPS quittiert. => Ist dies möglich?
Jein.
"Auftrag empfangen" wäre wenn das HMI den Steuerungsauftrag wieder auf 0 schreibt.
Ein Feedback, z.B. über einen Statuscode, hat der Steuerungsauftrag so direkt nicht (soweit ich weiß).
Eine Quittierung ob der Rezeptwechsel korrekt umgesetzt wurde (Datensatz vorhanden) könntest du umsetzen, indem du die Rezept/Datensatzvariable in der SPS abfragst & mit deinem Auftrag vergleichst.


Ich habe hierfür schon eine Rezepturverwaltung erstellt, welche andere, fest Prozessprameter für den jeweiligen Datensatz enthält. Hier habe ich 11 Rezepturen mit jeweils 500 Datensätzen in dem HMI angelegt.

Das funktioniert soweit ganz gut. Nun kam die Anforderung das das ganze um den Barcodescanner und einen weiteren Parameter ergänzt werden soll. Dieser Parameter *oben „Wert“ genannt, muss aber auf das Vorhandensein abgefragt werden.
Falls nein, öffnet sich eine Maske um den Wert einzugeben (E-A-Feld). Ist dies geschehen, wird der Steuerungsauftrag 69 (Datensatz speichern) angewendet, um den fertigen Datensatz abzuspeichern.

Verstehe ich das korrekt, dass du bei einem noch nicht in der Rezeptur vorhandenen Datensatz diesen dann neu anlegen möchtest?
Ich würde spontan vorschlagen per Steuerungsauftrag "Bildwechsel" auf ein Eingabebild zu springen & das Neuanlegen des Datensatzes dann dort vom Bediener machen zu lassen.
Du musst ja nicht zwingend die Rezepturanzeige von TIA nehmen, sondern kannst dir per E/A-Felder & Rezepturbefehle an ein paar Schaltflächen was auf das notwendigste reduzierte stricken.
 
Hallo,

Ich bin nun ein Stück weiter. Folgender Weg funktioniert aktuell:

1. Barcode wird gescannt
2. Es wird bestimmt aus welcher Rezeptur der Datensatz kommt
3. Der Name wird in eine Variable geschrieben
4. Es wird ein Triggerbit gesetzt. Auf Wertänderung wird der Rezepturname und der Datensatzname mit der Funktion "LadeDatensatz" geladen
5. Wenn Status "4" zurück kommt, dann ist alles in Ordnung

Soweit so gut, leider funktioniert die Änderung eines Datensatzes nicht.
Über das Triggerbit soll die Funktion "SpeichereDatensatz" angestoßen werden. Hier habe ich die Eigenschaften genau wie oben konfiguriert, und das Überschreiben "Nach Bestätigung" eingestellt. Wenn ich nun das Bit ändere, dann ändert sich der Status auf "2" (in bearbeitung) und es kommt das Abfrage Fenster. Wenn ich nun mit JA bestätige, wird der Datensatz nicht gespeichert und der Status ändert sich auf 12 (Fehler).
Woran kann das denn liegen? Der Vorgang wird doch komplett angestoßen und richtig abgefragt, Hier die Konfigurationen:

1687206321270.png

1687206571295.png

1687206376767.png

1687206502146.png
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Noch ein Hinweis:

Ich bekomme zwischendurch die Fehlermeldung: "Datensatzbearbeitung nicht möglich, da bereits eine Rezepturaktion läuft."

Wie kann ich denn eine Aktion beenden?

EDIT: Ich glaube diese Fehlermeldung kommt immer nur, wenn ich wiederholt einen trigger auslöse. Als ohne vorher die Bestätigung des überschreibens zu aktivieren. Diese Meldung scheint uninteressant zu sein.
 
Zuletzt bearbeitet:
Ich bekomme zwischendurch die Fehlermeldung: "Datensatzbearbeitung nicht möglich, da bereits eine Rezepturaktion läuft."

Wie kann ich denn eine Aktion beenden?

EDIT: Ich glaube diese Fehlermeldung kommt immer nur, wenn ich wiederholt einen trigger auslöse. Als ohne vorher die Bestätigung des überschreibens zu aktivieren. Diese Meldung scheint uninteressant zu sein.

Wenn eine Rezepturbefehl auf Status 12/Fehler springt, bekommst du (normalerweise) immer eine Systemmeldung was genau das Problem war.
Vorausgesetzt natürlich, dass ein Meldefenster für die Systemmeldungen projektiert ist.
In deinem Fall:
"Datensatzbearbeitung nicht möglich, da bereits eine Rezepturaktion läuft."

Wie kann ich denn eine Aktion beenden?
Direkt eine Aktion aus einer anderen Aktion abbrechen geht (glaube ich) nicht.

Ich halte es für gefährlich Rezepturaktionen über Bit-Trigger auszulösen.
Zum einen wird bei Trigger "Wertänderung" die Aktion zwei mal ausgeführt wenn es sich um einen Puls handelt (Wechsel 0 => 1 & wieder bei 1 => 0).
Wenn du einfach den Wert invertierst, kann bei Verbindungsverlust die Triggervariable von 1 auf 0 wechseln & die Aktion nochmal ungewollt auslösen.
Zudem musst du SPS-seitig gewährleisten, dass immer nur eine Rezepturaktion gleichzeitig läuft.

Vorschlag:
Rufe am Triggerbit ein Script auf, dass die eigentliche Aktion auslöst.
Dann kannst du die Ausführung bei Bedarf recht simpel gegen andere Zustände verriegeln.
Z.B. Ausführung der Aktion nur bei positiver Flanke.
 
Wenn eine Rezepturbefehl auf Status 12/Fehler springt, bekommst du (normalerweise) immer eine Systemmeldung was genau das Problem war.
Vorausgesetzt natürlich, dass ein Meldefenster für die Systemmeldungen projektiert ist.
In deinem Fall:



Direkt eine Aktion aus einer anderen Aktion abbrechen geht (glaube ich) nicht.

Ich halte es für gefährlich Rezepturaktionen über Bit-Trigger auszulösen.
Zum einen wird bei Trigger "Wertänderung" die Aktion zwei mal ausgeführt wenn es sich um einen Puls handelt (Wechsel 0 => 1 & wieder bei 1 => 0).
Wenn du einfach den Wert invertierst, kann bei Verbindungsverlust die Triggervariable von 1 auf 0 wechseln & die Aktion nochmal ungewollt auslösen.
Zudem musst du SPS-seitig gewährleisten, dass immer nur eine Rezepturaktion gleichzeitig läuft.

Vorschlag:
Rufe am Triggerbit ein Script auf, dass die eigentliche Aktion auslöst.
Dann kannst du die Ausführung bei Bedarf recht simpel gegen andere Zustände verriegeln.
Z.B. Ausführung der Aktion nur bei positiver Flanke.
Sehr gute Idee, leider habe ich keine Erfahrungen mit dem Script. Kann ich dort auch einfach die Funktionen aufrufen, wie z.B. LadeDatensatz?

Gibt es einen Guide bzw. eine Anleitung für das Scripten mit der Rezepturverwaltung?
 
Zuviel Werbung?
-> Hier kostenlos registrieren
1687334802910.png

Im Scripteditor kannst du dir rechts eine Funktionsliste wie gewohnt zusammen stellen & dann per "übernehmen" ins Script kopieren.
Ich benutze das ganz gerne, da im Script die Systemfunktionen in englisch angegeben werden müssen, im Rest von Tia aber in deutsch verwendet werden.
Bin auch nicht oft genug mit VBS unterwegs um die Funktionen mit korrekten Parametern alle auswendig zu können ¯\_(ツ)_/¯

Das Script taucht dann im Ereignis-Dialog bei den anderen Systemfuktionen auf.

Des weiteren zu Scripts:
Ein paar Tipps&Tricks die vllt noch hilfreich sein könnten
https://support.industry.siemens.co...skripten-in-wincc-(tia-portal)?dti=0&lc=de-WW
Übersicht über die Systemfunktionen im Script
https://support.industry.siemens.com/cs/mdm/109755216?c=115244270475&lc=de-WW
Grundlegendes zum Sprachumfang der von Siemens verwendeten VBS-Version (gibt große Unterschiede zur neusten VBS Version, weshalb viele Tipps von Onkel Google nicht im TIA funktionieren)
https://learn.microsoft.com/en-us/previous-versions//t0aew7h6(v=vs.85)?redirectedfrom=MSDN

Extra Scriptfunktionen für die Rezeptverwaltung in VBS gibt es so direkt nicht.
Du benutzt die normalen Systemfunktionen von Siemens, nur eben im Script wo sie (weil englisch) etwas anders benannt sind.
=> Funktionsliste hilft bei Auswahl & parametrierung.

Für deinen Fall wäre folgendes Script am Triggerbit möglich:
-----------------------------------------------------------------
IF SmartTags("Triggerbit") = TRUE then
//Diesen Code ausführen
End if
-----------------------------------------------------------------

Dieses Script hängst du dann an das Wertänderungs-Ereignis der Variable "Triggerbit".
Damit wird der Code in der IF-Anweisung nur bei Wertänderung & wenn Triggerbit = TRUE ist ausgeführt => positive Flanke.
 
Vielen Dank.

Der Fehler von oben ist behoben, bei der Rezeptur fehlte die Einstellung „Rezepturvariablen abgleichen“.

Allerdings werde ich das mit dem Script auf jeden fall ausprobieren und mich dann nochmal zurück melden.
 
Anhang anzeigen 69635

Im Scripteditor kannst du dir rechts eine Funktionsliste wie gewohnt zusammen stellen & dann per "übernehmen" ins Script kopieren.
Ich benutze das ganz gerne, da im Script die Systemfunktionen in englisch angegeben werden müssen, im Rest von Tia aber in deutsch verwendet werden.
Bin auch nicht oft genug mit VBS unterwegs um die Funktionen mit korrekten Parametern alle auswendig zu können ¯\_(ツ)_/¯

Das Script taucht dann im Ereignis-Dialog bei den anderen Systemfuktionen auf.

Des weiteren zu Scripts:
Ein paar Tipps&Tricks die vllt noch hilfreich sein könnten
https://support.industry.siemens.com/cs/document/57132412/tipps-und-tricks-für-das-erstellen-von-skripten-in-wincc-(tia-portal)?dti=0&lc=de-WW
Übersicht über die Systemfunktionen im Script
https://support.industry.siemens.com/cs/mdm/109755216?c=115244270475&lc=de-WW
Grundlegendes zum Sprachumfang der von Siemens verwendeten VBS-Version (gibt große Unterschiede zur neusten VBS Version, weshalb viele Tipps von Onkel Google nicht im TIA funktionieren)
https://learn.microsoft.com/en-us/previous-versions//t0aew7h6(v=vs.85)?redirectedfrom=MSDN

Extra Scriptfunktionen für die Rezeptverwaltung in VBS gibt es so direkt nicht.
Du benutzt die normalen Systemfunktionen von Siemens, nur eben im Script wo sie (weil englisch) etwas anders benannt sind.
=> Funktionsliste hilft bei Auswahl & parametrierung.

Für deinen Fall wäre folgendes Script am Triggerbit möglich:
-----------------------------------------------------------------
IF SmartTags("Triggerbit") = TRUE then
//Diesen Code ausführen
End if
-----------------------------------------------------------------

Dieses Script hängst du dann an das Wertänderungs-Ereignis der Variable "Triggerbit".
Damit wird der Code in der IF-Anweisung nur bei Wertänderung & wenn Triggerbit = TRUE ist ausgeführt => positive Flanke.
So es läuft alles sehr gut, allerdings hat sich noch ein Problem eingeschlichen. Ich habe das Script fertig und der Datensatz wird in die SPS geladen. In der SPS frage ich nach Status 4 ab und es klappt zu 70% super.
Zwischendurch kommt es allerdings vor, das der Befehlen schreibedatensatzinsteuerung ausgeführt wird, sich die Rezeptur Variable aber nicht ändert. Dieses Verhalten taucht sporadisch auf und ich finde nicht heraus warum das so ist.
Der Status 4 kommt immer passend zurück.
Habt ihr eine Idee ?
 
Ohne das Skript und den SPS-Code zu sehen wird es wohl schwierig.
Skript: (ich habe den Code nicht mehr vorliegen und die Syntax nicht im Kopf, deswegen hier der Aufbau, sollte aber verständlich sein.)

Code:
IF SmartTags("Load") = TRUE then

SchreibeDatensatzInSteuerung
(Rezepturname,Datensatzname,0, Status)

End if

SPS:

(Status als „Inout“ deklariert und „Load“ als Out)


Code:
case „state“ of:

0:

"Status" := 0;
„Load“ := False;

If
"NeuesRezept"
Then
state := 1
End_If;

1:

„Load“ := True;

If
„Status“ = 4
Then
State := 0;

END_Case;


Ich reiche morgen noch den original Code nach. Es funktioniert wie gesagt fast immer, nur manchmal ändert sich der Status in 4 und die Rezeptvariablen werden nicht geändert.
 
SPS:

(Status als „Inout“ deklariert und „Load“ als Out)
Das klingt wie der Klassiker: HMI-Zugriff (ohne Zykluskontrollpunkt) unterbricht den FB/FC und ändert "Status", aber der FB/FC überschreibt die Änderungen der HMI.

Das musst Du morgen mal genauer darstellen. Geht es hier immer noch um eine S7-1200? Ist der Baustein ein FB oder FC? "Optimiert" oder Standard-Zugriff? Datentyp von Status und Load? Schreibt die HMI direkt auf Inout/Out-Instanzvariablen oder sind die Inout/Out beim Aufruf der Instanz mit Variablen verschaltet und die HMI schreibt/liest die verschalteten Variablen? Liegen die verschalteten Variablen in "optimiertem" oder "Standard-Zugriff" Speicher?
Weil die HMI-Kommunikation ohne Zykluskontrollpunkt kommuniziert, gilt wie immer bei Multitasking: die Variablen von/zu HMI dürfen im Zyklus nur genau einmal gelesen und genau einmal beschrieben werden. Es muß quasi ein für den Zyklus konsistentes "Prozessabbild der HMI-Kommunikation" erstellt werden. Eventuell muß ein multitasking-geeignetes Handshake implementiert werden.

Harald
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Das klingt wie der Klassiker: HMI-Zugriff (ohne Zykluskontrollpunkt) unterbricht den FB/FC und ändert "Status", aber der FB/FC überschreibt die Änderungen der HMI.

Das musst Du morgen mal genauer darstellen. Geht es hier immer noch um eine S7-1200? Ist der Baustein ein FB oder FC? "Optimiert" oder Standard-Zugriff? Datentyp von Status und Load? Schreibt die HMI direkt auf Inout/Out-Instanzvariablen oder sind die Inout/Out beim Aufruf der Instanz mit Variablen verschaltet und die HMI schreibt/liest die verschalteten Variablen? Liegen die verschalteten Variablen in "optimiertem" oder "Standard-Zugriff" Speicher?
Weil die HMI-Kommunikation ohne Zykluskontrollpunkt kommuniziert, gilt wie immer bei Multitasking: die Variablen von/zu HMI dürfen im Zyklus nur genau einmal gelesen und genau einmal beschrieben werden. Es muß quasi ein für den Zyklus konsistentes "Prozessabbild der HMI-Kommunikation" erstellt werden. Eventuell muß ein multitasking-geeignetes Handshake implementiert werden.

Harald
Genau, es ist eine S7-1200.
Der Baustein ist ein FB. Das HMI schreibt auf die Variablen in einem Globalen DB, welcher optimiert ist. Die Globalen Variablen werden im OB1 an den FB übergeben.

We genau kann ich denn dieses handshake implementieren? Gibt es hierfür Beispiele die du mir zeigen kannst?
 
Ich habe einen vermeintlichen Erfolg, ich habe den optimierten zugriff ausgestellt und jetzt scheint es zu funktionieren. Kann mir dies einer erklären?
 
Ich habe jetzt keine Zeit, nur kurz:
Ist der FB "optimiert" oder Standard-Zugriff? Ist die außen angeschaltete Variable in "optimiertem" oder Standardzugriff-Speicher? Ist der InOut-Parameter eine Struktur oder ein einfacher Datentyp?
Danach richtet sich, ob der InOut als Referenz (Call-by-reference) oder als Kopie (Call-by-value) übergeben wird.
(...)
Programmierleitfaden für S7-1200/S7-1500
Wenn bei einem Bausteinaufruf Strukturen als Durchgangsparameter (InOut) an den aufgerufenen Baustein übergeben werden, werden diese standardmäßig als Referenz übergeben (siehe Kapitel 3.3.2 Übergabe per Referenz (Call-by- reference)).
Dies gilt jedoch nicht, wenn einer der Bausteine die Eigenschaft "Optimierter Zugriff" und der andere Baustein die Eigenschaft "Standardzugriff" hat. Dann werden grundsätzlich alle Parameter als Kopie übergeben (siehe Kapitel 3.3.1 Übergabe per Wert (Call-by-value)).
Der aufgerufene Baustein arbeitet in diesem Fall immer mit den kopierten Werten. Während der Bausteinbearbeitung werden diese Werte möglicherweise verändert und nach Abarbeitung des Bausteinaufrufs wieder auf den ursprünglichen Operanden zurückkopiert.
Dies kann zu Problemen führen, wenn die ursprünglichen Operanden durch asynchrone Prozesse verändert werden, z.B. durch HMI-Zugriffe oder durch Alarm- OBs. Wenn nach der Bausteinbearbeitung die Kopien wieder auf die ursprünglichen Operanden zurückkopiert werden, werden dabei die asynchron durchgeführten Änderungen an den ursprünglichen Operanden überschrieben.

Harald
 
Zurück
Oben