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

Seite 1 von 4 123 ... LetzteLetzte
Ergebnis 1 bis 10 von 35

Thema: Schwerpunkt Hochsprachenprogrammierung - Strukturierter Text

  1. #1
    Registriert seit
    24.05.2012
    Beiträge
    3
    Danke
    0
    Erhielt 6 Danke für 2 Beiträge

    Standard


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    Gegenwärtig befassen wir uns im SPS-MAGAZIN mit der Tatsache, dass immer mehr Anwender Interesse an Hochsprachenprogrammierung zeigen. Im ersten Teil einer Artikelserie erläutern wir beispielsweise die Vorteile dieser modernen SPS-Sprachen. Die Anweisungsliste (AWL) als Programmiersprache wird zunehmend von Strukturiertem Text abgelöst. Wo ST eingesetzt wird und welche Veränderungen sich dadurch ergeben können, könnt ihr hier nachlesen: http://sps-magazin.de/?inc=artikel/a..._show&nr=95329

    Programmiert ihr vielleicht selbst viel in ST, C, Automation Basic oder einer anderen Hochsprache?
    Plant ihr einen Umstieg oder habt ihn bereits hinter euch?
    Eure Erfahrungen und Kommentare nehmen wir gerne in unserer redaktionellen Berichterstattung auf.
    Zitieren Zitieren Schwerpunkt Hochsprachenprogrammierung - Strukturierter Text  

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

    rostiger Nagel (12.02.2015)

  3. #2
    Registriert seit
    24.02.2009
    Beiträge
    1.242
    Danke
    23
    Erhielt 276 Danke für 235 Beiträge

    Standard

    Erstaunlich das eine Programmiersprache, die es in der Steuerungstechnik seit über 20 Jahren gibt, teilweise immer noch wie Neuland© behandelt wird.
    Sänd from mei Kombjudder mitse Dastadurr.

  4. #3
    Registriert seit
    09.11.2007
    Ort
    Rhein Main (Darmstadt)
    Beiträge
    663
    Danke
    61
    Erhielt 112 Danke für 80 Beiträge

    Standard

    Zitat Zitat von MasterOhh Beitrag anzeigen
    Erstaunlich das eine Programmiersprache, die es in der Steuerungstechnik seit über 20 Jahren gibt, teilweise immer noch wie Neuland© behandelt wird.
    Das ist ein Ausbildungsproblem. Die Praktiker sind zugeschüttet mit Arbeit und wissen nicht, was ihnen entgeht, wenn sie weiter mit AWL etc. rumwursteln. Ausserdem sind sie bescheiden und klopfen nicht auf den Tisch wie die Piloten. Die Entscheider investieren aus ihrer Sicht lieber in Management Kurse als in Technik Fortbildung, weil sie davon nichts verstehen. Es ist schon ein Unterschied, ob ich ein paar Relais durch eine SPS ersetze wie in den Anfängen, oder ob ich eine vernetzte Fertigungsstrasse mit synchronen Antrieben und Safety Anforderungen programmieren soll.

    Die Unis sind da nicht besser, mir graut, wenn ich da so manche Fragestellungen von Studenten hier im Forum lese.

    Real besteht zusätzlich das Problem, dass ST zwar IEC genormt ist, aber jeder Hersteller bewusst ein wenig gegen die Norm verstösst (z.B. TIA Customer LockIn), damit die Kunden nicht abwandern können.

    Längst hat die allgemeine Software Wissenschaft Sprachen wie ST (aufgebohrtes PASCAL) auf den Müllhaufen der Geschichte befördert und hätte passendere elegantere Lösungen anzubieten, wie C++, Java, C# etc aber da gibt es wenige (Ausnahme Codesys?), die diesen Schritt gehen möchten.
    Als Freelancer immer auf der Suche nach interessanten Projekten.
    Zitieren Zitieren Ausbildungsproblem  

  5. #4
    Registriert seit
    20.10.2003
    Ort
    Biberach
    Beiträge
    5.068
    Danke
    959
    Erhielt 1.457 Danke für 922 Beiträge

    Standard

    Zitat Zitat von RobiHerb Beitrag anzeigen
    Längst hat die allgemeine Software Wissenschaft Sprachen wie ST (aufgebohrtes PASCAL) auf den Müllhaufen der Geschichte befördert und hätte passendere elegantere Lösungen anzubieten, wie C++, Java, C# etc aber da gibt es wenige (Ausnahme Codesys?), die diesen Schritt gehen möchten.
    Für alle, die – so wie ich – nicht so ganz im Thema sind, eine grafische Übersicht:

    https://plus.google.com/+Improgramme...ts/9PFRF7TLPhM

    PS: AWL = Schraubendreher fehlt.
    Beste Grüße Gerhard Bäurle
    _________________________________________________________________
    Hardware: the parts of a computer that can be kicked. – Jeff Pesis

  6. Folgender Benutzer sagt Danke zu Gerhard Bäurle für den nützlichen Beitrag:

    Zottel (16.02.2015)

  7. #5
    Registriert seit
    09.11.2007
    Ort
    Rhein Main (Darmstadt)
    Beiträge
    663
    Danke
    61
    Erhielt 112 Danke für 80 Beiträge

    Standard

    Zitat Zitat von Gerhard Bäurle Beitrag anzeigen
    ...
    PS: AWL = Schraubendreher fehlt.
    Würde mehr passen: AWL = Hammer und Meissel (Steinzeit)
    Als Freelancer immer auf der Suche nach interessanten Projekten.

  8. #6
    Registriert seit
    27.05.2004
    Ort
    Thüringen/Berlin
    Beiträge
    12.218
    Danke
    533
    Erhielt 2.696 Danke für 1.948 Beiträge

    Standard

    Zitat Zitat von RobiHerb Beitrag anzeigen
    Würde mehr passen: AWL = Hammer und Meissel (Steinzeit)
    Ich halte deine Aussagen zum Thema Programmiersprachen für vollkommen falsch.
    Wir hatten im Forum schon lange Diskussionen darum, das kann man nachlesen und muß es nicht hier wieder neu beginnen.
    Die Fragestellung des TE ist je sehr konkret.

    1. Ich versuche immer die Programmiersprache zu nutzen, die mit am besten für das Problem erscheint.
    Also KOP/FUP, wenn es um Logik, also Verunden und verodern von Bits geht.
    AWL, wenn ich indirekt adressieren will und meine Kenntnisse sowie schon lange vorhandene Bausteinschnipsel nutze und u.U.nicht viel Platz im Speicher der SPS ist.
    ST, wenn ich Zeit und Platz habe und wenn das Problem sehr komplex ist, also mal eben ein Zeiger erzeugen oder Blockmove nicht ausreicht.

    2. ST komt sicher immer mehr, weil immer mehr Daten verarbeitet, gespeichert, verschoben usw. werden müssen.
    Wenn ich eine einfache Maschine habe, die irgendwelche Teile zusammenfügt, also z.Bsp. viel Pneumatik im Spiel ist, ist KOP/FUP ST sicher überlegen, denn komplexe Bitverknüpfungen kann man da em einfachsten sehen und verstehen.

    Mein absoluter Wunsch wäre eine Programmierumgebung, in der ich in einem Baustein KOP und ST kombinieren kann, das wäre für mich eine schöne Sache.

    PS: @RobiHerb

    Einfache Probleme in der Automatisierung sind oft schon recht komplex. Wenn ich da noch mit C# anfange, dann will ich mal sehen, wer meine Programme dann noch blickt. Und aus meiner langjährigen Erfahrung sind Informatiker, die wirklich C++ und C# beherrschen häufig leider nicht in der Lage auch nur einen Nagel in die Wand zu bekommen, geschweige denn die komplexe Mechanik einer Produktionsanlage so zu verstehen, dass ihr Programm dann auch noch dazu paßt. Also lassen wir das lieber. Unter anderem daraus resultiert ja vielleicht auch die immer noch magere Verbreitung von Codesys 3.5 Applikationen. Dann man hlt sch neben den eingehen Probleme immer auch noch die von 2S und Microsoft ins Haus, inkl. aller Updates, Upgrades, Bugs usw. Da bin ich voll und ganz mit TIA beschäftigt.

    PS2: Ich denke, in der Automatisierung sollte man immer so einfach, klar, direkt,verständlich, wie nur möglich programmieren.
    Geändert von Ralle (15.02.2015 um 13:07 Uhr)
    Gruß
    Ralle

    ... there\'re 10 kinds of people ... those who understand binaries and those who don\'t …
    and the third kinds of people … those who love TIA-Portal

  9. Folgende 6 Benutzer sagen Danke zu Ralle für den nützlichen Beitrag:

    benostra (16.02.2015),Blockmove (15.02.2015),drmicha (27.03.2015),Joerg123 (16.02.2015),rostiger Nagel (15.02.2015),zako (15.02.2015)

  10. #7
    Registriert seit
    23.07.2009
    Ort
    Österreich
    Beiträge
    2.336
    Danke
    448
    Erhielt 688 Danke für 513 Beiträge

    Standard

    Oh... Ralle sticht ins Wespennest....
    Ich sag dazu immer: Die Verwendung von besserem Werkzeug kuriert keine zwei linken Hände.
    Zitat Zitat von Ralle Beitrag anzeigen
    Mein absoluter Wunsch wäre eine Programmierumgebung, in der ich in einem Baustein KOP und ST kombinieren kann, das wäre für mich eine schöne Sache
    Nominiert zum Vorschlag des Jahres! Dafür wär ich sofort zu haben.
    Man sollte sich immer aus allem vorhandenen das Beste nehmen.
    Geändert von RONIN (15.02.2015 um 13:38 Uhr)
    If at first you don't succeed, you're not Van Damme!
    ... or maybe using TIA!

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

    Standard

    Wenn solche Aussagen lese wie "AWL ist Steinzeit", dann merke ich, dass jemand schreibt keinerlei Ahnung von Maschinen und Anlagen hat.
    Und wenn jemand noch schreibt C oder C# sei die Lösung, dann hätte ich bitte gern mein Problem wieder.
    Wer kann denn ein garantiert fehlerfreies Programm in C# schreiben?
    Es gab doch die Ansätze so mit Highgraph oder der Ansatz C in Step 5 einzubinden.
    Hatte das Erfolg gehabt? Muss das wirklich sein?

    Ich gehe mit Ralle völlig konform, es gibt verschiedene Programmiersprachen für verschiedene Anwendungen.
    Ich verwende die Sprache, die passt.
    Schrittketten in SCL sind nicht so das Wahre, dafür gibt es FUP / KOP und Graph.
    Unsere Visualisierungen schreiben wir in Delphi, Java, C oder VB.
    Ich habe keine Berührungsängste mit Hochsprachen, doch bei Steuerungen?

    Jeder der Maschinen programmiert, programmiert nicht zum Selbstzweck, sondern für die Kunden und die müssen damit leben.
    Weniger ist oft mehr.

    bike
    "Any fool can write code that a computer can understand.
    Good programmers write code that humans can understand."
    --Martin Fowler

  12. #9
    Parmaster Gast

    Standard

    Zitat Zitat von Ralle Beitrag anzeigen
    Mein absoluter Wunsch wäre eine Programmierumgebung, in der ich in einem Baustein KOP und ST kombinieren kann, das wäre für mich eine schöne Sache.
    Geht doch in Codesys V3.5 SP6 (http://de.codesys.com/aktuelles/produktneuheiten/detail/article/codesys-v35-sp6.html)

    CODESYS Engineering -> ST-Code-Einbindung in FUP- und KOP-Editoren


  13. #10
    Registriert seit
    17.07.2009
    Ort
    Am Rande der Ostalb
    Beiträge
    5.476
    Danke
    1.140
    Erhielt 1.238 Danke für 971 Beiträge

    Standard


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    @bike

    Deine Ausssage, dass wir Maschinen nicht zum Selbstzweck programmieren unterschreibe ich 100%.
    Aber genauso wiederspreche ich zu 100% deiner Aussage bezüglich AWL.

    Bisher habe ich AWL dann genommen, wenn eine Aufgabe nicht für eine grafische Programmiersprache (KOP, FUP oder Graph) geeignet war.
    Also z.B. Datenhandling, Berechnungen oder Kommunikation.
    Bei neuen Anlagen verwende ich hier nun seit einiger Zeit fast ausschliesslich SCL. Die Entwicklungszeit ist deutlich kürzer, der Code besser lesbar und somit besser wartbar.
    Für mich ist AWL nun wirklich Steinzeit.

    Fängt man allerdings an Schrittketten oder simple Verknüpfungen in SCL zu programmieren, dann ist das schlichtweg nicht zielgerichtet.
    Obwohl KOP und FUP schon uralt sind, sind sie für den Einsatzzweck deutlich jeder Hochsprache überlegen. Hier gilt es einfach die Sprache an moderne Erfordernisse anzupassen.
    So wie es Siemens z.B auch bei TIA und S7-1500 gemacht hat.

    Ich sehe es wie Ralle:
    KOP / FUP und ST in einem Baustein und gut ist es ...

    Gruß
    Dieter

Ähnliche Themen

  1. FOR-Schleife Strukturierter Text
    Von joern_85 im Forum CODESYS und IEC61131
    Antworten: 10
    Letzter Beitrag: 23.07.2013, 11:51
  2. Strukturierter Text Grundlagen
    Von hansol1991 im Forum CODESYS und IEC61131
    Antworten: 3
    Letzter Beitrag: 26.02.2013, 11:30
  3. Strukturierter Text ????HÄ?????
    Von Pinky im Forum Programmierstrategien
    Antworten: 3
    Letzter Beitrag: 22.04.2010, 14:26
  4. For Schleif Strukturierter Text
    Von bluebird277 im Forum CODESYS und IEC61131
    Antworten: 7
    Letzter Beitrag: 28.01.2010, 20:45
  5. Strukturierter Text
    Von bluebird277 im Forum CODESYS und IEC61131
    Antworten: 3
    Letzter Beitrag: 21.01.2010, 15:54

Lesezeichen

Berechtigungen

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