# OPC Client Excel: Zugriffsrechtproblem



## Stefan.Belkot (18 September 2009)

*Gelöst*

Hallo liebe Community,

*Vorgeschichte:*
ich bin recht neu auf dem Gebiet OPC-Lösungen und arbeite nun an einer automatisierten Sicherung der SPS-Daten... da der OPC-Server "qualifiziert" ist kann ich nur über größeren Aufwand änderungen direkt am OPC-Server-PC vornehmen.

*Problemstellung:*
Wir haben hier noch keine Lösung zum dauerhaften "logging" der SPS Daten. Genau dies soll nun das Ziel sein:
Im Automatisierungsnetzwerk, also abgeschottet von aussen, soll ein PC als OPC-Client mit der Möglichkeit einer vollständigen Daten-Aufnahme & vor allem standardisierter Datensicherung (z.B. in Access DB`s) eingerichtet werden.

*Lösungsweg:*
Es soll über ein Excel VBA Projekt ein OPC Client eingerichtet werden. Das Excel Programm wird so gestaltet werden, dass es die Daten erfasst und sichert.

*Stand:*
Die OPCDAAuto.dll ist downgeloaded & in Excel VBA über "Verweise" registriert. Als Grundlage zur Programmierung habe ich zwei verschiedene Excel-Clients. Einmal direkt von der Siemens Seite und einmal aus einem privatem Projekt aus diesem Forum.
Die Funktionsweise beider Programme ist recht schnell ersichtlich.

Bei der Siemens Lösung muss jedoch, falls das Programm nicht direkt auf dem Server PC ausgeführt wird, eine Anpassung gemacht werden:
Vorher: Call MyOPCServer.Connect(Cells(4, 2))
Nacher: Call MyOPCServer.Connect(Cells(4, 2), Cells(5,2))
Es muss also OPC-Server Name & die IP des PC`s im Netzwerk angegeben werden. Alternativ zur IP kann auch der Name des PC`s angegeben werden (in der Form "\\ PCName" ohne Leerzeichen). Nicht verwechseln mit dem Namen des OPC-Servers, der z.B. in etwa so lautet: OPC.SimaticNET

*Mein spezielles Problem:*
Leider konnte ich keine Lösung finden... ein Hinweis war über DCOM Einstellungen zu finden: Dokument zu DCOM Einstellungen - gegoogleter Forenbeitrag zu Dokument
Die DCOM Einstellungen am geplanten Client waren schon passend eingestellt. Auf dem Server habe ich noch nicht nachschauen können.
Also abhacken...
... denn mein Problem ist: Ich kann mit dem Server Connecten! Jedoch keine Daten auslesen. Also woran kann das liegen?
Es kommt immer die "Fehlermeldung 70: Keine Berechtigung"

Nun aber Schritt für Schritt wie weit ich komme:
Im VBA Script sind folgende Zeilen von Bedeutung

```
'connect the OPC Server    
    Call MyOPCServer.Connect(Cells(4, 2), Cells(5, 2))
     'add one OPC Group
    [I][B]Set MyOPCGroup = MyOPCServer.OPCGroups.Add("Gruppe1")[/B][/I]
```
Im Debug-Modus schaffe ich es noch die .Connect Funktion auszuführen.
Bei .OPCGroups.Add streikt mir das ganze aufgrund von fehlenden Rechten.
Auch auf verschiedene andere Funktionen wie z.B. 
_MyOPCServer.CurrentTime_
kann ich nicht zugreifen aufgrund von Rechtemangel.

Ein Hinweis noch zu meinem Vorgehen:
Noch bevor ich "connecten" kann muss ich z.B. über die Netzwerkumgebung auf den OPC-Server-PC zugreifen und dort mit OPC-Server-PC lokalem Benutzername & Passwort "einloggen". Vorher geht garnichts.

*Mein 1.Lösungsansatz:*
Ich bin mir leider nicht sicher ob das funktioniert... könnte es helfen mich am OPC-Client PC mit dem selben Benutzername/Passwort anzumelden als wie ein existierender User am OPC-Server?
Leider konnte ich das noch nicht testen, OB das überhaupt helfen könnte würde mich brennend interessieren (dazu habe ich nur einen kurzen nicht weiter erklärten Satz über google gefunden, daher dieser Ansatz)

*Fragestellungen:*
Hat vielleicht jemand einen Tip für mich?
Alle Beiträge die ich bisher gefunden habe "scheitern ja schon am .connect"
Ich komme da drüber... also scheint mir ein anderes Problem vorzuliegen als in den dort genannten Beiträgen.

*Last but not Least:*
Der OPC-Server ist von Softing.

... ich hoffe evtl mit ausführlichen & verlinkten Beitrag auch anderen schon weiterhelfen zu können.... und dass die Länge daher eher Förderlich ist als Abschreckt 

*PS:*
Ah bevor ichs vergesse... ich habe es auch schon mit einem NICHT Excel Client probiert mit ebenso der Fehlermeldung "Keine Berechtigung"

*Lösung:*
Die Fragestellung, warum ich denn die .connect Funktion ausführen konnte, jedoch dann doch noch die "Zugriff verweigert" Meldung bekommen hatte, hat sich geklärt.
*Stichwort: DCOM Einstellungen!*
Und zwar Client-PC Seitig. Um nämlich über Excel mit dem OPC-Server kommunizieren zu können muss über die Start->Ausführen->"dcomcnfg" die Einstellung für "Microsoft Office Excel (Worksheet)" gemacht werden.
Meine Einstellungsänderung war: "Authentifizierungsebene => Keine", Sicherheitseinstellungen => Jeweils "Anpassen" und alles erlauben.
Tip:
Warum ich dann noch nicht direkt "arbeiten" konnte war noch ein Problem mit ".additem"
Es ist sehr wichtig dass entsprechendes item wirklich richtig bezeichnet ist, sonst wir keines "erzeugt".


----------



## Question_mark (18 September 2009)

*Remoter Zugriff*

Hallo,

gib mal auf der Seite vom Siemens Support folgende Beitrags-ID ein : 22033262


Gruß

Question_mark

PS : Ein direkter Link auf diese Seite funktionierte nicht, daher nur die ID .


----------



## Stefan.Belkot (18 September 2009)

Hallo und danke für die Antwort.

Leider komme ich heute nicht mehr an den Server. Die Beschreibung werde ich mal probieren.

Allerdings gibt es ein Update:
Mit dem Demo Softing-OPC-client klappt die Verbindung 
Der bringt mir aber leider garnichts... meine Anwendung muss in Excel VBA integriert werden.

Warum also klappt die Verbindung mit der Client-Software des Server-Entwicklers? Aber mit den standard-opc-funktionen nicht...?
Immer noch: Zugriff Verweigert.
... mit dem Softing Client klappte das ganze ohne jegliche Eingaben von Username, Passwort... 
eins fällt mir aber bei der Verbindung des softing clients auf..
Sieht so aus:
opcda://"ServerPCName"/Softing.OPC.S7.DA/*{7D23861T-1234-12AB-AB1A-ABC12AB12ABC}*
Den Dick geschriebenen Wert hatte ich über Excel niergends angegeben (oder wüsste auch nicht wo und wie)
Laut softing-anleitung ist dieser Wert ein code für die Server-Version.


In Excel, nun auch trotz stehender Verbindung mit der Softing Software, habe ich immer noch die Meldung "Zugriff verweigert"


----------



## Rainer Hönle (18 September 2009)

Ist jetzt ein Siemens- oder ein Softing-OPC-Server im Einsatz?
Wenn Softing: die haben ein ActiveX für Excel.


----------



## Stefan.Belkot (18 September 2009)

Hallo Herr Hönle,
Softing.. aber das hat kaum etwas mit dem ActiveX Control zu tun?
Sollte es nicht mit dem Standardisiertem Control gehen?
OPCDAAuto.dll 
Die Aufgabe ist einen Client selbst zu verwirklichen.
Den weiten Funktionsumfang vom softing-client benötige ich garnicht, wobei andererseits ich die OPC Werte in einer von mir gewünschten form sichern will.

Siehe Fragestellung im Erstbeitrag.


----------



## Rainer Hönle (18 September 2009)

Eben deshalb stelle ich die Frage, warum das Rad neu erfunden wird (OPC-Client) und nicht direkt die Aufgabenstellung (Sicherung der Daten) realisiert wird. Da bleibt auch ohne OPC-Gedöns noch genug zum Spielen übrig.
Wenn es allerdings ein Lernprojekt ist, dann sieht das anders aus.
Übrigens: die GUID des OPC-Servers muss selbstverständlich angegeben werden.


----------



## Stefan.Belkot (18 September 2009)

Lernprojekt: Teils teils => Ich bin als Praktikant (Studium Physik) in diesem Unternehmen tätig.
Nun ist für uns (die Abteilung) jedoch auch erstmal die Verwirklichungsmöglichkeit interessant - zudem der OPC Server ein Rechner ist der qualifiziert ist und daher eine Änderung der Software nicht so einfach möglich ist.
Also: OPC-Client ins Netzwerk stellen & dann erstmal Ergebnisse liefern => Die dann wiederrum zur Präsentation genutzt werden um dann eventuell die Datensicherung dauerhaft "laufen zu lassen"

"Übrigens: die GUID des OPC-Servers muss selbstverständlich angegeben werden."
Leider kann ich mit diesem Satz (bin schon zuhause/freizeit) ohne weitere Informationen nichts anfangen (GUID?)
Vielleicht kann mir jemand weiterhelfen wie ich diese GUID (anmeldung???) weitervermitteln kann über VB.
Solang bleibt: (trotz erfolgreicher .connect funktion) 70 Fehlendes Zugriffsrecht


----------



## Rainer Hönle (18 September 2009)

Somit spricht nichts gegen den Einsatz des vorhandenen ActiveX um die Daten auszulesen und dann zur Anzeige etc weiterzuverwenden.
GUID ist die eindeutige Nummer des Servers, über die mein Freund Bill bei COM/DCOM die Kommunikation realisiert. Und wenn nicht klar ist wohin (= keine GUID), dann ist der Fehler auch nicht verwunderlich. An dieser Stelle empfehle ich, einen kleinen Ausflug in die Grundlagen von OPC (= OLE for Process Control), in diesem Fall OLE (Object Linking and Embedding), das massiv Gebrauch von COM/DCOM macht. Im Klartext: bevor ein OPC-Client direkt realisiert werden kann, sollte klar sein, was die Grundlagen sind und wie man damit umgeht. Sonst kommt es früher (wie hier) oder später zu Problemen. Beim Autofahren lernen muss man sich auch erst mit der Theorie beschäftigen.


----------



## Stefan.Belkot (21 September 2009)

Montag Vormittag.. Problem besteht weiterhin:
- Softing Toolbox ActiveX Controls Demo downloaded
=> Versuch mit dem OPC-Server zu connecten schlägt fehl...

Wir wollen auch nur ungern an den Server-Computer ran.

Ein Indiz dass aber die Einstellungen am Server-PC und hier am client-PC passen müssten ist:
Über den "Normalen" Softing-OPC-Client (Demo) klappt die Verbindung wunderbar.
Über die Softing-ActiveX Controls oder auch die OPCDAAuto.dll Controls will es einfach nicht hinhauen.
"Zugriff verweigert"

_Also Frage: Kann die DCOM Einstellung am Server überhaupt "falsch" sein, wenn der Remotezugriff über die Softing-Clien__t Software klappt?_

Nur ungern wollen wir am Server PC Einstellungen ändern... es ist hier eine laufende Produktion und ein Ausfall des Servers wäre fatal.


----------



## Rainer Hönle (21 September 2009)

Dann besteht ja die Hoffnung, dass DCOM richtig eingerichtet ist. Mit welche GUID wird die Verbindung aufgebaut, d.h. wohin soll die Reise gehen?


----------



## Stefan.Belkot (21 September 2009)

Hallo Herr Hönle,
ich danke nochmal für die Antworten hier.

Es scheint dass ich der Lösung nah bin.
Ich habe die DCOM Einstellungen hier am Client PC wohl "verplant".

Nachdem ich nun über die DCOM Einstellungen "Microsoft Office Excel Worksheet" am Client PC bearbeitet habe ist die Zugriffsrecht-Beschwerde weg.

Der nächste Schritt am Aufbau des Clients über Excel ist also das gezielte auslesen von Werten. Dazu muss ich mich noch mit den ActiveX Controls beschäftigen.

Ich werde sobald ich eine Lösung gefunden habe das Topic hier updaten & meinen Lösungsweg posten. Ich habe das Gefühl recht nah dran zu sein.

Die GUID habe ich noch nicht benötigt gehabt. Es reichte bisher die Prog_ID, welche in diesem Falle "Softing.OPC.S7.DA" lautet.
Die GUID vom Server ist "{7D23861T-1234-12AB-AB1A-ABC12AB12ABC}"
Diesen Wert kann man aber niergends in den ActiveX Controls "übergeben".
Dafür bekomme ich jetzt schon Werte wie "Serverzeit" und "Server-Startzeit" übermittelt.

Jetzt gehts daran die Item-Werte anzufordern.... also nochmal etwas mit den oben genannten "Excel-Beispielen" beschäftigen.


----------



## Stefan.Belkot (21 September 2009)

Meine Anwendung funktioniert nun. Jetzt gehts also ans automatische Auslesen - also meine spezielle VB Anwendung.

Der Serverzugriff und die "Clienterstellung" konnte mit der kostenlos zugänglichen OPCDAAuto.dll gelöst werden.
Natürlich ist das ganze noch kein richtiger "Client". Daran habe ich mich jetzt erstmal hinzusetzen und zu programmieren, damit die gewonnenen Daten entsprechend visualisiert oder aufgezeichnet werden.

Ich bin jedenfalls schon ein bisschen Schlauer. Da ich trotzdem nur "Anwender" bleibe wird mein Wissen über OPC entsprechend beschränkt bleiben.

Zur Lösung steht auch noch direkt etwas im 1.Beitrag.
(so "leicht"... und dafür 1 1/2 Werktage getüftelt  gut dass ich hier mit Bildungsauftrag als Praktikant in der Firma bin  )


----------

