TIA Zykluskontrollpunkt S7-1500

Erema

Level-1
Beiträge
57
Reaktionspunkte
3
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo,

Da ja bei der S7-1500 keinen zykluskontrollpunkt für S7 Verbindungen wie bei S7-300 gibt und es somit bei In/Out Variablen Probleme gibt wollte ich mal fragen ob schon wer dieses Problem gelöst hat?

Ausserdem hat mir der Siemens Support gesagt das wenn man eine Variable als Structur also struct,udt aufruft dieses Problem nicht geben darf da er ja dann mit call-by-reference übergeben wird. Hat jemand schon damit erfahrung?

Lg

Markus

Gesendet von meinem LG-E975 mit Tapatalk
 
Ausserdem hat mir der Siemens Support gesagt das wenn man eine Variable als Structur also struct,udt aufruft dieses Problem nicht geben darf da er ja dann mit call-by-reference übergeben wird.
Standarddatentypen werden am INOUT als Kopie (Call_by_Value) übergeben und werden am Ende (auch wenn im FB/FC nicht verändert) wieder zurückgeschrieben.
Bei UDTs und andere strukturierte Datentypen wird nur eine Referenz (Call_by_Referenz) übergeben. Dort wird beim Lesen und Schreiben im FB/FC jedesmal direkt vom Datenbaustein gelesen und geschrieben.
Hier siehst die welcher Datentyp wie übergeben wird.
https://support.industry.siemens.com/cs/de/de/view/109011420/71500818699

Variante 1 (Call_by_Value) hat das Problem das wenn die HMI den DB verändert während die CPU mitten im FB/FC ist, dann wird der Wert im DB am Ende des FB/FC wieder überschrieben.
Die HMI-Eingabe geht verloren.​
Variante 2 (Call_by_Ref) hat das selbe Problem wie im restlichen SPS-Programm. Liest du einen Wert zwei mal im FB kann es sein dass die HMI in inzwischen verändert hat-

Ist also irgendwie wie die Wahl zwischen Pest und Cholera.

Die Aussage vom Support ist eher etwas praxisfremd.
Es sollte ja kaum das Ziel sein dass man die Art und Weise wie man seine FB-Schnittstelle baut von den Eigenheiten der HMI-Kommunikation abhängig macht.
Keiner wird wenn er einen einfaches DWORD an einen INOUT übergeben will seinen Baustein auf STRUCT(DWORD) umbauen nur wegen dem HMI-Zyklus.
Des weiteren gibt es auch dann wieder Sonderfälle wenn bei der Übergabe von optimiert auf nicht optimiert gewechselt wird. Dann wird aus einem Call_by_Ref schnell wieder ein Call_by_Val.

Hat jemand schon damit erfahrung?
Wurde hier schon ausgiebig diskutiert. Suche einfach mal nach "Zykluskontrollpunkt" und sieh dir die TIA-Beiträge an...
http://www.sps-forum.de/simatic/71057-zykluskontrollpunkt-s7-1200-und-s7-1500-mit-hmi.html
http://www.sps-forum.de/simatic/68319-s7-1500-hmi-kommunikation-zykluskontrollpunkt.html
http://www.sps-forum.de/simatic/821...ndung-mit-absoluter-adressierung-zur-cpu.html


Da ja bei der S7-1500 keinen zykluskontrollpunkt für S7 Verbindungen wie bei S7-300 gibt und es somit bei In/Out Variablen Probleme gibt wollte ich mal fragen ob schon wer dieses Problem gelöst hat?
Eine "offizielle" Erklärung und Abhilfe gibt's hier.
https://support.industry.siemens.com/cs/de/de/view/109478253
Ob das hilfreiche Wege sind muss jeder selbst entscheiden.

Im Prinzip musst du als Programmierer jetzt im Hinterkopf haben wie dir die HMI in den Zyklus reinschreibt und entsprechend arbeiten.
  • Werte möglichst nur ein mal im Zyklus lesen und schreiben
  • HMI-Schreibzugriffe und SPS-Schreibzugriffe trennen (Sollwert und Rückmeldung)
  • Selber an gewissen Punkten Kopien von HMI-Sollwerten machen damit sich der während der Abarbeitung nicht ändert.
  • etc.

Sieh dir einfach ein paar Beiträge zu dem Thema an. Da wurden schon viele Vorgehensweisen gezeigt. Mehr Arbeit is es aber schon.
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
Generelle Empfehlung kann es natürlich keine geben.
Ich ziehe quasi eine Zwischenschicht ein und arbeite bei kritischen Daten nicht mit den direkten HMI-Variablen.

Wie ist es eigentlich bei Codesys oder Beckhoff?

Gruß
Dieter
 
Wie macht ihr dann wenn ein sollwert in der sps verändert wird? Diesen muss ich ja dann auch wieder auf den hmi db rückschreiben! Ich habe auch einen aufruf mit einer variable aus einen udt beschaltet, das verhalten mit überschreiben tritt trotzdem ab und zu auf jedoch nicht so oft wie wenn ich eine real direkt drauflege. Habt ihr eine idee woran das liegen kann?
Wir sind da gerade am entwickeln ser umstellung von s7-300 auf s7-1500 und ich möchte es jetzt sauber lösen nicht das dann probleme auftretten wenn ersten maschinen gebaut werden.

Danke

Lg markus

Gesendet von meinem LG-E975 mit Tapatalk
 
Ich habe auch einen aufruf mit einer variable aus einen udt beschaltet, das verhalten mit überschreiben tritt trotzdem ab und zu auf jedoch nicht so oft wie wenn ich eine real direkt drauflege.
Du übergibst einmal einen REAL und einmal einen REAL_AUS_STRUCT an einen FB-INOUT, hab ich den Satz richtig verstanden?
Könnte mir hier nicht vorstellen dass es einen Unterschied geben sollte, zumindest ist mir kein technischer Grund bekannt.
In diesem Fall wird beides mal als Kopie (per_Value) übergeben.

Was ich oben gemeint hatte war die Übergabe der ganzen Struktur/UDT an den INOUT. Damit meine ich also das die Deklaration des INOUT im FB selbst vom Typ Struct oder UDT ist.
Nur dort bekommt man die Übergabe als Referenz (per_Ref). Aber auch dort nicht immer. ;)

Wie macht ihr dann wenn ein sollwert in der sps verändert wird? Diesen muss ich ja dann auch wieder auf den hmi db rückschreiben!
Die CPU arbeitet mit einer internen Kopie des HMI-Sollwerts und schreibt nur bei Bedarf den HMI-Sollwert zurück.
PN-DP hat dazu schon mal ein schönes Beispiel gepostet.
http://www.sps-forum.de/simatic/710...nd-s7-1500-mit-hmi-post492881.html#post492881

Wir sind da gerade am entwickeln der umstellung von s7-300 auf s7-1500 und ich möchte es jetzt sauber lösen nicht das dann probleme auftretten wenn ersten maschinen gebaut werden.
Wie gesagt, dieses Systemverhalten muss man im Hinterkopf haben und seine Programmierweise entsprechend umstellen damit Konstrukte die eventuell Probleme machen könnten gar nicht entstehen.
Wenn man nämlich sowas in der Steuerung hat wo eine HMI-Eingabe in einem von zehntausend Fällen ein Problem erzeugt kann man das nur mehr schwer diagnostizieren.
Für 300er-Programmierer ist das eine größere Umstellung, die 400er-Jungs kratzt es wenig. Es gibt auch noch die "400er-happy-go-lucky"-Type, denen war das Thema immer schon egal/nicht bekannt.

Wenn ihr gerade vor der Umstellung die Unterschiede prüft, könnte man an der Stelle und an das geänderte Verhalten der TON/TOF/TP-Timer hinweisen.
http://www.sps-forum.de/simatic/79662-umstieg-auf-s7-1500-a-post601632.html#post601632
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
Aso wird es nur als reference übergeben wenn ich ganze struct oder udt übergebe? Habe beim siemens support nachgefragt und der meinte dies ist auch wenn ich nur ein bit aus einer struct oder udt übergebe? Jetzt kenn ich mich nicht mehr aus ;) lg

Gesendet von meinem LG-E975 mit Tapatalk
 
Wie macht ihr dann wenn ein sollwert in der sps verändert wird? Diesen muss ich ja dann auch wieder auf den hmi db rückschreiben!

Hier musst Du meines Erachtens zunächst mal überlegen, welches Verhalten Du haben willst, denn Du schreibst ja von zwei verschiedenen Quellen (HMI, Programm) auf eine Variable (Sollwert). Was soll passieren, wenn sowohl das HMI als auch das Programm den Sollwert ändert? Warum war das beim Schreiben vom HMI am Zykluskontrollpunkt kein Problem?
 
Ja das habe ich mir schon überlegt. Nur habe ich noch folgendes Problem. Ich habe einen Sollwert DB mit ca 2000 Variablen wo die ganzen Sollwert Variablen abgelegt sind.
Dort sind aber BOOL, REAL, INT,.. gemischt abgelegt. Jetzt weiß ich nur noch nicht wie ich die einzelnen Datentypen vergleichen kann. Hat hierzu jemand eine Antwort?
Ja bei der S7-300 hats funktioniert, da das HMI nicht während eines Bausteinaufrufes mir die Variable überschrieben hat sondern am Ende des OB1 beim Zykluskontrollpunkt.

lg
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Kannst du uns ein Beispiel geben, wo das ohne Zykluskontrollpunkt bei dir ein Problem darstellt. Bei Reinen Darstellungen. Macht es sinn die Variablen am Ende des Zyklus auf einen HMI DB zu übertragen, damit wäre Flackern und dergleichen Erledigt. Man könnte natürlich auch sauber Programmieren und nicht 20 Zuweisungen hintereinander machen die sich gegenseitig überschreiben (Letzter Gewinnt). Dann gibts das Problem auch nicht.

Zu den Sollwerten. Normalerweise werden Sollwerte ja nur von der HMI geschrieben oder durch einen Auslöser aus dem Programm. Wenn der Auslöser z.B. eine Obergrenze des Sollwerts ist und man diesen mit einer Abfrage dann mit dem obersten zulässigen Wert überschreiben will. Dann ist das üblicherweise kein Problem. Es seidenn natürlich die Anlage killt sich direkt wenn für einen Zyklus der zu hohe Sollwert ansteht, Da würde ich die Grenzen aber direkt in der HMI abfangen.

Oder man fängt die Grenze in einem Baustein per Limit ab und kopiert dann den Sollwert auf den zu verwendeten Korrigierten Sollwert, der dann im Programm verwendet wird. Da kann dann zwar die Software nicht mehr drauf schreiben, da muss sie dann auf den HMI wert verwiesen werden, etwas grösserer Programmieraufwand.

mfG René
 
Aso wird es nur als reference übergeben wenn ich ganze struct oder udt übergebe? Habe beim siemens support nachgefragt und der meinte dies ist auch wenn ich nur ein bit aus einer struct oder udt übergebe?

Da hat der Support was falsches erzählt. Wie Du im ersten Link von RONIN nachlesen kannst, werden elementare Datentypen (egal wo sie herkommen) generell als Kopie (by value) übergeben. Nur strukturierte Datentypen werden per Pointer (by reference) übergeben, es sei denn die kommen aus nicht-"optimierten" Speicherbereichen, dann werden die ebenfalls als Kopie übergeben.


Wie macht ihr dann wenn ein sollwert in der sps verändert wird? Diesen muss ich ja dann auch wieder auf den hmi db rückschreiben!
Soll ein Sollwert sowohl von der HMI als auch aus dem SPS-Programm geändert werden, dann mußt Du erstmal genauer überlegen was Du willst und wann Änderungen vom HMI überhaupt zugelassen werden sollen und was Vorrang hat, evt. abhängig von HAND/AUTO. Wie das HMI schreibt kannst Du nicht beeinflussen, das HMI ist unkooperativ. Wenn tatsächlich Änderungen vom HMI zulässig sein sollen und trotzdem auch das SPS-Programm den selben Sollwert ändern können soll, dann darf das SPS-Programm nur 1 mal schreiben (bei Bedarf, am besten nur bei Änderung).
Wichtig ist: der vom HMI beschreibbare Wert darf nur 1 mal im SPS-Programm gelesen werden und vom SPS-Programm beschreiben nur wenn nötig (z.B. zur Limitierung) und dann ebenfalls nur 1 mal.

Harald
 
Also mein Baustein funktioniert wie folgt. Man kann im HMI Soll KW eingeben. Und je nach Temperatur regelt mein Baustein die Soll KW. D.h. Wenn die Temperatur zu gering ist werden die Soll Kw langsam erhöht und wenn Temperatur zu hoch werden die Soll KW langsam verringert. Der Operator muss aber auch die Möglichkeit haben die Soll KW über die Visu zu ändern und der Baustein muss dann bei den neuen Soll KW wieder zu regeln anfangen.
Jetzt passiert es bei meine Tests immer wieder, dass der Sollwert welche der Operator eingibt nicht übernommen werden, da sie der Baustein wieder überschreibt.

Jetzt möchte ich den Sollwert DB in einen SPS DB kopieren und dann die einzelnen Variablen in meine Sollwert DB welche Real, INt, Bool sind vergleichen und je nach dem wer geändert hat diese dann auf meinen Sollwert DB kopieren oder nicht.
Jedoch weiß ich noch nicht wie ich es in SCL in einer For Schleife dynamisiseren kann, das er einmal ein INT und beim nächsten mal ein REAL vergleicht je nachdem welcher Datentyp es ist.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Jetzt passiert es bei meine Tests immer wieder, dass der Sollwert welche der Operator eingibt nicht übernommen werden, da sie der Baustein wieder überschreibt.
Das bedeutet doch, dass Du irgendwo im Programm den Sollwert liest und danach wieder überschreibst. Wenn das HMI dazwischen schreibt, bekommst Du das nicht mit und überschreibst den vom HMI geschriebenen Wert gleich wieder.
Lösung: Arbeite im Programm mit einer Kopie des vom HMI geschriebenen Sollwerts. Überprüfe getrennt davon den vom HMI geschriebenen Sollwert und ändere ggf. die Kopie.
Eine For - Schleife wirst Du nur verwenden können, wenn Du die Sollwerte in Arrays legst, natürlich getrennt nach Datentypen. Mit der derzeitigen Lösung wirst Du es linear runterprogrammieren müssen.
 
Ja genau richtig, dass ist mein Problem! Ja wird mir eh nichts anderes über bleiben als das so zu lösen, dass ich jede Variable vergleiche und dann entscheide welchen Wert ich verwende. Dies wird aber ein extremer Programmieraufwand.
Aber werde mir jetzt noch mal einen Experten von Big S einladen vielleicht haben die ja schon eine Lösung.
 
Da hat der Support was falsches erzählt. Wie Du im ersten Link von RONIN nachlesen kannst, werden elementare Datentypen (egal wo sie herkommen) generell als Kopie (by value) übergeben. Nur strukturierte Datentypen werden per Pointer (by reference) übergeben, es sei denn die kommen aus nicht-"optimierten" Speicherbereichen, dann werden die ebenfalls als Kopie übergeben.

Nachdem ich mich wiedermal mit dem Problem rumschlagen musste, packe ich diesen alten Thread wieder aus.
Wenn ich es richtig sehe, dann werden bei der S7-1500 zumindest nicht elementare Datentypen aus Standard-DBs (nicht optimiert) mit "call-by-reference" übergeben, wenn der Instanz-DB des FBs ebenfalls nicht optimiert ist.
Ist der Instanz-DB optimiert, dann wird mit "call-by-value" übergeben.
3 Tage Fehlersuche bei einer OPC-Kopplung nach dem Portieren von S7-400 -> S7-1500 wegen dieses kranken Systemverhaltens. :sb5:
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Nachdem ich mich wiedermal mit dem Problem rumschlagen musste, packe ich diesen alten Thread wieder aus.
Wenn ich es richtig sehe, dann werden bei der S7-1500 zumindest nicht elementare Datentypen aus Standard-DBs (nicht optimiert) mit "call-by-reference" übergeben, wenn der Instanz-DB des FBs ebenfalls nicht optimiert ist.
Ist der Instanz-DB optimiert, dann wird mit "call-by-value" übergeben.
3 Tage Fehlersuche bei einer OPC-Kopplung nach dem Portieren von S7-400 -> S7-1500 wegen dieses kranken Systemverhaltens. :sb5:

irgendwo in der TIA-Hilfe steht das anschaulich erklärt, an anderen Stellen der TIA Hilfe nicht bzw. sogar falsch.

Jedenfalls hängt's davon ab, ob 300/400/1200/1500, optimiert/nichtoptimiert, FC/FB, welcher Datentyp bzw. Struktur oder UDT oder ARRAY ...

Das ist echt verwirrend. Aber alles erstmal in der Software nochmal umzukopieren trägt ja auch nicht unbedingt zur Übersichtlichkeit bei...

Wenn ich das morgen noch finde, kopier ichs hier nochmal rein.

Gruß.
 
Den fehlenden Zykluskontrollpunkt kennt man ja von der 400er. Bei der 1500er darf man sich auch noch mit der unterschiedlichen Parameterübergabe rumschlagen.
Macht irgendwie keinen Spass mehr.
 
Wenn ich es richtig sehe, dann werden bei der S7-1500 zumindest nicht elementare Datentypen aus Standard-DBs (nicht optimiert) mit "call-by-reference" übergeben, wenn der Instanz-DB des FBs ebenfalls nicht optimiert ist. Ist der Instanz-DB optimiert, dann wird mit "call-by-value" übergeben.
Ja sehe ich auch so.

Grundsätzlich ist bei FB alles byValue, außer INOUT mit Struct/UDT.
Also eigentlich eh gleich wie 300/400.

Dafür jetzt noch die Sonderfälle...
opt. Struct -> opt. INOUT -> byRef
nicht opt. Struct -> nicht opt. INOUT -> byRef
opt. Struct -> nicht opt. INOUT -> byVal

Als Programmierer eines nicht opt. FB kannst du also gar nicht immer sagen ob der Datenzugriff perRef oder perVal passiert.
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
Im TIA v14 Handbuch steht unter 1.3.4.4 Grundlagen zur Programmierung - Bausteinaufrufe - Parameter als Kopie oder als Pointer übergeben folgendes


1.3.4.4 Parameter als Kopie oder als Pointer übergeben
Einführung
Beim Bausteinaufruf übergeben Sie den Parametern in der Schnittstelle des Bausteins Daten.
An den Eingangsparametern (Input) übergeben Sie die Daten, mit denen der Baustein arbeiten
soll. An den Ausgangsparametern (Output) legen Sie fest, wo die Bearbeitungsergebnisse
abgelegt werden. Durchgangsparameter (InOut) dienen sowohl der Übergabe von Daten an
den aufgerufenen Baustein als auch der Rückgabe von Ergebnissen.
Intern kennt STEP 7 zwei unterschiedliche Methoden der Parameterübergabe: Abhängig von
Übergabebereich und vom Datentyp des Parameters werden die Daten entweder als Pointer
oder als Kopie übergeben.
Übergabe als Kopie (Call by value)
Beim Bausteinaufruf wird der Wert des Operanden auf den Eingangsparameter des
aufgerufenen Bausteins kopiert. Bei Funktionsbausteinen wird die Kopie im Instanz-DB
abgelegt, bei Funktionen im Baustein-Stack. Für die Kopie wird zusätzlicher Speicherplatz
benötigt.
Das bedeutet, dass der aufgerufene Baustein immer mit dem Wert arbeitet, den der
angegebene Operand zum Zeitpunkt des Bausteinaufrufs hatte. Er kann nicht direkt auf den
Operanden zugreifen. Schreibende Zugriffe verändern nur die Kopie, nicht aber den
tatsächlichen Wert des angegebenen Operanden. Lesende Zugriffe lesen nur die Kopie, die
zum Zeitpunkt des Bausteinaufrufs angelegt wurde.




Übergabe als Pointer (Call by reference)
Die Parameter werden beim Bausteinaufruf über einen Pointer referenziert.
Das bedeutet, dass der aufgerufene Baustein unmittelbar auf die Speicheradresse des
Operanden zugreift, der als Parameter angegeben ist: Schreibende Zugriffe führen direkt zur
Veränderung des angegebenen Operanden. Lesende Zugriffe lesen den Wert des Operanden
unmittelbar zum Zeitpunkt des Zugriffs. Da keine Kopien angelegt werden, wird kein
zusätzlicher Speicher benötigt.


Hinweis
Deklarieren Sie strukturierte Datentypen im Bereich "InOut"
Nutzen Sie für strukturierte Variablen (z. B. vom Datentyp ARRAY, STRUCT, STRING, …)
wenn möglich den Bereich "InOut" in der Bausteinschnittstelle. Da strukturierte
Durchgangsparameter (InOut) standardmäßig als Pointer übergeben werden, wird der
benötigte Datenspeicher so nicht unnötig vergrößert.
Parameterübergabe bei S7-1200/1500
Die folgende Tabelle zeigt, wie in S7-1200/1500 Bausteinparameter mit elementarem bzw.
strukturiertem Datentyp übergeben werden. Elementare Datentypen sind z. B. BOOL, INT
oder BYTE. Strukturierte Datentypen sind z. B. ARRAY, STRUCT oder STRING.






Hinweis
Parameterübergabe zwischen Bausteinen mit optimiertem Zugriff und Bausteinen mit
Standardzugriff
Wenn bei einem Bausteinaufruf Strukturen als Durchgangsparameter (InOut) an den
aufgerufenen Baustein übergeben werden, werden diese standardmäßig als Pointer
übergeben (Call by reference).
Dies gilt jedoch nicht, wenn beide Bausteine unterschiedliche Optimierungseinstellungen
haben: Wenn einer der Bausteine die Eigenschaft "Optimierter Zugriff" und der andere
Baustein die Eigenschaft "Standardzugriff" hat, werden grundsätzlich alle Parameter als Kopie
übergeben (Call by value).
Wenn der Baustein viele strukturierte Parameter enthält, kann das schnell dazu führen, dass
der temporäre Speicherbereich (Lokaldaten-Stack) des Bausteins überläuft.
Außerdem können Probleme entstehen, 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 seit dem Anlegen der Kopie beim Bausteinaufruf
asynchron durchgeführten Änderungen an den ursprünglichen Operanden überschrieben.
Das können Sie vermeiden, indem Sie für beide Bausteine dieselbe Zugriffsart einstellen oder
die asynchronen Zugriffe zuerst in einen separaten Speicherbereich schreiben lassen und
diesen Bereich dann zu einem geeigneten Zeitpunkt synchron kopieren.
Siehe auch:
Bausteine mit optimiertem Zugriff (Seite 39)
FAQ 109478253: Warum kann es zum Überschreiben von Daten des HMI-Systems oder des
Webservers in der S7-1500 kommen? (https://support.industry.siemens.com/cs/de/de/view/
109478253)


Parameterübergabe bei S7-300/400
Die folgende Tabelle zeigt, wie in S7-300/400 Bausteinparameter mit elementarem bzw.
strukturiertem Datentyp übergeben werden.




* Ausnahme: Operanden aus den Speicherbereichen E, A, M, P, L und teilqualifizierte DBAdressen
(z. B. "DW 2") werden als Pointer übergeben.
Hinweis
Besonderheiten bei der Übergabe als Pointer in S7-300/400
In den Fällen, in denen die Parameter über einen Pointer übergeben werden, ist es nicht
möglich, Ausgangs- oder Durchgangsparameter vom aufrufenden Baustein an die
Eingangsparameter des aufgerufenen Bausteins weiterzureichen.

1500.jpg

300.jpg

Gruß.
 
Den fehlenden Zykluskontrollpunkt kennt man ja von der 400er. Bei der 1500er darf man sich auch noch mit der unterschiedlichen Parameterübergabe rumschlagen.
Macht irgendwie keinen Spass mehr.
Bei uns hat das 2 recht strikte, aber klare Regeln zur Folge:
1. es gibt nur optimierte Bausteine (mir ist bisher keine Ausnahme bekannt)
2. Variablen mit HMI-Zugriff sind entweder HMI rw + PLC ro oder HMI ro + PLC rw. Zulässige Ausnahme sind nur das Ablöschen von HMI-Kommandos bei Kommunikationsausfall und das Überschreiben von HMI rw-Feldern mit sicheren Werten. Gleiches gilt für OPC.
 
Bei uns hat das 2 recht strikte, aber klare Regeln zur Folge:
1. es gibt nur optimierte Bausteine (mir ist bisher keine Ausnahme bekannt)
2. Variablen mit HMI-Zugriff sind entweder HMI rw + PLC ro oder HMI ro + PLC rw. Zulässige Ausnahme sind nur das Ablöschen von HMI-Kommandos bei Kommunikationsausfall und das Überschreiben von HMI rw-Feldern mit sicheren Werten. Gleiches gilt für OPC.

Wenn man es sich selber raussuchen kann ...
Wir bekommen die Datenstrukturen vorgegeben und diese sind auf allen S7-Baureihen fix.
Somit scheiden optimierte Schnittstellen-DBs aus.
Ich kann ohne Zykluskontrollpunkt oder mit Call-by-Value-Parameterübergabe leben.
Nur beides zusammen ist einfach Mist.
 
Zurück
Oben