TIA Frage zu OPC-UA Verhalten

Münchnerjunge

Level-1
Beiträge
314
Reaktionspunkte
38
Zuviel Werbung?
-> Hier kostenlos registrieren
Liebe Community,

gegenwärtig stelle ich bei einem Projekt mit unter anderem einer 1512SP mit FW2.1.0 und einem OPC Server in einer PC-Station, welche mittels einer S7 -Verbindung konfiguriert in TIA V14.1, Daten austauschen folgendes (Fehl)-Verhalten fest, dessen Ursprung ich noch nicht aufdecken konnte:

Leider kommt es sporadisch und undefinierbar vor, dass Daten, welche ich in der CPU schreibe, quasi "nicht übernommen" werden. Dies ist mir bereits aufgefallen, als ich Werte eines DBs auf welchen die CPU bis dato noch nicht geschrieben hatte und auf welchen der OPC zugreift, im Beobachtungsmodus händisch gesteuert habe. Hier wurden Werte teilweise erst beim dritten oder vierten mal Schreiben angenommen. Trotz Verwunderung bin ich der Ursache nicht nachgegangen.


Nun habe ich jetzt ein vergleichbares Problem. Werte, die mir der OPC schreibt, aber auch die Steuerung (im gleichen Zyklus) ändert, werden teilweise nicht angenommen.

Beispielsweise setzt mir der OPC ein Bit welches eine IF-Bedinung aktiviert:

Code:
IF 'Bit_von_OPC' THEN
...
...
...
...
'Bit_von_OPC' := FALSE;
END_IF;

Leider aber wird das 'Bit_von_OPC' nicht mehr auf FALSE gesetzt. Dies passiert gefühlt allerdings nur alle 10-15x.

Da ich bis dato noch nicht allzu viele Projekte mit OPC gemacht habe, würde ich gerne von erfahreneren Nutzern wissen, ob meine Programmstruktur diesen Fehler verursacht? Eigentlich bin ich davon ausgegangen, dass mir der OPC das Bit nur einmal schreibt, und dann aus der CPU rückliest.

Eingestellt habe ich für die Kommunikation eine Zykluszeit von 100ms.

Danke im Voraus für hilfreiche Antworten!
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Beispielsweise setzt mir der OPC ein Bit welches eine IF-Bedinung aktiviert:

Code:
IF 'Bit_von_OPC' THEN
...
...
...
...
'Bit_von_OPC' := FALSE;
END_IF;

Leider aber wird das 'Bit_von_OPC' nicht mehr auf FALSE gesetzt. Dies passiert gefühlt allerdings nur alle 10-15x.

Wobei wenn dort "Bit_von_OPC" wirklich obwohl true nicht mehr auf false gesetzt werden sollte, dann macht die SPS einen Fehler. Hast du dir den Online-Status dann schon einmal angesehen ob das wirklich so ist?

Ist "Bit_von_OPC" in dem Fall evtl. ein Parameter einer Funktion oder eines FCs? Falls "Bit_von_OPC" ein Merkerbit oder ein Global-DB Bit auf das direkt zugegriffen wird ist, sollte das auch mit der 1500 funktionieren.
 
Hmm, habe die Themen grade mal überflogen, bin leider auch unterwegs.

Vermutlich sind bei mir aufgrund der Unwissenheit einige Umstände zusammengekommen, die diese Probleme verursachen könnten, welche vermutlich meiner Programmstruktur geschuldet sind:

-Global-DB für Daten von/an OPC
-Globald-DB ist opimiert
-Verwendung von UDT's in dem DB
-UDT's an FB's als InOut gelegt

Habe das Online beobachtet, und ja - ist leider wirklich so.
 
Sofern es keine einfachere Lösung gibt würde ich nun wie folgt vorgehen:

Daten in Global-DB von/für OPC am Anfang des Zyklus auf Ungleichheit vergleichen. Wenn ungleich, dann überschreibe ich meinen (neuen) Temp-Global-DB gleicher Struktur.

Temp-Global-DB in Programm verwenden(lesen und schreiben).

Am Ende des Zyklus Temp-Global-DB vergleichen ob er sich im Zyklus geändert hat. Wenn ungleich dann Global-DB von/für OPC überschreiben.


Meine Performance wird dabei hoffentlich nicht in die Knie gehen.. :???:
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hmm, habe die Themen grade mal überflogen, bin leider auch unterwegs.

Vermutlich sind bei mir aufgrund der Unwissenheit einige Umstände zusammengekommen, die diese Probleme verursachen könnten, welche vermutlich meiner Programmstruktur geschuldet sind:

-Global-DB für Daten von/an OPC
-Globald-DB ist opimiert
-Verwendung von UDT's in dem DB
-UDT's an FB's als InOut gelegt

Habe das Online beobachtet, und ja - ist leider wirklich so.

Bei mir funktioniert folgendes bei OPC:
OPC-Daten in nicht optimierten DB
Bearbeitung in NICHT optimierten FBs
Übergabe von Strukturen via InOut-Parameter
(Elementare Typen werden mit Call-By-Value bei S7-1500 übergeben.
Damit hat man das Problem mit dem Überschreiben.)
Das Problem mit dem fehlenden Zykluskontrollpunkt löse ich wie bei der 400er durch lokale Kopien im Baustein

Gruß
Blockmove
 
Sofern es keine einfachere Lösung gibt würde ich nun wie folgt vorgehen:
[...]
Am Ende des Zyklus Temp-Global-DB vergleichen ob er sich im Zyklus geändert hat. Wenn ungleich dann Global-DB von/für OPC überschreiben.
Ein wie auch immer umständliches Vergleichen und Kopieren von Speicherbereichen wird Dir nicht wirklich helfen, weil auch während dem Vergleichen und Kopieren OPC-Schreibzugriffe auftreten können, welche dann nicht erkannt werden. Siemens hat es versäumt in die S7-Programmiersprachen elementare Funktionen zur Interprozesskommunikation einzubauen, wie z.B. eine atomare Exchange-Funktion oder Sperren von Interrupts durch Kommunikation. Weil es solche Mechanismen nicht gibt darf auf Kommunikationsvariablen nur ein einziges mal im Zyklus zugegriffen werden.

Allerdings ist Dein Problem vermutlich nicht (bzw. nicht nur) eine Folge der unkooperativen Kommunikation, da muß noch ein anderer Fehler mit rein spielen. (wie Thomas_v2.1 bereits in #3 anmerkte)
Beispielsweise setzt mir der OPC ein Bit welches eine IF-Bedinung aktiviert:

Code:
IF 'Bit_von_OPC' THEN
...
...
...
...
'Bit_von_OPC' := FALSE;
END_IF;

Leider aber wird das 'Bit_von_OPC' nicht mehr auf FALSE gesetzt. Dies passiert gefühlt allerdings nur alle 10-15x.
Ist 'Bit_von_OPC' die Variable, die vom OPC-Server beschrieben wird, oder ist es eine Kopie der Variable? Überlappt 'Bit_von_OPC' mit anderen Variablen? Oder ist da ein Fehler in dem nicht gezeigten Code? Wird der Code immer ausgeführt wenn 'Bit_von_OPC' TRUE ist? Woran merkst Du, daß 'Bit_von_OPC' am Ende nicht auf FALSE geht?

Harald
 
Allerdings ist Dein Problem vermutlich nicht (bzw. nicht nur) eine Folge der unkooperativen Kommunikation, da muß noch ein anderer Fehler mit rein spielen. (wie Thomas_v2.1 bereits in #3 anmerkte)

Ist 'Bit_von_OPC' die Variable, die vom OPC-Server beschrieben wird, oder ist es eine Kopie der Variable? Überlappt 'Bit_von_OPC' mit anderen Variablen? Oder ist da ein Fehler in dem nicht gezeigten Code? Wird der Code immer ausgeführt wenn 'Bit_von_OPC' TRUE ist? Woran merkst Du, daß 'Bit_von_OPC' am Ende nicht auf FALSE geht?

Harald


Mein Code ist noch etwas länger, aber vom Grundsatz her gleich. Ich schreibe gleich noch mehr Daten auf 0, merkwürdigerweise funktioniert das aber auch nicht immer zuverlässig. Die Daten werden nirgendwo anders überschrieben. Auch wird mein dargestellltes Bit nur alle paar Minuten mal gesetzt um Daten abzuholen.

Code:
IF 'Bit_von_OPC' THEN
...
Value1_von_OPC := 0;
Value2_von_OPC := '';
Value3_von_OPC := '';
...
'Bit_von_OPC' := FALSE;
END_IF;

Ich schreibe bspw. Value 1, dann 2, dann 3 und dann setzte ich das Bit.

Meist funktioniert das eben auch, manchmal kommt es aber auch vor, dass eben das Bit und der letzte geänderte Value nicht rückgeschrieben werden, allerdings die anderen Values. Daher sehe ich auch, dass mein Bit einmal kam, und ich sehe, dass es noch ansteht, und ich sehe eben, dass bspw. Value3 noch 'abcdefghi' ist.

Bit und die anderen Daten überlappen nicht. Auch handelt es sich bei allen um die direkt vom OPC geschriebenen Daten.
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
manchmal kommt es aber auch vor, dass eben das Bit und der letzte geänderte Value nicht rückgeschrieben werden, allerdings die anderen Values. Daher sehe ich auch, dass mein Bit einmal kam, und ich sehe, dass es noch ansteht, und ich sehe eben, dass bspw. Value3 noch 'abcdefghi' ist.
Mit "sehen" meinst Du, daß Du die Variable 'Bit_von_OPC' in der SPS beobachtest? Oder beobachtest Du den OPC-Server oder eine Visu, welche über den OPC-Server mit der SPS kommuniziert? Vielleicht funktioniert der OPC-Server nicht korrekt.

Falls Du die Variable 'Bit_von_OPC' in der SPS beobachtest: wieso wird die dann nicht im nächsten Zyklus auf FALSE geschrieben - da müsste Dein Code doch noch mal ausgeführt werden wenn 'Bit_von_OPC' nicht FALSE ist???

Harald
 
Seltsames Systemverhalten kann zum einen von der SPS oder auch vom OPC-Server kommen.
OPC-Server pollen erstmal in einem bestimmten Zeitraster die Steuerung.
Das heißt aber nicht, dass alle Variablen gleichzeitig abgefragt werden, sondern es können auch Trigger definiert werden.
Nach dem Setzen des Triggers, werden dann weitere Variablen abgefragt.
Bei einer großen Datenmenge kann dies mehre Kommunikationszyklen dauern.

Anstelle des OPC-Servers kannstdu mal versuchen mit der Visu / WinCC den Datenaustauch zu simulieren.
Zuerst ganz simpel über Buttons und wenn hier alles passt, dann kannst du den Handshake versuchen über Scripte zu automatisieren.

Gruß
Blockmove
 
Mit "sehen" meinst Du, daß Du die Variable 'Bit_von_OPC' in der SPS beobachtest? Oder beobachtest Du den OPC-Server oder eine Visu, welche über den OPC-Server mit der SPS kommuniziert? Vielleicht funktioniert der OPC-Server nicht korrekt.

Falls Du die Variable 'Bit_von_OPC' in der SPS beobachtest: wieso wird die dann nicht im nächsten Zyklus auf FALSE geschrieben - da müsste Dein Code doch noch mal ausgeführt werden wenn 'Bit_von_OPC' nicht FALSE ist???

Harald

Ich beobachte die Variablen sowohl in der CPU, als auch im OPC, als auch in der Visu. Sorry, war etwas ungenau ausgedrückt. Aber das hatte ich bereits überprüft.

Warum? Weil mein Code nicht vollständig niedergeschrieben ist. In der IF Bedingung sind eben noch ein paar "AND" drinnen, die ich der Einfachheit halber nicht aufgerufen habe. Eine davon kommt auch aus dem OPC, die anderen alle intern in der CPU, diese werden dann aber auch wieder in der IF-Schleife auf FALSE gesetzt. Ich darf nach derzeitigem Programmaufbau die IF-Schleife nur einmal aufrufen. Entweder ich finde die Ursache oder muss das eben anders aufbauen. Aber programmtechnisch ist das, bis eben auf eventuelle Besonderheiten aufgrund von OPC, die mir nicht bekannt sind und ich erfragen wollte, korrekt aufgebaut.

Jetzt muss ich aber mal ganz dumm fragen: Wenn mir der OPC zwei Variablen einer IF-Bedingung auf TRUE schreibt, und ich grade in der IF-Schleife bin, er mir dann aber eine der beiden Bedingungen weg nimmt, wird doch die IF-Schhleife dennoch fertig bearbeitet, oder täusche ich mich da?


Anstelle des OPC-Servers kannstdu mal versuchen mit der Visu / WinCC den Datenaustauch zu simulieren.
Zuerst ganz simpel über Buttons und wenn hier alles passt, dann kannst du den Handshake versuchen über Scripte zu automatisieren.

Entweder stehe ich grade auf dem Schlauch oder ich sollte einfach Schluss machen. Was meinst du damit? Soll ich einfach mal nen WINCC auf den Server hauen und das testen, oder wie soll ich deine Nachricht verstehen?


Jedenfalls schon mal vielen Dank für alle Antworten. Vielleicht findet sich ja noch eine Lösung.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Code:
IF 'Bit_von_OPC' THEN
...
Value1_von_OPC := 0;
Value2_von_OPC := '';
Value3_von_OPC := '';
...
'Bit_von_OPC' := FALSE;
END_IF;

Falls du wie in deinem Beispiel wirklich Strings vom OPC-Server übermittelt bekommst, wird es nochmal schwieriger. Denn um Strings konsistent und sicher über die Standard-HMI-Kommunikation der 1500/1200 zu verarbeiten, musst du einige Klimmzüge machen. Eigentlich kann man sich das nur irgendwie hinbiegen damit das zuverlässig immer funktioniert (mit Timern, Rücklesen, Prüfsummen), weil Siemens dem Programmierer keine Werkzeuge dazu zur Verfügung stellt.

Vielleicht sollte dazu mal jemand bei Siemens einen Support-Fall eröffnen. Die Wahrscheinlichkeit ist aber äußerst gering einen Bearbeiter zu bekommen, der überhaupt ahnt um was es da geht.
 
Entweder stehe ich grade auf dem Schlauch oder ich sollte einfach Schluss machen. Was meinst du damit? Soll ich einfach mal nen WINCC auf den Server hauen und das testen, oder wie soll ich deine Nachricht verstehen?

OPC-Server und Visu sind in ihrem Kommunikationsverhalten ähnlich. Viele Probleme, die du bei der OPC-Kommunikation hast, hast du auch mit der Visu.
Also wenn du eine Visu hast (egal ob WinCC, WinCC flex oder TIA), dann simuliere doch da einfach mal den Datenaustausch mit dem OPC.
Dann kannst du wenigstens mal herausfinden ob esein OPC- oder ein Steuerungsproblem ist.

Das hier beschriebende S7-1500 Problem

https://support.industry.siemens.com/cs/document/109478253/warum-kann-es-zum-%C3%BCberschreiben-von-daten-des-hmi-systems-oder-des-webservers-in-der-s7-1500-kommen-?dti=0&pnid=13614&lc=de-WW

hast du z.B. genauso bei OPC wie bei HMI.
Falls du irgendwo eine S7-1200 hast, kannst du auch mal mit der Testen.
Ich hatte aktuell den Fall, dass der selbe SCL-Code auf S7-300, S7-400 und S7-1200 funktionierte aber nicht bei einer S7-1500.
Die 1500er ist sehr "speziell" im Umgang mit ihren Speicherzugriffen.
Was bei mir jetzt problemlos läuft, sind nicht optimierte OPC-Global-DBs und Zugriff darauf mit nicht optimierten FBs (siehe auch der Link).

Gruß
Blockmove
 
Wenn mir der OPC zwei Variablen einer IF-Bedingung auf TRUE schreibt, und ich grade in der IF-Schleife bin, er mir dann aber eine der beiden Bedingungen weg nimmt, wird doch die IF-Schhleife dennoch fertig bearbeitet, oder täusche ich mich da?
Ja, der Code in der IF-Anweisung (im THEN-Zweig oder ELSE-Zweig) wird selbstverständlich zu Ende ausgeführt, auch wenn nach der Prüfung noch während der Programmausführung eine Bedingung wieder weg geht. Solange die verknüpfte Variable nicht erneut abgefragt wird ist dem Code der Zustand der Variablen egal. Wird die Variable aber in dem Programmteil noch einmal abgefragt dann kann sich deren Zustand gegenüber der ersten Abfrage geändert haben! Deshalb dürfen Variablen aus anderen Task nur ein einziges mal abgefragt werden.

Zurück zu Deinem problematischen Code:
Code:
[COLOR="#0000FF"]"testvar" := FALSE;[/COLOR]

IF 'Bit_von_OPC' THEN
[COLOR="#0000FF"]  "testvar" := TRUE;[/COLOR]
  ...
  Value1_von_OPC := 0;
  Value2_von_OPC := '';
  Value3_von_OPC := '';
  ...
  'Bit_von_OPC' := FALSE;
END_IF;

[COLOR="#0000FF"]...    //schreibt hier irgendwas auf 'Bit_von_OPC' ?

IF "testvar"       //THEN-Zweig wurde ausgeführt ('Bit_von_OPC' war TRUE)
AND 'Bit_von_OPC'  //und OPC-Variable ist (wieder) TRUE!
THEN
  "Bit_von_OPC_wurde_unerwartet_gesetzt" := TRUE;
END_IF;[/COLOR]
Wenn nach Ausführung des Codes die PLC-Variable 'Bit_von_OPC' nicht FALSE ist, dann wird sie entweder kurz nach der Zuweisung durch irgendwas überschrieben (Kommunikation, OPC-Server schreibt mehrmals, Überlappung mit anderer Variable, fehlerhafte indirekte Adressierung?) oder der Programmcode hat die Zuweisung nicht ausgeführt - ist da vielleicht vorher ein EXIT oder GOTO?
Du könntest mal meinen blauen Testcode zufügen.

Welche Adresse hat die Variable 'Bit_von_OPC' eigentlich?
Du könntest der Variable 'Bit_von_OPC' mal eine ganz andere bisher unbenutzte Adresse geben (z.B. DB1013.DBX12.5) um Überlappungen und Fehladressierungen auszuschließen.
Wie ist die Variable 'Bit_von_OPC' im OPC-Server konfiguriert? Durch welche (mehrere?) Trigger wird ein Schreiben der Variable ausgelöst?

Bei Deinen allgemeinen Angaben kann man leider nur allgemeine Antworten geben. Genauer hinschauen könnte man, wenn man den wirklichen Code sähe.


PS: IF-Schleifen gibt es nicht :cool:

Harald
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Um der Sache gründlich auf die Spur zu kommen, empfehle ich dir die Trace-Funktion von TIA. Da kannst du zumindest mal über mehrere Zyklen hinweg schauen, was dein OPC und deine Variablen wirklich machen. Und wenn das Verhältnis zwischen OPC-Zugriff und Zykluszeit passt, dann sollte der OPC ja zumindest nicht mehrfach in einem Zyklus schreiben (das würde der Trace nämlich auch nicht sehen).
Tracen kannst du alle DB und IDB-Einträge, man muss also vielleicht manchmal testhalber eine temp zur static machen.
 
Falls du wie in deinem Beispiel wirklich Strings vom OPC-Server übermittelt bekommst, wird es nochmal schwieriger. Denn um Strings konsistent und sicher über die Standard-HMI-Kommunikation der 1500/1200 zu verarbeiten, musst du einige Klimmzüge machen. Eigentlich kann man sich das nur irgendwie hinbiegen damit das zuverlässig immer funktioniert (mit Timern, Rücklesen, Prüfsummen), weil Siemens dem Programmierer keine Werkzeuge dazu zur Verfügung stellt.

Vielleicht sollte dazu mal jemand bei Siemens einen Support-Fall eröffnen. Die Wahrscheinlichkeit ist aber äußerst gering einen Bearbeiter zu bekommen, der überhaupt ahnt um was es da geht.

Das ist interessant. Bisher hatte ich noch keine Fehler bei der Eingabe von Strings, daher erzeuge ich auch keine Prüfsummen etc. Ohnehin werden die vom Anlagenbediener eingegebenen Werte rückgeschrieben und von dem Anlagenbediener dann erst bestätigt.

Aber das war mir bisher noch nicht bewusst, dass es wohl allgemein bekannt Probleme bei der Übertragung von Strings gibt. Darf ich Fragen was der Grund dafür ist, dass man zwar floats etc fehlerlos übertragen kann, aber bei Strings dann Fehler macht?

OPC-Server und Visu sind in ihrem Kommunikationsverhalten ähnlich. Viele Probleme, die du bei der OPC-Kommunikation hast, hast du auch mit der Visu.
Also wenn du eine Visu hast (egal ob WinCC, WinCC flex oder TIA), dann simuliere doch da einfach mal den Datenaustausch mit dem OPC.
Dann kannst du wenigstens mal herausfinden ob esein OPC- oder ein Steuerungsproblem ist.

Das hier beschriebende S7-1500 Problem

https://support.industry.siemens.co...der-s7-1500-kommen-?dti=0&pnid=13614&lc=de-WW

hast du z.B. genauso bei OPC wie bei HMI.
Falls du irgendwo eine S7-1200 hast, kannst du auch mal mit der Testen.
Ich hatte aktuell den Fall, dass der selbe SCL-Code auf S7-300, S7-400 und S7-1200 funktionierte aber nicht bei einer S7-1500.
Die 1500er ist sehr "speziell" im Umgang mit ihren Speicherzugriffen.
Was bei mir jetzt problemlos läuft, sind nicht optimierte OPC-Global-DBs und Zugriff darauf mit nicht optimierten FBs (siehe auch der Link).

Gruß
Blockmove

Danke für Hinweise und Links. Ich könnte das diese Woche höchstens mit PLCSIM testen, bin erst wieder in einigen Tagen vor Ort.

Ja, der Code in der IF-Anweisung (im THEN-Zweig oder ELSE-Zweig) wird selbstverständlich zu Ende ausgeführt, auch wenn nach der Prüfung noch während der Programmausführung eine Bedingung wieder weg geht. Solange die verknüpfte Variable nicht erneut abgefragt wird ist dem Code der Zustand der Variablen egal. Wird die Variable aber in dem Programmteil noch einmal abgefragt dann kann sich deren Zustand gegenüber der ersten Abfrage geändert haben! Deshalb dürfen Variablen aus anderen Task nur ein einziges mal abgefragt werden.

Zurück zu Deinem problematischen Code:
Code:
[COLOR=#0000FF]"testvar" := FALSE;[/COLOR]

IF 'Bit_von_OPC' THEN
[COLOR=#0000FF]  "testvar" := TRUE;[/COLOR]
  ...
  Value1_von_OPC := 0;
  Value2_von_OPC := '';
  Value3_von_OPC := '';
  ...
  'Bit_von_OPC' := FALSE;
END_IF;

[COLOR=#0000FF]...    //schreibt hier irgendwas auf 'Bit_von_OPC' ?

IF "testvar"       //THEN-Zweig wurde ausgeführt ('Bit_von_OPC' war TRUE)
AND 'Bit_von_OPC'  //und OPC-Variable ist (wieder) TRUE!
THEN
  "Bit_von_OPC_wurde_unerwartet_gesetzt" := TRUE;
END_IF;[/COLOR]
Wenn nach Ausführung des Codes die PLC-Variable 'Bit_von_OPC' nicht FALSE ist, dann wird sie entweder kurz nach der Zuweisung durch irgendwas überschrieben (Kommunikation, OPC-Server schreibt mehrmals, Überlappung mit anderer Variable, fehlerhafte indirekte Adressierung?) oder der Programmcode hat die Zuweisung nicht ausgeführt - ist da vielleicht vorher ein EXIT oder GOTO?
Du könntest mal meinen blauen Testcode zufügen.

Welche Adresse hat die Variable 'Bit_von_OPC' eigentlich?
Du könntest der Variable 'Bit_von_OPC' mal eine ganz andere bisher unbenutzte Adresse geben (z.B. DB1013.DBX12.5) um Überlappungen und Fehladressierungen auszuschließen.
Wie ist die Variable 'Bit_von_OPC' im OPC-Server konfiguriert? Durch welche (mehrere?) Trigger wird ein Schreiben der Variable ausgelöst?

Bei Deinen allgemeinen Angaben kann man leider nur allgemeine Antworten geben. Genauer hinschauen könnte man, wenn man den wirklichen Code sähe.


PS: IF-Schleifen gibt es nicht :cool:

Harald

Danke für Erklärung und Hinweise. Ich werden den Code mal eintragen bzw. ergänzen, wobei ich diesen in vergleichbarer Form ohnehin schon ergänzt habe um mir die Daten auf 0 zu schreiben, wenn der beschriebene Fehler passiert.

Es gibt keine Überlappungen, keine GOTO und keine EXIT Anweisungen in dem relevanten Abschnitt. Auf die relevanten Adressen wird per INOUT zugegriffen, da der FB mehrfach verwendet wird und es sich jeweils um andere Daten handelt. Daher auch die allgemeinen Angaben. Aber vielleicht kann ich die Tage mal ein Screen des Codes machen, wobei er vom Grundsatz her nicht von dem allgemein gehaltenen und dargestellten Code abweicht.

Ich vermute mittlerweile wirklich, dass es der OPC ist. Evtl. könnte ich an der eingestellten Zykluszeit noch was ändern, um das Problem zu minimieren? Habe dort 100ms eingetragen, wobei meine CPU ne Zykluszeit von ca 8ms hat, max 30ms.
 
Zurück
Oben