dll in WinCC einbinden

Spiff

Level-1
Beiträge
22
Reaktionspunkte
0
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo Experten,

weiß jemand, wie man .dll-Dateien in WinCC flexible 2005 Advanced einbinden kann?

Der Hintergrund ist Sherlock, eine Software zur Bildverarbeitung, deren Funktionen in einer WinCC-Anwendung verfügbar sein sollen.
Das hat in Visual Basic bereits funktioniert, indem die entsprechende .dll bekannt gemacht wurde. Die Sherlock-Funktionen können im Basic-Programm verwendet werden.

Wie ist das in WinCC realisierbar?

Mit freundlichem Gruß,


Spiff
 
Hallo Experten,

mittlerweile hat der Siemens-Supports auf Anfrage erklärt es sei nicht ohne Weiteres möglich, eine .dll in WinCC einzubinden. Allerdings sollen ActiveX.ocx besser handhabbar sein.
Hat jemand hier schon Erfahrungen damit, eine .dll in ein ActiveX Control zu kapseln? Ist VisualBasic 2005 Express dafür geeignet?

MfG


Spiff
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo,

Spiff schrieb:
Allerdings sollen ActiveX.ocx besser handhabbar sein.

Mag ja sein, nur weist Siemens selber ausdrücklich darauf hin, dass keine Gewähr beim Einbinden fremder OCX-Dateien übernommen wird und diese Fremd-OCX nur bei Einhaltung bestimmter Programmierrichtlinien ordnungsgemäß funktionieren. Ich kann mir das auch vorstellen, da ja z.B. WinCC auch aus dem OCX den Propertyeditor erzeugen muss.
Welche Richtlinien das sind, wird allerdings schamhaft verschwiegen.
Ich habe z.B. Delphi-Komponenten als Active-X neu erzeugt und die dann WinCC untergeschoben. In den meisten Fällen funktioniert das auch, aber eben nicht immer.
Fremd-DLL müssen sich aber in WinCC-Scripte einbinden lassen (ich glaube, das ging doch über #pragma code (\"myfile.dll\") und anschliessender Deklaration der importierten Funktionen. Nur mal so aus der Hüfte geschossen ...

Gruss

Question_mark
 
Hallo,



Mag ja sein, nur weist Siemens selber ausdrücklich darauf hin, dass keine Gewähr beim Einbinden fremder OCX-Dateien übernommen wird und diese Fremd-OCX nur bei Einhaltung bestimmter Programmierrichtlinien ordnungsgemäß funktionieren. Ich kann mir das auch vorstellen, da ja z.B. WinCC auch aus dem OCX den Propertyeditor erzeugen muss.
Welche Richtlinien das sind, wird allerdings schamhaft verschwiegen.
Ich habe z.B. Delphi-Komponenten als Active-X neu erzeugt und die dann WinCC untergeschoben. In den meisten Fällen funktioniert das auch, aber eben nicht immer.
Fremd-DLL müssen sich aber in WinCC-Scripte einbinden lassen (ich glaube, das ging doch über #pragma code (\"myfile.dll\") und anschliessender Deklaration der importierten Funktionen. Nur mal so aus der Hüfte geschossen ...

Gruss

Question_mark

So ähnlich kenne ich das auch. Ich hab vor Jahren mal WinCC ausprobiert und auch versucht OCX-Dateien, von Delphi erzeugt, zu nutzen, um ein paar Sachen, die WinCC absolut nicht konnte, doch machen zu können. Da ging damals gar nichts. Ich hatte sogar einen Entwickler von Siemens am Telefon (Ja, oh Wunder :ROFLMAO:), der meinte dann, Delphi würde gar keine kompletten (nach Spezifikation) ActiveX-Komponenten erzeugen, da würde dieses und jenes fehlen, was aber für WinCC nötig wäre. Wenns bei dir schon mal "oft" geht, kann man das ja durchaus als Fortschritt ansehen.
 
OCX in WinCC

Hallo,

Ralle schrieb:
da würde dieses und jenes fehlen, was aber für WinCC nötig wäre
Ja, das kriegt man hin durch manuelle Bearbeitung der von Delphi erzeugten TLB-Dateien. Aber ich habe keine Lust, das zu machen. Wenn WinCC meine OCX nicht haben will, mache ich die Visu dann direkt in Delphi mit Simatic OPC-Server oder AGLink 4.0 von Deltalogic ...
Und alle Grenzen von WinCC sind gesprengt. :-D
Wenn ich sehe, welche Klimmzüge man für die Einbindung von Datenbanken (also UserArchive in der Nomenklatur von WinCC) z.B. für Rezepturen, Produktionsdaten etc. in WinCC machen muss ... :twisted:
Also ganz ehrlich, WinCC habe ich erstmals bei einem Lehrgang anno 1997 als Version 3.0 (unter WinDoof 95 !!!) kennengelernt und seitdem jahrelang damit gearbeitet. Mein erster Eindruck auf dem Lehrgang anno dunnemals war eigentlich --> Wenn sich Siemens und Borland damals zusammengesetzt hätten (Siemens macht die SPS-Kommunikation und Borland die Visu auf Basis von Delphi, d.h. also Komponenten mit Datenanbindung zur SPS), es wäre eine optimale Lösung geworden. Der Zug ist abgefahren, der MS-Driss ist zu tief drin, leider.
Hatte vorhin in einem anderem Beitrag eine Frage zu STEP7 gelesen, ob Visual C++ Bestandteil vom .Net Framework ist, selten so gelacht :ROFLMAO:
Nun gut, damit müssen wir leben, aber es gibt zum Glück auch Alternativen.

Gruss

Question_mark
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ich bin ein Genie !!!!

Hallo,

Ralle schrieb:

Naja, so ca. 80% funktioniert. Bin ich jetzt ein Genie :ROFLMAO:

Ralle schrieb:

Nee, eigentlich nicht. Ich habe für die Leutchen aus Karlsruhe schon einen eigenen VPN-Zugang auf dem WinCC-Rechner angelegt und begrüsse regelmässig den C++ Debugger aus Karlsruhe auf meinem Bildschirm :rolleyes:

Gruss

Question_mark
 
Ich geb auch zu, daß ich WinCC sofort wieder von meinem Rechner verbannt hatte und damals zu InTouch (alles noch unter Win3.1, wenn ich nicht irre) gegriffen habe. Der Unterschied war etwa wie der zwischen ... , ach keine Ahnung, aber er war riesig :ROFLMAO:!
 
WinCC und Intouch

Hallo,

Ralle schrieb:
ich WinCC sofort wieder von meinem Rechner verbannt hatte und damals zu InTouch

Nein Ralle, ich habe WinCC nicht verbannt und arbeite auch heute noch mit WinCC, aber vieles in WinCC hätte besser gelöst werden können ...

Und für Visualisierungen mit Datenbankanbindung und speziellen Funktionen von Delphi-Komponenten schreibe ich das dann lieber direkt in Delphi und benutze zur Kommunikation mit der SPS den OPC-Server von Siemens oder AGLink 4.0 von Deltalogic (Hallo Rainer, da fehlt aber noch ein Protokoll, oder :ROFLMAO: ). Und das funktioniert im 24/7 Betrieb ganz ausgezeichnet.

Ralle schrieb:
Der Unterschied war etwa wie der zwischen ... , ach keine Ahnung, aber er war riesig

Der Unterschied ist nur marginal, die Preise und Leistung von WinCC und Intouch sind dem Markt entsprechend angepasst, es gibt ja keine ernsthafte Konkurrenz für die beiden :ROFLMAO:
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Der Unterschied ist nur marginal, die Preise und Leistung von WinCC und Intouch sind dem Markt entsprechend angepasst, es gibt ja keine ernsthafte Konkurrenz für die beiden :ROFLMAO:

Mag sein, heute. :rolleyes: Da kann man mal sehen, wie nachhaltig sich solche Beurteilungen auswirken, bis heute hab ich nie wieder richtig Vertrauen zu WinCC fassen können und wenn ich die Fragen hier im Forum sehe, dann wächst das Vertrauen auch nicht gerade zum Einsatzmuß an:ROFLMAO:.
 
Fremd-DLL müssen sich aber in WinCC-Scripte einbinden lassen (ich glaube, das ging doch über #pragma code (\"myfile.dll\") und anschliessender Deklaration der importierten Funktionen. Nur mal so aus der Hüfte geschossen ...

Mit diesem '#pragma code' hab ich nun eine weile gesucht, aber mein Ergebnis führt zu einem fehlerhaften Script.
Ich hege Zweifel daran, dass es überhaupt die richtige Sprache ist (siehe http://www.sps-forum.de/showthread.php?t=14261 ).

Verlangt Dein WinCC nach Skripten in C/C++/C#? Gibt es also verschiedene, die verschieden angesprochen werden wollen? Denn meines (WinCC flexible 2005) versteht der Hilfe nach VisualBasicScript.

Wie würde eine solche Anweisung
Code:
#pragma code (\"d:\\path\\IpeEngCtrl.dll\")
in VBS aussehen?

MfG


luker
 
Mit diesem '#pragma code' hab ich nun eine weile gesucht, aber mein Ergebnis führt zu einem fehlerhaften Script.
Ich hege Zweifel daran, dass es überhaupt die richtige Sprache ist (siehe http://www.sps-forum.de/showthread.php?t=14261 ).

Verlangt Dein WinCC nach Skripten in C/C++/C#? Gibt es also verschiedene, die verschieden angesprochen werden wollen? Denn meines (WinCC flexible 2005) versteht der Hilfe nach VisualBasicScript.

Wie würde eine solche Anweisung
Code:
#pragma code (\"d:\\path\\IpeEngCtrl.dll\")
in VBS aussehen?

MfG

luker

Ja, WinCC und WinCCFlexible sind zwei verschiedene Programme.
 
Zurück
Oben