Herrangehensweise an komplexere Programme

[hoeckaelstroem]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo liebe Forengemeinde,

ich bin nun seit etwa einem halbe Jahr dabei mir die Programmierung von SPS beizubringen, auch im Zuge meines Studiums.
Nun habe ich die Aufgabe mir eine Art Programmierrichtlinie auszudenken, welche für größere Projekte zum Einsatz kommen soll.
Im Internet habe ich schon ein paar Nützliche Tipps und vor allem ein paar DON'T DOs gefunden.
Die Aufgabe viel mir zu, da ich wenig erfahrung in der Programmierung von SPSen hab und daher unbefangener bin.
Ich bin nun auf der Suche nach etwas Literatur, welche sich auf die Herrangehensweise bzw Projektrierung von größeren Automatisierungsaufgaben beziehen. Ein Buch ist mir dabeischon aufgefallen: SPS-Standard: IEC-61131 Neumann. Gehe ich recht in der Annahme, dass dies so das Standardwerk zur Standardisierung ist? Gibt es weitere empfehlenswerte Bücher?

Eine Frage hab ich direkt schon:
Empfiehlt sich für größere Projekte eher eine Programmierung mit meherern FC oder eher FB. Wann empfielt sich der Einsatz der jeweiligen Bausteine. Übersichtlichkeit und vor allem ein leichtes Ändern und eine schnelle Fehlersuche dürfte ja insbesondere bei größeren Projekten sehr wichtig sein.

Mit eurer Erfahrung könnt ihr mir bestimmt weiterhelfen. Danke schon einmal dafür.

 

[Tigerente1974]

Es dürfte schwerfallen, den Königsweg aufzuzeigen. Es gibt unterschiedliche "Philosophien" und natürlich auch etliche Wege ans Ziel zu kommen.
Es gibt hier im Forum ausschweifende Diskussionen über Programmierstil und Sprachen.

Ein paar Grundsätze vielleicht mal:

- FC immer dann, wenn man nichts speichern muss. Für einen FB muss man einen Instanz-DB (als Speicherplatz) deklarieren, das ist zusätzlicher Aufwand.
- Gut kommentieren: nicht jede Programmzeile aber lieber mehr als zu wenig
- Gut strukturieren: Unnötig lange Bausteine vermeiden und lieber in mehrere Bausteine aufteilen. Z.B. Betriebsarten, Ausgänge Station "xy" da aber nicht zu viel zusammenfassen, Ablauf Station "xy" usw...
- Große Netzwerke vermeiden. Ein Netzwerk sollte nicht größer als eine Bildschirmseite sein.
- Bei der Namensvergabe für Symbole sollte ein kurzer und aussagekräftiger Symbolname gewählt werden.

 

[Aventinus]

Zuviel Werbung?
-> Hier kostenlos registrieren

Es kann keine absolut richtige Herangehensweise geben. Wie Tigerente schon geschrieben hat kannst du in div. Diskussionen nachlesen dass sich selbst die erfahrensten Programmierer oftmals fast die Köpfe einschlagen....

Aber soviel kann ich dir verraten. Es gibt für jedes Problem einen sinnvollen Ansatz und auch passende Werkzeuge. Aber du kannst mit einer guten Struktur einer Palletenfördertechnik nicht sinnvoll eine Roboterzelle oder ein Chemiewerk programmieren. Ähnlich sehe ich das im Bezug auf die Programmiersprache. Wenngleich logische Verknüpfungen schön in FUP darstellbar sind macht die Verwaltung von großen Datenmengen in FUP absolut keinen Spass. Dann nimmst du SCL - dass umgekehrt nicht optimal für die Bitverknüpfungen ist.

Je genauer man eine Aufgabenstellung spezifizieren kann umso besser kann man dafür auch einen Lösungsansatz erarbeiten.

 

[Knaufverbieger]

Aus meiner Erfahrung ist es sinnvoll sich als erstes mit dem Projekt auseinanderzusetzen, welches Du per SPS zum Laufen bringen sollst. Dabei spielt meist die Visualisierung eine große Rolle. Dafür eine Konzeption erstellen. Soll die Anlage als Übersicht dargestellt werden oder rein funktionell. Wie sollen Fehler in der Anlage dargestellt werden. Als blinkendes Symbol und/oder im Klartext. Solche Dinge als Beispiel.
Für die Programmierung selbst empfielt sich die Erstellung der Hardwareanbindung und einer Symboltabelle/Variablenzuweisung als Voraussetzung. Bei dieser Erstellung wird Dir meist schon klar, ob mehrere Baugruppen das Gleiche tun, wofür Du dann Standart-Bausteine erstellen kannst.
Wie Tigerente schon beschrieben hat ist die Dokumentation von Anfang an wichtig. Für Dich selbst, wenn mal der Überblick verloren geht über das, was Du bereits programmiert hast und vor allem für Betrachter, die mit Deiner Software später arbeiten müssen. Ich werde meist selbst auf Details aufmerksam, wenn ich eine Beschreibung für eine bestimmte Programmaktion verfasse.
FC oder FB? Wurde bereits viel gesagt. In FC's speichert man üblicherweise im Merker. Im FB im Instanz-DB (sinnvollerweise). Macht sich für Standart-Bausteine sehr gut. Unterm Strich setze ich immer auf eine "übliche" Programmierung, die vor Ort bereits Verwendung findet, wenn mir diese nicht zu "schlimm" erscheint.
Wenn Dir alle Wege zur Programmgestaltung offen stehen, wirst Du wohl mit der Programmierart beginnen, die Dir am geläufigsten ist und im Laufe der Projektentwicklung herausfinden, was Du besser machen kannst.
Just do it

 

[Sinix]

Zum Thema größere Projekte habe ich gute Erfahrungen damit gemacht, mir eine Programmstruktur vorher in Excel o.ä. zu erstellen. So haben die Bausteine, E/As, Merker, Timer im groben schon einen festen Bereich. Falls mehrere MA am Projekt beteilligt sind, finden die sich auch schneller zu recht.
MfG MK

Im S7-1200 System Handbuch (A5E02486681-06) Kapitel 6 stehen auch nützliche Hinweise.

 

[JOHKU]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo,
Richtlinien zur Softwareerstellung machen nur Sinn wenn man die Softwaredokumentation mit einbezieht. Nehmen wir als Beispiel das Modell: Lastenheft->Pflichtenheft->(Software-) Realisierung.
Lastenheft sollte in Form einer verbalen Beschreibung mit Konzeptbildern und eventuell Zustandsgraphen oder groben Ablaufdiagrammen vorliegen.
Das Pflichtenheft verfeinert das Lastenheft bis auf ein Niveau auf dem es 1:1 in Software umgesetzt werden kann. Das bedeutet detaillierte Ablaufdiagramme für Schrittketten, Zustandsgraphen für Funktionsbausteine die als Automat realisiert werden, Regelschemata, Funktionspläne nach DIN etc.
Die Wahl der Dokumentation für das Pflichtenheft bestimmt letztlich die Regeln nach denen dieses in Software umzusetzen ist. Z.B. Liegt die Aufgabe als Ablauf vor, stellt man Regeln auf wie eben diese Aufgabe in ein GRAPH Programm zu wandeln ist u.s.w.
Wichtig ist dass, es immer einen direkten Bezug zwischen den FB´s, FC´s und Symbolik des realisierten Programms zu den Kapiteln der Dokumentation gibt.
Ob die Regeln die man aufstellt richtig oder falsch sind, ist Geschmackssache aber letztlich völlig egal.
Ist das Regelwerk konsistent, führt es ganz automatisch zu einem klaren Firmen Stil.
Nun werden wahrscheinlich viele argumentieren dass, das Geld für ein luxuriöses Pflichtenheft niemals vorhanden ist. Allerdings muss man immer auch eine Softwaredokumentation für den Kunden erstellen. Die Arbeit die man in das Pflichtenheft steckt, ist zu 100% für die Kundendokumentation wiederverwendbar.

Gruß
Johannes

 

[Kotonaru]

Was bei mir immer funktioniert hat ist - ähnlich wie Mäuseklavier es beschrieben hat - die komplette Anlage grob in Gruppen/Baugruppen/Module etc. einzuteilen. Ich mach das immer auf einem Din A3 Blatt, da mir die Zeichnerei auf'm PC immer zu lange dauert. Danach werden die Baugruppen immer weiter zerteilt und mit den wichtigsten Verbindungen beschrieben. Soll heißen: Welche Baugruppe gibt welches Signal an welche Baugruppen weiter.
Und zu guter letzt wird für jede kleinere Einheit entweder ein Flussdiagramm oder sogar gleich die Schrtittkette gezeichnet.

Zum Thema FBs oder FCs: Also wir setzen FB nur dann ein wenn wir einen Baustein haben, der mehrmals in der aktuellen oder auch in anderen Anlagen eingesetzt wird oder werden kann. Ansonsten ist alles in FCs geschrieben.