OPC XML-DA und Visual Basic

magmaa

Level-1
Beiträge
349
Reaktionspunkte
27
Zuviel Werbung?
-> Hier kostenlos registrieren
So nachdem das mit Excel und OPC DCom gut geklappt habe ein weiteres Beispiel von Siemens (Visual Basic .NET und OPC XML-DA) ausprobiert.

Nur leider nicht mit Erfolg wie man auf dem Bild erkennen kann.
Kann mir jemand da weiter helfen vllt. der OPC Dr.?
 

Anhänge

  • opc.JPG
    opc.JPG
    120,1 KB · Aufrufe: 103
Zuletzt bearbeitet:
Les doch einfach die Fehlermeldung ...

Hallo,

magmaa schrieb:
Nur leider mit Erfolg

Da muss ich jetzt ganz gemein grinsen :ROFLMAO:

Aber Spass beiseite, lese doch einfach die Fehlermeldung nochmal durch :

"Der Name des Items entspricht nicht der Syntax des OPC-Servers" !!!

Das heisst, Du hast irgendwo Item Namen benutzt, die der OPC-Server nicht auflösen kann. ZB. falscher oder fehlender Verbindungsname, unzulässiger Datenbereich, unzulässiger oder fehlender Datentyp, da gibt es unzählige Möglichkeiten ...
Und nein, ich werde mir das Siemens-Beispiel nicht ansehen, finde es selber heraus.

Gruß

Question_mark
 
So mit dem OPC scout bekomme ich eine Verbindung hin (auch über das Netzwerk) also läuft der Server.
Mal sehen ob ich dann noch das VB Programm zum laufen bekomme.
 
Die Itemnamen sind in Listen definiert (das steht zumindest in der Beschreibung des Beispiels). Die dort definierten Items gibt es anscheinend nicht in deinem Server. Vermutlich LC ohne Symbolik geladen? Zu dem Beispiel gehört ein Step7-Projekt für die WinAC und den OPC Server.

1 Zum Lesen und Schreiben von Variablen mit OPC XML-DA werden sog. Itemlisten benutzt. Je nachdem, welche Funktion ausgeführt wird, werden verschiedene Itemlisten verwendet, z.B. WriteRequestItemList, ReadRequestItemList, SubscribeRequestItemList usw. Diese Itemlisten enthalten Items, die die einzelnen Variablen spezifizieren. In den Items
werden verschiedene Eigenschaften, wie Variablenname, Wert, Zeitstempel, Qualität, ...gespeichert. Eine Itemliste kann ein oder mehrere Items enthalten.
2 Anzahl der Items in der Itemliste festlegen (0 basiert, also 2 Items).
3 Zuweisung symbolischer Variablennamen. Dabei handelt es sich um den Namen des OPC-Items im OPC-Server.
 
Die WinLC ist die Steuerung mit der der OPC Server sich verbinden soll. Dann muss es eine S7-Verbindungsprojektierung in Netpro geben (vom OPC Server zur WinLC) und dann gibt es auch Symbole. Die Symbolinformation für den OPC Server kann nur dann erzeugt werden wenn die Projektierung weiß von welcher Steuerung (hier die LC) die Daten geholt werden sollen.

Entscheidend ist nun das BEIDES runtergeladen wird. Das Programm in die WinLC und die Projektierung und Symbolik in den OPC Server. Das muss zusammen passen.

Der OPC Client fragt ein OPC-Item an (hier einen symbolischen Namen aus der Itemliste). Der Server versucht nun dieses Symbol in eine direkte Adresse auf dem Zielgerät aufzulösen. Dies scheint bei Dir nicht zu klappen "Invalid Item Syntax" bedeutet dass der Server den symbolischen Namen den der Client anfordert nicht auflösen kann. Also entweder wurde die Symbolik nicht in der Server geladen oder sie passt nicht zu dem was in der WinLC geladen ist.
 
Zuletzt bearbeitet:
Verbindung mit OPC Server in NetPro ist gemacht Bild 1
und der OPC Server läuft denn ich kann mit dem OPC Scout eine Verbindung herstellen und Variablen lesen und schreiben Bild 2.

Die wie kann die Symbolik in der Server laden geschieht das nicht automatisch bei laden in Zielsystem?
 

Anhänge

  • OPC2.JPG
    OPC2.JPG
    107,1 KB · Aufrufe: 41
  • OPC3.JPG
    OPC3.JPG
    159,7 KB · Aufrufe: 43
Zuviel Werbung?
-> Hier kostenlos registrieren
Das stimmt, die Symbolik wird automatisch mit erzeugt (wenn der passende Haken an ist) und auch beim Download der PC-Station automatisch in den OPC Server geladen.

Den Haken findest du in den "Eigenschaften OPC Server", dazu in NetPro auf den OPCServer in der PC-Station doppelclicken und im Register "S7" die Symbolik anschalten. Danach nochmal "speichern übersetzen" und OPC Server laden. Den Einstieg in die Symbolik findest du über den Knoten "SYM:" beim Browsen des OPC Servers.

Dann solltest Du in den Itemlisten des Beispiels überprüfen ob deine Symbole auch genau so heißen wie die im Beispiel. Denn der Name der S7-Verbindung ist Bestandteil des Symbolnamens genauso wie der Name der WinLC. Also entweder nennst du deine Verbindung und WinLC "exakt genauso" wie im Beispiel, oder aber du änderst die ItemNamen im Codes des Client.
 
Also ich habe mal in der schnelle drüber geschaut und kann keinen unterschied in den Bezeichnung finden sowohl im Client-Code als im Projekt selbst.

z.B: "PCWinAC.WinLC RTX.Data_Act_Val.Act_Mixer"

Das dumme ist nur das ich den Client nicht richtig Debuggen kann das würde es vielleicht einfacher machen um zusehen wo er hängen bleibt.
Gibt es vielleicht noch andere einfache Beispiel für einen einfachen VB client?
 
naja, da hast du auch mit einem schwierigen Beispiel angefangen.

1) prüfe mal ob der XML-DA Server überhaupt geht, gib mal die URL in einen Browser ein "http://localhost/OPC.Simatic.NET/sopcweb.asmx" da sollte dann eine Webseite erscheinen auf der "SimaticNET OPC Server" steht. Falls nicht ist etwas falsch installiert, der IIS muss installiert sein bevor die SimaticNET CD installiert wird.

2) wenn die Webseite da ist, kann es nur noch an den "Itemnamen" liegen. Das Teil heißt "PCWinAC.WinLC RTX.Data_Act_Val.Act_Mixer" das bedeutet "<NameVerbindung>.<NameCPU>.<NameDB>.<NameWert>" In deinem Screeshot sehe ich dass bei dir die S7Verbindung aber ganz anders heißt und dafür ist der Name der CPU so wie die Verbindung heißen sollte. "WinLC_OPC_Conn.PCWinAC.Data_Act_Val.Act_Mixer"

3) ich habe gesehen dass du den ScoutV10 verwendest und dich über OPC UA (nicht XML-DA) mit dem Server verbindest, daher bin ich nicht sicher ob XML-DA überhaupt korrekt installiert ist. Das Beispiel ist für XML-DA (für die Symbole macht das zwar keinen Unterschied, ich wollte es aber dennoch mal erwähnt haben)

Es gibt viele weitere Beispiele im Installationsverzeichnis \programfiles\siemens\simatic.net\... für .NET, C++, und VB6 (gab es auf den älteren CDs).
 
Zuviel Werbung?
-> Hier kostenlos registrieren
1) prüfe mal ob der XML-DA Server überhaupt geht, gib mal die URL in einen Browser ein "http://localhost/OPC.Simatic.NET/sopcweb.asmx" da sollte dann eine Webseite erscheinen auf der "SimaticNET OPC Server" steht. Falls nicht ist etwas falsch installiert, der IIS muss installiert sein bevor die SimaticNET CD installiert wird.
Also die Seite geht Bild 1.

2) wenn die Webseite da ist, kann es nur noch an den "Itemnamen" liegen. Das Teil heißt "PCWinAC.WinLC RTX.Data_Act_Val.Act_Mixer" das bedeutet "<NameVerbindung>.<NameCPU>.<NameDB>.<NameWert>" In deinem Screeshot sehe ich dass bei dir die S7Verbindung aber ganz anders heißt und dafür ist der Name der CPU so wie die Verbindung heißen sollte. "WinLC_OPC_Conn.PCWinAC.Data_Act_Val.Act_Mixer"
Das "PCWinAC.WinLC RTX.Data_Act_Val.Act_Mixer" habe ich aus dem Client-Code (Bild 3) und bei SYM: im OPC Scout steht das auch (Bild 2).
Wenn Itemname <NameVerbindung>.<NameCPU>.<NameDB>.<NameWert>" sein muss, müsste ich das ja nur in Netpro ändern obwohl mich etwas verwirrt.

3) ich habe gesehen dass du den ScoutV10 verwendest und dich über OPC UA (nicht XML-DA) mit dem Server verbindest, daher bin ich nicht sicher ob XML-DA überhaupt korrekt installiert ist. Das Beispiel ist für XML-DA (für die Symbole macht das zwar keinen Unterschied, ich wollte es aber dennoch mal erwähnt haben)
Ja ich weiß XML-DA wird im Scout nicht angeboten hab es daher prinzipel mit DA mal ausprobiert.
 

Anhänge

  • OPC4.JPG
    OPC4.JPG
    76,2 KB · Aufrufe: 29
  • OPC5.JPG
    OPC5.JPG
    146,2 KB · Aufrufe: 29
  • OPC6.JPG
    OPC6.JPG
    180 KB · Aufrufe: 24
Hab gerade gelesen das bei der

absolute Adressierung: \S7\[Name der S7-Verbindung] ...

und

symbolische Adressierung: \SYM\[Name der Station]\[Name der CPU]...

Dann würde ja "WinLC_OPC_Conn.PCWinAC.Data_Act_Val.Act_Mixer" passen?
 
ja, genau. Welche Seite du änderst ist egal, es muss halt am Schluß zusammenpassen.

Wenn Du den Verbindungsnamen zur WinLC und den Stationsnamen der WinLC nicht ändern möchtest, kannst du auch den String im Beispielcode ändern. Das Step7 Projekt, das zu dem Beispiel gehört, sollte das eigentlich alles korrekt enthalten. Ich würde daher die originale XDB in die PC-Station importieren.

Du solltest darauf achten, dass wenn du etwas änderst, du auch immer "speichern übersetzen" machst und die "PC-Station" neu runter lädst, denn dabei wird die Symbolik neu erzeugt und in den Server geladen.

Die Überprüfung mit dem ScoutV10 ist sicher richtig um mal zu sehen wie es im Server aussieht. Hier solltest Du allerdings den OPC DA Server "OPC.SimaticNET" wählen (und nicht OPC.SimaticNET.S7 denn das ist der OPC UA Server). Nur der "klassische" OPC Server sieht "innen" so aus wie der XML-DA. So wie dort die Symbole heißen so heißen sie auch im XML-DA.
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
So hab jetzt einen "OPC XML - DA Test Client" ähnlich wie der OPC Scout von Siemens ausprobiert.

Als Server Status sag der mir:

Code:
Vendor :         SIMATIC NET OPC XML-Webservice DataAccess-V1.0 (C) SIEMENS AG 2002-2008
Product Version :    307.100.114.1
Status Info :    The web service is functioning normally
Interface Version :    XML_DA_Version_1_0
Locale Ids     :    en,  de
Server started at :    19:47:55.921

Server State :    running
Receive Time :    20:0:30.749
Reply Time :    20:0:30.765
Revised Locale Id:    en
hört sich ganz gut an

Bei Bei Symbolischer Adressierung bleibt die Meldung:

Code:
The item name does not conform to the server's syntax.
und bei S7 erhalte ich folgende Meldung:

Code:
System.Web.Services.Protocols.SoapException: An internal server is not running ---> System.Runtime.InteropServices.COMException (0xC00481FF): Ausnahme von HRESULT: 0xC00481FF
   bei MELBOURNE_Lib.INSInfo2.ChangePosition(String ElementName, Object ID, tagNS2_MoveDirection Direction)
   bei Siemens.Runtime.INSXMLWrapper.INSInfo2XML.BrowseFromNSInfo2(String ItemPath, String ItemName, String ItemNameFilter, Int32 MaxElementsReturned, browseFilter Browsefilter, List`1& entryList)
   bei Siemens.XMLDAWebService.OPCXML_DataAccess.Browse(XmlQualifiedName[] PropertyNames, String LocaleID, String ClientRequestHandle, String ItemPath, String ItemName, String& ContinuationPoint, Int32 MaxElementsReturned, browseFilter BrowseFilter, String ElementNameFilter, String VendorFilter, Boolean ReturnAllProperties, Boolean ReturnPropertyValues, Boolean ReturnErrorText, BrowseElement[]& Elements, OPCError[]& Errors, Boolean& MoreElements)
   --- Ende der internen Ausnahmestapelüberwachung ---
   bei Siemens.XMLDAWebService.OPCXML_DataAccess.Browse(XmlQualifiedName[] PropertyNames, String LocaleID, String ClientRequestHandle, String ItemPath, String ItemName, String& ContinuationPoint, Int32 MaxElementsReturned, browseFilter BrowseFilter, String ElementNameFilter, String VendorFilter, Boolean ReturnAllProperties, Boolean ReturnPropertyValues, Boolean ReturnErrorText, BrowseElement[]& Elements, OPCError[]& Errors, Boolean& MoreElements)
Da scheint irgendetwas nicht zu laufen!?!
 
Ja, das sieht natürlich nicht mehr so gut aus. Die SoapException zeigt das es bei der Auflösung des Namens ein "unerwartetes" Problem gab.

Ohne das jetzt selber live zu sehen und weiter einkreisen zu können, gehen mir langsam die Vorschläge aus. Aber einen habe ich noch:

Es sieht für mich so aus als ob die Komponente, die die Namensauflösung macht, nicht gestartet werden kann. Dies kann ein "Rechteproblem" sein. Der XML-DA Webserver läuft im SecurityContext des ASP Users und dieser hat üblicherweise nur sehr wenige Rechte. Eventuell hat dieser nicht ausreichende DCOM Rechte, um auf die Komponente zuzugreifen. Dies sollte allerdings eigentlich durch das Setup und den Security-Button in "PC Station einstellen" korrekt gesetzt werden "remote freischalten". Aber eine Kontrolle in dcomcnfg schadet nicht. Du solltest den ASPUser in die SimaticNET User-Gruppe aufnehmen, das sollte reichen. Der ASP User sollte auch Zugriffsrechte auf die STI Dateien erhalten falls du diese verwendest.

Ansonsten gibt es noch den Trace des Server "Data" und den Trace des NameServers "TagInfo" beide über "PC Station einstellen" einschaltbar. Hier solltest du in der Hochlaufphase des Servers schauen ob die Komponenten auch alle gestatet werden konnten. Weiterhin solltest du nach der IVarOPC.err Datei suchen, diese enthält "schwerwiegende" Fehler und wird immer von Server erzeugt. Hier könnte auch ein Hinweis enthalten sein, falls die Komponente "grundsätzlich" nicht geladen werden kann. Das scheint ja aber bei dir zu funktionieren, denn über den Scout siehst du ja alle Symbole. Daher tippe ich eher auf das Rechteproblem.

Der FehlerCode 0xC00481FF bedeutet E_ServerDown also ist der NameServer nicht gestartet worden. Es fragt sich also nur noch warum. Der OPC Server fragt den NameServer um den Namen des Symbols aufzulösen, das klapp nicht und daher sieht es auf OPC Client Seite so aus als ob "Invalid_Syntax" das Symbol falsch geschrieben wurde.
 
Der OPC Dr. ist der beste.

Ein Klick in "PC- Station einstellen" und es geht.

Besten Dank für die vielen mühen.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Eine Sache ist mir noch aufgefallen lesen der Variablen ist kein Problem aber bei schreiben bekomme ich immer folgende Fehlermeldung:

"E_BADTYPE The server cannot convert the value to the requested type."

was kann das wider sein?
 
In OPC kennt man 2 Datentypen für eine Variable
1) den Canonical Data Type
2) den Requested Data Type

Der kanonische Datentyp ist der "Urdatentyp" den eine Variable besitzt. Eine Lichtschranke hätte beispielsweise den kanonischen Datentyp "Boolean", das liegt in der "Natur" einer Lichtschranke. Ein "S7:[Verb1]DB1,W4,1" ist ein Word (VT_UI2) im Datenbaustein 1 ab der Byteoffsettadresse 4, dessen cannonical DT ist "VT_UI2". Wenn auf diese Adresse ein Symbol gelegt wird z.B. "MeineTemperaturImKessel2" dann hat auch das Symbol den cannonical Datatype VT_UI2 (16 Bit unsigned integer)

Ein OPC Client kann nun beim Hinzufügen der Variable zu einer Gruppe (AddItems) angeben dass der Server diese Variable bitte in einem anderen Datentyp liefern soll. Der Requested Data Type könnte also beispielsweise als String (VT_Bstr) angefordert werden. Nun wird der Server jedes mal wenn er die Variable an den Client sendet dessen Wert konvertieren und als String liefern. Umgekehrt muss der Client beim Schreiben den Wert als String angeben. Viele Clients, die Daten in der Oberfläche in z.B. "TextBox" anzeigen, machen das so, denn dann kann der Wert direkt zugewiesen werden. Das funktioniert rückwärts (beim Schreiben) aber nur dann wenn der String auch in einen VT_UI2 konvertierbar ist. Wenn du also den Wert "klaus" auf die Variable schreibst dann würde es nicht konvertierbar sein. Auch "-12" würden nicht klappen oder "65536".

Ein spezifikationskonformer OPC Server muss alle Konvertierungen entsprechend der Windowsfunktion "VariantChangeType" beherrschen. Wird bei AddItems der Requested Data Type mit VT_Empty (0) angegeben, dann liefert der Server die Variable in ihrem Cannonical Data Type, das ist bei den vielen Clients auch der Default.

Also prüfe zunächst wie die Variable bei AddItems angefordert wird, anschließend prüfe wie die Variable vom Client tatsächlich geschrieben wird. Bei "fertigen" Clients dessen Code man nicht hat, ist das nätürlich schwer. Da bleibt dann nur noch der Trace "Data" des Servers, um zu sehen was wirklich passiert.
 
Zurück
Oben