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

Seite 3 von 3 ErsteErste 123
Ergebnis 21 bis 30 von 30

Thema: Programmierung auf dem PC

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

    Standard


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    Zitat Zitat von Zottel Beitrag anzeigen
    ...
    Mit einem Debugger arbeitest du gewöhnlich mit Einzelschritten oder Breakpoints.
    ...
    So kenne ich das von CoDeSys. Ich benutze Breakpoints und Einzelschitte jedoch nur in der Simulation. Mit laufender Maschine würde das sicher mit einem schaden enden.

    Zitat Zitat von Zottel Beitrag anzeigen
    ...
    Nun zur Programmierung eines PC als Soft-SPS: C++ scheint mir nicht die richtige Sprache. Die typischen C++ Anwendungen generieren Objekte zur Laufzeit. Auch wenn man Teile des Prozesses/Feldes durch Objekte abbilden möchte, kann ich keine Notwendigkeit erkennen, solche Objekte zur Laufzeit zu generieren oder zu entfernen. Damit ist die Speicherverwaltung und der Konstruktor/Destruktor-Mechanismus überflüssig. Mehrfachvererbung verwendet kaum ein C++-Programmierer. Vererbung an sich läßt sich auch in C, ohne ++, mit Structs und Funktionszeigern realisieren.
    ...
    Ich selbst bin in C++ eine Niete und kann da auch nicht wirklich was zu sagen. In C beherrsche ich einige Schweinereien die den Code schlanker aber nicht gerade verständlicher machen.

    Zitat Zitat von Zottel Beitrag anzeigen
    ...
    C (auch ohne ++) macht auf mich immer einen leicht kryptischen Eindruck, da man mit kurzen Folgen von Sonderzeichen allerlei nette Effekte bewirken kann.
    Ich halte Pascal für leichter lesbar (wichtig, da Steuerungen eigentlich immer von anderen Personen als dem Programmierer gewartet werden müssen) und so finde ich es folgerichtig, daß SCL ziemlich "Pascal-artig" ist.
    ...
    100% ACK

    Zitat Zitat von Zottel Beitrag anzeigen
    ...
    Für binäre Verknüpfungen ist keine der üblichen Hochsprachen so richtig gut geeignet.
    ...
    Auch hier 100% ACK.
    Ich persönlich halte FUP bei Bitverknüpfungen für unschlagbar.
    Immer die richtige (passende) Sprache (Tool) für die Aufgabe zu wählen ist schon mal die halbe Miete.

    Zitat Zitat von Zottel Beitrag anzeigen
    ...
    Meine Vorstellung wäre, Compiler zur Verfügung zu stellen für:
    KOP, FUP -> AWL
    AWL->Maschinencode
    SCL->Maschinencode
    SCL-> AWL
    Und als Hochsprache eine Art abgespecktes JAVA (ohne new), nachfolgend AVA genannt:
    AVA->Maschinencode
    AVA-> AWL
    Der Sinn, den über den Zwischenschritt AWL gehen zu können oder nicht, liegt darin, daß mit AWL-Zwischenschritt der Code auch für nicht Hochsprachenkundige (notfalls) nachvollziehbar bleibt, während ohne AWL-Zwischenschritt optimaler (schneller, kurzer) Maschinencode erzeugt wird.
    Ich kenne das ja nur vom hören sagen hier aus dem Forum. Bin mir also bei folgenden Aussagen nicht sicher:

    Step7 macht aus SCL erstmal AWL und das würde dann übel und schwer zu lesen sein.

    Es gab ja mal ein CoDeSys abkömmling von Deltalogic der für S5 und S7 aus den Sprachen AWL/KOP/FUP/ST/AS/CFC Code (AWL?) erzeugt hat und das muss nur sehr schwer lesbar gewesen sein.

    _____

    Ich kenne das auch von µC wenn man sich da einen Code der in C verfasst wurde in ASM anschaut ist das nicht wirklich lesbar.

    Einen Compiler zu bauen ist sehr schwer und super viel Arbeit.

    Ich denke das sich ST/SCL für die entsprechenden Aufgaben etablieren wird.

    Als die SPSen auf den Markt kamen hat auch kein Instanthalter gewust was das ist und was da auf sie zu kommt. Das war zwar weit vor meiner Zeit aber heute ist eine SPS absolut Standart und so wird es mit den "neuen" Sprachen auch sein.

    Die Anforderungen steigen und wenn wir da mit halten wollen dürfen wir nicht als Bermse wirken.
    If you open your Mind too much, your Brain will fall out.

  2. #22
    Registriert seit
    30.08.2005
    Beiträge
    280
    Danke
    41
    Erhielt 96 Danke für 66 Beiträge

    Standard

    Hallo Zottel,

    ich denke wie du, dass die Sprache keine Rolle spielt. Das Problem sind die Programmierumgebungen. Und die sind bei C/C++ eben nicht dafür gemacht,
    sich an einen laufenden Prozess anzudocken, ohne Anhalten des Prozesses
    Werte anzusehen. Mal eben schnell den Code ändern. (Du hast in deinem Beispiel vergessen, dass man auch Daten ändern will, dann wird die Sache meist komplizierter).

    Zitat Zitat von Zottel Beitrag anzeigen
    Und als Hochsprache eine Art abgespecktes JAVA (ohne new), nachfolgend AVA genannt:
    AVA->Maschinencode
    AVA-> AWL
    Das ist genau das, was wir mit Codesys 3.x machen. Wir haben ein "abgespecktes" Java mit (Einfach-) Vererbung, Interfaces, Methoden etc. in die IEC integriert. Was fehlt, sind die Schlüsselworte public private protected und new. Eigentlich müsste dir das gefallen.
    Ob es viel bringt, aus AVA AWL zu erzeugen, das bezweifle ich allerdings.
    Das Problem ist ja nicht zu verstehen was "a = b % c;" heissen soll, sondern das man eine Klassenhierarchie, virtuelle Methodenaufrufe etc verstehen muss. Da nützt einem eine bekannte Syntax der Anweisungen überhaupt nichts.

    Bernhard

  3. #23
    Registriert seit
    20.10.2003
    Ort
    Biberach
    Beiträge
    5.068
    Danke
    959
    Erhielt 1.459 Danke für 922 Beiträge

    Standard

    Zitat Zitat von Zottel Beitrag anzeigen
    ...
    KOP, FUP -> AWL
    ...
    SCL-> AWL
    ...
    AVA-> AWL
    Der Sinn, den über den Zwischenschritt AWL gehen zu können oder nicht, liegt darin, daß mit AWL-Zwischenschritt der Code auch für nicht Hochsprachenkundige (notfalls) nachvollziehbar bleibt, während ohne AWL-Zwischenschritt optimaler (schneller, kurzer) Maschinencode erzeugt wird.
    Der AWL Code ist lesbar, aber nachvollziehbar? ... das ist dann ein
    riesiger Aufwand.

    Zitat Zitat von zotos Beitrag anzeigen
    Es gab ja mal ein CoDeSys abkömmling von Deltalogic der für S5 und S7 aus den Sprachen AWL/KOP/FUP/ST/AS/CFC Code (AWL?) erzeugt hat und das muss nur sehr schwer lesbar gewesen sein.
    Ja, das auf CoDeSys basierende ProSys hat STEP5-AWL
    und STEP7-AWL erzeugt, das AWL war auch lesbar.

    Aber wie jeder automatisch generierte Code war dieser
    AWL-Code nicht wartbar. Wurde von manchmal eher als
    Kopierschutz betrachtet.

    Keine Kommentare, der Compiler macht manches um-
    ständlicher als ein Programmierer - oder so effizient,
    dass es auch wieder schwer zu verstehen ist.

    Das die Zukunft dem Pascal-ähnlichen ST/SCL gehört,
    kann ich mir auch vorstellen.

    Viele Grüße

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

  4. #24
    Registriert seit
    29.07.2005
    Ort
    Salzburg
    Beiträge
    113
    Danke
    2
    Erhielt 6 Danke für 6 Beiträge

    Standard

    Auch wenns eher an der Anfangsfrage vorbeigeht:

    Ich bin nun seit 15 Jahren in der Steuerungstechnik tätig und programmiere nun seit gut 5 Jahren unsere SPSn ausschliesslich in C. Anfänglichs skeptisch weil ich dabei doch einiges mehr an Tipparbeit leisten muss (zumindestens meine IDE behandelt C eher stiefmütterleich). Ich habe in dieser Zeit die Sprache C lieben gelernt und möchte es nicht mehr missen. Richtig strukturiert erübrigen sich fast jeder zusätzlicher Kommentar.

    Beim Debugging einer S7 (für mich nicht das Maß aller Dinge, aber ein Beispiel, das alle kennen) kannst du die Registerinhalte nach jedem Schritt (Verknüpfung, Rechnung) ansehen.
    Das sollte eigentlich jeder Debugger ein Hochsprache auch können. Kommt eigentlich nur darauf an wie man programmiert. Der klassische Debugger einer Hochsprache bleibt ja bei einer Programmzeile stehen und je länger diese ist desto umständlicher das debuggen.

    Für binäre Verknüpfungen ist keine der üblichen Hochsprachen so richtig gut geeignet.
    Was man nicht kennt erschliesst sich nicht jedem sofort, soll heissen, je öfter du damit konfrontiert wirst desto weniger Probleme hast du damit. Ein Programmierer sollte aber mit logischen Ausdrücken wie

    Code:
    A = ((B && C) || D) && E;
    eigentlich keine Probleme haben (das sind mE absolute Basics).

    Die typischen C++ Anwendungen generieren Objekte zur Laufzeit. Auch wenn man Teile des Prozesses/Feldes durch Objekte abbilden möchte, kann ich keine Notwendigkeit erkennen, solche Objekte zur Laufzeit zu generieren oder zu entfernen.
    Viele dieser Objekte werden eh nur einmal beim Start generiert und bleiben dann bis zum Schluss am Leben. Wichtig ist doch das man sich um die Speicherverwaltung nicht mehr selbst kümmern muss. Dass man dazu nicht unbedingt eine Hochsprache verwenden muss (Instanz DBs, lokaler Speicherbereich) ist klar, nur bei den meisten Anlagen mit Siemens SPSn seh ich noch fast immer den klassischen Stil mit absoluten Adressen.

    Das ist genau das, was wir mit Codesys 3.x machen. Wir haben ein "abgespecktes" Java mit (Einfach-) Vererbung, Interfaces, Methoden etc. in die IEC integriert. Was fehlt, sind die Schlüsselworte public private protected und new. Eigentlich müsste dir das gefallen.
    Ob es viel bringt, aus AVA AWL zu erzeugen, das bezweifle ich allerdings.
    Das Problem ist ja nicht zu verstehen was "a = b % c;" heissen soll, sondern das man eine Klassenhierarchie, virtuelle Methodenaufrufe etc verstehen muss. Da nützt einem eine bekannte Syntax der Anweisungen überhaupt nichts.
    Vererbung, überladene Methoden, Namespaces ... klingt interessant!

    Grüsse, Harrylask

  5. #25
    Registriert seit
    13.03.2006
    Beiträge
    428
    Danke
    5
    Erhielt 43 Danke für 43 Beiträge

    Standard

    Wenn man Hochsprachen in der Programmierung von Automationen einsetzen will,
    muss man auf folgendes achten:

    - Das Wartungspersonal muss sich in der Hochsprache auskennen
    - Man braucht eine Bibliothek für die gängigen Funktionen,
    die einfach zu nutzen ist.
    - Das Grundgerüst des Programms sollte vorgegeben sein.
    - Das Lesen und Schreiben der Prozessvariablen,
    sollte durch einfache Parametrierung in einer INI-Datei gemacht werden.

    Dann könnten die Aktionen die in das Grundgerüst eingesetzt werden wie folgt aussehen:

    //---------------------------------------------------------
    #include "spslib.h" // hier sind die Klassen und Funktionen der SPS-Bibliothek definiert
    #include "spsdefines.h" // hier wird z.B. DRUCK, DRUCK_LIMIT definiert
    extern SPSEingaenge eingaenge;
    extern SPSAusgaenge ausgaenge;
    extern SPSMeldungen meldungen;

    void SPSZyklus() // nur hier drin muss der Anwendungsprogrammierer programmieren
    // das Hauptprogramm ist fertig vorgegeben
    {
    eingaenge.lesen();

    // Hier kommen die Aktionen
    // zum Beispiel
    if(eingaenge.variable(DRUCK) > DRUCK_LIMIT)
    {
    meldungen.printf("DRUCK zu hoch %d Bar",eingaenge.variable(DRUCK)); // zeigt Meldung in HMI an
    }

    ausgaenge.schreiben();
    }
    //---------------------------------------------------------

    Das kann meines Erachtens einfacher lesbar sein,
    als ein konventionelles SPS Programm.

    Bei der Programmierung von Level 2 und 3 einer Automation,
    wird sowieso eine Hochsprache eingesetzt.
    Wenn man auch in Level 1 der Automation,
    die gleiche Hochsprache einsetzen würde,
    braucht das Wartungspersonal nur in einer Sprache zu denken.
    Das wäre meines Erachtens ein Vorteil.

  6. #26
    Registriert seit
    20.10.2003
    Ort
    Biberach
    Beiträge
    5.068
    Danke
    959
    Erhielt 1.459 Danke für 922 Beiträge

    Standard

    Zitat Zitat von pvbrowser Beitrag anzeigen
    Bei der Programmierung von Level 2 und 3 einer Automation,
    wird sowieso eine Hochsprache eingesetzt.
    Wenn man auch in Level 1 der Automation,
    die gleiche Hochsprache einsetzen würde,
    braucht das Wartungspersonal nur in einer Sprache zu denken.
    Das wäre meines Erachtens ein Vorteil.
    Hallo,

    in der Literatur gibt es ja verschiedene Automatisierungs-
    pyramiden mit drei, vier, fünf oder gar noch mehr
    Ebenen – je nach Hersteller oder Hochschullehrer .

    Können Sie mal erläutern, was Sie unter Level 1, 2 und 3
    verstehen – damit wir eine einheitliche Basis haben.

    Dummerweise ist in Wikipedia bei SCADA zwar von davon die
    Rede, dass Automationen verschiedene Schichten
    haben, bei den Automationen selbst steht aber nichts
    Genaueres dazu.

    Viele Grüße

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

  7. #27
    Registriert seit
    13.03.2006
    Beiträge
    428
    Danke
    5
    Erhielt 43 Danke für 43 Beiträge

    Standard

    > Können Sie mal erläutern, was Sie unter Level 1, 2 und 3
    > verstehen – damit wir eine einheitliche Basis haben.

    - Level 1
    Feldebene, physikalische IO's, geschlossene Regelkreise, Echtzeit ...

    - Level 2
    Modellrechnungen, Optimierung, Sollwerte für Level 1 bereitstellen,
    Data Logging, HMI ...

    - Level 3
    Produktionsplanung, Qualitätssicherung ...

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

    Standard

    Ich habe mir überlegt das man eine pro contra Liste zum diesem Thema anfangen sollte.

    Also PC-basierende Automatisierung:
    IEC 61131-3 vs. Hochsprachen

    Aber das ist viel zu allgemein gefasst.

    Also nimmt man eine Hochsprache wie C/C++ mit der kann man ja nun wirklich fast alles machen. Nur man muss eben auch alles selbst machen. Man benötigt um damit arbeiten zu können so was wie ein (auf neudeutsch) Framework. Das Beispiel von pvbrowser ist wohl so ein Grundgerüst das die Anbindung an die Hardware (IOs, etc.), Timer und sonstige Bausteine zu verfügung stellt. Allso alles aufgaben die, die SoftSPSen in Verbindung mit den Entwicklungsumgebungen von Haus aus mit sich bringen.

    Solche Grundgerüste für C sind wohl in großer Zahl im Einsatz. Ich selbst habe eine Zeitlang mit einem solchen System gearbeitet. Nun findet man in einem solchen System oft nur schwer den durchblick da die gegebenen Funktionen die man benötigt nicht genormt sind.

    Die Programmiersysteme die sich an die IEC 61131-3 anlehnen (also mit zwei zugekniffenen Augen auch Step7) bieten also eine reihe an genormten Funktionen die meist auch gut dokumentiert sind und die "großen" darunter sind auch noch weit verbreited. Dazu kommt das man mit diesen Systemen eben nicht nur eine PC-basierende Steuerung sondern eben auch die klassischen SPSen programmieren kann.

    Das Argument das man wenn man auf allen Ebenen der Automatisierung nur eine Sprache benutzen könnte:
    Zitat Zitat von pvbrowser Beitrag anzeigen
    ...
    Bei der Programmierung von Level 2 und 3 einer Automation,
    wird sowieso eine Hochsprache eingesetzt.
    Wenn man auch in Level 1 der Automation,
    die gleiche Hochsprache einsetzen würde,
    braucht das Wartungspersonal nur in einer Sprache zu denken.
    Das wäre meines Erachtens ein Vorteil.
    ...kann ich zwar nachvollziehen. Ich denke aber man bei einer SPS immer das passende Tool (Programmiersprache) verwenden sollte.

    z.B.:
    Bitverknüpfungen (FUP/KOP)
    Komplexe Sachen (ST/SCL)
    Schrittketten (AS/GRAPH7)
    Schnelle trickreiche Sachen (AWL)

    Kann man so machen muss man aber nicht.

    Das Kredo alles was in der Sprache XYZ geht auch in dieser zu machen halte ich für unpraktisch. Wird aber oft verlangt ;o(


    Gibt es eigentlich ein offenes C/C++ "Framework" für die Automatisierung das von verschiedenen Firmen angewand wird?
    If you open your Mind too much, your Brain will fall out.

  9. #29
    Registriert seit
    30.08.2005
    Beiträge
    280
    Danke
    41
    Erhielt 96 Danke für 66 Beiträge

    Standard

    Hallo,

    wenn man einen PC für Steuerungsaufgaben hernimmt, dann muss man doch zuallererst das Problem der Echtzeitfähigkeit lösen. Die hat der nämlich nicht.
    Aber sagen wir mal, wir brauchen keine Echtzeitfähigkeit, dann muss man die Anbindung an die Feldebene lösen.
    Da gibt es x Karten für y Feldbusse.
    Dann erwartet man von einer SPS ein gesichertes Anlaufverhalten, remanente Daten, Programmänderung ohne den Prozess anzuhalten, Variablen beobachten ohne den Prozess anzuhalten...
    Wenn man das alles gelöst hat, dann kann man mit der Applikation anfangen.
    Oder man nimmt eben gleich ein Standardtool.

    Bernhard

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

    Standard


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    Zitat Zitat von Werner29 Beitrag anzeigen
    Hallo,

    wenn man einen PC für Steuerungsaufgaben hernimmt, dann muss man doch zuallererst das Problem der Echtzeitfähigkeit lösen. Die hat der nämlich nicht.
    Aber sagen wir mal, wir brauchen keine Echtzeitfähigkeit, dann muss man die Anbindung an die Feldebene lösen.
    Da gibt es x Karten für y Feldbusse.
    Dann erwartet man von einer SPS ein gesichertes Anlaufverhalten, remanente Daten, Programmänderung ohne den Prozess anzuhalten, Variablen beobachten ohne den Prozess anzuhalten...
    Wenn man das alles gelöst hat, dann kann man mit der Applikation anfangen.
    Oder man nimmt eben gleich ein Standardtool.

    Bernhard
    Das Echtzeitproblem ist ja nicht Hardware bedingt. Man muss ja nicht zu einem OS greifen das keine Echtzeit unterstützt ;o) Aber wenn man z.B. zu RTLinux greift muss man das ja auch erstmal im Griff haben.

    Ich denke auch das der Griff zu einem Standart Tool zur Programmierung wie CoDeSys (mit der CoDeSys-RTE) oder Step7 (mit WinAC/ACCONtrol) oder TwinCAT oder eines der anderen zahlreichen Systeme.

    Die von Bernhard Angesprochenen Aufgaben die solche Systeme schon gelöst haben sind nicht gerade trivial.

    In der heutigen Zeit wird oft bei der Entscheidung "make or buy" zu kaufen tendiert und in diesen Systemen stecken ja Mannjahre an Entwicklung und man muss diese Dinge oft erstmal auf eigene Kosten entwickeln bevor man damit Geld verdienen kann.

    Der Bereich der Automatisierung ist sehr groß es gibt sicher die eine oder andere Anwendung wo es sich lohnt C/C++ anstelle eines SPS-Systems zu nehmen.

    Meiner Meinung nach sind die vorhandenen SPS-Systeme so ausgelegt das sie die meisten Anwendungen abdecken können.
    If you open your Mind too much, your Brain will fall out.

Ähnliche Themen

  1. B&R Programmierung
    Von Viper86 im Forum Sonstige Steuerungen
    Antworten: 29
    Letzter Beitrag: 25.01.2011, 16:53
  2. S5 AWL Programmierung
    Von Wasserkraft im Forum Programmierstrategien
    Antworten: 2
    Letzter Beitrag: 22.09.2007, 16:58
  3. TC/IP Programmierung
    Von Christian Schröder im Forum Feldbusse
    Antworten: 1
    Letzter Beitrag: 06.07.2006, 19:30
  4. Programmierung KM PS4-341
    Von 62addi im Forum Sonstige Steuerungen
    Antworten: 1
    Letzter Beitrag: 23.08.2005, 20:46
  5. Programmierung in S7- SCL
    Von old_willi im Forum Stammtisch
    Antworten: 5
    Letzter Beitrag: 19.06.2005, 15:29

Lesezeichen

Berechtigungen

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