# Daten archivieren von SPS nach SQL



## urlaub (12 November 2014)

Hallo,

ich möchte das Thema "WinCC flexible Skript Daten Archivieren: Aktualisierungszeit der variablen" aus dem HMI-Forum
hier weiterführen.

Wir hatten gelernt, dass das Archivieren von Prozesswerten über ein WinCC flex Skript nicht sicher ist,
und ich hatte nach Alternativen gefragt.

Mit C# und libnodave habe ich Versuche gemacht, habs aber nicht hingekriegt, OPC erscheint mir noch komplizierter. 
Was gibts ausser Hochsprachen noch für Möglichkeiten? 

Konkret geht es bei uns darum, aus einer S7 317-2PN/DP alle 25s ca. 100-200 Int/Real-Werte in eine Microsoft-SQL-Server Datenbank zu schreiben.

Danke 
urlaub


----------



## JesperMP (12 November 2014)

Hallo Urlaub.

Muss es eigenständig gemacht werden ?
Es ist möglich selber etwas zu basteln, aber um von "es funktioniert" nach "es funktioniert zuverlässig und robust" zu kommen,  ist ein riesen Unterschied.
Es gibt Produkte die für genau diesen Zweck gemacht sind.
Ich kenneOPC Datahub.
Inductive Automation FactorySQL
Matrikon OPC to SQL.
und mehrere ...​
Selber habe ich Inductive Automation eingesetzt.
Ich hatte ein Projekt in Japan mit Datenübertragen nach ein Oracle Server, wo ich es zuerst mit VBS Skripte den Job gelöst habe. Es hat funktioniert, aber nur 99.9% zuverlässig. Das hat mich eine extra Reise nach Japan gekostet um FactorySQL zu installieren.


----------



## Larry Laffer (12 November 2014)

Naja ... C# und LibNoDave wäre da jetzt mein Ansatz gewesen - habe ich ja in dem anderen Thread schon angedeutet. Wo hat es denn da konkret gehapert ? Vielleicht bekommt man das ja auch noch ans Laufen. Esd gäbe da ja auch noch den Jochen Kühner (der auch immer sehr hilfsbereit ist) mit seiner Bibliothek. Und wenn wir schon dabei sind : wenn es auch Geld kosten darf so wäre dann da auch noch die Fa. Deltalogic mit deren AGLink ...

Gruß
Larry


----------



## Larry Laffer (12 November 2014)

@Jesper:
Das, was du da vorschlägst (als fertiges Tool) ist natürlich auch etwas Eigenständiges - also auch "unabhängig von der Visu"

Gruß
Larry


----------



## JesperMP (12 November 2014)

Larry Laffer schrieb:


> Wo hat es denn da konkret gehapert ?


Ist das ein Frage an mir ?
Genau wo das Problem lieg weiss ich nicht. Es kann unterschiedliche Probleme gewesen sein. Ich _denke_ es lag bei den Netzwerk womit mein PC mit der Datenbank Server verbunden war.
Nur manchmal bekam ich Skript Überlauffehler, gegen die ich keine Massnahmen hatte. Einzigste Möglichkeit Fehler abzufangen war bei ein Timeout Rückmeldung von der SQL Verbindung. Dieser Rückmeldung kam aber erst ab 60 Sekunden was zu späht war, weil der Datenübertragen jeden 20 Sekunden passieren musste.

Es ist auch problematisch mit diesen Problematik zu eksperimentieren in ein Anlage das 24/7 zuverlässig funktionieren muss.

FactorySQL konnte offenbar die Probleme hantieren, weil nachdem ich es verwendete anstatt meine selbst-erstellte Skripte hat es für Jahren 100% funktioniert ohne probleme.


----------



## Larry Laffer (12 November 2014)

@Jesper:
Nein ... ich hatte mich eigentlich auf das Folgende bezogen :


urlaub schrieb:


> Mit C# und libnodave habe ich Versuche gemacht, habs aber nicht hingekriegt ...


----------



## LowLevelMahn (12 November 2014)

wenn es um Sicherheit geht - also kein Datenverlust/kein Erfassungs/Zeitlücken usw. geht solltest du definieren was für dich schlimm ist und was du selber machen kannst

folgende Szenarien sind böse:

-der SQL-Server schluckt nicht alle S7-Werte ohne weiteres - z.B. bei NaN oder denormalen Floats fängt er an zu kotzen -> Ersatzwert oder NULL-Loggen
-die Verbindung zu deinem SQL-Server versagt - dann muss du bis zum Reconnect die Daten der SPS lokal Sammeln und dann Überführen
-die Verbindung zu deiner SPS bricht ab, schreibst du weiter zyklisch Werte in deine DB? - welcher Inhalt oder hällst so solange an?
-dein SQL-Server packt die (Insert)Datenrate nicht - hier hilft ein lokaler Datenpuffer und Transaktionen mit mehreren Inserts als Block usw.
...

und am besten genau auf diese Dinge testen - die anderen Sachen funktionieren ohne Probleme - aber konzentrier dich auf die Bösen

diese Probleme und einige mehr musst du beim Selbermachen beachten - sonst Funktioniert so lala und nur in der perfekten Umgebung


----------



## LowLevelMahn (12 November 2014)

ganz überlesen - du willst ja nicht selbst machen - Sorry


----------



## bike (12 November 2014)

Also ich würde libnodave nehmen. 
Das funktioniert ohne Probleme mit verschiedenen Datenbanken.
 Wichtig ist, dass du dir klar machst, wie du die Daten weiterverarbeiten willst.
Redudanz ist auch noch so ein Problem, das geklärt werden muss.


bike


----------



## urlaub (12 November 2014)

@Larry Lafer:
die Versuche mit C# und libnodave sind schon einige Zeit her, woran es genau gescheitert ist kann ich nicht mehr genau sagen.
Meine Hochsprachenkenntnisse sind eher bescheiden. Einen Testaufbau zum Laufen zu bringen und ein betriebssicheres Archivierungsprogramm zu schreiben
sind wohl nochmal ganz verschiedene Sachen, gerade wenn ich an die ganzen bösen Störfälle denke, die LowLevelMahn aufgezählt hat.

@Jesper:
ich werde mir das mal anschauen, was du aufgezählt hast.
Das sieht mehr nach Konfigurieren aus als nach selbst programmieren, das ist wohl eher was für uns.

mfg
urlaub


----------



## JesperMP (12 November 2014)

Von Inductive Automations website:



> *SQL Bridge Module • $2,600*
> Bridges PLC data from OPC to SQL databases. Includes transaction group manager and SQLTags Historian. Unlimited data points. *Limited edition (basic SQL data logging only) available for $1000*.



Der "Limited edition" sollte genügend sein.
Dies ist der Preislage für fertige Tools.


----------



## Larry Laffer (13 November 2014)

... wenn du lieber Konfigurieren als Programmieren willst dann solltest du auf alle Fälle den von Jesper vorgeschlagenen Weg gehen. Ich kann auch an dieser Stelle sagen, dass ich mit den Vorschlägen von Jesper bisher imer ganz gut gefahren bin ...
Der Preis des vorgeschlagenen Tools (wenn es das tut, was du willst) sollte dich auch nicht abschrecken (falls es so ist) - deine Arbeit kostet schlußendlich auch Geld ...

Gruß
Larry


----------



## urlaub (13 November 2014)

Danke an Jesper und Larry

mfg
urlaub


----------



## schattenparker (21 November 2014)

Hast Du Dir mal das hier angesehen?

http://www.iba-ag.com/de/unternehmen/ibaaktuell/termine/250-sps-ipc-drives-2014/#ibapda-plc-xplorer

Schreibt zwar nicht direkt in DB, aber in Dateien.


----------



## rudl (28 November 2014)

Schau dir doch mal SQL4automation an. Aus der SPS hast du direkten Zugriff auf die SQL Datenbank. Die Verbindung wird nur konfiguriert. Aus der SPS kannst du mit SQL Strings auf die Datenbank zugreifen. Es gibt fertige Bibliotheken für Siemens Simatic S7-300, S7-400, S7-1200, S7-1500, sowie für CODESYS, Rockwell Allen-Bradley, Beckhoff TwinCAT, B&R, Sigmatek... Die Bibliotheken und die Demoversion gibts zum Download unter: www.sql4automation.com.


----------



## LowLevelMahn (28 November 2014)

> Aus der SPS hast du direkten Zugriff auf die SQL Datenbank



http://www.sql4automation.com/ - braucht man hier nicht noch eine PC-Software (also auch einen PC)?

http://www.plcsql-link.com/ geht direkt von der SPS auf die DB (ohne Zusatz-PC)


----------



## rudl (28 November 2014)

Ja, SQL4automation läuft auf LINUX und Windows, wird also auf einem kleinen IPC, der SPS oder dem Datenbank PC installiert.


----------



## norustnotrust (28 November 2014)

Es gibt ja von Siemens auch einen CP der angeblich direkt in eine DB schreiben kann: http://support.automation.siemens.c...objaction=csview&extranet=standard&viewreg=WW Ich persönlich habe damit aber noch nie gearbeitet, weiß also nicht ob der hält was er verspricht.


----------

