Wie seht ihr die C und C++ Programmierung gegenüber der IEC?

Ich bin überzeugter IEC61131 Fan. Gerade die Mischung der IEC Sprachen stellt für mich einen riesigen Vorteil dar. Grafische Schrittketten (AS) und grafische Bitverknüpfungen (KOP/FUP/CFC) so wie Text basierendes Datenhändling und Rechenaufgaben (ST/AWL). Nach dem der Schritt nun auch noch hin zur Objektorientierung hingeht sehe ich da auch viel Potential.

Klar bietet C/C++ ein breites Spektrum an Möglichkeiten und auch viele Programmierer beherrschen diese Sprache bereits. Für mich stellt sich jedoch die Frage wenn jemand so gut in C/C++ ist das man ihn auf eine Produktionsanlage los lässt dann sollte man von ihm auch erwarten können das er mit der IEC61131 klar kommt. Branchen spezifische Programmiersprachen gab es schon immer und einige Firmen erfinden sogar ihre eigenen Sprachen (z.B. SAP mit ABAB). Gerade die grafischen Darstellungen von Programminhalten haben IMHO Vorteile z.B. bei Schrittketten. Auch Datenflussmodelle wie bei Labview haben ihre Vorzüge.

Wenn man Maschinen und Anlagen nur in C/C++ Programmieren will halte ich das für einen Rückschritt das mag eine Revolution sein aber in die falsche Richtung wenn man gewisse Bestandteile besser in C/C++ lösen kann und die optional einsetzt mag es eine Bereicherung sein.

Egal wie ich die Sache heute sehe, wenn mein Chef eines Tages kommt und mir sagt das ab heute C/C++ das Maß aller Dinge ist werde ich die Maschinen eben in C/C++ programmieren.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
IEC für einmalige Anlagen oder für einfache Anlagen die nicht gross ändern.

C und C++ für komplexe Anlagen und sehr stark ändernde Anlagen.

Für mich kann kein grafische Programmierung je an eine Text basierende Lösung ran kommen. Mit der Text basierten Lösung kann man mehr machen. Dafür ist die Grafische verständlicher für die meisten Menschen.

Gruss
Thomas
 
Anscheinend wird Twincat 3 mit der Sprache C, Code für die Runtime-Engine generieren können. Das Marketing-Argument dafür ist, dass es mehr C-Programmierer gibt, als Automatisierungsings. Das ist soweit wahr. Realistisch gesehen, wird wohl die Hürde kleiner sein, sich mal mit TwinCat zu beschäftigen, aber die eigentlichen Hürden wie die quasi-parallele Ausführung von Programmteilen sind damit natürlich nicht genommen. Das macht aber auch nichts. Die Anforderungen an den Automatisierer werden nicht kleiner.

Beckhoff versucht offenbar aus der Spezialistenecke herauszukommen, indem TW allen mit Visual Studio zugänglich gemacht wird und sprach im Interview speziell China an. Die Hürden für den Einsatz des Produktes werden kleiner. Dort ist der Markt riesengross und je einfach man es man dem Kunden mit dem ersten Schritt macht, desto besser wird Beckhoff später seine Anteile am Markt holen können.
 
Danke für eure ersten Antworten.

ich find es absolut reizvoll, dass man IEC und C parallel fahren kann.
Somit können die Bestandsanlagen und "normalen" Anlagen weiter in der IEC programmiert werden und zu gleich können alle unlösbaren Programmteile z.B. dynamische FBs bzw. Objekte in C umgesetzt werden.

Den Schritt zu Visual Studio ist sicherlich auch genial. Somit können die Scadas und HMIs mit einem Editor bearbeitet werden. Und welcher heutige fertigwerdende Ing. oder Techniker hatte noch keinen Kontakt zum VStudio?

Ich könnte mir auch vorstellen, dass ähnlich wie im SystemManager die verschiedenen Hardwarekommunikation einfach gelöst sind, die Kommunikation zwischen den verschieden Softwaresprachen gehandelt werden könnte. (Webservice, OCX, etc.)

Gruß, Frohe Weihnachten
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Eigentlich ist es der falsche Ansatz!
Warum C und C++ Programmierung gegenüber der IEC?

IEC beinhaltet mehrere Sprachen. C++ könnte einfach eine weitere sein.
Ich vertrete ganz einfach die Auffassung, dass die Aufgabe und die Sprache zusammen passen müssen.
Eine Schrittkette kann ich in jeder Sprache programmieren, aber grafisch ist es nun mal einfachsten und am übersichtlichsten.
Eine Lagerwaltung kann ich auch in FUP programmieren, aber hier wäre C++ einfach geeigneter.

Just my 2Cents

Gruß
Dieter
 
Zum Thema, es gibt ja so viele C-Programmierer:

Man muss sich trotzdem vor Augen halten, dass C nicht zur Programmierung von SPS'en entwickelt wurde. Mit C++ ist es noch einfacher möglich, schwerwiegende Fehler zu programmieren.

Da die meisten C-Programmiere auf normalen PC's an irgendwelche nonsense Konsolen-Anwendungen das programmieren gelernt haben, wissen sie nicht wie man ein zyklisches Programm schreibt. Auf einer SPS wird das Programm alle x ms neu gestartet. Das ist einem normalem Ing nicht bewusst! Zumindest weiß er nicht, solch ein Programm zu entwickeln.

Ein normaler Kommunikationsaufruf, Zugriff auf die Festplatte oder ähnliches kann zu schweren Fehlern führen und die x ms deutlich überschreiten. Das wäre ein arges Problem, wenn das Programm auf einer Anlage läuft.
 
Neals schrieb:
Da die meisten C-Programmiere auf normalen PC's an irgendwelche nonsense Konsolen-Anwendungen das programmieren gelernt haben, wissen sie nicht wie man ein zyklisches Programm schreibt.
Zum Vergrößern anklicken....

Sicher nicht. Das Problem kann man aber auch mit ST produzieren (mir schon passiert), auch wenn man Experte ist. Dummerweise reagierte Twincat bisher mit einem Bustimeout auf Ethercat oder z.B. Profibus. Da fängt dann der Ärger für den Anfänger so richtig an.

Ob man C oder ST oder sonstwas auch immer nimmt, der Fortbildungsbedarf ist immer da. Die Programmiersprache sollte immer von der Anwendung abhängen. Ich sehe keinen wesentlichen Unterschied zwischen dem Pascal-Abkömling ST und C. Es wird viel interessanter, wie das umgesetzt wird.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Naja, sagen wir mal, man lernt nie aus

Neals schrieb:
Zum Thema, es gibt ja so viele C-Programmierer:

Man muss sich trotzdem vor Augen halten, dass C nicht zur Programmierung von SPS'en entwickelt wurde. Mit C++ ist es noch einfacher möglich, schwerwiegende Fehler zu programmieren.
Zum Vergrößern anklicken....

C ist schon lange tot, ich wage aber die Behauptung, dass die meisten heute eingesetzten SPS per C++ überhaupt erst entwickelt worden sind.

Neals schrieb:
Da die meisten C-Programmiere auf normalen PC's an irgendwelche nonsense Konsolen-Anwendungen das programmieren gelernt haben, wissen sie nicht wie man ein zyklisches Programm schreibt. Auf einer SPS wird das Programm alle x ms neu gestartet. Das ist einem normalem Ing nicht bewusst! Zumindest weiß er nicht, solch ein Programm zu entwickeln.
Zum Vergrößern anklicken....

Ich denke mal auch einem SPS Programmierer fehlt gelegentlich der Überblick, wie komplexe professionelle Programme geschrieben werden. Dagegen sind die zyklisch periodischen Tasks der SPS noch Spielen im Sandkasten. In einem grösseren technischen Programm laufen eine Menge von Threads und Prozessen, die synchronisieren sich gegenseitig, die können auf Ereignisse warten an bestimmten Punkten, die können wieder neue Tasks und Threads starten, die können einzelne Aufgaben auf bestimmte Prozessor Kerne auslagern etc...
 
Wenn man bedenkt, dass Beckhoff gerade stärker in den Bereich "Scientific Automation" und Messtechnik hinein möchte, wofür sie schon E/A-Komponenten ("XfC") und Software haben (z. B. "Condition Monitoring"), dann ist die Einbindung von weiteren Sprogrammiersprachen wie C/C++ ja nur der logische Schritt.
Für uns Steuerungs-Programmierer klingt es vielleicht komisch, dass wir nun auch C/C++ für die SPS nutzen können/sollen, aber denkt mal an die Kollegen aus der Messtechnik oder an Entwickler aus dem Forschungs-Bereich.
Die haben eher wenige Kenntnisse in Sachen IEC61131. Und wenn die nun plötzlich "herkömmliche" SPSen, statt sündhaft teuren und aufwendig zusammengestelltes Labor-Steuerungen nutzen können, kann das für die plötzlich ein richtiger Segen sein, wenn die direkt Teile von z.B. Messprogrammen 1:1 weiter nutzen können. Es wurde auf der Messe ja auch von Einbindung von Matlab/Simulnk gesprochen. Mit Simulink kann man z.B. komplizierteste Regelkreise grafisch erstellen und bekommt später C-Code raus. Diesen könnte man direkt ins TwinCAT 3 packen und braucht dann keine teuer Realtime-Hardware mehr.
Ich weiß noch aus meinem Studium, wo man krampfhaft versuchte, einen im Labor´entwickelten Regelkreis mit Spezial-PC-Hardware als "Echtzeit"-Programm ablaufen zu lassen... und dann brauchte man noch I/O-Karten usw. ... für sowas gibt's spezialisierte Hersteller, die sich das auch fürstlich bezahlen lassen.
... und bald könnten dann "Rapid Prototyping" und "Hardware in The Loop" -Simulationen (HIL-Simulation) in "Standard-SPSen" laufen.... :rolleyes:

.. wir reden dann nicht mehr von unseren bekannten Anwendungsfällen wie der Anlagen- und Maschinenprogrammierung.
Ich denke schon dass hier ein risieger Markt exisitert, den wir aber gar nicht kennen.
 
trinitaucher schrieb:
.. wir reden dann nicht mehr von unseren bekannten Anwendungsfällen wie der Anlagen- und Maschinenprogrammierung.
Ich denke schon dass hier ein risieger Markt exisitert, den wir aber gar nicht kennen.
Zum Vergrößern anklicken....

Bei uns werden z.B. die Steuerungsschränke mit Octave (Opensource Matlab-Ersatz) kalibriert. Wir haben massenhaft Messgeräte, die mit Gpib angesteuert werden, für das es bis Heute bei Beckhoff nichts gibt. Es gibt im Bereich der Messgeräte standadisierte Ethernetprotokoll, so dass auch diese genutzt werden könnten.

Bis Heute werden an vielen Unis für Realtime FPGAs oder DSPs eingesetzt. Die Zeit vom Entwurf bis zum Betrieb ist dementsprechend gross. Da könnte ein C-Interface zu externen Geräten gewaltig helfen.

Doch Beckhoff meint etwas anderes mit C. Die wollen ihren Bytecode nicht nur mit ST oder FUP erzeugen können, sondern mit C oder C++. Das ist etwas grundlegend anderes. Oder habe ich das falsch verstanden?
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ich glaube auch das man C++ für die "herkömmlichen" Automatisierungsaufgaben nicht unbedingt braucht. Immerhin bekommt man im Studium beigepaukt wie man komplexe Systeme auf so kleine Teilschritte runterbrechen kann, das man da locker mit ST, AS, AWL, FUP auskommt um sie zu realisieren.

Die Erweiterung macht aber Sinn, wenn Beckhoff wirklich das Einsatzportfolio ihrer Steuerungen auf Bereiche außerhalb der traditionellen SPS Domänen ausbreiten will.

Ich glaube hier in Deutschland werden wenige Automatisierer auf diese neuen Möglichkeiten zurückgreifen.
Hier regiert leider immernoch Siemens (wie ich auch in meinem Studium scherzhaft feststellen muss), und da bewegt sich erfahrunggemäß so schnell nichts.
 
drfunfrock schrieb:
Bis Heute werden an vielen Unis für Realtime FPGAs oder DSPs eingesetzt. Die Zeit vom Entwurf bis zum Betrieb ist dementsprechend gross. Da könnte ein C-Interface zu externen Geräten gewaltig helfen.

Doch Beckhoff meint etwas anderes mit C. Die wollen ihren Bytecode nicht nur mit ST oder FUP erzeugen können, sondern mit C oder C++. Das ist etwas grundlegend anderes. Oder habe ich das falsch verstanden?
Zum Vergrößern anklicken....

Beckhoff hat eine neue modulare Runtime. Diese stellt eine Umgebung zur Verfügung, in welcher TwinCAT Module ablaufen können. Diese Module können "SPSen", C/C++-Module, Motion Control-Module, in Matlab/Simulink oder C/C++ generierte Regler usw. sein. Die Funktionalität der Module ist somit frei skalierbar. Diese Module können über diese Schnittstellen zyklisch aufgerufen werden, sich gegenseitig aufrufen (z.B. als Funktionsbausteine), Daten austauschen usw. Ebenso kann man damit auch eine Anbindung an externe Geräte programmieren, welche dann echtzeitfähig mit anderen Modulen Daten austauschen können.
 
MasterOhh schrieb:
Ich glaube auch das man C++ für die "herkömmlichen" Automatisierungsaufgaben nicht unbedingt braucht. Immerhin bekommt man im Studium beigepaukt wie man komplexe Systeme auf so kleine Teilschritte runterbrechen kann, das man da locker mit ST, AS, AWL, FUP auskommt um sie zu realisieren.

Die Erweiterung macht aber Sinn, wenn Beckhoff wirklich das Einsatzportfolio ihrer Steuerungen auf Bereiche außerhalb der traditionellen SPS Domänen ausbreiten will.

Ich glaube hier in Deutschland werden wenige Automatisierer auf diese neuen Möglichkeiten zurückgreifen.
Hier regiert leider immernoch Siemens (wie ich auch in meinem Studium scherzhaft feststellen muss), und da bewegt sich erfahrunggemäß so schnell nichts.
Zum Vergrößern anklicken....

C braucht sicherlich niemand in der AT. Mit C++ oder besser gesagt Objekt-Orientierung sieht es schon anders aus. Wenn du siehst welche Aufgaben heute mit einer SPS erledigt werden (müssen), da wäre es manchmal schon hilfreich, wenn du mit Objekten arbeiten könntest.
Wenn du Siemens genügend Geld gibst, dann kannst du auch schon heute S7 in C programmieren. Es gibt eine Art SDK mit dem du dann quasi deine eigenen Betriebssystem-Erweiterungen und -Funktionen für S7 schreiben kannst.

Gruß
Dieter
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Blockmove schrieb:
Wenn du Siemens genügend Geld gibst, dann kannst du auch schon heute S7 in C programmieren. Es gibt eine Art SDK mit dem du dann quasi deine eigenen Betriebssystem-Erweiterungen und -Funktionen für S7 schreiben kannst.
Zum Vergrößern anklicken....

Hast Du dazu weitere Infos oder einen Link?
 
Zurück
Oben