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..
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.
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.
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.
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?
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.
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?
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
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.
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?
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...
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.
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?
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.
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.
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.
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.
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.
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
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..")
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
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?
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... :)
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.
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?
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.
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
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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.