# Vorgehen bei Programmerstellung



## Georgius (8 August 2008)

Hi,

da es hier ja doch so einige SPS-Programmierer gibt, hoffe ich auf meine Frage eine oder mehrere Antworten zu erhalten.
Wie geht ihr bei der Programmerstellung vor? Werden Verfahren wie Funktionsdiagramme/ Weg-Schrittdiagramm, (neuerdings) Grafcet oder Motoren und Komponentenliste benutzt?
Wie erläutert man Menschen ein Programmablauf (SPS) die zum ersten mal auf das SPS-Programm (also auf ein neues Programm, nicht generell auf SPS-Programme) schauen.
Wie ist das Vorgehen in eurer Firma?
Hintergrund:
Ich schreibe meine Diplomarbeit in einem Unternehmen und soll auch ein SPS Programm erstellen. Dabei muss aber beachtet werden, dass dies vom ersten Gedanken bis zur Umsetzung verständlich funktioniert. Derzeit ist es so, dass sich ein Programmierer in sein Büro verkriecht und allte Programme, kopiert, erweitert, modifiziert. Man will jedoch auch externen Programmierer eine Möglichkeit geben, etwas zu programmieren. Diesen muss also deutlich gemacht werden, was die Anlage tun soll.
Und genau darum geht es. In welcher Form wird dieses Wissen vom Konstrukteur in eine "programmierbare" Form übergeben?
Über Antworten würde ich mich sehr freuen.


----------



## kiestumpe (8 August 2008)

*Programmerstellung / Softwareentwicklung*

Vorab: Wir entwickeln Software, Codierung oder Programmerstellung ist nur ein kleiner Teil davon

Eine mögliche Vorgehensweise ist das V-Modell:

1. Lastenheft
2. Pflichtenheft/Funktionsbeschreibung (Word / Visio)
3. Software-Design-Spezifikation, Schaltplan, Pneumatikplan, E/A-Liste, Bibliotheksdokumentation, HDS, Ablaufpläne
4. Codierung
5. Test, Testdokumente bezgl. Spezifikationen (es wird nachgewiesen, dass
das was spezifziert wurde auch drin ist )
6. Qualifizierung / Validierung.

Da sich 2 und 3 hin und wieder ändern muss ein Change-ControlManagement vorhanden sein (Änderungen und ihre Behandlung)

Leider wird dieses Vorgehen so selten angewendet, in deinem Fall scheint das auch nicht so zu sein. Es muss das Bestreben von allen Seiten vorhanden sein, es umsetzen zu wollen und erfordert von den Strategen einiges an Erfahrung und Geschick dies umsetzen zu wollen.
manchmal geht es schneller, wenn ein 'Externer', die viel Geld dafür bekommt, eine gute Beratung durchführt und sowas installiert ;-)

Nochmal zurück auf Ablaufdiagramme, engineering :TOOL: Nr.1 ist immer noch Word, evt. mit Visio wenn man etwas "malen" will.

So, hoffe das hilft dir weiter, oder gibt ein paar Anregung.
viel Erfolg


----------



## Georgius (8 August 2008)

Hey danke,

das ist schonmal ein Ansatz. Das mit dem V-Modell hatte ich auch gelesen, jedoch wurde angemerkt, dass es zwar sehr vorteilhaft hinsichtlich der Handhabung ist, jedoch in der Praxis nicht wirklich verbreitet ist, da es schlicht zu aufwändig ist.


----------



## Pietpinguin (10 August 2008)

*Programmerstellung*

1. Erstellung eines Pflichtenheftes. Das Pflichtenheft beinhaltet die Funktionsbeschreibungen aller einzelnen Aggregate für den Hand- und Automatikbetrieb. Weitere Bestandteile des Pflichtenheftes sind z.B. Verriegelungen, Störmelde- Quittierkonzept und Anlagenkennzeichen,...

2. Erstellung einer E/A-Liste. Als Grundlage dienen die zuvor angefertigten Stromlaufpläne. Als Symbolname sollte das Anlagenkennzeichen, mit einer entsprechenden Erweiterung für jedes einzelne Signal, benutzt werden. So lässt sich das PRG später strukturiert aufbauen.

3. Festlegung der Groben Programmstruktur nach Funktionsbereichen.

4. Festlegung des Datenaustausches an ein Leitsystem oder Bedienpanel.

5. Kundenspez. Antriebsbausteine usw. erstellen.

6. Programmieren nach Pflichtenheft.

7. Komplexe SPS-Programme z.B. mit WinMOD testen. Lohnt sich...!

Die Verständlichkeit eines SPS-Programmes hängt im wesentlichen von einer klaren Strukturierung und einer deutlichen Kommentierung ab.


----------



## Larry Laffer (10 August 2008)

Ich verstehe die Frage mal als Anforderung an einen selbst.
Für mich stehen vor "Start Progarmmierung" zunächst die Erstellung der Schrittketten. Diese dokumentiere ich mittels meines Schaltplan-Programmes und erstelle nach diesen Schrittkettenbildern(-plänen) schließlich meine Programme. Zu der Dokumentation der Schrittketten gehört hierbei natürlich auch wie selbige miteinander kommunizieren.

Bei diesen Überlegungen entstehen dann in der Konsequenz mögliche Anlagen-Parameter (sofern nicht vorher schon bekannt) und Ankopplungen an die Visu.

Ein Pflichtenheft hat mir bei diesen Dingen in meiner bisherigen Praxis wenig bis gar nicht geholfen bzw. es hat so etwas nur für die Festlegung der Hardware gegeben. Selbstverständlich entwickelt man natürlich mit der Zeit eigene "Standards", die dann soweit möglich auch in unterschiedlichen Projekten immer wieder gerne Verwendung finden.

Ich hoffe, ich konnte ein paar zusätzliche Anregungen liefern.

Gruß
LL


----------



## PLCSmilie (12 August 2008)

*Programmerstellung, Abschätzung des Aufwandes*

Hallo zusammen,

in diesem Zusammenhang interssiert mich noch, nach welchen Methoden Ihr den Aufwand zur Prgrammerstellung abschätzt. Je nach Anforderung kann der Aufwand mehr oder weniger komplex sein. Im Internet habe ich z.B. die Function Point - Methide gefunden. Diese wird jedoch in erster Linie zur Abschaätzung von dialogbasierter Software, z.B. bei Hochsprachen, verwendet. 
Wie geht Ihr bei der Aufwandsabschätzung vor? Für Hinweise oder Methoden vorab vielen Dank.

Gruß

PLCSmilie


----------



## moeins (10 September 2008)

PLCSmilie schrieb:


> Hallo zusammen,
> 
> in diesem Zusammenhang interssiert mich noch, nach welchen Methoden Ihr den Aufwand zur Prgrammerstellung abschätzt. Je nach Anforderung kann der Aufwand mehr oder weniger komplex sein.



Meine Erfahrung sowohl als Auftraggeber/-nehmer hat gezeigt, wenn man als Auftraggeber einen Programmablaufplan beschrieben hat, das eigentliche Programm auch gleich selbst schreiben kann.

Der größte Anteil am SPS-Programm ist das "drumherum" wie Sicherheitsverriegelungen, Kommunikation Profibus/HMI/Antriebsreglern, Störungsverarbeitung und Anpassung von Analogsignalen.
Die Schrittkette ist i.d.R. wenn ein Programmablaufplan vorliegt nur noch ein schnelles runtertippen.

Als Auftraggeber würde ich ohnehin nur einen funktionsfähigen "HAND"-Betrieb vom externen Programmierer bestellen, und den Automatikbetrieb selbst erstellen. 
Damit erspart man sich
1. Knowhow-Transfer 
2. man muß sich nicht um das nervige "drumherum" kümmern 
3. kennt man seinen eigenen Automatikprogrammablauf viel besser.

Gruß
moeins


----------



## Georgius (25 September 2008)

Hi,

ich würde dieses Thema nochmal gerne Auffassen. Welches Mittel
kommt bei euch ausser Word/ Visio noch zur Beschreibung von Steuerungsaufgaben zum Einsatz? Benutzt ihr soetwas wie Weg-Schritt Diagramm oder Grafcet, oder ist da der Aufwand gegenüber dem Nutzen zu hoch?
Wäre klasse, wenn ihr mir dazu auch noch Infos geben könnt.
Danke schonmal


----------



## Larry Laffer (25 September 2008)

Hallo,
die Schrittketten (GraphCet's) stehen bei mir noch vor der eigentlichen Programmerstellung - d.h. es werden zunächst die Schrittketten grafisch erstellt und diese dann im eigentlichen Programm umgesetzt. Für die Erstellung derselben verwende ich/wir unser Elektro-CAD-Programm.

Gruß
LL


----------



## Bösertom (19 Oktober 2008)

*Benötige auch Hilfe*

Hallo,

erst einmal vielen Dank an alle hier im Forum - macht weiter so.

Ich fange im November in einer neuen Firma an, wo ich auch in die Projektierung und Inbetriebnahme bzw. Programmierung eingearbeitet werden soll.
Ich bin nun schon etwas aufgeregt.
Mich würde auch einmal interessieren, in welcher Form man so einen Auftrag/Projekt auf den Schriebtisch bekommt.
Besteht die Möglicheit mir ein Beispiel für einen Projektauftrag (Beispiel von der Uni, Kurse, etc.) zukommen zu lassen, damit ich soetwas auch mal sehen könnte.
Ich würde mich sehr freuen.

mfG
Thomas


----------



## vierlagig (19 Oktober 2008)

ich erinnere mich gut an einen auftrag für die modernisiserung einer wasseraufbereitung, da hat mir mein damaliger chef die epläne (auf russisch) und ein fließbild der anlage (auf russisch) aufm gang in die hand gedrückt mit den worten "machen se mal ein angebot" ... kurz darauf, gefühlte 10 min, war er aufm weg in den urlaub und kein anderer wußte von irgendwas 

selbe firma, anderes erlebnis: auftrag für einen schaltschrank, kein pflichtenheft, aber die möglichkeit beim kunden direkt, die planung zu machen. also hin, mit dem verantwortlichen alles abgeklärt, pläne fertig gemacht, aufbau abgestimmt, alles mit unterschrift. nach auslieferung die meldung: "das entspricht aber nicht unseren vorstellungen" ... der verantwortliche, der die unterschriften gegeben hatte war zum zeitpunkt der auslieferung schon nicht mehr in da, gekündigt - das hieß dann wohl offensichtlich, die unterschriften sind ungültig, vom auftragsvolumen wurden so 80k€ in den sand gesetzt ...

andere firma, anderes erlebnis: "da müssen wir mal was machen - überleg dir mal was" ... mit allen verantwortlichen und evtl. betroffenen geredet, ein konzept erstellt, abzeichnen lassen, umgesetzt und nachher ... das übliche: "früher war alles besser" ...

... an solche sachen gewöhnt man sich irgendwann - früher hab ich mich geärgert und konnte nächtelang nicht schlafen ...

wichtigste regeln:
- hab ein pflichtenheft in der hand
- lass dir liefervorschriften aushändigen (ohne mach ich nischts mehr!)
- hab mindestens zwei ansprechpartner beim auftraggeber
- frag deinen direkten vorgesetzten immer, wenn ein neuer auftrag auf deinem tisc landet, wer da noch von weiß und WAS ER WILL!
- gelassen bleiben, auch beim engsten terminplan! ...unsicherheit und stress bauen dir mehr fehler ein, als irgendetwas anderes

... das gilt für hardware UND software-projekte gleichermaßen ...


----------



## moeins (20 Oktober 2008)

vierlagig schrieb:


> ich erinnere mich gut an einen auftrag für die modernisiserung einer wasseraufbereitung, da hat mir mein damaliger chef die epläne (auf russisch) und ein fließbild der anlage (auf russisch) aufm gang in die hand gedrückt mit den worten "machen se mal ein angebot"


Da werden Erinnerungen an meine erste SPS-Anlage wach . Mein damaliger Chef machte das Angebot und mir wurde es mit den Worten in die Hand gedrückt" Das ist was womit man nach seinem ersten SPS-Lehrgang leicht beginnen kann". 
Es waren dann etwa ~300 E/As mit einer S5-115U und dem ersten vollgrafischen Visualisierungssystem OP30 von Siemens, welchen unter dem Betriebssystem "Comgraph" projektiert werden mußte. Es war schon ein Krampf eine Dos-Maus zu installieren.
Zum Glück gabs keinen Zeitdruck. Es mußte nur über Ostern vom alten System (Schütztechnik) auf S5-Technik umgestellt werden. Hätte es nicht funktioniert, wären täglicher Produktionsausfall von einer halben Mio. DM aufgelaufen...



> "das entspricht aber nicht unseren vorstellungen" ...
> ... mit allen verantwortlichen und evtl. betroffenen geredet, ein konzept erstellt, abzeichnen lassen, umgesetzt und nachher ... das übliche: "früher war alles besser" ...


Das höre ich auch gerne immer wieder...




> wichtigste regeln:
> - hab ein pflichtenheft in der hand
> - lass dir liefervorschriften aushändigen (ohne mach ich nischts mehr!)
> - hab mindestens zwei ansprechpartner beim auftraggeber
> ...


 
dem ist nur noch das hinzuzufügen :
- Überprüfe die Zahlungsfähigkeit deines Kunden (Schufa) 

Ansonsten volle Zustimmung !


----------



## AUDSUPERUSER (20 Oktober 2008)

> wichtigste regeln:
> - hab ein pflichtenheft in der hand
> - lass dir liefervorschriften aushändigen (ohne mach ich nischts mehr!)
> - hab mindestens zwei ansprechpartner beim auftraggeber
> ...


 
Auch ganz wichtig, alles Dokumentieren.
Jedes E-Mail speichern und an Chef und betreffende Kollegen weiter leiten.
Probleme und Änderungen, die Zeit und Geld kosten auflisten und Chef informieren.
Beim Militär heist es "Melden macht frei". 
Ein Programmierer muss schauen, dass er sich so raushaut, dass ihm keiner ans Bein pissen kann und Chef und Projektleiter nicht anderst können, als die Verantwortung zu übernehmen.

Gruss
Audsuperuser


----------



## Bösertom (24 Oktober 2008)

*...keine Möglichkeit*

Hallo,

vielen Dank erstmal für die Antworten.

Leider besteht anscheinden keine Möglichkeit, soetwas (vielleicht in Anszügen) gezeigt zu bekommen.
Schade!

Gruß
Thomas


----------



## vierlagig (24 Oktober 2008)

Bösertom schrieb:


> Leider besteht anscheinden keine Möglichkeit, soetwas (vielleicht in Anszügen) gezeigt zu bekommen.
> Schade!



ja, tut mir ja auch leid, aber es gibt dafür kein muster-blatt nach IEC4711, das passiert immer anders und immer irgendwie neu...


----------



## Bösertom (24 Oktober 2008)

Hallo,

vielen Dank vierlagig.
Ich bin nur einwenig nervös, weil ich nächste Woche bei meinem neuen Arbeitgeber dann wahrscheinlich ins kalte Wasser geworfen werde. Dann lernt man zwar vielleicht schneller schwimmen aber beruhigter wäre ich anders.
Meiner neuer Chef sagt zwar jeder "normale" Elektriker mit etwas normalem logischen Verständnis könnte ein super SPS Programmierer werden. Aber trotzdem bin ich nervös und bin lieber immer ein bisschen vorbereitet.

Gruß Thomas


----------



## Georgius (24 Oktober 2008)

Hallo,

mit einem Musterprojekt kann ich leider nicht dienen.
Aber es gibt unter itq.de einige Zeitschriftenartikel, die
zur Problematik der Softwareprojektierung und Softwareprogrammierung passen.
Daraus entstammt auch dieses Dokument:
http://www.itm.tum.de/lehre/Mechatr...DMA Leitfaden Software Qualitätssicherung.pdf

Ansonsten gibt auch die veraltete aber teilweise noch verbreitete VDI 3683 gute Tipps zum Erstellen eines Pflichtenhefts sowie zjm Beschreiben von Steuerungsproblemen.

Gruß und schönes WE


----------

