Konzept aber welches?

[rogseut]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo, wir möchten im Zuge der Umstellung auf 1500er Steuerungen unsere alten Zöpfe abschneiden und neue Wege gehen. Wir bauen immer ähnliche aber nie gleiche Maschinen.

Wir unterteilen die Maschine in Funktionen und Teilfunktionen. z.B. Materialzuführung als Funktion mit Teilfunktion Motor, Produkterkennnung, Produktzählen.
Die Teilfunktionen werden sich öfter in der Maschine wiederholen und als Bibliotheksbaustein geführt. Das heißt wir setzen die Funktion aus Teilfunktionen zusammen. Später sollen diese als kopiervorlagen mit in die Bibliothek.

Normalerweise speichern wir die dazugehörigen Einstellwerte im Panel als Rezeptur. Störmeldungen werden als einzelne Bits ausgegeben.

Zu jeder Funktion soll es einen Bildbaustein geben der über einen UDT mit dem Baustein verbunden wird.

Jetzt wäre es schön eine Maschine anhand der Funktionen aus den Kopiervorlagen einfach zusammen kopieren zu können inkl. HMI, Störmeldungen Rezeptwerte usw. Gibt es eine Möglichkeit das alles zu bündeln und "einfach" ins Projekt zu ziehen und fertig? Ohne das an verschiedenen stellen Hand angelegt werden muss.

 

[DennisBerger]

DB(s) anlegen für einzelne Meldungen die immer gleich sind (abweichende neu dazu kommende werden ganz nach hinten in wincc projektiert) dann nur noch mit den richtigen Triggern im Programm beschalten werden, Rezepturen als csv datei speichern und die Parameter darüber reinladen.

weitere tipps kommen sicherlich noch

 

[rostiger Nagel]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich würde mich von den Bitmeldungen lösen und ProgrammAlarm nutzen.

 

[roboticBeet]

Ich würde mich von den Bitmeldungen lösen und ProgrammAlarm nutzen.

dito. Wenn man sich keine Gedanken macht, hat man zwar durchaus Performance-Themen, es gibt aber einige smarte Implementierungen, bspw. durch bedingte Aufrufe. Dazu gibts hier im Forum auch einige Threads mit Beispielen.
Durch ProgramAlarm hast du dann auch künftig gute Erweiterungsmöglichkeiten, bspw. durch Nutzung von OPC UA Alarms & Conditions. Mit Bitmeldungen bekommst du deine Alarme nämlich nicht in die OPC UA Schnittstelle.

Eine andere gute Alternative wäre ProDiag, das kostet aber extra (für jedes Projekt und abhängig der Meldungsanzahl) und ist noch nicht für WinCC Unified verfügbar. Da gibt es auch einige tolle Diagnosefunktionen. Ist in der Einrichtung aber zunächst ungewohnt. ProDiag wird mehr parametriert denn programmiert.

 

[DennisBerger]

das muss ich mir auch mal anschauen mit dem ProgrammAlarm, kenn ich so noch nicht.

 

[faust]

Zuviel Werbung?
-> Hier kostenlos registrieren

Guten Morgen.

Ein paar Fragen vorab:

1. Wie muss man sich "Wir bauen immer ähnliche aber nie gleiche Maschinen." genau vorstellen? Eigentlich immer die gleiche Reihenfolge von Funktionen und Teilfunktionen, es werden nur nicht immer alle eingesetzt, oder immer komplett unterschiedliche Zusammenstellungen?
2. Wer nimmt die Maschinen in Betrieb? Ein Servicetechniker/Inbetriebnehmer oder der Entwickler/Programmierer?
3. Welche HMI-Hard- und Software soll zum Einsatz kommen?

Ich bin seit jeher ein Freund von strikter Trennung der Gewerke HMI/Steuerung/Safety/Antriebe, wir sind bei uns mit diesem Konzept bisher am besten gefahren:

• Das HMI-Projekt wird von Spezialisten (u.a. mir) bearbeitet, diejenigen können sich ganz auf dieses mittlerweile sehr umfangreiche Gebiet konzentrieren. Es muss dann auch nicht ein Automatisierungsprodukt (z.B. TIA ) eingesetzt werden!
• Steuerung/Safety/Antriebe werden durch Automatisierer gemeinsam projektiert, wobei es ob der Gewerkeaufteilung keine allzu großen Abhängigkeiten gibt (Hauptsache, die Schnittstellen passen.).
• Es gibt keine Gewerk-Vermischung, wie z.B. Landessprachen-Handling als HMI-Thema in einem SPS-Projekt.

Aufgrund des Aufbaus unserer Maschinenfamilien (nämlich wie im ersten Teil von Frage 1 beschrieben) arbeiten wir immer mit 100%-Projekten, d.h. in den jeweiligen Gewerken der einzelnen Familien sind IMMER ALLE Bereiche/Module/Stationen/Funktionen enthalten, diese können dann ZUR LAUFZEIT am HMI konfiguriert (besser: aktiviert bzw. deaktiviert) werden. Dies hat für uns folgende Vorteile:

• Die jeweiligen Entwicklerteams können recht einfach unterschiedliche Stände vergleichen, auch das Thema Versionsverwaltung wird m.M.n. besser unterstützt, da kein umständliches Bibliotheks-Handling.
• Abhängigkeiten von Bereichen/Modulen/Stationen/Funktionen lassen sich (quasi) einmalig projektieren und werden -da eine Software ja immer nur "wächst" dadurch immer berücksichtigt (werden nicht vergessen).
• Inbetriebnahmen werden -sofern nicht z.B. Modul-Neuentwicklungen erstmalig implementiert sind-durch Nicht-Entwickler durchgeführt.

Natürlich ist diese Darstellung nicht vollständig und teilweise idealisiert, dennoch fahre ich/fahren wir damit ganz gut.


Gruß, Fred

 

[rostiger Nagel]

Ich bin seit jeher ein Freund von strikter Trennung der Gewerke HMI/Steuerung/Safety/Antriebe, wir sind bei uns mit diesem Konzept bisher am besten gefahren:

• Das HMI-Projekt wird von Spezialisten (u.a. mir) bearbeitet, diejenigen können sich ganz auf dieses mittlerweile sehr umfangreiche Gebiet konzentrieren. Es muss dann auch nicht ein Automatisierungsprodukt (z.B. TIA ) eingesetzt werden!
• Steuerung/Safety/Antriebe werden durch Automatisierer gemeinsam projektiert, wobei es ob der Gewerkeaufteilung keine allzu großen Abhängigkeiten gibt (Hauptsache, die Schnittstellen passen.).
• Es gibt keine Gewerk-Vermischung, wie z.B. Landessprachen-Handling als HMI-Thema in einem SPS-Projekt.

Das Konzept ist richtig, birgt aber eine große Gefahr.
Wenn der HMI-Mann oder Antriebs-Mann jeweils nur
einer ist. Wird der Krank oder scheidet aus dem Betrieb
aus, kann es ganz schön brenzlig für den Betrieb werden.

 

[ducati]

Das Konzept ist richtig, birgt aber eine große Gefahr.
Wenn der HMI-Mann oder Antriebs-Mann jeweils nur
einer ist. Wird der Krank oder scheidet aus dem Betrieb
aus, kann es ganz schön brenzlig für den Betrieb werden.

Nicht nur für den Betrieb sondern auch für alle bisherigen Kunden...

 

[faust]

Zuviel Werbung?
-> Hier kostenlos registrieren

@rostiger Nagel und @ducati:

Ihr habt beide recht, jedoch ist dies ja eigentlich keine Schwäche des Konzepts.

Vielmehr ist der AG in der Pflicht, dieses Szenario nicht eintreten zu lassen (Personalplanung).
Außerdem besteht die Gefahr ja eigentlich ständig, denn andere Konzepte müssen auch entwickelt und gewartet werden. Und wir wissen alle, wie gerne auch Generalisten ihr jeweils eigenes Codesüppchen kochen ...

 

[Ing_Lupo]

Hallo

ich würde mir Gedanken machen ob auch verschiedene SPS und Panelhersteller abgedeckt werden sollen/müssen.
Was nützt ein Konzept für Siemens wenn der nicht liefern kann ?

Oder ist das bei Euch keine Fragestellung ?

 

[de vliegende hollander]

ich sage es mal gern so;
Mach dir die backsteinen und bau dir immer das Haus neu zusammen.
Du weißt selbst aber am Beste ob du Prefab Teilen machen kannst. Das Badezimmer, Keller Küche als 1 Teil vorbereiten..

ich würde eher ein Vorlageprogramm machen statt Bausteine in ein Bibliothek.
Das vorlageprogramm enthällt die Grundstruktur die du immer hast.
Z.b. Bedientasten wie ACK, die wieder als vorbelegtes Attribute im Standart Bausteinen benutzt wird. u.s.w.

Wir haben Bausteinen für Analogwerten, Antrieben und so weiter. jeweils mit UDT HMI Anbindung Bildbaustein.

 

[faust]

Zuviel Werbung?
-> Hier kostenlos registrieren

Wir haben Bausteinen für Analogwerten, Antrieben und so weiter. jeweils mit UDT HMI Anbindung Bildbaustein.

Und wie macht ihr das dann mit der Übersetzung der HMI-Texte in andere Sprachen?
Soweit ich weiß muss man ja bei Siemens die Bildbaustein-Bibliothek UND das HMI-Projekt separat behandeln - also alles zweimal machen ...
Lasse mich gerne eines besseren belehren.

 

[rostiger Nagel]

Und wie macht ihr das dann mit der Übersetzung der HMI-Texte in andere Sprachen?
Soweit ich weiß muss man ja bei Siemens die Bildbaustein-Bibliothek UND das HMI-Projekt separat behandeln - also alles zweimal machen ...
Lasse mich gerne eines besseren belehren.

Das mit dem Übersetzen bei Siemens, ist aber auch total unpraktikabel.
Zum einen die Auswahlliste zum übersetzen ist eine Katastrophe, das
weiß man nicht was man da wirklich auswählt.
Zum anderen bekommt man da Monster Excel Listen, wo ein Übersetzer
schon keine anderen Aufträge mehr annehmen muss und eine Luxusreise
buchen kann.
Zum anderen währe es Sinnvoller wenn die Texte als CSV Datei auf dem
Panel erreichbar währen, so das der Kunde im Nachhinein, die übersetzung
überarbeiten kann. Oder prüft einer von euch nach was da übersetzt wurde
wenn es in Chinesisch oder Italienisch zurück bekommt?

 

[de vliegende hollander]

Und wie macht ihr das dann mit der Übersetzung der HMI-Texte in andere Sprachen?
Soweit ich weiß muss man ja bei Siemens die Bildbaustein-Bibliothek UND das HMI-Projekt separat behandeln - also alles zweimal machen ...
Lasse mich gerne eines besseren belehren.

Übersetz wird den Bildbaustein. Dies ist separat. Also sind die Projektsprachen nochmal angelegt.
Dann gibt es auch da HMI Projekt selber ja.

ich weißso schnell nicht ob die im gesamt projekttexte ale auftauchen

 

[de vliegende hollander]

Zuviel Werbung?
-> Hier kostenlos registrieren

Monster Excel Listen

Joa, grausam..

 

[rostiger Nagel]

gerade mal von so einen kleinen Projekt aufgemacht.
8000 Zeilen, so ein Blödsinn da findet man doch nichts wieder.
Wenn Sie es wenigstens in mehrere Taps aufteilen würden.

 

[faust]

Zum anderen bekommt man da Monster Excel Listen, ...

Man kann die Textarten für den Export auswählen und so schon einiges loswerden.

ENDLICH -gerechnet seit Erscheinungsdatum von ProTool (Steinzeit) bzw. WinCC Flexible (Mittelalter) bzw. TIA (alt)- kann man auch mehr als eine Zielsprache gleichzeitig exportieren!! Ich bin fast in Tränen ausgebrochen...

Zum anderen währe es Sinnvoller wenn die Texte als CSV Datei auf dem
Panel erreichbar währen, so das der Kunde im Nachhinein, die übersetzung
überarbeiten kann.

Das würde ja bedeuten, dass Siemens sein Paradigma "Kompilieren des HMI-Projektteils in EINE Datei" aufgeben müsste. Schwer vorstellbar.

Oder prüft einer von euch nach was da übersetzt wurde
wenn es in Chinesisch oder Italienisch zurück bekommt?

Soweit möglich tue ich dies tatsächlich; alleine schon um meinem Vorgesetzten zu zeigen, welcher Aufwand dahinter steckt.
Im Nachhinein sind nämlich alle froh, wenn sich der Kunde NICHT über manche Übersetzung schlapplacht.


BTW: Ich hantiere aktuell mit ca. 35000(!) Zeilen, sind aber auch eine Menge Leertexte und Reserve-Bitmeldungen dabei.

 

[rostiger Nagel]

Zuviel Werbung?
-> Hier kostenlos registrieren

Soweit möglich tue ich dies tatsächlich; alleine schon um meinem Vorgesetzten zu zeigen, welcher Aufwand dahinter steckt.
Im Nachhinein sind nämlich alle froh, wenn sich der Kunde NICHT über manche Übersetzung schlapplacht.

Fred, ich meine jetzt schon echtes Chinesisch, nicht Fachchinesisch,
aber wer kann der kann

 

[faust]

Fred, ich meine jetzt schon echtes Chinesisch, nicht Fachchinesisch,
aber wer kann der kann

Ich hatte das schon richtig verstanden , bei meiner Aussage aber ehrlicherweise das auch erwähnte Italienisch und vielmehr alle Sprachen gemeint, die noch einigermaßen lesbar sind (Asiatische/arabische/kyrillische etc. Schriftzeichen gehören in meinem Fall nicht dazu).

Aber Spass beiseite (und vielleicht auch etwas back-to-topic):
Das HMI-Thema ist eines, dass bei der Suche nach dem richtigen Software-Konzept eine besondere Rolle einnimmt, da m.M.n. einige Automatisierungs-Entwicklungsumgebungen (z.B. TIA) gerade dort Nachholbedarf haben (Stichwörter: Modularisierung, Datenhandling, Benutzerverwaltung, Visu-Controls und deren Möglichkeiten/Einschränkungen).

Ich würde (und werde!) bei der Neukonzeptionierung einer Software nur noch die für den jeweiligen Anwendungsfall optimale Entwicklungsumgebung einsetzen - das wird bei den HMIs definitiv nicht TIA sein.


Zumal noch ein anderer Grund hinzukommt: Lizenzkosten!
Einige Hersteller lassen sich ihre Tools (und schlimmer: die Laufzeitumgebungen pro HMI) ganz schön teuer bezahlen.
Wir haben intern eine Aufstellung angefertigt, die u.a. zum Ergebnis hatte, dass bei Einsatz von Siemens-Software (WinCC Advanced RT) für bestimmte Maschinenfamilien Mehrkosten von ca. 160.000,- € pro Jahr(!) gegenüber dem Einsatz von freien Tools (z.B. HTML5, JavaScript) entstehen - und dabei sind die eigentlichen Software-Entwicklungskosten noch nicht einmal berücksichtigt.

 

[faust]

Jetzt könnte man natürlich (wieder) anmerken:
"Die erwähnten Programmiersprachen können unsere Leute nicht, also müssten sie geschult werden, oder wir müssen uns Spezialisten von außen holen, dann können wir den Code selbst nicht pflegen, keine Zeit/kein Geld für soetwas, ..." (Blah-blah-blah).

Ich bleibe aber bei meiner Aussage von Post #9:
Das ist keine Konzeptschwäche, sondern Sache des AGs.
Und für 160.000,- € PRO JAHR kann man schon gut was an Personal und deren Schulung auf die Beine stellen ...