Programmiersprachen

Zuviel Werbung?
-> Hier kostenlos registrieren
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.

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.
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.
 
@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: 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.
 
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
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
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.
 
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?

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
 
Zuviel Werbung?
-> Hier kostenlos registrieren
...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.
 
...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.
 
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
 
Zuviel Werbung?
-> Hier kostenlos registrieren
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.
 
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" :ROFLMAO: 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.
 
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.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
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
 
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
 
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

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
 
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

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
 
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. :ROFLMAO:

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.
 
Zurück
Oben