# Programming Guidelines and Programming Styleguide for SIMATIC S7-1200 and S7-1500



## ADS_0x1 (24 November 2017)

Hallo Forum,

Siemens hat die im Betreff genannten Guidelines herausgebracht, ich habe nach Suche im Forum nichts entdeckt (und war mir zugegebener Maßen unsicher, ob das nun hierher gehört oder in den Stammtisch). 

Ich stelle den Link dazu mal hier ein, da es bisher noch keine Diskussion/Aufschrei/Lob/Kritik/Hinweis dazu gab. 
[h=1]Programming Guidelines and Programming Styleguide for SIMATIC S7-1200 and S7-1500[/h]
Unter anderem um den Styleguide wird es bei den "Wissen kompakt"-Veranstaltungen in nächster Zeit gehen.

Viele Grüße!


----------



## Draco Malfoy (25 November 2017)

Ich habe diesen StyleGuide mir mal zu Gemüte geführt, ich finde, das ist harter Tobak. Es wird dadrin z.B. gefordert, auf den Gebrauch externer Quellen zu verzichten, und bei SCL ausschließlich Auto-Formatierung anzuwenden. Das würde ja zum Teil fast schon in Unlesbarkeit des Codes münden.


----------



## zako (26 November 2017)

... wenn ich mir den Styleguide durchlese, habe ich auch das Gefühl dass der aus einen hausinternen Vorgabe hervorging ( SCL; konsequent englisch; ...)
Andererseits hilft es schon wenn z.B. Bausteinkopf vorhanden ist (macht auch nicht jeder und v.a. auch mit allen notwendigen Info´s); Vorgaben für Variablennamen gemacht werden (damit man weiß ob es z.B. ein IN/OUT, TEMP; STAT; Konstante etc. ist). Wenn Vorschläge drinn sind, die auch zu einen effizienteren Betrieb der Steuerung führen, schadet es ja auch nicht.
Vielleicht gibt es ja hier ja noch weitere Meinungen (man kann ja auch mal schreiben was man gut findet und was man lieber anders macht (vielleicht auch warum)).


----------



## Wincctia (26 November 2017)

Hallo Beisammen, 

muss sagen gibt wirklich gute Punkte z.b. das Warnungen zu vermeiden sind oder der Begriff was ein In InOut und ein Out ist einzuhalten sind. Muss sagen mittlerweile hab ich das gefühl das sich 99% aller Programmierer nichts darum kümmern und das Thema für einen Chef so abstrakt ist das er sich mit einen geht nicht anders abspeisen lässt. 


Mit freundlichen grüßen Tia


----------



## rostiger Nagel (26 November 2017)

Diesen Stylguide finde ich als Ansatz nicht schlecht, ich setze ihn Teilweise um.
Zb für Constantan nur Großbuchstaben zu verwenden, kann doch hilfreich sein.


----------



## Thomas_v2.1 (26 November 2017)

Dieser Styleguide scheint so "gut" zu sein, dass nicht mal Siemens selber sich daran orientiert.
Oder hat schon mal jemand eine Siemens Bibliothek oder Codebeispiele gesehen, wo sich daran gehalten wird?

Ich vermute eher, das Erstellen des Dokuments ist ein Praktikantenprojekt gewesen.


----------



## PN/DP (26 November 2017)

ADS_0x1 schrieb:


> Siemens hat die im Betreff genannten Guidelines herausgebracht, ich habe nach Suche im Forum nichts entdeckt


Die genannten Programming Guideline und Styleguide wurden hier im Forum schon öfters verlinkt, allerdings ohne Begeisterungsstürme  sondern eher wegen den darin enthaltenen zahlreichen Fehlern :sad:

Suchbegriffe: 81318674, Programmierleitfaden, Styleguide

Harald


----------



## Draco Malfoy (26 November 2017)

Thomas_v2.1 schrieb:


> Dieser Styleguide scheint so "gut" zu sein, dass nicht mal Siemens selber sich daran orientiert.
> Oder hat schon mal jemand eine Siemens Bibliothek oder Codebeispiele gesehen, wo sich daran gehalten wird?



APL und BL sind von der Kommentarsprache intern größtenteils auf Deutsch verfasst. Auch die Variablennamen genügen nicht diesem Kodex.



> Ich vermute eher, das Erstellen des Dokuments ist ein Praktikantenprojekt gewesen.



Das vermute ich auch.


----------



## ADS_0x1 (26 November 2017)

Hi Leute und danke für die Diskussion!

Ich muss mich einigen Meinungen hier anschließen, a la 99% der Programmierer halten sich eh nicht dran, u.a. die Programmierer von Siemens selber 

Und dann sind einige Stellen, bei denen ich denke: "Das darf doch nicht war sein, das regt mich auch immer auf, wenn ich das irgendwo sehe". Andererseits sind da auch Dinge unter einer "Rule" aufgeführt, die ich so nicht mache und auch nicht machen werde. 

Konkrete Beispiele aus dem Dokument:

- no global constants

Ich habe globale Konstanten (pi, pi halbe, pi viertel, Wärmeleitkoeffizienten usw...). Diese verwende ich allerdings nicht in mehrfach verwendeten Bausteinen, sondern in den "Sammel-FBs" einzelner Anlagenteile

- no prefix for formal parameters

Ich mache das anders als vorgeschlagen... meine Eingänge haben eine Präfix-Struktur wie bspw. i_b_LichtschrankeEinlauf

- Data exchange via block interfaces - Direct access to Static tags outside the FB is prohibited (und dann noch der Hinweis, dass nicht auf globale Merker zugegriffen werden darf)

*JA VERDAMMT! *Es ist unglaublich, wie viele Leute das eben genau NICHT einhalten. Und das nervt unglaublich. Das schlimme ist noch, dass das nur schwer Querverweis-fähig ist. Wenn ich z.b. folgende Struktur habe:

OB > FB1 > FB2 

Dann muss ich im FB2 eine static nicht  mit komplettem Namespace ansprechen ( #zaehler als Beispiel ). Greift man nun außerhalb auf diese Variable zu, wird diese unter FB2.zaehler geführt und auch nur diese Querverweise werden angezeigt. Dem kommt man teilweise nur schwer auf die Schliche. Einzige Todsünde, die noch darüber steht: globale Merker in einem Know-How-geschütztem Baustein verwenden 

Ansonsten steht da viel hilfreiches, vieles, was ich verstehe, aber vieles, bei dem ich es anders mache und auch weiß, dass (aus gutem Grund) es andere auch nicht befolgen.


----------



## Thomas_v2.1 (26 November 2017)

ADS_0x1 schrieb:


> - Data exchange via block interfaces - Direct access to Static tags outside the FB is prohibited (und dann noch der Hinweis, dass nicht auf globale Merker zugegriffen werden darf)
> 
> *JA VERDAMMT! *Es ist unglaublich, wie viele Leute das eben genau NICHT einhalten. Und das nervt unglaublich. Das schlimme ist noch, dass das nur schwer Querverweis-fähig ist. Wenn ich z.b. folgende Struktur habe:



Das Schreiben auf die Instanzdaten von außen ist selbst bei neuen Siemens-Bausteinen für die 1500 notwendig. Ich meine das habe ich bei den Modbus RTU Bausteinen machen müssen, vor allem an der Stelle völlig unnötigerweise.

Ich habe mich erst beim Erstellen meiner ersten Standardbausteine für die 1500 daran etwas orientiert, also mit SCL, Variablenbezeichnungen, Kommentarbereich im Kopf usw. angeht. Dann muss kein separates Dokument für die Firma geschrieben werden. sondern kann sich direkt daran orientieren was ja auch Arbeit erspart. Aber vieles darin passt dann doch nicht oder würde ich niemals (wieder) so machen, und Siemens macht es ja auch nicht. Also dann lieber wieder etwas eigenes an der Praxis orientiertes verfassen, was dann auch nicht durch so viele Trivialitäten aufgebläht ist.


----------



## zako (26 November 2017)

Thomas_v2.1 schrieb:


> ...  hat schon mal jemand eine Siemens Bibliothek oder Codebeispiele gesehen, wo sich daran gehalten wird?...


Schau Dir mal den "Axis Control Block" an. Ich finde das ist ein recht gutes Beispiel wie ein Programm aussehen sollte, bzw. wie man eine umfangreichree Funktionalität umsetzen kann  (Auslieferung als Lib; mit entsprechenden UDT´s; "eigener Ordner" Baustein mit eigenen Errorcodes;  Datenaustausch über Bausteinschnittstellen ...). 
https://support.industry.siemens.com/cs/ww/en/view/48816191
Ich bin  jetzt auch nicht der absolute Programmierprofi, von daher orientiere ich mich gerne an diesen Baustein. Aber wenn Dir hier was auffällt was  besser im Sinne eines Styleguides umgesetzt sein sollte, würde mich das interessieren. 





*

*


----------



## Thomas_v2.1 (26 November 2017)

zako schrieb:


> Ich bin  jetzt auch nicht der absolute Programmierprofi, von daher orientiere ich mich gerne an diesen Baustein. Aber wenn Dir hier was auffällt was  besser im Sinne eines Styleguides umgesetzt sein sollte, würde mich das interessieren



Auf den ersten Blick: Block Autonumbering nicht aktiviert bei den Bausteinen. Steht aber so im Styleguide. Und wahrscheinlich noch zig Sachen mehr wenn man danach sucht und in den Quellcode schauen könnte

Wenns nach mir ginge hätte ich diese Nummern in bei der 1200/1500 überhaupt nicht mehr eingeführt, das ist nur nervig und völlig unnütz.


----------



## zako (26 November 2017)

... der ist sogar mit Sourcecode. Aber ich verschalte nur die Ein-/Ausgänge um eben Motion Control Funktionalität  möglichst einfach und schnell umzusetzen.


----------



## Thomas_v2.1 (26 November 2017)

zako schrieb:


> ... der ist sogar mit Sourcecode.


Gut zu wissen, muss ich morgen mal reinschauen. Bin grad eh daran zu Lernzwecken etwas mit Motion Control rumzuspielen.


----------



## rogseut (5 Dezember 2017)

Auf Anfrage gibt's bei Siemens einen Styleguidechecker. Dieser prüft den Code auf Übereinstimmung mit den Leitfaden. Damit auch der Auftraggeber ganz simpel überprüfen kann was er für sein Geld gefordert hat.


----------



## maxder2te (6 Dezember 2017)

Der deutschsprachige Styleguide liegt übrigens hier:
https://support.industry.siemens.co...ür-simatic-s7-1200-und-s7-1500?dti=0&lc=de-WW

Bei uns im Betrieb (> 80 SPS-Programmierer) hat sich die Standardisierungsrunde darauf verständigt, dass der Styleguide und der Leitfaden mit kleineren Einschränkungen einzuhalten ist, vor allem in Bezug auf die Benennung der Datentypen und Variablen, Autonumbering, optimierte Bausteine, usw.

Für Leute, die jahrelang mit S7-300 und AWL gearbeitet haben und faktisch nichts anderes kennen, ist das wirklich harter Stoff. Für jemanden wie mich, der auch mit B&R, Rockwell und ein bisschen CoDeSys gearbeitet hat, ist der Umstieg natürlich etwas einfacher. Dort hat man sich an das konsequente "symbolisch und optimiert" arbeiten ja gewohnt, und das Zugreifen auf Instanzdaten ist. i.d.R. ohnehin nicht möglich.
Natürlich wird es immer Dinge geben, die mit absolutem oder indiziertem Zugriff kompakter oder schneller sind, aber wenns daran scheitert sollte man sich ernsthaft überlegen, ob man nicht den Siemens-Zug verlassen sollte.


----------



## zako (6 Dezember 2017)

maxder2te schrieb:


> Bei uns im Betrieb (> 80 SPS-Programmierer) hat sich die Standardisierungsrunde darauf verständigt, dass der Styleguide und der Leitfaden mit kleineren Einschränkungen einzuhalten ist, vor allem in Bezug auf die Benennung der Datentypen und Variablen, Autonumbering, optimierte Bausteine, usw.


... da gehe ich mal davon aus, dass Ihr Euch das ernsthaft angeschaut und bewertet habt.
Andere Meinung aus dem Forum:


Draco Malfoy schrieb:


> Ich habe diesen StyleGuide mir mal zu Gemüte geführt, ich finde, das ist harter Tobak.





Thomas_v2.1 schrieb:


> Ich vermute eher, das Erstellen des Dokuments ist ein Praktikantenprojekt gewesen.





PN/DP schrieb:


> Die genannten Programming Guideline und Styleguide wurden hier im Forum schon öfters verlinkt, allerdings ohne Begeisterungsstürme sondern eher wegen den darin enthaltenen zahlreichen Fehlern
> Harald


Also Fehler konnte ich da nicht entdecken und einem Praktikanten (allein) traue ich so ein Thema nicht zu. Aber mit solchen Themen (wie auch "Standardisierung" ) kann man sich schöne blutige Nasen holen (und war überrascht dass sich jemand das antut). Aber am schönsten sind Diskussionen über Styleguides für HMI- Oberflächen (da fallen meiner kleinen Tochter wahrscheinlich auch noch Vorschläge ein ("die Button´s könnten doch rosa sein")).


----------



## Thomas_v2.1 (6 Dezember 2017)

Ich nehme alles zurück. Wenn das >80 Programmierer gut finden, dann muss es das Beste sein was es gibt. 

Die einzige Empfehlung an die ich mich nicht halte: Programm übersichtlich und strukturiert gliedern.


----------



## PN/DP (6 Dezember 2017)

zako schrieb:


> Also Fehler konnte ich da nicht entdecken und einem Praktikanten (allein) traue ich so ein Thema nicht zu.


Guideline und Styleguide gibt es schon länger (seit 2013). Einige besonders krasse Fehler haben wir hier im Forum thematisiert, z.B. hier. Manchen Fehlern sieht/sah man an, daß sie von Leuten mit nur theoretischem Wissen aber fast keiner praktischen Erfahrung verzapft wurden.

Vielleicht findest Du in den aktuellen Dokumentversionen keine Fehler, doch schaue mal in die Historie der Dokumente. In jeder neuen Version steht bei Änderung: "_Korrekturen in folgenden Kapiteln_", "_Diverse Korrekturen in unterschiedlichen Kapiteln_", "_Anpassungen und Korrekturen_".

Harald


----------



## PN/DP (6 Dezember 2017)

Seit 2013 gibt es auch folgende Empfehlungs-Sammlung:
Wie können Sie in STEP 7 (TIA Portal) für die S7-1200/S7-1500 effizient und performant programmieren?

(Ob die Einzelempfehlungen vielleicht mittlerweile in die Guides übernommen wurden habe ich jetzt nicht gecheckt.)

Harald


----------



## Thomas_v2.1 (6 Dezember 2017)

Falsch ist z.B. Kapitel 2.13 mit der Referenz ID. Denn die ID verändert sich nicht nur durch das Umbenennen einer Variable sondern bleibt in dem Fall gleich.
Darum würde ich auch anderen Aussagen über Verhaltensweisen der 1200/1500 nicht unbedingt blind vertrauen. Der Verfasser hat wohl nur eingeschränkten Zugriff auf die Siemens-Internas.


----------



## maxder2te (7 Dezember 2017)

maxder2te schrieb:


> Der deutschsprachige Styleguide liegt übrigens hier:
> https://support.industry.siemens.co...ür-simatic-s7-1200-und-s7-1500?dti=0&lc=de-WW
> 
> Bei uns im Betrieb (> 80 SPS-Programmierer) hat sich die Standardisierungsrunde darauf verständigt, dass der Styleguide und der Leitfaden mit kleineren Einschränkungen einzuhalten ist, vor allem in Bezug auf die Benennung der Datentypen und Variablen, Autonumbering, optimierte Bausteine, usw.



Ok, da ich den Beitrag gestern offenbar zu leichtfertig abgesetzt habe, ein paar Details dazu:
Die "Standardisierungsrunde" besteht aus den Leuten, die Vorlagen, Treiber und Bibliotheken erzeugen, und den Entscheidungsträgern, die das Zeug dann ihren Leuten (Programmierer, Inbetriebnehmer, >80) weitergeben. Die Runde erstellt keine strikte Norm, sondern Leitlinien, die wir selbst im Bibliotheksbau umsetzen und dann zur Anwendung kommen, wenn der Kunde keine expliziten Vorschriften setzt.
Das was Siemens als "Programmierleitfaden" (ich beziehe mich auf 1.5) bezeichnet, ist für Leute mit mittelmäßiger S7 Classic Erfahrung eine einigermaßen brauchbare Einführung in die S7-1200/1500-Welt. Zum Erstellen von Leitlinien ist es nur eine Entscheidungshilfe, aber sicherlich keine Vorgabe - schließlich sind am Ende nur ca. 20-30% der Informationen relevant. Was sich aus dem Leitfaden ableiten lässt sind, aber folgende Vorgaben:

Ausnahmslos optimierte Bausteine und Autonummerierung
Programmierung ausschließlich in FBs, Programmaufbau hierarchisch in Multiinstanzen
Programmierung in FUP/KOP und SCL, kein Graph, kein AWL
keine Berücksichtigung der S7-1200
striktes Trennen von Persistenten Daten, Aktualdaten und Instanzdaten, konsequentes Information-Hiding

Vorgabe 1 ist eine Frage der Konsistenz - in der C#-Applikations- oder C-Embedded-Entwicklung stellt sich diese Frage ohnehin nicht. Auch stellt sich so die Frage, ob INOUT-Parameter byref oder byval übergeben werden, nicht. Dass speziell die Abhandlung von Schnittstellen auf diese Art und Weise in ziemlicher Arbeit ausarten kann, nehmen wir teils hin.
Vorgabe 2 sorgt für übersichtliche Programme - vor allem wenn man eine hierarchische Vererbung von gewissen Informationen konsequent durchzieht.
Vorgabe 3 Graph nur auf ausdrücklichen Kundenwunsch und erst nach einem direkten Gespräch mit den technischen Entscheidungsträgern - ausschließlich für Bewegungsabläufe.
Vorgabe 4 die 200-300 EUR Preisunterschied zu den kleinen 1500er Steuerungen sind bei den meisten Maschinen vernachlässigbar - zentrale IOs gibts ohnehin nie
Vorgabe 5 bedarf noch eines gewissen Lerneffekts, vor allem in Bezug auf die Speicherreserve.


Viel wichtiger als der Leitfaden ist der Styleguide mit seinen Regeln, wobei natürlich Regeln aufgeweicht werden, z.B.
4.1.3 Quellen - lassen sich teils nicht vermeiden
4.1.3 nur Lokale Variablen - lässt sich teils nicht einhalten da Schnittstellen zu sehr aufgebläht würden
4.1.5 Struct - nur in globalen DBs (Persistent oder Aktual)
...

Fragen?


----------



## PN/DP (7 Dezember 2017)

maxder2te schrieb:


> .
> Programmierung ausschließlich in FBs, Programmaufbau hierarchisch in Multiinstanzen


Dann erfordert fast jede Änderung an den Lokaldaten (!) oder der Schnittstelle der beteiligten FB einen CPU-STOP zum laden. Nein, danke.

Harald


----------



## maxder2te (7 Dezember 2017)

PN/DP schrieb:


> Dann erfordert fast jede Änderung an den Lokaldaten (!) oder der Schnittstelle der beteiligten FB einen CPU-STOP zum laden. Nein, danke.
> Harald


Das stimmt so nicht. Passt man nicht auf, ist das Reinitialisieren nötig - zum CPU stoppen gehört aber schon einiges dazu.


----------



## rostiger Nagel (7 Dezember 2017)

Ich würde den "Style-Guide" nicht überbewerten, das Wort gibt nichts anderes wieder wie Gestaltungrichtlinie
und nicht Programmiergesetz oder Verordnung zur Verwendung von Bits und Bytes. Es ist eine Hilfe, mehr nicht.


----------



## PN/DP (7 Dezember 2017)

maxder2te schrieb:


> Das stimmt so nicht. Passt man nicht auf, ist das Reinitialisieren nötig - zum CPU stoppen gehört aber schon einiges dazu.


OK, stimmt, das war falsch so. Der STOP wird nicht nötig wegen der Multiinstanz, sondern schon wegen Änderung der Instanzdaten - eventuell kann TIA den STOP ja noch teilweise mit der Speicherreserve abfangen, doch wenn TIA den STOP verlangt, dann habe ich wegen den Multiinstanzen nur noch unter sehr hohem Aufwand eine Chance, das TIA zu umgehen und meine eigene "intelligentere" Ladestrategie ohne CPU-STOP durchzuführen.

Macht die S7-1500 eigentlich bei jedem Programm laden ein Defrag des "optimierten"-Arbeitsspeichers oder wird das Programm nach jeder Änderung in RUN ein kleines bisschen langsamer?
Was passiert bei der S7-1500 bei indirekter Adressierung eines Array oder String, wenn der Index beim Zugriff einen Wert außerhalb der deklarierten Array/String-Grenzen hat?

Harald


----------



## RONIN (7 Dezember 2017)

PN/DP schrieb:


> Was passiert bei der S7-1500 bei indirekter Adressierung eines Array oder String, wenn der Index beim Zugriff einen Wert außerhalb der deklarierten Array/String-Grenzen hat?


 Da geht die CPU in STOP.


----------



## maxder2te (7 Dezember 2017)

PN/DP schrieb:


> OK, stimmt, das war falsch so. Der STOP wird nicht nötig wegen der Multiinstanz, sondern schon wegen Änderung der Instanzdaten - eventuell kann TIA den STOP ja noch teilweise mit der Speicherreserve abfangen, doch wenn TIA den STOP verlangt, dann habe ich wegen den Multiinstanzen nur noch unter sehr hohem Aufwand eine Chance, das TIA zu umgehen und meine eigene "intelligentere" Ladestrategie ohne CPU-STOP durchzuführen.


Sorry, aber das kann ich so nicht nachvollziehen. Solange man mit dem Speicher nicht aus dem letzten Loch pfeift, kann man auch grobe Änderungen in die 1500er ohne STOP laden - auch wenn man an den Instanzen herumbastelt. Reinitialisieren ja - stoppen: nein. Muss aber auch sagen, dass ich noch nichts kleineres als eine 1515er an meinem Rechner hatte.




PN/DP schrieb:


> Macht die S7-1500 eigentlich bei jedem Programm laden ein Defrag des "optimierten"-Arbeitsspeichers oder wird das Programm nach jeder Änderung in RUN ein kleines bisschen langsamer?


Was soll das eine mit dem anderen zu tun haben? Warum soll ein Programm langsamer werden, nur weil was im Speicher woanders liegt, ist der Zugriff nicht automatisch langsamer. Und sowas wie das Fragmentieren von Dateien sollte es nicht geben.


PN/DP schrieb:


> Was passiert bei der S7-1500 bei indirekter Adressierung eines Array oder String, wenn der Index beim Zugriff einen Wert außerhalb der deklarierten Array/String-Grenzen hat?


Ist die Frage ernst gemeint? Es ist heutzutage wohl zumutbar, dass man Arraygrenzen selber überwacht (weil man ohnehin nicht mit Zeigern, sondern mit Array-Indizes drauf zugreift).
Spannenderweise zeigt die S7-1500 (zumindest mit Firmware 1.8) das gleiche Verhalten wie die 300er. Wenn beim Array-Überlauf in dem betroffenen Baustein hinterher noch Daten deklariert sind, dann wird schnell mal Müll aus dem Nirvana gelesen. Rockwell ist da von jeher viel rigoroser!


----------



## Draco Malfoy (7 Dezember 2017)

maxder2te schrieb:


> [*]Programmierung in FUP/KOP und SCL, kein Graph, kein AWL  Vorgabe 3 Graph nur auf ausdrücklichen Kundenwunsch und erst nach einem direkten Gespräch mit den technischen Entscheidungsträgern - ausschließlich für Bewegungsabläufe.  Fragen?


Ja, eigentlich nur eine - was ihr dort g'soffn habt. Ich weiß nicht, was für Anlagen ihr da programmiert - aber das was Du hier schreibst, klingt nach einem schweren Dachschaden (ja, ist genau so wenig schmeichelhaft gemeint wie es geschrieben ist).    

Wenn ich ein externer Einkäufer wär - und zu mir jemand käme, der mir anbieten würde, eine Anlage mit Bewegungsabläufen (ja überhaupt mit irgendwelchen diskreten schrittweisen Abläufen, es sei denn, es handelt sich um eine prozesstechnische Anlage nach PCS7) ohne Graph, ohne PDIAG/PRODIAG und nur mit SCL zu programmieren - dann würde ich ihm sagen, daß es hackt. Und daß ich als Kunde als Ziel-Senke für seine unbefriedigten Hochsprachen-Gelüste und die dazugehörigen Bemühungen, noch bis zum Jahresende irgendwo schnell 2000-3000 Programmierstunden zu verbauen, die bei sachgerechter Vorgehensweise erst gar nicht anfallen würden, nicht in Frage komme. Und die Kompetenz des Anbietenden aufgrund seiner sektenhaft-antiquirten Programmiervorstellungen stark hinterfragt sehe. 

   Die Vorgehensweise ohne Graph würde ich allenfalls bei reinem Prozess noch irgendwie nachvollziehen können, aber auch da nicht wirklich. Meine sehr bedauernswerte aber trotzdem fast ausnahmslos zutreffende Feststellung bezüglich abgeschlossener Programmierergesellschaften in mittelständischen Firmen indes lautet, daß diese Biotope ab einer bestimmten Größe der Programmierabteilung, Vorliegen entsprechender hierarhischer Strukturen, Konzentrierung der Entwicklungskompetenzen in wenigen "erfahrenen Händen" und zunehmender Entkoppelung von der großen Außenwelt in einer sehr sektenähnlichen Dynamik ausarten. Das passiet in der Regel dann, wenn zwar hochintelligente aber eigensinnige und in die Jahre gekommene Herren im kleinen Kreis Standardisierungsfragen für die gesamte Firma auf eigene Faust entscheiden dürfen. Die Kollegen unter ihnen dürfen ihnen nichts sagen, die Chefs darüber haben von der Materie kaum Ahnung, da es für sie sehr abstrakt ist. Und als externer hat man da in der Regel sowieso nichts zu melden. Im Ergebnis entwickelt sich da desöfteren eine ganz eigene Flora und Fauna, ja ein ganz eigener Biotop, wo irgendwelche Phoenix "Kliki-Bunti Sinus Plus allways minus kosinus"-Panels und Verzicht auf "Global Tags" noch die harmlosesten Entwicklungen darstellen.


----------



## maxder2te (7 Dezember 2017)

Draco Malfoy schrieb:


> Ja, eigentlich nur eine. Ich weiß nicht, was für Anlagen ihr da programmiert - aber das was Du hier schreibst, klingt nach einem schweren Dachschaden (ja, ist genau so wenig schmeichelhaft gemeint wie es geschrieben ist).
> 
> Wenn ich ein externer Einkäufer wär - und zu mir jemand käme, der mir anbieten würde, eine Anlage mit Bewegungsabläufen (ja überhaupt mit irgendwelchen diskreten schrittweisen Abläufen, es sei denn, es handelt sich um eine prozesstechnische Anlage nach PCS7) ohne Graph, ohne PDIAG/PRODIAG und nur mit SCL zu programmieren - dann würde ich ihm sagen, daß ich als Kunde als Ziel-Senke für seine unbefriedigten Hochsprachen-Lustträume und die dazugehörigen Bemühungen, noch zum Jahresende irgendwo schnell 2000-3000 Programmierstunden zu verbauen, die bei sachgerechter Vorgehensweise erst gar nicht anfallen würden, nicht in Frage komme. Und die Kompetenz des Anbietenden aufgrund seiner sektenhaft-antiquirten Programmiervorstellungen stark in Zweifel ziehen würde.
> 
> Die Vorgehensweise ohne Graph würde ich allenfalls bei reinem Prozess noch irgendwie nachvollziehen können, aber auch da nicht wirklich. Meine sehr bedauernswerte aber trotzdem fast ausnahmslos zutreffende Feststellung bezüglich abgeschlossener Programmierergesellschaften in mittelständischen Firmen indes lautet, daß diese Biotope ab einer bestimmten Größe der Programmierabteilung, Vorliegen entsprechender hierarhischer Strukturen, Konzentrierung der Entwicklungskompetenzen in wenigen "erfahrenen Händen" und zunehmender Entkoppelung von der großen Außenwelt in einer sehr sektenähnlichen Dynamik ausarten. Das passiet in der Regel dann, wenn zwar hochintelligente aber eigensinnige und in die Jahre gekommene Herren im kleinen Kreis Standardisierungsfragen für die gesamte Firma auf eigene Faust entscheiden dürfen. Die Kollegen unter ihnen dürfen ihnen nichts sagen, die Chefs darüber haben von der Materie kaum Ahnung, da es für sie sehr abstrakt ist. Im Ergebnis entwickelt sich da eine eigene Flora und Fauna, ja ganz eigener Biotop, wo irgendwelche Phoenix "Kliki-Bunti Sinus Plus allways minus kosinus"-Panels und Verzicht auf "Global Tags" noch die harmlosesten Entwicklungen darstellen.


Und wie lautet die angekündigte Frage?


----------



## Draco Malfoy (7 Dezember 2017)

> keine Berücksichtigung der S7-1200



Tatsächlich. Das ist ja mutig. Darf ich fragen, wie äußert sich das denn überhaupt, wenn ihr GRAPH und PRODIAG laut deiner Aussage eh in der Pfeife rauchen wollt (intern bestimmt verbunden mit deftigen Kommentaren von der Sorte "Diesen Shit brauchen ma hier nit!", die, regelmäßig in der Rauchpause persönlich vom 68-jährigen Chefentwickler geäußert, als Begründung dafür herhalten sollen, daß man seinen Leuten den Umgang mit zeit- und sachgemäßen Programmiermitteln verbietet) ?



> Und wie lautet die angekündigte Frage?


Ich weiß nicht, ob es richtig ist, deswegen meinen ganzen Beitrag in voller Breite zu zitieren, um diesen einen Kommentar noch dranzuhängen. Woanders heißt das eigentlich "Overquoting". Die Frage lautet - was für Maschinen stellt ihr da eigentlich her ? Weil wenn es am Ende irgendwelche Flaschenverpackungsanlagen oder Sortiereinrichtungen oder Feederpressen aus der Fertigungsindustrie sind, dann müsste man sich schon echt an den Kopf fassen. Ich würde dann bei den Firmen, die das bei euch zukaufen, und bei solchen Programmierrichtlinien, für kein Geld der Welt noch als Instandhalter arbeiten wollen. Aber möglicherweise ist es ja sogar gewollt, um sich auf Kundenkosten Alleinstellungsmerkmale zu verschaffen. Damit die Kunden bei jedem kleinen "Mek-Mek" wenn die Maschine irgendwo in der Schrittkette stehen geblieben ist, in jedem Fall eure Servicetechniker für 1000€/h rufen müssen.


----------



## PN/DP (7 Dezember 2017)

maxder2te schrieb:


> PN/DP schrieb:
> 
> 
> > Was passiert bei der S7-1500 bei indirekter Adressierung eines Array oder String, wenn der Index beim Zugriff einen Wert außerhalb der deklarierten Array/String-Grenzen hat?
> ...


Ist Deine Antwort ernst gemeint? Die TIA-Hife und RONIN sagen, die CPU geht in STOP. Du behauptest, die CPU liest dann aus Speicherbereichen außerhalb des Arrays. Wer hat wirklich recht?

Und was die Zumutbarkeit betrifft, so behaupte ich, daß gerade heutzutage ein großer Teil der SPS-Programmierer keine korrekte Prüfung der Index-Grenzen vor Verwendung macht. Die haben das einfach nicht gelernt und glauben an das Gute im SPS-Programm. 

Harald


----------



## maxder2te (7 Dezember 2017)

PN/DP schrieb:


> Ist Deine Antwort ernst gemeint? Die TIA-Hife und RONIN sagen, die CPU geht in STOP. Du behauptest, die CPU liest dann aus Speicherbereichen außerhalb des Arrays. Wer hat wirklich recht?


RONIN und die TIA-Hilfe haben recht. Siemens hat seine Hausaufgaben gemacht.

Ich konnte den Fall, den ich denke, mal geschafft zu haben, mit aktuellen Mitteln nicht mehr nachbauen. Die Randbedingungen dazumals waren:
- TIA V13 (ohne SP1)
- UDT, welcher ein Array [0.."Con"] OF REAL mit "Con" = 16 als PLC-Konstante enthielt und direkt anschließend eine weitere REAL-Variable
- 1516 (erster Hardwarestand), Firmware 1.8, projektiert als noch ältere Firmware



PN/DP schrieb:


> Und was die Zumutbarkeit betrifft, so behaupte ich, daß gerade heutzutage ein großer Teil der SPS-Programmierer keine korrekte Prüfung der Index-Grenzen vor Verwendung macht. Die haben das einfach nicht gelernt und glauben an das Gute im SPS-Programm.



Tja, man lernt nie aus.... Und glauben tu ich Siemens grundsätzlich nichts, was ich nicht selbst nachvollziehen kann ;-)


----------



## maxder2te (7 Dezember 2017)

Draco Malfoy schrieb:


> Ich weiß nicht, ob es richtig ist, deswegen meinen ganzen Beitrag in voller Breite zu zitieren, um diesen einen Kommentar noch dranzuhängen. Woanders heißt das eigentlich "Overquoting". Die Frage lautet - was für Maschinen stellt ihr da eigentlich her ?


Da ich im ganzen Beitrag keine Frage gefunden habe, war des angebracht.




Draco Malfoy schrieb:


> Ja, eigentlich nur eine. Ich weiß nicht, was für Anlagen ihr da programmiert - aber das was Du hier schreibst, klingt nach einem schweren Dachschaden (ja, ist genau so wenig schmeichelhaft gemeint wie es geschrieben ist).


Es handelt sich um so ziemlich alles, was bei uns im Haus an Maschinen und Anlagen gebaut wird. Von kleiner handbeschickter Schleifmaschine bis zum vollständigen Parkettbodenwerk, Volumen (nur Software) zwischen 60 und 14.000 Stunden, der Median dürfte so zwischen 400-800 liegen. Serien-Losgröße: 1
Mist, den ein Programmierer verbockt, darf er auch selber, ggf. vor Ort, ausbaden - auch wenn er eigentlich in der Entwicklung sitzt.



Draco Malfoy schrieb:


> Wenn ich ein externer Einkäufer wär - und zu mir jemand käme, der mir anbieten würde, eine Anlage mit Bewegungsabläufen (ja überhaupt mit irgendwelchen diskreten schrittweisen Abläufen, es sei denn, es handelt sich um eine prozesstechnische Anlage nach PCS7) ohne Graph, ohne PDIAG/PRODIAG und nur mit SCL zu programmieren - dann würde ich ihm sagen, daß ich als Kunde als Ziel-Senke für seine unbefriedigten Hochsprachen-Lustträume und die dazugehörigen Bemühungen, noch zum Jahresende irgendwo schnell 2000-3000 Programmierstunden zu verbauen, die bei sachgerechter Vorgehensweise erst gar nicht anfallen würden, nicht in Frage komme. Und die Kompetenz des Anbietenden aufgrund seiner sektenhaft-antiquirten Programmiervorstellungen stark in Zweifel ziehen würde.


Alles eine Frage der Zeit und des Geldes.

Zeit:
Graph war vor V14 faktisch unbedienbar, der Zeitaufwand enorm. PDIAG ist schlicht ein zeitlicher Mehraufwand, den die meisten Kunden (auch die großen Automobilisten) nicht bereit sind zu zahlen - denen sind ihre I4.0-Konzepte viel wichtiger. Nur ein Kunde aus der Rohstoffindustrie will das unbedingt haben.
Geld:
Für PDIAG braucht man entsprechend geschultes Personal, die das Tool auch nutzen können. Das leisten sich in unseren Branchen kaum Firmen. Oft muss man froh sein, wenn die Instandhaltung über 2-4 Schlosser hinausgeht.

Und eine Frage, die bei der ganzen Sache ganz außer Acht gelassen wird: Von welchem Anteil der Software sprechen wir denn? Abläufe sind heute meist nur 10-20% des gesamten Programms. Was mache ich mit Graph beim Rest?



Draco Malfoy schrieb:


> Die Vorgehensweise ohne Graph würde ich allenfalls bei reinem Prozess noch irgendwie nachvollziehen können, aber auch da nicht wirklich. Meine sehr bedauernswerte aber trotzdem fast ausnahmslos zutreffende Feststellung bezüglich abgeschlossener Programmierergesellschaften in mittelständischen Firmen indes lautet, daß diese Biotope ab einer bestimmten Größe der Programmierabteilung, Vorliegen entsprechender hierarhischer Strukturen, Konzentrierung der Entwicklungskompetenzen in wenigen "erfahrenen Händen" und zunehmender Entkoppelung von der großen Außenwelt in einer sehr sektenähnlichen Dynamik ausarten. Das passiet in der Regel dann, wenn zwar hochintelligente aber eigensinnige und in die Jahre gekommene Herren im kleinen Kreis Standardisierungsfragen für die gesamte Firma auf eigene Faust entscheiden dürfen. Die Kollegen unter ihnen dürfen ihnen nichts sagen, die Chefs darüber haben von der Materie kaum Ahnung, da es für sie sehr abstrakt ist. Und als externer hat man da in der Regel sowieso nichts zu melden. Im Ergebnis entwickelt sich da desöfteren eine ganz eigene Flora und Fauna, ja ein ganz eigener Biotop, wo irgendwelche Phoenix "Kliki-Bunti Sinus Plus allways minus kosinus"-Panels und Verzicht auf "Global Tags" noch die harmlosesten Entwicklungen darstellen.


Ja, davor ist man nicht sicher. Zu unserem Glück sind die Entscheidungsträger jene, die die Standards in ihren jeweiligen Sparten aufgebaut haben und > 20 Jahre an der Front waren. Die Entwickler und Standardisierer bunt gemischt und mit einer Ausnahme unter 40.



Draco Malfoy schrieb:


> Darf ich fragen, wie äußert sich das denn überhaupt, wenn ihr GRAPH und PRODIAG laut deiner Aussage eh in der Pfeife rauchen wollt


Das habe ich so nicht behauptet.



Draco Malfoy schrieb:


> (intern bestimmt verbunden mit deftigen Kommentaren von der Sorte "Diesen Shit brauchen ma hier nit!", die, regelmäßig in der Rauchpause persönlich vom 68-jährigen Chefentwickler geäußert, als Begründung dafür herhalten sollen, daß man seinen Leuten den Umgang mit zeit- und sachgemäßen Programmiermitteln verbietet)?


Der Kommentar kommt mir bekannt vor. Der Herr, von dem solche Meldungen gekommen sind, wurde vor 2 Jahren unehrenhaft in die Pension geschickt - Entscheiden durfte er seit 5 Jahren nichts mehr, Programmieren seit 20 Jahren nicht mehr.
Als sachgemäß würde ich Graph/Prodiag durchaus bezeichnen, als zeitgemäß nicht.

Die Programmierung in Hochsprache verleitet natürlich dazu, dass man sich völlig austobt. Wer in Case-Schrittketten rekursive Aufrufe nutzt, schießt schon etwas an der Sache vorbei. Wer die Möglichkeiten von Case wie lokale Konstanten usw. nicht nutzt, oder mit Schrittnummern herumrechnet oder Schrittnummern zum Steuern von Funktionen nutzt, braucht dringend eine Kopfwäsche.

Vielleicht wehren sich auch einige Kollegen innerlich gegen PDIAG, weil sie ohnehin gewöhnt sind, eine umfangreiche Diagnose mittels Meldesystem und Diagnosefenstern zu realisieren.



Draco Malfoy schrieb:


> Die Frage lautet - was für Maschinen stellt ihr da eigentlich her ? Weil wenn es am Ende irgendwelche Flaschenverpackungsanlagen oder Sortiereinrichtungen oder Feederpressen aus der Fertigungsindustrie sind, dann müsste man sich schon echt an den Kopf fassen. Ich würde dann bei den Firmen, die das bei euch zukaufen, und bei solchen Programmierrichtlinien, für kein Geld der Welt noch als Instandhalter arbeiten wollen. Aber möglicherweise ist es ja sogar gewollt, um sich auf Kundenkosten Alleinstellungsmerkmale zu verschaffen. Damit die Kunden bei jedem kleinen "Mek-Mek" wenn die Maschine irgendwo in der Schrittkette stehen geblieben ist, in jedem Fall eure Servicetechniker für 1000€/h rufen müssen.


Unterstellungen kommentiere ich nicht


----------



## ducati (8 Dezember 2017)

maxder2te schrieb:


> Das stimmt so nicht. Passt man nicht auf, ist das Reinitialisieren nötig - zum CPU stoppen gehört aber schon einiges dazu.


reinitialisieren ist zumindest bei unseren Anlagen genauso toedlich wie CPU-Stop... Wie aendert Ihr Eure Software im laufenden Betrieb der Anlage? Oder krigt Ihr immer genug Stillstaende?
Gruss


----------



## Draco Malfoy (8 Dezember 2017)

maxder2te schrieb:


> Da ich im ganzen Beitrag keine Frage gefunden habe, war des angebracht.



Man kanns auch so dazu schreiben.


> 14.000 Stunden


Das sind genau so die Zeiten, die zustande kommen, wenn man versucht, komplexe, wartungsintensive Maschinenabläufe, ggf. dann auch noch mit besonders betreuungsintensiven Prozessverfahren auf der physikalischen Maschinenebene, softwareseitig in SCL zu verketten. Jede keine Änderung ("nach Schritt X dann bitte noch Xk einfügen, wo der Greifer rückwärts fährt") kostet mich Stunden; Verriegelungsbedingungen und Überwachungsbedingungen sind kaum noch übersichtlich darzustellen; Ein Versuch, dazu noch Schrittzeiten und Meldungen zu implemetieren, wird dann zu einem homosexual act mit besonderer Härte. Jemand, der sich dazu berufen sieht, ist allerdings selber Schuld. Wenn die Ketten dann auch noch verzweigt sind, Alternativ- oder Parallelzweige, ggf. sogar mehrere, oder im Worst Case noch alles zusammen, dazukommen, dann möchte ich diese Inbetriebnahme besser nicht aus der Nähe erleben.



> Alles eine Frage der Zeit und des Geldes.


Wahres Wort. Ich wüsste nicht, wie ich jemandem gegenüber diese 14 000h ehrlicherweise rechtfertigen müsste, bei beschriebenen Programmiermethoden.



> Graph war vor V14 faktisch unbedienbar, der Zeitaufwand enorm. PDIAG ist schlicht ein zeitlicher Mehraufwand, den die meisten Kunden (auch die großen Automobilisten) nicht bereit sind zu zahlen - denen sind ihre I4.0-Konzepte viel wichtiger.


Das stelle ich in Abrede. Ich habe schon seit V12 SK in Graph gearbeitet, die einzige Einschränkung war, daß es noch kein PRODIAG gab. Wenn man das aber unbideingt haben wollte, dann gab es eben noch die Classic-Welt mit PDIAG/ProRuntime, und die gibt es auch heute noch. VW schafft immer noch so. Die nehmen statt abgekündigter Flexible Panels Panel PCs, und lassen eine Flexible Runtime darauf laufen. Und dort wird überall nur mit PDIAG/ProRuntime und GRAPH gearbeitet. Also von wegen große Automobilisten.



> Geld: Für PDIAG braucht man entsprechend geschultes Personal, die das Tool auch nutzen können. Das leisten sich in unseren Branchen kaum Firmen. Oft muss man froh sein, wenn die Instandhaltung über 2-4 Schlosser hinausgeht.


Quatsch. Das brauche ich doch in erster Linie selber, zum Service und Ferndiagnose. Und dem Betriebselektriker zu erklären, wie er das Diagnosefenster aufruft, um davon ein Screenshot zu machen, kann doch nicht so schwer sein.



> Und eine Frage, die bei der ganzen Sache ganz außer Acht gelassen wird: Von welchem Anteil der Software sprechen wir denn? Abläufe sind heute meist nur 10-20% des gesamten Programms. Was mache ich mit Graph beim Rest?


Deswegen frage ich ja, was ihr da für Maschinen baut. Abläufe mögen optisch 20% ausmachen, sind aber genau das, weswegen ein Kunde diese Maschine kauft. Nicht wegen der tollen Treiberbausteine.


> Ja, davor ist man nicht sicher. Zu unserem Glück sind die Entscheidungsträger jene, die die Standards in ihren jeweiligen Sparten aufgebaut haben und > 20 Jahre an der Front waren. Die Entwickler und Standardisierer bunt gemischt und mit einer Ausnahme unter 40.


Wenn ich fertig studiert habe, dann bin ich doch im günstigsten Fall 24-25 ? Wie soll ich dann, unter 40, noch 20 Jahre an der Front verbracht haben ?


> Das habe ich so nicht behauptet.


Eigentlich wohl


> Als sachgemäß würde ich Graph/Prodiag durchaus bezeichnen, als zeitgemäß nicht.


Was genau soll daran nicht zeitgemäß sein ? Antiquiert und sachfremd ist weniger Graph, oder irgendwelche andere Programmiermittel, außer AWL. Sondern die Vorstellungen, daß man mit einem C++ Programm effizient industrielle Maschinen steuern kann. Und genau so sachfremd sind Ideen, Programmiermittel, die der Hersteller einem fertig an die Hand gibt, abzulehnen, und stattdessen zu versuchen, mühselig und verbissen eigene, fast zwangsläufig unzulängliche und fehlerträchtige, Ersatzkonzepte zu bauen, und sie dann vehement gegen jede Kritik zu verteidigen, wie sinnlos das auch sei. Da fehlt mir allenfalls noch ein Bibelwort zu ein: "Keine Erkenntnis haben, die sich abschleppen mit den Klötzen ihrer Götzen und zu einem Gott flehen, der nicht helfen kann." (Jesaja 45,20). Sehr treffende Beschreibung.



> Die Programmierung in Hochsprache verleitet natürlich dazu, dass man sich völlig austobt. Wer in Case-Schrittketten rekursive Aufrufe nutzt, schießt schon etwas an der Sache vorbei. Wer die Möglichkeiten von Case wie lokale Konstanten usw. nicht nutzt, oder mit Schrittnummern herumrechnet oder Schrittnummern zum Steuern von Funktionen nutzt, braucht dringend eine Kopfwäsche.



Können die ja ruhig machen, solange es sich zum Beispiel um abgeschlossene Bausteine, zum Beispiel zum Kommunikationaufbau, handelt. Welche, die ich hinterher weder häufig ändern noch dauernd analysieren muss. Aber nicht den Maschinenprozess in SCL.


----------



## Draco Malfoy (8 Dezember 2017)

> Was mache ich mit Graph beim Rest?



Diesen Satz muss man sich eigentlich gesondert auf der Zunge zergehen lassen. 
Unterschiedliche Programmiermittel in ein und demselben Projekt darf man in eurer Firma aus religiösen Gründen nicht verwenden?


----------



## maxder2te (12 Dezember 2017)

Draco Malfoy schrieb:


> "Keine Erkenntnis haben, die sich abschleppen mit den Klötzen ihrer Götzen und zu einem Gott flehen, der nicht helfen kann."


Siemensu akbar! Es ist alles im grünen (petrolfarbenen) Buch verzeichnet! Und alles was davon abweicht darf vernichtet werden.

Danke fürs Öffnen der Augen. Ich war naiv genug zu glauben, dass ein Forum zur Diskussion und zum Meinungsaustausch da ist.


----------



## Faceman (12 Dezember 2017)

> Ich war naiv genug zu glauben, dass ein Forum zur Diskussion und zum Meinungsaustausch da ist.



Zu 99,99% ist diskutieren und Meinungsaustausch hier doch sehr gut möglich.

In anderen Fällen gibt es hier einen sinnvollen Rat:
Suche Link zum Applikationsbeispiel - TCP/IP Kommunikation Leittechnik


----------



## smoe (12 Dezember 2017)

He! Da haben ein paar hier ihre Tabletten schon lange nicht mehr genommen.... 
Kommt wieder runter. Wir sind doch alle auf der selber Seite (der Macht).

Einen guten Morgen wünscht euch der smoe


----------



## maxder2te (12 Dezember 2017)

smoe schrieb:


> He! Da haben ein paar hier ihre Tabletten schon lange nicht mehr genommen....
> Kommt wieder runter. Wie sind doch alle auf der selber Seite (der Macht).
> 
> Einen guten Morgen wünscht euch der smoe


Mein Tablettenersatz am Wochenende: http://www.hellbrunneradventzauber.at/


----------



## DeltaMikeAir (12 Dezember 2017)

> Mein Tablettenersatz am Wochenende: http://www.hellbrunneradventzauber.at/



:sm19::s12:  Hübsch, gefällt mit


----------



## rostiger Nagel (12 Dezember 2017)

maxder2te schrieb:


> Siemensu akbar! Es ist alles im grünen (petrolfarbenen) Buch verzeichnet! Und alles was davon abweicht darf vernichtet werden.
> 
> Danke fürs Öffnen der Augen. Ich war naiv genug zu glauben, dass ein Forum zur Diskussion und zum Meinungsaustausch da ist.



Hallo Max,
bitte überbewerte die Diskussion nicht, Sie war bis zu einen bestimmten Zeitpunkt auch sachlich,
bis die Mülltonne aufging und Oscar alles zerredet hat. Oscar mag keine Programmierer über 30,
weil da muss man schon in Rente sein. Alles was nicht mit PCS7 Automatisiert ist, kann nichts sein
und da sind dann KOP, FUP, AWL und SCL tabu, das einzige was man verwenden darf ist GRAPH.

Da kann man halt nichts machen ist halt Sesamstraße.

gruß RN


----------



## Draco Malfoy (12 Dezember 2017)

rostiger Nagel schrieb:


> Hallo Max, bitte überbewerte die Diskussion nicht, Sie war bis zu einen bestimmten Zeitpunkt auch *sachlich*, bis die Mülltonne aufging und Oscar alles zerredet hat.


 Wer zum Satan ist Oscar ? Meinst Du mich etwa damit ? Leute mit "Mülltonne" zu bezeichnen, soll jetzt ein sachlicher Umgang miteinander sein ? Fairnessverständnis (Besser gesagt - Rechtsnihilismus) wie bei der "Roten Hilde" in der DDR & Sitten wie bei den Hells Angels scheinen sich in dieser Gesellschaft immer tiefer festzusetzen.





rostiger Nagel schrieb:


> das einzige was man verwenden darf ist GRAPH


 Belege man bitte diesen unsäglichen Stuß, und wann und wo ich das geschrieben haben soll. Und erkläre mir bitte, wer zur Hölle Oscar ist.


----------



## Draco Malfoy (12 Dezember 2017)

maxder2te schrieb:


> Ich war naiv genug zu glauben, dass ein Forum zur Diskussion und zum Meinungsaustausch da ist.


Nun, das war eine (kontroverse) Diskussion und ein offener Meinungaustausch. Genau das war es, und nichts anderes. Wenn Du fremde Meinungen nicht verträgst oder dich denen nicht stellen willst, kannst du dich ja weiterhin in dein wohlbehütetes Firmenumfeld, besser gesagt, in eure firmeninterne Entwicklersekte, zurückziehen, und dort, wo ihr vor schändlichen Einflüssen der weiten Welt draußen, im festen Bunker sicher geschützt seid, in dem von der Firmeninquisition freigegebenem und abgesegneten Meinungsrahmen euch untereinander koscher austauschen, und nicht etwa auf einer öffentlichen Plattform, wo einem an jeder Ecke Ketzerei, Unzucht und Blasphemie auflauern.


----------



## hucki (12 Dezember 2017)

Draco Malfoy schrieb:


> Wer zum Satan ist Oscar ?


Ein Bewohner der Sesamstraße mit eigener Bleibe: https://de.wikipedia.org/wiki/Sesamstraße#Oscar


----------



## DeltaMikeAir (12 Dezember 2017)

Auch bekannt als Okar aus der Mülltonne.


----------



## Draco Malfoy (6 Mai 2020)

DeltaMikeAir schrieb:


> Auch bekannt als Okar aus der Mülltonne.



Aus der Mülltonne gekrochen scheinen mir hier eher gewisse Metallwarenerzeugnisse mit Rostansatz


----------



## Mrtain (6 Mai 2020)

...............


----------



## DeltaMikeAir (6 Mai 2020)

Mrtain schrieb:


> @Draco
> 
> Eigentlich schätze ich ja deine Beiträge. Aber ohne dir jetzt persönlich nahe treten zu wollen, du hast schon sehr provozierend geschrieben und mehr als einmal die sachliche Ebene verlassen.



Ja ist doch ok jetzt. Immerhin hat er sich 2 Jahre lang beruhigt und nun geantwortet.



Spaß muss sein, um den Beitrag mal wieder etwas aufzulockern :icon_lol:


----------



## Mrtain (6 Mai 2020)

DeltaMikeAir schrieb:


> Ja ist doch ok jetzt. Immerhin hat er sich 2 Jahre lang beruhigt und nun geantwortet.
> 
> 
> 
> Spaß muss sein, um den Beitrag mal wieder etwas aufzulockern :icon_lol:



voll verrafft


----------

