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

Seite 1 von 4 123 ... LetzteLetzte
Ergebnis 1 bis 10 von 31

Thema: C-Compiler für S7! wer macht mit?

  1. #1
    Registriert seit
    18.12.2005
    Beiträge
    71
    Danke
    0
    Erhielt 1 Danke für 1 Beitrag

    Standard


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    Hallo @

    Wenn ich die Möglichkeiten sehe, die sich mir im Simatic-S7-Bereich so bieten, da graut's mir eigentlich und für mich wird die Frage immer deutlicher, warum ein Anwender soviel Gehirnakrobatik aufwenden muss, um ein halbwegs ordentliches S7-SPS-Programm auf die Reihe zu bringen.

    Was gibt es denn so in der S7-Welt:

    AWL - ist was für Leute, die sich bis in die tiefsten Winkel einer CPU auskennen müssen und wird LEIDER von der Mehrzahl der Kundschaft abgelehnt. AWL ist aber bis heute immer noch das Mittel der Wahl, wenn es darum geht, effiziente Programme zu erstellen, da führt nach meinem Verständnis kein Weg daran vorbei, auch wenn es die Befürworter anderer Ansichten nicht wahr haben wollen.

    KOP und FUP - ich schmeiß das mal in einen Topf (zumindest aus meiner Sicht) ist was für Leute, die mit dem Zeigefinger die grafischen Linien nachfahren und so die Logik erfassen wollen ('tschuldigung wenn ich das so salopp ausdrücke). Spätestens bei komplexeren Problemen, die mit arithmetischen Mitteln gelöst werden müssen, wird's fad und man sehnt sich nach AWL zurück (SCL klammere ich an dieser Stelle vorerst einmal aus). Zu Zeiten der S5 habe ich bei meinen Projekten FUP und KOP eine klare Absage erteilt - bei S7-CFC ergibt FUP und KOP ohnehin keinen Sinn mehr. Es macht z.B. keinen Sinn drei Logikzweige herunterzurasseln, wenn jeder Zweig nur bei einer bestimmten Bedingung Gültigkeit besitzt. Dies ist immer dann der Fall, wenn "z" durch verschiedene Logikmuster gebildet werden soll aber das jeweilige Logikmuster nur bei einer bestimmten Bedingung gültig ist. Bei z.B. drei Logikmustern führt dies unter KOP und FUP schon zu drei unnützen UND-Funktionen und einer unnützen ODER-Funktion, um schließlich "z" zu bestimmen. Bei großen Programmen kann dies schon mal dazu führen, dass die Zykluszeit nachgetriggert werden muss, was eigentlich keine gute Sache ist.

    SCL - Structured Control Language, ein pathetischer Name für etwas, was es eigentlich nicht verdient so genannt zu werden. Ich drücke das mal bewusst so provozierend aus. Wenn SIEMENS in seinem Handbuch zu SCL die Orientierung zu PASCAL hervorhebt, wird mir schlecht. Ich kann gar nicht so viel essen, wie ich kotzen möchte. Was bleibt sind die zu Pascal ähnlichen syntaktischen Regeln aber spätestens beim Aufruf einer Funktion oder Prozedur werden diese Regeln bei der Parameterübergabe schon verletzt. Wenn SCL wenigstens ein Minimum dessen bieten würde, was in Pascal tatsächlich formuliert werden könnte, so wäre wenigstens der Weg von AWL zu SCL mit einem positiven Vorzeichen besetzt.

    CFC - hier verkommt der SPS-Programierer zum "Verdrahter" von Funktionsbausteinen, deren Komplexität er in den allermeisten Fällen nicht übersehen kann. Das Ergebnis ist dann oft nur über Try&Error zu erreichen und basiert selten auf dem zuvor angedachten Lösungsweg, der mit einer klaren Programmformulierung in einer klaren Programmiersprache effizienter erreichbar gewesen wäre. CFC setzt daher auf den intensiven Gebrauch von SCL und AWL.

    Jetzt hat die CFC-Fangemeinde sich selbst in eine Ecke manövriert (oder besser manövrieren lassen), in dem für veraltete Argumente kein Platz mehr ist. Früher hat vielfach das Argument gegolten, AWL könne nicht von Instandhaltungselektrikern verstanden werden - ja und, dann hätte der Kunde doch eigentlich mehr in die Weiterbildung seines Personals investieren müssen! Heute bietet sich die Möglichkeit an, komplexere oder wiederkehrende Funktionen in SCL oder AWL zu definieren und diese dann in CFC einzubauen und wird, erstaunlich genug, von den Kunden so akzeptiert! Man könnte natürlich auch diese komplexeren oder wiederkehrenden Funktionen als Plan-in-Plan implementieren, bei umfangreichen Projekten sind dann aber ziemlich schnell die Resourcen erschöpft, die Grenze bei einem größeren Projekt auszutesten ist dann eine ziemlich miserable Ausgangslage und man wird dann die Vernunft walten lassen und sich gleich darauf einrichten, komplexere oder wiederkehrende Funktionen von Anfang an immer in SCL oder AWL zu definieren. Womit ich fast an dem Punkt einer Idee angelangt bin, die mir seit einiger Zeit nicht mehr aus dem Kopf geht.

    Es gibt immer noch Leute, die AWL hassen, wie der Teufel das Weihwasser. Aber was hat es mit dem SCL auf sich? Unter SCL kann ich z.B. die simple Addition dreier Variablenwerte so ausdrücken:
    Code:
    D := A + B + C;
    Direkt in AWL implementiert würde das so aussehen können:
    Code:
    L   #A
    L   #B
    +R
    L   #C
    +R
    T   #D
    Aber was macht SCL beim Übersetzen????
    Man kann also einen Baustein in einer x-beliebigen Library mit SCL erzeugen und den Baustein dann anschließend in das Projekt übertragen. Es wird nur der compilierte Code übertragen, nicht jedoch die SCL-Quelle. Man kann den Baustein dann im Projekt öffnen und - oh Wunder - man sieht AWL!!!!!!

    Ja also - so ganz ohne AWL geht's dann doch nicht! Warum das so ist, will ich hier nicht näher vertiefen, es reicht zu wissen, das es so ist. Natürlich schaut die Formulierung des oben genannten Beispiels in SCL viel eleganter als in AWL. Aber für jemanden, der in einer Hochsprache wie Pascal oder C zu hause ist, ist die von Siemens vorgehaltene SCL-Umgebung mehr als jämmerlich. Ich will Pascal nicht abwerten, ich selbst bin über Pascal zu C gekommen und so hätte ich mir eigentlich vorstellen können, dass Siemens statt der Anlehnung an Pascal dann doch besser eine Anlehnung an C vorgenommen hätte.

    Wesentlich ist, dass es in SCL selbst keine Debugmöglichkeiten gibt. Beim Testen eines in SCL geschriebenen Bausteins ist man entweder auf Try&Error angewiesen oder man knöpft sich den Baustein auf der AWL-Ebene (!!!) vor. Auch sind die Fehlerausschriften des SCL-Compilers sehr miserabel und braucht schon eine Menge an Intuition, um die Formulierungsfehler auf Anhieb zu finden.

    Bei mir ist dann so die Idee entstanden, eine Entwicklungsumgebung für S7-Bausteine zu entwickeln, die im Rahmen der Möglichkeiten, die sich auf Simatic-S7 (Serie300/400) beziehen, statt einer Anlehnung an Pascal eben mit einer Ausrichtung zu C aufwarten kann. Der generierte Code wird im AWL-Format im Rahmen einer Textdatei gespeichert, der in die S7-Umgebung als AWL-Quelle importiert werden kann. Die Ausrichtung zu C sollte alle in C üblichen Methoden beinhalten, sofern dies entsprechend den Adressierungsmöglichkeiten der S7 durchführbar wäre.

    Wer hätte Lust, an einem solchen Projekt für den Compilerbau mitzuwirken?

    Gruß Barnee
    Zitieren Zitieren C-Compiler für S7! wer macht mit?  

  2. #2
    Registriert seit
    18.02.2005
    Beiträge
    36
    Danke
    0
    Erhielt 0 Danke für 0 Beiträge

    Standard

    Also ich persönlich, würde alles beim Alten lassen. SPS ist halt eine Welt für sich und sollte es auch bleiben. Wenn man das zu sehr vereinfacht, gefährdet das bloß wieder Arbeitsplätze.Wenn mit einmal jeder "0815"-Windoof-User daherkommen kann und eine SPS programmiert?? Na ich weiß nicht so recht. Letzten endes ist es jedem freigestellt, was er SPS-mäßig machen möchte, von mir aus auch das Programmieren vereinfachen. Aber von meiner Seite kommt da auf jeden Fall kein allzugroßer Zuspruch. Man sollte es bei den bestehenden Regeln belassen. Ich denke das ich meinen Standpunkt damit kurz und klar beschrieben habe und ich denke mal, das ich damit nicht der einzigste sein werde.

    Ansonsten könnte man auch noch anfangen, Videorekorder etc. in einer vereinfachten Art und Weise zu programmieren. Oder die Mikrowelle, das Höllengerät, dazu zu bewegen auf Sprache zu reagieren. Ist alles machbar, nur die Frage ist halt ob es sinnvoll, bzw. gewünscht ist...


    Mfg

    dna909

  3. #3
    Registriert seit
    31.10.2005
    Beiträge
    26
    Danke
    0
    Erhielt 3 Danke für 3 Beiträge

    Standard

    Hallo Barnee,

    SCL ist sicherlich nicht mit Pascal zu vergleichen. Das liegt aber IHMO daran, das SCL eher ein Flickwerk ist, um zur IEC 61131-3 konform zu sein.
    Wesentlich ist, dass es in SCL selbst keine Debugmöglichkeiten gibt
    Quatsch ! Es gibt alle Debug-Möglichkeiten: Haltepunkte, Einzelschritt usw.
    Was allerdings nicht geht sind zusammengesetzte Datentypen (Strings, Date_and_Time usw.) online zu debugen, was mich pers. am meisten an SCL stört. Codesys macht das ohne Probleme.

    Was dein Projekt angeht denke ich der SCL-Editor ansich schon das beste für Step 7 ist (denke an Debug-Möglichkeit ).

    Aber nix für ungut ist auf jedenfall ne tolle Idee !

    Gruß

    Bewareofthis

  4. #4
    Registriert seit
    09.01.2006
    Beiträge
    31
    Danke
    0
    Erhielt 0 Danke für 0 Beiträge

    Standard

    Ich schließe mich dna´s Meinung an, denn dann könnte echt beinahe jeder daher kommen der auch nur annähernd bis 3 zählen kann!
    S7 ist gar nicht so mies wie du es machen willst, man muss sich halt nur mehr gedanken darüber machen wie man was machen will, wer das nicht möchte kann es ja bleiben lassen

  5. #5
    Barnee ist offline Benutzer
    Themenstarter
    Registriert seit
    18.12.2005
    Beiträge
    71
    Danke
    0
    Erhielt 1 Danke für 1 Beitrag

    Standard

    Zitat Zitat von dna909
    Also ich persönlich, würde alles beim Alten lassen. SPS ist halt eine Welt für sich und sollte es auch bleiben. Wenn man das zu sehr vereinfacht, gefährdet das bloß wieder Arbeitsplätze. Wenn mit einmal jeder "0815"-Windoof-User daherkommen kann und eine SPS programmiert??
    Ach je Verzeihung, wollte eigentlich keine Ängste wecken. Aber ich erinnere mich noch an ein Projekt, vor etwa 10...12 Jahren, da hab ich für CP584, welche jeweils in einem S5-155H-Rack gesteckt wurden, ein Programm in Pascal (Borland) geschrieben. Das Programm war zur Realisierung eines mathematischen Modells bestimmt, konnte aber nicht mit der Peripherie direkt kommunizieren, d.h. der Datenaustausch wurde über DB's geregelt. Ohne dna909 zu nahe zu treten zu wollen, war aber IEC1131 schon dazu bestimmt worden, die Dinge in der SPS-Umgebung zu vereinheitlichen und schlussendlich sollte alles einfacher werden. Na ja, in der Siemens-Welt ist da dann doch nicht soviel bei herausgekommen. 1996 wurde von einem Frankfurter Team, was ehemals aus einem alten AEG-Ableger entstammt, "CADSOFT IEC1131" für Quantum-PLC entwickelt. Mein Team gehörte damals mit zu den ersten Anwendern und wir haben an der Entwicklung maßgeblichen Einfluß gehabt. Schon damals habe ich für diese Umgebung anwendungsspezifische Bausteine in C entwickeln können. Für das damalige Projekt hab ich eine beachtliche Anzahl von Bausteinen für die Regelungstechnik codiert, angefangen bei einem universalen PID-Regler usw.usf. Das Projekt umfasste damals etwa 140 Regelkreise in unterschiedlichen Konstellationen und da hatte es sich schon gelohnt, etwas Hirnschmalz aufzuwenden, um ähnliche und wiederkehrende Abläufe zu systematisieren. Außerdem war auch die damalige Drahtziehtechnik um einige Klassen besser, als das was Siemens heute unter CFC bietet. Aber lassen wir das, denn das ist schließlich nicht mein Thema.

    @Bewareofthis
    Jetzt haste mich doch erwischt. Hab ich bisher nicht mitbekommen, dass man SCL debuggen kann Gut, nicht jeder kann alles wissen, will ich auch nicht.

    Ich will auch nicht das SCL verbessern, das sollen die tun, die es auch verbrochen haben. Mein Ansatz bezieht sich darauf, eine externe Möglichkeit zu schaffen, mit den Sprachmitteln von C eine Umgebung zu bauen, welche die Formulierung von Lösungen eben mit diesen C-Sprachmitteln erlaubt. Da ich schon mehrere Compiler gebaut habe, schreckt mich ein solcher Gedanke nicht. Ersten Zuspruch gibt es schon über PN, hat mich doch positiv überrascht.

    Gruß Barnee

  6. #6
    Registriert seit
    17.06.2004
    Ort
    Offenau
    Beiträge
    3.746
    Danke
    209
    Erhielt 421 Danke für 338 Beiträge

    Standard

    Hätte auch interesse, wenn ich was helfen kann...

    Es würde ja später auch die möglichkeit bestehen über die libnodave auch eine sps kommunikation einzubinden und somit viel. doch ein debbuging möglich zu machen???
    ---------------------------------------------
    Jochen Kühner
    https://github.com/jogibear9988/DotN...ToolBoxLibrary - Bibliothek zur Kommunikation mit PLCs und zum öffnen von Step 5/7 Projekten
    Zitieren Zitieren interese....  

  7. #7
    Registriert seit
    18.02.2005
    Beiträge
    36
    Danke
    0
    Erhielt 0 Danke für 0 Beiträge

    Standard

    Ich fühle mich in keinster Weise angegriffen.
    Jeder der eine Meinung hat, darf diese auch vertreten.

    Mfg

    dna909

  8. #8
    Anonymous Gast

    Standard

    @Barnee

    Sagmal haben die Dich bei Siemens nicht eingestellt und Deine Bewerbungsunterlagen in den Müll geworfen ??????

    Nur weil C für Dich das "Beste" auf der ganzen Welt ist trifft das nicht für jeden zu.

    Ich bin zB. sehr glücklich das es neben C in WinCC jetzt VB gibt weil ich bei C immer das Gefühl habe zu kotzen.

    Außerdem wenn AWL nicht immer von Kunden erlaubt wird meinst Du wirklich das dann Dein C in Ordnung ist.

    Überhaupt hier im Forum immer der Blödsinn von AWL ist besser und FUP.KOP ist scheisse....... usw.

    FUP, KOP, Graph, HiGraph, CFC, SCL alles Müll...................
    Ich finde Sie alle gut und jede hat Vor-/und Nachteile.

    Wenn Du was schreiben willst dann schreibe etwas was man gebrauchen kann.
    Was wir nicht brauchen ist sowas aus der Steinzeit als Quelle importieren.

    Gruß
    Zitieren Zitieren ein Schlaumeier  

  9. #9
    Registriert seit
    25.09.2005
    Ort
    Neuss
    Beiträge
    278
    Danke
    11
    Erhielt 31 Danke für 29 Beiträge

    Standard

    Im Großen und Ganzen komme ich mit den Sprachelementen, die S7 bietet aus. Mir wäre für den Anfang lieber, wenn man z.B. unter SCL bessere Debug-Möglichkeiten hätte. Wenn ein evtl. C-Compiler im Stil wäre wie der SCL-Compiler im Moment, möchte ich lieber darauf verzichten. (meine Meinung)

  10. #10
    Registriert seit
    07.07.2004
    Beiträge
    3.285
    Danke
    38
    Erhielt 584 Danke für 382 Beiträge

    Standard


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    @Barnee,
    besser Du beschäftigst Dich mit den Möglichkeiten, die AWL, SCL und Co. zur Zeit bieten. Das Rad neu zu erfinden, daran haben viele Leute Zeit und Geld verschwendet, es wird dadurch nicht runder. Man kann es vielleicht nur auswuchten, aber bestimmt nicht mit der Programmiersprache C oder C++. Schau Dir nur mal den Quelltext von Zottels's LibNoDave an, es ist einfach nur ein Graus, welche Klimmzüge mit Makefiles, Compilerdirektiven u.ä. gemacht werden muss, nur um allen möglichen Plattformen (die kein Mensch braucht), gerecht zu werden. Zeigerakrobatik bis zum Erbrechen, und Du willst eine C-Plattform für PLC's schaffen ?
    Wenn Du ein paar Jahre Zeit hast, fang schon mal an zu programmieren. Mich erinnert das an einige Beiträge in einschlägigen Foren, wo Schulkinder mit der PE von Delphi gleich ein neues Betriebssystem a la Windows in 2 Wochen erstellen wollten.
    Zusammenfassung : Vergiss es, was einige hundert Ingenieure bei Siemens nicht entwickeln wollen (der Markt dafür ist einfach nicht präsent) , schaffst Du auch in einigen Jahren nicht allein. Und wenn doch, will es keiner haben oder bezahlen !!!
    @Zottel,
    nicht böse sein, ich will Deine tolle Leistung damit nicht abwerten, aber über eine serielle Schnittstelle auf MPI zu adaptieren ist nun mal wirklich nicht die optimale Lösung. Interessant wäre eine direkte Kommunikation über CP5611 oder CP'S von Fremdanbietern, aber leider kennt keiner die Registerbelegung dieser Karten (ausser Herr Hönle vielleicht)

    Gruß
    Question_mark
    ''Ich habe wirklich keine Vorurteile.
    Meine Meinung ist nur die Summe der Erfahrungen" ... (Question_mark)
    Zitieren Zitieren Haha, C für SPS, ich kann nicht mehr  

Ähnliche Themen

  1. Gedanken zum C Compiler
    Von seeba im Forum Hochsprachen - OPC
    Antworten: 37
    Letzter Beitrag: 17.10.2015, 11:51
  2. was ist den aus dem C-Compiler für S7 geworden?
    Von LowLevelMahn im Forum Hochsprachen - OPC
    Antworten: 1
    Letzter Beitrag: 06.10.2008, 17:12
  3. SCL-Compiler und Case-Anweisung
    Von herdi im Forum Simatic
    Antworten: 4
    Letzter Beitrag: 10.09.2008, 10:02
  4. Markus und der S7 C-Compiler
    Von Markus im Forum Hochsprachen - OPC
    Antworten: 1
    Letzter Beitrag: 27.01.2006, 01:33
  5. Freier SCL-Compiler ?
    Von linax im Forum Simatic
    Antworten: 0
    Letzter Beitrag: 04.12.2003, 20:25

Lesezeichen

Berechtigungen

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