mikrocontroller.net

Forum: Offtopic Bin ich zu doof für SPS-Programmierung?


Autor: Peter P. (huloka12)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Hallo,

ich habe während meines E-Technik Studiums ein 6-Monatiges Praktikum im 
Bereich Engineering eines Produktionsunternehmens gemacht und wurde dort 
mit SPS "konfrontiert".. (Hatte ich vorher im Studium nicht viel mit zu 
tun)

Ich sollte zuerst via TIA Portal einen SPS-gesteuerten Reinigungsprozess 
einer Abfüllanlage auf einem HMI visualisieren. Das hat auch ganz gut 
geklappt soweit.

Danach sollte ich den recht umfangreichen Reinigungsprozess (welcher 
durch eine eigene SPS mit Zentral-CPU (S7-300) und zwei weiteren 
dezentralen CPU (ET200) gesteuert wurde, angesteuert durch einen 
abgesetzten Steuerungs-PC der für den Produktionsprozess zuständig war, 
inkl. Regelung für Dosierung von Reinigungsmitteln, Wassererhitzung via 
Dampf usw) aus FUP quasi "reverse engineeren" und in TIA Portal mit 
S7-Graph für ne 1500 neu umsetzen um Diagnosefunktionalitäten nutzen zu 
können.

Jedenfalls hat mich das ganze ein wenig überfordert und ich habe circa. 
3-4 Monate an diversen Schrittketten gesessen bis das Praktikum dann 
endlich vorbei war.

Das ganze hat mich etwas demotiviert und ich habe mich dann auch dagegen 
entschieden, dort meine Abschlussarbeit zu schreiben und bin in eine 
andere Richtung gegangen.

Jetzt frage ich mich, ob das an mir lag, dass ich einfach zu blöd war 
für die Aufgabe. Ich meine, ich war offensichtlich zu blöd. Aber ist das 
eine Aufgabe die man von einem Absolventen direkt nachm Studium ohne 
Erfahrung im Bereich der SPS-Programmierung erwarten kann?

Ehrlich gesagt reizt mich das Thema SPS und co schon noch ein wenig, 
aber nach dieser Erfahrung habe ich einfach das Gefühl, keinerlei Talent 
dafür zu besitzen..

Autor: Matthias S. (da_user)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Das hört sich schon nach einen ziemlichen Brocken an...

Ich glaube dir hat damals einfach die Erfahrung gefehlt, bzw. die Zeit 
dich da ordentlich einzuarbeiten. Sowohl in die Anlage/Aufgabe, wie auch 
Allgemein in die SPS-Geschichte.

Autor: Unbekannt U. (unbekannter)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
Naja, so und so...

Ein Problem: Der Siemens-Kram ist, naja, eben Siemens-Kram. Der 
Hersteller versucht schon, "seine" Programmierer an seine Plattform zu 
binden in dem vieles etwas anderes ist als in bestimmten Normen und dem 
Rest der Welt. Auch die elende Kompatibilität zu irgendwelchen 
Uralt-Designs, ich sag nur "Datenbaustein" etc., ist ganz schön nervig.

Ein anderes: SPS gilt immer noch als trivial und simpel, ebenso wie 
irgendwelche Steuerungsaufgaben von Maschinen und Anlagen. Mental wird 
SPS in der Masse immer noch bei den Elektrikern verortet.
Tatsächlich ist es aber doch so, dass seit gut 15 Jahren die 
SPS-Programmierung zur gewöhnlichen Software-Entwicklung konvergiert und 
diese Realität in vielen Köpfen noch nicht angekommen ist. Dazu kommt, 
das heutige Anlagen und Maschinen ganz schön komplex geworden sind, und 
die Komplexität weiter rasant steigt.

Abgesehen von den Frickelbuden die mit einer 300er ein paar Aktoren und 
Sensoren steuern und sich an ein paar Netzwerken abrackern, ist 
ernsthafte SPS-Programmierung inzwischen gewöhnliches 
Software-Engineering.

Daher: Bemühe Dich um eine Software-Engeneering-Ausbildung, wenn Du die 
nächsten Jahren Anlagen und Maschinen programmieren möchtest. Der 
Elektriker der auch SPS macht, stirbt gerade aus, weil diese Leute 
reihenweise in Rente gehen.

Autor: Claus M. (energy)
Datum:

Bewertung
-8 lesenswert
nicht lesenswert
Unbekannt U. schrieb:
> ist ernsthafte SPS-Programmierung inzwischen gewöhnliches
> Software-Engineering.

Nö, ist nach wie vor unterschichten Entwicklung. Würdelos, sowas als 
Ing. Zu machen.

Autor: Egon D. (egon_d)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Peter P. schrieb:

> Jetzt frage ich mich, ob das an mir lag, dass ich
> einfach zu blöd war für die Aufgabe.

Nein.

Das Einzige, was man eventuell als blöd bezeichnen
könnte, ist, dass Du die Aufgabe offensichtlich
unterschätzt hast. Mehr aber auch nicht.


> Ich meine, ich war offensichtlich zu blöd.

Genau. Und wenn ich Dich ohne Vorwarnung an eine Tuba
setze, und Du aus dem Ding keinen Ton herausbekommst,
heißt das, dass Du zu blöd zum Tubaspielen bist. Logo.

Wozu nochmal gibt es eigentlich Lehrer?
Und warum muss man komplexe Tätigkeiten i.d.R. erstmal
erlernen und üben?


> Aber ist das eine Aufgabe die man von einem Absolventen
> direkt nachm Studium ohne Erfahrung im Bereich der
> SPS-Programmierung erwarten kann?

Wann der Absolvent nicht gerade Automatisierungstechnik
studiert hat: Nein.


> Ehrlich gesagt reizt mich das Thema SPS und co schon
> noch ein wenig, aber nach dieser Erfahrung habe ich
> einfach das Gefühl, keinerlei Talent dafür zu besitzen..

Was hast Du denn für Vorkenntnisse?
- Was weisst Du über Steuerungstechnik?
- Welche Programmiersprachen (egal welche Plattform)
  beherrscht Du wie gut?
- Was weisst Du über Digitaltechnik und Automatentheorie?
- Was weisst Du über theoretische Informatik?

Autor: A. S. (achs)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Peter P. schrieb:
> welcher durch eine eigene SPS mit Zentral-CPU (S7-300) und zwei weiteren
> dezentralen CPU (ET200) gesteuert wurde,

3 CPUs. Das ist nichts für einen Anfänger, wenn da nicht ein 
Mentor/Lehrer/Senior bei ist.

Autor: Egon D. (egon_d)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
A. S. schrieb:

> Peter P. schrieb:
>> welcher durch eine eigene SPS mit Zentral-CPU
>> (S7-300) und zwei weiteren dezentralen CPU
>> (ET200) gesteuert wurde,
>
> 3 CPUs. Das ist nichts für einen Anfänger, wenn
> da nicht ein Mentor/Lehrer/Senior bei ist.

Ich weiss, dass der TO das TIA-Portal benutzt hat,
aber trotzdem: Machen die 3 CPUs einen Unterschied,
wenn man AWL/FUP verwendet? Und, wenn ja -- wieso?

Autor: Asko B. (dg2brs)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Unbekannt U. schrieb:
> Naja, so und so...
>
> Ein Problem: Der Siemens-Kram ist, naja, eben Siemens-Kram. Der
> Hersteller versucht schon, "seine" Programmierer an seine Plattform zu
> binden in dem vieles etwas anderes ist als in bestimmten Normen und dem
> Rest der Welt. Auch die elende Kompatibilität zu irgendwelchen
> Uralt-Designs, ich sag nur "Datenbaustein" etc., ist ganz schön nervig.

@all

Erst gestern wieder gehabt. Nach einem Stromausfall vorige Woche stand
die Anlage "im Wald". Nach der Neuprogrammierung gestern, muss ich
heute wieder hören, das immer noch nicht alles funktioniert.
(und das ist bloß eine Klimasteuerung, keine Prozesssteuerung)

Unser Opa würde sich im Grabe umdrehen, wüsste er davon.
(War mal Ingenieur bei Siemens & Halske)
Sicherlich gabs damals noch keine SPS und dergleichen.

Aber mittlerweile bin ich persönlich der Meinung, will man eine
funktionierende Anlage, nimmt man besser KEINE von Siemens.

Gruss Asko

: Bearbeitet durch User
Autor: Peter D. (peda)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Peter P. schrieb:
> ich habe mich dann auch dagegen
> entschieden, dort meine Abschlussarbeit zu schreiben und bin in eine
> andere Richtung gegangen.

Das war die einzig richtige Entscheidung.
Ich hab mal ein SPS-Programm Fehler korrigieren und erweitern müssen. 
Das hat mich für alle Zeiten von SPS geheilt.

Ein SPS-Programm reverse zu engineeren ist nur bei extremst einfachen 
Steuerungen möglich.
Die SPS-Programme sehen in der Regel aus, wie Kraut und Rüben. Eine 
Strukturierung ist nicht erkennbar und wird auch nicht unterstützt. 
Alles ist global verfügbar und global veränderbar. Man sieht auch schön, 
wie verschiedene Teile von woanders zusammen kopiert wurden, da sind 
Relaiskontakte neben Logikblöcken usw.
Es ist auch extrem schwierig, ein Programm auszudrucken, um es "offline" 
zu analysieren. Das werden riesige Stapel an Papier.

Für komplexe Sachen nimmt man daher immer noch erwachsene 
Programmiersprachen und keinen SPS-Kinderkram.

Peter P. schrieb:
> Ehrlich gesagt reizt mich das Thema SPS

Lieber nicht, Du verpaßt absolut nichts.

Autor: Bernd K. (prof7bit)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
OK. Auf die Gefahr hin daß ich mich jetzt in die Nesseln setze, 
folgendes ist mein Eindruck:

Ich komme aus der Ecke (und befinde mich auch noch dort) in der PCs (und 
kleine Embedded-Systeme) und Mikrocontroller programmiert werden, dies 
geschieht in der Regel in althergebrachten prozeduralen oder auch 
objektorientierten Sprachen, manchmal (bei mir weniger) auch in 
funktionalen Sprachen. Und zwar ganz unabhängig davon wie komplex die 
Aufgabe ist!

All diese Sprachen, von den Urgesteinen angefangen bis hin zu den 
ultrahippen modernen Hochsprachen haben eins gemeinsam: Sie werden als 
Text notiert, nicht als Bilder!

Wenn Du einen aus dem Umfeld der oben genannten Programmierer fragst ob 
irgendein Szenario denkbar ist wo das graphische 
Mausklickprogrammieren Vorteile hätte, wo sie sich vorstellen damit 
irgendwas schneller gebacken zu bekommen, blickst Du in leere Gesichter.

Im SPS-Umfeld jedoch wird bis aufs Messer die (meiner bescheidenen 
Meinung nach) irrsinnige These verteidigt daß grafisches Programmieren 
unter irgendwelchen nebulösen Umständen die dort und nirgends anders in 
der Welt herrschen (Elektriker sind involviert??) deutlich einfacher sei 
als alles andere.

Sind nun Elektriker eine ganz spezielle Klasse vom Menschen mit 
fundamental anders strukturierten Gehirnen denen umständliches einfacher 
erscheint und einfacheres hingegen umständlicher? Das bezweifle ich 
irgendwie. Also woran liegt das?

Autor: Egon D. (egon_d)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Bernd K. schrieb:

> All diese Sprachen, von den Urgesteinen angefangen
> bis hin zu den ultrahippen modernen Hochsprachen
> haben eins gemeinsam: Sie werden als Text notiert,
> nicht als Bilder!

AWL wird nicht als Bilder notiert.


> Sind nun Elektriker eine ganz spezielle Klasse vom
> Menschen mit fundamental anders strukturierten
> Gehirnen denen umständliches einfacher erscheint und
> einfacheres hingegen umständlicher?

Ja, das muss es sein.

Systemstrukturen werden ja immer und überall in Form der
berühmten Blockprosa beschrieben. Kein Mensch verwendet
Blockschaltbilder.

Konstrukteure schreiben Konstruktionsromane; niemand
macht Zeichnungen.
Kein normaler Elektriker verwendet Kabelpläne, kein
normaler Elektroniker Schaltpläne. Für Hydraulik
ist die allseits bekannte Ölprosa verbreitet.

Was haben wir nur gemacht, bevor es Programmierer gab...

Autor: Egon D. (egon_d)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Peter D. schrieb:

> Ein SPS-Programm reverse zu engineeren ist nur bei
> extremst einfachen Steuerungen möglich.

Das ist falsch.


> Die SPS-Programme sehen in der Regel aus, wie Kraut
> und Rüben.

Das hängt auch vom Können des Programmierers ab.


> Eine Strukturierung ist nicht erkennbar und wird auch
> nicht unterstützt.

... und wird auch nicht in dem Maße benötigt.
Deine Kritik ist in diesem Punkt dennoch berechtigt.


> Es ist auch extrem schwierig, ein Programm auszudrucken,
> um es "offline" zu analysieren. Das werden riesige Stapel
> an Papier.

Nun ja, AWL hat etwa das Niveau einer Assemblersprache.
Kein Mensch verlangt, dass Du FUP oder KOP ausdruckst.


> Für komplexe Sachen nimmt man daher immer noch erwachsene
> Programmiersprachen und keinen SPS-Kinderkram.

Jaja... alle Halbstarken glauben, sie würden es ja VIEL
besser machen als die Erwachsenen...


> Peter P. schrieb:
>> Ehrlich gesagt reizt mich das Thema SPS
>
> Lieber nicht, Du verpaßt absolut nichts.

Das stimmt nicht.
Es hilft allerdings, wenn man keine "Ehre" als "richtiger"
Programmierer zu verteidigen hat.

Autor: Bernd K. (prof7bit)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Egon D. schrieb:
> Kein normaler Elektriker verwendet Kabelpläne, kein
> normaler Elektroniker Schaltpläne. Für Hydraulik
> ist die allseits bekannte Ölprosa verbreitet.

Dir ist schon der Unterschied bewußt zwischen einem Plan der die 
Struktur von etwas beschreibt und einem Programm welches einen 
Algorithmus beschreibt. Aus Deiner Antwort lese ich heraus daß Du der 
Meinung bist daß man Algorithmen besser in Bildern notiert? Warum 
verwenden dann so viele noch textuelle Programmiersprachen? Weil sie das 
Licht der Erleuchtung noch nicht gesehen haben?

Autor: Egon D. (egon_d)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Bernd K. schrieb:

> Egon D. schrieb:
>> Kein normaler Elektriker verwendet Kabelpläne, kein
>> normaler Elektroniker Schaltpläne. Für Hydraulik
>> ist die allseits bekannte Ölprosa verbreitet.
>
> Dir ist schon der Unterschied bewußt zwischen einem
> Plan der die Struktur von etwas beschreibt und einem
> Programm welches einen Algorithmus beschreibt.

Zum Teil, ja.


> Aus Deiner Antwort lese ich heraus daß Du der Meinung
> bist daß man Algorithmen besser in Bildern notiert?

Nein.

Aber wer sagt denn, dass man das Sollverhalten
programmierbarer binärer Schaltsysteme immer am Besten
in Form von Algorithmen formuliert?

Genau das ist nämlich der Punkt, in dem Peters Kritik
unqualifiziert ist -- obwohl er, wenn man es ganz wörtlich
nimmt, im mancherlei Hinsicht durchaus Recht hat.

Ein SPS-Programm beschreibt nämlich KEINEN Algorithmus,
sondern einen (i.d.R. endlichen) AUTOMATEN: Es werden
Zustände benannt; dann werden Bedingungen formuliert,
unter denen Zustände in andere Zustände übergehen, und
schließlich wird festgelegt, welche Ausgangssignale in
welchem Zustand erzeugt werden sollen.

Als Folge dessen ist (wenn wir uns mal auf AWL oder FUP
beschränken) die Frage "Wie formuliere ich für die SPS
eine for-Schleife?" sinnlos. AWL kennt keine Schleifen.
Man verwendet statt dessen einen Zähler und leitet davon
ein passendes Freigabesignal ab.
Der Charme dieser Geschichte ist, dass die SPS keine
Blockierungen durch Warten kennt -- denn die SPS wartet
nicht. Muss sie auch nicht. Jede SPS hat eingebaute
Parallelisierung. Eine Rundtischmaschine mit 12 Stationen
und Hunderten von Sensoren und Aktoren kann von einer SPS
mit einer CPU blockierungsfrei gesteuert werden. Das
gehört zum Alltagsgeschäft.


> Warum verwenden dann so viele noch textuelle
> Programmiersprachen? Weil sie das Licht der Erleuchtung
> noch nicht gesehen haben?

In gewisser Weise, ja :)

Nein, im Ernst: Es geht (mir) weniger um textuelle oder
graphische Programmierung.
Der entscheidende Punkt ist, dass man eine SPS klassisch
NICHT dadurch programmiert, dass man einen ALGORITHMUS
eingibt, sondern dadurch, dass man ENDLICHE AUTOMATEN
beschreibt (Eingangssignale, Ausgangssignale, Zustände,
Überführungsfunktion, Ausgabefunktion).

Das ist genauso eine eigene Denkweise wie z.B. der
Entwurf relationaler Datenbanken.

Das Ärgernis aus meiner Sicht ist, dass normale
PC-Programmierer i.d.R. für diese Besonderheit völlig
blind sind und aus der Tatsache, dass SPS älter sind
als der PC, folgern, das sei alles total veralteter
und überholter Schrott.

Genau das Gegenteil ist richtig: Die "Objekte" der
"objektorientierten Programmierung" sind auch weiter
nichts als Automaten (allerdings nicht zwingend
ENDLICHE Automaten) -- nur kann die Mehrheit der
PC-Programmierer das nicht wissen, weil sie sich ja
nicht für solchen "total veralteten Schrott" wie
z.B. SPS interessiert.

: Bearbeitet durch User
Autor: Thomas W. (thomas_v2)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Egon D. schrieb:
> Als Folge dessen ist (wenn wir uns mal auf AWL oder FUP
> beschränken) die Frage "Wie formuliere ich für die SPS
> eine for-Schleife?" sinnlos. AWL kennt keine Schleifen.
> Man verwendet statt dessen einen Zähler und leitet davon
> ein passendes Freigabesignal ab.

Ein üblicher Assembler kennt auch keine For-Schleifen.
So wie es sich bei Peda anhört, hat er mit einem AG-Abzug gearbeitet. 
Das ist so ziemlich das Gleiche, wie wenn er an von jemand anderem in C 
geschriebenen Programm nicht am Quellcode weiterarbeitet, sondern das 
Hex Binary verwendet und das in Assembler zurückkonvertiert und an 
diesem weiterarbeitet.

Eine SPS macht nichts anderes als ein Microcontrollerprogramm. Bei 
Siemens entspricht der OB1 der endlosen while(true){} Schleife, OB35 
usw. entspricht den Interrupts, ein Datenbaustein entspricht einer 
globalen Struct, ein FC ist eine Funktion, ein FB ist eine Funktion 
welche als ersten Parameter ein Zeiger auf eine globale Struct besitzt, 
und da gibt es noch viele weitere Ähnlichkeiten.

Wenn jemand von der meistens ereignisorientierten PC-Programmierung 
kommt, kann ich es verstehen warum sich jemand mit der 
SPS-Programmierung anfangs schwer tut. Aber für jemanden der von der 
Microcontroller-Seite her kommt, ist es mir unverständlich.

Autor: Egon D. (egon_d)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Thomas W. schrieb:

> Egon D. schrieb:
>> Als Folge dessen ist (wenn wir uns mal auf AWL oder FUP
>> beschränken) die Frage "Wie formuliere ich für die SPS
>> eine for-Schleife?" sinnlos. AWL kennt keine Schleifen.
>> Man verwendet statt dessen einen Zähler und leitet davon
>> ein passendes Freigabesignal ab.
>
> Ein üblicher Assembler kennt auch keine For-Schleifen.

Nun, zumindest für den Z80 ist das falsch ("DJNZ").


> Eine SPS macht nichts anderes als ein Microcontrollerprogramm.

Das ist eine Null-Aussage.
Jede turing-vollständige Anordnung "macht nichts anderes"
als eine andere turing-vollständige Anordnung.

Ist deswegen Java identisch mit Brainfuck?


> Bei Siemens entspricht der OB1 der endlosen while(true){}
> Schleife, OB35 usw. entspricht den Interrupts, ein
> Datenbaustein entspricht einer globalen Struct, ein FC ist
> eine Funktion, ein FB ist eine Funktion welche als ersten
> Parameter ein Zeiger auf eine globale Struct besitzt, und
> da gibt es noch viele weitere Ähnlichkeiten.

Du sagst es. Die entscheidenden Worte sind "entspricht"
und "Ähnlichkeiten".


> Wenn jemand von der meistens ereignisorientierten
> PC-Programmierung kommt, kann ich es verstehen warum sich
> jemand mit der SPS-Programmierung anfangs schwer tut. Aber
> für jemanden der von der Microcontroller-Seite her kommt,
> ist es mir unverständlich.

Nun ja.
Du könntest ja einfach Deine Voraussetzung, dass alles
dasselbe ist, und dass dies auch für jedermann völlig
offensichtlich ist, mal fallenlassen.

Vielleicht kommt das Verständnis dann langsam.

Autor: Michael M. (deltal)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Um auf Peters frage zurückzukommen.. komplexe Systeme wie in deiner 
Aufgabe brauchen schon etwas Erfahrung. Aber warum man dich 3-4 Monate 
mit dieser Aufgabe sitzen lässt ist mir nicht begreiflich, hier hätte 
der Praktikumsbetrieb dir unter die Arme greifen sollen.

Im Prinzip geht es auch beim SPS Programmieren darum ein System in 
einzelne Funktionen aufzuteilen und das ganze Stück für Stück 
zusammenzusetzen. Hat man so etwas noch nie gemacht und bekommt man 
keine Unterstützung endet das in dem erwähnten "Kraut und Rüben".

Der Job endet jedoch nicht bei dem Schreiben von Programmen hier kommen 
auch noch Aufgaben wie Antriebstechnik, Sensorik, Elektronik, Safety und 
die oft unterschätzte Praxis wo sich ein Programm bewähren muss. 
Simulation ist in der SPS Welt oft ein Fremdwort (wegen der Komplexität 
einer Anlage nicht weil die Programmierer das nicht wollen/können)

Leider sind die Anforderungen für einen SPS Programmier oft 
unterschätzt. Der Facharbeiter hat zwar gelernt wie man logische 
Verknüpfungen erstellt und das mag auch hier und dort ausreichen. Mit 
moderen "Eierlegendenwollmichsau" Maschinen sollte man schon das eine 
oder andere Programmierwerkzeug mehr in seiner Tasche haben.

Ich programmiere übrigens in SCL (IF/CASE/FOR/WHILE..) aber das reicht 
ja auch nur zum Kinderkram.

Autor: A. S. (achs)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Egon D. schrieb:
> Das ist genauso eine eigene Denkweise

Das trifft es sehr gut. Bei gleicher Aufgabe (ein paar hundert Aktoren 
mittels Sensoren automatisieren) ähnelt die embedded 
C(++)-Programmierung dann auch wieder der SPS-Loop (und wird auch so 
bezeichnet).

Und jedem neuen Event-Glücksritter fehlt dann die Zeit, den ganzen 
Sch**ß  modern/richtig/einfacher/besser zu machen. Geld ist dabei kein 
Problem, weil auch dem Management klar ist, wie überholt das ist. 
Entweder schlägt die Rente zu oder es warten schon mit Prophezeiung des 
Erfolges neue Abenteuer.

Autor: Chris D. (myfairtux) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Egon D. schrieb:
>> Warum verwenden dann so viele noch textuelle
>> Programmiersprachen? Weil sie das Licht der Erleuchtung
>> noch nicht gesehen haben?
>
> In gewisser Weise, ja :)
>
> Nein, im Ernst: Es geht (mir) weniger um textuelle oder
> graphische Programmierung.
> Der entscheidende Punkt ist, dass man eine SPS klassisch
> NICHT dadurch programmiert, dass man einen ALGORITHMUS
> eingibt, sondern dadurch, dass man ENDLICHE AUTOMATEN
> beschreibt (Eingangssignale, Ausgangssignale, Zustände,
> Überführungsfunktion, Ausgabefunktion).

Das war auch meine Überlegung, als im Thread weiter oben die 
Unterscheidung zwischen grafischer und textueller Programmierung aufkam 
- mit der Frage: "Wo hast Du selbst schon grafisch programmiert bzw. 
könntest Du Dir es als übersichtlicher vorstellen?"

Und als Antwort kam ich in der Tat auf die FSM, bei denen ich 
mittlerweile den entsprechenden C-Code fast nur noch über 
Graphendarstellung generieren lasse.

Das empfinde ich dort in der Tat als viel übersichtlicher und auch 
schneller als textuelle Programmierung.

> Das Ärgernis aus meiner Sicht ist, dass normale
> PC-Programmierer i.d.R. für diese Besonderheit völlig
> blind sind und aus der Tatsache, dass SPS älter sind
> als der PC, folgern, das sei alles total veralteter
> und überholter Schrott.

Ich selbst kenne mich mit der SPS-Programmierung (noch) gar nicht aus, 
habe hier aber offenbar eine alte und einfache S5 im Drehautomaten 
hängen und werde mich in Kürze damit beschäftigen - und ich freue mich 
darauf :-)

> Genau das Gegenteil ist richtig: Die "Objekte" der
> "objektorientierten Programmierung" sind auch weiter
> nichts als Automaten (allerdings nicht zwingend
> ENDLICHE Automaten) -- nur kann die Mehrheit der
> PC-Programmierer das nicht wissen, weil sie sich ja
> nicht für solchen "total veralteten Schrott" wie
> z.B. SPS interessiert.

Vielleicht etwas Offtopic:

Das Thema "grafische Programmierung" kam schon in meinem Studium immer 
mal wieder auf, aber durchgesetzt hat sie sich in der Breite nicht.

Mich würde wirklich interessieren, warum das so ist.

Liegt das an nur wenigen, schlechten Werkzeugen (Texteditoren und IDEs 
gibt es wie Sand am Meer)?

Oder ist es wirklich Voreingenommenheit der Anwender (einfach hier 
entsprechende Threads C/ASM/Pascal oder Linux/Windows verfolgen ;-)?

Oder sprechen wirklich handfeste Gründe gegen diese Art der 
Programmierung?

: Bearbeitet durch Moderator
Autor: Peter P. (huloka12)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Michael M. schrieb:
> Um auf Peters frage zurückzukommen.. komplexe Systeme wie in
> deiner
> Aufgabe brauchen schon etwas Erfahrung. Aber warum man dich 3-4 Monate
> mit dieser Aufgabe sitzen lässt ist mir nicht begreiflich, hier hätte
> der Praktikumsbetrieb dir unter die Arme greifen sollen.


Naja, mir wurde da so sporadisch mal Hilfestellung gegeben.. "Zeichne 
doch erstmal die bestehenden Schrittketten auf" .. Aber bei Detailfragen 
konnten/wollten mir die Kollegen dann leider nicht helfen und ich musste 
mir quasi alles selbst erarbeiten (was man von einem Absolventen ja auch 
prinzipiell erwarten kann)..

Das Praktikum war halt generell ein Schuss in den Ofen. Es war, wie 
gesagt, in der Engineeringabteilung eines produzierenden Unternehmens. 
Die HR hatte die Praktikumsstelle zwar wunderbar ausgeschrieben, aber 
ich war dann wohl der erste Praktikant dort in der Abteilung und die 
Kollegen wussten so ziemlich nichts mit mir anzufangen, was sie mir auch 
direkt gesagt hatten..

Genug Bewerbungen bekam das Unternehmen dank Chemie-Tarifvertrag wohl 
auch, weshalb die das Praktikum wohl auch nicht als Möglichkeit gesehen 
haben, Nachwuchs anzuwerben. Im Nachhinein wäre ich besser direkt zu 
Anlagenhersteller gegangen, aber man lernt ja aus Fehlern.

Doof nur, dass ich für die sechs Monate - außer ner netten Station im 
Lebenslauf - kaum was von dem Praktikum hatte..

> Der Job endet jedoch nicht bei dem Schreiben von Programmen hier kommen
> auch noch Aufgaben wie Antriebstechnik, Sensorik, Elektronik, Safety und
> die oft unterschätzte Praxis wo sich ein Programm bewähren muss.
> Simulation ist in der SPS Welt oft ein Fremdwort (wegen der Komplexität
> einer Anlage nicht weil die Programmierer das nicht wollen/können)


Jep, das hat mich auch stark gewundert. Besagte Anlage war ne 
Abfüllanlage mit einem Durchsatz von ein paar hunderttausend Einheiten 
am Tag. Die hätten mich da ernsthaft irgend nen Programm 
zusammenpfuschen und das aufspielen lassen.. Es ging ja nicht nur um das 
Programm, das ganze sollte ja gleichzeitig von ner S7-300 auf ne 1500 
migriert werden, also inkl. Hardwaretausch usw..

Sowas - im laufenden Betrieb - mal eben nen Praktikanten machen zu 
lassen.. Auf meine Frage, ob man so n Programm nicht vorher mal testen 
würde, bevor man das auf die Anlage tut und das da scheiße baut, wurde 
mir nur gesagt, das wäre nicht üblich und das ginge auch nicht.

Am besten war noch der Spruch meines Betreuers: "Wenn du damit fertig 
bist, kannst du ja noch den Steuerungs-PC neu machen. Der ist auch schon 
etwas in die Jahre gekommen" (der war dann aber wohl in einer 
Hochsprache programmiert, denke ich). Die Anlage war übrigens vom 
Hersteller Serac, wenn jemandem das was sagt.


Finde es halt schade, dass mit motivierten Praktikanten, die Leistung 
zeigen wollen, so umgegangen wird. Woanders werden SPS-Programmierer ja 
händeringend gesucht, was mir div. Anzeigen von Headhuntern auf xing 
jetzt nachm Jobeinstieg gerade zeigen.. ("Sie haben mal was mit SPS 
gemacht.. Wir suchen für nen Kunden da jemanden..")

Autor: Markus M. (mmvisual)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sps Programmierung ist extrem anspruchsvoll und darf von Anfang an nie 
unterschätzt werden. Eine einfache Klimagerät Steuerung ist wohl eher 
seltener an zu treffen. Vielmehr steuert man ein Teil einer 
Fertigunslinie und da gibt es jede Menge fremde Teilnehmer die per 
Profinet an zu steuern sind. Mein letztes Projekt hatte ca. 50 TCP/IP 
Adressen, Verbindung über Netzwerk zu PC's und 3 Kukas angesteuert. 
Einzelteileverwaltung wo jedes Stück andere Maße hatte, Kommunikation 
mit SAP und komplette Verfolgung und Weiterleitung "Industrie 4.0". 
Verwaltung der Einzelteile in einem Kardex Tower mit 36 Schubladen hatte 
ich dann doch in einem PC mit Datenbank ausgelagert (sucht Platz für das 
Teil in den Tablaren).
Die komplexere Abläufe schreib ich in SCL, die einzelnen FB's fasse ich 
in KOP zusammen.

Viele meckern über Siemens und TIA - ist wohl eher meckern auf hohem 
Niveau. Liegt wohl eher daran dass sie mit der Aufgabe überlastet sind. 
Ich kenne kein besseres Tool als TIA. Geht man auf einer Variable auf 
die Querverweis Liste, sieht man sofort alles. Auch das HMI und die 
Steuerung spielen immer zusammen, selbst wenn man den Variablen Name in 
der SPS ändert ist die noch immer verbunden. Oder OnlineChannge um ohne 
den komplexen Prozess zu beenden mal eine Kleinigkeit zu ändern. 
Natürlich kommen die ein oder anderen Probleme immer mal wieder, sind 
auch lösbar, dafür hat man bei anderen Steuerungen andere Probleme.
Über die letzten Jahrzehnte habe ich mir solche Ablauf Strukturen 
entwickelt und ständig verfeinert die nahezu auf jede komplexe Anlage 
sehr einfach anwendbar sind. Ein simples Grundkonzept mit Aufzeichnung 
der letzten Prozessschritte machen die Diagnose bei der Inbetriebnahme 
leichter. Es gib Leute die schwören auf Beckhoff oder eine andere 
Steuerung. Schlussendlich ist man als Programmierer davon abhängig was 
der Kunde gerne für eine einsetzen mag. Siemens ist der Platzhirsch hier 
zu Lande, wenn ein Steuerungsbauer Technik von Siemens einsetzt wird der 
Verkäufer sich nie rechtfertigen müssen gegenüber dem Kunden. Bei exoten 
muss er schon gute Gründe erzählen können warum der Endkunde seine 
Lagerhaltung erweitern sollte.
Und nein, mich kann man nicht kaufen, bin ausgebucht für dieses Jahr.

: Bearbeitet durch User
Autor: Unbekannt U. (unbekannter)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Chris D. schrieb:
> Das Thema "grafische Programmierung" kam schon in meinem Studium immer
> mal wieder auf, aber durchgesetzt hat sie sich in der Breite nicht.
>
> Mich würde wirklich interessieren, warum das so ist.

Das ist einfach: Aus dem gleichen Grund, warum wir uns nicht mehr per 
Höhlenmalerei unterhalten...

Grafik ist toll für die groben Konzepte und Übersichtspläne, wie was 
zusammenhängt. Aber eben von Menschen für Menschen.

Algorithmen und Softwarekonstrukte sind komplex. Mit textuellen 
Programmiersprachen schafft man sich beliebig viele Abstraktionen, mit 
denen es sich viel besser Arbeiten lässt. Schriftsprache enthält viel 
mehr eindeutige Informationen.

Streng genommen benötigt man nur ein AND (oder ein OR, ist ja egal), ein 
NOT und ein BOOL. Damit kann man das komplette Internet bauen, 
einschließlich diesem Forum.
Macht aber keiner. Kurz nach dem Bit kam schon das Byte. Addieren und 
die ganzen anderen Operationen auch. Dazu kommen Schleifen, Bedingungen, 
Datenstrukturen etc. Später kommen Module, Klassen, Bibliotheken und, 
und, und. Wie willst Du das alles mit Bildchen kommunizieren?

Was meinst Du, hätte ich alles an die Höhlenwand pinseln müssen, um Dir 
meinen Standpunkt mit Grafiken mitzuteilen?

Autor: Egon D. (egon_d)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Chris D. schrieb:

> Und als Antwort kam ich in der Tat auf die FSM, bei
> denen ich mittlerweile den entsprechenden C-Code
> fast nur noch über Graphendarstellung generieren
> lasse.

Das ist interessant. Magst Du ein paar Worte über die
konkreten Anwendungen, die verwendeten Werkzeuge und
Deinen Arbeitsablauf sagen?


>> Das Ärgernis aus meiner Sicht ist, dass normale
>> PC-Programmierer i.d.R. für diese Besonderheit völlig
>> blind sind und aus der Tatsache, dass SPS älter sind
>> als der PC, folgern, das sei alles total veralteter
>> und überholter Schrott.
>
> Ich selbst kenne mich mit der SPS-Programmierung (noch)
> gar nicht aus, habe hier aber offenbar eine alte und
> einfache S5 im Drehautomaten hängen und werde mich in
> Kürze damit beschäftigen - und ich freue mich darauf :-)

Oho! Na dann: Gut Holz!

Sei aber gewarnt: S5 ist meiner Erinnerung nach deutlich
murksiger als die S7.


>> Genau das Gegenteil ist richtig: Die "Objekte" der
>> "objektorientierten Programmierung" sind auch weiter
>> nichts als Automaten (allerdings nicht zwingend
>> ENDLICHE Automaten) -- nur kann die Mehrheit der
>> PC-Programmierer das nicht wissen, weil sie sich ja
>> nicht für solchen "total veralteten Schrott" wie
>> z.B. SPS interessiert.
>
> Vielleicht etwas Offtopic:
>
> Das Thema "grafische Programmierung" kam schon in
> meinem Studium immer mal wieder auf, aber durchgesetzt
> hat sie sich in der Breite nicht.
>
> Mich würde wirklich interessieren, warum das so ist.
>
> Liegt das an nur wenigen, schlechten Werkzeugen
> (Texteditoren und IDEs gibt es wie Sand am Meer)?

Das glaube ich nicht.


> Oder ist es wirklich Voreingenommenheit der Anwender
> (einfach hier entsprechende Threads C/ASM/Pascal oder
> Linux/Windows verfolgen ;-)?

Ich weiss es nicht wirklich; schließlich bin ich nur
autodidaktischer Dilettant, der ab und zu in den
Gefilden der Informatik wildert.

Keine Ahnung, ob das zur Klärung Deiner Frage beiträgt, aber
ich habe das Gefühl, dass unter Programmierern das Modell
des Automaten -- und alles, was damit zusammenhängt -- in
äußerstem Maße unbeliebt ist.
Echte Programmierer (tm) denken zwanghaft in sequenziellen
Abläufen: Eine (sic!) CPU "ist" an einer "bestimmten Stelle"
im Programmablauf. Jetzt werden bestimmte Operationen
ausgeführt, bestimmte Entscheidungen getroffen, und an eine
"bestimmte andere Stelle" verzweigt.

Einen Computer einfach als programmierbaren Zuordner
aufzufassen, der bestimmte binäre Eingangsvektoren auf
bestimmte binäre Ausgangsvektoren abbildet, wobei die
konkrete Abbildung noch von einer verborgenen Variablen
(dem Zustand) abhängt -- das geht ja gar nicht. Das ist
eine zutiefst vulgäre Auffassung, die vielleicht den
allseits verachteten Elektro-Ingenieuren ziemt,
keinesfalls aber einem Informatiker!

Nun sind es aber gerade Zustände und ihre Übergänge, die
sich graphisch gut repräsentieren lassen -- nämlich in
Form von Automatengraphen.

Ich weiss nicht, ob es da einen Zusammenhang gibt, aber
es wird behauptet, dass im amerikanischen Sprachraum die
funktionalen Sprachen einen völlig anderen Stellenwert
in der Ausbildung hätten, als das in Kontinentaleuropa
der Fall ist.
Aus der VHDL-Ecke ist immer mal wieder zu hören, dass
"normale" Programmierer häufig Probleme mit VHDL haben,
eben weil sie es so schreiben, wie man ein C-Programm
schreiben würde. Das kann natürlich nicht funktionieren,
eben weil programmierbare Logik zwar PROGRAMMIERBAR ist,
aber NICHT primär einen ALGORITHMUS realisiert.


> Oder sprechen wirklich handfeste Gründe gegen diese
> Art der Programmierung?

Keine Ahnung, ob meine Interpretation stimmt, aber ich
kann mir schon vorstellen, dass man Algorithmen am
Besten textuell beschreibt -- nur muss "Programmieren"
ja nicht zwingend das Beschreiben von ALGORITHMEN sein.
Man könnte ja auch AUTOMATEN beschreiben, und dafür ist
der Automatengraph eine recht nette Repräsentation.

Vielleicht ist in Wahrheit auch alles ganz anders... :)

Autor: Egon D. (egon_d)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Unbekannt U. schrieb:

> Das ist einfach: Aus dem gleichen Grund, warum wir
> uns nicht mehr per Höhlenmalerei unterhalten...

Du irrst.

Jeder Zerspaner-Lehrling will eine normgerechte ZEICHNUNG.
Jeder Architekt, jeder Bauleiter, Installateur, Elektriker,
Elektroniker, jeder Hydraulikfritze... und sogar jeder
Gartenbauer und jeder Modefritze oder Schneider will eine
ZEICHNUNG sehen.

NUR mit Computern müssen wir in Textform kommunizieren,
weil Computer traditionell dumm sind und man ihnen haarklein
in ihrer eigenen Sprache sagen muss, was sie nacheinander
machen sollen -- statt ihnen mitteilen zu können, was am
Ende herauskommen soll.

Und WEIL Computer so dumm sind, halten sich die Echten
Informatiker (tm) für die Krone der Schöpfung...

Was für eine Ironie.

Autor: Egon D. (egon_d)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
A. S. schrieb:

> Und jedem neuen Event-Glücksritter fehlt dann die Zeit,
> den ganzen Sch**ß  modern/richtig/einfacher/besser zu
> machen.

Hmm. Was willst Du damit sagen?

Bist Du der Meinung, man sollte, statt AWL zu verwenden,
alles in C++ schreiben?

Ich meine... dass AWL murksig ist, steht meiner Meinung
nach außer Frage, aber... ob C++ da die angemessene
Antwort ist?

Autor: A. S. (achs)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Chris D. schrieb:
> Mich würde wirklich interessieren, warum das so ist.

Dort, wo es sinnvoll ist, wird es ja gemacht:
- wo physische repräsentierung wichtig sind, egal ob baupläne oder 
gui-designer. (OT: darum sind dynamische GUIs selten oder schwierig)
- wo es relativ einfach ist (wenn fachfremde was zusammenklicken 
sollen), labviev.
- wo Verdrahtung / Kombinatorik im Vordergrund steht. Schaltpläne, 
Verdrahtungspläne, teilweise SPS/FPGA.

Und wenn man bei Schaltplänen dann das Resultat (die Netzlisten) 
vergleicht, stellt man fest, dass der Übergang fließend ist. Wenn Du 2-3 
große FPGAs hast, dann gleicht der Schaltplan oft einer zerrissen 
Netzliste mit globalen Bezeichnern.

: Bearbeitet durch User
Autor: Bernd K. (prof7bit)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Egon D. schrieb:
> Nun sind es aber gerade Zustände und ihre Übergänge, die
> sich graphisch gut repräsentieren lassen

Ja, aber nicht das was bei den Übergängen zu geschehen hat, das lässt 
sich besser hinschreiben als hinmalen. Ein Automatengraph ist nur ein 
leeres Gerüst, er wird erst aussagekräftig wenn vollständig beschreibt 
wie das Ding mit seiner Umgebung interagiert, was die Trigger sind und 
was die Übergänge machen. In einer Doku kann zu einem Automatengraphen 
typischerweise noch mit mehreren Seiten Prosa oder tabellarischer 
Aufzählung gerechnet werden die jeden Trigger, jeden Zustand und jeden 
Übergang mehr oder weniger vollständig erläutern ohne die es nur ein 
hübsches Bildchen wäre.

Das leere Gerüst eines Automaten kann man in jeder Programmiersprache in 
wenigen Zeilen Code hinschreiben so kompakt daß typischerweise pro 
Zustand und pro Übergang nur eine Zeile Boilerplate übrigbleibt, die 
restlichen 99% zwischen diesen Zeilen müssen mit "normalem" Code 
gefüllt werden der dann die eigentliche Arbeit tut, Ausdrücke auswertet, 
interne Unterzustände manipuliert, Entscheidungen trifft, Aktionen 
auslöst, gegebenenfalls einen Zustandsübergang auslöst. Das folgt keiner 
festen Struktur, das kann beliebig komplex werden und schreit nach einer 
Sprache mit ausreichend flexiblen Sprachkonstrukten.

Der zweite Punkt ist Versionskontrolle: Mach mal ein diff über zwei 
Diagrammne oder versuche die Änderungen die in den letzten 2 Monaten in 
Projekt A eingeflossen sind ins Projekt B zu mergen oder zwecks 
Fehlersuche die Unterschiede zwischen zwei fast identischen Projekten 
einzeln zu identifizieren und zu isolieren. Für Text existieren da 
mittlerweile extrem mächtige Werkzeuge denen sich ein 
"konventioneller" Programmierer heute routinemäßig bedient ohne groß 
drüber nachzudenken. Ist der selbe Komfort auch schon bei einhändigen 
Zeige-und-Klick-Sprachen¹ verfügbar und üblich?


---
¹) Off-Topic, bitte nicht darauf einrasten: "Zeige-und-Klick" erinnert 
mich stark an die Kommunikationsbandbreite eines Säuglings: Auf etwas 
Zeigen und einen Laut von sich geben. Allerdings hat der Säugling 2 Arme 
und kann mehr Geräusche machen als nur "Da" und "DaDa" (Doppelklick) und 
"GaGa" (rechte Maustaste). Das Erlernen von Sprache und Schrift wird in 
diesem Zusammenhang auch generell als Fortschritt gefeiert, als 
wichtigsten Meilenstein überhaupt, den man stolz dokumentiert und 
feiert, ganz anders jedoch bei der Kommunikation mit Computern, da 
möchte man sich auf Teufel komm raus gerne zurückentwickeln und auf 
Sprache und Schrift so weit wie möglich verzichten, nur noch auf Dinge 
zeigen und "Dada" und "Gaga" sagen und diesen Rückschritt in der 
Kommunikation als Fortschritt feiern und gerne das meiste Geld für das 
am stärksten kommunikationsgestörte System ausgeben das man finden kann, 
verstehe das wer will ;-)

: Bearbeitet durch User
Autor: A. S. (achs)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Egon D. schrieb:
> Hmm. Was willst Du damit sagen?
>
> Bist Du der Meinung, man sollte, statt AWL zu verwenden,
> alles in C++ schreiben?

Nein. Überhaupt nicht. Deine

Egon D. schrieb:
> Keine Ahnung, ob das zur Klärung Deiner Frage beiträgt, aber
> ich habe das Gefühl, dass unter Programmierern das Modell
> des Automaten -- und alles, was damit zusammenhängt -- in
> äußerstem Maße unbeliebt ist. ....

kann ich nur unterschreiben.

Und wenn Automaten in C(++), dann (wie ich schrieb) vorzugsweise im Stil 
der SPS-Loop. Und natürlich sehe ich auch einen Vorteil von grafischen 
Programmiersprachen wie Kontaktplan etc., da wo es vor allem um 
Verknüpfungen geht.

Ich bin ja auch nur Autodidakt, aber 2 fundamentale Erkenntnisss aus 20 
Jahren Automation haben sich bei mir herauskristalisiert:

1) In der Automation reduziert "Loop" die Komplexität meist besser als 
"Event".

2) Bei konkreten(*) Objekten greifen die meisten OOP-Paradigmen nicht 
(im Gegensatz zu virtuellen(*) Objekten)

(*) wobei ich hier "konkret" für dedizierte Sensoren/Aktoren/Entitäten 
der echten Welt meine, die eine konkrete Aufgabe oder Position haben. 
Z.B. im Auto das Rad vorne links. "Virtuell" dagegen alle Objekte, von 
denen ein Programm zur Laufzeit neue sinnvoll instanziieren könnte, z.B. 
zusatz-Bremsleuchten.

Das ist m.E. ein Grund, warum Autosar auf C (statt C++) setzt. Natürlich 
programmiert man auch in C "objektorientiert", im Sinne von Klassen 
(structs und Methoden die auf diesen Structs arbeiten). Es wäre aber 
absurd, den Kontrollfluss eines ESPs wegzukapseln und dann zu versuchen, 
die konkreten Unterschiede (in Eigenschaften und Verknüpfungen) der 4 
Räder durch Attribute des Ojektes "Rad" zu modellieren.

Das ist z.B. ein Grund, warum wir für unsere 
Haupt-Automations-Applikation C vorschreiben, obwohl der HAL (und die 
komplette Toolchain) C++ nativ spricht und der Code (z.B. durch 
constExpr, Überladung, Lambda-Funktionen) kleiner und schneller wäre. 
Bei unserer Visu, Kommunikationsschnittstellen oder OPC-Servern wäre es 
hingegen sträflich, nicht OOP (oder funktional) einzusetzen.

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail, Yahoo oder Facebook? Keine Anmeldung erforderlich!
Mit Google-Account einloggen | Mit Facebook-Account einloggen
Noch kein Account? Hier anmelden.