Step 7 Probleme Datenerfassung S7 -->AGLink-->MSSQL

Bitreactor

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

wir betreiben bereits seit einigen Jahren eine Datenerfassung welche aus vordefinierten Datenbausteinen
Produktionsdaten abruft und in eine MSSQL DB schreibt.
Die S7 sind entweder über interne Schnittstelle (falls vorhanden) oder über NETLink Adapter ans Netzwerk angebunden.
Das Ganze läuft über einen Windows Dienst (.NET) der über ACCON AGLink mit den CPU´s (ca. 100) kommuniziert.

Das System läuft eigentlich sehr stabil allerdings finden wir durch genaueres Untersuchen immer wieder
einzelne "verschluckte" Datensätze die wir uns nicht erklären können.

Noch was zur Funktionsweise:

- SPS stellt im DB die Daten bereit
- im DB wird ein Zähler inkrementiert
- Datenerfassung schaut zyklisch auf den DB und schreibt bei Änderung des Zählers die Daten in die Datenbank

Leider finden wir immer wieder einzelne Datensätze die scheinbar "verschluckt" wurden so ca. 0,1 % grob geschätzt.
Die Zählerspalte die mitgeschrieben wird sieht in der Datenbank dann z.B. so aus:

1
2
4
5

Ich weiß das Thema ist ziemlich komplex und es lassen sich natürlich nur ein Bruchteil der Informationen zur Verfügung stellen.
Aber ich bin mittlerweile ratlos da ich meinerseits alles ausgeschlossen habe was ich kann.
Es wird eigentlich alles was schieflaufen kann protokolliert.

-Fehler beim Verbindungaufbau zur SPS
-Laufzeitfehler der Anwendung
-Überschreitung der "normalen" Abfragedauer einer SPS

Falls jemand eine Idee hat wäre ich sehr dankbar.
 
Die Frage ist, ob die SPS mitbekommt, dass die Daten auch abgeholt wurden. Ändern sich die Daten in der SPS zu schnell, kann es sein, dass die Daten (bei dir im Beispiel Nr. 3) noch gar nicht abgeholt und gespeichert wurden, von der SPS aber schon der nächste Datensatz geschrieben wurde.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo Ralle,
die Abfragezyklus liegt bei 1,5 Sekunden.
Es gibt keine Station die eine Taktzeit von unter 6 Sekunden hat die meisten sogar erheblich mehr.
Das schließe ich eigentlich aus.
 
Ihr fragt 100 SPS in 1,5 Sekunden ab und holt da die Daten in die Datenbank?
Das wäre wirklich sehr schnell. Kann ich mit nur für das reine Polling der Zähler so richtig vorstellen.
Vielleicht gibt es Lastereignisse, in denen dann aus vielen Stationen viele Daten gehohlt werden müssen?
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ich hatte auch schön überlegt ob evtl. das Problem beim Schreiben der Daten in die DB das Problem sein könnte.
Die Last auf dem SQL Server ist teilweise doch recht hoch da nicht nur geschrieben sondern auch zyklisch Daten für die verschiedenen Visualisierungen an
den Anlagen aufbereitet werden.
Allerdings kann das theoretisch nicht sein weil dann beim Schreiben der Daten eine exception auftreten müsste die protokolliert würde
und das Schreiben in die DB liegt mit in dem Bereich der über die Zykluszeitüberwachung der Datenerfassung abgedeckt wird, das würde auch protokolliert wenns zu lange dauert.
 
Na ja ok, ich hab da so einen Problemfall mit WinCC7.0, da kann es schon mal 60 Sekunden dauern, bis eine FTP-Anfrage erledigt ist (kommt über VB-Komponente). Ich dachte erst, es wäre FTP, aber es ist das WinCC, wahrscheinlich ist die Script-queue überlastet, aber eine Fehlermeldung gibt es nur, wenn ich einenTimout selbst überwache. :-(
Das Dumme, es wird erst richtig schlimm, wenn ich mit dem PG über Ethernet online Bausteine beobachte. Das muß man erst mal rausbekommen. Auch hier könnte noch der SQL-Server in Frage kommen.
 
dein SQL-Insert oder der SPS-Read braucht hin und wieder mal kurz etwas länger und schon driften deine Read/Inserts langsam aber kontinuierlich vom SPS-Zyklus weg - bis eben mal ein Zyklus "superknapp" verpasst wird

solange du keinen Handshake zwischen SPS und PC oder wenigstens für den PC-Read einen Durchgeführt-Counter auf der SPS hast
(damit du erkennen kannst ob kein Read stattgefunden hat) kannst du das erstmal nicht sauber erkennen
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo,

LowLevelMahn.
Die Idee mit dem "Durchgeführt-Counter" ist gut und wäre ein Versuch wert das so einzubauen.
Das mit dem Wegdriften kann meiner Meinung nach nicht passieren, da ich überall immer mindestens 2-3
Abfragezyklen schaffe pro Anlagenzyklus.
 
Die Idee mit dem "Durchgeführt-Counter" ist gut und wäre ein Versuch wert das so einzubauen.

Einfach mal einbauen dann kannst du das wenigstens ausschliessen

Zusatzfrage: du machst aber schon eine Zeiterfassung(Benchmarking) zu deinen SPS-Read/SQL-Insert Zeiten, oder? z.B. Min/Max/Durchschnitt
sonst könnte es da ja problemlos "grosse" Ausreisser geben die du einfach nicht siehst
 
Zuletzt bearbeitet:
Ich werde das einbauen, das Problem ist nur dass ich den Dienst nicht immer beliebig anhalten kann um
ihn zu aktualisieren.
Zu deiner Frage:
Ich kann natürlich nicht jeden Abfragezyklus wegspeichern, deshalb habe ich
Schwellwerte eingebaut. Wenn ein kompletter Abfragezyklus (inkl. Connect, Read, Disconnect, SQL...) diesen Wert übersteigt
wird das in einer zusätzlich SQL Tabelle gespeichert. Dort finde ich auch vereinzelte Einträge die aber weder zum Verlustzeitpunkt passen,
noch dass diese gross genug wären um das Problem auszulösen.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Warum erhältst du die Verbindungen zwischen den Abfragezyklen nicht aufrecht, wenn du alle 6 Sekunden abfragst? 100 TCP-Verbindungen stellen doch kein Problem mehr dar. Wenn du nur ein Datensatz der in ein Telegramm passt abfragst, kostet der Verbindungsaufbau schon einen großen Anteil an der Gesamtzeit.

Behebt aber nicht das eigentliche Problem, eine gesicherte Übertragung bekommst du nur mit Handshake-Signalen in den Griff.
 
Das hatte damals einen Grund warum wir die Verbindung wieder schliessen. Ich weiß nicht mehr genau warum aber
ich glaube es gab Probleme mit den NETLink Adaptern.
 
Zurück
Oben