Programmiersprachen

gloeru

Level-1
Beiträge
339
Reaktionspunkte
35
Zuviel Werbung?
-> Hier kostenlos registrieren
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! :)
 
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. :ROFLMAO:

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

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


Irgendwie werde / bin ich nicht schlau. :confused:

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

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

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

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

Frank


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
 
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.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
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.
 
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:
...
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.
 
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
 
Zurück
Oben