# Arrays mit "IndustrialDataBridge"



## logo78 (11 Februar 2010)

Ich kann keine Arrays mit IndustrialDataBridge auslesen.
Als Target hat mir einmal eine Excel-Tabelle und zum Anderen mal ein CSV File gedient. In der Spalte mit meinen Arrays steht dann immer "bad quality" osä.

Beim Konfigurieren habe ich als Data Type Array angeklickt, aber auch Binary String genommen. Geht leider nicht.

Den Auswahldialog mit den Triggern habe ich bisjetzt auch noch nicht zu Gesicht bekommen?!

Falls ich eine Datenbank (anstatt CSV) für meine Daten aufsetzen würdem, was sollte ich nehmen; SQL/Access ...? Gibt es so eine freie, schnell  & simple Datenbank mit ner Gui?


----------



## logo78 (15 Februar 2010)

Alsooo, ein kurzer Zwischenstand:


Ein ganzer Datenbereich wie Beispielsweise Db400,Int0,10 (Array) lässt sich einfach nicht auslesen. Als Target haben; Access, Excel, CSV und eine MySQL Datenbank gedient. Obwohl ich alles mögliche versucht habe, habe ich es mit DataBridge (v7.x) von Siemens nicht hingekriegt! Wenn ich es richtig verstanden gibt man beim Zieldatentyp (e.g. SQL-DB) ein char/varchar etc.. aus, da er die Arrays ja nur als String interpretieren kann.
DataLogger von SoftwareToolBox meckert wenigstens gleich beim aufzeichnen unten in der Konsole, dass keine Arrays unterstützt werden.
Die Bedienung von IndustrialToolBox ist nicht gerade intuitiv, selbsterklärend oder gar benutzerfreundlich. Die Beschreibung gibt leider nicht viel her. Gerade wenn es um das lesne von Arrays geht.
MySQL Anbindung funktioniert. Man darf zwar den neuesten Server nehmen, muss aber sich den alten Connector v3.51.23 (aktuell=v5.1.6) aus dem Netz besorgen. *Es geht nur mit diesem!*
Richtig blöde finde ich, dass er es mit dem SQL Clienten nicht schafft, die benötigten Felder selbst anzulegen (mit SQL Befehlen). 
Sprich, es muss für jedes aufzuzeichnende Element auf ein Feld in der SQL-DB existieren! Super wäre es gewesen, wenn er diese einfach in der Tabelle selber anlegen würde.
Fazit: Für mein endloses Glück müsste die DataBridge die Arrays lesen und die notwendigen Felder in der SQL/CSV-DB selber anlegen könne.
Vllt liegt es auch an meiner Unfähigkeit, welches aber gänzlich ausgeschlossen werden muss


----------



## Dr. OPC (7 April 2010)

falls es doch mal jemanden interessiert:

Die IndustrialDataBridge verschaltet "OPC-Items" mit einem Datenziel (z.B. ein Feld in einer Datenbank). Immer wenn der Wert des OPC Items "zappelt", wird der Wert in die Datenbank geschrieben. Der DataLogger und ähnliche Tools funktionieren alle sehr ähnlich.

Abhängig vom Datentyp des Ziels (also dem Feld in der Datenbank) versucht die DataBridge den Wert vom OPCServer anzufordern. Hierzu wird der sogenannte "requested Datatype" verwendet. Nemen wir an das Feld in der DB ist INT32 und das OPC Item ist ein Byte dann fragt die Databridge den OPCServer "bitte gib mir dieses Byte als INT32". Der Server liefert es dann als INT32 (wenn eine Konvertierung möglich ist) und die DataBridge kann den Wert dann einfach so in die Datenbank schreiben. Hier sind nicht alle Konvertierungen möglich und der OPC Server kann einen Requested Datatype auch ablehnen.

Bei einem Array ist das schon schwieriger denn das läßt ich NUR in einen String konvertieren. Das Feld in der Datenbank in der es landen soll, muss also vom Typ "Text" sein (mal abgesehen davon das die Textlänge auch ausreichen sollte um den konvertierten String aufzunehmen). Die Stringkonvertierung eines Arrays kann nun sehr seltsam aussehen und mitunter komische Sonderzeichen enthalten, die in der Datenbank seltsame Sonderbedeutungen haben können. 

Als Alternative könnte man die Arrayelemente einzeln Addressieren und auch einzeln in (unterschiedliche) Datenbankfelder abfüllen.  Das Problem dabei ist a) ein deutlich erhöhter Konfigurationsaufwand und b) die Datenkonsitenz ist dann nicht mehr sichergestellt.

Eine weitere Möglichkeit ist den Wert innerhalb der Bridge zu konvertieren. Meines wissens macht die Databridge das nicht, beim DataLogger bin ich mir nicht sicher ob man da für jeden Datenpunkt noch eine "Umrechnungs-vorschrit" angeben kann.


----------



## logo78 (7 April 2010)

um noch ein paar hart erarbeitete Randbemerkungen loszuwerden:
Um sich den höheren Aufwand für SQL zu umgehen, CSV ja, aber nur bei kleinen und überschaubaren Projekten, da: 
der Ole Treiber von MS eine Dateigröße von max 2Gbyte nur zulässt
maximal 4000 offene Verbindungen (bzw. 4000 Felder) möglich sind
die Datei exclusiv vom dummen DataBridge gesperrt wird und so lange der Dienst noch läuft, man nichts mit den CSVs anstellen kann.
Ein erneuter Start vom Dienst läuft auch nicht immer zuverlässig ab, nicht selten ist danach ein Reboot von nöten.
die Datei sehr schnell anwachsen kann und der Databridge keine neuen Dateien anlegt (pro Ereignis, pro Tag, pro 1Gbyte etc..)
schon mal überlegt. mit was man eine 2Gbyte große CSV aufmacht, anschaut oder sogar editiert?  Tip: HiEditor
Mann kann mit den CSV nur etwas anfangen, wenn man die Daten lokal auf seinem Rechner hat. Kein wirklicher Spass Gbytes an Daten mit ner lahmen VPN Verbindung zu besorgen. So mal auf die schnelle reinschauen, ist nicht! Und xx Gbyte sind auch nicht in 5min komprimiert

Darum lieber gleich sich die Arbeit machen und eine richtige DB nehmen! Hat alle die oben genannten Einschränken *nicht* und zusätzlich kann man beispielweise:
Bei der MySQL anstatt InnoDB, Archive oder myisam als Engine auswählen, womit die DB in echtzeit komprimiert wird. Hat zwar ein paar kleine Nachteile, aber für unser OPC zweck eher unrelevante.
Außerdem kann man mit dem entsprechendem Aufwand und ein par SQL Kentnissen, ein unterbrechungsfreies Logging mit Archivierung aufbauen (mit zwei SQL Servern).


----------

