# OPCDotNetLib + Remote OPC Server



## david.ka (1 Februar 2008)

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.


----------



## afk (1 Februar 2008)

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


----------



## david.ka (1 Februar 2008)

Hallo,
ja, lokal funktioniert es. über einen anderen Client funktioniert die remote verbindung auch.


----------



## afk (1 Februar 2008)

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


----------



## david.ka (1 Februar 2008)

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


----------



## Question_mark (1 Februar 2008)

*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


----------



## david.ka (2 Februar 2008)

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


----------



## seeba (2 Februar 2008)

Kann die OPCDotNetLib, dass denn überhaupt?  Kannst du den Code mal kopieren?


----------



## Question_mark (2 Februar 2008)

*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


----------



## david.ka (3 Februar 2008)

seeba schrieb:


> Kann die OPCDotNetLib, dass denn überhaupt?  Kannst du den Code mal kopieren?



genau das war ja auch meine Frage 

muss ich das in der Connect() Methode übergeben?
z.b. Srv.Connect(@"\\Rechner\Matrikon.OPC.Simulation.1");

ohne "\\Rechner\", also lokal, funktioniert es problemlos.


----------



## afk (3 Februar 2008)

david.ka schrieb:


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

Google hilft:

```
Svr.Connect(ProgID, PCName);
```



david.ka schrieb:


> 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


----------



## david.ka (3 Februar 2008)

oki, danke, werde mal die dcom einstellungen vornehmen.

Srv.Connect(ProgID,PCName) kennt OPCDotNetLib nicht.


----------



## afk (3 Februar 2008)

david.ka schrieb:


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


Gruß Axel


----------



## Question_mark (3 Februar 2008)

*---*

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


----------



## seeba (3 Februar 2008)

Folgende Sache ändern:
*Klasse OPCdotNETLib.OPC_Data_Srv*

```
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();
}
```


----------



## afk (4 Februar 2008)

seeba schrieb:


> 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 ?



Question_mark schrieb:


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


Gruß Axel


----------



## seeba (4 Februar 2008)

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.


----------



## afk (4 Februar 2008)

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

Der Patch ist demnach von Dir ?


Gruß Axel


----------



## seeba (4 Februar 2008)

Kannst du mir einen Link geben?


----------



## afk (4 Februar 2008)

seeba schrieb:


> Kannst du mir einen Link geben?


Zu der belgischen Beschreibung ? 
Auf Seite 28/29 findest Du den Beispielcode ...


Gruß Axel


----------



## seeba (4 Februar 2008)

Ich denke mal, da handelt es sich um eine Bachelor Thesis bzw. Diplomarbeit.

David, wo setzt du die OPCDotNetLib ein, ist das ganze auch wirklich stabil? Ich hab da so meine Bedenken. Wäre über ein Feedback sehr dankbar.


----------



## afk (4 Februar 2008)

seeba schrieb:


> Ich denke mal, da handelt es sich um eine Bachelor Thesis bzw. Diplomarbeit.


Ja und ?
Soll mir das jetzt sagen, daß Diplomarbeiten unzuverlässige Quellen sind, oder,  daß der Author der Diplomarbeit seiner Zeit weit voraus ist ...  


Gruß Axel


----------



## seeba (4 Februar 2008)

afk schrieb:


> Ja und ?
> Soll mir das jetzt sagen, daß Diplomarbeiten unzuverlässige Quellen sind, oder,  daß der Author der Diplomarbeit seiner Zeit weit voraus ist ...
> 
> 
> Gruß Axel


Nene, OPCDotNetLib ist ja *nicht *aus einer Diplomarbeit heraus enstanden. Aber dieses "Beispiel", wofür du mir den Link geschickt hast.


----------



## afk (4 Februar 2008)

seeba schrieb:


> Nene, OPCDotNetLib ist ja *nicht *aus einer Diplomarbeit heraus enstanden. Aber dieses "Beispiel", wofür du mir den Link geschickt hast.


Das PDF meine ich ja auch. Du hast geschrieben, daß OPCDotNetLib mit remoten OPC-Servern normalerweise (d.h. ohne den Patch) nicht kann, aber in der vermeintlichen Diplomarbeit steht es so drin, als ob das ohne weiteres geht. Also steht in dem PDF entweder Blödsinn, oder der Author ist einfach seiner Zeit voraus, und Dein Patch wird in eine zukünftige Version der Bibliothek übernommen ...  

Aber das ist eher eine philosophische Diskussion, und hat mit dem ursprünglichen Thema nix zu tun ...  

Apropos, @david.ka: Funktioniert es jetzt ?


Gruß Axel


----------



## Question_mark (4 Februar 2008)

*Wat iss denn OPCDotNetLib ?*

Hallo,

wobei mich jetzt mal wirklich interessiert, was die besagte "OPCDotNetLib" nun wirklich ist und woher die stammt. Zumal die Infos per Google recht mager sind...
@seeba : klär uns doch mal bitte auf ...

Gruß

Question_mark


----------



## seeba (5 Februar 2008)

Das Kind stammt von einer schweizer Firma: http://www.viscomvisual.com/index.php .

Fragt mich aber nicht, wieso die das irgendwann einmal ins Internet gestellt haben.


----------

