Java als SPS Programmiersprache

[Heinz]

Zuviel Werbung?
-> Hier kostenlos registrieren

@zotos
Siemens geht den Weg in Richtung objektorientierte Programmierung.
Durch die Zugriffe auf die Daten der Multiinstanzen und durch die Multiinstanzen überhaupt entwickelt sich langsam eine objektorientierter Ansatz. Weiterhin wurde der Ansatz durch das CFC Zusatzpaket weiterentwickelt. Es ist natürlich so, dass vieles noch fehlt insbesondere die Ereignisse und Methoden.

Andere Programmiersprachen wie Steeble Chase sind dort schon weiter.

Ansonsten denke ich auch, dass die "alten" Sprachen wie AWL aussterben werden

Gruß Heinz

 

[Ralle]

Also, ich glaube nicht, daß die Objektorientierung soweit gehen wird wie unter Win, man sehe sich nur mal die S7-Software von Siemens an, tausende DLL-, Exe-, und Sonstwas-Dateien, immer wieder mal Abschmierer meist einzelner Komponenten. Sicher, ein Schlumi-Programmierer kann jede gute Programmiersprache versauen.
In der normalen Maschinensteuerung ist doch die Problemstellung(hier kraß vereifacht) folgende:

500 Eingänge, 200 Ausgänge --> Automatischer Ablauf in Abhängigkeit der Eingänge und von ein paar internen Vorgaben (auch nichts anderes als Eingänge).

Wenn jetzt alle Eingänge z.Bsp. Ereignisse auslösen sollen, auf die man dann reagieren kann, ist allein dafür der interne Aufwand des BS enorm groß. Außerdem muß dann der gesamte deterministische Mechanismus anders gestaltet sein, schon bei SPS-Software mit mehreren parallelen Tasks passiert genug, weil Signale zu früh oder zu spät sind. Übersicht oder gar Einblick in die Abläufe geht da völlig verloren.

Ich denke eher, daß Beschreibungssprachen interessant werden. Man gibt ein Problem vor (Fahrwerk mit 5 Haltstellen etc.) und eine Software generiert daraus den Code. Allerdings ist auch hier Vorsicht geboten, sonst kann das Ergebnis keiner mehr bewerten, geschweige denn warten. Die Gefahr dabei, soetwas könnte gute Programmierer "fast!!!!!" überflüssig machen (Script-Kiddis reichen :lol: )

rk

 

[Ralf]

Zuviel Werbung?
-> Hier kostenlos registrieren

Nunja, vereinfacht gesagt, Java:
Wenn der Maus - Listener sich aufgehängt hat schließe ich das Programm und mach es wieder auf.
Wenn der Hydraulikstempel listener sich in der Automatisierung aufgehängt hat mach ich ein Dummes Gesicht und geh laufen ...

Gruß

Ralf

 

[Zottel]

Die Multiinstanzen gehen insofern Richtuung OO, als sie Daten und Methoden zu deren Bearbeitung zusammenfassen.
Was nicht geht, ist Verebung und überladen:
"Pumpe C läuft wie Pumpe A und B, aber mit anderer Hyterese"
Hier bleibt nur:
1. Dem FB einen extra Parameter zu geben, der bei A und B konstant ist.
2. Den FB kopieren, umbenennen und die Hysterese ändern.

1. führt auf Dauer zu Bibliotheks-FBs, die im konkreten Anwendungsfall mehr überflüssige als benutzte Parameter haben.
2. führt zu einem Haufen spezialisierter Bausteine.

OO macht das nicht automatisch besser: Entweder sind analog zu 1 schon Methoden für alles und jedes drin oder man leitet ständig neue Objekte ab.
Mehrfachverebung sollte es richten, aber schaut euch mal C++ mit Mehrfachvererbung an!

JAVAs Ansatz, verschiedenens Verhalten an Klassen zu deligieren finde ich da überschaubarer. Es führt aber dazu, daß man im Nachhinein bestehende Objekte zerlegt und die Funktionalität auslagert. Ich habe noch keine gute Methode kennengelernt, um beim ersten Entwurf eines Objekts gleich alles "richtig" zu machen.

Ich denke eher, daß Beschreibungssprachen interessant werden. Man gibt ein Problem vor (Fahrwerk mit 5 Haltstellen etc.) und eine Software generiert daraus den Code. Allerdings ist auch hier Vorsicht geboten, sonst kann das Ergebnis keiner mehr bewerten, geschweige denn warten.

Die Wartung hätte natürlich auf der Ebene der Beschreibung zu erfolgen. Man nimmt ja auch nicht den C-Compiler her, um nachher das Ergebnis auf Assemblerebene zu ändern. Aber wie es Assembler-Unterprogramme in Hochsprachenprogrammen gibt (oder native Code, der von JAVA aufgerufen wird), wird es wieder AWL geben, um Probleme zu lösen, die man in der Beschreibungssprache nicht ausdrücken kann oder bei denen es auf maximale Effizienz ankommt.
[/quote]

 

[Ralf]

Guten... diesmal abend

Ich ergänze hier meinen Beitrag von heute morgen. Ich habe dort einiges Allgemeines erzählt, ohne meine ‚gemeinte’ Kernaussage auch nur ansatzweise zum Ausdruck zu bringen.

(kann Markus das ganze Topic nicht in den Stammtisch verschieben, das wäre wahrscheinlich eher was für ´ne Diskussion mit Wein, Bier, Zigaretten und ‚nem Dicken Kopf am nächsten Morgen)

Jemand der meint Objektorientiertheit sei die allseligmachende Eigenschaft einer guten Programmiersprache, befindet sich auf dem Holzweg. Objektorientiertheit ist gut, wenn man Probleme zu lösen hat, die
- gut zu modellieren sind
- häufig in abgewandelter Form zu finden sind
Die meisten derjenigen, die SPSen programmieren arbeiten im Anlagenbau. Sie finden keine geeigneten Modelle für die auftretenden Probleme (es sei denn man hat da eine Reglung, da ist ja PID ein geeignetes Modell. Sie haben es nicht mit Problemen zu tun, die häufig in abgewandelter Form bestehen. Entweder gibt es eine Funktion zigmal auf gleiche Art gelöst werden muß, oder Funktionen sind so unterschiedlich, daß sie mit verschiedenen (Unter)Programmen gelöst werden müssen.

Ähnlich geht es den IT – Leuten, aber mit geänderten Vorzeichen. Der große Anteil der IT – Anwendungen, die der ‚Normaluser’ so sieht, beruht auf Modellen / die Benutzerschnittstelle ist ja nur ein einziges Modell. Auch sind in der IT vielfach Probleme zu lösen, die auf dem selben Rechner in leicht abgewandelter Form an vielen Stellen zu lösen sind (z.B. Rufe den Datei öffnen Dialog auf, und öffne die gewählte Datei). Hier macht Objektorientiertheit Sinn.

Wenn die IT aber mit Problemen konfrontiert ist, die denen des Anlagenbaus vergleichbar sind (in meinem vorherigen ‚Guten morgen’ - Beitrag ‚Profibereich’), geht sie einen anderen Weg. Im Profibereich wird viel Geld für Rechenleistung ausgegeben. Probleme die singulär auftreten werden auch singulär d.h. nicht Performance lastig und Instabilitäten fördernd gelöst. Wenn eine Bank sich einen Rechner leistet, der die Bankgeschäfte abwickelt, ist nach wie vor COBOL (in meinem anderen Beitrag hatte ich ALGOL geschrieben / Ist aber COBOL) Maß aller Dinge, große Forschungsabteilungen die Großrechner benutzen, geben diesen ihre Aufgabenstellungen (‚simulier mir mal das Schwingungsverhalten einer Nockenwelle’) nach wie vor in FORTRAN. Würde hier der dringende Wunsch nach Objektorientiertheit bestehen, hätte man längst umgeschwenkt. Dies tut man nicht, da man keine Performancediebe oder noch schlimmer Rechnerstabilitätsgefährder gebrauchen kann.

Die Lastenhefte dieser Aufgabenstellungen entsprechen am ehesten denen, die auch wir aus der Anlagenautomation kennen: Ganz wichtig ist, das Programm läuft stabil.

Gruß

Ralf

 

[drfunfrock]

Zuviel Werbung?
-> Hier kostenlos registrieren

Möglicheweise dann, wenn er fremde Programme nachvollziehen muß. Das ist aber in einer OO-Sprache nicht eo ipso (automatisch) besser

Ich kann in Assembler , AWL etc. sicherlich alles machen, nur sinnvoll ist es nicht. Ich bin selbst mit Einplatinen-Z80-Platinen gross geworden und habe nicht die mindesten Skrupel gehabt, eine höhere Sprache zu wählen.

AWL und ähnliche Sprachen unterstützen die Beschreibung der Problemlösung nicht oder anders, derartige Programmiersprachen ermöglichen eine Lösung, dass ist aber schon alles. ST ist das schon ein ganzes Stück weiter. Mit einer objektorientierten Sprache ist das i.d.R. wesentlich einfacher. Aus einem Programmtext sollte i.d.R. das Konzept herauszuslesen sein.

Wie mißt du den Erfolg? Ich messe ihn mal daran, daß das Steuerprogram richtig auf Eingaben des Bedienes und Ereignisse der äußeren Welt (Prozeß) reagiert.

Das allein wäre nun doch ein bischen wenig. Ein Programm sollte sich im weitesten Sinne selbst dokumentieren und - wenn konzeptionell möglich - einfach erweiterbar sein. Ich wäre nie zur Programmierung einer SPS gekommen, wenn es nicht organisatorisches Chaos gegeben hätte, welches zu einem Code führte, der funktionierte, aber weder veränderbar noch selbstdokumentierend war.

Mein Erfolg war der, das Kollegen sofort mir bestätigten, dass mein Experiment nicht nur funktionierte, sondern auch für andere lesbar war.

Zwischen der Wirklichkeit und dem Programm steht nun die Modellierung als Objekt. Wenn dein Programm nicht funktioniert, mußt du das Objektmodells infrage stellen.

So arbeite ich nicht. Erst wird ein Konzept aufgestellt, dass die wichtigsten Kriterien darstellt und zum Entwurfkriterium eines Algorithmusses macht. Hält der Algorithmus den Kriterien stand, beginne ich zu Kodieren und nicht nach dem Trial- und Error-Verfahren. Das hat den Vorteil, dass Irrwege nicht so schnell beschritten werden und Kollegen eine Chance haben sich zu beteiligen.

Deine Einwürfe zu Java sind richtig und es wäre zu überlegen, ob hier nicht mehr getan werden könnte. Schade das die Automatisierer so konderativ sind, obwohl das oftmals nur eine Scheinsicherheit ist.

 

[drfunfrock]

Auswahl von Programmiersprachen

Ich versuche mal etwas kurz zur Auswahl von Programmiersprachen einzuwerfen:

Eine Programmiersprache sollte die Beschreibung der Problemlösung unterstützen und nicht nur Problemlösung sein. Bsp: Die Programmierung mit Assembler kann ein Problem lösen, dass dann aber selten gut beschrieben ist. Daher sind Diagramme mit LD durchaus i.O. wenn sie die Prolemlösung angemessen darstellen.

Eine Programmiersprache sollte auch die sichere Programmierung unterstützen und nicht nur ermöglichen. Bsp. In ST ist es möglich enumerated Datentypen zu Integern durch eine Zuweisung zu konvertieren, um solche Werte auch in Case-Of Anweisungen benutzen zu können. Grundsätzlich sollten implizite Casts nicht möglich sein. Das Konzept von Pointern macht die Systeme auch nicht sehr viel zuverlässiger.

Eine Programmiersprache (und ihre Umgebung) sollte ein gute Codeorganisation unterstützen.

 

[drfunfrock]

Also, ich glaube nicht, daß die Objektorientierung soweit gehen wird wie unter Win, man sehe sich nur mal die S7-Software von Siemens an, tausende DLL-, Exe-, und Sonstwas-Dateien, immer wieder mal Abschmierer meist einzelner Komponenten.

Ich selbst habe Step7 und die Software von Beckhoff in den Fingern gehabt und kann nur sagen, das Siemens Step7 eine Zumutung ist. Ich weiss noch nicht wie stabil Beckhoff TwinCat wirklich ist, aber zumind. ist die Programmierungebung sehr sauber und gut programmiert. Die Installation ist innerhalb von 3 Minuten abgeschlossen. Keine langwierige Registrierung diverser Komponenten....

Wenn jetzt alle Eingänge z.Bsp. Ereignisse auslösen sollen, auf die man dann reagieren kann, ist allein dafür der interne Aufwand des BS enorm groß. Außerdem muß dann der gesamte deterministische Mechanismus anders gestaltet sein, schon bei SPS-Software mit mehreren parallelen Tasks passiert genug, weil Signale zu früh oder zu spät sind.

Ich denke, wenn man nicht unbedingt alle Features von C++ implementiert, ist auch das zu schaffen. Zudem sind heutige Prozessoren doch etwas leitungsfähiger. Zudem benötigt man sicherlich leicht abgewandelte Konzepte. Events lassen sich durchaus über Hardware erzeugen. Eine Beschreibung einer Anlage über Objekte ist nicht in jedem Fall sinnvoll, aber sicherlich kann es einen grossen Gewinn bei verteilten Anlagen bringen.

 

[Anonymous]

Zuviel Werbung?
-> Hier kostenlos registrieren

Sprache

Aber sonst habt ihr wohl keine Probleme? Sinnlose Diskussionen! Automatisierungstechnik ist kein Feld für Hobbyprogrammierer. Macht lieber was mit "Hello World" ;-)

Bernd

 

[Ralf]

Ich kann in Assembler , AWL etc. sicherlich alles machen, nur sinnvoll ist es nicht.

Ein Postulat!
Gott sei dank hat Drfunrock keinen Brief an meinen Chef geschrieben mit der Betreffzeile
Wofür kriegt der eigentlich Geld, bei dem Sinnlosen Kram, den der tut
dann wär's um mich geschehen.

Das allein wäre nun doch ein bißchen wenig. Ein Programm sollte sich im weitesten Sinne selbst dokumentieren und - wenn konzeptionell möglich - einfach erweiterbar sein

Schon wieder ein Postulat,
Meiner Meinung zufolge muß ein Programm in erster Linie den Aufgaben entsprechen, die vom Auftraggeber respektive der Anlage an das Programm gestellt werden, erst sekundär können Eigenschaften wie Verständlichkeit und Erweiterungsfähigkeit gestellt werden. Versuch mal einer einem Auftraggeber zu erklären, das die Programmierung zwar nicht ganz den erheblichen Performanceanforderungen entspricht, aber dafür jederzeit erweiterbar... spätestens hier ist man tot.

Deine Einwürfe zu Java sind richtig und es wäre zu überlegen, ob hier nicht mehr getan werden könnte. Schade das die Automatisierer so konserativ sind, obwohl das oftmals nur eine Scheinsicherheit ist.

:?: :?: :?: Ich versteh den Zusammenhang nicht, ich bin konservativ, aber das ist nur eine Scheinsicherheit Kratzamkopf wird schon richtig sein.

Eine Programmiersprache sollte die Beschreibung der Problemlösung unterstützen und nicht nur Problemlösung sein.

Hier ist noch mal die (nicht nur in der Automatisierung) wichtige Prioritätenfrage zu klären.

Grundsätzlich sollten implizite Casts nicht möglich sein.

Woher nimmst Du das? Wenn es Zweckdienlich ist wandle ich Dir jede REAL in INT :!: :!: :!:

 

[zotos]

Es war einmal…

Es war einmal…

Ich hatte mal einen Vorgesetzten in einem Ingenieurbüro der auch auf Programmierungen abgefahren ist wie er sie aus der S5-Welt gekannt hat. Ernannte das konventionelle Programmierung und war glücklich damit. Wenn er ein Programm von mir gesehen hat mit FB die mehrfach aufgerufen wurden und Instanz DB´s war er sauer und richtig aus war es als ich einen Fünfzeiler SCL verwendet hatte er konnte mich nicht mehr leiden und ich ihn nicht mehr sehen. Ein Kollege hat mir nach dem ich die Firma verlassen hatte gesagt das es wohl daran lag das der Vorgesetze gemerkt hat das ihn die Technik überholt und er sich nicht etwas von einem Neuling erklären lassen wollte. Die Automatisierungstechnik hat sich in den letzten Jahren stark geändert oder lötet ihr noch 74 Reihen? Das mit dem Objektorientierten Ansatz ist schon gut gerade wenn man die Datenkapselung betrachtet und nur Methoden auf den Bereichzugreifen dürfen die das auch sollen.

@BerndS: Mach mir einen gefallen und Sterbe doch einfach aus. :stinkefinger: :!: //das war nur die Retourekutsche für das doofe „Hello World“ Kommentar.

Ich bin froh das auch andere der Ansicht sein werden das AWL ausstirbt und SCL & Co. die modernen Nachfolger werden.

Der Vorteil ist ich kann auch mit AWL umgehen :!: :wink:

 

[Ralf]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich schrieb doch

das wäre wahrscheinlich eher was für ´ne Diskussion mit Wein, Bier, Zigaretten und ‚nem Dicken Kopf am nächsten Morgen

.... jaja ....

Gruß

Ralf

 

[zotos]

@Ralf

guter Plan :lol: :!:

 

[drfunfrock]

Ich kann in Assembler , AWL etc. sicherlich alles machen, nur sinnvoll ist es nicht.

Ein Postulat!
Gott sei dank hat Drfunrock keinen Brief an meinen Chef geschrieben mit der Betreffzeile
Wofür kriegt der eigentlich Geld, bei dem Sinnlosen Kram, den der tut
dann wär's um mich geschehen.

Es geht nicht darum die Welt zu verbessern, sondern darum darüber zu diskutieren, inwieweit man es besser machen kann.

Meiner Meinung zufolge muß ein Programm in erster Linie den Aufgaben entsprechen, die vom Auftraggeber respektive der Anlage an das Programm gestellt werden, erst sekundär können Eigenschaften wie Verständlichkeit und Erweiterungsfähigkeit gestellt werden.

Ich stehe in anderer Position, denn ich führe keine Auftragsarbeiten durch und würde die Entlassung für so eine Pfuschermentalität riskieren. Es geht darum, dass eine Produktionsanlage nicht erweitert werden konnte, weil die Programmierung einfach chaotisch war. Dadurch ist uns ein Auftrag durch die Lappen gegangen.

Wer zudem seine Arbeit nicht konzeptionell vorbereiten kann, der wird immer wieder Code produzieren, der derartige Ergebnisse bringt.

Versuch mal einer einem Auftraggeber zu erklären, das die Programmierung zwar nicht ganz den erheblichen Performanceanforderungen entspricht, aber dafür jederzeit erweiterbar... spätestens hier ist man tot.

Das ist doch nun wirklich eine Ausrede. Gute Arbeit entspricht allen Anforderungen und dazu gehört neben dem sauberen Softwareengineering auch die Bedingungen der Anlage einzuhalten. Alles andere ist in meinen Augen Pfuscherei. Geschwindigkeit und Softwareengineering sind kein Widerspruch.

 

[drfunfrock]

Zuviel Werbung?
-> Hier kostenlos registrieren

Re: Sprache

Aber sonst habt ihr wohl keine Probleme? Sinnlose Diskussionen! Automatisierungstechnik ist kein Feld für Hobbyprogrammierer. Macht lieber was mit "Hello World" ;-)

Bernd

Ja, klar mit einem schönen Bier geht es besser Es sind häufig alteingesessene Automatisierer die mit Betonköpfen und einem Brett vor dem Kopf durch den Alltag laufen und meinen sie seien die Könige.

 

[Ralf]

Wer zudem seine Arbeit nicht konzeptionell vorbereiten kann, der wird immer wieder Code produzieren, der derartige Ergebnisse bringt

1. - Wen beurteilst Du hier
2. - Welche Ergebnisse meinst Du

Schreib doch bitte nicht so unverständlich, eine Konzentration auf das Sachliche wäre angebracht

Gruß

Ralf

 

[Ralf]

Ich stehe in anderer Position, denn ich führe keine Auftragsarbeiten durch

Aha, Du führst also nur Arbeiten zum Selbstzweck durch, hast also weder vom Endkunden, Deinem Arbeitgeber oder sonstwem einen Auftrag.

Dann mag Deine Position verständlich sein.

 

[Ralf]

Zuviel Werbung?
-> Hier kostenlos registrieren

@Markus
Wenn Dir dieser Beitrag irgendwie auf den Geist fällt, lösch Ihn bitte

@drfunrock
Ich kann es mir jetzt absolut nicht mehr verkneifen

Ich beschäftige mich erst seit 3 Wochen mit SPS-Technik und musste feststellen, dass es in der Automatisierungstechnik manchmal (nicht immer!) noch wie zu Anfang der 80'-Jahre zugeht.

- drfunrock beschäftigt sich seit drei Wochen (einem gesunden Schlaf / Beschäftigungsverhältnis voraussetzend also seit max. 180 Stunden) mit SPSen
- drfunrock weiß, wie es Anfang der 80ern zuging – vor über 20 Jahren

... erzielte sofort einen Erfolg

- drfunrock revolutionierte gewachsene Strukturen

Erst wird ein Konzept aufgestellt, dass die wichtigsten Kriterien darstellt und zum Entwurfkriterium eines Algorithmusses macht. Hält der Algorithmus den Kriterien stand, beginne ich zu Kodieren und nicht nach dem Trial- und Error-Verfahren. Das hat den Vorteil, dass Irrwege nicht so schnell beschritten werden und Kollegen eine Chance haben sich zu beteiligen.

Aha, drfunrock bekommt mit den oben errechneten 180 Stunden Erfahrung die Gelegenheit den Arbeitsprozeß zu gestalten. Er programmiert nicht wie wir alle :?: nach dem Versuch und Irrtum Prinzip sondern stellt (vor oder während der 180 Stunden) ein schlüssiges Konzept auf, in das :!: seine Kollegen :!: einbezogen werden können.

Ich selbst habe Step7 und die Software von Beckhoff in den Fingern gehabt und kann nur sagen, das Siemens Step7 eine Zumutung ist. Ich weiss noch nicht wie stabil Beckhoff TwinCat wirklich ist, aber zumind. ist die Programmierungebung sehr sauber und gut programmiert. Die Installation ist innerhalb von 3 Minuten abgeschlossen. Keine langwierige Registrierung diverser Komponenten....

drfunrock nutzt die in den 180 Stunden zwangläufig anfallenden Kaffeepausen sinnvoll mit dem Vergleich von Entwicklungsumgebungen

Es sind häufig alteingesessene Automatisierer die mit Betonköpfen und einem Brett vor dem Kopf durch den Alltag laufen und meinen sie seien die Könige.

drfunrock weiß, daß die Automatisierungswelt von Pfeifen bestimmt wird – spätestens nachdem man sich 180 Stunden mit der SPS Programmierung auseinandergesetzt hat, wird dem normalsterblichen das klar.

Ich möchte hier noch einmal meine Kernaussage aus dem letzten Beitrag unterbringen, die sich mit den aktuellen Mitteln der IT bezüglich der Objektorientiertheit auseinandersetzt

Wenn die IT aber mit Problemen konfrontiert ist, die denen des Anlagenbaus vergleichbar sind (in meinem vorherigen ‚Guten morgen’ - Beitrag ‚Profibereich’), geht sie einen anderen Weg. Im Profibereich wird viel Geld für Rechenleistung ausgegeben. Probleme die singulär auftreten werden auch singulär d.h. nicht Performance lastig und Instabilitäten fördernd gelöst. Wenn eine Bank sich einen Rechner leistet, der die Bankgeschäfte abwickelt, ist nach wie vor COBOL (in meinem anderen Beitrag hatte ich ALGOL geschrieben / Ist aber COBOL) Maß aller Dinge, große Forschungsabteilungen die Großrechner benutzen, geben diesen ihre Aufgabenstellungen (‚simulier mir mal das Schwingungsverhalten einer Nockenwelle’) nach wie vor in FORTRAN. Würde hier der dringende Wunsch nach Objektorientiertheit bestehen, hätte man längst umgeschwenkt. Dies tut man nicht, da man keine Performancediebe oder noch schlimmer Rechnerstabilitätsgefährder gebrauchen kann.

 

[sps-concept]

gewachsene Strukturen

is schon genial wie schnell manche dazu mutieren die Arbeit von anderen zu werten! Nach 3 Wochen die Erfahrung von Jahren übern Haufen werfen, als Anfänger alte Strukturen ablösen.... Kein Trial & Error.. wow! Da entfällt wohl auch die Inbetriebnahme? Da lassen sich ja 50% der Kosten sparen. Man steckt vor Auslieferung die MMC und fragt dann wenn der Elektriker eingeschalten hat ob alles läuft. Natürlich läuft alles, man will nur ne Bestätigung. Also ich nehme den Beitrag hier schon lange nicht mehr ernst. Da will nur einer reizen

MfG
André Räppel

 

[drfunfrock]

Ich stehe in anderer Position, denn ich führe keine Auftragsarbeiten durch

Aha, Du führst also nur Arbeiten zum Selbstzweck durch, hast also weder vom Endkunden, Deinem Arbeitgeber oder sonstwem einen Auftrag.

Dann mag Deine Position verständlich sein.

Du nimmst wohl alles persönlich? Es ist ein grosser Unterschied, ob jemand alle 2 Wochen für einen anderen Kunden arbeitet oder nur die Anlage in der Firma wartet bei der er seinen Job hat.

Nichts für ungut, aber ich habe im meinen Leben genug Programmierer gesehen, die tausende Zeilen Kode produzierten und das ohne eine Zeile Dokumentation zu hinterlassen. Es mag ja Auftraggeber geben, die so etwas aus Unkenntnis hinnehmen oder schlicht aus Faulheit. Ich akzeptiere so etwas nicht und würde von jedem, der so ein Ergebnis abliefert Schadensersatz fordern. Die Zeiten, in denen Programmierer - und seien es SPS-Techniker - Narrenfreiheit hatten, sind vorbei.