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

Seite 5 von 6 ErsteErste ... 3456 LetzteLetzte
Ergebnis 41 bis 50 von 56

Thema: Tipps zur Standardisierung der Programmierung

  1. #41
    Registriert seit
    16.10.2012
    Beiträge
    611
    Danke
    47
    Erhielt 24 Danke für 19 Beiträge

    Standard


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    Zitat Zitat von ducati Beitrag anzeigen
    Nun ja, ich kenne zwar die Hintergründe von Dracos Standard nicht, aber ich vermute, er wurde nicht erst letztes Jahr erstellt. Stammt also aus einer Zeit, als SCL und TON etc. noch nicht so "in" waren.
    1982 wahrscheinlich. Schätze mal, daß sich seitdem auch nicht viel verändert hat.
    Und wenn ein Standard erstmal in xxx Anlagen eingesetzt wurde, muss man schon sehr gute Gründe vorbringen, um ihn ueber den Haufen zu werfen.
    Fortschreitender geschäftlicher Schaden für die gesamte Firma wäre da mal so ein Grund.
    Nur mal so als Denkanstoss...
    Wenn man deinen Ausführungen folgt, dann dürften wir im Serienmaschinenbau keine anderen Standards mehr vorfinden. Denn die Anfänge sind in der Regel ja nicht gestern gelegt worden.
    Nebenbei hat der beschriebene Standard natuerlich auch Vorteile, wie hier im Forum schon oeffters diskutiert wurde...
    Das ist jetzt hoffentlich nicht dein Ernst? Es ist kein Standard, sondern ein schlechter Scherz.

    Der einzige Vorteil davon ergibt sich für einen kleinen Haufen betagter Mitarbeiter, die sich kurz vor der Rente ihre Ruhe auf Kosten der gesamten Firma erkauft haben. Denn mit so einer Vorgehensweise kostet jedes Projekt locker mal das Doppelte davon, wie die Investitionen beim Einsatz von zeitgemäßen Mitteln ausfallen würden. Ich bin zwar kein Fachmann im Unternehmensconsulting, aber ich schätze das mal so. Und dieser Müll ist hinterher auch für nichts zu gebrauchen, es ist nicht migrierbar und nicht editierbar, zumindest nicht für Leute die keine S5 mehr programmiert haben.

  2. #42
    Registriert seit
    13.10.2007
    Beiträge
    11.537
    Danke
    2.648
    Erhielt 2.967 Danke für 2.030 Beiträge

    Standard

    Zitat Zitat von Draco Malfoy Beitrag anzeigen
    Ich bin zwar kein Fachmann im Unternehmensconsulting, aber ich schätze das mal so. Und dieser Müll ist hinterher auch für nichts zu gebrauchen, es ist nicht migrierbar und nicht editierbar, zumindest nicht für Leute die keine S5 mehr programmiert haben.
    Anschließend bis du das Kücken in der Firma, dann wird es aber Zeit das du dir
    von den Dinosauriern, noch ein paar Kniffe aus der S5 Zeit zeigen lässt. Ansonsten
    wird es irgendwann schwer für dich, wenn die alten in Rente gehen und ein Kunde
    hat ein Problem mit einer Anlage.

    Aber irgendwie verstehe ich dich, ich bekomme auch noch jedem Tag Programme
    von Kollegen auf den Tisch, deren Struktur aus DB11 und DB12 für S5 Zeiten bzw.
    Zählern ist, zusätzlich KOP Programm, deren Verkettung aus schlecht bzw. undokumentierten
    Merkern (M 1.0 mit Symbol M 1.0) besteht, die nicht auf 2x 24" nicht darstellbar sind.

    Gut das ich mit S5 aufgewachsen bin.
    - - -
    Wer als Werkzeug nur einen Hammer hat, sieht in jedem Problem einen Nagel.

  3. #43
    Registriert seit
    09.08.2006
    Beiträge
    3.155
    Danke
    774
    Erhielt 558 Danke für 466 Beiträge

    Standard

    Nunja, wie gesagt, ich kenne Euren Standard nicht und die Hintergründe und konkreten Anforderungen schon garnicht. Geh doch einfach mal zu Deinem Chef und Teile ihm Deine hier aufgeführten Argumente mit Wenn er kein Idiot ist, sollten ihn die 50%ige Programmierzeiteinsparung schon aufhorchen lassen. Evtl. darft Du das dann im nächsten Projekt beweisen
    Zu dem beschriebenen Programmierstil, ich sagte nicht, dass er gut ist, sondern das er AUCH Vorteile besitzt. Natuerlich auch Nachteile, was man gegeneinander abwaegen sollte. Und wie RN schon anmerkte, die Altanlagen loesen sich mit dem neuen Standard nicht in Luft auf, d.h. Du musst dann 2 Programmierstile beherrschen und verstehen um auch Altanlagen warten und erweitern etc. zu koennen. Es gibt immer mehrere Sichtweisen.
    Ansonsten bin ich mal davon ausgegangen, dass Deine Kollegen nicht ganz doof sind, was natürlich nicht stimmen muss

  4. #44
    Registriert seit
    16.10.2012
    Beiträge
    611
    Danke
    47
    Erhielt 24 Danke für 19 Beiträge

    Standard

    Ich habe da für mich eine Lösung gefunden und arbeite nicht nach diesem Standard. Die Leitung drückt da ein Auge zu. Außerdem gehöre ich offiziell nicht zu dieser Abteilung. Von den anderen Kollegen, die nicht aus dieser speziellen Abteilung sind, ist auch kaum jemand bereit, die Vorgehensweisen zu übernehmen.

    Aber des ist zum Teil schon harter Tobak, wenn ich sehe wie in einer Anlage mit dreistelliger Anzahl an Proportionalventielen, einem Haufen komplexer vorgesteuerter überlagerter Regler und hydraulischen Leistungen von mehreren Megawatt, mit einem hochverfügbaren Rack und 417H CPU, die Software so aufgebaut ist, daß noch nichtmals BLOCKMOVE Befehle eine Anwendun finden. Datenblöcke werden z.B. so kopiert:

    Code:
    L DB100 DBD0
    T DB200 DBD0
    L DB100 DBD4
    T DB200 DBD4
    ...
    Ich habe für mich entschieden, dass

    - Bibliotheksbausteine die ich verwende vorzugsweise in SCL geschrieben werden,
    - nur lokale Datenhaltung verwenden wird,
    - die Anzahl der DBs möglichst klein gehalten wird,
    - für die Datenhaltung möglichst sinnvolle Strukturen benutzt werden,
    - Schrittketten im Graph geschrieben werden,
    - Komplxe Reglerstrukturen aus dem CFC kommen, um den Signalfluss grafisch nachvollziehen zu können.

  5. #45
    Registriert seit
    09.08.2006
    Beiträge
    3.155
    Danke
    774
    Erhielt 558 Danke für 466 Beiträge

    Standard

    Wie ich das verstehe verwendest Du klassisch KOP/FUP + Graph + CFC in einem Projekt? Das KOENNTE einem Nichteingeweihtem aber auch gehöriges Grübeln bereiten. Vor allem wenn er kein Graph, SCL und CFC auf seinem PG hat Also immer mehrere Sichtweisen...

  6. #46
    Registriert seit
    16.10.2012
    Beiträge
    611
    Danke
    47
    Erhielt 24 Danke für 19 Beiträge

    Standard

    Zitat Zitat von ducati Beitrag anzeigen
    Wie ich das verstehe verwendest Du klassisch KOP/FUP + Graph + CFC in einem Projekt? Das KOENNTE einem Nichteingeweihtem aber auch gehöriges Grübeln bereiten. Vor allem wenn er kein Graph, SCL und CFC auf seinem PG hat Also immer mehrere Sichtweisen...
    Bei der Kompexität der Syteme wäre es illusorisch, zu erwarten, daß man die Problemstellungen mit Mitteln von KOP/FUP alleine lösen kann. Wenns nach mir ginge, würde ich auch auch gleich in Richtung PCS7 gehen und die Programmierer verpflichten, bibliotheksfähige Bausteine so zu erstellen, daß die PCS7-fähig sind.

    Aber soweit muss man gar nicht gehen, es gibt fertigungstechnische Anlagen wo man das nicht braucht. Wichtig ist, daß man am Puls der Zeit bleibt und im Unternehmen das Bestreben existiert, möglicht die optimalen Produkte und zeitgemäße Mittel für die Umsetzung der Projekte zu bestimmen und mitzunehmen, anstatt im vorletzten Jahrhundert zu verharren.
    Geändert von Draco Malfoy (01.10.2016 um 19:37 Uhr)

  7. Folgende 2 Benutzer sagen Danke zu Draco Malfoy für den nützlichen Beitrag:

    achimE (01.10.2016),de vliegende hollander (01.10.2016)

  8. #47
    Registriert seit
    17.03.2011
    Beiträge
    8
    Danke
    5
    Erhielt 1 Danke für 1 Beitrag

    Standard

    Zitat Zitat von ducati Beitrag anzeigen
    Nun ja, ich kenne zwar die Hintergründe von Dracos Standard nicht, aber ich vermute, er wurde nicht erst letztes Jahr erstellt. Stammt also aus einer Zeit, als SCL und TON etc. noch nicht so "in" waren. Und wenn ein Standard erstmal in xxx Anlagen eingesetzt wurde, muss man schon sehr gute Gründe vorbringen, um ihn ueber den Haufen zu werfen. Nur mal so als Denkanstoss... Nebenbei hat der beschriebene Standard natuerlich auch Vorteile, wie hier im Forum schon oeffters diskutiert wurde...
    Also ich glaube das kann man nicht Standard nennen sondern Programmierstil. Ich kann Draco voll verstehen. Bei mir wurde mit "verloren gegangener Kreativität" gegen einen Standard argumentiert.
    Wie Instandhaltung, nachfolgende Kollegen damit zurechtkommen? ..... Und alles schön mit Merkern dafür keine internen Variablen und dann noch M1.0 = "M1.0"

    Wie auch immer, ich glaube lieber einen schlechten Standard, als gar keinen.

    Aber scheinbar scheint ein Nicht-Vorhanden-Sein eines Standards, mehr die Regel als die Ausnahme zu sein.

    Wobei doch alles so ähnlich ist: die meisten Maschinen bestehen aus Betriebsarten, Motoren, Zylindern, Türen, Knöpfen, einem Roboter?, einem HMI, .....

    Unter einem Standard verstehe ich übrigens nicht was in Stein gemeißeltes, sondern eine stetige Weiterentwicklung und Erweiterung.

    Wobei es nicht nur die "alten Hasen" sind, die bremsen. Es scheint eher eine Frage zu sein wie weit der gewollte Standard dem eigenen Programmierstil entgegenkommt. Da sollte aber seit den Programmierempfehlungen von Siemens kein Diskussionsbedarf mehr bestehen.
    Geändert von achimE (01.10.2016 um 20:10 Uhr)

  9. #48
    Registriert seit
    13.10.2007
    Beiträge
    11.537
    Danke
    2.648
    Erhielt 2.967 Danke für 2.030 Beiträge

    Standard

    So was ich mal hier festhalten möchte, ein guter Programierstiel oder Standard, hat nichts mit
    dem Alter zu tun oder ob da die Modernsten Sprachen verwendet wird.
    Ein schlechter Programmierstil kann auch sein wenn man einfache Aufgaben, wie Binäre
    Verknüpfungen, in komplexen Anlagen, unbedingt in Hochsprache machen möchte,
    mit Hornbrille und Pikel im Gesicht !!!
    Dann ist das Programm schlecht und Puperitäre Jüngling hat wegen seines Ausehen keinen Stil.
    - - -
    Wer als Werkzeug nur einen Hammer hat, sieht in jedem Problem einen Nagel.

  10. #49
    Registriert seit
    22.03.2007
    Ort
    Detmold (im Lipperland)
    Beiträge
    11.095
    Danke
    389
    Erhielt 2.270 Danke für 1.894 Beiträge

    Standard

    Zitat Zitat von rostiger Nagel Beitrag anzeigen
    ... ein guter Programierstiel oder Standard, hat nichts mit
    dem Alter zu tun oder ob da die Modernsten Sprachen verwendet wird.
    Ein schlechter Programmierstil kann auch sein wenn man einfache Aufgaben, wie Binäre
    Verknüpfungen, in komplexen Anlagen, unbedingt in Hochsprache machen möchte ...


    Ich würde auch sagen, das Standard heutzutage mit guter Strukturierung und guter Dokumentation zu definieren ist.
    Auch dazu gehören würde m.E. z.B. das gleiche Sachen auch immer gleich heißen.
    Was ich sehr gerne mache ist, dass ich mir für wiederkehrende Perepherie-Schnickeleien wie Zählerkarte, FU, Servo-Regler, Laser und und und eigene Bausteine erstelle, die so funktionieren, wie ich es brauche und setze ich dann natürlich auch immer wieder gerne ein. Oder innerhalb der Programmierung : ein FB für ein Aggregat oder eine Station hat immer den gleichen Innenaufbau und Bennung der verwendeten Strukturen.

    Es gibt da viele Möglichkeiten ...

    Gruß
    Larry

  11. Folgender Benutzer sagt Danke zu Larry Laffer für den nützlichen Beitrag:

    de vliegende hollander (01.10.2016)

  12. #50
    Registriert seit
    09.08.2006
    Beiträge
    3.155
    Danke
    774
    Erhielt 558 Danke für 466 Beiträge

    Standard


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    Jo... Auch wenn ich auch am liebsten immer PCS7 einsetzen wuerde, ein Standard oder ProgrammierStil ist nicht per se schlecht, nur weil er auf AWL, Merkern und Timern basiert. Wenn es wichtige Gründe dafür gibt, und er gut gemacht ist kann er im speziellen Fall sogar besser sein als was auch immer...

Ähnliche Themen

  1. Tipps zur Fehlersuche...
    Von petzi im Forum Simatic
    Antworten: 14
    Letzter Beitrag: 03.06.2010, 06:26
  2. Antworten: 21
    Letzter Beitrag: 13.04.2010, 19:03
  3. Antworten: 6
    Letzter Beitrag: 24.11.2009, 10:20
  4. Antworten: 4
    Letzter Beitrag: 24.09.2006, 11:18
  5. Brauche Tipps zur Regelstrategie Klima
    Von Jo Sol im Forum Programmierstrategien
    Antworten: 1
    Letzter Beitrag: 30.07.2006, 09:38

Stichworte

Lesezeichen

Berechtigungen

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