Zuviel Werbung? - > Hier kostenlos beim SPS-Forum registrieren

Seite 4 von 8 ErsteErste ... 23456 ... LetzteLetzte
Ergebnis 31 bis 40 von 77

Thema: Programmiersprachen

  1. #31
    Registriert seit
    02.02.2007
    Beiträge
    104
    Danke
    12
    Erhielt 16 Danke für 13 Beiträge

    Standard


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

  2. Folgender Benutzer sagt Danke zu Dummy für den nützlichen Beitrag:

    Werner29 (30.03.2011)

  3. #32
    Registriert seit
    30.08.2005
    Beiträge
    280
    Danke
    41
    Erhielt 96 Danke für 66 Beiträge

    Standard

    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.

  4. #33
    Registriert seit
    10.12.2009
    Beiträge
    41
    Danke
    1
    Erhielt 5 Danke für 5 Beiträge

    Standard

    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.

  5. #34
    Registriert seit
    14.08.2004
    Beiträge
    824
    Danke
    45
    Erhielt 73 Danke für 66 Beiträge

    Standard

    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.

  6. #35
    Registriert seit
    25.06.2007
    Ort
    Dresden
    Beiträge
    3.930
    Danke
    465
    Erhielt 878 Danke für 634 Beiträge

    Standard

    Zitat Zitat von drfunfrock Beitrag anzeigen
    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
    Grüße Frank

  7. Folgender Benutzer sagt Danke zu IBFS für den nützlichen Beitrag:

    marlob (30.03.2011)

  8. #36
    Registriert seit
    17.07.2009
    Ort
    Am Rande der Ostalb
    Beiträge
    5.480
    Danke
    1.141
    Erhielt 1.242 Danke für 973 Beiträge

    Standard

    Zitat Zitat von drfunfrock Beitrag anzeigen
    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

  9. #37
    Registriert seit
    03.04.2008
    Beiträge
    6.200
    Danke
    237
    Erhielt 815 Danke für 689 Beiträge

    Standard

    Zitat Zitat von Dummy Beitrag anzeigen
    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

  10. #38
    Registriert seit
    25.06.2007
    Ort
    Dresden
    Beiträge
    3.930
    Danke
    465
    Erhielt 878 Danke für 634 Beiträge

    Standard

    Zitat Zitat von bike Beitrag anzeigen
    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
    Grüße Frank

  11. #39
    Registriert seit
    02.02.2007
    Beiträge
    104
    Danke
    12
    Erhielt 16 Danke für 13 Beiträge

    Standard

    Zitat Zitat von IBFS Beitrag anzeigen
    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

  12. #40
    Registriert seit
    14.08.2004
    Beiträge
    824
    Danke
    45
    Erhielt 73 Danke für 66 Beiträge

    Standard


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    Zitat Zitat von bike Beitrag anzeigen

    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.

Ähnliche Themen

  1. Brauche Hilfe! Programmiersprachen für Basissoftware einer sps
    Von fun4you1974 im Forum Sonstige Steuerungen
    Antworten: 10
    Letzter Beitrag: 14.07.2006, 10:55

Stichworte

Lesezeichen

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •