Sein Problem ist, daß der vereehrte Kollege, nebst der Ablehnung von Graph aus Gründen der Firmenphilosophie, offensichtlich auch nicht immer, oder nach Möglichkeit wahrscheinlich auch gar nicht, Siemens-Visualisierungen verwenden möchte. Da es aber bei Nichtsiemens Visus wie "Phönix zwei plus minus sinus kosinus", InTouch etc. weder vernünftige Meldungsgenerierung, noch Möglichkeiten zur Anbindung von Instanzen und FacePlates, noch irgendwelche andere Datentypen wie INT, BOOL und REAL gibt, müssen die verehrten Kollegen gezwungenermaßen im S5 Style arbeiten.
Es ist irgendwie bezeichnend, daß es immer wieder dieselbe Personengruppe ist, die regelmäßig mit umreißenden eigenentwickelten Automatisierungskonzepten um die Ecke kommt, Siemens-Panels ablehnt und verteufelt, und gleichzeitig aber selber im S5-Style wie 1982 programmiert. Zu dem umreißenden Automatisierungskonzept gehören in der Regel noch zahlreiche in C oder C++ eigengeschriebene Tools, die angeblich bei der Arbeit mit "völlig unzulänglichem Siemens-Shit" helfen sollen, sowie seltsame Excel-Tabellen mit Telefonbuch von Makros dahinter, um daraus etwa Datenbausteine zu generieren, und möglichst viel unterschiedliche bunte Hardware, die in etwa so zusammenpasst wie Ostereier und Glühwein. Alles zusammen wird dann anschließend als sehr fundierte und durchdachte Vorgehensweise verkauft.
Geschenkt, daß Hersteller darum bemüht sind, ein ganzheitliches Automatisierungskonzept aus einer Hand anzubieten, wo einzelne Komponenten miteinander interagieren, und sich gegenseitig ergänzen. Stattdessen nimmt man Fremdkomponten von seltsamsten Random-Firmen, und beschwert sich darüber daß diese nicht vernünftig mit einer 1516 CPU zusammenarbeiten wollen.
Da muss ich auch mal meinen Senf dazu geben. Du siehst die Angelegenheit meiner Meinung nach zu engstirnig.
Nicht jeder der eine der Siemens Programmierumgebungen nutzt, arbeitet in einer großen Firma bei der die Kunden die gesamte Anlage kaufen, bzw. das Anwendungsgebiet es bedingt dass sowohl Visualisierung, Steuerung und überlagerte Systeme aus ein und der selben Firma mit einem durchdachten einheitlich anwendbaren System kommen.
Was passiert zum Beispiel, wenn der Kunde weil er schon 30 dieser Panels einsetzt, lieber welche von Firma XY hätte?
Dein Ach so schönes auf Program- Alarm zugeschnittenes Meldungskonzept das so tief in der Struktur des Programms verwoben ist, kannst du dann in die Tonne treten und musst ein System außen rum programmieren.
Das System mit dem Program-ALarm ist toll und nimmt einem bei der Visuerstellung viel Arbeit ab, vor allem wenn man die Anlage X- Mal verkaufen kann, aber sobald es nicht mehr möglich ist jedes Bauteil dieser Kette zu verwenden, z.B. wenn man sich an andere Systeme anpassen muss, ist dieses System von Siemens nicht mehr verwendbar.
Wäre doch Schade wenn man einen Auftrag verliert, weil das Visupanel nicht zum Automatisierungskonzept passt.
In meinem Arbeitsumfeld kommt es z.B. in 50% der Fällen vor, dass die Kunden bereits eine Visualisierung haben, die sie gerne weiterbenutzen würden. Ich hatte auch schon Kunden, die uns vorgeschrieben haben, dass wir die Anlage mit Step7 5.5 programmieren sollen damit das Wartungspersonal nicht TIA benutzen/ lernen muss (und keine Lizenz gekauft werden muss), aber die Panels, "wegen Farbe" doch bitte die neuen sein sollten. Kann die 300er überhaupt mit TIA den Program- Alarm? Kann man den in Step 7 5.5 nutzen?
Ich habe in der kurzen Zeit die ich das bisher mache folgendes festgestellt, wenn man bei der zehnten Anlage die zehnte komplett unterschiedliche Zusammenstellung hat, sodass es keine Möglichkeit gibt, irgendwas zu Standardisieren, muss man sich andere Wege suchen um seine Effizienz zu steigern und wenn das nun deine Excel Telefonbuch Makros sind, was solls.
Wir benutzen für kleine wiederkehrende Aufgaben ein selbstgeschriebenes Tool bei der die Fehlermeldungen zusammen mit dem Triggerbit aus der Steuerung in eine Liste eingetragen werden. Aus der Liste kommen dann die DBs als Quelle raus (mit Fehlermeldungstext als Kommentar) die die Störmeldungs- Schnittstelle zum Visupanel darstellen, zusammen mit einer Importliste der Störmeldungen die von TIA Portal oder WinCC flex oder WinCC importiert werden kann. Der Baustein der das Befüllen der Stör- DB's übernimmt kann auch aus dem Tool geholt werden, muss aber nicht.
Bei dieser Verwendung kann ich im Supportfall, wenn ich hunderte KM weit weg sitze (manchmal auch auf der anderen Seite der Erde) ohne Panel zu haben direkt in der Schnittstelle sehen, welche Störungen gerade aktiv sind. Kann ich das mit den Program- Alarm auch? Da ich das noch nicht getestet habe, wäre es nett wenn mir darauf einer eine Antwort geben könnte.
Falls die vom Kunden gewünschte Visu ein anderes Importformat will, kann ich diese Listen auch noch händisch anpassen, sodass ich nicht jede der Xtausend Meldungen von Hand eintragen muss.
Das mag S5 Style sein und auch dem entsprechen worüber du dich aufregst, aber das ist flexibel und direkt an den Kundenwunsch anpassbar.
Wie schon gesagt, ich weigere mich anzuerkennen, einen Auftrag zu verlieren weil der Kunde sich X wünscht, mein Automatisierungskonzept aber so eingefahren ist, dass ich nicht reagieren kann.
Und bevor jetzt jemand schreit " das gibts nicht, das glaub ich nicht", glaubt es, ich war dabei als es einmal daran scheiterte weil eine zusätzliche Meldungslampe auf der anderen Hallenseite nicht mit dem Automatisierungskonzept vereinbar war.
Ich hätte das Ding einfach händisch im Programm eingebaut, aber der Standard war ja heilig und sah nur einen einzigen Ausgang als Meldungsausgang vor.
Natürlich war die jetzt nicht ausschlaggebend für die Nicht-vergabe des Auftrags, aber eine Firma die so engstirnig und eingefahren ist, dass schon einfachste Änderungen nicht mehr möglich sind, wer will sich denn mit dieser Firma rumschlagen.
€dit: Sagtmal, seit wann werden denn ä ö ü nicht mehr richtig dargestellt? Oder liegt das wiedermal nur an meinem Browser?
) verstanden, zu dieser Diskussion hier eine Frage:
