Forum für OPC-UA-Programmierung mit C/C++

[Kandiszucker]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo,
ich muss mich in OPC-UA-Programmierung mit C++ einarbeiten und hab mir mal die Toolkits von Softing und UA-Expert runtergeladen und arbeite mich anhand der Beispiele ein. Klappt nicht schlecht, aber bei manchen Sachen habe ich noch Probleme, z.B.: mit komplexen Datentypen wie structs.
Bei structs braucht man ja eine DataType-Description. Wenn ich diese DataType-Description vom Server hole klappt das Lesen & Schreiben. "Bastle" ich mir die DataType-Description selbst zusammen, dann klappt zwar das Lesen, beim Schreiben kriege ich aber BadTypeMismatch und ich hab keine Ahnung, was ich falsch mache.
Kann mir jemand einen Tipp geben, wie ich prüfen kann, wo der Fehler liegt, oder MUSS man die DataType-Description IMMER vom Server holen?

Kann mir jemand ein Forum empfehlen, das sich mit der OPC-UA Programmierung (auch Grundlagen) beschäftigt? Suchen mit Tante Google lieferte mir bisher nichts brauchbares.....

 

[Kandiszucker]

Hallo,
kann es sein, dass man bei komplexen-Datentypen die DataType-Description vom Server holen MUSS, dass es also gar nicht geht, diese Description von Hand zu basteln?

Ich suche mir einen Wolf im INet, aber eine klare Beschreibung zur Vorgehensweise ist mir bisher nicht untergekommen.

Grüße!

 

[Dr. OPC]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo,

das hast du genau richtig erkannt. Der Server gibt den komplexen Typ vor, und der Client kann, wenn er ihn nicht kennt, vom Server eine Description holen, diese Description ist ein XML Fragment das den Typ beschreibt, aber es kann auch ein Attribut sein z.B. viele kleine embedded Geräte haben keine XML Parser und auch keinen Platz um XML-Dictionaries zu halten. Eine gute Client-Implementierung verkraftet beide Varianten, je nachdem was der Server anbietet.

Von Hand basteln kannst du jedenfalls getrost vergessen.

Wenn du dich als Client auf ganz bestimmte komplexe Strukturen "spezialisiert" hast, macht es Sinn diese auch vorab schon zu kennen. Dann ersparst du dir auch das (zeit)-aufwändige Lesen der Dictionaries und (generierst) kennst diesen Typ bereits auf der Clientseite. Einen Code-Generator (UaModeler) gibt es beispielsweise von UnifiedAutomation.

Noch besser ist es wenn der komplexe Typ selber wieder standardisiert ist (z.B. in einer Companion-Spezifikation). Dann liest du den Namespace und weißt dass der Server genau diese Typen enthält, und du bist darauf "spezialisiert" (kennst die alle schon), und kannst sofort loslegen.

 

[Kandiszucker]

Hallo Dr.OPC,

vielen Dank für die Erklärung (!!!) - bin fast "verzweifelt" beim Versuch mit der "händischen" Description.

Ich denke vom Thema OPC-UA einiges begriffen zu haben, allerdings habe ich noch grooooosse Wissenslücken. Bevor ich hier geschrieben habe, hab zu obigem Thema schon das INet abgegrast, aber keine (für mich) verständlichen Erklärungen gefunden. (Ich habe allerdings einige Erfahrung in Classic-OPC)

Könntest Du mir einen Tipp geben, wo man prinzipielle Vorgehensweisen, "Rezepte" also quasi ein "OPC-UA for Dummies" finden kann?

Es ist so, dass ich einen Client bauen muss (hab den Server noch nicht), bei dem gewisse Strukturen bekannt sind. Könnte man den angesprochenen UaModeler benutzen, um Descriptions zu erzeugen oder Client-Code?

Grüße

 

[Dr. OPC]

Hallo,

ja das Thema komplexe Strukturen ist nicht so ganz trivial (und bei classic DA gab es das überhaupt nicht). Wirklich gut beschrieben ist es nirgends, außer in der OPC UA Spezifikation, die liest sich aber nicht wirklich gut.

Vereinfacht gesagt ist es so:

Der UA Server gibt das Typsystem vor:
1) es gibt von der OPC Foundation vordefinierte Typen (der Baukasten, die Basis von allem)
2) es gibt von Companion Spezifikationen vordefinierte Typen (z.B Spritzgussmaschine)
3) ein Server kann seine eigenen Typen definieren (z.B. SPS mit UDTs)

Aus Sicht des UA Client sieht das so aus:
1) "well known" Types, muss man kennen, sind reinkompiliert
2) "companion" Types, sollte man kennen wenn man darauf spezialisiert ist, sind meist reinkompiliert
3.1) neue feste Strukturen, könnte man theoretisch kennen und reinkompilieren
3.2) neue unbekannte Strukturen, kann man vorher nicht kennen, muss man zur Laufzeit rausfinden wie die aufgebaut sind. Dafür gibt es 2 Möglichkeiten: a) XML TypeDictionary oder b) DictionaryAttribute wird vom Server bereitgestellt, kann der Client zur Laufzeit "auslesen" und enstprechend drauf reagieren.

Wenn du einen UA Client schreiben musst, dann ist die erste Frage ob du zur Kompilezeit schon weißt welche Typen der Server hat (ist der einfachere Fall und du kannst dich "spezialisieren" z.B. eine feste GUI für Spritzgussmaschinen anbieten), um den Code zu generieren könnte der UaModeler dir helfen. Oder ob du die Typen erst zur Laufzeit erfährst (ist der komplizierte Fall, du kannst es "aufbröseln" und z.B. in einer generischen GUI anzeigen), um das zu implementieren könnte dir ein SDK/Toolkit helfen dass Dictionaries auslesen kann.

Der UaModeler ist ein TypEditor und ein CodeGenerator für die Server- und für Clientseite. Er erzeugt für die serverseite Code und Dictionary und er erzeugt für die clientseite Code (Dictionaries gibt es dort ja nicht). Der UaModeler kann Typsysteme "laden" und dann Code dafür generieren, das spart viel Arbeit.

 

[Kandiszucker]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo Dr.OPC,

wiederum vielen Dank für Deine Erläuterungen - hast Du schon mal nachgedacht, Kurse zum Thema anzubieten? ))

Ich soll mit einer Werkzeugmaschine kommunizieren, Spritzgussmaschinen (euromap77) kann auch mal in Betracht kommen, ist aber noch Zukunft.

Ich habe eine XML-Datei, die wohl die kompletten Typ & Datendefinitionen enthält (das Model eben) - ich konnte bis *vor* Deinen Erläuterungen nichts damit anfangen, jetzt begreife ich schon mehr.....

Einfach ausgedrückt: man kann diese XML-Datei für das Server-Toolkit benutzen (zur Codegenerierung), aber auch im Client, um die Descriptions (bzw. den kompletten Adressraum) "anzusprechen" ?

Ich bin aktuell auch noch dabei ein Toolkit auszuwählen, die Wahl wird wohl zwischen UnifiedAutomation und Softing fallen.

UnifiedAutomation hat mit dem UaExpert die Nase vorn, für Softing spricht die Tatsache, dass ich die ClassicOPC-Sachen mit deren Toolkit gemacht habe. (Softing hat wohl bei den Beispielen auch den Sserver-seitigen Import der XML-Files drin, Client-seitig habe ich bei den Beispielen bisher nichts gefunden. Die Doku ist leider auch nicht sehr ergiebig).

Grüße!!

 

[Kandiszucker]

Hallo,

hab zwar einige "Erfolge" beim rum-experimentieren verbuchen können, aber ich habe einfach zu viele Wissenslücken bzgl. OPCUA. Hab mich darum dazu entschlossen, einen Kurs bei Softing zu machen - war damals mit ClassicOPC auch OK. Ich glaube, fundiertes Grundlagenwissen kann keinesfalls schaden

@Dr. OPC: würd mich trotz Kurs interessieren, wie man per XML-Datei die Server-structs zur Compile-Zeit definieren kann

Grüße & Danke!

 

[Softing_IA]

Hallo,

hab zwar einige "Erfolge" beim rum-experimentieren verbuchen können, aber ich habe einfach zu viele Wissenslücken bzgl. OPCUA. Hab mich darum dazu entschlossen, einen Kurs bei Softing zu machen - war damals mit ClassicOPC auch OK. Ich glaube, fundiertes Grundlagenwissen kann keinesfalls schaden

@Dr. OPC: würd mich trotz Kurs interessieren, wie man per XML-Datei die Server-structs zur Compile-Zeit definieren kann

Grüße & Danke!

Alternativ zu den Schulungen gibt es auch ein paar Video How-Tos auf Youtube, die z.B. eine beispielhafte Client-Entwicklung für OPC UA zeigen.

.Net: https://www.youtube.com/watch?v=QaiLE5aQzKA
C++: https://www.youtube.com/watch?v=hdVvlXNyyAY

Das Thema komplexe Strukturen kann man sicherlich auch in einer der Entwickler-Schulungen von Softing vermitteln. Am besten vorher mal Fragen, ob diese Themen behandelt werden.

Schöne Grüße

 

[Kandiszucker]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo und Danke,

das Video ist für den Einstieg sehr gut, Danke!

Hab die Tutorials mal "durchgearbeitet" und muss sagen, dass das Thema zwar nicht einfach ist, aber die Lib das Entwickeln ungemein erleichtert

Wenn man einen Client debuggt und an einem Breakpoint anhält, dann wird beim Weiterlaufen die Session, Subscription, Monitored Items auf disconnected gesetzt (also der Server denkt, der Client sei tot?).

Hab mit verschiedenen Timeouts "rumgespielt", hilft aber nichts (Session Timeout kann man setzen), die Subscriptions & MonitoredItems gehen aber trotzdem in Timeout.

Welche Parameter muss man denn setzen, damit man vernünftig debuggen kann?

Wäre für Tipps sehr dankbar!

 

[Softing_IA]

Hallo,

Neben dem Session Timeout gibt es auch einen Subscription Timeout, der für die Subscription und deren MonitoredItems gilt.

Dieser Timeout wird nicht direkt als Timeout gesetzt, sondern indirekt über den LifeTimeCount (Subscription::setLifeTimeCount()).
LifeTimeCount * PublishingInterval = SubscriptionTimeout

Viele Grüße
Softing_IA

 

[Kandiszucker]

Hallo,

das mit den Zeiten hat prächtig funktioniert

Vielleicht könnt ihr mir noch einen Tipp geben.

Also: ich versuche gerade einen UA FileTransferStateMachineType in den Griff zu kriegen indem ich ein MonitoredItem auf die Id der StateMachine setze. Leider kriege ich bei Änderungen nie einen Callback. Nun ist der value-Typ der Id eine NodeId. Geht das da mit MonitoredItems nicht? Muss ich die Id aktiv pollen?

Grüße!!
[h=2][/h]

 

[Swyss]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo Kandiszucker,

für die Kombination C++ und OPC UA kann ich Dir QT empfehlen. Wir setzen das bei einigen Projekten ein das läuft wirklich sehr gut und sehr performant.

Viele Grüsse

Swyss