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

Seite 1 von 5 123 ... LetzteLetzte
Ergebnis 1 bis 10 von 48

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

  1. #1
    Registriert seit
    20.02.2009
    Beiträge
    21
    Danke
    0
    Erhielt 2 Danke für 1 Beitrag

    Idee


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    Hallo zusammen

    Vielleicht könnt ihr mal eure Erfahrungen aus der AT mit C oder Visonen zum neuen TwinCAT 3 posten.

    Scheinbar läutet Beckhoff wieder eine "kleine" Revolution in der AT ein.

    Siehe Video mit Herrn Beckhoff

    http://www.computer-automation.de/na...2-001ec9efd5b0

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

  2. #2
    Registriert seit
    07.03.2004
    Beiträge
    4.369
    Danke
    946
    Erhielt 1.158 Danke für 831 Beiträge

    Standard

    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.
    If you open your Mind too much, your Brain will fall out.

  3. #3
    Registriert seit
    11.06.2007
    Beiträge
    162
    Danke
    3
    Erhielt 16 Danke für 16 Beiträge

    Standard

    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

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

    Standard

    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.

  5. #5
    DJchris81 ist offline Neuer Benutzer
    Themenstarter
    Registriert seit
    20.02.2009
    Beiträge
    21
    Danke
    0
    Erhielt 2 Danke für 1 Beitrag

    Standard

    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

  6. #6
    Registriert seit
    17.07.2009
    Ort
    Am Rande der Ostalb
    Beiträge
    5.485
    Danke
    1.141
    Erhielt 1.243 Danke für 974 Beiträge

    Standard

    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

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

    Kurt (10.01.2010)

  8. #7
    Registriert seit
    24.04.2008
    Ort
    Lübeck
    Beiträge
    324
    Danke
    8
    Erhielt 63 Danke für 62 Beiträge

    Standard

    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.

  9. Folgender Benutzer sagt Danke zu Neals für den nützlichen Beitrag:

    Blockmove (24.12.2009)

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

    Standard

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

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

    Lächeln

    Zitat Zitat von Neals Beitrag anzeigen
    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.
    C ist schon lange tot, ich wage aber die Behauptung, dass die meisten heute eingesetzten SPS per C++ überhaupt erst entwickelt worden sind.

    Zitat Zitat von Neals Beitrag anzeigen
    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.
    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...
    Als Freelancer immer auf der Suche nach interessanten Projekten.
    Zitieren Zitieren Naja, sagen wir mal, man lernt nie aus  

  12. #10
    Registriert seit
    19.11.2006
    Beiträge
    1.346
    Danke
    6
    Erhielt 254 Danke für 231 Beiträge

    Standard


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

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

Ähnliche Themen

  1. Erdungswiderstand Hauspotential gegenüber Erdreich
    Von bernd81 im Forum Maschinensicherheit - Normen und Richtlinien
    Antworten: 8
    Letzter Beitrag: 07.10.2016, 14:51
  2. Wie seht ihr die nahe Zukunft von S7-300 / 400
    Von maxi im Forum Stammtisch
    Antworten: 16
    Letzter Beitrag: 30.10.2009, 20:15
  3. Vorteile TCP gegenüber SINEC H1 ISO
    Von lehmann im Forum Simatic
    Antworten: 3
    Letzter Beitrag: 04.06.2007, 14:36
  4. Antworten: 13
    Letzter Beitrag: 12.12.2006, 13:57
  5. Programmierung in S7- SCL
    Von old_willi im Forum Stammtisch
    Antworten: 5
    Letzter Beitrag: 19.06.2005, 15:29

Stichworte

Lesezeichen

Berechtigungen

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