1500er TCP/IP ACCON AGLink in DB schreiben (AGL_WriteDataBytes) scheitert vereinzelt

[GuWa]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo

ich mache gerade aktuell Kommunikationsversuche mit einem PC via TCP/IP zu einer SPS 1515TF-2 PN mittels der Bibliothek ACCON AGLink (zunächst mal Demoversion, zum Glück gibt es sowas ja).
Derzeit brauche ich nicht mehr als aus DBs zu lesen oder in DBs zu schreiben.
Die entsprechenden DBs sind nicht optimiert.
PUT/GET ist auf SPS-Seite freigegeben.

Mein Versuch sieht wie folgt aus:

1. Ich schreibe einen Wert in einen DB im Sync-Mode (Timeout: 1)
2. Der Wert wird (als Kontrollmechanismus) bei jedem Durchlauf inkrementiert
3. Zur Kontrolle lese ich den Wert aus dem DB zurück und vergleiche diesen mit dem gesendeten
4. Bei 1000 Durchläufen (in Schleife) lese ich in ca. 5 .. 15 Fällen, das ist total sporadisch, einen falschen Wert zurück, interessanterweise ist das immer ein Wert vom vorherigen Durchlauf (also um 1 kleiner als aktuell gesendet)
5. Im Moment wiederhole ich in diesen Fällen die Kommunikation (also erneut senden und nochmal neu lesen), dann scheint es zu klappen (das würde ich aber natürlich gerne vermeiden)
6. Rückgabecodes vom Schreiben und Lesen sind selbstverständlich ausgewertet und sind immer ok (AGL40_SUCCESS), egal ob der Problemfall eintritt oder nicht

Auf Grund des Wertes den ich im Problemfall zurück lese (siehe Punkt 4.) sieht es für mich so aus, dass das Schreiben in den DB, im Problemfall, irgendwie ins Nirwana zu laufen scheint.
Ich habe auch schon ein Delay von 200 ms und 500 ms zwischen Schreiben und Lesen eingebaut, aber das ändert nichts an der Problematik.
Ich programmiere in C++ (Borland) unter Windows (aktuell getestet auf meinem Notebook mit Windows 7 Ultimate).
Zwischen dem PC und der SPS hängt ein Switch Scalance XB008 (falls das eine Rolle spielt).

Hat jemand schon mal sowas gehabt, probiert oder eine Idee an was das liegen kann?

Vielen Dank für evtl. Ideen und Hilfe

 

[Rainer Hönle]

Probleme gibt es, wenn der Wert auch als INOUT- oder OUT-Parameter in einem FB verwendet wird, da dann die SPS den Wert am FB-Ende wieder überschreibt und die Kommunikation asynchron zum SPS-Zyklus stattfindet. Ist dies bei dem geschriebenen Wert definitiv nicht der Fall?

 

[PN/DP]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich würde sagen, das ist normal, weil die Kommunikation nicht im Zykluskontrollpunkt stattfindet, sondern irgendwann Dein SPS-Programm unterbricht. Und weil Dein SPS-Programm auf die selbe Variable zurückschreibt, auf die auch die Kommunikation von außen schreibt (keine gute Idee!). Wenn nun Dein Programm den Wert inkrementieren will und liest den vorhandenen Wert (z.B. 100) --!!!-- jetzt unterbricht die Kommunikation Dein SPS-Programm und schreibt 200 in die Variable --!!!-- jetzt arbeitet Dein SPS-Programm weiter, addiert 1 zu den gelesenen 100 und schreibt 101 zurück in die Variable. Der zwischenzeitliche Wert 200 in der Variable wird überschrieben, so als hätte es ihn nie gegeben.

Merke bei Multitasking: Werte die in einer anderen Task geschrieben werden dürfen immer nur ein einziges mal im Zyklus gelesen werden, und nur bei Änderung einmal geschrieben werden.

Wie sieht Dein SPS-Programm zum inkrementieren des Wertes aus?

Das Problem ist nicht spezifisch bei AGLink, sondern besteht ganz allgemein auch bei der HMI-Kommunikation der S7-400/1200/1500, und bei S7-300 wenn priorisierte BuB freigegeben ist.

Harald

 

[GuWa]

@Rainer Hönle
Danke für das erste und schnelle Feedback.
Zu Ihrer Frage:
Nein, das ist in diesem Fall definitiv nicht der Fall.

 

[GuWa]

@Harald (PN/DP)
Nein so ist das nicht. Nur ich schreibe in den DB, die SPS soll später mal lesend darauf zugreifen.
Der Wert wird von mir inkrementiert, das ist mein PC interner Zähler. Das Lesen findet nur zur Kontrolle statt, es wird nicht der zurück gelesene Wert inkrementiert.
Trotzdem auch Danke für das Feedback.

 

[PN/DP]

Zuviel Werbung?
-> Hier kostenlos registrieren

Genau auf welche Adresse schreibt Dein AGLink-Zugriff?
Gibt es in der SPS Schreibzugriffe auf diese Adresse, evtl. indirekt adressiert?

Harald

 

[PN/DP]

Das Rücklesen im PC Programm wird erst angestossen, wenn das Schreiben beendet ist?
Wenn Du im PC Programm im Fehlerfall ohne erneut schreiben mehrmals rückliest - kommt dann irgendwann der erwartete/zuletzt geschriebene Wert?

Harald

 

[GuWa]

Genau auf welche Adresse schreibt Dein AGLink-Zugriff?

DB 99 ein Int auf Adresse 22

Gibt es in der SPS Schreibzugriffe auf diese Adresse, evtl. indirekt adressiert?

Ziemlich sicher nicht, ich kann das morgen nochmal von meinem Kollegen von der SPS-Seite bestätigen lassen.

Ich hole mal noch etwas weiter aus, das oben ist vereinfacht geschrieben, und ich dachte das genügt so zunächst mal für das Verständnis etc.
Im Prinzip liegt im DB99 eine "Drucktabelle", also Druckpositionen an denen bei einem Vorschub der zu steuernden Maschine die SPS Drucksignale für einen Industrie-Tintenstrahldrucker ausgeben soll. Diese ist auf 96 Positionen (96 DInt ab Adresse 24) ausgelegt, dazu gibt es noch einen Eintrag wie viel Einträge in der Tabelle abzuarbeiten sind (das ist der Int auf Adresse 22).
Ich habe auch entsprechend inkrementierte Einträge für die Druckpositionen rein geschrieben, mit dem gleichen Effekt, dass im Problemfall alle Druckpositionen die ich zur Kontrolle zurück lese denen des vorherigen Durchlaufs entsprechen.

 

[GuWa]

Zuviel Werbung?
-> Hier kostenlos registrieren

Das Rücklesen im PC Programm wird erst angestossen, wenn das Schreiben beendet ist?

Da ich ja sync schreibe kommt die Funktion ja wohl erst zurück wenn das Schreiben durchgeführt wurde, somit denke/meine/hoffe Ich ja.

Wenn Du im PC Programm im Fehlerfall ohne erneut schreiben mehrmals rückliest - kommt dann irgendwann der erwartete/zuletzt geschriebene Wert?

Das könnte ich noch prüfen aber ich vermute mal eher nicht, das Delay das ich mal zum Testen dazwischen gesetzt habe, hat zumindest nichts in der Richtung bewirkt (und 500 ms sind dabei ja einiges denk ich)

 

[PN/DP]

Wie Rainer schon andeutete: es reicht wenn im SPS-Programm die DB99-Variablen als STRUCT an einem FB/FC-OUT oder jeder INT einzeln als FB/FC-INOUT angeschaltet sind, oder als STRUCT an INOUT eines "optimierten" FB/FC, dann werden die Variablen am Ende des FB/FC-Aufrufs mit den Werten vom FB/FC-Durchlauf beschrieben. Ein Kommunikations-Schreibzugriff während der FB/FC-Ausführung wird dadurch überschrieben. Laß mal prüfen, ob die Kollegen sowas im SPS-Programm haben.

Um sicherzugehen, daß die Variablen nicht irgendwie im SPS-Programm geschrieben werden: einen neuen DB mit neuer/bisher unbenutzter DB-Nummer nur für Deine Kommunikations-Versuche anlegen und in die SPS laden.

Harald

 

[GuWa]

Wenn Du im PC Programm im Fehlerfall ohne erneut schreiben mehrmals rückliest - kommt dann irgendwann der erwartete/zuletzt geschriebene Wert?

Ich hab jetzt mal die Programmierung noch entsprechend erweitert und kann sagen, dass wenn ich im Problemfall für weitere 4 Sekunden immer neu einlese, trotzdem nicht der erwartete/zuletzt geschriebene Wert kommt.

 

[GuWa]

Zuviel Werbung?
-> Hier kostenlos registrieren

Wie Rainer schon andeutete: es reicht wenn im SPS-Programm die DB99-Variablen als STRUCT an einem FB/FC-OUT oder jeder INT einzeln als FB/FC-INOUT angeschaltet sind, oder als STRUCT an INOUT eines "optimierten" FB/FC, dann werden die Variablen am Ende des FB/FC-Aufrufs mit den Werten vom FB/FC-Durchlauf beschrieben. Ein Kommunikations-Schreibzugriff während der FB/FC-Ausführung wird dadurch überschrieben. Laß mal prüfen, ob die Kollegen sowas im SPS-Programm haben.

Äußerst unwahrscheinlich, aber ich spreche morgen nochmal mit meinem Kollegen.
Du meinst ja, dass meine neu gesendeten Daten von der SPS überschrieben werden, aber wäre es dann nicht ein sehr großer Zufall, dass die SPS meine Daten genau mit den Daten überschreibt die ich beim vorherigen Durchlauf gesendet habe?

Um sicherzugehen, daß die Variablen nicht irgendwie im SPS-Programm geschrieben werden: einen neuen DB mit neuer/bisher unbenutzter DB-Nummer nur für Deine Kommunikations-Versuche anlegen und in die SPS laden.

Ja, ich denke so ein Versuch ist wohl nötig/sinnvoll. Voraussichtlich morgen.

 

[Rainer Hönle]

Bei einem INOUT ist dies nicht seltsam sondern eher Absicht. Der alte Wert wird an den FB übergeben, dieser bearbeitet ihn ggf. und am Ende des FB wird der übergebene Wert wieder zurückgeschrieben. Wenn der FB nichts verändert hat, dann steht da jetzt wieder der alte Wert drin, obwohl der PC in der Zwischenzeit ggf. einen neuen Wert geschrieben hat.
Bis jetzt hatten alle diesbezügliche Anfragen diesen Grund, obwohl das im SPS-Programm nicht immer gleich offensichtlich sein muss. Deshalb am besten zum Testen so vorgehen, wie Harald beschrieben hat: separaten DB anlegen, der nirgends in der SPS verwendet wird und dort die Schreib- und Leseversuche machen.

 

[Heinileini]

Du meinst ja, dass meine neu gesendeten Daten von der SPS überschrieben werden, aber wäre es dann nicht ein sehr großer Zufall, dass die SPS meine Daten genau mit den Daten überschreibt die ich beim vorherigen Durchlauf gesendet habe?

Wenn das PLC-Programm zum ZeitPunkt x das Datum liest und den gelesenen Wert zum ZeitPunkt x+n unverändert zurückschreibt UND Du von anderer Seite zwischen dem ZeitPunkt x und dem ZeitPunkt x+n den Wert des Datums änderst . . . rat' mal, wer gewinnt!
Der "Zufall" besteht lediglich darin, mit dem DazwischenFunken den "richtigen" ZeitPunkt zu erwischen bzw. zu verfehlen. Das Rekonstruieren des alten Wertes durch die IN_OUT_VAR-Mimik hat jedoch System.
Der Fehler, bequemerweise zu beschliessen, dass so etwas - wenn überhaupt - nur alle JubelJahre mal eintreten dürfte und deshalb wohl ignoriert werden könne, wird aber gerne gemacht.

 

[Jochen Kühner]

Zuviel Werbung?
-> Hier kostenlos registrieren

In/Out wird doch in 1500er als Pointer übergeben, oder nicht?

 

[PN/DP]

In/Out wird doch in 1500er als Pointer übergeben, oder nicht?

Nur manchmal: nur strukturierte Datentypen werden an InOut by-reference (Pointer) übergeben, wenn beide Bausteine "optimiert" oder beide "nicht optimiert" sind. Sonst wird by-value (als Kopie) übergeben.
siehe Programmierleitfaden für S7-1200/S7-1500

Harald

 

[GuWa]

Also nachdem ich meinem Kollegen die letzten Antworten präsentiert habe, ist ihm die Erleuchtung gekommen und er hat nochmals seine Programmierung geprüft und festgestellt, dass die Drucktabellenstruktur an einer Stelle als INOUT übergeben wird, obwohl hier IN ausreichend ist und die Funktion sowie keine Änderungen an den zugehörigen Daten vornimmt (deswegen dachte er wohl zunächst, dass das INOUT kein Problem sei). Das hat er nun entsprechend geändert (auf IN) und so wie es aussieht funktioniert es nun .
Wir machen ggf. ab Montag noch ein paar Versuche, solange gibt es also keine Neuigkeiten von meiner Seite.
Danke an alle die sich an der Diskussion beteiligt haben für euren hilfreichen und zum Erfolg führenden Tipps, ihr seit Spitze :s12:.

schönes Wochenende wenn es für euch so weit ist, für mich beginnt es heute schon