# Programmiersprachen



## gloeru (27 März 2011)

Um den Thread von xinix nicht zu überladen, möchte ich hier mal über die versch. Sprachen der IEC-Norm diskutieren:

Im [FONT=&quot]erinnere [/FONT]mich bestens am meinen Prof. im Fach Automation: "Wenn wir  Automatisierer nicht endlich vorwärts machen mit der Programmierung,  werden uns in wenigen Jahren die Informatiker die Arbeit wegnehmen"

Wenn ich jetzt z.B. Beckhoffs neuster Wurf (TwinCAT 3) gesehen habe, geht Beckhoff exakt in diese Richtung mit C/C++...

Ich persönlich arbeite meist mit ST, für komplizierte boolsche Abhängigkeiten nehme ich gerne FUP. Nun ein paar Fragen:
- Gibt es eine Möglichkeit, mit anderen Sprachen als ST Arrays und FOR-Schleifen sinnvoll zu nutzen? (Habe z.B. ein Projekt mit 16 gleichen Tanks)
- Darf/Soll man die verschiedene Sprachen frei kombinieren, oder doch besser alles in der gleichen Sprache?
- Ist das Zustandautomaten-Denken mit einer Anlage mit mehreren NC-Achsen und mehr als 100 IOs überhaupt geeignet?

Jetzt hoffe ich auf eine lehrreiche unf konstruktive Diskussion!


----------



## IBFS (27 März 2011)

gloeru schrieb:


> Im [FONT=&quot]erinnere [/FONT]mich bestens am meinen Prof. im Fach Automation: "Wenn wir  Automatisierer nicht endlich vorwärts machen mit der Programmierung,  werden uns in wenigen Jahren die Informatiker die Arbeit wegnehmen"



Das ist totaler Unsinn, denn:

1. Programmieren von Maschinen ist nicht 100% Programmieren sonder höchstens 30%. Der Rest ist das Herumärgern mit Umrichtern, Schutztüren, Sensoren, Projerktleitern, Konstrukteueren etc. 

2. Wenn dem so wäre, dann müßten sich die Informatiker mal richtige Arbeitschuhe kaufen und aus ihren dunklen Räumen herauskommen und die Schlappen (Birkenstockschuhe) ausziehen --- das ist kaum zu erwarten.

3. Wie schon woanders gesagt, ist C/C++ Eventgetriggert  im Gegensatz zur SPS da überwiegt eindeutig die Zyklusorientierte Programmierung.  
Das bei Rezeptursteuerungen oder Datenbankanbindungen dort die Grenzen verschwimmen ist dabei zu vernachlässigen.

4. Schicke "deinen" Professor mal für ein paar Tage auf eine RICHTIGE Baustelle. Da wird der ganz schnell seien C-Laptop wieder einpacken, weil er Angst hat das der Laptop Kratzer bekommt.

Frank


----------



## rostiger Nagel (27 März 2011)

IBFS schrieb:


> 4. Schicke "deinen" Professor mal für ein paar Tage auf eine RICHTIGE Baustelle. Da wird der ganz schnell seien C-Laptop wieder einpacken, weil er Angst hat das der Laptop Kratzer bekommt.




Es muss nicht gleich eine Baustelle sein, es reicht unter Umständen eine
einfache Weiterbildung, den Anschein nach hat dieser Mensch einfach keine
Ahnung. Nicht überall wo Prof drauf steht ist auch wissen drin.


----------



## MSB (27 März 2011)

gloeru schrieb:


> Ich persönlich arbeite meist mit ST, für komplizierte boolsche Abhängigkeiten nehme ich gerne FUP. Nun ein paar Fragen:
> - Gibt es eine Möglichkeit, mit anderen Sprachen als ST Arrays und FOR-Schleifen sinnvoll zu nutzen? (Habe z.B. ein Projekt mit 16 gleichen Tanks)
> - Darf/Soll man die verschiedene Sprachen frei kombinieren, oder doch besser alles in der gleichen Sprache?
> - Ist das Zustandautomaten-Denken mit einer Anlage mit mehreren NC-Achsen und mehr als 100 IOs überhaupt geeignet?


- Für Schleifen/Arrays und Co. ist ST sicherlich das mit Abstand effektivste Werkzeug,
mit dem man hinterher den nachvollziehbarsten Code erhält.

- Logisch, man darf und man soll, für jede Teilaufgabe das am besten geeignete Werkzeug verwenden

- Also der überwiegende Teil des Maschinenbaus entspricht wohl der Ablaufsteuerung,
allerdings sind natürlich hier auch einzelne Teile wieder eher eine Zustandsmaschine,
z.B. der Treiberbaustein für einen FU, Servo, Ventil ...
Also für mich hängt diese Trennung ausschließlich von der Maschine/Anlage ab,
und nicht von deren Größe ob 1 Antrieb oder 1000 Antriebe.

Mfg
Manuel


----------



## MSB (27 März 2011)

Helmut_von_der_Reparatur schrieb:


> Es muss nicht gleich eine Baustelle sein, es reicht unter Umständen eine
> einfache Weiterbildung, den Anschein nach hat dieser Mensch einfach keine
> Ahnung. Nicht überall wo Prof drauf steht ist auch wissen drin.



Vor allem, wie wir seit Gutti alle Wissen, wird ein Professor bestellt, er muss dafür keine Prüfung ablegen ... *ROFL*


----------



## IBFS (27 März 2011)

MSB schrieb:


> - Für Schleifen/Arrays und Co. ist ST sicherlich das mit Abstand effektivste Werkzeug, mit dem man hinterher den nachvollziehbarsten Code erhält.



Bei diesem Punkt gebe ich dir recht. Extra für solche Aufgaben habe ich mir unmittelbar nach dem Beginn meiner Programmierertätigkeit SCL gekauft.

Frank


----------



## gloeru (27 März 2011)

MSB schrieb:


> Vor allem, wie wir seit Gutti alle Wissen, wird ein Professor bestellt, er muss dafür keine Prüfung ablegen ... *ROFL*



Nun, "mein" Professor ist hauptamtlich Senior-Engineer bei einem Weltkonzern der Automatisierungsbranche...

Ich bin ziemlich befremdet, wie gewisse Leute hier über andere Personen herziehen! Ist den Beckhoff/CoDeSys wirklich auf dem Holzweg mit C/C++??


----------



## rostiger Nagel (27 März 2011)

gloeru schrieb:


> Nun, "mein" Professor ist hauptamtlich Senior-Engineer bei einem Weltkonzern der Automatisierungsbranche...
> 
> Ich bin ziemlich befremdet, wie gewisse Leute hier über andere Personen herziehen! Ist den Beckhoff/CoDeSys wirklich auf dem Holzweg mit C/C++??



C/C++ bei TwinCat III ist nur eine zusätzlicher Programmeditor, mit
Sicherheit wartet so mancher Maschinenbuer da drauf und ich bin mir sicher
das es Anwendungen gibt wo es seinen Sinn hat. Im übrigen hatte ich die
Tage einen Kurs wo wir eine Siemens SPS in C++ programmiert haben, die
können das schon lange, dort waren einige Anwender die dieses brauchten 
um eine Datenbankanbindung zu realisieren zu können, die mit herkömmlichen
Mitteln nicht machbar war, speziell für die Verpackungsindustrie. 
Aber solche Anwendungen sind aber eher eine Seltenheit.


----------



## Kieler (27 März 2011)

Ich mache jetzt seit über 20 Jahren Automatisierung und hier vornehmlich SPS Programmierung. Ich denke, der Trend geht ganz klar in Richtung Hochsprachen. Hier vornehmlich ST. Die Ursache hierfür sehe ich aber weniger in den überragenden Fähigkeiten dieser Sprache, als vielmehr in der Ausbildung der nachwachsenden Generationen. Heute ist das vermitteln von Hochsprachen viel geläufiger. Früher gab es häufig deutlich kompliziertere Stromlaufpläne, da mehr über Hardware gemacht wurde. Hierauf waren die Leute ausgebildet. Ich finde ST gut und setze es auch gerne und häufig ein. Aber ich habe noch kein Projekt ausschließlich mit ST realisiert. Mit FUP oder AWL aber schon.

Am besten finde ich noch immer einen Mischbetrieb. Alle Unterprogramme (Antriebsbausteine, Automatik, Skalierung, ...) schreibe ich in einer Text-Sprache, also AWL oder ST. Die Zusammenschaltung passiert dann meisten in einer graphischen Sprache, wie z.B. FUP oder noch besser CFC.


----------



## Gerhard Bäurle (27 März 2011)

gloeru schrieb:


> Im [FONT=&quot]erinnere [/FONT]mich bestens am meinen Prof.  im Fach Automation: "Wenn wir  Automatisierer nicht endlich vorwärts  machen mit der Programmierung,  werden uns in wenigen Jahren die  Informatiker die Arbeit wegnehmen"





gloeru schrieb:


> Ich bin ziemlich befremdet, wie gewisse Leute hier über andere Personen  herziehen! Ist den Beckhoff/CoDeSys wirklich auf dem Holzweg mit  C/C++??


 
Hallo,

so wirklich nachvollziehen kann ich die Aussage Deines Professors 
zu den Informatiken auch nicht.

Der Schlüssel für eine Automation ist m. E. das Verständnis für
Verfahren und Prozesse, das Zerlegen der Gesamtaufgabe in
Teilaufgaben und das Lösen der Teilaufgaben. Erst dann kommt
der "Informatiker" mit seinen Werkzeugen.

M. E. lernt ein Verfahrenstechniker wesentlich schneller neue 
Programmiermethoden, als ein Informatiker die Verfahrenstechnik.


----------



## Kieler (27 März 2011)

Gerhard Bäurle schrieb:


> Der Schlüssel für eine Automation ist m. E. das Verständnis für
> Verfahren und Prozesse, das Zerlegen der Gesamtaufgabe in
> Teilaufgaben und das Lösen der Teilaufgaben. Erst dann kommt
> der "Informatiker" mit seinen Werkzeugen.



*ACK*

Das ist ein ganz zentraler Gedanke, den ich jederzeit unterschreiben würde.


----------



## Blockmove (27 März 2011)

Meine Sicht der Dinge:

Egal ob Codesys oder S7, ich habe die Wahl zwischen verschiedenen Sprachen. Beim Erstellen des SPS-Programms ist eigentlich die wichtigste Aufgabe das Projekt / die Anlage zu gliedern. Für jeden Teilbereich kann ich mir die passende Sprache wählen. Betriebsarten und Ausgangsverriegelung z.B. in KOP/FUP, Schrittketten in Graph und Datenverarbeitung in AWL/SCL  oder C++. Alle Sprachen haben ihre Daseinsberechtigung und jede hat gegenüber den anderen anforderungsbedingte Vor- und Nachteile.

DIE Sprache gibt es schlichtweg nicht! 

Wenn hier C++ angeführt wird, dann erwarte ich schlichtweg, dass Objektorientierung in die SPS Einzug hält. Und das ganzflächig, also auch in den anderen Sprachen (KOP, FUP, ST, ...). Grundlegende Konzepte wie Kapselung und Vererbung. Weg von FB,Global-DB,Instanz-DB und Merkern.

Gruß
Dieter


----------



## bike (27 März 2011)

Blockmove schrieb:


> DIE Sprache gibt es schlichtweg nicht!
> 
> Wenn hier C++ angeführt wird, dann erwarte ich schlichtweg, dass Objektorientierung in die SPS Einzug hält. Und das ganzflächig, also auch in den anderen Sprachen (KOP, FUP, ST, ...). Grundlegende Konzepte wie Kapselung und Vererbung. Weg von FB,Global-DB,Instanz-DB und Merkern.
> 
> ...




Irgendwie werde / bin ich nicht schlau. 

Wozu Objekte bei Ablaufsteuerungen?
Bei Daten Dingen kann es ggF Sinn machen.
Kapselung ist doch schon jetzt möglich wenn du es willst und richtig anlegst. 

Für jede Aufgabe die richtige Entwicklungsumgebung, doch Objekte bei PLC muss echt nicht sein.
Ich habe ein Programm einmal in die Finger bekommen, das nur aus Objekten besteht und kann sagen:
Der Entwickler kommt damit klar, doch andere?
Und wofür werden Anlagen gebaut und programmiert?


bike


----------



## zotos (27 März 2011)

Gerhard Bäurle schrieb:


> ...
> Der Schlüssel für eine Automation ist m. E. das Verständnis für
> Verfahren und Prozesse, das Zerlegen der Gesamtaufgabe in
> Teilaufgaben und das Lösen der Teilaufgaben. Erst dann kommt
> ...


Die Werkzeuge sind aber eben auch entscheidend. 
Für einen Grafiker ist das Auge und Gefühl für Detail und Gesamteindruck wichtig und entscheidend.

Aber wenn man ihm vorschreibt auf Adobe Photoshop zu verzichten und ihm gebietet statt dessen nur mit Microsoft Paint arbeiten zu dürfen könnte es sein das er schnell die Lust an dem Job verliert.


----------



## IBFS (27 März 2011)

bike schrieb:


> Ich habe ein Programm einmal in die Finger bekommen, das nur aus Objekten besteht und kann sagen:
> Der Entwickler kommt damit klar, doch andere?   Und wofür werden Anlagen gebaut und programmiert?



... und dann kommt der Instandhalter angeschlappt und frag:  "das is doch garnisch in KOP oder FUP - das kansch nisch  "    

Wobei ich schon sagen muss, alle Anlagen(teile)/Programm(teile) sollen und müssen Instandhalter nicht verstehen. 
Denn sonst muss man auf einer dermaßen niedrigen Abstaktionsebene Programmieren, dass man gleich wieder die Lochkarte herausholen könnte  

Frank


----------



## bike (27 März 2011)

IBFS schrieb:


> ... und dann kommt der Instandhalter angeschlappt und frag:  "das is doch garnisch in KOP oder FUP - das kansch nisch  "
> 
> Wobei ich schon sagen muss, alle Anlagen(teile)/Programm(teile) sollen und müssen Instandhalter nicht verstehen.
> Denn sonst muss man auf einer dermaßen niedrigen Abstaktionsebene Programmieren, dass man gleich wieder die Lochkarte herausholen könnte
> ...




Nein, das müssen diese nicht, doch den Ablauf und die draus entstehenden Probleme soll, nein muss! verstanden werden.
Ohne Studium und seitenlangen Manuals.

bike


----------



## Tigerente1974 (27 März 2011)

Blockmove schrieb:


> Alle Sprachen haben ihre Daseinsberechtigung und jede hat gegenüber den anderen anforderungsbedingte Vor- und Nachteile.
> 
> DIE Sprache gibt es schlichtweg nicht!



*ACK*

Ich sehe das genauso wie es schon gesagt wurde. Komplexe Bitverknüpfungen sind mit KOP/FUP gut zu machen. Adressieren von Array-Elementen ist im Vergleich zu den Möglichkeiten der Hochsprache mit AWL extrem kompliziert.

Ich sehe eine Programmiersprache aber nur als Handwerkszeug, dei der ich die entsprechenden Befehle kennen muss. Entscheidend bleibt, dass man die Aufgabe erfassen, zerlegen und dann strukturiert programmieren können muss. Wer das kann, schafft das auch mit jeder Sprache.

Für die Zukunft wünsche ich mir einen Mix, so wie es Siemens mit SCL, AWL, KOP/FUP bereits zur Verfügung stellt.


----------



## marlob (27 März 2011)

zotos schrieb:


> Die Werkzeuge sind aber eben auch entscheidend.
> Für einen Grafiker ist das Auge und Gefühl für Detail und Gesamteindruck wichtig und entscheidend.
> 
> Aber wenn man ihm vorschreibt auf Adobe Photoshop zu verzichten und ihm gebietet statt dessen nur mit Microsoft Paint arbeiten zu dürfen könnte es sein das er schnell die Lust an dem Job verliert.


Sicherlich sind die Werkzeuge auch wichtig. Aber mit den bisherigen Programmiersprachen KOP, FUP, AWL (IL), SCL (ST), Graph (AS) hat man doch alles um professionell zu programmieren ohne die Lust daran zu verlieren.
Da hinkt der Vergleich mit Photoshop und Paint doch ein wenig.


----------



## zotos (27 März 2011)

marlob schrieb:


> Sicherlich sind die Werkzeuge auch wichtig. Aber mit den bisherigen Programmiersprachen KOP, FUP, AWL (IL), SCL (ST), Graph (AS) hat man doch alles um professionell zu programmieren ohne die Lust daran zu verlieren.
> Da hinkt der Vergleich mit Photoshop und Paint doch ein wenig.


Der Vergleich hinkt keines Wegs. Vielleicht hat sich das Umfeld in diesem Forum ja in den Letzten Monaten stark geändert, aber es ist noch nicht lange her da wurden SCL (ST) und Graph (AS) als Teufelswerk angesehen. Auch heute liest man hier noch Kommentare wie:


Blockmove schrieb:


> ...
> ST / SCL halte generell nicht für Anfänger geeignet.
> ...


usw.

Betriebe die statt ihre Leute zu schulen lieber den Einsatz von SCL (ST) und Graph (AS) verbieten.

In meinem Projektumfeld ist es zum Glück nicht so. Ich kenne diese Akzeptanz Probleme fast nur hier aus dem Forum.


----------



## IBFS (27 März 2011)

zotos schrieb:


> Betriebe die statt ihre Leute zu schulen lieber den Einsatz von SCL (ST) und Graph (AS) verbieten.



Das ist zumindest bei STEP7 auch eine Kostenfrage.

Es ist schon ein Unterschied, ob du eine Firmen-SUS für
18 Leute für STEP7-PUR oder STEP7-Professional kaufen
musst. Schulungskosten sind bei der Mitarbeiterzahl im
Mittelstand oft nicht darstellbar. 

Das in Grosskonzernen, wo jeder Willi BUSINESS fliegen 
kann, dort keine Finanzhemmnisse existieren dürfte klar sein.

frank


----------



## marlob (27 März 2011)

zotos schrieb:


> Der Vergleich hinkt keines Wegs. Vielleicht hat sich das Umfeld in diesem Forum ja in den Letzten Monaten stark geändert, aber es ist noch nicht lange her da wurden SCL (ST) und Graph (AS) als Teufelswerk angesehen. Auch heute liest man hier noch Kommentare wie:
> 
> usw.
> 
> ...


Bei uns schreibt der Kunde (also unser Projektumfeld) vor, womit wir zu programmieren haben. Ich würde auch gerne öfters Graph oder SCL usw. benutzen. Hi-Graph hätte ich auch mal gerne was mit gemacht. Nur um zu sehen was damit möglich ist und ob es für unsere Projekte geeignet ist. Aber das ist alles nicht (immer) möglich da oft der Kunde, und dann auch noch meist der Einkauf davon, bestimmt was eingesetzt wird.


----------



## zotos (27 März 2011)

@IBFS: Das Stützt doch wieder den Paint vs. Photoshop Vergleich. Paint ist bei Windows schon dabei. Photoshop kostet einen Batzen Geld.

@marlob: Also passt der Vergleich doch. So interpretiere ich Dein letztes Posting.


----------



## IBFS (27 März 2011)

zotos schrieb:


> @IBFS: Das Stützt doch wieder den Paint vs. Photoshop Vergleich. Paint ist bei Windows schon dabei. Photoshop kostet einen Batzen Geld.



So ist das! 

Der kleinste gemeinsame Nenner sind oft die kleinsten "gemeinsamen" Kosten 

Frank


----------



## marlob (27 März 2011)

zotos schrieb:


> @IBFS: Das Stützt doch wieder den Paint vs. Photoshop Vergleich. Paint ist bei Windows schon dabei. Photoshop kostet einen Batzen Geld.
> 
> @marlob: Also passt der Vergleich doch. So interpretiere ich Dein letztes Posting.


So gesehen hast du vollkommen recht. Ich hatte vorhin mehr an die Möglichkeiten der Programme und die Resultate die man damit erzielen kann gedacht.


----------



## IBFS (27 März 2011)

marlob schrieb:


> Hi-Graph hätte ich auch mal gerne was mit gemacht. Nur um zu sehen was damit möglich ist und ob es für unsere Projekte geeignet ist.



Die meisten Leute sind für HiGraph nicht geeignet, weil sie oftmals noch nie das Wort "PETRI-NETZ" gehört haben.

Ansonsten hat sich LEIDER das Thema HiGraph erledigt, weil HiGraph im Gegensatz zu allen anderen Spachen 
von STEP7-P. (KOP-FUP-AWL-SCL-GRAPH7-CFC) definitiv nicht in die PORTAL-WELT V11 ff. herübergeholt wird.

Frank


----------



## StructuredTrash (27 März 2011)

bike schrieb:


> Für jede Aufgabe die richtige Entwicklungsumgebung, doch Objekte bei PLC muss echt nicht sein.



Das kommt auch auf die gesteuerten Anlagen an. Ich werde die OOP sicher nicht nur für die Bibliotheks-, sondern auch für die Anlagenprogrammierung nutzen. Ich verbringe gut 70% meiner Zeit mit einem Maschinentyp, der in den letzten Jahrzehnten nur behutsam weiterentwickelt wurde. Bei den meisten Baugruppen erkennt man die Verwandtschaft zum bis zu 30 Jahre alten Urahn auf Anhieb. Da macht es für mich schon Sinn, diese Entwicklung auch softwaretechnisch durch Vererbung nachzuvollziehen. Vor allem, weil bei der Modernisierung von Altanlagen nicht zwangsläufig Baugruppen der jüngsten Generation eingebaut werden.


----------



## IBFS (27 März 2011)

StructuredTrash schrieb:


> Ich verbringe gut 70% meiner Zeit mit einem Maschinentyp, der in den letzten Jahrzehnten nur behutsam weiterentwickelt wurde......



...diese Fälle sind im Maschinenbau die Ausnahme und im Sondermaschinenbau nahezu unauffindbar. 

Frank


----------



## Blockmove (27 März 2011)

bike schrieb:


> Wozu Objekte bei Ablaufsteuerungen?
> Bei Daten Dingen kann es ggF Sinn machen.
> Kapselung ist doch schon jetzt möglich wenn du es willst und richtig anlegst.
> 
> ...



Objekte machen auch bei einer SPS ihren Sinn. Und gerade nicht nur bei Daten-Dingen, sondern auch oder gerade bei simplen Bewegungen. Du kannst alles, was zu einer Bewegung gehört in einen Behälter (Objekt) packen und über Eigenschaften und Methoden darauf zugreifen.
Und wenn man es genau betrachtet, dann hat man heute schon beinahe Objekte in der SPS. UDT, Multiinstanzen und der Zugriff auf Instanz-DB ist schon beinahe Objektorientierung. Nur sind hier - wie in schon vielen vorherigen Threads beschrieben - viele Fallstricke. Durch Weiterentwicklung hin zu richtigen Objekten, wird dies entschärft. Und selbst für Instandhalter kann es dann einfacher werden.

Gruß
Dieter


----------



## StructuredTrash (27 März 2011)

IBFS schrieb:


> ...diese Fälle sind im Maschinenbau die Ausnahme und im Sondermaschinenbau nahezu unauffindbar.



Das stimmt natürlich. Selbst in unserer Branche ist es keineswegs üblich, die Maschinen für die Produktion selbst zu entwickeln. Ist halt historisch gewachsen.

Ich denke aber, dass die OOP auch im Sondermaschinenbau ihren Platz finden wird, dafür wird allein schon der Kostendruck sorgen. Das Zusammensetzen von Anlagen nach dem Baukastenprinzip wird dadurch schon einfacher. Ob es auch sicherer wird, ist noch eine andere Frage. Für jemanden, der ähnliche Strukturen bislang mit herkömmlichen Mitteln realisiert hat, wohl schon. Aber es wird sicher auch genügend Versuche geben, sich nur die rein technischen Rosinen aus der OOP herauszupicken, ohne die dahinterstehende Philosophie umzusetzen.


----------



## zotos (28 März 2011)

IBFS schrieb:


> ...diese Fälle sind im Maschinenbau die Ausnahme und im Sondermaschinenbau nahezu unauffindbar.


Ich kenne etliche Firmen die selbst im Sondermaschinenbau ein neues Projekt beginnen in dem sie die Software einer "ähnlichen" Vorgängermaschine umschreiben. Das ist eben auch eine Art der Vererbung. 

Zugegeben der Trend deutet eine Besserung an.


----------



## Dummy (29 März 2011)

Hallo,

ich kann nur aus meiner Sicht sagen, dass wir (mittelständiger Maschinenbauer) TwinCAT 3 lieber gestern als heute eingesetzt hätten.
Die Mittel, die mit OOP zur Verfügung stehen sind doch wesentlich mächtiger als die Spachelemente, die in  TWinCAT 2 verfügbar sind.

Als Beispiele:

-dynamische Speicherverwaltung(auch wenn es nicht normkonform sein wird)
-Vererbung 
-Interfaces/ Gleiche Schnittstellen 
-Überladen von Methoden

Das mögen vielen anders sehen.
Ich glaube aber, dass wenn man sich damit tiefer beschäftigt, viele zu dem Schluß kommen werden, dass es sinnvoll ist auf OOP zu setzen.

Zu Thema Ablaufsteuerungen: Es ist doch schön wenn ich anstelle eines riesen FBs, den ich ständig aufrufen muss, um die Schnittstelle von einer Schrittkette bedienen zu können, nur die in dem Schritt notwendige Methode aufrufen muss. Das sollte richtig programmiert soger Performance sparen.  


Gruß

dummy


----------



## Werner29 (30 März 2011)

Für mich ist die Sachlage auch klar: eine grosse Steuerungsapplikation mit einigen tausend Bausteinen und etlichen Megabyte generierten Code wird man nicht im Spagetticode runtercodieren wollen.
Das sind anspruchsvolle Programmieraufgaben, die sich in der Komplexität in nichts von sonstigen Programmieraufgaben unterscheiden. Ich kann das denke ich beurteilen, weil ich an der Schnittstelle sitze.
Ich behaupte, dass einige der Projekte die mit CoDeSys geschrieben werden, genauso komplex sind wie CoDeSys selbst, also das was ich als Programmierer zu tun habe.
Deswegen ist unser Anspruch, unseren Kunden genauso fortschrittliche Werkzeuge zu geben wie wir sie für unsere Arbeit erwarten. Ich wüsste nicht was daran falsch sein sollte.


----------



## SPSDAU (30 März 2011)

Hallo,

nun ich denke der Hr. Prof. bezieht sich vor allem darauf das es für jeden nachvollziehbar eine deutliche Weiterentwicklung der Hochsprachen gegeben hat. Im Vergleich dazu kommt die Weiterentwicklung in der IEC (jetzt die Objektorientierung) doch ziemlich gemächlich daher. Da kann man sicher nicht Widersprechen.

Nur was sich in welchen Bereichen als nächster Schritt durchsetzen wird kann heute auch niemand sicher vorhersagen. Klar ist aber das es keinen Stillstand gibt. (auch wenn hier wenige scheinbar etwas anders glauben)

Bezüglich "IT Fuzzis"  man sollte nicht unterschätzen das es davon viel mehr als IEC Programmierer auf der Welt gibt. Diese Welten werden Schritt für Schritt zusammen wachsen. Ich kenne bereits heute große Anwender bei denen ein reiner Hochsprachenprogrammierer mit einem Verfahrenspraktiker (nicht Programmierer!) zusammen arbeiten und erstaunliche Projekte bewegen.


----------



## drfunfrock (30 März 2011)

Objektorientierung richtig angewandt, macht das Leben manchmal leichter. Wie man das handhaben kann, dafür braucht es auch Erfahrung, weil es meistens diverse Lösungen gibt. 

Ich könne mir aber Vorstellen, dass in Zukunft damit auch besser in Schichten gedacht werden kann, so dass man zwischen direkter Hardwaresteuerung und der notwendigen Anwendungslogik unterscheidet. Z.b lassen sich dann Achsen verschiedener Hersteller wesentlich leichter gegen die eines anderen austauschen, um z.B. Lieferengpässe zu umgehen. Der Preis ist natürlich, dass es mehr CPU kostet. Aber das sollte kein Hinderniss sein.


----------



## IBFS (30 März 2011)

drfunfrock schrieb:


> Z.b lassen sich dann Achsen verschiedener Hersteller wesentlich leichter gegen die eines anderen austauschen, um z.B. Lieferengpässe zu umgehen.



Nur wegen einem Lieferengpass z.B. einen SINAMICS gegen einen Berger-Lahr tauschen? oder umgekehrt - Ich halte das für totalen Unsinn.

Da sind schon die Achsinbetriebnahmewerkzeuge völlig andere.
Und wenn beim Kunden schon drei Maschinen stehen, wird oft eine
EXAKT gleiche Maschine erwartet. Da kann man nicht einfach "durchmischen".
Spätestens bei wenn man die reale Servo-Welt betritt ist die OOP am Ende.

Frank


----------



## Blockmove (30 März 2011)

drfunfrock schrieb:


> Ich könne mir aber Vorstellen, dass in Zukunft damit auch besser in Schichten gedacht werden kann, so dass man zwischen direkter Hardwaresteuerung und der notwendigen Anwendungslogik unterscheidet.



Viele machen das heute schon ... und wissen gar nicht, dass sie eigentlich Objektorientierung nutzen. Wenn z.B. die Ausgänge gar nicht direkt anspricht, sondern einen "Ausgangs-FB" verwendet, dann ist das eigentlich schon der Anfang.
Fasst man dann diese Ausgangs-FB als Multiinstanzen in einem Stations-FB zusammen und greift per Instanz-DB zu, dann hat man sogar schon den OO-Syntax: "Station4".Zentrierung.Ausfahren.
Nur muss man heute eben noch Symbolische Programmierung, Multiinstanz und Instanzdaten-Zugriff verwenden. Da bei S7 leider die Entwicklungsumgebung dies alles nur halblebig unterstützt, kann es für den Instandhalter schwierig sein, Fehler zu finden.

Gruß
Dieter


----------



## bike (30 März 2011)

Dummy schrieb:


> Hallo,
> 
> ich kann nur aus meiner Sicht sagen, dass wir (mittelständiger Maschinenbauer) TwinCAT 3 lieber gestern als heute eingesetzt hätten.
> Die Mittel, die mit OOP zur Verfügung stehen sind doch wesentlich mächtiger als die Spachelemente, die in  TWinCAT 2 verfügbar sind.
> ...



Vielleicht liegt es daran, dass ich neu beim Programmieren bin.

Wozu brauche ich Vererbung bei einer PLC?
Schnittstellen zu standardisieren ist mit normaler Programmierung ohne Probleme möglich.
Warum überladen? Ein zweites Objekt ist auch keine Sünde.

Bis heute hat mir noch niemand einen Programmcode gezeigt, bei dem OOP wirklich sinnvoll ist.

Durch die Komplexität des Programmes wird es immer schwerer ein Programm sinnvoll zu testen.
Unabhängig davon, dass es schwerer für Außenstehende wird die Anlagen zu warten. 
Es wird leider immer wieder vergessen, dass wir für die Kunden arbeiten.


OOP und die Zuverlässigkeit von WIn$ passen nahtlos zusammen.



bike


----------



## IBFS (30 März 2011)

bike schrieb:


> Es wird leider immer wieder vergessen, dass wir für die Kunden arbeiten.



...das wir für die Wartungstruppen der Kunden arbeiten!!!!!!!!

Da bin ich schon froh, wenn ich nicht alles in KOP programmieren muss.

Frank


----------



## Dummy (30 März 2011)

IBFS schrieb:


> Nur wegen einem Lieferengpass z.B. einen SINAMICS gegen einen Berger-Lahr tauschen? oder umgekehrt - Ich halte das für totalen Unsinn.
> 
> Da sind schon die Achsinbetriebnahmewerkzeuge völlig andere.
> Und wenn beim Kunden schon drei Maschinen stehen, wird oft eine
> ...



Hallo Frank,

vielleicht ist das Beispiel mit den Lieferengpässen nicht gut.
Ansonsten kann ich Dir nur schwer folgen, da der Trend in der Antriebstechnik zum dummen Steller geht. 

Drehmoment-, Drehzahl- und Positionsreglung laufen auf dem Steller.
Die Sollwertführung wird auf der SPS gerechnet. Dazu noch ein bischen Logig fürs Steuerwort. So groß ist dann der Unterschied zwischen verschiedenen Herstellern nicht mehr.

Ich persönlich denke gerade in der Antriebstechnik wird die OOP in der Zukunft sehr wertvoll sein.

Es kann  darüber aber jeder denken wie er will! Aber bei einigen Usern hier, die schon FBs mit In- und Outvariablen als OOP nahen Ansatz sehen, sollten sich noch tiefer damit beschäftigen. Die OOP hat noch viel mehr zu bieten.

Gruß

dummy


----------



## drfunfrock (30 März 2011)

bike schrieb:


> Durch die Komplexität des Programmes wird es immer schwerer ein Programm sinnvoll zu testen.
> Unabhängig davon, dass es schwerer für Außenstehende wird die Anlagen zu warten.
> Es wird leider immer wieder vergessen, dass wir für die Kunden arbeiten.
> bike



Das sind aus meiner Sicht falsche Paradigmen. 

Komplex ist ein Problem, nicht dein Programm. Wie du die Lösung abbildest, dass ist die Herausforderung. Es gilt eine Lösung zu finden, die die Pflege einfach macht und die auch richtig ist.  

Manchmal zwingen einen die Kosten, zu einer Lösung, die die Pflege schwerer macht. Ich ziehe - wenn ich denn darf - immer eine Lösung vor, in der das Programm, die Lösung in der obersten Ebene so einfach wie möglich abbildet. Das hat manchmal den Preis, dass du mehr CPU brauchst. 

Der Kunde soll ein Produkt bekommen, das funktioniert und das pflegeleicht ist. Beides ist keine Selbstverständlichkeit.

Als Programmierer versuche ich darauf zu bestehen, dass der Kunde akzeptiert, dass ich die Lösung anbiete und dafür hafte und er das Pflichtenheft liefert. Das lässt nicht alle Freiheiten, aber gibt dir Gelegenheit darauf aufmerksam zu machen, dass du bestrebt bist ein gutes Produkt zu liefern und du seine Zusammenarbeit benötigst und er dir einräumt, dass du der Fachmann bist. 

Ich habe mit FB OOP nachgebildet und es macht das Testen einfacher und billiger. Kandidaten dafür sind, wiederholende Funktionsgruppen wie Transportsysteme, parallel arbeitende Laboranalyseanlagen, Achsen oder einfach nur die Prozesse an einem Rundtisch. Vererbung wird dann praktisch und macht das Gesamtsystem einfacher, wenn man gemeinsame Funktionalitäten hat, wie bei Achsen oder bei Transportsystemen. Aber auch die Prozesse an einem Rundtisch, haben zb. den Trigger für den Start der Prozess gemeinsam, ebenso wie die Auslieferung von Statusinfos. 

Wer OPP behutsam einsetzt macht sein System wartbarer. Letztlich macht er sich selbst und den Kunden damit glücklicher. Wenn eine Änderung an einem System mit 8 Vakuumventilen 5h braucht, weil man ein Leiterdiagram eingesetzt hat, setzt bei mir jedenfalls jedes Verständnis aus.


----------



## bike (30 März 2011)

drfunfrock schrieb:


> Wer OPP behutsam einsetzt macht sein System wartbarer. Letztlich macht er sich selbst und den Kunden damit glücklicher.




Ja klar so wie bei Win$.
Ein FB kann als ein Objekt angeschaut werden, doch hat es mit OOP nicht so echt viel zu tun.

Wenn du es schaffst den Kunden deinen Programmierstil aufzuschwatzen, dann gut.
Doch was ist wenn der Kunde dies nicht will?
Und denkst du auch die Nachfolger, die deinen Programm warten und ggF weiter entwickeln müssen?


bike


P.S: ich warte immer noch auf ein Beispielprogramm, das mit OOP programmiert werden muss.


----------



## drfunfrock (30 März 2011)

bike schrieb:


> Ja klar so wie bei Win$.
> 
> Wenn du es schaffst den Kunden deinen Programmierstil aufzuschwatzen, dann gut.
> Doch was ist wenn der Kunde dies nicht will?
> Und denkst du auch die Nachfolger, die deinen Programm warten und ggF weiter entwickeln müssen?



Wenn der Kunde es nicht will, ist es seine Entscheidung. Und da OOP gut wartbar ist, wird auch ein Nachfolger damit zurechtkommen.


----------



## IBFS (30 März 2011)

bike schrieb:


> P.S: ich warte immer noch auf ein Beispielprogramm, das mit OOP programmiert werden muss.



...ich warte mit  

Da war einmal ein neuer Programmierer in einer mir nahestehenden Firma.
Schlauer Kerl, kam frisch von der UNI und wollte jede Station einer Maschine
schön verpacken - alles mit Pointer durchreichen über zwei FB-Layer usw.
Für die UNI war das SPS-Programm gut geeignet, aber in der Praxis gingen
dann die liebgewonnenen Funktionen "Referenzdaten" nur sehr schwerlich.

Frank


----------



## Dummy (30 März 2011)

bike schrieb:


> Vielleicht liegt es daran, dass ich neu beim Programmieren bin.
> 
> Wozu brauche ich Vererbung bei einer PLC?
> Schnittstellen zu standardisieren ist mit normaler Programmierung ohne Probleme möglich.
> ...



Hallo Bike,

wozu braucht man Vererbung?
Um nicht ständig den gleichen Code neu zu schreiben!
In meiner letzten Firma haben wir z.B. 3 FBs für  fast gleiches Module gehabt. Der Gleichanteil lag bei etwa 80%. Wenn ich etwas am gleichen Anteil geändert habe, musst ich dies 3 mal machen!

Was ist dann passiert:
Wie alle Programmierer bin ich ziemlich faul! :-D
 Also,  2 mal copy and paste. Leider habe ich dabei aber einen Fehler gemacht, so dass der FB nicht mehr sauber gearbeitet hat. Festgestellt habe ich es erst einige Monate später, da diese FBs voher nicht benutzt wurden. So was kann ganz schön schmerzhaft und teuer sein.

Die andere Variante ist alles in einem Fb zu machen und die unterschiede mit cases und ifs abzufangen. Daraus wird über einen längeren Zeitraum ganz schöner Spaghetti-Code. Viel Spaß damit!

Warum überladen? Siehe oben!

Was zum Teufel ist win$? Siemens? Wenn Du den Verein meinst, kann ich Dich beruhigen, die sind von OOP so weit entfernt, wie der Mars von der Erde.

OOP ist im Übrigen ein Mittel um komplexe Problem zu lösen und nicht zu erschaffen. Ein falscher OOP Ansatz kann aber durchaus problematisch werden. Ist aber bei allen anderen Methoden genauso.

Gruß

dummy


----------



## Dummy (30 März 2011)

bike schrieb:


> Ja klar so wie bei Win$.
> Ein FB kann als ein Objekt angeschaut werden, doch hat es mit OOP nicht so echt viel zu tun.
> 
> Wenn du es schaffst den Kunden deinen Programmierstil aufzuschwatzen, dann gut.
> ...



Hier ein Beispiel von 3S:

http://www.3s-software.com/index.shtml?de_v3_oop&sitesearchmatch=oop#sitesearchmatch

Ist sicherlich nur ein einfaches Beispiel, dass bestimmt nicht objektorientiert Programmiert werden muss!

Aber was muss schon! Ich kann auch alles mit AWL programmiern oder noch besser den Locher für den Lochstreifen aus dem Keller holen 

Gruß dummy


----------



## bike (30 März 2011)

Dummy schrieb:


> Hallo Bike,
> 
> wozu braucht man Vererbung?
> Um nicht ständig den gleichen Code neu zu schreiben!
> ...



Einen Baustein ohne Prüfung raus zuschicken ist dumm. Egal ob vererbt oder neu geschrieben.




Dummy schrieb:


> Die andere Variante ist alles in einem Fb zu machen und die unterschiede mit cases und ifs abzufangen. Daraus wird über einen längeren Zeitraum ganz schöner Spaghetti-Code. Viel Spaß damit!



Man kann sehr wohl sauber programmieren, ohne dass gleich Spagetti wird. Das liegt nur an der Planung der Funktion(en)



Dummy schrieb:


> Was zum Teufel ist win$?



Nein, das ist ein Verein in Redmond, der es perfekt schafft Bugfix als Neuerungen für viele $ zu verkaufen.



Dummy schrieb:


> OOP ist im Übrigen ein Mittel um komplexe Problem zu lösen und nicht zu erschaffen. Ein falscher OOP Ansatz kann aber durchaus problematisch werden. Ist aber bei allen anderen Methoden genauso.
> 
> Gruß
> 
> dummy



Ich weiß schon was OOP ist und verwende es auch in Programmen, aber bitte nicht in der PLC.

Wenn ich in VB oder C(mit Abkömmlingen) oder Delphi schreibe nutze ich OOP auch, denn da macht es Sinn und ist ein Teil der Grundlagen der Sprache.


bike


----------



## Dummy (30 März 2011)

bike schrieb:


> Einen Baustein ohne Prüfung raus zuschicken ist dumm. Egal ob vererbt oder neu geschrieben.
> 
> 
> 
> ...



Hallo Bike,

ich kann Dich beruhigen. Der vehlerhafte Code ist nicht mit ausgeliefert worden.  So dumm, bin ich dann doch nicht............

Warum man OOP nicht in der SPS benutzen sollte ist mit allerdings immer noch nicht klar. Im Übrigen kann man nur wirklich OOP-Programmieren, wenn das Tool es unterstützt.


----------



## drfunfrock (30 März 2011)

OOP und Winzigweich hier gleichzusetzen ist schönstes Trollen. :roll::roll:


----------



## Werner29 (31 März 2011)

Ich habe hier mal einen Entwurf für einen Artikel für eine Fachzeitschrift angehängt (leider in englisch).
Darin zeige ich, wie wir (für unsere Systembibliotheken) die Objektorientierung einsetzen, ohne dass ein Benutzer der Bibliotheken davon überhaupt was mitbekommt. Die Grundidee kommt eigentlich von den Motion Control Blöcken der PLCOpen.
Der Artikel ist dann mit einem anderen Beispiel erschienen, das ist vielleicht auch interessant und hier
http://www.3s-software.com/index.shtml?en_publications&news=IEEE_BW_2010
zu finden.


----------



## bike (31 März 2011)

drfunfrock schrieb:


> OOP und Winzigweich hier gleichzusetzen ist schönstes Trollen. :roll::roll:



Nicht wirklich, das passt zusammen wie die Faust aufs Auge.


bike


----------



## bike (31 März 2011)

Dummy schrieb:


> Aber was muss schon! Ich kann auch alles mit AWL programmiern oder noch besser den Locher für den Lochstreifen aus dem Keller holen
> 
> Gruß dummy



Mit der Aussage hast du recht.
Schreibe ein Programm so, dass es kein anderer nicht bzw nur nach viel Aufwand versteht, dann bist du unabkömmlich.
Ich denke du kennst Lochstreifen nicht und kannst so auch nicht programmieren. 


bike


----------



## drfunfrock (31 März 2011)

bike schrieb:


> Nicht wirklich, das passt zusammen wie die Faust aufs Auge.
> 
> 
> bike



Na, dann ist ein Mann, nur ein Mann, wenn er es versteht, seine SPS Bitweise mit binären Schaltern zu programmieren.


----------



## Dummy (31 März 2011)

bike schrieb:


> Mit der Aussage hast du recht.
> Schreibe ein Programm so, dass es kein anderer nicht bzw nur nach viel Aufwand versteht, dann bist du unabkömmlich.
> Ich denke du kennst Lochstreifen nicht und kannst so auch nicht programmieren.
> 
> ...



Was willst Du mir damit sagen?
Das OOP dafür da ist damit andere das Programm nicht verstehen oder
das Du OOP nicht verstehst?

Ansonsten hat es nichts mit dem Thema zu tun.
Ist Dir langweilig oder willst Du nur ein sehr interesantes Thema zerreden?

In einer Sache gebe ich Dir recht.
Ich kann keine Lochstreifen programmieren!


----------



## bike (31 März 2011)

Dummy schrieb:


> Was willst Du mir damit sagen?
> Das OOP dafür da ist damit andere das Programm nicht verstehen oder
> das Du OOP nicht verstehst?
> 
> ...



Warum so nett?
Weil ich anderer Meinung bin?

Also ich kann Hochsprachen und auch OOP.
Langweilig ist mir nicht.
Ich schreibe aus der Erfahrung, da ich seit längerem programmiere und eben gelernt habe zu differenzieren, wann was und wie sinnvoll ist.
Interessantes Thema? Also bei uns ist OOP in der Entwicklung von PLC Programmen kein Thema, da es nach unserer Meinung nicht sinnvoll ist.

Es ist aber immer schön zu lesen was und wie Jungdynamiker alle paar Jahre die Maschinenprogrammierung revolutionieren (wollen).


bike


----------



## drfunfrock (31 März 2011)

Das ist eben sogenanntes Elitedenken. Weder Alter noch Erfahrung schützen vor Torheit 

Entweder taugt OOP etwas oder es taugt nichts. Wenn es taugt, dann gibt keinen Grund es nicht im Bereich von SPSen anzuwenden. Und wer eine SPS programmieren kann, der wird auch OOP so anwenden, dass es andere verstehen. Bei grösseren System wird das ganze damit auch verständlicher und vor allem lassen sich die Komponenten dann auch leichter unabhängig testen.  Wer es nicht fertigbringt gute OOP-Programmierung abzuliefern, wird auch mit Nicht-OOP nichts vernünftiges ausliefern. 

Alles andere ist FUD.


----------



## IBFS (31 März 2011)

drfunfrock schrieb:


> Entweder taugt OOP etwas oder es taugt nichts. Wenn es taugt, dann gibt keinen Grund es nicht im Bereich von SPSen anzuwenden.



In einem aktuellen Projekt "musste" ein bestimmter Standard (OOP-ähnlich) verwendet werden.
Im anschl. Controlling fand man heraus, dass die IB-Zeit mit diesem OOP-Stil
auf Basis von CoDeSys fast doppelt so hoch war, als mit den alten klassischen
Strukturen in STEP7.

Das hat was mit oft "endlosem" Deklarieren zu tun, die ein Übermäßiges
Kapseln mit sich bringt.

In PC-Applikationen bin ich der letzte, der etwas gegen OOP sagen würde,
aber in der SPS-Technik funktioniert OOP führt mich nur, wenn die 
Schreib- und Deklarierarbeit im Rahmen bleibt.

Wenn du einmal in CoDesys V2.3 in ST (STRUCTURD TEXT) endlose
FB-Deklarationen wie Matrioshkas ineinander packen musstest - ohne
Kontexthilfe - dann sieht du möglicherweise manches anders .

Frank


----------



## drfunfrock (31 März 2011)

IBFS schrieb:


> In einem aktuellen Projekt "musste" ein bestimmter Standard (OOP-ähnlich) verwendet werden.
> Im anschl. Controlling fand man heraus, dass die IB-Zeit mit diesem OOP-Stil
> auf Basis von CoDeSys fast doppelt so hoch war, als mit den alten klassischen
> Strukturen in STEP7.
> ...



Ich glaub dir das. Ich denke auch mehr an einen Mix aus konventionellem Code und Objekten. Ich denke zur Zeit nur an Rundtische mit mehr als 4 Prozessen und Montrac-Anlagen. Wie schön wäre es gewesen, OOP dort einzusetzen, wenn man per Vererbung, die Grundstrukturen für jeden Prozess schon fertig hat. Das sieht dann schöner aus, als einen FB im FB zu instanzieren und die IO durchzureichen und sollte lesbarer sein. 

Ich denke aber auch an die Kommunikation zwischen Labview (Testsystem) und der SPS. So etwas schreit förmlich danach, vor allem weil ich es ständig brauche.


----------



## bike (31 März 2011)

drfunfrock schrieb:


> Das ist eben sogenanntes Elitedenken. Weder Alter noch Erfahrung schützen vor Torheit
> 
> Entweder taugt OOP etwas oder es taugt nichts. Wenn es taugt, dann gibt keinen Grund es nicht im Bereich von SPSen anzuwenden. Und wer eine SPS programmieren kann, der wird auch OOP so anwenden, dass es andere verstehen. Bei grösseren System wird das ganze damit auch verständlicher und vor allem lassen sich die Komponenten dann auch leichter unabhängig testen.  Wer es nicht fertigbringt gute OOP-Programmierung abzuliefern, wird auch mit Nicht-OOP nichts vernünftiges ausliefern.
> 
> Alles andere ist FUD.



Hab ich dir auf die Füße getreten? 
Das tut mir leid.  
Die Kunst besteht darin, eine Anlage so zu strukturieren, dass die einzelnen Teile für und in sich in Betrieb und getestet werden können.
Wenn bei der Inbetriebnahme bei der 4. Station ein Fehler auftritt und die Funktion geändert werden muss, dann beginnst du mit der Inbetriebnahme wieder von vorne.
Das kann es nicht sein.

Daher setzt sich ja OOP bei PLC noch? nicht durch, das hast du richtig erkannt. 
Für jede Aufgabenstellung sollte das richtige Werkzeug genommen werden.

Und deine Erfahrung mit LabView kannst du nicht auf Maschinen und Anlagen anwenden, würde ich sagen.
Wenn wir zeitkritisch programmieren, dann wird jedes Bit mehrmals überprüft, ob es notwendig ist. 

Wie IBFS geschrieben hat, steht der Aufwand für OOP Entwicklung in keinem Verhältnis zum Ergebnis. 
Wenn ich meine PC Applikationen anschaue kommen diese nicht ohne OOP aus und das ist ja auch da so sinnvoll.


bike


----------



## zotos (31 März 2011)

bike schrieb:


> ...
> Wie IBFS geschrieben hat, steht der Aufwand für OOP Entwicklung in keinem Verhältnis zum Ergebnis.
> ...



Eine "schöne" Verallgemeinerung. Alle Projekte sind ja auch gleich ;o)

Die Firma BR hat im Januar im SPS-Magazin das etwas besser dargestellt:






Quelle: sps-magazin.de
Hier der Link zum Artikel: http://www.sps-magazin.de/?inc=artikel/article_show&nr=59182


----------



## rostiger Nagel (31 März 2011)

zotos schrieb:


> Eine "schöne" Verallgemeinerung. Alle Projekte sind ja auch gleich ;o)
> 
> Die Firma BR hat im Januar im SPS-Magazin das etwas besser dargestellt:
> 
> ...



Das sieht aus wie eine Break Even Point Analyse, das haben die bestimmt nur kopiert


----------



## bike (31 März 2011)

Wo liegt die Komplexitätsgrenze?
Was ist das? Bisher ist mir dies noch nie begegnet.
Und es ist klar, dass man als Hersteller von irgendetwas  versucht einen Nutzen zu generieren. 
Machen wir als Hersteller auch, da werden auch DInge angeboten die nicht immer sinnvoll sind. 


bike


----------



## IBFS (31 März 2011)

Jedes SPS-Programm besteht im Prinzip aus einer Sammlung von ganz simplen Sachen. 
Wenn ein SPS-Programm zu komplex wird, hat man die Teilabläufe
oder Teilprobleme nicht lange genug in appetitliche SPS-Happen zerhackt.

Daher ist es für mich ein Märchen, dass es KOMPLEXE SPS-Programme geben könnte.
Es gibt nur viel - hoffentlich gut strukturierten Code. 

Oft komm vermeintliche Komplexität auch daher, das der Konstrukteur
was ganz besonders tolles konstruieren wollte anstatt möglichst einfach
zu konstruieren. 

Beispiel: 
Der Konstrukteur baut eine Kollision- bzw. Störkontur ein, die durch 
frühzeitiges Verrücken einer Teilstation um wenige Zentimeter hätte
vermieden werden können. 
Ergebnis ist eine viel aufwändigere Grundstellungsfahrt.  


Das es bei PC-Applikationen komplexe Programme gibt, da stimme ich zu,
wobei auch hier in der Modularisierung der Schlüssel zur Einfachheit liegt.

Frank


----------



## zotos (31 März 2011)

Die Komplexität bezieht sich auf die Aufgabe nicht auf den Code.

Modularisierung ist der Vorfahre bzw. einbestandteil der Objektorientierten Programmierung.


----------



## drfunfrock (31 März 2011)

bike schrieb:


> Die Kunst besteht darin, eine Anlage so zu strukturieren, dass die einzelnen Teile für und in sich in Betrieb und getestet werden können.
> Wenn bei der Inbetriebnahme bei der 4. Station ein Fehler auftritt und die Funktion geändert werden muss, dann beginnst du mit der Inbetriebnahme wieder von vorne. Das kann es nicht sein.
> 
> Daher setzt sich ja OOP bei PLC noch? nicht durch, das hast du richtig erkannt.
> ...



Da sind wir uneinig. Für mich sind Stationen potentielle Objekte im Code und hier lohnt es richtig. 
Ich hab vor Jahren mal damit gearbeitet: 

http://www.youtube.com/watch?v=1ZS0J8UQSSg

Jede Station ist hier ein Objekt, dass beim Halten des Wagens

- sicherstellen muss, dass der Wagen auch in Position ist (Die Technik dieser Wagen ist suboptimal)
- die Wagen-ID auslesen muss um
- dann den vom Produkt, dass sich auf dem Wagen befindet, abhängigen Produktionsprozess zu starten. (nein, das war nicht fest)

Ohne Vererbung ist das unschön, aber mit FBs konventionell per Pseudo-OOP machbar. Mit OOP wäre das bei 40 Stationen noch schöner geworden. Ich habe jede Station für sich testen können oder auch nur den Wagensteuercode testen können. Gerade an solchen Anlagen lohnt es. 
Ich habe die Kommunikation zwischen Wagenmanagement und dem einzelnen Prozess per Event-System gelöst. Ein Event hat z.B. einen Prozess gestartet und per Event habe ich den Status zurückgemeldet.  Das wäre alles schöner mit OOP geworden. Dagegen habe ich die einzelnen Prozesse als ganz gewöhnliche Schrittketten implementiert. Ich habe während der 4 Jahre, die diese Anlage gelaufen hat, insgesamt ca. 10 grössere Änderungen eingebaut, um neuen Anforderungen zu entsprechen. Und keine von denen hat die Produktion mehr als 2h gestoppt. Das hat übrigens nur 1 TwinCat Installation gesteuert. 

OOP richtig angewendet, macht das Leben leichter. Ich würde es aber nicht vollständig durchziehen, wenn es nicht lohnt. Das war übrigens mein erstes Projekt   Mein Hintergrund liegt eigentlich in der Microelektronik mit VHDL und so.


----------



## Werner29 (1 April 2011)

IBFS schrieb:


> Jedes SPS-Programm besteht im Prinzip aus einer Sammlung von ganz simplen Sachen.
> Wenn ein SPS-Programm zu komplex wird, hat man die Teilabläufe
> oder Teilprobleme nicht lange genug in appetitliche SPS-Happen zerhackt.


Das ist schon richtig, aber unterscheidet sich nicht von der PC-Programmierung. Das Versprechen der OOP ist ja gerade, dieses Zerhacken zu unterstützen. 
Schau dir doch mal mein Beispiel an und sag uns, wie man das mit herkömmlichen Mitteln besser macht.
Ich habe noch ein Beispiel für dich:
http://www.3s-software.com/index.shtml?de_OOP
Ist das schlechter Stil? Wo liegen die Nachteile in der Vorgehensweise?

Bernhard


----------



## bike (2 April 2011)

Werner29 schrieb:


> Wo liegen die Nachteile in der Vorgehensweise?



Geht es um Nachteile?
Sollte nicht die Fragestellung sein: 
Vorteile bei dieser Art der Programmierung?


bike


----------



## Larry Laffer (2 April 2011)

... ist interessant das hier mitzulesen ... 

Die Vor- und Nachteile einer Programmierart liegen IMMER im Auge des Betrachters. Damit meine ich jetzt auch nichts Spezielles. Ich habe mich z.B. erst letztens noch mit jemanden unterhalten, der mit sein schlecht strukturiertes und unübersichtliches FUP-Programm als das Non-plus-Ultra "verkaufen" wollte. Auch da war es mir nicht möglich, den Aderen zu überzeugen - es ging nur mit zwingen ...

Im Falle des Themas hier würde ich sagen, dass man OOP wenn man es einmal wirklich und richtig verstanden hat nicht mehr missen möchte. Leider kann ich es für mich nur in meiner kleinen Visual-Studio-Welt praktizieren. In der Step7-Welt gibt es das ja LEIDER gar nicht und auch nicht die Möglichkeit, es zu nutzen - vielleicht irgendwann in ferner Zukunft mal, da auch die sich sicherlich dahin entwickeln werden. Also versuche ich für wiederkehrende Funktions-Strukturen einen Pseudo-OOP-FB zu bauen, der seine Methoden über die Schnittstelle bereitstellt.

Bezüglich dieser Vorgehensweise kann ich die von Zotos hier eingestellte Grafik nur bestätigen. Hat man erstmal seine Basis zusammen so kann man für eine Anlage (die ja bei uns in ihrer Grundstruktur auch immer ähnlich ist - trotz Sonder-Maschine) sehr schnell ein funktionierendes Programm zusammen. Da brauche ich schon heute für die Visu doppelt so viel Zeit, wie für das Programm - und so schrecklich viel können meine Visu's nun auch wieder nicht.

Wie auch immer ... ich würde die OOP-Idee absolut unterstützen und sehe sie auch nicht als "neumodischen Kram" oder wie immer man sagen möchte.
Es hat aber sicherlich jeder so seinen Stil, den er vielleicht auch mit einem gewissen Recht verteidigt - ich bin bei meiner Masche auch zu wenig Zugeständnissen bereit ...

Gruß
Larry


----------



## Dummy (3 April 2011)

Werner29 schrieb:


> Das ist schon richtig, aber unterscheidet sich nicht von der PC-Programmierung. Das Versprechen der OOP ist ja gerade, dieses Zerhacken zu unterstützen.
> Schau dir doch mal mein Beispiel an und sag uns, wie man das mit herkömmlichen Mitteln besser macht.
> Ich habe noch ein Beispiel für dich:
> http://www.3s-software.com/index.shtml?de_OOP
> ...



Hallo Bernhard,

da sich niemand mit den Nachteilen auseinandersetzen möchte, werden ich mal versuchen einige Vorteile aufzuzeigen:

1.)Flexibilität 
Eine Änderung des Raumtypes ist nur durch eine Deklerations-Änderung möglich. Es muss kein Quellcode verändert werden.
Dies sollte jeder Instandhalter/Hausmeister schaffen.

2.)Erweiterbarkeit
Bei einem Anbau von mehreren Räumen ist es ebenfalls nur durch eine Neu-Deklaration der neuen Räume möglich. 

Sollte ein neuer Raumtyp benötigt werden, kann ebenfalls durch Vererbung auf bestehenden Code zurück gegriffen werden. Es müssen nur die zusätzlichen Funktionen implementiert werden.

Gesamteindruck:
Die Syntax ist die Gleiche wie in ST. Es wurden nur zusätzliche Funktionen der OOP hinzugefügt. Jeder der schon mit ST-Programmiert hat, kann sich darin schnell zu recht finden. 

Gruß

dummy


----------



## bike (3 April 2011)

Dummy schrieb:


> 1.)Flexibilität
> Eine Änderung des Raumtypes ist nur durch eine Deklerations-Änderung möglich. Es muss kein Quellcode verändert werden.
> Dies sollte jeder Instandhalter/Hausmeister schaffen.



Kann jeder Standard FB einer PLC auch.
Über ein OP die Eingangsparameter ändern und weiter geht es.



Dummy schrieb:


> 2.)Erweiterbarkeit
> Bei einem Anbau von mehreren Räumen ist es ebenfalls nur durch eine Neu-Deklaration der neuen Räume möglich.
> 
> Sollte ein neuer Raumtyp benötigt werden, kann ebenfalls durch Vererbung auf bestehenden Code zurück gegriffen werden. Es müssen nur die zusätzlichen Funktionen implementiert werden.



Einen neuen FB mit den richtigen Parameter einfügen und es funktioniert ebenso.



Dummy schrieb:


> Gesamteindruck:
> Die Syntax ist die Gleiche wie in ST. Es wurden nur zusätzliche Funktionen der OOP hinzugefügt. Jeder der schon mit ST-Programmiert hat, kann sich darin schnell zu recht finden.
> 
> Gruß
> ...



Leider sehe ich den Vorteil bei PLC mit OOP immer noch nicht.


----------



## Dummy (3 April 2011)

bike schrieb:


> Kann jeder Standard FB einer PLC auch.
> Über ein OP die Eingangsparameter ändern und weiter geht es.



Ja, das kann man so machen.
Aber:




IBFS schrieb:


> Jedes SPS-Programm besteht im Prinzip aus einer Sammlung von ganz simplen Sachen.
> Wenn ein SPS-Programm zu komplex wird, hat man die Teilabläufe
> oder Teilprobleme nicht lange genug in appetitliche SPS-Happen zerhackt.
> Frank


 
_

_
Wiederspricht sich dies nicht? Wenn ich alle Varianten in einem FB programmiere sind doch die Teilaufgaben nicht mehr in appetitlichen Happen.
Es geht aber auch  X-Fbs mit nahezu identischen Code zu pflegen.
Finde ich persönlich gar nicht gut! 




bike schrieb:


> Einen neuen FB mit den richtigen Parameter einfügen und es funktioniert ebenso.


Auch das geht, wenn man zusätzlich auch noch den Code ändern möchte.

Gruß

dummy


----------



## bike (3 April 2011)

Dummy schrieb:


> Auch das geht, wenn man zusätzlich auch noch den Code ändern möchte.
> 
> Gruß
> 
> dummy



Ein Objekt mit zusätzlichen Eigenschaften, muss ich doch auch ändern, oder versteh ich jetzt etwas wieder nicht? 
Ob ich einen FB habe mit den Standardfunktionen habe und den dann ggF ableite(kopiere) oder zusätzlich aufrufe für neue und zusätzliche Funktionen, dann funktioniert dies.

Ich gehe absolut konform, dass OOP eine Berechtigung hat.
Doch in der PLC noch? nicht. 
Vielleicht sieht man es anders wenn man nur Anlagen programmiert.


bike


----------



## Dummy (3 April 2011)

bike schrieb:


> Ein Objekt mit zusätzlichen Eigenschaften, muss ich doch auch ändern, oder versteh ich jetzt etwas wieder nicht?
> Ob ich einen FB habe mit den Standardfunktionen habe und den dann ggF ableite(kopiere) oder zusätzlich aufrufe für neue und zusätzliche Funktionen, dann funktioniert dies.
> 
> bike



Gut, wenn Du ein neuen bisher unbekannten Typen implemtieren willst, musst Du auch bie OOP den Code ändern. Hast Du das Beispiel überhaupt angesehen. 

Allerding hat Ableiten so gut wie nichts mit kopieren zu tun!

Was mich bei Dir nervt, ist dass Du hier immer solche Dinger raus haust:



bike schrieb:


> Ich gehe absolut konform, dass OOP eine Berechtigung hat.
> Doch in der PLC noch? nicht.
> Vielleicht sieht man es anders wenn man nur Anlagen programmiert.
> 
> bike



Warum musst Du für die ganze SPS-Fachwelt sprechen.
Es gibt eben welche, die sehen die Vorteile.
Also sprich besser für Dich und nicht für alle.
Außerdem warten hier immer noch viele darauf, dass Du uns mal die Nachteile erklärst.

Schönen Abend noch.

dummy


----------



## bike (3 April 2011)

Dummy schrieb:


> Also sprich besser für Dich und nicht für alle.
> Außerdem warten hier immer noch viele darauf, dass Du uns mal die Nachteile erklärst.
> 
> Schönen Abend noch.
> ...



Falscher Ansatz, würde ich sagen.
Es geht drum etwas zu verbessern, nicht das neue rote Rad als neu zu verkaufen, weil der Vorgänger schwarz war.

Ich programmiere in einer Firma mit zur Zeit 30 Programmieren in einem Großraum. 
Wir programmieren nicht nur Step7, sondern Fanuc und Bosch und Heidenhain und Codesys und ...
Denkst du wir reden nicht und wenn so viele Entwickler zusammen sind, kommen viele Meinungen und Erfahrungen zusammen.

Ich versuche die Vorteile zu verstehen und wie unsere Kunden davon profitieren können.
Mir hat ein Autohersteller in Paris ins Gesicht gesagt: 
"Eure Entwicklung ist für den Hersteller gut, aber nicht für den Kunden."
Das war keine OOP, sondern AWL und SCL.  

Daher ist in unserem Focus der Kunde und nicht mit oder ohne OOP oder sonstigem.

Dir auch einen entspannten Abend


bike


----------



## Dummy (3 April 2011)

bike schrieb:


> Falscher Ansatz, würde ich sagen.
> Es geht drum etwas zu verbessern, nicht das neue rote Rad als neu zu verkaufen, weil der Vorgänger schwarz war.
> 
> Ich programmiere in einer Firma mit zur Zeit 30 Programmieren in einem Großraum.
> ...



Die Menschheit hat auch mal geglaubt im Mittelpunt des Universum zu stehen. Da war die Erde auch noch eine Scheibe.
Heute reicht dafür schon ein Großraumbüro...........

Nur ein Beispiel warum wir aus anderen Welten kommen:

Unser Kunde bekommt den Quellcode nicht zu gesicht.


----------



## bike (3 April 2011)

Dummy schrieb:


> Die Menschheit hat auch mal geglaubt im Mittelpunt des Universum zu stehen. Da war die Erde auch noch eine Scheibe.
> Heute reicht dafür schon ein Großraumbüro...........



Deine Weisheiten sind echt Klasse.
Den "Mittelpunt" sind wir doch immer noch, oder?





Dummy schrieb:


> Nur ein Beispiel warum wir aus anderen Welten kommen:
> 
> Unser Kunde bekommt den Quellcode nicht zu gesicht.



Wir müssen unseren Code nicht verstecken *ROFL*

So als kleiner Denkansatz


bike


P.S: bei uns in Bayern gibt es den Begriff des Klugscheißers.


----------



## IBFS (3 April 2011)

@bike
@Dummy

Ich denke 

1. ihr redet momentan völlig aneinander vorbei
2. wir müssen hier nicht mit Adam und Eva oder Gallileo anfangen
3. das Teilprojekte oder Aufgaben eben noch lange keine Objekte sind
4. die Vererbung ist im "harten" Vorort-SPS-Alltag ohne Netzzugang zum firmeninteren Code-Source -Safe nur in sehr wenigen Fällen praktikabel
5. solange der Eine von LabView und C#  und der Andere von CodeSys und STEP7 redet bringt ein Diskussion recht wenig, weil die Daten- ,Wissens- und Erfahrungsbasis völlig verschieden sind.
6. die Gebäudetechnik als Maßstab herzunehmen ( Anbau von mehreren Räumen ) ist unglücklich, weil das mit KNX, LON etc. gemacht wird und da wird eher parametriert als programmiert.
7. geht mal zusammen ein Bier trinken, dass ist effektiver

Grüße

Frank


----------



## bike (3 April 2011)

IBFS schrieb:


> 7. geht mal zusammen ein Bier trinken, dass ist effektiver



Das ist der beste Beitrag zu diesem Thema, denn da gibt es keinen Reibpunkt.

Ich hätte gern ein beck's gold, nicht zu kalt bitte.

bike


----------

