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

Seite 2 von 4 ErsteErste 1234 LetzteLetzte
Ergebnis 11 bis 20 von 32

Thema: HMI Software

  1. #11
    Registriert seit
    13.10.2007
    Beiträge
    12.027
    Danke
    2.784
    Erhielt 3.268 Danke für 2.156 Beiträge

    Standard


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    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.
    - - -
    Wer als Werkzeug nur einen Hammer hat, sieht in jedem Problem einen Nagel.

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

    Standard

    Zitat Zitat von rostiger Nagel Beitrag anzeigen
    ...
    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?


    Zitat Zitat von rostiger Nagel Beitrag anzeigen
    ...
    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

  3. #13
    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

    ...
    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

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

    Standard

    Hallo nicknack,

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


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


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

  5. #15
    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,

    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

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

    Standard

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

  7. #17
    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

    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
    Geändert von nicknack123123 (02.03.2015 um 22:22 Uhr)

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

    Standard

    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

  9. #19
    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

    ...
    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

  10. #20
    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


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

Ä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
  •