Zuviel Werbung? - > Hier kostenlos beim SPS-Forum registrieren

Seite 1 von 4 123 ... LetzteLetzte
Ergebnis 1 bis 10 von 32

Thema: HMI Software

  1. #1
    Registriert seit
    26.02.2015
    Beiträge
    11
    Danke
    0
    Erhielt 0 Danke für 0 Beiträge

    Standard


    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
    Zitieren Zitieren HMI Software  

  2. #2
    Registriert seit
    06.04.2010
    Ort
    Hamburg
    Beiträge
    124
    Danke
    12
    Erhielt 16 Danke für 14 Beiträge

    Standard

    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

  3. #3
    Registriert seit
    22.03.2007
    Ort
    Detmold (im Lipperland)
    Beiträge
    11.726
    Danke
    398
    Erhielt 2.401 Danke für 2.001 Beiträge

    Standard

    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

  4. #4
    nicknack123123 ist offline Neuer Benutzer
    Themenstarter
    Registriert seit
    26.02.2015
    Beiträge
    11
    Danke
    0
    Erhielt 0 Danke für 0 Beiträge

    Standard

    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

  5. #5
    Registriert seit
    22.03.2007
    Ort
    Detmold (im Lipperland)
    Beiträge
    11.726
    Danke
    398
    Erhielt 2.401 Danke für 2.001 Beiträge

    Standard

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

  6. #6
    nicknack123123 ist offline Neuer Benutzer
    Themenstarter
    Registriert seit
    26.02.2015
    Beiträge
    11
    Danke
    0
    Erhielt 0 Danke für 0 Beiträge

    Standard

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

  7. #7
    Registriert seit
    17.10.2007
    Beiträge
    263
    Danke
    5
    Erhielt 52 Danke für 48 Beiträge

    Standard

    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

  8. #8
    nicknack123123 ist offline Neuer Benutzer
    Themenstarter
    Registriert seit
    26.02.2015
    Beiträge
    11
    Danke
    0
    Erhielt 0 Danke für 0 Beiträge

    Standard

    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

  9. #9
    Registriert seit
    13.10.2007
    Beiträge
    12.037
    Danke
    2.789
    Erhielt 3.271 Danke für 2.158 Beiträge

    Standard

    Zitat Zitat von faust Beitrag anzeigen
    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

    Zitat Zitat von nicknack123123 Beitrag anzeigen
    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.
    - - -
    Wer als Werkzeug nur einen Hammer hat, sieht in jedem Problem einen Nagel.

  10. #10
    Registriert seit
    17.10.2007
    Beiträge
    263
    Danke
    5
    Erhielt 52 Danke für 48 Beiträge

    Standard


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    @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

Ähnliche Themen

  1. Software Engineer (m/w) – HMI Development
    Von ictjob.de im Forum Suche - Biete
    Antworten: 0
    Letzter Beitrag: 29.11.2012, 10:37
  2. Antworten: 5
    Letzter Beitrag: 26.01.2012, 08:06
  3. VBS in einer HMI-Software
    Von HSThomas im Forum HMI
    Antworten: 6
    Letzter Beitrag: 17.03.2007, 10:52
  4. HMI Software
    Von Maier im Forum HMI
    Antworten: 5
    Letzter Beitrag: 02.07.2006, 15:02
  5. suche für C7-613 HMI Software
    Von kljosc im Forum Suche - Biete
    Antworten: 0
    Letzter Beitrag: 13.02.2005, 12:16

Stichworte

Lesezeichen

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •