HMI Software

[nicknack123123]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo,

ich bin zur Zeit auf der Suche nach einem Visualisierungssystem, welches folgende Anforderungen erfüllen sollte:
- Zugriff auf Siemens / Rockwell Steuerungen (RSLogix5000-Generation)
- Rezeptverwaltung
- Datenspeicherung (CSV, SQL) / Trends
- Programmierschnittstelle (.net oder ähnliches)

Es geht darum, eine standardisierte Visualisierung aufzubauen. Ich möchte möglichst viel programmatisch durch Konfigurationsdateien oder sogare SPS Daten lösen. So soll z.B. eine Parameterseite nur einmal erstellt werden müssen und über eine Konfiguration die entsprechenden Werte angezeigt werden.

Es wäre auch eine Variante das ganze mit entsprechenden Treibern von z.B. INGEAR(???) mit einer Eigenentwicklung (C#/VB.net) zu realisieren.

Ich freue mich auf eure Vorschläge, Erfahrungsberichte, etc.

Gruß,
nicknack123123

 

[spstiger]

Auf was für einem System soll das laufen? HMI, Windows PC, Server, Tablet?
Sollen die verschiedenen SPS gleichzeitig angesteuert werden oder nur jeweils eine SPS per System?
Datenspeicherung und Rezeptverwaltung sind ja Standardaufgaben einer HMI- oder SCADA-Software, da wirst du keine Probleme haben, etwas zu finden.
Bei den Kommunikationstreibern wird die Auswahl schon etwas kleiner, aber es gibt sehr viel Software, die auch Kommunikationstreiber für verschiedene SPS bietet. Siemens S7 und RSLogix sind dabei weit verbreitet.

Wichtigstes Kriterium ist in deinem Fall die Plattform (und Fernzugriffsoptionen z.B. vom Smartphone etc.) und natürlich die Programmierschnittstelle. Was soll die tun?

Grüße

Steffen

 

[Larry Laffer]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo,
wir setzen an der Stelle VisiWin ein. Das kannst du komplett unter .Net erstellen (Visual Studio) und dich da so richtig austoben. Die Rezeptverwaltung von denen ist allerdings genauso Sch...e wie bei den meißten anderen - aber da könntest du dann ja auch etwas Eigenes erstellen.
Einzig, ob die einen Treiber für Rockwell haben weiß ich im Augenblick nicht ... wäre aber mit Sicherheit zu erfragen ...

Gruß
Larry

 

[nicknack123123]

Danke erstmal für die Antworten, also das ganze soll grundsätzlich auf einem Windows PC eingesetzt werden evtl. auch auf Windows Panels (WinCE). Tablets wären ein schönes Gimmick, aber nicht lebensnotwendig.

Ich möchte erreichen, dass wir ein universales System mit möglichst großer Flexibilität einsetzen können. Deshalb auch die Programmierschnittstelle, welche mir einfach im Sonderfall (Kundenabhängig) die Möglichkeit gibt weitere Funktionen (Anbindung an Fremd-Anlagen, ERP oder ähnliches) zu realisieren.

Es gilt eigentlich ein System zu finden, welches die oben genannten "Standard"-Funktionen eines HMIs von Hause aus abdeckt (um das Rad nicht neu erfinden zu müssen und Entwicklungs, als auch Wartungsaufwand zu sparen). Trotzdem sollte das System natürlich maximale Flexibilität zur Erweiterung/Anpassung zur Vergügung stellen ;-). Am besten bei freier Plattformwahl ;-) ...

Die wichtigsten Punkte sollten abgedeckt sein.

Danke im vorraus,
nicknack123123

 

[Larry Laffer]

Naja ... dann schau dir das von mir vorgeschlagene vielleicht mal im Internet an ...

 

[nicknack123123]

Zuviel Werbung?
-> Hier kostenlos registrieren

Danke für eure Antworten, dass hilft mir schonmal weiter VisiWin sieht schon sehr interessant aus.

 

[faust]

Hallo nicknack,

ich stehe quasi vor der gleichen Aufgabe, möchte in meinem Fall von proprietären Entwicklungssystemen aber ganz wegkommen:
1. Ich möchte kein Geld für Lizenzen ausgeben.
2. Ich möchte soweit möglich nur die Standard-Bibliotheken der eingesetzten Programmiersprache verwenden.
3. Ich möchte wissen, wie z.B. eine Rezeptverwaltung oder ein Meldesystem intern funktioniert, werde diese und mehr deswegen selbst entwickeln.

Ich habe mich für Java als Programmiersprache entschieden, unter anderem weil
+ meine favorisierte Entwicklungsumgebung 'Eclipse' sehr mächtig und dazu kostenlos ist,
+ sie plattformunabhängig eingesetzt werden kann (Linux als Betriebssystem ist ein weiteres Ziel).

Ich habe darüber hinaus vor, auch die Kommunikation zur Steuerung/zum Steuerungsprogramm nur mit Standardbibliothekselementen zu bewerkstelligen, da ich dadurch eine fast vollständige Unabhängigkeit zu unseren unterschiedlichen Steuerungsplattformen erreiche.

Zum Vorschlag VisiWin: Habe ich zu VB6-Zeiten auch schon einmal eingesetzt. Ich habe zum Schluss VB6 solo verwendet, da die damaligen VisiWin-Controls dann doch nicht den großen Mehrwert für mich hatten.


Da dieses Thema hier schon mehrmals sehr kontrovers diskutiert wurde hier noch ein paar Fragen/Gedanken dazu:
1. Wie sind bei euch die Themen 'Weiterentwicklung' und'Softwarepflege' geregelt?
2. Wie steht es mit 'Implementierung von Sonderwünschen'?
3. Wie läuft eine Inbetriebnahme von euren Maschinen ab?
4. Wer darf Codeänderungen durchführen?


Gruß, Fred

 

[nicknack123123]

Hallo Fred,

grundsätzlich würde ich mir natürlich auch gerne die Lizenzkosten sparen und volle Kontrolle über das System haben bzw. wissen wie es im Detail funktioniert.
Jetzt kommen wir aber zu deinen aufgeführten Punkten:
1.) Grundsätzlich haben wir zur Zeit ein Team, welches hauptsächlich aus "SPS-Programmieren" besteht. Daraus resultiert, dass ich der einzige wäre der das System überblicken, weiterentwickeln, pflegen kann (zumindest in der aktuellen Situation). Daraus resultiert für mich eigentlich, dass es eine "Kauf"-Lösung werden muss, welche diesen Teil der Entwicklung übernimmt. Ich denke die Pflege eines "Eigenbaus" steht da nicht ganz im Verhätlnis, außer wir gehen davon aus, dass sich die Kommunikationsprotokolle nicht mehr verändern.
Es gäbe für mich noch die Variante alle HMI Funktionen selber zu implementieren und nur die Kommunikationstreiber zuzukaufen und auf Basis des .net-Frameworks den Rest eigenständig zu entwickeln.
Hier würde ich durch einmalige Lizenzkosten erstmal den Kostenfaktor für jede Einzelvisualisierung minimieren.

2.) Implementierung von Sonderwünschen sind normalerweise extra kalkuliert oder werden dem Kunden als "Goodwill"-Extras implementiert. Generell sollte das System eine passende Schnittstelle bereitstellen, um in dieser Richtung möglichst viel möglich machen zu können.

3.) Für die Inbetriebnahme stelle ich mir vor, dass es dem Inbetriebnehmer aufgrund von Konfigurationsdateien/Menüs möglich sein muss, dass Visualisierungssystem an die entsprechende Anlage anpassen zu können.

4.) Codeänderungen sollten nur durch die Entwickler (mich ;-)) durchgeführt werden bzw. nur nach Absprache. Ich bin der Meinung, dass man ein System entwickeln könnte, welches keiner Code-Anpassungen durch einen Inbetriebnehmer erfordert.

Gruß,
nicknack

 

[rostiger Nagel]

Zuviel Werbung?
-> Hier kostenlos registrieren

Zum Vorschlag VisiWin: Habe ich zu VB6-Zeiten auch schon einmal eingesetzt. Ich habe zum Schluss VB6 solo verwendet, da die damaligen VisiWin-Controls dann doch nicht den großen Mehrwert für mich hatten.

So ist es bei uns auch einmal gelaufen, erst VisiWin, was dann nicht ausreichte
und dann mit VB.net (pur) eine eigene Oberfläche gebaut und dann über OPC angebunden

Hallo Fred,

grundsätzlich würde ich mir natürlich auch gerne die Lizenzkosten sparen und volle Kontrolle über das System haben bzw. wissen wie es im Detail funktioniert.
Jetzt kommen wir aber zu deinen aufgeführten Punkten:
1.) Grundsätzlich haben wir zur Zeit ein Team, welches hauptsächlich aus "SPS-Programmieren" besteht. Daraus resultiert, dass ich der einzige wäre der das System überblicken, weiterentwickeln, pflegen kann (zumindest in der aktuellen Situation). Daraus resultiert für mich eigentlich, dass es eine "Kauf"-Lösung werden muss, welche diesen Teil der Entwicklung übernimmt. Ich denke die Pflege eines "Eigenbaus" steht da nicht ganz im Verhätlnis, außer wir gehen davon aus, dass sich die Kommunikationsprotokolle nicht mehr verändern.
Es gäbe für mich noch die Variante alle HMI Funktionen selber zu implementieren und nur die Kommunikationstreiber zuzukaufen und auf Basis des .net-Frameworks den Rest eigenständig zu entwickeln.
Hier würde ich durch einmalige Lizenzkosten erstmal den Kostenfaktor für jede Einzelvisualisierung minimieren.

2.) Implementierung von Sonderwünschen sind normalerweise extra kalkuliert oder werden dem Kunden als "Goodwill"-Extras implementiert. Generell sollte das System eine passende Schnittstelle bereitstellen, um in dieser Richtung möglichst viel möglich machen zu können.

3.) Für die Inbetriebnahme stelle ich mir vor, dass es dem Inbetriebnehmer aufgrund von Konfigurationsdateien/Menüs möglich sein muss, dass Visualisierungssystem an die entsprechende Anlage anpassen zu können.

4.) Codeänderungen sollten nur durch die Entwickler (mich ;-)) durchgeführt werden bzw. nur nach Absprache. Ich bin der Meinung, dass man ein System entwickeln könnte, welches keiner Code-Anpassungen durch einen Inbetriebnehmer erfordert.

Gruß,
nicknack

Wenn du das wirklich alleine stemmst, geht es nicht ohne eine kommerzielle Lössung,
wenn du mal krank wirst oder ausscheidest, kannst du deine Firma oder Kunden ganz
schön in Schwierigkeiten bringen.

 

[faust]

@nicknack:
Ich bin sowas von bei dir, alle deine Aussagen treffen auch bei mir zu.

Wobei ich nach wie vor eines nicht verstehe (@nagel: wir sind wieder bei der gleichen Diskussion wie schon einige Wochen zuvor ):
Wieso meinst du/meinen so viele, dass es einfacher sei, eine Software zu pflegen nur weil ein proprietäres Entwicklungssystem/eine proprietäre Programmiersprache wie z.B. Siemens WinCC (Adv. oder Prof. ist egal) zum Einsatz kommt?
Die Funktionalität, die mittlerweile von Kunden oder der eigenen Firma gefordert wird, geht meistens weit über das hinaus, was mit einfachen Drag&Drop-Methoden (und dazu zähle ich auch Bildbausteine etc.) zu bewerkstelligen ist. Dadurch wird auch eine mit WinCC projektierte HMI-Software nicht so ohne weiteres für einen Nicht-HMI-Entwickler zu durchschauen.

Vielmehr finde ich, dass Hochsprachen eine viel bessere Strukurierung des Projektes zulassen, von durchgängigerer Funktionalitätskapselung, Vermeidung von Code-Redundanzen und ähnlichem ganz zu schweigen. Dass eine Hochsprachen-Entwicklungsumgebung die ganzen Unzulänglichkeiten/Probleme eines TIA-Portals oder AutomationStudios oder Twincat nicht hat und darüber hinaus (meistens) weit bessere Programmierunterstützung bietet, brauche ich glaube ich nicht extra erwähnen. Deswegen glaube ich auch nicht, dass ich bei einer Funktions-Eigenentwicklung am Ende soviel langsamer bin; aktuell verbrate ich z.B. viel Zeit damit, meinem WinCC-Adv.-Projekt ein TreeView-Control zu verpassen (welches für Panels ebenso verwendbar ist), in Java wäre das eine Sache von wenigen Stunden und nicht von Tagen...

Und wenn die Chefs und Abteilungsleiter genauso und auch weit genug denken, dann wird sich dies alles hoffentlich auch in der (zukünftigen) Personalplanung niederschlagen.


Gruß, Fred

 

[rostiger Nagel]

Hallo Fred,
ich bin ja ganz bei dir das WinCC bis Advanced und Konsorten, zu Leistungsschwach
in seiner Funktionalität ist. Das Problem bei der Hochsprachen Lössung ist das es da
zu große Freiheitgrade gibt und keine klassischen Lössungen die man später einfach
nachvollziehen kann. Nimm zb das Meldesystem bei WinCC, da gibt es nur die vorgegebenen
Wege von Siemens, da kann dann ein fremder in dein Projekt, hier im Forum nachfragen
wie es funktioniert. Bei einer selbstgebastelten Lössung wird das schwer.

Vor allen Dingen finde ich es garnicht so leicht so etwas einen Kunden zu verkaufen, der
zurecht darauf besteht das sein Service Personal die Anlage zu beherrschen hat.

 

[faust]

Zuviel Werbung?
-> Hier kostenlos registrieren

...
Das Problem bei der Hochsprachen Lössung ist das es da
zu große Freiheitgrade gibt und keine klassischen Lössungen die man später einfach
nachvollziehen kann. Nimm zb das Meldesystem bei WinCC, da gibt es nur die vorgegebenen
Wege von Siemens, da kann dann ein fremder in dein Projekt, hier im Forum nachfragen
wie es funktioniert. Bei einer selbstgebastelten Lössung wird das schwer.
...

Und eben dieses Argument zieht m.M.n. nicht, wenn ich den vorgegebenen Weg von z.B. Siemens derart verbiegen und umständlich erweitern muss, damit eine für mich/unsere Firma adäquate Lösung dabei herauskommt. Da kann dann ein Fremder noch soviel über den Siemens-Weg und seine Controls/Funktionen herausfinden wollen, meine Vorgehensweise/Logik müsste er trotzdem verstehen. Und warum nicht dann gleich ganz auf die unpassende Basis verzichten und das System komplett so schneidern wie man es braucht?

...
Vor allen Dingen finde ich es garnicht so leicht so etwas einen Kunden zu verkaufen, der
zurecht darauf besteht das sein Service Personal die Anlage zu beherrschen hat.
...

Hier gilt m.E. das gleiche: zeige mir einen kundeneigenen Servicetechniker, der sich nicht bei einer großen Anlage mit zig umfangreichen und komplizierten Funktionen im Code verliert.
Vielmehr ist wichtig, dass die Software einer Anlage so entwickelt wurde, dass dieser Mensch bei der Störungssuche optimal unterstützt wird; aussagekräftige Meldungen und ein gut umgesetzter I/O-Test z.B. sind da viel wichtiger als eine vermeintliche Sicherheit durch die eingesetzte Plattform (Am Ende meint der Kunde/Techniker noch, er beherrscht die Anlage. Eine Erweiterung kann dann doch nicht so schwer sein... Ups, ist ja doch komplizierter... Oje, die Anlage steht... Hersteller - Hilf mir!!!).


Gruß, Fred

 

[nicknack123123]

...
Die Funktionalität, die mittlerweile von Kunden oder der eigenen Firma gefordert wird, geht meistens weit über das hinaus, was mit einfachen Drag&Drop-Methoden (und dazu zähle ich auch Bildbausteine etc.) zu bewerkstelligen ist. Dadurch wird auch eine mit WinCC projektierte HMI-Software nicht so ohne weiteres für einen Nicht-HMI-Entwickler zu durchschauen.
...

Da stimme ich dir voll zu, jedoch hast du zumindest die Grundfunktionalität (Meldesystem, Kommunikation, etc.) durch ein proprietäres System soweit abgedeckt, dass es der Firma die "Sicherheit" gibt, dass es durch den Hersteller genügend Unterstützung angeboten wird um es weiter zu gebrauchen und das Wissen nicht auf wenige Mitarbeiter beschränkt wird.
Außerdem hat es den Vorteil, dass man sich zu mindest in diesem Teil nicht mit der Weiterentwicklung der Kommunikationsprotokolle "belasten" muss.

Deshalb eine proprietäre Lösung mit einer "mächtigen" Enwicklungsumgebung im Hintergrund, die es ermöglicht entpsrechende Funktionalitätskapselung und Sonderwünsche abzudecken.

Die Nachvollziehbarkeit des Codes muss meiner Meinung nach durch eine ordentliche Dokumentation der Software abgedeckt werden. Wenn dies nicht eingehalten wird gibt es egal ob proprietäre Lösung oder Eigenbau immer Probleme (Wie oft schon vorgekommen).

Gruß,
nicknack

 

[faust]

Hallo nicknack,

Da stimme ich dir voll zu, jedoch hast du zumindest die Grundfunktionalität (Meldesystem, Kommunikation, etc.) durch ein proprietäres System soweit abgedeckt, dass es der Firma die "Sicherheit" gibt, dass es durch den Hersteller genügend Unterstützung angeboten wird um es weiter zu gebrauchen ...

Das mit der Unterstützung ist aber zumindest bei Siemens ziemliches Wunschdenken, oder?:?
Auch (oder gerade!) bei dieser Grundfunktionalität liegt ja oft der Hase im Pfeffer. Was nützt mir eine durch mich/uns gezwungenermaßen 'verbogene' proprietäre Grundfunktionalität, wenn dadurch nicht einmal der Siemens-Support helfen kann? Habe ich nämlich schon oft genug erlebt...

...
Außerdem hat es den Vorteil, dass man sich zu mindest in diesem Teil nicht mit der Weiterentwicklung der Kommunikationsprotokolle "belasten" muss.
...

Die Anpassung 'meines gedachten' Kommunikationsprotokolls wäre bei mir aber automatischer Bestandteil der Software-Weiterentwicklung: Die Meldungen werden einfach um die neuen Informationen erweitert.

...
Die Nachvollziehbarkeit des Codes muss meiner Meinung nach durch eine ordentliche Dokumentation der Software abgedeckt werden. Wenn dies nicht eingehalten wird gibt es egal ob proprietäre Lösung oder Eigenbau immer Probleme (Wie oft schon vorgekommen).
...

100%ige Zustimmung. Wobei gerade hier die proprietären Entwicklungssysteme m.M.n. extrem schwächeln, so etwas wie z.B. JavaDoc habe ich noch nirgendwo gefunden.


Gruß, Fred

 

[nicknack123123]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo Fred,

Das mit der Unterstützung ist aber zumindest bei Siemens ziemliches Wunschdenken, oder?:???:
Auch (oder gerade!) bei dieser Grundfunktionalität liegt ja oft der Hase im Pfeffer. Was nützt mir eine durch mich/uns gezwungenermaßen 'verbogene' proprietäre Grundfunktionalität, wenn dadurch nicht einmal der Siemens-Support helfen kann? Habe ich nämlich schon oft genug erlebt...

Das ist sowohl bei Siemens als auch Rockwell wunschdenken, wenn ich allerdings einen dritten Fremden nehme, kann ich mir vorstellen, dass hier die Unterstützung besser ist. Da diese davon leben, dass ihre Software verkauft wird. So mein Wunschgedanke ;-).

Die Anpassung 'meines gedachten' Kommunikationsprotokolls wäre bei mir aber automatischer Bestandteil der Software-Weiterentwicklung: Die Meldungen werden einfach um die neuen Informationen erweitert.

Du musst ja hier bis auf die Protokoll-Ebene (Profinet, Ethernet/IP, etc.) runtergehen, wenn du es selber machen willst. Erstmal wäre die Frage, inwiefern die Protokollstacks "frei" verfügbar sind.
Bei Siemens anscheinend schon (siehe libnodave). Bei AB (Ethernet/IP) bin ich mir nicht sicher. Habe ich mich auch noch nicht weiter mit beschäftigt um ehrlich zu sein.

Alternativ kannst du theoretisch natürlich ein eigenes Protokoll über TCP/IP entwickeln, wofür du dann allerdings wieder die entsprechenden Steuerungsmodule brauchst um entsprechende TCP/IP-Pakete zu schnüren.

Und spätestens dann wird es meiner Meinung nach unwirtschaftlich und viel zu unüberschaubar, wenn du dies "nebenbei" machen willst.
Deshalb komme ich hier wieder zu einer Kauf-Lösung, die mir die Kommunikationsprotokolle und Grundfunktionen eines HMIs zur Verfügung stellt und pflegt, aber mir für alle weiteren Funktionalitäten möglichst viel Freiraum durch Ihre Programmierschnittstelle gibt.

Gruß,
Peter

 

[faust]

...
A;-)lternativ kannst du theoretisch natürlich ein eigenes Protokoll über TCP/IP entwickeln, wofür du dann allerdings wieder die entsprechenden Steuerungsmodule brauchst um entsprechende TCP/IP-Pakete zu schnüren.
...

Die besagten Steuerungsmodule wären dann aber das einzige, was plattformabhängig wäre; die Protokoll-Struktur ist aber das wichtige hierbei, und diese sollte sogar zwingend überall gleich sein.
Zudem wäre die Plattformabhängigkeit 'nur' auf der Steuerungsseite vorhanden, dem HMI-Projekt wäre der Kommunikationspartner ja egal.


Halt mich bitte mal auf dem Laufenden, was die weitere Entwicklung bei dir/euch angeht, interessiert mich wirklich.


Gruß, Fred

 

[nicknack123123]

Hi Fred,

hatte ich vorher noch gar nicht in Betracht gezogen, die Idee an sich gefällt mir. Allerdings haben wir in einem Unternehmensbereich bereits eine solche Lösung (hab ich irgendwie verdrängt ;-)).
Diese basiert allerdings auf einer PC-Steuerung (Realtime/Linux - Eigenentwicklung).

Allerdings wären für eine SPS noch folgende Punkte interessant:
1.) Zusätzliche Belastung der CPU um TCP/IP Kommunikation zu handlen
2.) Mehrkosten für TCP/IP Modul

Abgesehen davon wäre es eine absolut freie und maximal skalierbare HMI Lösung.

Ich werde berichten, wie es weiter geht. ;-)

Gruß,
nicknack

 

[faust]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo Peter,

die Belastung der Steuerung sollte vergleichbar mit der der Standard-Kommunikation sein (ohne Gewähr, ist nicht meine Hauptbaustelle).
Als Beispiel: In meiner alten Firma haben wir auf die beschriebene Art und Weise Postsendungsdaten von der Steuerung zum HMI übertragen und diese direkt in eine Datenbank transferiert. Pro Datensatz waren dies bis zu 500 Byte, wir haben bei Tests bis zu 40000 Datensätze/h -also 11 pro Sekunde- übertragen. Zusätzlich dazu wurden noch diverse Statuswerte ausgetauscht, diese allerdings asynchron.

Was für ein Modul meinst du? Eine Ethernet-Schnittstelle haben doch mittlerweile fast alle Steuerungen onBoard.


Gruß, Fred

 

[nicknack123123]

...
Was für ein Modul meinst du? Eine Ethernet-Schnittstelle haben doch mittlerweile fast alle Steuerungen onBoard.
...

Habe irgendwie im Kopf, dass mir z.B. AB nicht die Möglichkeit Standard TCP/IP Pakete zu versenden/empfangen, sondern nur Ethernet/IP. Hier hätte man dann wieder die Problematik mit dem Protokollstack (öffentlich/nichtöffentlich?).
Ich weiß nicht wie das bei anderen Herstellern aussieht (Siemens - ProfiNET).

Bin mir hier nicht sicher, habe ich mich noch nicht wirklich mit beschäftigt.

Gruß,
nicknack

 

[nicknack123123]

Hallo Fred,

bei uns geht die Entscheidung wohl in Richtung VisiWin. Hier bekommt man eine klassische HMI-Entwicklungsumgebung (Standardkomponenten parametrierbar). Außerdem sind Anbindungen an die gängigen Steuerungen möglich, sogar über einen Variablen-Adapter, so hat man quasi eine Übersetzungsliste für die verschiedenen Treiber. Desweiteren bekommt man eine vollständige .net-Programmierschnittstelle.

Also alles in allem denke ich eine Runde Lösung.

Gruß,
Peter