TC3: Wann nutzt Ihr Methoden und wann "nur" den FB

Das Haltepunkte im Maschinenbau Käse sind ist klar,
allerdings wie ich es bei seehma rauslese, wird er die auch
nicht benötigen.
Die Probleme bei OOP hat ja @Rob1337 gut beschrieben.
Du bekommst teilweise nicht mal einen Status angezeigt (zumindest bei Wago eCockpit).
Also daher muss man schon überlegen was man mit OOP umsetzt und was man "normal" macht.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Eins noch zum Besten: Vor einigen Tagen habe ich an einer 34 Jahre alten Bosch CL Steuerung eine Programmänderung gemacht. Schön mit Vergleichen, Ändern, Online Nachladen, auf Diskette sichern. Das möchte ich mal an einer gleichalten Beckhoff oder TIA Maschine sehen... Wär bestimmt interessant.
Ich bin nicht davon überzeugt, dass eine 1500er überhaupt so lange lebt. Die ersten paar haben bei mir grad mal so die Garantiezeit überlebt, bis sie einfach dunkel wurden. Ich bin also skeptisch, dass wir überhaupt die Chance haben werden bei einer so alten Anlage was ändern zu können.
 
Ich bin nicht davon überzeugt, dass eine 1500er überhaupt so lange lebt. Die ersten paar haben bei mir grad mal so die Garantiezeit überlebt, bis sie einfach dunkel wurden. Ich bin also skeptisch, dass wir überhaupt die Chance haben werden bei einer so alten Anlage was ändern zu können.
Das ist extra so gemacht, weil die TIA auch so verdammt schnell altert.
Nicht das du in 5 Jahren versuchst V11 zu starten.
 
Sehr spannende Diskussion hier.
Ich arbeite bereits seit über 7 Jahren mit TC3 und ich nutze die Möglichkeiten von OOP wirklich aus.
Mit OOP hat man die Möglichkeit seine Programme sehr leserlich zu machen, wenn man das will.
Ich arbeite vor allem viel mit Interfaces, die sind sehr mächtig und hilfreich.
Klar gibt es noch ein paar Dinge, die für meinen Geschmack noch fehlen (besonders das Erweitern von Methoden mit zusätzlichen Parametern bei Erweiterungen) und es gibt auch Dinge mit denen man sehr gut aufpassen muss (dynamische Objekte). Wenn man aber ein bisschen dahinter sieht, wenn man weiss, wie das alles im Speicher abläuft, dann ist es wirklich eine sehr gute Sache. Und ganz wichtig: Man muss immer daran denken, dass man es bei SPS Anwendungen mit einer deterministischen Umgebung zu tun hat: Man darf es nicht übertreiben.

Aber für Personen, die sich mit OOP noch nicht so auskennen, würde ich empfehlen zuerst mal einen OOP Kurs zu besuchen (mit SOLID Prinzipien und so). Denn das hilft dann wirklich, ein Programm gut zu strukturieren und die OOP Möglichkeiten gut einzusetzen.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Mit OOP hat man die Möglichkeit seine Programme sehr leserlich zu machen, wenn man das will.
Ich arbeite vor allem viel mit Interfaces, die sind sehr mächtig und hilfreich.
Leserlich für Dich oder für andere ;)

Also was sagen Instandhalter oder fremde Programmierer des Kunden zu Deinem Programmierstil?

Ich finde, mit jeder Programmiersprache/Programmierstil kann man leserlich oder unleserlich programmieren.

Aber bestimmte Dinge sind halt eben "Standard" in der Automatisierung, weil man es eben "immer so macht" und deshalb sind diese Sprachen/Stile per see schonmal "leserlicher".

Man fährt halt in Deutschland mit dem Auto auf der rechten Straßenseite, weil das eben so ist, bzw. weil man es in der Fahrschule/Automatisierungslehre so gelernt hat.

Am Ende kommts aber vorrangig drauf an, dass die Anlage/Maschine ordentlich läuft und auch in 10 Jahren noch änderbar/wartbar ist, auch durch einen fremden Automatisierer.

Das ist jetzt keine Kritik an Dir, sondern nur meine allgemeine persönliche Meinung.

Gruß.

PS: es macht halt keinen Sinn, wenn jeder "Programmierer" sich an jeder Anlage neu "selbstverwirklichen" will ;)

Bei mir gilt generell Einheitlichkeit geht vor Schönheit.
 
Zuletzt bearbeitet:
Leserlich für Dich oder für andere ;)

Also was sagen Instandhalter oder fremde Programmierer des Kunden zu Deinem Programmierstil?

Ich finde, mit jeder Programmiersprache/Programmierstil kann man leserlich oder unleserlich programmieren.

Aber bestimmte Dinge sind halt eben "Standard" in der Automatisierung, weil man es eben "immer so macht" und deshalb sind diese Sprachen/Stile per see schonmal "leserlicher".

Man fährt halt in Deutschland mit dem Auto auf der rechten Straßenseite, weil das eben so ist, bzw. weil man es in der Fahrschule/Automatisierungslehre so gelernt hat.

Am Ende kommts aber vorrangig drauf an, dass die Anlage/Maschine ordentlich läuft und auch in 10 Jahren noch änderbar/wartbar ist, auch durch einen fremden Automatisierer.

Das ist jetzt keine Kritik an Dir, sondern nur meine allgemeine persönliche Meinung.

Gruß.

PS: es macht halt keinen Sinn, wenn jeder "Programmierer" sich an jeder Anlage neu "selbstverwirklichen" will ;)

Bei mir gilt generell Einheitlichkeit geht vor Schönheit.

Ich bin voll Deiner Meinung. Einheitlichkeit ist das A und O.

Deshalb ist es so wichtig, dass es eine Codier- und eine Designrichtlinie gibt an die sich alle halten.
Dann wird der Code komplett verständlich und wartbar.

Instandhalter und fremden Programmierern kann man dann diese Richtlinien und die Dokumentation zeigen und dann ist es ihnen sehr schnell klar, wie das Ganze aufgebaut ist und funktioniert. Bis jetzt haben wir da überhaupt keine Probleme gehabt. Im Gegenteil: Sie waren begeistert von diesem Stil.

Zudem werden in 10 Jahren fast alle Automatisierer mit OOP komplett vertraut sein, da bin ich mir ziemlich sicher.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Haltepunkte sind bei SPS zur Störungssuche eh' ein absolutes No-Go.
Ich verwende NIE!!!! Haltepunkte. Das liegt aber vermutlich daran, das ich versuche so zu programmieren, das ich auch ohne Haltepunkte und ggf. mit aufrufabhängigen Merkern "Wartepunkte" erzeugen kann, ohne die ganze SPS "abzuschießen".
 
Zurück
Oben