# HMI eigenbau. VB6, VB.NET, C#, Delphi, oder ... ?



## JesperMP (27 Juli 2008)

Hallo.

Inspiriert von diesen thread:
http://www.sps-forum.de/showthread.php?t=21187
frage ich:

Welche Programmier-Umgebung ist die beste für die Bereitstellung eines selbstgemachtes HMI ?
Wichtig ist wie einfach der Sprache und die Programmierumgebung ist zu verwenden. Ich bin kein Guru in die genannten Sprachen.

Ehrlich gesagt, es ist unwahrscheinlich, dass ich stelle um von WinCC Flexible zu eigenprogrammierung.
Aber dieses Thema interessiert mich trotzdem.

http://translate.google.com/translate_t?sl=en&tl=d


----------



## mst (28 Juli 2008)

Ich bin auch kein Guru in diesen Sprachen,

aber mit .net kann man je nach bedarf die einfacheren Sachen mit VB lösen und wenn es ins eingemachte geht C#.

Und wenn über die Funktionen von der Express Version nicht hinauskommt gibt es auch keine Lizenz Kosten.

Habe das gesamte .net Paket installiert, mir fehlte bis jetzt aber die Zeit um mich genauer damit auseinander zu setzen.


----------



## HeizDuese (28 Juli 2008)

Gerade in .net sind die Unterschiede in den Programmiersprachen nicht mehr so riesig, weil man ja mit dem .net-Framework arbeitet. Es gibt war spezielle Sachen, die sich noch unterscheiden (z.B. XML in VB), die sind dann aber meist nur noch sprachspezifisch. Mircrosoft hält auf seinen Webseiten im übrigen ein paar sehr schöne Webcasts zum kostenlosen Download (man benötigt einen live-Account) bereit, die auch für Änfänger geeignet sind:
http://www.microsoft.com/germany/events/webcasts/ondemand.mspx
Unter'm Strich würde ich, wenn .net, die Sprache verwenden, die mir liegt, der Code, der erzeugt wird ist nahezu gleich.


----------



## pvbrowser (29 Juli 2008)

Man kann auch
http://pvbrowser.org
nutzen.
Das ist GPL. Wenn man "closed source" schreiben will, braucht man eine Entwicklerlizenz, aber keine Runtime Lizenzen.


----------



## seeba (3 August 2008)

Oder mir helfen meine Sache auf .NET Basis weiter zu entwickeln. Es wird erst wieder was öffentliches geben, wenn es stabil läuft und sich einfach installieren lässt.


----------



## MW (5 August 2008)

seeba schrieb:


> ....Es wird erst wieder was öffentliches geben, wenn es stabil läuft und sich einfach installieren lässt.


 
Deswegen also immer dieses "Zugriff nicht erlaubt" beim klick auf den link in deiner Signatur ?.


----------



## seeba (5 August 2008)

Ja, da war ein Wiki installiert. Irgendwie war das ganze recht unsicher. Da wurden dauernd Seiten in komischen Sprachen erstellt, deswegen hab ich's einfach offline genommen.


----------



## arcis (5 August 2008)

*+*

Die versierte Hausfrau schwört auf

http://trolltech.com/products/qt/


----------



## Rainer Hönle (5 August 2008)

arcis schrieb:


> Die versierte Hausfrau schwört auf
> 
> http://trolltech.com/products/qt/



Meines Wissens nach ist qt unter anderem etwas für eine plattformübergreifende GUI-Programmierung (und Threads, und DB, und ...) Aber was hat qt mit einer Visu zu tun?


----------



## pvbrowser (5 August 2008)

arcis schrieb:


> Die versierte Hausfrau schwört auf
> 
> http://trolltech.com/products/qt/



Deshalb basiert http://pvbrowser.org ja auch auf Qt4.

Nur dass das auch schon an HMI/SCADA angepasst ist und
eine echte Client/Server Architektur implementiert.
Darüber hinaus sind auch schon eine Reihe von Datenerfassungen vorhanden.
http://pvbrowser.de/pvbrowser/index.php?menu=4&topic=4&subtopic=2


----------



## arcis (5 August 2008)

*+*



> Deshalb basiert http://pvbrowser.org ja auch auf Qt4.


In diesem Sinne, wenn es nicht nur sauber, sondern REIN sein soll, empfiehlt Clementine: 

http://trolltech.com/products/qt/

:s1:


----------



## JesperMP (5 August 2008)

Was kostet Qt ?


----------



## seeba (5 August 2008)

Nichts, solange du deine Visu öffentlich publizieren wirst.
Da finde ich dann das .NET Framework dennoch bequemer.


----------



## JesperMP (5 August 2008)

Ich kann leider nicht von Regenwasser leben. Meine Kunden muss doch etwas bezahlen für mein Arbeit.
Also, wieviel kostet den kommerzielle Version von Qt ?


----------



## pvbrowser (5 August 2008)

JesperMP schrieb:


> Was kostet Qt ?



Erstmals kostet eine Qt Entwicklerlizenz über 2000 Euronen (glaub so 2300).
Danach jedes Jahr so 850 Euronen.

Wir haben eine solche Lizenz und können damit kommerzielle Apps bauen.
Sonst kann man unter GPL Bedingungen auch kostenlos damit arbeiten.

http://pvbrowser.org hat aber u.a. den Vorteil, dass nur der Client Qt enthält.
Dieser wird nicht verändert, wenn Visus erstellt werden.
Der Server enthält aber keinerlei Qt Komponenten.
Deshalb kann man mit pvbrowser Visus erstellen OHNE eine Qt Lizenz zu benötigen.

Um Visus zu erstellen wird lediglich der Server (kommt ohne Qt aus) mit pvdevelop weitgehend graphisch erstellt. Neben dem eingebauten Designer kann man, wenn man möchte auch den Qt Designer zum Entwerfen der Masken verwenden. Wenn die Masken auf SVG basieren, nehmen wir inkscape.


----------



## JesperMP (2 Oktober 2008)

Ich habe C# etwas näher angekuckt. Scheint nett zum anfang aus, aber dann vermisse ich bestimmte sachen, z.b. eine numerische Eingabefeld. Es gibt ein Text-Eingabefeld, aber man kann es nicht auf numerische werte einschräncken.
Auf das www finde ich code-Beispiele womit man das text-eingabe steuern kann, aber es wird etwas kompliziert, und genau das wollte ich vermeiden.
Es ist seltsam, dass eine solche Funktionalität nicht bereits ein Teil von .Net ist.


Perfekt wäre wenn es gibt ein Komponent mit solchen Funktionalität:
Wenn das Wert nicht editiert wird, wird das wert von SPS angezeigt.
Wenn das Wert editiert wird, wird es von Gültigheit und Min/Max geprüft bevor es in den SPS geschrieben wird.
Das editieren soll möglich zu sperren sein (z.b. wenn der Benutzer nicht den benötigte recht dazu hat).

Ich glaube, dass die einfachste Weg ist die Verwendung einer 3rd-Party-Komponente.
Habt Ihr Erfahrung mit das ?
Welche Komponenten setzen Ihr ein ?


----------



## seeba (2 Oktober 2008)

JesperMP schrieb:


> Ich habe C# etwas näher angekuckt. Scheint nett zum anfang aus, aber dann vermisse ich bestimmte sachen, z.b. eine numerische Eingabefeld. Es gibt ein Text-Eingabefeld, aber man kann es nicht auf numerische werte einschräncken.
> Auf das www finde ich code-Beispiele womit man das text-eingabe steuern kann, aber es wird etwas kompliziert, und genau das wollte ich vermeiden.
> Es ist seltsam, dass eine solche Funktionalität nicht bereits ein Teil von .Net ist.
> 
> ...


Die WinCC-typischen Komponenten habe ich mir zum Beispiel selbst gebastelt.

Für manche Zwecke reicht vielleicht die MaskeTextBox.


----------



## Zottel (3 Oktober 2008)

Ich würde dafür nach wie vor JAVA verwenden, aus folgenden Gründen:
- Es steht auf jeder Plattform einschließlich PDAs und Handys zur Verfügung. Damit läßt sich Standard-Consumer-Hardware als (mobile) Bedieneinheit nutzen.
- JAVA (und auch .NET) können zur Laufzeit neue Klassen einbinden. "Oben" (in den Seiten der Visualisierung) kann man einfach ein neues Element kreieren ohne die ganze Anwendung neu zu kompilieren und ohne den kompletten Quellcode zu benötigen odeer zu kennen. "Unten" (zur Feldebene hin) kann man ein anderes Datenaustausch-Protokoll (und damit eine neue Steuerung) ebenso einfach einbinden. Wenn man eine kleine Abstraktionsschicht zwischen der HMI-Grafik und dem AWT/Swing/JFC einfügt kann man auch "seitwärts" einfach neue Grafik- und Eingabegeräte nutzen.

Natürlich kann man den Vorteil von JAVA und .NET, das dynamische Nachladen von Klassen, auch in jeder anderen Programmiersprache nachbilden. Unzählige Anwendungen, die "plug-ins" nutzen können und mehrheitlich in C++ (es darf auch C sein, z.B. GTK und Gimp) geschrieben sind, beweisen das. Nur muß man sich dann darum selbst kümmern und die Unterstützung durch das OS ist immer anders:
Win32:LoadLibrary
Unix:dlopen
Symbian:???
Win32:GetProcAddress
Unix:dlsym
Symbian:???

Als Nachteil sehe ich bei JAVA und .NET die dynamische Speicherverwaltung mit garbage collector: Es ist zwar bequem, sich um die Entsorgung dynamisch belegten Speichers nicht kümmern zu müssen, aber es gibt dann plötzlich eine "Gedenkminute" (oder Sekunden) wenn der GC aufräumt. 
Eine HMI-Anwendung sollte am besten genauso zügig reagieren wie ein mechanischer Taster.
Die Wartezeiten für den GC lassen sich vermeiden, indem man mit der Anforderung neuen Speichers vorsichtig umgeht. Eine HMI-Anwendung braucht meist keinen neuen Speicher, solange dieselbe Seite angezeigt wird.


----------



## pvbrowser (3 Oktober 2008)

Hallo Zottel,

was macht dein Bello ?

Zu Deinem Posting muss ich auch was sagen.
Wenn Du schon mit einer Hochsprache,
wie Java eine Visualisierung machen willst,
musst Du doch bei Adam und Eva anfangen oder
hast Du da schon eine Basissoftware,
die Dir den grössten Teil der Arbeit abnimmt ?

Wer mit Java oder C# umgehen kann sollte mit
http://pvbrowser.org
auch keine Probleme haben.

Darin haben wir z.B. Dein libnodave schon eingebunden,
so dass sich die Anwender nicht mehr auf Programmierebene begeben müssen.
Es reicht einfach eine INI Datei auszufüllen und die Datenerfassung mit Deinem libnodave ist fertig.

Da pvbrowser C/C++ ist, können da also problemlos Fremdbibliotheken,
wie Dein libnodave mit eingebunden werden.
Im Prinzip kann man da jedes Protokoll mit erschlagen.
Momentan kann pvbrowser von Hause aus

Modbus (Serial Line and TCP)
Siemens TCP
Siemens PPI
Ethernet_IP
EIBnet/KNX
OPC XML-DA
PROFIBUS
CAN

http://pvbrowser.de/pvbrowser/index.php?menu=4&topic=4&subtopic=2

Probier doch mal selber aus.
Du kannst ja C/C++.
Vielleicht ergeben sich ja da irgend welche Anknüpfungspunkte.

Jedenfalls wird Dir mit pvbrowser die meiste Arbeit schon abgenommen.
Du brauchst wirklich nur Deine eigene Logik in das generierte Framework einzusetzen.

Viele Grüsse:
pvbrowser


----------



## seeba (5 Oktober 2008)

Zottel schrieb:


> Ich würde dafür nach wie vor JAVA verwenden


Du hast schon Recht und die Gründe sind einleuchtend. Bei .NET ist halt aus den Express Editions schnell ein Editor für die eigene HMI-Applikation gemacht. Bei Java find' ich mich da nicht zurecht. Momentan überlege ich auch, ob ich nicht lieber etwas mit Java machen sollte. Eine Idee wäre, den SVG-Standard so zu erweitern, dass er etwas für die PV nutzt. Dafür müsste man einen guten, absolut dem Standard nahestehenden SVG Viewer haben, den man um die Features erweitert. Die Prozessdaten würde ich dann per Webservice anbieten, so dass das neue Viewer-Applet daher seine Daten zur Animation bezieht. Was hälst du davon? Gutes Konzept?


----------



## pvbrowser (5 Oktober 2008)

seeba schrieb:


> Eine Idee wäre, den SVG-Standard so zu erweitern, dass er etwas für die PV nutzt. Dafür müsste man einen guten, absolut dem Standard nahestehenden SVG Viewer haben, den man um die Features erweitert. Die Prozessdaten würde ich dann per Webservice anbieten, so dass das neue Viewer-Applet daher seine Daten zur Animation bezieht. Was hälst du davon? Gutes Konzept?



http://pvbrowser.de/pvbrowser/doc/manual/de_p33.html


----------



## seeba (5 Oktober 2008)

Hallo Rainer,
ich bin eher dafür die Animationsinformationen im SVG-File einzubauen.
Geht sowas auch?

Liebe Grüße,
Sebastian


----------



## pvbrowser (5 Oktober 2008)

seeba schrieb:


> Hallo Rainer,
> ich bin eher dafür die Animationsinformationen im SVG-File einzubauen.
> Geht sowas auch?



Neben der eigentlichen Grafik kann man in SVG beliebige weitere Eigenschaften / Texte einbauen, die nicht vom Viewer sondern von Dir selber interpretiert werden.

siehe: pvbrowser:beispiel... in dieser SVG Grafik

PS: die forensoftware hat probleme, die svg richtig rüber zu bringen :-(

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!-- Created with Inkscape (http://www.inkscape.org/) -->
<svg
   xmlns:dc="http://purl.org/dc/elements/1.1/"
   xmlns:cc="http://creativecommons.org/ns#"
   xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
   xmlns:svg="http://www.w3.org/2000/svg"
   xmlns="http://www.w3.org/2000/svg"
   xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
   xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
   width="210mm"
   height="297mm"
   id="svg2"
   sodipodi:version="0.32"
   inkscape:version="0.46"
   sodipodi:docname="murx.svg"
   inkscapeutput_extension="org.inkscape.output.svg.inkscape">
  <defs
     id="defs4">
    <inkscapeerspective
       sodipodi:type="inkscapeersp3d"
       inkscape:vp_x="0 : 526.18109 : 1"
       inkscape:vp_y="0 : 1000 : 0"
       inkscape:vp_z="744.09448 : 526.18109 : 1"
       inkscapeersp3d-origin="372.04724 : 350.78739 : 1"
       id="perspective10" />
  </defs>
  <sodipodi:namedview
     id="base"
     pagecolor="#ffffff"
     bordercolor="#666666"
     borderopacity="1.0"
     inkscapeageopacity="0.0"
     inkscapeageshadow="2"
     inkscape:zoom="0.35"
     inkscape:cx="350"
     inkscape:cy="520"
     inkscape:document-units="px"
     inkscape:current-layer="layer1"
     showgrid="false"
     inkscape:window-width="1280"
     inkscape:window-height="734"
     inkscape:window-x="0"
     inkscape:window-y="0" />
  <metadata
     id="metadata7">
    <rdf:RDF>
      <cc:Work
         rdf:about="">
        <dc:format>image/svg+xml</dc:format>
        <dc:type
           rdf:resource="http://purl.org/dc/dcmitype/StillImage" />
      </cc:Work>
    </rdf:RDF>
  </metadata>
  <g
     inkscape:label="Ebene 1"
     inkscape:groupmode="layer"
     id="layer1">
    <rect
       style="opacity:0.97971018;fill:#003b00;fill-opacity:1;stroke:#674a00;stroke-width:0;stroke-linecap:butt;stroke-linejoin:round;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1"
       id="rect2380"
       width="85.714287"
       height="65.714287"
       x="74.285713"
       y="75.219322"
       pvbrowser:beispiel="hier irgend was einbauen" />
  </g>
</svg>


----------



## seeba (5 Oktober 2008)

So hab ich mir das auch gedacht. Dann fehlt nur noch der passende Viewer, der meine Eigenschaften interpretieren kann.  Hast du da eine passende Basis?


----------



## pvbrowser (6 Oktober 2008)

seeba schrieb:


> So hab ich mir das auch gedacht. Dann fehlt nur noch der passende Viewer, der meine Eigenschaften interpretieren kann.  Hast du da eine passende Basis?



Der SVG Viewer wird von Qt gestellt und ist schon in pvbrowser integriert.
Solche Eigenschaften "missbrauchen" wir auch schon als INI-Daten.
Ja, die passende Basis habe ich schon, pvbrowser


----------



## thiborg (14 Oktober 2008)

*Schwieriges Thema*

Hallo,

wir haben bis vor 3 Jahren mit VB6 entwickelt. Wir haben eine fertigen "Treiber" zu S7, welcher auf der Schnittstelle von DeltaLogic beruht.
Unserer Treiber vereinfacht die Komunikation mit der S7 durch unsere VB Anwendung. Allerdings haben wird im Moment keine Absicht das ganze von VB6 in .Net zu konvertieren, da kein entsprechendes Projekt ansteht.

Begonnen haben wir im Jahre 2000 mit dem ersten Projekt und dies hat sich dann weiterentwickelt und basierte auf ActiveX Controls.
Mit den heutigen Entwicklungswerkzeugen würde ich auf jeden Fall einiges anders Lösen. Allerdings bin ich der Meinung, dass das .Net Framwork die Richtigen Werkzeuge bereitstellt, also entweder C# oder VB.Net, da ziemlich "einfach" zu programmieren. Es wird einem viel Verwaltungsarbeit abgenommen und man kann sich auf das Wesentliche konzentrieren.

Also mein Rat ist das .Net Framework.

Gruß
Thorsten


----------



## Thomas_v2.1 (14 Oktober 2008)

thiborg schrieb:


> Also mein Rat ist das .Net Framework.


Aufgrund eurer Erfahrungen mit VB6 finde ich das ein seltsames Fazit.
Bei .Net seid ihr dann wieder von den Änderungen seitens Microsoft am .Net-Framework abhängig.
Hättet ihr damals den S7-Treiber in C programmiert, so wäre er heute (und ich schätze mal dass es einen C-Compiler für die gängigen Prozessor-Architekturen in 10 Jahren immer noch geben wird) immer noch zu gebrauchen - siehe auch Libnodave, welches aufgrund der BSD-Sockets nichtmal auf Windows oder Linux beschränkt ist.

Gruß
Thomas


----------



## Rainer Hönle (15 Oktober 2008)

Thomas_v2.1 schrieb:


> Aufgrund eurer Erfahrungen mit VB6 finde ich das ein seltsames Fazit.
> Bei .Net seid ihr dann wieder von den Änderungen seitens Microsoft am .Net-Framework abhängig.
> Hättet ihr damals den S7-Treiber in C programmiert, so wäre er heute (und ich schätze mal dass es einen C-Compiler für die gängigen Prozessor-Architekturen in 10 Jahren immer noch geben wird) immer noch zu gebrauchen - siehe auch Libnodave, welches aufgrund der BSD-Sockets nichtmal auf Windows oder Linux beschränkt ist.
> 
> ...


Tja, ganz so einfach ist es nicht. In C geschriebene Programme sind in .net grundsätzlich unmanaged. Und die .net Programme sind managed. Deshalb wird auch dafür ein entsprechender Wrapper benötigt. Und diesen kann man aber auch für VB6-DLLs und ActiveX-Komponenten erstellen.
Darüber hinaus muss bei der portablen Programmierung nicht nur auf die BSD-Sockets geachtet werden. Zwischen Linux und Windows gibt es noch deutlich mehr Fallstricke. Und wenn dann noch WinCE ins Spiel kommt, wird es noch einmal lustiger.


----------



## pvbrowser (15 Oktober 2008)

Rainer Hönle schrieb:


> Darüber hinaus muss bei der portablen Programmierung nicht nur auf die BSD-Sockets geachtet werden. Zwischen Linux und Windows gibt es noch deutlich mehr Fallstricke. Und wenn dann noch WinCE ins Spiel kommt, wird es noch einmal lustiger.



Dann will ich mal etwas Reklame für Qt machen,
das ist nämlich eine Alternative zu .NET die auch noch portabel ist.

http://trolltech.com/products/appdev

Man kann also mit 1 Sourcecode Programme estellen, die auf
Linux/Unix/Windows/OS X/Embedded Linux und Windows CE laufen !!!

Wenn man eine portable Bibliothek in C/C++ haben will,
braucht man die Systemabhängigkeiten nur konsequent kapseln und per
#ifdef für die einzelnen Plattformen zu implementieren.

Wie das aussehen kann will ich hier mal an unserer Time Klasse zeigen:
http://pvbrowser.de/pvbrowser/sf/manual/rllib/html/classrlTime.html#58e753a2b74eea66ef8df028f266f7e2

Seht euch auch mal die anderen Klassen dort an.
Durch die Verwendung der #ifdef innerhalb der Methoden der Bibliothek sind
Programme, die darauf basieren portabel.
http://pvbrowser.de/pvbrowser/sf/manual/rllib/html/classes.html


----------



## Rainer Hönle (15 Oktober 2008)

Hallo Rainer,
wenn ich qt im professionellen Bereich einsetze (keine Open Source Software), dann kostet das Teil richtig Geld. Und zwar für jedes Betriebssystem und für jedes einzelnen Module und für jeden Entwickler. Entwicklerwechsel nur alle x Monate zulässig ... Die "freie" Version die bei Borland mal mitgeliefert wurde, war auch nicht der Perfomancebrüller. 
Wir haben uns deshalb für das Konfigurationsprogramm von AGLink für wxwidgets entschieden. Reicht dafür vollkommen aus (Anforderungen sind hier nicht so groß), kostet auch im professionellen Bereich nichts und braucht genauso viel Zeit zur Einarbeitung wie qt. AGLink selber kommt ganz ohne fremde GUI-Bibliothek aus und ist für Win32 (einschließlich .net), WinCE und Linux verfügbar.
Nichts desto trotz halte ich persönlich derzeit .net und mono für eine recht interessante Alternative zu wxwidgets und auch zu qt. Die Jungs hinter mono scheinen rech fit zu sein.


----------



## pvbrowser (15 Oktober 2008)

Rainer Hönle schrieb:


> Hallo Rainer,
> wenn ich qt im professionellen Bereich einsetze (keine Open Source Software), dann kostet das Teil richtig Geld. Und zwar für jedes Betriebssystem und für jedes einzelnen Module und für jeden Entwickler. Entwicklerwechsel nur alle x Monate zulässig ...



Hallo Rainer,
wir haben eine kommerzielle Qt Lizenz. Aber bei dem pvbrowser braucht man KEINE Qt Lizenz, denn nur der Client beinhaltet Qt und deshalb ist da die GPL Version vollkommen ausreichend (der Client wird ja nicht vom Entwickler einer Visualisierung verändert). Der Server, um den es bei pvbrowser ja eigentlich geht, beinhaltet KEIN Qt. 

Der Client entspricht ja sowas wie Firefox.
Und der Server sowas wie Apache.
Dabei können Client und Server ja auch komplett verschiedene Lizenzen haben.


----------



## Rainer Hönle (15 Oktober 2008)

pvbrowser schrieb:


> Hallo Rainer,
> wir haben eine kommerzielle Qt Lizenz. Aber bei dem pvbrowser braucht man KEINE Qt Lizenz, denn nur der Client beinhaltet Qt und deshalb ist da die GPL Version vollkommen ausreichend (der Client wird ja nicht vom Entwickler einer Visualisierung verändert). Der Server, um den es bei pvbrowser ja eigentlich geht, beinhaltet KEIN Qt.
> 
> Der Client entspricht ja sowas wie Firefox.
> ...


Hallo Rainer,

mein Statement war ausschließlich auf qt bezogen und nicht auf pvbrowser. Du hattest ja Reklame für qt gemacht ;-). Und da musste ich einfach antworten.


----------



## phyrexianer (14 Dezember 2012)

Und was hat sich bei euch in den letzten 4 Jahren getan ?    QT oder .Net ?

gruß


----------

