# Schwerpunkt Hochsprachenprogrammierung - Strukturierter Text



## Kai Binder (12 Februar 2015)

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/article_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.


----------



## MasterOhh (13 Februar 2015)

Erstaunlich das eine Programmiersprache, die es in der Steuerungstechnik seit über 20 Jahren gibt, teilweise immer noch wie Neuland[SUP]©[/SUP] behandelt wird.


----------



## RobiHerb (13 Februar 2015)

*Ausbildungsproblem*



MasterOhh schrieb:


> Erstaunlich das eine Programmiersprache, die es  in der Steuerungstechnik seit über 20 Jahren gibt, teilweise immer noch  wie Neuland[SUP]©[/SUP] 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.


----------



## Gerhard Bäurle (15 Februar 2015)

RobiHerb schrieb:


> 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/+ImprogrammerNetwork/posts/9PFRF7TLPhM

PS: AWL = Schraubendreher fehlt.


----------



## RobiHerb (15 Februar 2015)

Gerhard Bäurle schrieb:


> ...
> PS: AWL = Schraubendreher fehlt.



Würde mehr passen: AWL = Hammer und Meissel (Steinzeit)


----------



## Ralle (15 Februar 2015)

RobiHerb schrieb:


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


----------



## RONIN (15 Februar 2015)

Oh... Ralle sticht ins Wespennest.... 
Ich sag dazu immer: Die Verwendung von besserem Werkzeug kuriert keine zwei linken Hände.


Ralle schrieb:


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


----------



## bike (15 Februar 2015)

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


----------



## Parmaster (15 Februar 2015)

Ralle schrieb:


> 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


----------



## Blockmove (15 Februar 2015)

@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


----------



## rostiger Nagel (15 Februar 2015)

Stichpunkt TIA, warum haben Sie die Kombi AWL/KOP/FUP/SCL/Graph in einen Baustein
nicht eingebaut, bei der Neuendwicklung einer neuen Programmierumgebung, währe der
richtige Zeitpunkt gewesen. 

Aber bei Siemens scheinen die Informatiker zu sitzen, die den Nagel nicht in die Wand bekommen.


----------



## Blockmove (15 Februar 2015)

Parmaster schrieb:


> 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



Jetzt muss ich doch mal meinen Raspberry aus dem Schrank holen und 3.5 mal antesten


----------



## Blockmove (15 Februar 2015)

rostiger Nagel schrieb:


> Aber bei Siemens scheinen die Informatiker zu sitzen, die den Nagel nicht in die Wand bekommen.



Vielleicht war der Nagel ja bei Siemens *rostig* *SCNR*


----------



## rostiger Nagel (15 Februar 2015)

Blockmove schrieb:


> Vielleicht war der Nagel ja bei Siemens *rostig* *SCNR*



Rostig ist nicht schlimm, ein verosterter Handgeschmiedeter Nagel kann mehr halten als so manche Schraube. 

Wichtig ist ein geübter Handwerker, der den Nagel von oben auf den Kopf trifft. Ein leicht schräger Hammerschlag
und der Nagel ist sofort krumm. Das kann man in der Regel nicht mehr richten. So da sind wir wieder bei TIA, ich
Glaube das ist deren größtes Problem, das Portal ist krumm. Jetzt sitzen da ungeschickte Handwerker und klopfen
mal von Links,  mal von Rechts, aber es wird nicht gerade.


----------



## RONIN (15 Februar 2015)

@RN: den Beitrag unterschreibe ich sofort.



Parmaster schrieb:


> Geht doch in Codesys V3.5 SP6
> CODESYS Engineering -> ST-Code-Einbindung in FUP- und KOP-Editoren


Wow, das ist wirklich ein schlagkräftiges (;-)) Argument für CodeSys.
Gibt's davon auch schon ein paar schöne Bilder wie das aussieht?

Wenn man ST so wie jetzt AWL (zumindest bei Siemens) integrieren könnte, dann würde ich AWL vermutlich nicht lange vermissen.
 Das ist für mich ja nach wie vor der Hauptvorteil. Mann, wäre das toll.


----------



## MasterOhh (15 Februar 2015)

Für mich ist ST so universell, dass ich komplett ohne FUP, KOP oder AWL auskomme. Nur für wirklich komplexe Schrittketten setze ich nebenbei noch AS als Rahmenwerk ein (wobei die Schritte und Transitionen wieder in ST geschrieben sind). 
Ich kannte aus der Schule Pascal und habe Hobby-mäßig µC in C Programmiert. Und dank ST hat es genau eine Woche gedauert, bis ich mich in die SPS-Programmierung eingefuchst hatte.
Ich will nicht jedesmal die Programmiersprache wechseln, wenn ich in einem Baustein Berechnungen, Bitverknüpfungen und einfache Zustandsmaschinen benötige. In ST bekomme ich das problemlos gelöst.

Der Haken ist, dass man bei allem Freiraum den einem ST bietet, keinerlei Zwänge bei der Formatierung unterworfen ist, wie bei den anderen Sprachen. D.h. man muss selber dafür sorgen das der Code lesbar bleibt. Dazu ist etwas Selbstdisziplin nötig. Aber gut formatierter ST Code steht in Punkto Übersichtlichkeit den anderen Sprache in nichts nach und hat sogar oftmals den Vorteil das er viel kompakter daher kommt und somit mehr Code auf einmal dargstellt werden kann.
(FUP-Netzwerke (größere) auf einem 15" - 17" Laptop- Bildschirm finde ich nicht wirklich prickelnd.)

Was mir ein wenig aufgefallen ist, ST scheint bei Programmierern die mit Codesys oder TwinCAT arbeiten wesentlich öfter und auch selbstverständlicher zum Einsatz zu kommen, als bei den Kollegen die vorrangig Steuerungen von großen S einsetzen. Zu mindest bei Step 7 kann ich das gut verstehen, denn der SCL - Editor dort ist ein schlechter Witz, für den man auch noch extra Kohle abdrücken muss....


----------



## Ralle (15 Februar 2015)

@MasterOhh

Aber wie sieht eine Freigabe für einen Servoantrieb bei dir "schön Formatiert" aus, wenn die aus X Oder-Verknüpfungen, mit zusätzlichen diversen Und besteht? Genau da steht bei mit dann KOP/FUP, denn genau dafür ist das da. Ich hab das noch nie wirklich gut lesbar in ST hinbekommen, an der Stelle ist ja selbst AWL noch besser.


----------



## RONIN (15 Februar 2015)

MasterOhh schrieb:


> Ich kannte aus der Schule Pascal und habe Hobby-mäßig µC in C Programmiert.


  Ich komme auch von der selben Schiene (AVR/GCC). Hobbybastler und Platinenätzer... 
Hab deswegen auch keine Schwierigkeiten mit ST, bin aber der selben Meinung wie Ralle.
Mir geht eigentlich auch nur um diese "Einmal hinschauen - ohne genau lesen - was fehlt für die Freigabe" - Dinge



MasterOhh schrieb:


> Ich will nicht jedesmal die Programmiersprache wechseln, wenn ich in einem Baustein Berechnungen, Bitverknüpfungen und einfache Zustandsmaschinen benötige.


Das Schöne ist ja dass man nicht muss. Aber wer will, der könnte. Bei SCL bekommt man die Wahl leider nicht.
Die anderen Darstellungsarten nehmen keinem was weg, aber solange man die Leute (aus teilweise berechtigten Gründen) nicht von SCL überzeugen kann....



MasterOhh schrieb:


> (FUP-Netzwerke (größere) auf einem 15" - 17" Laptop- Bildschirm finde ich nicht wirklich prickelnd.)


Wie gesagt, für alles was in KOP/FUP nicht auf einen Blick erkennbar wird (zu groß oder der Baum zu vermurkst) nehme ich dann eine anderer Darstellungsart.
Was dann weder in FUP noch in AWL schön wird, schreib ich dann auch in SCL *und* umgekehrt.
Leider bleibt aktuell dafür nur AWL, wenn's da SCL gäbe würd ich sicher das nehmen.



MasterOhh schrieb:


> ST scheint bei Programmierern die mit Codesys oder TwinCAT arbeiten wesentlich öfter und auch selbstverständlicher zum Einsatz zu kommen


Im Laufe des Beitrags haben wir ja glaub ich die wichtigsten Gründe ja schon aufgedeckt

Keine Integration zu anderen Darstellungsarten
Bis jetzt kein vernünftiger Editor

Diese zwei Hürden aus dem Weg und man könnte gar nicht so schnell schauen wie SCL sich verbreitet.
Man kann aber viel diskutieren, deswegen wird's nicht besser.


----------



## MasterOhh (15 Februar 2015)

Ralle schrieb:


> @MasterOhh
> 
> Aber wie sieht eine Freigabe für einen Servoantrieb bei dir "schön Formatiert" aus, wenn die aus X Oder-Verknüpfungen, mit zusätzlichen diversen Und besteht? Genau da steht bei mit dann KOP/FUP, denn genau dafür ist das da. Ich hab das noch nie wirklich gut lesbar in ST hinbekommen, an der Stelle ist ja selbst AWL noch besser.



Das hängt dann vieleicht auch vom Programmierstil ab. In meinen Programmen kommt es sehr selten zu Verknüpfungsorgien, aber das ist hier auch nicht das Thema.
Vieleicht können wir uns darauf einigen, dass ST als Programmiersprache am universellsten ist. Wer halt 20+ boolsche Werte auf einmal miteinander Verknüpfen möchte kann das je gerne in FUP tun (auch wenn man dann über 3 Seiten vertikal und horizontal scrollen muss).

Nur deine Aussage "an der Stelle ist ja selbst AWL noch besser" irritiert mich etwas. Eine zeilenweise Verknüpfung von Variablen kann man auch in ST machen. Und ehrlich gesagt wüsste ich auf Anhieb nicht in welchem Punkt
AWL ST überlegen wäre.


----------



## Thomas_v2.1 (15 Februar 2015)

Interessant wäre mal zu erfahren aus welchem Grunde AWL überhaupt entwickelt wurde.
Ich behaupte mal, es wurde entworfen um die grafischen Anweisungen (KOP) auch in textueller Form darstellen zu können. Soweit ich weiß gab es auch niemals einen Prozessor dessen Befehlssatz direkt aus AWL/IL Anweisungen bestand. Außer die speziellen Siemens-Asics in manchen S7 Steuerungen, oder die Speed7 von Vipa/Profichip für MC7.
Das bedeutet, auch mit AWL war man und ist man nie so richtig nah am Prozessor, weil auch AWL erst in den eigentlichen Maschinencode übersetzt werden muss.

Für mich vereint AWL darum die Nachteile aus beiden Welten (kompilierte Sprachen / Assembler):
- Keine Datentypsicherheit
- Schlechte Möglichkeiten zur statischen Codeanalyse
- Schlecht les- und wartbar
- Kein Einblick in den wirklichen Code der ausgeführt wird

Und ob man mit AWL im Gegensatz zu ST Speicher sparen kann habe ich bei TwinCAT mal überprüft (bei Siemens ergibt das mit SCL nicht viel Sinn, weil aus SCL erst AWL erzeugt wird).
Ich habe vor einiger Zeit aus Neugierde den Assemblercode verglichen, der aus einer in ST und in AWL geschriebenen Funktion welche die Fakultät berechnet, erzeugt wird. Wenn man die Debug-Infos abzieht ist der Code von der Anzahl der Anweisungen her fast identisch (AWL -1). Mit den zusätzlichen Debug-Infos erzeugt die AWL-Funktion aber ca. 1/3 mehr Anweisungen.

Wie das bei Bitgewackel aussieht habe ich noch nicht geprüft. Dafür ist meiner Meinung nach eine grafische Sprache wie FUP/KOP die beste Lösung.


----------



## zako (15 Februar 2015)

Ob man unbedingt in C/C++ automatisieren muss, sei mal dahin gestellt. Aber die Möglichkeit C/C++ - Code zu integrieren, ist schon schon von Vorteil. Ich sehe das z.B. in der Prüfstandstechnik, wo Reglerentwürfe/-Simulationen gerne mit MATLAB SIMULINK gemacht werden. Hieraus kann man dann entsprechenden Code generieren, welchen man dann auf einen Automatisierungssystem ausführen kann.


----------



## Ralle (15 Februar 2015)

@Thomas

Na ja, alles hat ja im Prinzip mit Assembler angefangen, das war die direkte Maschinensprache. Ich hab dann schon an Systemen programmiert, da lief Macroassembler, da waren einige Dinge vereinfacht und zusammengefasst. Das ist zwar noch immer kein AWL aber gut vorstellbar, dass das aus dieser Richtung kam, spezialisiert auf Anforderungen der Steuerungstechnik (VKE usw.). Aber wer Henne oder Ei war, kann ich dir nicht sagen, ich persönlich denke, KOP wurde aus AWL entwickelt um eine bessere graphische Darstellung zu bekommen und das auch noch so ähnlich, wie ein Schaltplan für Schützschaltungen ausgesehen hat. Damit konnten auch Elektriker etwas anfangen, ein riesiger Fortschritt damals.


----------



## Ralle (15 Februar 2015)

zako schrieb:


> Ob man unbedingt in C/C++ automatisieren muss, sei mal dahin gestellt. Aber die Möglichkeit C/C++ - Code zu integrieren, ist schon schon von Vorteil. Ich sehe das z.B. in der Prüfstandstechnik, wo Reglerentwürfe/-Simulationen gerne mit MATLAB SIMULINK gemacht werden. Hieraus kann man dann entsprechenden Code generieren, welchen man dann auf einen Automatisierungssystem ausführen kann.



Das macht ja auch Sinn und ist in diesen speziellen Fällen von Vorteil.


----------



## bike (16 Februar 2015)

Blockmove schrieb:


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



Ich habe mit keiner Silbe geschrieben, dass AWL state of the art ist.
Aber ich finde es einfach bescheiden, pauschal zu schreiben AWL ist Sche..e.
Es gibt Funktionen die ich einfacher in AWL schreibe, habe es bzw mache es  vermutlich schon zu lange. 
Wenn AWL schreiben ist wie textschreiben, dann nimmt man es UND das Wichtigste ist: du kannst in einem einfachen Editor auf jedem OS schreiben.

Aber wir programmieren z.B. unser WZV und PV inzwischen in SCL und lagern ggF vieles auf externe System aus.

Aber zu schreiben, das oder jenes ist das allein Heilsbringende ist einfach falsch.

Auch hat Zako recht, wenn man fordert komplexe Funktionen in einer Hochsprache zu erstellen.
Doch diese Funktionen müssen in sich sauber geschlossen sein, so dass keiner reinschauen muss, wenn es knallt.

Ist Trabbi oder Porsche die richtige Lösung im Strassenverkehr?


bike


----------



## Blockmove (16 Februar 2015)

bike schrieb:


> Ist Trabbi oder Porsche die richtige Lösung im Strassenverkehr?



Hmmm ... 
Aus persönlicher Sicht gibt es wohl wenig, was ein Trabi besser kann als ein Porsche.
Und so ist es - meiner Ansicht nach - eben auch mit AWL und SCL.

Aber solange man sauber programmiert und dokumentiert, kann jeder nehmen was er will.
Schwäbisch würde man sagen:
"S gibt sotte un sotte un au no sottige" (Es gibt solche und solche und auch noch ganz andere)

Gruß
Dieter


----------



## bike (16 Februar 2015)

Magst du Lenkradschaltung und Zweitaktgeruch?

Aber du hast recht: Jedem Tierchen sein Pläsierchen.


bike


----------



## Thomas_v2.1 (16 Februar 2015)

Als Autovergleich finde ich passender wenn man annimmt das Ergebnis soll mal ein Auto werden. Strukturierter Text entspricht in etwa einem Kitcar z.B. für einen Caterham. Die Wahrscheinlichkeit, dass etwas zumindest autoähnliches dabei herauskommt ist sehr groß. Bei AWL bekomme ich eine Drehbank, Schweißgerät, Wellen und Bleche. Wenns gut läuft kommt eine Cobra bei heraus, wenns schlecht läuft ein Haufen Eisenschrott.


----------



## Blockmove (16 Februar 2015)

Thomas_v2.1 schrieb:


> Als Autovergleich finde ich passender wenn man annimmt das Ergebnis soll mal ein Auto werden. Strukturierter Text entspricht in etwa einem Kitcar z.B. für einen Caterham. Die Wahrscheinlichkeit, dass etwas zumindest autoähnliches dabei herauskommt ist sehr groß. Bei AWL bekomme ich eine Drehbank, Schweißgerät, Wellen und Bleche. Wenns gut läuft kommt eine Cobra bei heraus, wenns schlecht läuft ein Haufen Eisenschrott.



Naja da widerspreche ich jetzt auch mal ...
Also ST-Eisenschrott hab ich auch schon genug gesehen.
Das Problem an ST ist, dass jeder der mal 5 Zeilen in einer Hochsprache geschrieben hat, auf einmal der irrigen Meinung ist, dass er SPS programmieren kann.
Da werden dann IF-THEN-ELSE-ENDIF-Konstukte verbrochen, dass es schlimmer nicht mehr geht.
Das man sowas mit ner simplen boolschen Verknüpfung lösen kann, ist diesen "Experten" fremd..
 Setzt man diese Experten vor AWL, dann verlaufen sie sich wenigsten sehr schnell selber zwischen den ganzen Sprungmarken und kapitulieren (hoffentlich).

Vielleicht sollte man ST / SCL nur nach einem Test freischalten.
Ähnlich wie du bei Audi / BMW die Freischaltung von >250km/h nur nach einem Fahrertraining bekommst.

Gruß
Dieter


----------



## RONIN (16 Februar 2015)

Thomas_v2.1 schrieb:


> Strukturierter Text entspricht in etwa einem Kitcar z.B. für einen Caterham.
> Bei AWL bekomme ich eine Drehbank, Schweißgerät, Wellen und Bleche.
> Wenns gut läuft kommt eine Cobra bei heraus, wenns schlecht läuft ein Haufen Eisenschrott.


Leider gibt es den  Reliant-Robin sowohl in SCL als auch in AWL. 
 Eine unerwartete Kurve und schon liegt man auf dem Dach.... 

Ich hätt ja lieber eine Morgan 3-wheeler. Hat auch 3 Räder, kippt aber nicht jedes mal um und ist viel cooler....


----------



## Thomas_v2.1 (16 Februar 2015)

Blockmove schrieb:


> Naja da widerspreche ich jetzt auch mal ...
> Also ST-Eisenschrott hab ich auch schon genug gesehen.
> Das Problem an ST ist, dass jeder der mal 5 Zeilen in einer Hochsprache geschrieben hat, auf einmal der irrigen Meinung ist, dass er SPS programmieren kann.
> Da werden dann IF-THEN-ELSE-ENDIF-Konstukte verbrochen, dass es schlimmer nicht mehr geht.
> Das man sowas mit ner simplen boolschen Verknüpfung lösen kann, ist diesen "Experten" fremd..


Diese If-Then-Else Konstrukte sind aber meistens nur unnötig umständlich, aber nicht immer grundsätzlich falsch. D.h. Funktion ist gegeben: die Räder sind zumindest an den vier Ecken.
Um beispielsweise das Bitmuster einer Ganzzahl auf den Speicher einer Real-Zahl zu schreiben, muss man in ST schon einiges anstellen. Da der Aufwand so hoch ist, weiß ich aber meistens auch dass ich das so will. In AWL kann sowas alleine aus Flüchtigkeit entstehen: anstatt den Rädern sitzen vier Akkumulatoren an den Ecken.


----------



## MasterOhh (17 Februar 2015)

Weil man schlechten Code ja auch nur in ST / SCL schreiben kann....
In AWL / FUP kann es keine aufgeblähten ungekürzten Bitverknüpfungen geben weil .... ? 

Vieleicht sollten wir hier nicht mit "Ich habe mal ein ganz übles Programm gesehen das wurde in Sprache X geschrieben, ergo ist Sprache X total mies" anfangen. 
Denn X ist ein Element ALLER Programmiersprachen. 
Ich glaube jeder hier kann einige Beispiele misslungender Code-Schnipsel liefern (FUP, KOP, AWL SCL, Graph) und die meisten brauchen dazu auch nur im Fundus ihrer eigenen Frühwerke nachschauen.


----------



## RONIN (17 Februar 2015)

@MasterOhh: Diesen Tenor konnte ich aus den vorigen Beiträgen aber nicht rauslesen....

Ich dachte eigentlch wir hätten uns auf:
"Egal welche Darstellungsart, entweder wird damit ein E-Type oder eben ein Robin zusammengeschraubt"
 geeinigt... 

Der Vergleich von Thomas vorhin, hatte es auch ganz gut getroffen.


----------



## manseluk (17 Februar 2015)

Bei uns wurde AWL an der Hochschule nicht einmal mehr behandelt (Automatisierung war eh nur ein kleines Nebenfach). Allerdings dank Assembler ist AWL doch nicht ganz so fremd.
Der Fokus lag klar auf ST von Beckhoff (einigermasen brauchbare Umsetzung von Pointer) und C (B&R Steuerung lassen sich schon seit x Jahren auf C Programmieren).
AWL wurde eher als Sprache der Cracks behandelt, welche seit 20+ Jahren im Geschäft sind. Mit dem Vorteil, dass es zwar sehr hardwarenah und optimiert genutzt werden kann, aber auch das eine effiziente Nutzung viel spezifisches Fachwissen verlangt. Wo hingegen in der Welt der Hochsprachen der Wechsel von einer zur anderen Sprache leichter ausfällt.


----------



## bike (17 Februar 2015)

Der Vergleich von Thomas wegen Auto und so stimmt nur bedingt.
Wenn bei AWL die AKKUs an den Ecken sind, ist die Ursache meist leicht zu finden.

Es  ist doch gut, dass es verschiedene Sprachen gibt. 
Und wenn jemand  schreibt diese oder jene ist die richtige, dann trifft das eben nicht  zu.
Auch im Bereich der Hochsprachen gibt es verschiedene.
Wenn ich mich erinnere, dass z.B. einmal Fortran für Finanz- und ADA für Militäranwendungen entwicklet wurden.
Was ist daraus geworden?
Eines wurde nicht:
Es wurde nicht alles auf eine Sprache eingedampft.

Vielleicht sollten sich einmal Entwickler, Programmierer und User zusammensetzen und darüber reden, was wer braucht.
Dann kommt vielleicht eine neue gute Idee  heraus.
Kann es denn nicht sein, dass dann eine Software herauskommt, die zumindest den selben Befehlssatz für verschiedenste PLC hat?

Wenn jemand schreibt der Umstieg von C zu Java sei einfacher als zwischen AWL und SCL, dann kann ich nur leicht lächeln.
Und nicht alles was an den Universitäten geleert wird, ist sinnvoll. 

Jetzt sind wir wieder im Glaubensdilema.
Was ist besser und was schlechter?


bike


----------



## manseluk (17 Februar 2015)

Schlussendlich gibts halt nicht nur schwarz und weiss sondern so 200 shades of grey.

Eine guter Programmierer macht einen guten Code, unabhänig von der Sprache. Ist ja so ähnlich wie mit den gesprochenen Sprache, ein paar Flüche in irgendeiner Sprache sind schnell erlernt, philosophieren können nicht einmal alle muttersprachigen.


----------

