Firmen-Norm

Zuviel Werbung?
-> Hier kostenlos registrieren
Aber der Gedanke ist gut vor Einführung von TIA die
die Alte Arbeitsweise zu hinterfragen und das auf einen
System was man beherrscht, die classic Welt.
Außerdem wird wahrscheinlich TIA sehr schnell auf euch
zukommen, weil im Oktober sieht es mit den Panels schlecht
aus. Also bleibt euch doch garnicht soviel Zeit eine Firmen
Norm zu erarbeiten.

Was ich mal von dir hören möchte ist eine Einziger Grund der
Objektiv dagegen spricht, zur zeit sind es ja nur subjektive Gründe.

Eine Firmen Norm muss doch auch kein eng geschnürtes Korsett
sein, sondern kann doch eine Hilfe sein, wenn du mal ein Programm
deines Kollegen vorgesetzt bekommst und findest dich darin zurecht.
 
Aber der Gedanke ist gut vor Einführung von TIA die
die Alte Arbeitsweise zu hinterfragen und das auf einen
System was man beherrscht, die classic Welt.

Ist das nicht eher so, wie ein Haus vor dem Abriss noch einmal zu streichen?

Außerdem wird wahrscheinlich TIA sehr schnell auf euch
zukommen, weil im Oktober sieht es mit den Panels schlecht
aus. Also bleibt euch doch garnicht soviel Zeit eine Firmen
Norm zu erarbeiten.

Zu erarbeiten?
Geht das mit TIA nicht in 10 Minuten von alleine?

Der Wutbürger
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Mir ging es weniger um Taktmerker. Ich hab das aber auch schon bei Schrittmerkern gesehen. Die Schritte wurden über einen Merkerdoppelwortzugriff gelöscht (Initialisieren) und ansonsten bitweise angesprochen. Nach einer Erweiterung suchte ein Kollege immer wieder sporadisch auftretende Fehler, die nach einer Störung auftraten weil das Doppelwort nicht mehr alle Schrittmerker umfasst hat.

Und sowas kann mit einer Struktur nicht passieren.


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

So ein Fehler wird nur dann schnell gefunden, wenn es zur Regel wird, dass er auftritt.
Strukturen allein sind kein Allheilmittel, schaffen aber, wenn es gut gemacht ist, Übersicht.

Alles was global angelegt ist, aber nicht global sein müsste, raubt Übersicht.

Gewisse Ansätze in der Skalierbarkeit und Wiederverwendbarkeit konnte ich schon umsetzen.
Eine vernünftige und einfache Versionsverwaltung habe ich leider noch keine gefunden.

Kennt da wer was richtig gutes?
Vorzugsweise nicht ausschließlich für Siemens?

Der Wutbürger
 
Ist das nicht eher so, wie ein Haus vor dem Abriss noch einmal zu streichen?



Zu erarbeiten?
Geht das mit TIA nicht in 10 Minuten von alleine?

Der Wutbürger

sehe ich nicht so krass, zur einer Firmen-Normierung können doch die ganz einfachen dinge Zählen
die sich bei der umstellung auf TIA nicht unterscheiden müssen. Es sind schon die kleinen Dinge, die
so etwas ausmachen z.b.:

  • Das ein Taktmerkerbyte immer das gleiche ist und die einzelnen Bits immer die gleiche Symbolik hat.
  • Grundsätzlich, wie eine Symbolik auszusehen hat.
  • Wie ein Programm strukturiert werden soll.
  • Nummernbereiche für Programmbausteine und Biblotheken
  • und und und.

Außerdem kann man sich ja bei der Endwicklung TIA paralell anschuen und schon darauf eingehen
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Interressant wäre eine Diskussion über Programmstrukkturen, anstatt sich hier über den Sinn un Unsinn von Merkern zu streiten. Wobei mich doch eher die Programmstrukktur ohne Merker interessieren würde.
 
Zuletzt bearbeitet:
Ist die Diskussion inzwischen nicht nur noch akademisch?
Das Standardisieren und Vereinheitlichen der Programmierung wurde doch bei den Hochsprachen versucht.
Hat es geklappt?

Ist das Gleichschalten der Programmierung wirklich der richtige Weg?
Was macht denn "Made in Germany" aus?
Beruht der Fortschritt nicht darauf, dass anders gedacht, produziert und programmiert wird?

Grundlagen können und sollen standardisiert sein.
Doch alles über einen Kamm scheren?

Muss nicht sein.


bike
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ist die Diskussion inzwischen nicht nur noch akademisch?
Das Standardisieren und Vereinheitlichen der Programmierung wurde doch bei den Hochsprachen versucht.
Hat es geklappt?

Ist das Gleichschalten der Programmierung wirklich der richtige Weg?
Was macht denn "Made in Germany" aus?
Beruht der Fortschritt nicht darauf, dass anders gedacht, produziert und programmiert wird?

Grundlagen können und sollen standardisiert sein.
Doch alles über einen Kamm scheren?

Muss nicht sein.


bike

Interessant diese Diskussion hatte ich vor ein paar Wochen auch schon im Geschäft. Es geht ja nicht da drum jedes Fitzelchen zu standardisieren. Ich empfehle dir den Programmierleitfaden von TIA.
Warum soll ich jedes mal das Rad neu erfinden und mir Tagelang die Finger wund tippen oder aus unterschiedlichen Programm zusammen kopieren um nachher alles zu testen ob ich mich nirgends vertippt habe? Meistens hat eine Firma ja ähnliche Maschinen bzw. ist auf was spezialisiert. und da kann der größte Teil mit einem guten Standard erschlagen werden. Und der Rest ist dann wirklich anders und da kann man Gehirnschmalz reinstecken.

Fängt man immer wieder von vorne an z.B. Zylinderfehler dort, Ansteuerung dort, Verriegelung mal so und so, wird man über ein bestimmtes Level nie hinaus kommen, bzw. länger brauchen oder schlechtere Programme abliefern oder man ist richtig gut. Aber wenn ein neuer Kollege bei Euch anfängt wird er froh sein bestimmte Dinge eben eine Firmennorm vorzufinden.

Mal abgesehen waren Lochkarten auch lange Zeit Stand der Technik. Also Sachen nur gut finden ohne Begründung zählt nicht.
 
Zuletzt bearbeitet:
Ich wollte dazu auch noch was schreiben um hervorzuheben wie Sinnvoll und notwendig ich solche Richtlinien finde, wo die Vorteile und Gefahren bestehen usw. Beim überfliegen dieses Threads ist mir dann aber aufgefallen das die wichtigsten Punkte bereits geschrieben wurden.

es wird schwer fallen Argumente aufzulisten die gegen die Einigung auf einen gemeinsamen Programmierstil in einer Firma sprechen. Beim dem Thema wie eine solche Richtlinie zu gestallten ist gibt es hingegen genügend Diskussionsbedarf. Wenn das Klima in der Entwicklungsabteilung passt wird man sich da aber auch einigen könnten.

Ich finde den Standard den wir verwenden super. Er erleichtert das Programmieren sehr da Standardfunktionen bereits vorhanden sind und einheitlich zur Verfügung stehen. Die Wiederverwendbarkeit ist auch ein riesen Vorteil. Die Programme von den Kollegen kann man wie ein Buch lesen dessen Sprache man versteht ohne sich erst ewig einarbeiten zu müssen. Das ganze dient keinem Selbstzweck und ist auch kein Gesetz man hält sich bei uns deshalb an di gemeinsam definierten Standards da diese enorme Vorteile bringen.
 
Interressant wäre eine Diskussion über Programmstrukkturen, anstatt sich hier über den Sinn un Unsinn von Merkern zu streiten. Wobei mich doch eher die Programmstrukktur ohne Merker interessieren würde.

Programmstrukturen sind eigentlich eher selten ein Thema (Falls du damit meinst, wie ein Programm gegliedert ist)

Die Diskussionen gehen eigentlich immer um die gleichen Themen:
  • Verwenden von Merkern und S5-Timer
  • Übergreifende Zugriffe auf Instanz-DB oder Verwendung von Global-DB
  • Schnittstellen-DB für Visualisierungen oder Integration der Visualiserung im Instanz-DB.

Meines Erachtes ist das "WAS" egal. Das "WIE" ist der Punkt!
Ich hab sowohl beschiessene als auch hervoragende Programme in jeder Form / Sprache gesehen.

Einer unserer Instandhalter sagte mal zu mir:
"Ich hab deine Telefonnummer und weiß wo du und deine Familie wohnen ... Programmier entsprechend" :p

Gruß
Dieter
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ich finde den Standard den wir verwenden super. Er erleichtert das Programmieren sehr da Standardfunktionen bereits vorhanden sind und einheitlich zur Verfügung stehen. Die Wiederverwendbarkeit ist auch ein riesen Vorteil. Die Programme von den Kollegen kann man wie ein Buch lesen dessen Sprache man versteht ohne sich erst ewig einarbeiten zu müssen. Das ganze dient keinem Selbstzweck und ist auch kein Gesetz man hält sich bei uns deshalb an di gemeinsam definierten Standards da diese enorme Vorteile bringen.

Ganz geanu. Wenn man die Zeiten mal zusammen zählen würde, wie lange es dauert sich in die unterschiedlichen Programme einzudenken (egal ob gut oder schlecht, aber halt immer anders).

In dieser Zeit hätte man sich LOCKER einen Standard schreiben und testen können.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Interessant diese Diskussion hatte ich vor ein paar Wochen auch schon im Geschäft. Es geht ja nicht da drum jedes Fitzelchen zu standardisieren. Ich empfehle dir den Programmierleitfaden von TIA.
Warum soll ich jedes mal das Rad neu erfinden und mir Tagelang die Finger wund tippen oder aus unterschiedlichen Programm zusammen kopieren um nachher alles zu testen ob ich mich nirgends vertippt habe? Meistens hat eine Firma ja ähnliche Maschinen bzw. ist auf was spezialisiert. und da kann der größte Teil mit einem guten Standard erschlagen werden. Und der Rest ist dann wirklich anders und da kann man Gehirnschmalz reinstecken.

Fängt man immer wieder von vorne an z.B. Zylinderfehler dort, Ansteuerung dort, Verriegelung mal so und so, wird man über ein bestimmtes Level nie hinaus kommen, bzw. länger brauchen oder schlechtere Programme abliefern oder man ist richtig gut. Aber wenn ein neuer Kollege bei Euch anfängt wird er froh sein bestimmte Dinge eben eine Firmennorm vorzufinden.

Mal abgesehen waren Lochkarten auch lange Zeit Stand der Technik. Also Sachen nur gut finden ohne Begründung zählt nicht.

Bitte nicht TIA, ich bin kein Masochist. :wink:
Du schreibst das wie wir es auch sehen.
Symbole, die Programmstruktur sowie Standardfunktionen sind in allen Programmen gleich.
Bei allem das besonders bzw spezifisch ist, kann der Entwickler sein Wissen und auch teilweise seine Vorlieben umsetzen.
Damit sind wir bisher und werden auch in Zukunft gut gefahren und wenn einer zu Kreativ wird, dann kann mit dem beim Kaffee dies bereden und einen gemeinsamen Nenner finden.


bike
 
Was mir halt wirklich widerstrebt ist, dass diese Änderungen angegangen werden sollen, bevor wir auf TIA umstellen.
Sollte es ansprechende Neuerungen in TIA geben, so können diese auf den neuen Standard von Klassik, trotz aller Bemühungen, doch nicht angewandt werden.

Dann haben wir nicht ein einheitliches System, sondern drei verschiedene:
- Klassik alt
- Klassik neu
- TIA

Eure Lordschaft

sehe ich auch so... aber kommt halt drauf an, wieviele Anlagen Ihr noch mit Classic bauen wollt/könnt/dürft...

macht halt wenig Sinn, ne einheitliche Standardbibliothek für 2 Anlagen mit Classic zu entwickeln, wenn davon für TIA das meiste nicht mehr läuft und nochmal entwickelt werden müsste...

Gruß.

PS: ich sehe Classic noch lange nicht tot... und ob TIA sich durchsetzen wird, wäre noch abzuwarten. Von daher: kommt eben drauf an.
 
Interressant wäre eine Diskussion über Programmstrukkturen, anstatt sich hier über den Sinn un Unsinn von Merkern zu streiten. Wobei mich doch eher die Programmstrukktur ohne Merker interessieren würde.

2 Möglichkeiten nutze ich selber.


  1. Multiinstanzen nutzen wo es nur geht und als Schnittstelle für die einzelnen Bausteine den TEMP Bereich des FB nutzen. Somit werden Funktionen komplett gekapselt und Copy und Paste fähig.
  2. Seine Bausteine so anlegen das Sie einen InOut als STRUCT haben wo alle relevanten Daten für Schnittstellen übergeben werden. Funktioniert gut erzeugt aber unnötigen Code und erschwert die Lesbarkeit des Programms.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Seid Gegrüßt,

Ihr Programmierer und Leidensgenossen. Sei geraumer Zeit treibt eine neuer Geist in meiner Firma sein Unwesen. Es wird gemunkelt, „Firmen-Norm“ soll er sich nennen!

Er verlangt mit den traditionellen Arbeitsweisen zu brechen. In S7 sollen weder S5-Timer noch Merker Verwendung finden. Auch Instanz-Datenbausteine sollen rationiert werden. Der Übersicht wegen, soll alles in „Multi-Instanzen“ verpackt werden.
Auch verlangt der „neue Geist“, dass Bausteine zur Wiederverwertung entwickelt werden, an denen später keine Änderungen mehr vorgenommen werden dürfen.

Wie geht es in Euren Landen?
Geht jener Spuk von alleine wieder vorüber?
Habt Ihr solch neue Geister schon vertrieben?

Eure Lordschaft

Was spricht dagegen in einer S7 Steuerung ein S7 Programm mit dessen Möglichkeiten ablaufen zu lassen und nicht nur alten S5 Code ?

Ich entwickle gerade auch eine neue Standardbibliothek für TIA da setze ich auch die ganzen Neuerungen ein die TIA mitbringt.
Ich will keinen STEP 7 Klassik Code im TIA Portal. Sonst kann ich ja gleich bei Klassik bleiben was ja auch Problemlos möglich bleiben wird.
Sich auf die Möglichkeiten eines neuen Systems einzulassen kann durchaus einen großen Schritt nach vorne bedeuten.
Auch wenn es für das Gewohnheitstier Mensch oftmals einfach nur eine sinnlose Änderung von bewährten Dingen zu sein scheint.
 
2 Möglichkeiten nutze ich selber.


  1. Multiinstanzen nutzen wo es nur geht und als Schnittstelle für die einzelnen Bausteine den TEMP Bereich des FB nutzen. Somit werden Funktionen komplett gekapselt und Copy und Paste fähig.
  2. Seine Bausteine so anlegen das Sie einen InOut als STRUCT haben wo alle relevanten Daten für Schnittstellen übergeben werden. Funktioniert gut erzeugt aber unnötigen Code und erschwert die Lesbarkeit des Programms.

Was mich an beiden Lösungen stört ist, dass bei keiner ein Querverweiss richtig möglich ist.
Man muss sich unter Umständen bei der Fehlersuche durch x-Aufrufschnittstellen hangeln.
Unsere Instandhalter (und ich denke auch viele andere) fluchen bei sowas kräftig.


Gruß
Dieter
 
Methode 1 nutze ich immer wenn ich die Software Programmiere. Dann brauche ich auch keine Querverweise bzw. ich nutze gehe zur lokalen Verwendungsstelle (Shift+STRG+ B oder F).

Bei Methode 2 befinden sich die Daten in einem DB wieso sollten da die Querverweise nicht funktionieren ?
 
Zurück
Oben