OPC Server debuggen

[joacim]

Ein OPC Server soll erweitert werden. Ich habe die Quellen übernommen, der ursprüngliche Programmierer steht leider nicht mehr zur Verfügung. Die Situation ist wie folgt:

- der Quelltext liegt vor und lässt sich fehlerfrei kompilieren
- die ursprüngliche Entwicklung erfolgte in Delphi 6,
wird auch bei mir verwendet.
- der Server verwendet das XPress OPC Server Toolkit der
Firma Softing GmbH, Deutschland
- ein Testclient liegt vor (kein Quelltext)
- der Testclient kann sich mit dem Server verbinden und dort Daten anfordern

Nach meinem (rudimentären) Verständnis eines OPC Servers fordert ein Client via TCP
beim Server Daten an. In der Quelle finde ich die Verwendung von Sockets in einem Thread.
Keiner der von mir gesetzten Breakpoints an mir relevant erscheinenden Stellen (open, close usw.) im Thread triggert, wenn sich der Testclient mit dem Server verbindet bzw. dort Daten anfordert. Dass es sich um den „richtigen“ Server handelt, kann ich sehen, da das connect des Clients fehlschlägt, wenn ich den Server nicht per Delphi (F9) starte.

Gibt es Tipps zum debuggen, warum triggern meine Breakpoints nicht?

[TiGü]

Triggern denn andere Breakpoints?
Erste Zeile in der DPR oder in den jeweiligen Konstruktoren und Destruktoren?

[joacim]

ja, andere Breakpoints triggern, z.B. in einem Timer,
auch ganz am Anfang der DLL des Servers kann ich Breakpoints
verwenden. Ich würde gerne mal sehen wie die Verbindung
zum Client läuft. Die ganze Sache ist etwas unübersichtlich,
da der eigentliche Client (Visualisierung) noch ein Script
verwendet. Da der Visualisierungs-Client abgekündigt ist,
muss dieses Script - dann im Server - ersetzt werden.

[himitsu]

Der die Haltepunkte sind aber auch aktiv? (die blauen Punkte in den Zeilen und der Haltepunkt im Betrieb nicht ausgegraut ....)

Hat D6 vielleicht ein Problem mit Multithreaddebugging?


Statt eines "normalen" Haltepunktes, kann man es auch "direkt" machen,
also DebugBreak; oder asm int 3 end; in den Code schreiben, an den gewünschten Stellen.

Ansonsten kannst auch in eine Logfile schreiben, an jenen Stelle, falls der Debugger einfach nicht will.
(einen schönen Zeinzeiler wie TFile.AppendAllText('C:\xyz\log.txt', 'jo, war hier'#10); oder TFile.AppendAllText('C:\xyz\log.txt', Now.ToString + ' jo, war hier'#10); mußt dir im alten Delphi wohl selbstbasteln, falls keine andere Loggingfunktion vorhanden ist)

[joacim]

Danke für die Hinweise.
In eine Log-Datei zu schreiben habe ich schon probiert.
Da tauchen als Einträge nur die sekündlichen Timer-Events auf.

bei
TCPServer.OnAccept:=EventServerConnect;
z.B. kommt nichts, auch nicht, wenn ich erfogreich eine Verbindung vom Testclient
aus aufbaue.

Wobei
TTCPServer = class(TCustomWSocket)
ist.

[joacim]

Ich bin einen Schritt weiter. Das ganze ist ein Missverständnis. In einem Gespräch konnte ich herausbekommen, dass der Zugriff des Clients nicht über TCP/IP läuft. Ich hatte mich durch das Vorhandensein von Sockets darauf versteift, dass der Client über TCPIP mit dem Server kommuniziert. In Wirklichkeit läuft das aber über dCOM! Der Socket Teil ist für den Datenempfang von von Messstationen gedacht. Da es solche auf meinem PC nicht gibt, passiert natürlich auch nichts. Jetzt brüte ich über dCOM.

[TurboMagic]

Hallo,

dann benutzt ihr OPC/DA und nicht OPC/UA.
Der von dir erwähnte Socket scheint übrigens in ICS programmiert worden zu sein.

Falls mal die Zeit vorhanden ist kann ruhig auch an eine Portierung in ein
neueres Delphi gedacht werden, da es dort dann ja viele neue komfortable
Sachen gibt...

Es muss halt von allen Bibliotheken eine kompatible Version vorhanden sein
oder ggf. der Quellcode.

Grüße
TurboMagic

[Neumann]

Habe das vor vielen Jahren mal gemacht; war auch mit so einer alten Delphi-Version, logisch. War nicht schön, viele Merkwürdigkeiten und kaum stabil zu bekommen. Die DCOM Sache ist gegen REST oder meinetwegen auch Soap ziemlich unkomfortabel.

Geht OPC nicht inzwischen auch mit REST? Meine sowas mal gelesen zu haben.

[Der schöne Günther]

OPC hat seit vielen Jahren eigentlich den Nachfolger OPC UA. Das hat nichts mehr mit DCOM (plattformunabhängig) zu tun und läuft entweder über ein TCP-Binärprotokoll oder über HTTP (Soap).

Bei uns war es ähnlich, ein Kunde wollte nach vielen, vielen Jahren nochmal was an einer alten OPC-Schnittstelle gebastelt haben. Wir haben irgendwann aufgegeben und ihm gesagt er soll bitte OPC UA benutzen 😁

[TurboMagic]

Umstellung auf OPC/UA hilft aber auch nur, wenn man die andere Seite auch umstellen kann...
Und falls OPC Server und Client auf dem selben PC laufen sollte es mit DCOM auch keine
Konfigurationsprobleme geben...