Firmen-Norm

Zuviel Werbung?
-> Hier kostenlos registrieren
So so ein Fehler ist in der Regel aber in Sekunden gefunden und behoben. Kann das mit einer Struktur wirklich nicht passieren ? Auch bei Erweiterungen nicht ?
Wenn die Struktur mit z.B. FILL auf 0 gesetzt wird und mit BLKMOV kopiert wird, gibt es bei Erweiterungen keine solchen Fehler.
 
Ist das nicht eher so, wie ein Haus vor dem Abriss noch einmal zu streichen?

Mein Programmierstil sieht anders aus, d.h. es gibt keinen Abriss. Es muss möglich sein, den gleichen Quellcode in der alten wie in der neuen Version zu verwenden. Dazu sind vielleicht einige Anpassungen nötig, und der Verzicht auf neue vendor-lock-in Features.

Der Hersteller hat natürlich ein entgegengesetztes Interesse. Ein Update alter Maschinen mit neuen Features und neuer Software sollte so beeinflusst werden, dass möglichst viel Umsatz mit neuen SPS und Zubehör erzielt wird.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Standards sind schlecht, wenn sie guten Programmierstil verhindern, oder schlechten erzwingen.

Meinst du das ernst?

Edit: Leider haben wir ja einen Standard für Steckdosen sonst könnten wir uns in Europa an 10.000 "guten" Steckdosenlösungen erfreuen und müßten nicht immer mit der einen "schlechten" leben...
 
Zuletzt bearbeitet:
Standards sind schlecht, wenn sie guten Programmierstil verhindern, oder schlechten erzwingen.

Meinst du das ernst?

Edit: Leider haben wir ja einen Standard für Steckdosen sonst könnten wir uns in Europa an 10.000 "guten" Steckdosenlösungen erfreuen und müßten nicht immer mit der einen "schlechten" leben...

Den möchte ich mich mal ausdrücklich anschließen, das ist doch geschwafel, weil man weiterhin nicht über den Tellerand schauen möchte.

Warum muss ein Baustein den man zum Ansteuern eines Servos nimmt, z.b. der von SEW, in jeden Programm anders aus sehen.
Weil auch Merker angesprochen werden, wo es im Prinzip nichts gegen zu sagen gibt, warum können da nicht einige Merker, wie
zb. das Taktmekerbyte nicht immer das gleiche sein, mit den selbigen Kommentaren und Symbolen.

Auch das ist FIRMEN-NORM....
 
Ein Programmierstandard erstellt noch keine Standardbibliothek, sondern schreibt nur vor, wie sie aussehen soll, wenn es sie denn gibt.

Und selbstverständlich meine ich das ernst. Ich konnte z.B. immer sehr gut ohne einen Programmierstandard leben, der vorschreibt, dass in IF-Abfragen keine Negationen vorkommen dürfen. Wo es diese Vorschrift gibt, sind natürlich einige Workarounds nötig. Und diese stehen immer in der Gefahr, dass sie den "Geist" des Standards verletzen, was zu noch sinnloserem Code führt, um diese Tatsache zu verschleiern.

Ich brauche auch nichts, das vorschreibt, dass ein bestimmtes Byte oder sonstiges immer an der gleichen Adresse zu sein hat. Habe ich nie gebraucht. Es hat ja einen Namen ("Symbol"). Ich habe am Anfang meiner Zeit solche informellen "Standards" so lange weiter gepflegt, bis es kam, wie es kommen musste: zwei verschiedene FCs mit gleicher Nummer in einem Programm. Seitdem nicht mehr.

Und genau die, die schlechte Standards entwickeln und vorschreiben, werden sich nicht daran halten, wenn dadurch das Ergebnis noch schlechter werden kann. Eigene Beobachtung.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ich brauche auch nichts, das vorschreibt, dass ein bestimmtes Byte oder sonstiges immer an der gleichen Adresse zu sein hat. Habe ich nie gebraucht. Es hat ja einen Namen ("Symbol").
Wow, he. Hört sich ja verdammt nach God-Mode an. Aber genau da ist je das Problem.
DU brauchst es nicht, klar aber vielleicht braucht es dein Kunde?
Oder der Typ der mal was wartet/erweitert an der Anlage?
Oder ein neuer MA der was programmieren soll und keine Ahnung hat was gute/schlechte Lösungen sind?
Oder ein Zulieferant der was liefern soll und du sicherstellen willst dass das was er liefern wird auch eine gewisse ausführungstechnische Qualität hat?
Oder der der dein Programm fertig schreibt wenn dich morgen in der Früh der Blitz trifft!
Oder dein ich aus der Zukunft das nach 10 Jahren an die Anlage kommt und sich fragt wo könnte ich das damals wohl reingepackt haben!

Das sind die Gründe warum Standards Sinn machen. Und es macht keinen Sinn in der Argumentation irgendwelche theoretischen Unsinnigkeiten rauszuholen die in einem Standard drinnen stehen könnten. Das ist doch kein Argument für/gegen einen Standard. Klar könnte es den einen oder anderen Unfall verhindern wenn ich mal auf der linken Spur fahre und mal auf der rechten aber in den meisten Fällen macht es schon Sinn sich auf eine Seite zu einigen meinst du nicht?

Es ist für mich zu kurz gedacht zu sagen nur weil "ICH" das nicht brauche braucht es "NIEMAND" und deswegen ist es Unsinn.

Der Inhalt und die Reichweite eines Standards natürlich hängt von vielen Dingen ab. Aber das es Sinn macht sich auf einen gemeinsamen Nenner zu einigen steht für mich außer Frage. Und ich bin auch der Ansicht dass es besser ist je größer der gemeinsame Nenner ist.
 
Zuletzt bearbeitet:
@NRNT:
Ich habe diesen Thread auch mitgelesen und seit einiger Zeit immer schon überlegt, was man dazu (hier speziell den Statements von Drutbluck) schreiben kann. Irgendwo war ich bei ähnlichen Inhalten angekommen, wie du sie hier so schön zusammen gefasst hast.
So schön wie du hätte ich es aber nicht zu schreiben vermocht.
Deswegen mein DANKE zu deinem Beitrag.

Gruß
Larry
 
Hi,

meine symbolische Programmierung führt nicht automatisch dazu, dass es keine sichtbaren Adressen gibt (abgesehen von z.B. RSLogix 5000) oder dass sie überall unterschiedlich sind oder dass sie nicht bekannt sind.

Bei uns stehen eben (Merker-, DB-, FC-) Adressen nicht in einer "Firmen-Norm", sondern in der Symboltabelle und im Projekt. Die sind häufig tatsächlich fast immer gleich, weil ich es für sinnvoll halte, Dinge nicht ohne Grund unterschiedlich zu machen. Nur sind sie eben nicht streng normiert. Die Taktmerker sind also immer gleich nach Name, Kommentar und auch Byteadresse, aber wenn eine Kunden-Firmen-Norm oder eine importierte Bibliothek verlangt, dass das Byte verschoben wird, spricht nichts dagegen. Das Symbol zu ändern, ist etwas unangenehmer (weil das tatsächlich eine Abweichung von einer Art "Norm" sein könnte), aber auch möglich.

Und ich vermute, dass die, die solche Adressen normieren, ihre Norm auch gelegentlich ändern (müssen). Oder man hält sich nicht dran.

Addressen innerhalb DBs ändern sich durch Weiterentwicklung, Änderungen der Maschine, Kundenwünsche, weil sich die Struktur der UDTs und FBs ändert. Wenn das nicht sein dürfte, wäre Weiterentwicklung blockiert oder der Einsatz von UDTs, FBs und Arrays behindert.

So kann ich die Bedenken beantworten:
- Der Kunde hat die Adressen, sie stehen im Step7-Projekt. Globale Adressen (Symboltabelle) bleiben meistens gleich, Adressen tief in Strukturen eher nicht.
- Wer ganz ohne Step7-Projekt die Maschine ändert, kann es etwas leichter haben, wenn die Maschinen eines Herstellers alle gleich sind. Wenn ich keine neuen Kundenwünsche, keine Weiterentwicklung, keine Änderungen und keine Umstellung auf TIA-Portal umsetzen muss, geht das.
- Ein anderer MA hat ja Zugriff auf Quellcode und Adressen und kann im übrigen auf Anfrage informelle Programmierrichtlinien haben. Nach meiner Erfahrung, programmieren sie lieber so wie sie es wollen. Ich würde da nur nachbessern, wenn es "zu weit" abweicht oder fehlerhaft ist.
- Bei Kunden und Lieferanten werden Schnittstellen entwickelt, ich denke das ist nichts besonderes und liegt in der Natur der Sache.
- Bei Übergabe der Codebasis ist meines Erachtens ein Code, der auf Bezeichnern basiert statt Adressen, besser verständlich. Aber wie gesagt, die Adressen sind auch da (zumindest bei Step7 classic). Gleiches für "in 10 Jahren".
- Wenn ich nach 10 Jahren nur Adressen und Nummern vor mir sehen würde, würde ich da nichts finden. Gibt es Namen und Kommentare, sieht es besser aus. Das ist dann wohl "God-Mode".

Mein Beispiel für eine weniger wünschenswerte Richtlinie ist nicht theoretisch, sondern habe ich selbst so gesehen und anwenden müssen. Die gesamte Richtlinie, in der das enthalten war, hat auf weniger als 1 Blatt gepasst.

Wenn ich irgendwo programmiere, versuche ich mich an bestehende Standards zu halten, ob dokumentiert oder de facto ersichtlich. Nur wenn ich sehe, dass es so nicht funktioniert, dann bemühe ich mich um Verbesserung. Wenn es Programmier-Standards von mir geben soll, dann wird wohl weniger geregelt als manchen hier lieb ist, zumal ich sie ohnehin nicht durchsetzen kann.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Fällt dir auf dass wir voneinander vorbeischreiben?
Ich schreibe: "Ein Programmierstandard macht Sinn"
Du schreibst: "Ein Programmierstandard der XY vorgibt macht keinen weil YZ besser ist"
Fein, wenn du YZ auf ein Blatt Papier schreibst was hast du dann? Einen STANDARD!

Und ich vermute, dass die, die solche Adressen normieren, ihre Norm auch gelegentlich ändern (müssen). Oder man hält sich nicht dran.
Ja man muß halt abwiegen ob/wann es wert ist vom Standard abzuweichen und wann es das nicht wert ist. Es wird immer Ausnahmen geben in denen es Sinn macht vom Standard abzuweichen, das stellt aber den Standard als solchen für mich nicht in Frage. Wir haben ja auch einen Standard names "Rechtsfahrgebot" und das heißt eben aus gutem Grund nicht "Linksfahrverbot".

Nur wenn ich sehe, dass es so nicht funktioniert, dann bemühe ich mich um Verbesserung.
Ja, natürlich ist kein Standard für die Ewigkeit. Die Technik ändert sich, Prozesse entwickeln sich weiter, uvm. Damit ist der Standard auch immer einer ständigen Evolution unterworfen. Wir z.B. halten regelmäßig interne Kurz-Workshops ab in denen wir prüfen wo/was/warum wir etwas ändern wollen.
 
Wenn sich das Eine oder das Andere nicht unmittelbar standardisieren läßt (soll es ja geben - kenne ich sogar auch) dann kann man aber immer noch mit Vorlagen (also ggf. Bausteine, die man dann abwandelt und anpasst) arbeiten.

Gruß
Larry
 
Zurück
Oben