Excel OPC Client über Netzwerk auf OPC Server

magmaa · 28 Juli 2009

Hallo ich habe mal diese beiden Siemens Beispiele

(Wie erstelle ich einen OPC-Client mit Microsoft Excel?) und
(Wie werden die S7 Controls in Microsoft Excel eingebunden?)

für einen Excel OPC Client ausprobiert. In Zusammenhang mit einem Siemens OPC Server und WinAC auf einem PC.

Lokal funktionieren beiden Beispiele bestens.

Danach ab ich versucht aus dem Netzwerk mit dem Excel Client auf den OPC Server zuzugreifen. Dies funktioniert nur mit dem zweiten Beispiel ohne probleme.

Bei dem ersten Beispiel bekommen ich immer eine Fehlermeldung.
Kann mir da einer weiter Helfen?

magmaa · 11 August 2009

So hab es raus gefunden der OPC Client ist nur für den lokalen Gebrauch.
Für den Netzwerk Gebrauch muss der VBA- Code erweitert werden.

Franz · 4 November 2009

Werte der SPS in Excel darstellen

Hallo,

wie wird denn der VBA Code erweitert?

Ich benutze einen S7 400 und einen CP443-1 und wollte zum Test Werte in Excel darstellen. Der PC und CP befinden sich im gleichen Netz. Habe die Excel Datei einfach mal ausgeführt!
Muss ich auf Seiten der SPS auch noch etwas konfigurieren? Und was muss ich beim OPC Server einstellen?

Dr. OPC · 3 Dezember 2009

Der Fehler, der im Screenshot von Excel angezeigt wird, ist: OPC_E_UNKNOWNITEMID
das kommt direkt aus dem OPC Server und bedeutet, der Server kennt die Items nicht die hinzugefügt werden sollen.

Dies kann nun mehrere Ursachen haben, es wird zum Beispiel "S7:[OPC_1]DB1,W0" angefordert:
1) die an der S7-Verbindung mit dem Namen "OPC_1" hängende SPS besitzt überhaupt keinen Datenbaustein 1
2) sie besitzt diesen Datenbaustein aber der hat nur die Länge von einem Byte (und nicht einem Wort wie angefordert)
3) dem OPC Server mit dem verbunden wird, ist die S7-Verbindung "OPC_1" völlig unbekannt (z.B. weil er nicht projektiert wurde oder die Verbindung ein ganz anderen Namen hat z.B. "OPC-1")
4) Die Verbindung ist zwar projektiert , kann aber nicht aufgebaut werden (z.B. weil die hinterlegte IP Addresse falsch ist)

magmaa · 4 Dezember 2009

Hallo gut das jetzt einen OPC Doktor hier gibt.

Das Problem mit dem Excel client ist das er nicht für das Netzwerk gedacht ist sondern für den Lokalen Einsatz.
Man kann zwar die IP angeben diese wird aber im hinterlegten VBA- Code nicht berücksichtigt.
Erweitern man den VBA Code funktioniert es:

Code:

[FONT=Arial][/FONT]
[FONT=Arial]z.B. Call MyOPCServer.Connect( Cells (4, 2), Cells (5, 2) )[/FONT]

Dr. OPC · 4 Dezember 2009

Das ist natürlich richtig, die IP Adresse (oder Rechnernamen) sollte auch in den OPC-Connect-Aufruf reingesteckt werden, sonst kann das nicht gehen.

Wenn man diesen 2. Parameter im Connect weg lässt oder nicht befüllt, dann verbindet sich der Client auf den "lokalen" OPC Server. Dort waren dann die angeforderten OPC Items offensichtlich nicht bekannt "unknownitemid". Wenn ein derartiger Fehler-Code auftritt, kann das (nur) die beschriebenen Ursachen haben.

z.B. war im obigen Fall der syntaktische Aufbau der ItemID schon richtig (die "Rechtschreibung" war also OK), sonst hätte der Server den Fehler "invaliditemid" gebracht, ein feiner aber wichtiger Unterschied da eine ganz andere Ursache zugrunde liegt: wie "." und "," vertauscht oder "]" vergessen.

magmaa · 4 Dezember 2009

Genau aber ich habe noch ein weiteres Problem bei dem du mir sicher auch weiter helfen kannst.

Muss nur mal das ganze Starten und Screenshot machen.

magmaa · 4 Dezember 2009

Aso mein Problem ist ich habe ein nacktes System:

Win XP SP2
Simatic NET 7.1
Office 2003

auf dem System möchte ich jetzt den Excel Client laufen lassen.
Nur leider bekomme ich keine Verbindung zum dem OPC Server

Ich erhalte immer als Fehlermeldung Laufzeitfehler '70' Zugriff verweigert.

Selbst mit dem OPC Scout bekomme ich keine Verbindung zustanden.

Was kann ich tun?

Stefan.Belkot · 8 Dezember 2009

Ich habe das Problem mal durch das freischalten von DCOM von Excel gelöst.

Mein Beitrag damals mit Lösung:
http://sps-forum.de/showthread.php?t=30373

Wenn 'Sicherheit' also kein problem ist, weil 'von aussen' auf das Netzwerk sowieso nicht zugegriffen werden kann (getrenntes Netz) bitte sehr. DCOM komplett öffnen und gut ists.

Natürlich muss auch Serverseitig eine entsprechende Konfiguration da sein. In meinem Fall musste ich aber am Server PC nichts machen (zum Glück thema validiertes System)

PS:
Der 'Fehler' trat erst nach der 'Connection' Funktion auf... auch ganz wichtig!
Also erst wenn der Client die Remotecontrol Funktion '.addgroup' ausführen wollte. (wo dann wohl der OPC-Server "die macht" an sich reissen wollte *g* aber nicht durfte - oder so ähnlich)

magmaa · 8 Dezember 2009

Ok Danke, werde ich mir mal bis zum Wochenende ansehen ob es dann bei mir läuft.

Stefan.Belkot · 8 Dezember 2009

ahjo also was auch noch interessant ist neben DCOM Einstellungen ist der Absatz:

"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."

heisst: Erstmal in der Netzwerkumgebung schauen ob der entsprechende PC mit OPC-Server zu finden ist und ob darauf zugegriffen werden kann.
In meinem Fall siehe oben: Ohne vorheriges einloggen auf dem OPC-Server-PC ging nüschts

magmaa · 8 Dezember 2009

Gut zu wissen

magmaa · 11 Dezember 2009

So hab mal wieder bisschen Rum gespielt will aber nicht so richtig.

Wie gesagt nicht mal mit dem OPCScout bekomme ich ne Verbindung hin.
Das schon merkwürdig.

Stefan.Belkot · 14 Dezember 2009

Die Fehlermeldung kenne ich nun nicht. Wurde wohl auch von OPCScout generiert. Hört sich jedenfalls nicht nach OPC-Library Standardmeldungen an.

2 Vorschläge:
- Lokale DCOM-Konfiguration für das Programm OPCScout checken
- evtl DCOM-Konfiguration auf dem OPC-Server selbst checken (steht ja so umschrieben auch in der Fehlermeldung)

Ich glaube der Softing-Demo-Client konfiguriert seine DCom Einstellungen 'automatisch' bei der Installation. Vlt also mal mit dem testen? Bei mir klappte der ohne weitere Einstellungen... kann aber auch daran liegen, dass bei uns ein Softing OPC-Server im Einsatz war an der Stelle.
Für Testumgebungen können die verschiedenen Softing Anwendungen als Demo frei verwendet werden.

Also wenn ein Zugriff besteht auf den PC, auf dem der OPC-Server läuft, dann mal ran da und zumindest von der Seite die DCOM-Einstellungen machen (für den OPC-Server mit Zugriffslevel 'JEDER')... bzw wenn die Öffnung von DCOM nicht soooo einfach mal 'probiert' werden dürfte zumindest mal nachschauen wie die Zugriffe geregelt sind. Siehe DCOM Konf. Anleitungen in meinem Posting

magmaa · 14 Dezember 2009

Hab ich schon gemacht die Einstellungen.

Mich wundert nur das es auf den Systemen wo Step7 und Wincc und co. installiert ist ohne irgentwelche Einstellungen, Werder auf Server als auf Client Seite läuft.

Stefan.Belkot · 14 Dezember 2009

magmaa schrieb:
Mich wundert nur das es auf den Systemen wo Step7 und Wincc und co. installiert ist ohne irgentwelche Einstellungen, Werder auf Server als auf Client Seite läuft.

Mh damit sind z.B. HMI`s oder so gemeint?
Naja, denke das liegt mitunter daran, dass der OPC-Server dort auch lokal auf dem entsprechendem Rechner läuft und auch von aussen abgeschottet ist.
Lokal OPC-Server und lokal OPC-Client ist praktisch nie ein Problem.

Wenn die Sicherheit eine Rolle spielt & an den OPC-Server-PC rangegangen werden kann dann könnte auch ein OPC-Tunnel interessant sein... allerdings habe ich damit noch keine Erfahrung.

Mein Topic http://sps-forum.de/showthread.php?t=30373 war aber auch richtig zum verzweifeln...
ich bin Praktikant bzw Werkstudent und habe nunmal einfach die Zeit gehabt... BIS zur Lösung sind effektiv wohl 15-20 reine Arbeitsstunden, googlen, probieren etc 'draufgegangen'.
Sowas kann man sich ja wenn mal richtig drin im Job kaum mehr leisten

*denkt grad dran wenn der Cheffe den Ingenieur fragt was er den ganzen Tag gemacht hat und eine Aussage kommt wie: seit 15 Arbeitsstunden am 'rumprobieren ohne Lösung' *
... selbst mir als Praktikant war das schon fast peinlich ...

magmaa · 14 Dezember 2009

Nein nicht lokal, bei den anderen Systemen greife ich auch über das Netzwerk auf den OPC Server zu. Der einzige unterschied ist das auf den anderen Systemen diese Software (Step7, WinCC) noch zusätzlich drauf ist und es da funktioniert und bei dem Nacktem System mit nur Office und Simatic Net nicht.

Hab leider dein Topic noch nicht gelesen werde mal bis zum We versuchen zu schafen und dann wieder mal versuchen.

Trozdem Danke für dein behühen.

Dr. OPC · 19 Dezember 2009

Na das ist doch alles ganz einfach. Die Fehlermedung bedeutet "Zugriff verweigert" (Hexadezimal 47) oder H46 wie die Fehlermeldung im Scout es auch anzeigt. Und in Excel ist es "70" (dezimal) bedeutet aber das selbe.

Die DCOM Einstellungen sollte man nicht anfassen wenn mann nicht genau weiß was man tut. Im Prinzip ist das aber auch ganz leicht, vor allem ab XP SP2. Mein Tip: immer nur an einer Schraube drehen und sich den Effekt anschauen, sonst lernt man nichts dabei oder die Kiste ist hinterher total verbastelt und es geht nichts mehr. Ich vermute aber das war hier nicht das Problem.

Folgende Einstellung wird den Erfolg bringen:

Systemsteuerung --> Lokale Sicherheitsrichtlinie --> Sicherheitsoptionen --> Netzwerkzugriff: Modell für gemeinsame Nutzung und Sicherheitsmodell für lokale Konten --> umstellen auf "klassisch-lokale Benutzer authentifizieren sich als sie selbst"

Das Problem ist dass aus Sicherheitsgründen (und das ist ja auch gut so) bei einem neu installierten XP alle Zugriffe, die von "aussen" kommen, auf den "Guest" Account "umgebogen" werden. Und dieser ist natürlich "disabled". Da geht also erstmal nichts.

Für OPC Kommunikation sollte man das auf "klassisch" umstellen (klassisch übrigens deshalb weil es "damals" bei Win2000 so war). Und schon geht alles.

Übrigens stellen Produkte der Simatic-Familie das schon beim Setup richtig ein (andere OPC Produkte übrigens auch). Bei SimaticNET gibt es in der "Konfigurations-Konsole" noch den "Sicherheits-Button" der den OPC Server "auf einen Schlag" für Zugriffe von aussen (remote) konfiguriert. Inklusive Firewalleinstellungen.

Stefan.Belkot · 21 Dezember 2009

Dr. OPC schrieb:
Na das ist doch alles ganz einfach.

Hihi, ja das ist wohl ansichtssache

Ich bin da nach dem Try&Error Prinzip vorgegangen bis es funktionierte. Dabei aber sehr vorsichtig, was den Prozess noch länger hingezogen hat... Immerhin wollte ich bei allem was ich mache auch erstmal Recherchieren was ich da überhaupt mache...
sollte ja auch der Sinn eines Praktikums in der Industrie sein!

Dr. OPC schrieb:
Übrigens stellen Produkte der Simatic-Familie das schon beim Setup richtig ein (andere OPC Produkte übrigens auch).

Bei uns lief ein OPC-Server von Softing. Mit dem Softing Demo-Client war der Zugriff auch kein Problem - nur Excel wollte eben nicht so ganz. Ein Zeichen dafür, dass der Softing Client benötigte Einstellungen schon bei der Installation richtig setzte. Mit dem OPC-Scout funktionierte das übrigens nicht...
Warum Excel bei mir? Ganz einfach weil ich in Excel-VBA ganz gut eingearbeitet war und das für mich die einfachste - und kostenlose - alternative war OPC-Daten auf irgendeine Weise zu sichern oder auch zu visualisieren/auszuwerten.

magmaa · 23 Dezember 2009

Systemsteuerung --> Lokale Sicherheitsrichtlinie --> Sicherheitsoptionen --> Netzwerkzugriff: Modell für gemeinsame Nutzung und Sicherheitsmodell für lokale Konten --> umstellen auf "klassisch-lokale Benutzer authentifizieren sich als sie selbst"

So hab mal die Einstellung gemacht ändert aber nix bleibt bei der Fehlermeldung.

Ist die Einstellung nicht eher was für die Server Seite?

Excel OPC Client über Netzwerk auf OPC Server

Level-1

Anhänge

Level-1

Level-1

Level-1

Level-1

Level-1

Level-1

Level-1

Level-1

Level-1

Level-1

Level-1

Level-1

Anhänge

Level-1

Level-1

Level-1

Level-1

Level-1

Level-1

Level-1

Similar threads

Wir schützen deine Privatsphäre