OPCDotNetLib + Remote OPC Server

david.ka

Level-2
Beiträge
180
Reaktionspunkte
26
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo Leute,

irgendwie stehe ich momentan auf dem Schlauch, denn ich bekomme es nicht hin, mit der OPCDotNetLib auf einen Remote OPC Server zuzugreifen.
hat das jemand von euch schon mal realisiert?

danke schon mal im voraus,

Grüße.David.
 
Funktioniert es denn mit der OPCDotNetLib bei einem lokalen OPC-Server, und funktioniert es mit einem anderen Client bei dem remoten OPC-Server ?

Gruß Axel
 
Dann tippe ich auf ein Problem mit den DCOM-Rechten. Wenn die nicht im Programmcode eingestellt werden, dann wird die Standardeinstellung des Systems übernommen. Die DCOM-Einstellungen sind 'ne Wissenschaft für sich, ist nix für kurz vor dem Wochenende ... ;)


Gruß Axel
 
Zuviel Werbung?
-> Hier kostenlos registrieren
afk hat es doch schon gesagt ...

Hallo,

david.ka schrieb:
wenn aber andere clients darauf zugreifen können, sollte es doch kein problem mit dcom sein oder?!?

Nicht mit den DCOM-Settings des Rechners mit dem OPC-Server, sondern mit dem Rechner des Clients. afk hat Dir schon den richtigen Weg gezeigt, dazu kommen noch andere Kriterien wie Zugriffsrechte (User, Passwort, welches OS ?) etc.

afk schrieb:
Die DCOM-Einstellungen sind 'ne Wissenschaft für sich, ist nix für kurz vor dem Wochenende ...
Und schon gar nicht zum Karneval :icon_wink:

Gruß

Question_mark
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Dcom

Hallo,

david.ka schrieb:
aber das höre ich das erste mal, das die dcom settings am client auch eingestellt werden müssen.

Gehe auf die Siemens Service&Support Homepage und suche nach Beitrags-ID 13542666. Lade das Handbuch herunter und im Kapitel 18 steht das alles beschrieben.
Ich glaube, da es sich um generelle DCOM-Einstellungen handelt, sollte das auch für die OPCDotNetLib zutreffen.

Gruß

Question_mark
 
genau das war ja auch meine Frage :)

muss ich das in der Connect() Methode übergeben?
z.b. Srv.Connect(@"\\Rechner\Matrikon.OPC.Simulation.1");
Dann hättest Du das besser gleich fragen sollen ... :p

Google hilft:
Code:
Svr.Connect(ProgID, PCName);

danke. aber das höre ich das erste mal, das die dcom settings am client auch eingestellt werden müssen.
Der OPC-Server baut zum OPC-Client auch eine DCOM-Verbindung auf, um dem Client die Events übermitteln zu können. Dafür müssen die Zugriffsrechte beim Client korrekt eingestellt sein. Das passiert entweder über die globalen Einstellungen in der Komponentenkonfiguration der Systemsteuerung, oder im Programmcode auf der Prozessebene. Ein vernünftig implementierter Client sollte die 2. Variante anwenden.

Wenn Client und Server auf dem gleichen System laufen, gibt's normalerweise keine Probleme damit, daß die systemweiten Standardeinstellungen verwendete werden, da ja beide Prozesse in jedem Fall unter Benutzern laufen, die lokal bekannt sind, und in den allermeisten Fällen auch die notwendigen Rechte besitzen.

Das sieht ganz anders aus, wenn Server und Client auf verschiedenen Systemen laufen. Da kümmert man sich am besten von Anfang an darum, unter welchem Benutzer die Prozesse laufen, und welche Rechte sie haben.


Gruß Axel
 
Srv.Connect(ProgID,PCName) kennt OPCDotNetLib nicht.
Komisch, zu OPCDotNetLib findet man bei Google zwar nicht wirklich viel, aber in diesem PDF steht im Beispielcode auf Seite 28/29 der von mir zitierte Aufruf drin.
Muß aber nichts bedeuten, da ich des Belgischen (oder was auch immer das ist) nicht mächtig bin ... :rolleyes:


Gruß Axel
 
---

Hallo,

afk hat es dir vorgelegt. Hast Du auch das Objekt Srv vorher auch erzeugt ?
In dem Beispielprogramm von afk wird die ProgID als String und die IP-Adresse des Servers als String an die Funktion Srv.Connect() übergeben. Meiner Meinung nach sollte das aber auch mit dem Rechnernamen funktionieren.
Einfach mal versuchen.

Mich wundert nur, dass beim Connect die ProgID übergeben wird. Mir ist bisher nur die Übergabe als ClassID bekannt. Normalerweise lasse ich mir vor dem Connect durch die Funktion 'ProgIDToClassID' aus dem Servernamen die passende GUID aus der Registry zurückgeben.
Aber das mag bei der OPCDotNetLib vielleicht anders sein, dazu fehlt mir einfach die passende Beschreibung.

Gruß

Question_mark
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Folgende Sache ändern:
Klasse OPCdotNETLib.OPC_Data_Srv
Code:
public void Connect(string progidOPCServer, string computerName)
{
    Disconnect();

    Type typeofOPCserver = Type.GetTypeFromProgID(progidOPCServer,computerName);

    if( typeofOPCserver == null )
        Marshal.ThrowExceptionForHR( HRESULTS.OPC_E_NOTFOUND );

    OPCserverObj = Activator.CreateInstance( typeofOPCserver );
    ifServer = (IOPCServer) OPCserverObj;
    if( ifServer == null )
        Marshal.ThrowExceptionForHR( HRESULTS.CONNECT_E_NOCONNECTION );

    // connect all interfaces
    ifCommon = (IOPCCommon)    OPCserverObj;
    ifBrowse= (IOPCBrowseServerAddressSpace)ifServer;
    ifItmProps= (IOPCItemProperties)ifServer;
    cpointcontainer    = (UCOMIConnectionPointContainer)OPCserverObj;
    AdviseIOPCShutdown();
}
 
Folgende Sache ändern: ...
Reine Neugier:
Kann die Lib das gar nicht, und der Code ist ein Patch (von Dir ?), um ihr das beizubringen, oder kann die das erst ab einer bestimmten Version ?

Mich wundert nur, dass beim Connect die ProgID übergeben wird. Mir ist bisher nur die Übergabe als ClassID bekannt. Normalerweise lasse ich mir vor dem Connect durch die Funktion 'ProgIDToClassID' aus dem Servernamen die passende GUID aus der Registry zurückgeben.
Das wird wohl in der Lib gekapselt sein, mache ich in meinem OPC-Client (Delphi-Komponente) auch so. :cool:


Gruß Axel
 
Diese "Lib" kann sowas garnicht, auch gibt es keine Versionen, keinen Support und keinen kommerziellen Vertrieb. Sie ist eigentlich nur ein Beispiel um die .NET DCOM "Kommunikation" zu demonstrieren.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Dann wundert's mich umso mehr, daß sich in Belgien jemand die Mühe macht, so eine ausführliche Beschreibung mit Beispielen dafür zu schreiben, in der dann ausgerechnet der Funktionsaufruf so passend "falsch" ist ... :rolleyes:

Der Patch ist demnach von Dir ?


Gruß Axel
 
Zurück
Oben