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



## Barnee (21 Januar 2006)

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:

```
D := A + B + C;
```
Direkt in AWL implementiert würde das so aussehen können:

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


----------



## dna909 (21 Januar 2006)

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


----------



## Bewareofthis (21 Januar 2006)

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


----------



## Sven1983 (21 Januar 2006)

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  8)


----------



## Barnee (21 Januar 2006)

dna909 schrieb:
			
		

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


----------



## Jochen Kühner (21 Januar 2006)

*interese....*

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


----------



## dna909 (22 Januar 2006)

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

Mfg

dna909


----------



## Anonymous (22 Januar 2006)

*ein Schlaumeier*

@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ß


----------



## HeizDuese (22 Januar 2006)

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)


----------



## Question_mark (22 Januar 2006)

*Haha, C für SPS, ich kann nicht mehr*

@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)  :lol: 

Gruß
Question_mark


----------



## afk (22 Januar 2006)

*Re: Haha, C für SPS, ich kann nicht mehr*



			
				Question_mark schrieb:
			
		

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


Soweit ich weiß dient der größte Teil der "Klimmzüge" für die Platformunabhängigkeit dazu, libnodave auch auf Windows zum laufen zu bringen. Braucht das außer mir wirklich kein Mensch ?  :lol: 
Was das Thema Zeigerakrobatik betrifft, da habe ich in C schon übelsten Quellcode gesehen, aber der von Zottel gehört nun wirklich nicht dazu. 
Ich gehöre zwar zur ObjectPascal-Fraktion und bin selbst auch kein Fan von C, aber Zottel hat wirklich gute Gründe dafür, libnodave in C zu programmieren. 



			
				Question_mark schrieb:
			
		

> @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)  :lol:



In libnodave ist schon seit längerem ISver_TCP implementiert (Ethernet), zusätzlich beherscht es das Protokoll der diversen Netlink-Adapter (auch Ethernet), und seit geraumer Zeit ist kann man sogar per S7Onlinx.dll über die diversen Siemens-CPs auf die SPS zugreifen, und offensichtlich ist mittlerweile sogar eine Anbindung von S5 in Arbeit, und das alles auch noch mit einer einheitlichen Programmierschnittstelle, wo ist also das Problem ? :?

Gruß Axel


----------



## arcis (22 Januar 2006)

*+*



> Wenn ich die Möglichkeiten sehe, die sich mir im Simatic-S7-Bereich so bieten, da graut's mir eigentlich



Es stellt sich die grundsätzliche Frage, ob es die Aufgabe einer SPS sein soll, umfangreichere Datenverarbeitung zu betreiben. Darauf zielt dieser Ansatz wohl ab. Wenn sowas angedacht wird, wie sichert man die Echtzeitfähigkeit für möglicherweise gleichzeitig ausgeführte Ablaufsteuerungen?  Mehrere Prozesse mit unterschiedlichen Prioritäten, Prozesskommunikation und -synchronisation? Was baucht das für ein Betriebssystem auf der SPS? Lohnt sich dieser Mehraufwand an Komplexität, nur um z.B. ein paar Datenbankberechnungen auf der SPS auch noch auszuführen?


----------



## Barnee (22 Januar 2006)

Moin allseits



			
				OhGott schrieb:
			
		

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


Wusste gar nicht, dass sich der liebe Gott persönlich um mich bemüht  Lieber Gott, wenn du tatsächlich wüsstest, für wen ich alles so arbeite... aber wir wollen ja nicht persönlich werden, also lassen wir das... BTW, es muss sich ja nicht jeder angesprochen fühlen und am wenigsten sollte man bei mir den missionarischen Eifer suchen, da schaut es doch anderweitig viel eher danach aus :wink: Es scheint doch viel eher zu sein, als wenn der große Bruder eine Parole ausgegeben hat, so AWL mit Steinzeit assoziiert wird... Hab ich da was verpasst 8)



			
				Question_mark schrieb:
			
		

> ...besser Du beschäftigst Dich mit den Möglichkeiten...das Rad neu zu erfinden...schau Dir nur mal den Quelltext von Zottels's LibNoDave an...


Nix für ungut, aber ich weiß noch immer selbst am besten, was ich in meiner Freizeit anstellen möchte. Davon abgesehen, dass ich selbst am späten Abend noch geantwortet habe, scheinen aber andere noch bis in die frühen Morgenstunden zu grübeln...sorry, habt ihr keine Betten zu hause anstatt sich mit Bitbumserei beschäftigen?? 



			
				arcis schrieb:
			
		

> Es stellt sich die grundsätzliche Frage, ob es die Aufgabe einer SPS sein soll, umfangreichere Datenverarbeitung zu betreiben. Darauf zielt dieser Ansatz wohl ab....


Zu einem Zeitpunkt, als die Bitmaschinen gerade das Laufen gelernt haben, hat wohl niemand damit gerechnet, dass heute ausgewachsene SPSen viele Aufgaben auf Gebieten übernehmen, die von den damaligen Herren der MSR-Zunft für sich reklamiert wurden. Es waren die Leutchen, die auf ihrem Schreibtisch immer einen vorgewärmten Lötkolben griffbereit hatten und die mit hoch getragener Nase auf die niedere Kaste der Elektriker herabsahen. Das hat sich geändert und für viele dieser Leutchen gilt der Spruch von Gorbatschow, die nun die Elektriker bitten müssen, in der SPS nach einer Messstelle zu schauen...so ändern sich die Zeiten.

Um allen Missverständnissen vorzubeugen, will ich mal definieren, was ich *nicht* möchte:
- Ich will den S7-Manager nicht revolutionieren.
- Ich will keinen missionarischen Eifer entwickeln.
- Ich will keine Fraktion für mich gewinnen.
- Ich will SCL nicht verbessern.

Meine Idee hat eher den sportiven Hintergrund. So sollte es doch für Interessierte - was also klar ausdrückt, wer sich angesprochen fühlen sollte - eine Möglichkeit geben, die täglich anfallenden Aufgaben mit einem eleganteren Werkzeug zu lösen. Da in S7-AWL C-Elemente bereits angewendet werden, verwundert es mich, das man in SCL wieder mit Pascal-Sprachelementen konfrontiert wird. Die Herstellung eines solchen Werkzeugs ist nicht mit einem so großem Aufwand verbunden, als es viele glauben machen wollen. Es kommt darauf an, welches Nahziel man sich setzt. *Die einfache Formel für ein solches Werkzeug sollte nur die Forderung aufstellen, die Erstellung von FC's oder FB's mit C-Sprachmitteln zu ermöglichen, um damit einen sauberen und gültigen (sicheren) AWL-Code zu generieren.* Damit bleibt es jedem überlassen, das mit einer SPS zu machen, was auch immer er will und was er auch bisher schon immer getan hat. Wer sich mit C nicht anfreunden kann, sollte es dabei bewenden lassen, ihm bleiben eh alle anderen Möglichkeiten offen.

Da ich bereits mehrfachen Zuspruch über PN bekommen habe, bitte ich auch potentiell Interessierte sich bei mir persönlich via PN zu melden.

Schönen Sonntag noch allen
Gruß Barnee


----------



## Anonymous (22 Januar 2006)

Hi Barnee......

Erstens ist es gut das Du nicht persönlich werden willst und zweitens ist es auch gut das ich nicht weiß für wen Du so alles arbeitest................. sollen doch Deine Kunden bleiben  :wink: 

Ich meine nicht AWL ist Steinzeit sondern Dein Import als Quelle. 

Wie lange kennst Du eigentlich Step7 & Co das Du Dich erst jetzt so über SCL aufregst???

STEP 7 Optionspaket Pro C/C++ hast Du damit mal etwas gemacht???
Die Nachfrage war so groß das es seit 5 Jahren aus dem Programm ist.

Gruß


----------



## Question_mark (22 Januar 2006)

Hallo,


			
				afk schrieb:
			
		

> wo ist also das Problem ?


Ich habe kein Problem mit LibNoDave. Den Hinweis darauf habe ich nur gemacht, um aufzuzeigen, wie dann möglicherweise SPS-Bausteine in C aussehen könnten (Zottel möge mir das bitte verzeihen). Wenn ich Barnee richtig verstanden habe, bemängelt er u.a. die Umsetzung von SCL in AWL.
Ein paar Sätze weiter möchte er dann AWL aus allen Elementen der C-Sprache erzeugen. Dann sollte man auch konsequenterweise AWL umgehen und direkt S7-Maschinencode erzeugen. Die SCL-Syntax ist sicherlich an einigen Stellen verbesserungswürdig, aber m.E. noch lange kein Grund, dies jetzt durch einen C-Compiler zu ersetzen. Siemens wird nicht ohne Grund SCL an Pascal angelehnt haben. Dies könnte z.B. die wesentlich striktere Typüberprüfung und die logischere Syntax der Sprache Pascal sein.
Die mir bekannten C-Compiler nehmen es ohne Murren hin, wenn ich Speicherplatz für fünf Zeichen vom Typ Char anfordere und zehn Zeichen da reinschreibe. Ganz klar ein Fehler des Programmierers, im günstigsten Fall sofortiger Programmabsturz. Im ungünstigen Fall Programmabsturz alle 8 Wochen, viel Spass bei der Fehlersuche. 
Damit die Elektriker von der Reparatur und Instandhaltung sich schon mal warmlaufen können, habe ich mir den Hinweis auf die Quelltexte von LibNoDave erlaubt (also versteht das bitte nicht als Kritik an LibNoDave, sondern eher als Kritik an der Sprache C und deren Ableger).
Genausowenig will ich hier einen Glaubenskrieg der Programmiersprachen anzetteln, die Sprache C ist sicher für viele Zwecke die bessere Wahl. Aber vergesst nicht, dass wir hier über den Einsatz in industriellen Steuerungen reden und nicht über PC-Programmierung. Letztendlich muss ich als Ersteller von Software dafür sorgen, durch leichte Lesbarkeit,  saubere Strukturierung und Kommentierung des Quellcodes (SCL,AWL,FUP etc.) das Programm auch für das Wartungspersonal verständlich zu machen. Und genau dafür ist die Sprache C m.E. hier mal nicht die erste Wahl. Soviel zum Thema Qualität der Software und mit welchen Maßnahmen und Werkzeugen Qualität erreicht werden kann.
Meine Meinung kurz zusammengefasst : Ich glaube nicht, dass ein C-Compiler für SPS-Programme erforderlich oder gar erstrebenswert ist. Mit den bisherigen Möglichkeiten von STEP7 kann man durchaus komplexe Steuer- und Regelungsaufgaben lösen. Aber egal welches Werkzeug für die Programmerstellung benutzt wird, sollte man nicht vergessen : Irgendein armer Kerl muss evtl. in der Nachtschicht einen Fehler suchen, mein Programm sollte ihm durch Strukturierung, Kommentierung und Übersichtlichkeit auch eine Chance bieten, den Fehler zu finden. Und ob ich das mit der Sprache C erreichen kann, daran habe ich mit Verlaub so meine Zweifel.

Gruß
Question_mark


----------



## Lazarus™ (22 Januar 2006)

Also ich finde die Idee zwar gut, aber der Sinn ???  Ich denke, wenn ich allgemeine Steuerungsaufgaben in SCL und AWL abdecke in einer SPS und bei Datenverwaltung grösseren Stils einen PC einbinde, der das macht, dann kann ich eh über C,Pascal,VB oder sonstwas arbeiten. Also
ist es irgendwie nicht sinnvoll, bzw. Zeitverschwendung...
Ich will niemenden verletzen, aber diese Ideen gab es schon vor 20 Jahren und es wurde nie was draus, da man, speziell bei Siemens mit völlig veralteten Protokollen und Klimmzügen versucht, so inkompatibel zu sein, wie maximal möglich...  Es wäre ein leichtes ein anständiges Betriebssystem in die SPS zu integrieren und offene Schnittstellen zu implementieren, aber das wird halt nicht gewünscht (logisch)
Also wenn ich bei dem Projekt irgendwann,irgendwo einen brauchbaren Ansatz finde, würde ich es unterstützen, glaube aber nicht dran.

Letzter Satz: Zottels Zeigerakrobatik ist trotz allem den möglichkeiten entsprechend sehr sauber und gut verständlich. Ich habe da auch schon andere Codes gesehen ;-) und die hatten dann irgendwann noch die Bemerkung: Sorry,war Werksstudent und bin nicht mehr fertig geworden...   Das ware eine 1200,- DM teure Software für S5/Windows Kopplung    Und Zottels Lib ist FREEWARE !!!


----------



## Barnee (22 Januar 2006)

Ich habe meine ersten SPS-Erfahrungen mit einer Melsec von Mitsubishi gemacht, da stand der Begriff SIMATIC noch für Logikbausteine auf Hardwarebasis....ich bin also ein Urviech aus der Steinzeit, mein Nickname kommt daher nicht von ungefähr...

Die letzten S5-Steuerungen waren S5-155H (redundante Systeme) als es bereits S7-Systeme gab. Aber seitens Siemens hat man mir davon abgeraten, sofort auf S7 umzustellen, die wussten sicher schon weshalb. Zwischendurch in den 80ern gab es mal Projekte mit MMC216 (auf RMOS-Basis, Programmierung in PLM86, wer kennt das noch?) und Visualisierung mit GAV usw.usf.

Die S5 als Vorgänger zu S7 hat sicher wesentliche Teile des heutigen S7-Systems geprägt. Doch habe ich mich bisher im Bereich S7 wenig um die "Innereien" bemüht, weniger als es bei der S5 der Fall war. Doch das kann sich ändern.

Bei S5 war MC5 angesagt und die 1:1-Repräsentanz von MC5-Code auf der Programmieroberfläche der PG's war nun mal AWL. Ich kann mir vorstellen, dass es sich heute bei S7-Systemen so ähnlich verhält, zumindest hat es den Anschein bei S7-300, bei der 400er bin ich z.Zt. überfragt (bestand bisher keine Notwendigkeit, sich um tiefere Einblicke zu bemühen), aber warum sollte es anders sein? Man mag mich eines Besseren belehren.

Wer kennt noch Coros LSB? Bei den Einsätzen Anfang der 90er habe ich mir sehr viele Tools geschrieben, um die Manipulation zum Zwecke der Dynamisierung zu vereinfachen bzw. zu automatisieren. Bei den Projekten war dies eine erhebliche Arbeitserleichterung anstatt jede Grafikbox manuell zu bearbeiten, Reduzierung des Arbeitsaufwandes bis zu 50%.

Eine Idee kann man natürlich versuchen abzuwürgen, in dem man vordergründig alles ins Feld führt, was in einem anderen Kontext schon mal negativ aufgestoßen ist. Die Gestaltung eines Projekts hängt IMHO davon ab, ob man sich konform zum Mainstream verhalten will oder nicht. Konform zum Mainstream hat die Idee schon verloren, so wäre es besser, gleich nach der Geburt die Beerdigung zu bestellen. Warum Siemens sein Angebot für eine C/C++-Option eingestellt hat, kann ich nicht beurteilen, das mag viele Gründe haben, darüber nachzudenken, da gerät man in den Bereich der Spekulation. Das ich für meine Teil die Anwendung eines C-Compilers als vorteilhaft sehe, begründet auch meine öffentliche Äußerung der Idee in diesem Forum.

Die bisher aufgeführten Nachteile schrecken mich nicht, man kann das eher als Anmerkung registrieren, die möglichen Nachteile abzufangen. Aber bei allem, was bisher von meiner Seite dazu geäußert wurde, handelt es sich nur um die Bekanntgabe einer Idee in den Grundzügen, quasi die Definition eines Nahzieles. Die Ausgestaltung des Nahzieles war ja bisher auch nicht diskutiert worden und das würde ich im Rahmen dieses Threads auch gar nicht wollen - wie heißt es so schön: Viele Köche verderben den Brei. Aber ein Team von guten Köchen kann sicher schon was bewirken.

Gruß Barnee


----------



## Jochen Kühner (22 Januar 2006)

*sinn / unsinn eines  c compilers...*

Wenn dies alles so unsinnig ist, frage ich mich, warum gibt es auch auf dem pc so viele programmiersprachen???

Wenn ich vor einem problem sitze könnte ich ja auch immer sagen das könnte ich doch auch mit dieser oder jener lösen, warum gibt es die anderen überhaupt noch?? ich denke je mehr auswahl desto besser. es kann ja sein das sich durch einen c compiler mache aufgabe viel einfacher lösen lässt als wie es mit einer der schon vorhandenen funktioniert hätte... 

ich denke man sollte diesen schritt einfach wagen, man muss ihn ja nicht verwenden... und bei den problemen bei denen der einsatz dann sinvoll ist wird er schon verwendet werden...


----------



## Anonymous (22 Januar 2006)

> Wer kennt noch Coros LSB?



So so von Dir war der Kram .....  :shock:   aber war ok  

Ich kenne LSB noch sehr gut weil ich auch schon lange dabei bin.
Wie stellst Du dir den Ablauf vor???


Gruß


----------



## Question_mark (22 Januar 2006)

Hallo,


			
				Lazarus schrieb:
			
		

> Letzter Satz: Zottels Zeigerakrobatik ist trotz allem den möglichkeiten entsprechend sehr sauber und gut verständlich.


Ja, keine Frage. Der Code von Zottel musste nur als Beispiel dafür herhalten, was ich auf einer SPS nicht haben möchte. Und die Kunden, die in der Nachtschicht einen Fehler suchen, bestimmt auch nicht.



			
				Barnee schrieb:
			
		

> Die bisher aufgeführten Nachteile schrecken mich nicht, man kann das eher als Anmerkung registrieren, die möglichen Nachteile abzufangen


Eher Anregung als Anmerkung, dann kann meine negative Kritik letztendlich positiv auf das Projekt wirken.  :lol: 
Aber wie auch schon Lazarus geschrieben hat, den Sinn des Projektes sehe ich zur Zeit noch nicht.



			
				Jochen Kühner schrieb:
			
		

> warum gibt es auch auf dem pc so viele programmiersprachen?



Auf dem PC haben die auch Ihre Berechtigungen. Aber PC und SPS vergleichen ist Äpfel mit Birnen vergleichen.

Gruß
Question_mark


----------



## Barnee (22 Januar 2006)

Jochen Kühner schrieb:
			
		

> Wenn dies alles so unsinnig ist, frage ich mich, warum gibt es auch auf dem pc so viele programmiersprachen???
> 
> Wenn ich vor einem problem sitze könnte ich ja auch immer sagen das könnte ich doch auch mit dieser oder jener lösen, warum gibt es die anderen überhaupt noch?? ich denke je mehr auswahl desto besser. es kann ja sein das sich durch einen c compiler mache aufgabe viel einfacher lösen lässt als wie es mit einer der schon vorhandenen funktioniert hätte...
> 
> ich denke man sollte diesen schritt einfach wagen, man muss ihn ja nicht verwenden... und bei den problemen bei denen der einsatz dann sinvoll ist wird er schon verwendet werden...



Die Welt außerhalb von S5/S7 ist nicht so propietär, deshalb gibt es dort auch viele Wege, die man beschreiten kann, wobei die Wahl der Mittel sich trotzdem immer nach dem Zwecke richten sollte. Ob nun Pascal, C oder C++ um nur weniges zu nennen, entspricht der Entwicklung auf diesem Sektor. In der Windoof-Welt ist man aber schon wieder dabei, sich von BG einnorden zu lassen, ohne dem Microsoft Foundation Club geht da fast nix mehr und dreimal darf man raten auf welcher Basis die Siemens-OPC-Server funktionieren. Für viele Bitbumser bleibt fast gar nichts anders mehr übrig, als sich dem Diktat zu beugen.

Es gibt ein paar Dinge, die man in SCL nicht machen kann, die aber in AWL sehr wohl sauber und sicher ausformuliert werden können. Das ist z.B. ein Antrieb, um über andere Lösungen nachzudenken. Die Tatsache, das AWL nicht totzuschweigen ist und das AWL Sprachelemente aus C verwendet, ist ein weiterer Antrieb für mich. Was mich außerdem ärgert, ist die Konstanten-Schreibweise in SCL, die sich doch erheblich von den Pascal-Syntaxregeln unterscheidet (ich erwarte schon den Einwand der S7-Puristen).




			
				ohGott schrieb:
			
		

> > Wer kennt noch Coros LSB?
> 
> 
> 
> ...



Wenn du Interesse hast, dann melde dich an und schreib mir eine PN. Ich habe bis zum jetzigen Zeitpunkt (Wochenende) noch nicht mit einer solchen Resonanz gerechnet. Diskussionen um das Thema werden wir demokratisch in einem Team in einer privaten Atmosphäre führen.


Gruß Barnee


----------



## Gerhard Bäurle (22 Januar 2006)

Hallo,

hat für die S5 schon mal jemand versucht, es gab dazu
ein Buch vom Franzis-Verlag:

Maschinensteuerung mit dem PC. Steuerungsaufgaben der SPS erfolgreich mit dem PC realisieren. 
Autor: HOFER, Johannes, 
ISBN 3772348211.
Gibt es wohl nur noch im Antiquariat.

Hat damals aber eher weniger Leute interessiert.

Viele Grüße

Gerhard Bäurle


----------



## arcis (22 Januar 2006)

*+*



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



Beinhaltet das auch die Standard C Library?  Wobei ich nur die in diesem Zusammenhang sinnvollen Teile meine. Unter sinnvoll verstehe ich z.B.  alles, was in <math.h> zu finden ist.


----------



## afk (23 Januar 2006)

Question_mark schrieb:
			
		

> Hallo,
> 
> 
> 
> ...


Der Code von Zottel wurde schon in mehreren Threads als Beispiel für die "schrecklichen Zustände" in C herangezogen. Das Problem ist nur, das die Quellen von libnodave dafür gar kein gutes Beispiel sind, da sich Zottel meines Erachtens nach an die "guten Sitten" beim Programmieren gehalten hat.  Meine Erfahrungen mit C/C++ habe ich vor 14+ Jahren gesammelt, seitdem rosten sie vor sich hin. Trotzdem komme ich mit Zottels Code sehr gut zurecht !  

Das Problem, das viele mit C haben (ich auch), ist doch, das C fast alles schluckt, was es vorgesetzt bekommt, und manche Programmierer dementsprechend unleserlichen Code schreiben. Nur ist das im Grunde genommen ja kein Fehler von C, sondern der dieser Programmierer. Der Fehler von C ist nur, das es solche Exzesse überhaupt erlaubt.

Ich sehe daher die Akzeptanz von C als Programmiersprache in der SPS auch kritisch, aber wer weiß, auf dem PC ist C ja auch trotz der beschriebenen Probleme wohl die am meisten verbreitete Sprache.

Gruß Axel


----------



## Boxy (23 Januar 2006)

Hallo Leute,

also für spezielle Funktionen könnte ich mir auch vorstellen diese lieber in C oder VB zu programmieren als in AWL!
Wenn in z.B. in "C" übersichtlich programmiert wird, so kann der Code einfacher und schneller gelesen werden als in AWL. 

Ich kenne nun nicht die Arbeitsgebiete der meisten Leute hier am Board, unser Gebiet ist der Sondermaschinenbau (Tranferstraße, Bearbeitungszentren, Montagelinien usw.). Hier wird heute sehr viel Fremdapplikationen wie Videoüberwachung, Mobby uvm. und auch Verwaltungstechnische Aufgaben in der PLC abgehandelt. 
Z.B. eine Paletten oder Werkzeugverwaltung in einem Bearbeitungszentrum. 
Diese Dinge in C zu Programmieren währe teils sehr hilfreich, da wenn z.B. ProTool Pro eingesetzt wird, dort teils auch mit C teilen in den Bildern gearbeitet wird.

Wenn das "Know-How" sitzt, kann der Kunde auch einen AWL oder FUP Baustein anschauen. Ein Kunde oder das Servicpersonal muß auch nicht in allen Bausteinen änderungen vornehmen. Es beschwert sich auch keiner, das z.B. bei ner NCU57x.x im Grundprogramm oder bei Hi-Graph oder bei TL2000 Bausteine gesperrt sind. ALso kann der Hersteller auch Bausteine mit Know-How sperren. 

Sicherlich war früher die Nachfrage an C für für Step7 nicht so groß, aber die Möglichkeiten, Funktionen sowie Anforderungen sind in den letzten Jahre auch sehr gewachsen. Von der anderen Seite, ist es für Siemens auch nicht so einfach auf verschiedene Ebenen zu Entwickeln. Man merkt dies sehr stark, wenn man mal die versch. Engenieering Tools von Siemens zusammen verwendet. Dies ist bei Projekten in der Automobil-Industrie ja immer der Fall, da kommen die Projekthandbücher von A&D Siemens und am Anfang gibst sehr oft Probleme mit der Kombination der einzelnen Tools!


----------



## Anonymous (23 Januar 2006)

*Großes Interesse*

Hallo

@Barnee

Bei uns ist dieses Thema auch schon öfters diskutiert worden, denn es gäbe schon einige Fälle, bei denen man einen Algorithmus portieren möchte, in denen ein C-nach-AWL-Umsetzer sehr viel Arbeit abnehmen würde.

Die Frage ist jetzt wie Ernst die Sache schon ist und auf welche Basis man aufbaut. GCC wäre da durchaus auch eine denkbare Möglichkeit. Das Problem wird aber das Debuggen!

Gruß

Longbow


----------



## Zottel (23 Januar 2006)

Question_mark schrieb:
			
		

> Hallo,
> Der Code von Zottel musste nur als Beispiel dafür herhalten, was ich auf einer SPS nicht haben möchte. Und die Kunden, die in der Nachtschicht einen Fehler suchen, bestimmt auch nicht.


Die Hauptanwendung sähe ich darin, einfache Aufgaben aus der allgemeinen Informatik zu portieren. Ich erinnere mich, hier mal Code für den Bubblesort-Algorithmus gepostet zu haben. In S7-AWL, weill das der gemeinsame Nenner mit dem Anfragenden war. Das sieht schon ziemlichich schrecklich aus und im Vergleich zu "richtigen" Programmiersprachen ist es eine Zumutung, Array-Indizes zu Fuß berechnen zu müssen.
Wenn ihr euch AWL-Code anschaut, in dem dann noch ein bischen mit den Adressregistern hantiert wird, steht er schlechtem C-Code an Unübersichtlichkeit nicht nach.
Natürlich gehen diese DInge auch mit SCL ganz ordentlich, aber SCL ist nun mal eine Zusatzoption, was häufig dazu führt, daß der Wartungsmann entweder kein SCL hat oder die SCL-Quellen nicht hat oder kein SCL kann.
Wenn der C-Compiler frei verfügbar wäre, fiele wenigstens die erste Hürde weg und die zweite könnte er mit etwas Interesse überwinden. Außerdem gibt es umfangreiche Sammlungen von Beispielcode für so etwas in C (oder Fortran), aber kaum in SCL.
Insgesamt sehe ich so ein Projekt positiv.
Zwei "Spezialitäten" der SPS sollten berücksichtigt werden:
1. Daß sie Maschinenbefehle zur Manipulation von Bits hat (hat ein 8051 auch, also mal bei Keil-C gucken).
2. Daß Schleifen variabler Länge die Echtzeitfähigkeit jedes Codes zunichte machen. Die S7 bietet die Möglichkeit, derartigen Code in einen OB zur Hintergrundbearbeitung zu packen.  

Bezüglich vorhandener open source C-Compiler: GCC ist mehr für 32-Bit-Architekturen gemacht. Die S7 kann zwar 32-Bit-Arithmetik, aber der knappe Speicher wird besser  byteweise belegt. Daher schau dir mal den SDCC an, ein C-Compiler für diverse Mikrocontroller. Dem bräuchte man nur ein neues back end (Code-Generator) hinzuzufügen, wenn mich nicht irre.


----------



## Barnee (23 Januar 2006)

arcis schrieb:
			
		

> > ....*Die Ausrichtung zu C sollte alle in C üblichen Methoden beinhalten, sofern dies entsprechend den Adressierungsmöglichkeiten der S7 durchführbar wäre.*
> 
> 
> 
> Beinhaltet das auch die Standard C Library?  Wobei ich nur die in diesem Zusammenhang sinnvollen Teile meine. Unter sinnvoll verstehe ich z.B.  alles, was in <math.h> zu finden ist.



Bitte um etwas Vorsicht bei solchen Vorhaben. Eine Library hat immer eine Bindung an den Prozessor für die der Code-Generator entwickelt wurde. Eine stdio-Lib für einen x86 läuft sicher nicht auf einem PowerPC, wenn diese nicht explizit für den PowerPC erstellt wurde. Unser Prozessor ist ein Etwas, das nur MC7-Code versteht, um es mal salopp auszudrücken. So denke ich mir, das sich nicht die Frage stellt, ob existierende Standard-Libs verwendbar wären. Meine (unsere) Standard-Libs sind die existierenden SFB's und SFC's, die allesamt nur STEP7 verstehen.

@deltalogic
Nee, 'tschuldigung is nich ganz mein Thema. Ich will nicht eine PLC auf einem PC realisieren, das gibt's ja schon..



			
				afk schrieb:
			
		

> Question_mark schrieb:
> 
> 
> 
> ...



Leider habe ich bisher noch keinen Einblick in Zottel's Quellcode von "libnodave" genommen, um mir hier meine eigenes Urteil bilden zu können. Wenn aber *afk* von der Einhaltung der guten Sitten spricht, was gäbe es dann noch daran auszusetzen? Ich finde man sollte nicht alles in Topf werfen, um danach "igitt" zu rufen. Ich nehme mal an, dass *afk* weiss wovon er spricht, so zeigt doch Diskussion auf, dass bisher zu viel in die von mir vorgetragene Idee hinein interpretiert worden ist.

Ein Beispiel eines schlechten Programmierstils in SCL habe ich hier:

```
IF (Cond_Enable AND 16#0001)= TRUE THEN

    C1 := TRUE;

ELSE

    C1 := FALSE;

END_IF;



IF SHR(IN:=(Cond_Enable AND 16#0002),N:=1)= TRUE THEN

    C2 := TRUE;

ELSE

    C2 := FALSE;

END_IF;
```
Das lässt sich in ZWEI Zeilen verpacken ohne an Informationsgehalt zu verlieren:

```
C1 := (Cond_Enable AND 16#0001) <> 0;
C2 := (Cond_Enable AND 16#0002) <> 0;
```
Wie man sieht, ist die Angst vor unübersichtlichen Code nicht nur auf C beschränkt, man kann schlechten Programmierstil in jeder Programmiersprache üben, wenn man es nicht besser weiss. In "richtigem" Pascal würden die Zeilen übrigens so aussehen:

```
C1 := (Cond_Enable AND $1) <> 0;
C2 := (Cond_Enable AND $2) <> 0;
```
In C würden die beiden Zeilen so aussehen:

```
C1 = (Cond_Enable & 0x1) != 0;
C2 = (Cond_Enable & 0x2) != 0;
```



			
				Boxy schrieb:
			
		

> Hallo Leute,
> also für spezielle Funktionen könnte ich mir auch vorstellen diese lieber in C oder VB zu programmieren als in AWL!
> Wenn in z.B. in "C" übersichtlich programmiert wird, so kann der Code einfacher und schneller gelesen werden als in AWL.


Das trifft genau meine Beweggründe!



			
				Longbow schrieb:
			
		

> Hallo
> 
> @Barnee
> 
> ...



Ja, wie ich sehe, stehe ich mit meinen Gedanken zu dieser Idee nicht alleine.
Mir ist die Sache schon ernst, auch wenn ich das ganze vorerst einmal vor einem sportiven Hintergrund sehe. Wer mitmachen will, kann sich bei mir via PN melden, ich gehe davon aus, in dieser Woche ein Team bilden zu können. Alles weitere auf einem privaten Kanal.

Gruß Barnee

PS. Ist das normal, dass das Forum am Sonntagnachmittag immer Offline geht?


----------



## Barnee (23 Januar 2006)

*C-Compiler für S7, wer macht mit?*

Hallo @
Die Anzahl der Beiträge wie auch die Anzahl der Zugriffe (616 z.Zt.) bestätigen mir, dass ich mit meinem Vortrag der Idee (auch wenn sie nicht neu ist) doch bei einigen Forumsbesuchern offene Türen einrennen konnte.

Es haben sich einige Interessierte bei mir gemeldet, die bereit sind, in einem Team ein solches Projekt gemeinsam zu realisieren. Dafür danke ich erst einmal an dieser Stelle. Aus Gründen der Fairness halte ich das Angebot zum Mitmachen noch bis Mittwochabend offen. Spätere Meldungen können ggf. noch berücksichtigt werden, wir wollen jedoch die Beteiligung in einer überschaubaren Größe halten. Ich werde ab diesem Termin ein Zusammentreffen realisieren, auf welcher Basis das geschehen soll, werden wir zwischenzeitlich intern klären.

Die Meldung zum Mitmachen sollte über PN erfolgen.

Gruß Barnee


----------



## volker (24 Januar 2006)

Barnee schrieb:
			
		

> ```
> C1 := (Cond_Enable AND 16#0001) <> 0;
> C2 := (Cond_Enable AND 16#0002) <> 0;
> ```



sehr interessant zu wissen.
wir haben hier auch eine maschine die in scl programmiert ist und die haben das 'in dem schlechten code' gemacht.
als ich das gesehen habe hab ich mich auch gefragt, was für aufwand den ich in awl mit einem U = erschlagen kann.

aber woher weiss man dass das auch viel besser geht.

ich hab hier vor einiger zeit schon mal gefragt ob es nicht ein brauchbares referenzbuch über scl gibt. leider ohne ergebnis,   

oben angesprochenen maschine wurde auch mit c geschrieben.
die haben einen compiler geschrieben der aus dem c-code einen scl-code macht. ist zwar ein umweg aber leichter zu realisieren wie direkt von c nach awl. (soweit ich das beurteilen kann).

der generierte awl-code ist natürlich grauenerregend wie alle von scl compilierten quellen.

EDIT:
der erzeugte awl-code von der guten variante sieht übrigens auch viel besser aus:  :wink: 
nur für c1.
den sinn vom L0.3 kann ich aber nicht nachvollziehen.

schlecht:

```
SET   
      SAVE  
      =     L      0.3
      U     #TEMP0
      SPBN  M001
      SET   
      =     #TEMP1
      SPA   M002
M001: CLR   
      =     #TEMP1
M002: CLR   
      U     L      0.3
      SAVE  
      BE
```
gut

```
SET   
      SAVE  
      =     L      0.3
      U     #TEMP0
      =     #TEMP1
      U     L      0.3
      SAVE  
      BE
```
am besten. von hand   

```
U     #TEMP0
      =     #TEMP1
      BE
```


----------



## Barnee (24 Januar 2006)

*VKE und BIE*

@Volker


```
SET   
      SAVE 
      =     L      0.3
      U     #TEMP0
      =     #TEMP1
      U     L      0.3
      SAVE 
      BE
```

Das ist ganz einfach (und in dem speziellen Falle fast nur Blödsinn):

SET, setzt am Anfang der Bearbeitung das VKE auf eins;

SAVE, sichert das aktuelle (!!!!!) VKE in das BIE-Bit des Statuswortes;

= L 0.3, offensichtlich existieren noch drei weitere (lokale) Variablen vom Typ BOOL in der Funktion, daher "erfindet" der Compiler eine 4. lokale Variable - L 0.3 - und sichert das VKE vor der Ausführung weiterer Operationen ab.

Die nachfolgenden Operationen beeinflussen das VKE, statt der o.g. Verknüpfung könnte auch z.B. ein Bausteinaufruf stehen. Bei einem Fehler, der bei der Ausführung des aufgerufenen Bausteins auftreten könnte, wird dies im BIE-Bit dieses Bausteins vermerkt (wenn Fehler, dann ist das BIE-Bit auf NULL gesetzt), das BIE-Bit bestimmt die Valenz des ENO-Ausgangs des aufgerufenen Bausteins, das dann UNMITTELBAR nach dem Aufruf im aufrufenden Baustein abgefragt werden kann.

U L 0.3, klar, ist hier in dem Beispiel eh auf 1 - kann aber bei einem andern Sachverhalt zwischenzeitlich beeinflusst worden sein - setzt das VKE.

SAVE, sichert das VKE abschließend in das BIE-Flag, das wiederum beim Verlassen dieser Funktion den eigenen ENO-Ausgang beeinflusst.

Was du also hier siehst, ist nur der Rahmen, den ein Compiler generell anlegt. in dem o.g. Beispiel ist dieser (fast) überflüssig. Wenn keine Fehler bei der Bearbeitung zu erwarten sind, sollte das BIE-Bit immer korrekt gesetzt sein, es könnte ja jemand versuchen den ENO-Ausgang der Funktion auszuwerten!


Gruß Barnee


----------

