TIA Atomare Schreibvorgänge in Siemens 1500 CPUs

Wir haben jetzt noch ein Problem was wir uns nicht erklären können:

Wir schreiben einen Real Wert via AgLink, dieser hat wunderbar funktioniert als der Datenbaustein nicht optimiert war. Nun haben wir den DB auf Optimiert umgestellt, und immer wieder kommt es vor das der Real Wert auf der SPS nicht stimmt. Lt. meinem Kollegen wird der Wert aber auf der SPS nicht beschrieben
 
Lt. meinem Kollegen wird der Wert aber auf der SPS nicht beschrieben
ja... würd ich mal den Hersteller von AG-Link fragen ;)

könnte mir vorstellen:

- Die SPS liest, während grad geschrieben wird > inkonsistent
- es gibt verschiedene "REAL-Formate" der PC verwendet was anderes als Siemens
- Siemens hat was geändert, was AG-Link noch nicht abkann (was ist das für ne SPS? Welche FW? welche TIA-Version?)
- der Real-Wert liegt in ner Struktur oder UDT
- ...

(Bin halt immer noch der Meinung, Siemens hat die optimierten DBs nur eingeführt, um den Fremdherstellern das Leben schwer zu machen)
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
Wir haben jetzt noch ein Problem was wir uns nicht erklären können:

Wir schreiben einen Real Wert via AgLink, dieser hat wunderbar funktioniert als der Datenbaustein nicht optimiert war. Nun haben wir den DB auf Optimiert umgestellt, und immer wieder kommt es vor das der Real Wert auf der SPS nicht stimmt. Lt. meinem Kollegen wird der Wert aber auf der SPS nicht beschrieben
Das kommt mir irgendwie bekannt vor.
Sowas hatte ich auch, als ich Kommunikationsbausteine von S7-300 nach S7-1500 portiert habe.
Nicht optimiert hat funktioniert, optimiert nicht. Da gab es Datenverfälschungen.
Ich hoff mal, dass ich es noch richtig zusammen bekomme (Ist ein paar Jahre her)
Die Ursache war:
S7-1500 hat keinen Zykluskontrollpunkt. Kommunikationsdaten werden zu einem x-beliebigen Zeitpunkt während des Zyklus vom Kommunikationspuffer in den DB übertragen.
Ich habe die Daten als UDT über Parameter durch mehrere FBs geschickt. Bei nicht elementaren Datentypen können Parameter per Call by Value übergeben werden. Werden nun Daten während einer FB-Bearbeitung übertragen, hast Datenverfälschungen. Egal ob man die Daten beschreibt oder nicht.

Interessanterweise hat es auf einer S7-1200 funktioniert.

Im SiePortal gibt es eine Erklärung und weiterführende Links:
https://support.industry.siemens.com/cs/de/de/view/102750088

Vielleicht ist es ja auch was in der Richtung ...
 
Wir schreiben einen Real Wert via AgLink, dieser hat wunderbar funktioniert als der Datenbaustein nicht optimiert war. Nun haben wir den DB auf Optimiert umgestellt, und immer wieder kommt es vor das der Real Wert auf der SPS nicht stimmt. Lt. meinem Kollegen wird der Wert aber auf der SPS nicht beschrieben
Also wenn der Wert nur von außerhalb geschrieben wird und der real einen falschen Wert hat, dann tippe ich auf einen Bug im aglink. Mit dem "neuen" Protokoll hatten wir meines Wissens noch keine solche Probleme.
Mit dem "alten" (mit aglink) mehr als einmal. Wenn ich mich richtig erinnere waren das immer Bugs die was mit dem optimierten lesen/schreiben zu tun hatten und im .net wrapper behoben wurden (readoptmix oder so).
Hab das gerade nicht im Kopf, aber beim symbolischen lesen/schreiben gibt es im aglink glaub kein optimiertes lesen/schreiben.
Schreibst du mehrere variablen auf einmal?
Was passiert wenn du eine variable mehr oder weniger schreibst?
 
Also wenn der Wert nur von außerhalb geschrieben wird und der real einen falschen Wert hat, dann tippe ich auf einen Bug im aglink.
So was lässt sich ja im Prinzip leicht feststellen. Eine nackte CPU und einfach ne Testroutine im OB1 schreiben. Dann kann man feststellen von welcher Seite der Fehler kommt.
 
Also wir hatten 2 Probleme, beim ersten (das mit In_OUT und nicht optimiert) hatte er dann die Firewall aktiviert das auch sicher nur die eine Visu schreiben kann. Als das gelöst war, hat er die wieder rausgenommen und mir nichts gesagt ;-(
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Habens gefunden....
Mein Kollege hatt die Firewall deaktiviert... Und ein anderer hatte bei siche ne Kopie der Visu laufen die den gleichen Wert beschrieben hat....
Kopfschüttel....
Klassiker... wenn man keine Probleme mehr hat, macht man sich welche :-D
Ist mir selbst aber schon so oft passiert, daher kann ich das komplett mitfühlen.

Um nicht ganz unnötig zu schreiben: Ich habe mir angewöhnt einen DB zu haben in dem ich lese und schreibe, und diesen intern im ob1 in meinen arbeits db zu kopieren (je in die richtige Richtung) und mir so einen Zykluskontrollpunkt gebastelt. Damit habe ich immer definierte Zustände, egal was mir der Programmierer macht. Das konsistente Schreiben bei nicht Standard-Datentypen muss man dabei natürlich berücksichtigen, aber das ganze optimiert / nicht optimiert / interrupt / call by value hab ich damit komplett umgangen, natürlich auf kosten von 2 Kopiervorgängen. Da ich meine Kommunikation aber immer versuche schmal zu halten, war das nicht so die teure Operation.

Grüße

Marcel
 
Das bringt mir aber nix wenn in der Visu was berechnet wird und eben ab und an was unterschiedliches darin landet....

Wir haben ja ein eigenes Visu system, das kannst du einfach auf nen anderen rechner kopieren und starten...
 
Warum sind denn die Test-SPSn im Büronetz? Ich hab immer 2 oder mehr Netzwerkkarten in meinem Laptop, und alles was ich so zum Testen auf meinem Bürotisch habe, ist immer nur lokal an meinem Rechner.
 
Zurück
Oben