# Verbindung zu OPC Server herstellen (Servername nicht bekannt)



## matziane (17 Januar 2011)

Hallo,

habe vor eine Verbindung zu einem laufenden OPC Server auf einem anderen Rechner herzustellen.
IP des Rechners ist bekannt, Routing auf anderen Rechner funktioniert.
Ping absetzen ist erfolgreich.
OPC Scout will ja bei Verbindsherstellung Servernamen haben, diesen kenne ich aber nicht.

Gibts es Tools um den Servernamen zu ermitteln?
Kann ich auf dem Rechner auf dem der OPC Server läuft den Namen ermitteln?

Vielen Dank im voraus für eure Hilfe.


----------



## marlob (17 Januar 2011)

Auf welchem Betriebssystem läuft dein OPC-Server?
Bei Windows 2000 / XP findest du den Computernamen hier:
http://www.its05.de/computerwissen-.../system-windows/win_2000_xp_computername.html

Da steht zwar Ändern des Computernamens, aber es gibt einen Hinweis wie man ihn findet ;-)


----------



## matziane (17 Januar 2011)

Nene, den Computernamen kenne ich, den brauche ich ja für den OPC Scout auch nicht.
Den Namen des OPC Servers muss ich wissen.


----------



## marlob (17 Januar 2011)

ping /a Ip-adresse


----------



## marlob (17 Januar 2011)

matziane schrieb:


> Nene, den Computernamen kenne ich, den brauche ich ja für den OPC Scout auch nicht.
> Den Namen des OPC Servers muss ich wissen.


Ich meinte ja auch den Computernamen vom Server. Kannst du da nicht bei?


----------



## marlob (17 Januar 2011)

Oder
nslookup ip-adresse
falls DNS verwendet wird


----------



## matziane (17 Januar 2011)

Nene, der Name des Rechners bzw. Servers ist ja ein anderer als der des auf dem Rechner laufenden OPC Servers.
Habe z.Bsp. einen anderen Rechner bei dem mir der OPC Servername bekannt ist.
Der Rechner selbst heisst "VISU" und der Name des OPC Servers ist "OPC.SimaticNet"

Nur bei diesem Rechner jetzt ist mir der Name des OPC Servers nicht bekannt, den Namen des Rechners kenne ich bereits.


----------



## marlob (17 Januar 2011)

Habe ich wohl was falsch verstanden. Trotzdem noch mal meine Frage von oben. Kannst du nicht an der Server ran kommen um dir den Namen auszulesen.
Du könntest doch auch mal mit einem OPC-Client durchs Netzwerk browsen. Matrikon z.B.


----------



## matziane (17 Januar 2011)

Sowas wie auf der Seite beschrieben such ich, was kannst da empfehlen?
Den OPC Explorer oder den Sniffer?


----------



## marlob (17 Januar 2011)

Den Sniffer habe ich nicht in Gebrauch. Den Explorer benutze ich ständig.
Der ist auch gratis.


----------



## matziane (17 Januar 2011)

Und mit dem kann ich nach laufenden OPC Servern auf einem entfernten Rechner suchen?


----------



## marlob (17 Januar 2011)

matziane schrieb:


> Und mit dem kann ich nach laufenden OPC Servern auf einem entfernten Rechner suchen?


Ja, einfach Programm starten und dann fragt er ob er browsen soll.


----------



## Dr. OPC (17 Januar 2011)

Die Bedienung beim "alten" OPC Scout ist etwas "seltsam".

Rechte Maus auf "Remote Server" und dann kommt die Auswahl "Browsen" oder "selber eingeben". Bei Browsen durchsucht er das Netzwerk und listet (erstmal) die Rechnernamen auf, die er gefunden hat. Wenn du dann den entsprechenden Rechner anklickst (den Namen anklicken nicht +), fragt er diesen nochmal explizit nach den vorhandenen OPC Server und listet diese im mittleren Fenster auf.

Hintergrund: Es werden zwei Funktionen verwendet, einmal um sich die Rechner im Netzwerk (ganz normale Windows-Betriebssystem-Funktion, die auch der Windows-Explorer benutzt) zu holen und zum Zweiten ein Aufruf an den OPCEnum zum Ermitteln der installierten OPC Server auf der betreffenden Maschine.

Der OPC Enum ist ein Dienst, der (für einen bestimmten Rechnernamen) eine Liste der dort registrierten OPC Server (ProcID und CLSID) zurückgibt.


----------



## AutoSPy (18 Januar 2011)

matziane schrieb:


> Kann ich auf dem Rechner auf dem der OPC Server läuft den Namen ermitteln?


 
Vielleicht noch zur Ergänzung: Diese Fragestellung ließe sich auch mit unserem SPS-Analyser AutoSPy bequem klären. 

Folgende Schritte wären notwendig: 
1. Demo installieren, starten und neues Dokument anlegen
2. Datenquelle "OPC Data Access" einfügen und "Konfigurieren..."
3. OPC-Server lokal oder im Netzwerk browsen und verbinden (optional)

Die Demo gestattet auch die Aufzeichnung von zwei beliebigen OPC-Items (zeitlich unbegrenzt).

Viele Grüße, 
Jens


----------



## matziane (31 Januar 2011)

Hallo,

mal ein paar Neuigkeiten zu meinem Problem, den Servernamen habe ich mittlerweile schon rausbekommen können.
Zum einen Nachfrage beim Hersteller der Anlage und zum anderen in der DCOM Konfiguration steht er auch drinne.
Nun gehen die Probleme natürlich weiter, da sich beide Rechner in unterschiedlichen Arbeitsgruppen befinden, finde ich den OPC Server über den OPC Explorer schonmal nicht.
Da ich aber die IP und den Servernamen kenne, habe ich das so eingegeben, jedoch meldet der OPC Explorer, dass dort kein OPC Server läuft.
Stimmt aber nicht, lokal kann ich auf den OPC Server zugreifen, habe dort einen OPC Scout gefunden.

Könnt ihr mir Rat geben wie ich eine Arbeitsgruppenübergreifende Kommunikation zu dem OPC Server hinbekomm?


----------



## Dr. OPC (31 Januar 2011)

Das Finden der Rechner, die in unterschiedlichen Arbeitsgruppen sind, hat prinzipiell NICHTS mit OPC zu tun. Die OPC Clients müssen hier eine Windows-Betriebssystemfunktion verwenden. Das funktioniert im Windows-Explorer schon meistens nicht und daher bei OPC Clients auch nicht, denn die Funktion ist nur dann einigermaßen zuverlässig wenn die Rechner in der selben Arbeitsgruppe sind (und schon einige Zeit laufen). OPC hat hier also keine eigene Funktion definiert sondern geglaubt eine Funktion von Windows verwenden zu können (eine Fehleinschätzung).

ABER, wie du schon richtig vermutest, wenn du die IP kennst dann brauchst du die Windowsfunktion nicht benutzen sondern kannst im OPC Client direkt die IP angeben. Danach gibt es zwei Möglichkeiten
a) mit der IP Addresse nach OPC Servern auf dieser Maschine suchen (OPCEnum)
b) mit der IP Addresse (und der ProgID des OPC Servers) direkt versuchen den Server zu verbinden.

Bei a) macht der OPC Client einen Aufruf an den Prozess "OPCEnum.exe" auf dem remoten Rechner. Dieser sollte funktionieren denn das die DCOM Rechte des OPC Enum nicht stimmen ist unwahrscheinlich. Dieser Prozess läuft normalerweise als "Dienst" und lässt einen "Anonymous" Zugriff zu.

Bei b) solltest du prüfen in welchem Nutzerkontext der Server läuft und in welchem der Client (Taskmanager). Am einfachsten wäre es wenn es in beiden Fällen die selbe Person ist (die selbe Person bedeutet Login und PWD identisch, gleicher Login aber unterschiedliche PWD auf zwei Maschinen sind auch zwei unterschiedliche Personen). Leider ist das nicht immer der Fall und dann sollten beide Personen auf beiden Maschinen bekannt sein (Account muss existieren) und in den DCOM-Rechten der Prozesse sollten Start und gegnseitige Zugriffsrechte eingestellt werden.

Die Einstellung der Rechte hat übrigens mit OPC ebenfalls NICHTS zu tun, es ist ein "Feature" von Microsoft (das bei verschiedenen Windowsversionen auch noch unterschiedliche Defaulteinstellungen hat)

Eine (wie ich finde) sehr gute Beschreibung findest du hier:
http://www.ascolab.com/de/dokumente.html
im Unterpunkt "Dokumente"

Viele Herrsteller haben sich diese recht komplizierte Einstellung der DCOM Rechte kommerziell zu Nutze gemacht und bieten Tools um der DCOM-Konfiguration aus dem Wege zu gehen. Diese so genannten "Tunneler" (Matrikon, Softing, etc.) funktionieren alle etwa gleich, sie halten eine "lokale" OPC-Verbindung (zum Server bzw. zum Client) und über das Netzwerk kommunizieren sie irgendwie proprietär meist http. Das hat den Vorteil das sie nur einen offenen Port benötigen (z.B. Port 80) aber ansonsten hat es nur Nachteile denn die Kommunikation wird extrem langsam (Faktor 2 bis Faktor 25 langsamer) und besonders sicher ist sie auch nicht (quasi offen). Ich habe daher bisher keine Tunneler eingesetzt, es sei denn es ließ sich nicht vermeiden (z.B.  1 Server und 5 Clients sind in 6 unterschiedlichen Domains, die sich nur teilweise gegenseitig vertrauen), dann macht es schon aus Gründen des Konfigurations- und Administrations-aufwands Sinn einen Tunneler zu verwenden.

In deinem Fall sollte das noch manuell hinzukriegen sein. Und denke immer daran, nicht die OPC Technologie ist schlecht, du konfigurierst an Windows-Funktionen herum !


----------



## matziane (1 Februar 2011)

Guten Morgen,

habe eben nochmal drüber geschaut, User auf dem Client Rechner ist der gleiche wie auf dem Server Rechner (Username und Kennwort).
Kann trotzdem nicht verbinden.
Habe mir diese Beschreibung angeschaut, OPCEnum auf dem Client Rechner steht auf Verbinden und Identifizieren.

Muss ich eventl. noch irgendwo auf dem Client Rechner etwas einstellen?
Was muss ich wo auf dem Server Rechner eventl. einstellen?
In der OPCEnum? Im OPCServer.WinCC?
Wenn ja was sollte ich da einstellen, groß was einstellen müsste ich ja da theoretisch nicht, da ja der lokale Zugriff funktioniert, max. noch etwas an den Benutzerrechten.
Bzw. worauf sollte ich achten was zwingend in den Einstellungen drinnen sein sollte.

Nochmals vielen Dank für die Hilfe.


----------



## Dr. OPC (1 Februar 2011)

Gehe die Checkliste durch, dann sollte es klappen. (s. Link oben in meinem Posting)

Ich vermute das zwar alles richtig eingestellt ist aber jeder Zugriff von aussen auf den "Gast"-Account umgeleitet wird (eine Standardeinstellung von XP3). Diese Sicherheitsrichtlinie musst du öffnen (auf beiden Seiten). Das ist WICHTIG also unbeding prüfen !



> Habe mir diese Beschreibung angeschaut, OPCEnum auf dem Client Rechner steht auf Verbinden und Identifizieren.


den Enum auf dem Client-Rechner brauchst du nicht, der OPC Client muss den OPCEnum auf dem Server-Rechner nach den installierten OPCServern fragen.

Wer prinzipiell in den Start und Zugriffsberechtigungen enthalten sein soll, kann man nicht pauschal beabtworten. Der User der zugreifen soll jedenfalls, in einigen Fällen auch "Netzwerk" und "System" z.B. wenn der Prozess (Client oder Server) als NT-Dienst läuft. Wichtig sind auch die AccessControlLimits das ist sozusagen die erste "Schicht" da musst du durchkommen und erst dann wirken die Standardeinstellungen bzw. die spezifischen Einstellungen, die für den jeweiligen Prozess vorgenommen wurden.



> Im OPCServer.WinCC?


wenn der Server WinCC ist, gibt es eine gute Beschreibung der Einstellungen in der Hilfe. Es könnte sein das du den User noch in irgendeine WinCC-Usergruppe hinzufügen musst, da bin ich mir aber nicht sicher.


----------



## Ralle (1 Februar 2011)

Dr. OPC schrieb:


> Und denke immer daran, nicht die OPC Technologie ist schlecht, du konfigurierst an Windows-Funktionen herum !



Na ja, aber dann hätte die OPC-Foundation oder wer auch immer das war vielleicht nicht auf dieses Pferd mit 17 Beinen, die alle in eine andere Richtung rennen, setzen, sondern was eigenes, solides, vernünftig administrierbares entwickeln sollen, oder? Ich bekomm auch jedes Mal die Krise, wenn ein OPC-Server benötigt wird und bete jedes mal, daß die lokale Variante genügt!


----------



## Dr. OPC (1 Februar 2011)

> sondern was eigenes, solides, vernünftig administrierbares entwickeln sollen, oder?


Da kann ich dir nur voll zustimmen !!! Und genau das haben sie dann auch getan und OPC UA entwickelt, das setzt direkt auf TCP/IP auf und verwendet Technologien, die funktionieren (TCP und SSL) und die nicht von Microsoft sind. Das UA-Protokoll haben sie selber entwickelt, und siehe da es funktioniert auch, ist sicher und unabhängig von "Security-Updates" und "Betriebssystem-Versionen" und solchen Dingen. 

Gibt aber schon wieder Leute die diese neue funktionierende Technik UNBEDING mit .NET entwickeln wollen und WCF verwenden (weil alles so schön einfach ist und man sich um nichts kümmern muss) und dann stehen die Helden wieder da und kratzen sich am Kopf wenn es nicht geht und irgendwo in den Tiefen des Frameworks stecken bleibt, oder schwer zu konfigurieren ist. Naja, einigen ist halt nicht mehr zu helfen... 

Das Problem ist dass man diese DCOM Einstellungen halt selten macht und dann jedesmal wieder von Neuem anfängt. Ich mache das täglich (nur so zum Spass) und finde es schon nicht mehr so schlimm. Übung ist halt alles...


----------



## matziane (1 Februar 2011)

> Ich vermute das zwar alles richtig eingestellt ist aber jeder Zugriff von aussen auf den "Gast"-Account umgeleitet wird (eine Standardeinstellung von XP3). Diese Sicherheitsrichtlinie musst du öffnen (auf beiden Seiten). Das ist WICHTIG also unbeding prüfen !


 
Könntest mir das bitte etwas Laienhaft erklären, wo ich was genau einstelle.

Habe jetzt Clientseitig alles so eingestellt wie es in der Checkliste steht.
Nur ist laut dieser Checkliste eine Grundvoraussetzung, dass beide Rechner in der selben Workgroup sind, was sie ja in diesem Falle nicht sind.
Serverseitig ist meiner Meinung nach so gut  wie alles richtig eingestellt, da es sich um mehrere Serverrechner handelt, dort kann ich untereinander auf die verschiedenen Server schauen.
Nur eben von außen mit dem neuen Clientrechner nicht.

http://www.youtube.com/watch?v=d0aVOSKcgFw&feature=related

Hatte mir diese Guides noch zu gemüte geführt, brachte aber auch nichts, obwohl es da Workgroupübergreifend auch funktionieren soll.
Will aber auf einem der Server rechner nicht zu viel herumstellen, wegen Produktionsrechner, nicht das dann alles den Bach runter geht.

Bin wirklich schon drauf und dran, in den neuen Clientrechner eine zweite Netzwerkkarte zu basteln und den so in die andere Workgroup mit reinzubringen.


----------



## Dr. OPC (1 Februar 2011)

Es ist in der Checkliste der Punkt 4


> Start->Einstellungen->Systemsteuerung-
> >Verwaltung->Lokale
> Sicherheitsrichtlinie->Lokale Richtlinie->
> Sicherheitsoptionen hier: Netzwerkzufriff:
> ...


Aus Sicht von DCOM ist es nur ein Unterschied ob beide Rechner in einer Domäne sind oder in einer Workgroup. Ist der Rechner in einer Workgroup werden die UserCredentials nur "lokal" geprüft, entsprechend muss es den user auf beiden Maschinen geben (und er muss identisch sein).


----------

