Bewertungskriterien für eine SPS-Programmierung

danika

Level-1
Beiträge
4
Reaktionspunkte
0
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo an alle!

Ich schreibe derzeitig an einem Praxisbericht für die FH.
Als Grundlage hierfür habe ich ein S5 Programm und möchte das in S7 umschreiben. Natürlich soll als Grundlage das alte Programm bewertet und beurteilt werden. Aber was stellt ein gutes Programm dar??
Klar weiß ich das es möglichst wenig Speicherplatz belegen soll. Aber was bedeutet denn wenig? Wieviel Speicherplatz nimmt ein Zähler im Vergleich zu einem Merker ein?
Was sind weitere Bewertungkriterien?

Ich hoffe ihr könnt mir helfen, da ich im Netz nichts brauchbares finden kann. :(
 
Aber was stellt ein gutes Programm dar??
Klar weiß ich das es möglichst wenig Speicherplatz belegen soll.

Also ist ein vom Speicherbedarf her kleines aber unübersichtliches Programm gut ? Nach meiner Meinung stellt der Speicherbedarf bei dieser Betrachtung höchstens eine untergeordnete Rolle dar.

Was sind weitere Bewertungkriterien?

Zunäüchst sollte es die geforderten Ansprüche hinsichtlich der Funktion erfüllen.
Am Wichtigsten wäre mir dann eine gute Dokumentation und eine klare (nachvollziehbare) Struktur. An diesem Punkt lassen sich dann natürlich noch tausenderlei Features mit anknüpfen.

Gruß
LL
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Programmierung

Hallo ,
ich würde darauf Wert legen das die Programmierung eine gute Prozessicherheit bietet. D.h. es dürfen natürlich keine Sackgassen progarmmiert werden z.B. oft bei Graph Schrittketten. Weiterschaltbedingungen und Verriegelungen müssen sauber programmiert sein. Übersichtliche Netzwerke wenn möglich machen vieles leichter.

Schrittketten wenn vorhanden kleiner halten dafür mehrere verwenden. Wie gut ist die Programmierung nach Spannugsausfall ( Remanenz ) . Diagnose und Zustände des Programms sollten schnell und gut erkennbar sein . Oftmals nicht der Fall bei Verwendung von Pointern und Lokalvariablen.Alle benötigten Daten im Projektsichern Positions DB's oder benötigte Werte in DB's sollten Initialisiert sein. Das nach Urlöschen oder CPU tausch alle Daten im Projekt enthalten sind . Und nicht Werte und evtl. Positionen von Antrieben neu eingegeben werden müssen.

Mfg
SPQR
 
Ein wirklich gutes Programm, lässt sich auch von anderen Leuten später noch erweitern. Also wie schon geschrieben:
Vor dem programmieren muss erst ein vernünftiges Konzept stehen.
Dem Konzept folgend wird eine klare Struktur aufgebaut werden.
Beim (also nicht erst nachher) erstellen des Programmes wird sauber kommentiert.
 
Ein wirklich gutes Programm, lässt sich auch von anderen Leuten später noch erweitern.

Leider ist es meistens so (man lernt ja schliesslich nie aus), dass man selber nach zwei oder drei Jahren keinen blassen Schimmer mehr von seinen eigenen Programmen hat.

Ob ein Programm gut ist sieht man nicht sofort, man sieht aber sofort ob es gut programmiert ist.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Leider ist es meistens so (man lernt ja schliesslich nie aus), dass man selber nach zwei oder drei Jahren keinen blassen Schimmer mehr von seinen eigenen Programmen hat.

Wenn der Schimmer beim lesen des Programmes nicht wieder kommt, hat man es definitiv schlecht kommentiert. Wer soll den eigenen kruden Gedanken folgen können, wenn man es selbst nicht kann. ...auch nach 10 Jahren.

Kieler
 
Speicherplatz war früher mal ein wichtiges Thema. Da wurden schon mal recht merkwürdige Dinge programmiert, um ein oder zwei Zeilen zu sparen. :confused:
Aber heute ist das eigentlich kein Thema mehr.
(Es sei denn, man erweitert in Portugal gerade eine Anlage und plötzlich ist der Speicher voll und man hat keine größere MMC dabei. Aber das ist ein eigenes Thema.... :rolleyes:)

Das wirklich allerwichtigste ist m.E. ja mal die Funktion des Ganzen. Also sprich: Prozess-Sicherheit, Zykluszeit-Optimierung, Bedien-Freundlichkeit...
Ob und wie der Code dann "schick aussieht" kommt erst an zweiter Stelle. Für Erweiterungen oder Fehlersuche ist natürlich auch ein sauberer Aufbau und eine ausführliche Beschreibung des Programmes wichtig. Wobei die Menge der Kommentare noch nix über deren "Güte" aussagt.

Man liest immer wieder gerne sowas:

L MB 10 //Wert von MB 10 in Akku laden

Aha! :rolleyes:*ROFL*

Dann kommt noch das Thema Symbolik, die kann auch übersichtlich oder total "kryptisch" sein.

Wichtig finde ich auch noch eine Durchgängigkeit Im Programmstil, also dass z.B. bei mehreren Anlagenteilen der Aufbau immer gleich oder ähnlich ist. Das ist oft ein Problem, wenn mehrere Leute an einer Anlage programmieren und vorher keine Programmierkonventionen abgesprochen werden.

Und da SPS Programme auch oft von Leuten bearbeitet werden, die das nicht jeden Tag machen (Instandhalter...), sollte ein Programm immer so einfach wie möglich gehalten werden.
 
Wie bereits von den Vorgängern beschrieben, ist das nackte SPS-Programm zu bewerten relativ sinnfrei, vor allen nach heutigen Kriterien.
Man sollte folgendes beachten, auch auf die Gefahr einiges zu wiederholen:
1. Gibt es Spezifikationen, Abläufe, Beschreibungen zum Programm - oft bei alten Systemen gar nicht vorhanden.
2. Wie wird der Bezug zum Schaltplan in der Symbolik unterstützt (z.B. BMKs)
3. Aussagekraft der Symbolik und der Kommentare (s.o.), schlägt sich die Struktur der Anlage auch im Programm nieder?
4. Diagnose der Störungen und Beseitigung
5. Fehlermeldungen vom Betreiber, wie oft hat die Maschine Schwierigkeiten gemacht auf Grund der Steuerung?
6. Ist die Erweiterung einfach durchzuführen, sind z.B. Daten gekapselt, oder wurde mit Copy&Paste gearbeitet?
7. Toter Code, viele Sprünge, nie errreichbare Zeilen
8. ...

Das mal nur so aus der Hüfte geschossen.
 
Zurück
Oben