Gedanken zum C Compiler

seeba

Level-1
Beiträge
1.867
Reaktionspunkte
62
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo liebe Mitwirkenden,
ich habe mir mal ein paar Gedanken zu den Rahmenfunktionen gemacht:

Natürlich sollte er erstmal C zu AWL- oder besser MC7-Code "compilieren" können.
Ein Problem dürfte das Debugging werden, welches aber schon möglich sein sollte. Wenn sich das ganze etwas in den SIMATIC Manager integrieren könnte, wäre ganz schön, allerdings kenne ich die APIs nicht. Haltepunkte und Einzelschritte wären schon 'ne tolle Sache, aber ich frage mich gerade, wie man das am bestens umsetzt.
Soll das ganze ein Windows Programm werden, oder noch mehr Plattformen unterstützen? Ich denke Windows wäre ausreichen, da es sowieso keinen SIMATIC Manager unter Linux oder so gibt.

Gruß Sebastian
 
seeba schrieb:
Natürlich sollte er erstmal C zu AWL- oder besser MC7-Code "compilieren" können.
Hier ist die Frage der Umsetzung. Wer von uns hat Erfahrung mit Compilerbau, Syntaxbäumen und dem Ganzen darumherum. Ansonsten bleibt uns nur in erster Fassung ein 1:1-Übersetzer. Beim ProSys hatten wir das Ganze auch. Allerdings ist der damalige Entwickler (Informatiker) mittlerweile direkt bei 3S.

seeba schrieb:
Ein Problem dürfte das Debugging werden, welches aber schon möglich sein sollte. Wenn sich das ganze etwas in den SIMATIC Manager integrieren könnte, wäre ganz schön, allerdings kenne ich die APIs nicht. Haltepunkte und Einzelschritte wären schon 'ne tolle Sache, aber ich frage mich gerade, wie man das am bestens umsetzt.
Der Status zu Zeiten unseres ProSys erfolgte auf Basis von Variablenstatus. Ein entsprechende Programmstatus mit Haltepunkte etc. war nicht möglich. Meine Kenntnisse des Simatic-Managers reichen momentan auch nicht aus, um ihn um diverse Programme zu erweitern. Habe allerdings auch noch nicht gebohrt. Eine Integration in unser S7-PG (ok, es bekomt noch Hardwarekonfig etc.) ist da einfacher möglich. Auch können wir den erzeugten Code direkt in ein originales Step7-Projekt einfügen.

seeba schrieb:
Soll das ganze ein Windows Programm werden, oder noch mehr Plattformen unterstützen? Ich denke Windows wäre ausreichen, da es sowieso keinen SIMATIC Manager unter Linux oder so gibt.
Das ist jetzt eine Glaubensfrage. Aber unter Linux wird es eher schwierig. Ich würde vorschlagen, dass wir mit Windows anfangen und Linux soweit möglich nicht sofort ausschließen. Aber zuerst müssen wir die Grundlagen schaffen.
Momentan untersuchen wir bei uns qt in der Version 4.1, da wir einige portable Applikationen benötigen. Mal sehen wie das voran geht.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Den Compiler könnte man als reine Konsolen Anwendung programmieren. Ließe sich auch besser auf andere Systeme portieren.
Bei dem Debugger sehe ich so meine Probleme mit Breakpoint. Man kann ja nicht sie SPS so einfach stehen lassen wenn sich irgendwo etwas bewegt.
Ein Debugger wie in SCL auf Variablenstatus währe aber schon möglich.
Um Portable zu sein währe qt eine Möglichkeit. Gibt es auch als Freeware.

Gruß Zbynek
 
Speedy schrieb:
Den Compiler könnte man als reine Konsolen Anwendung programmieren. Ließe sich auch besser auf andere Systeme portieren.
Bei dem Debugger sehe ich so meine Probleme mit Breakpoint. Man kann ja nicht sie SPS so einfach stehen lassen wenn sich irgendwo etwas bewegt.
Ein Debugger wie in SCL auf Variablenstatus währe aber schon möglich.
Um Portable zu sein währe qt eine Möglichkeit. Gibt es auch als Freeware.

Gruß Zbynek

Also bei SCL kann ich Breakpoints setzen?
 
Beim SCL kann man keine Breakpoints setzen.
Ein Debugger wie in Visual Studio kann man für ein SPS Projekt nicht gebrauchen. Die Steuerung muss zum jedem Zeitpunkt weiter laufen.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Speedy schrieb:
Um Portable zu sein währe qt eine Möglichkeit. Gibt es auch als Freeware.
Gibt es als GPL. Nur wenn alles was damit erstellt wurde auch der GPL unterliegt, also Open Source ist, dann darf diese Version verwendet werden. Bei Open Source bin ich allerdings etwas zugeknöpfter, da ich in das Projekt etwas von dem bei uns über Jahre erarbeiteten KnowKnow einbringen würde. Und das sollte nicht jeder für lau bekommen, denn mit etwas muss ich meine Brötchen ja auch verdienen :wink:
Die Frage ist sowieso noch, was wir mit dem Teilchen wollen. Zeigen dass wir (vielleicht) gut sind oder Geld verdienen?
 
Rainer Hönle schrieb:
Zeigen dass wir (vielleicht) gut sind oder Geld verdienen?

Beides...? ;)

Wir könnten den Code allerdings auch mit libnodave auf die SPS bringen.

Ich hab schon Breakpoints gesetzt. Da kann mir keiner was erzählen!
 
seeba schrieb:
Ich hab schon Breakpoints gesetzt. Da kann mir keiner was erzählen!
Natürlich kann die S7 je nach Steuerung Breakpoints und Einzelschrittbearbeitung in beschränkter Anzahl. Dieser Testbetrieb ist nur für die normale Umgebung/Produktion suboptimal da wirklich der Prozess stehen bleibt. Um logische Programmierprobleme zu entdecken steht ja PLCSim oder ACCONtrol :wink: zur Verfügung.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Rainer Hönle schrieb:
seeba schrieb:
Ich hab schon Breakpoints gesetzt. Da kann mir keiner was erzählen!
Natürlich kann die S7 je nach Steuerung Breakpoints und Einzelschrittbearbeitung in beschränkter Anzahl. Dieser Testbetrieb ist nur für die normale Umgebung/Produktion suboptimal da wirklich der Prozess stehen bleibt. Um logische Programmierprobleme zu entdecken steht ja PLCSim oder ACCONtrol :wink: zur Verfügung.

Ja Haltepunkte setzt man ja auch nur für Debugging... Die sollten im normalen Betrieb nicht mehr im Programm sein. ;)
 
Den Debugger würde ich erstmal nach hinten schieben.
Wir müssen erstmal etwas zum debuggen haben.

Ich habe mir z. B. beim WinCC mit dem Standart Debugger von Visual Studio geholfen.

Gruß Zbynek
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Speedy schrieb:
Den Debugger würde ich erstmal nach hinten schieben.
Wir müssen erstmal etwas zum debuggen haben.

Ich habe mir z. B. beim WinCC mit dem Standart Debugger von Visual Studio geholfen.

Gruß Zbynek

Klar brauch man den nicht sofort, aber man sollte ihn vorsehen!
 
Speedy schrieb:
Den Debugger würde ich erstmal nach hinten schieben.
Wir müssen erstmal etwas zum debuggen haben.
Vollkommen richtig. Nur grundsätzlich beim Thema debuggen: was einen wirklich interessiert sind doch die Zustände der Variablen an bestimmten Programmstellen. Und das bekommen wir mit einem Status auf den Quellcode gemappt auch hin. Wichtig ist dabei allerdings, dass der Zustand der Variable beim Durchlaufen der Programmzeile angezeigt wird. Weiter unten könnte sie ja verändert werden. Da hilft nur Status Bausteine (@seeba: noch nicht Bestandteil von libnodave :wink: ).

@barnee:
Wie wollen wir die ganze Sache angehen? Soll jeder seine Vorstellungen sammeln und zu Papier (äh Mail) bringen?

@alle:
Wer hat welche Vorkenntnisse die für das Schreiben eines Compilers nützlich sind? Stichwort Lex und Yacc und all so ein Informatikergedöns.
In welcher Programmiersprache wollen wir den C-Compiler schreiben (ich weiss, komische Frage)? Brauchen oder wollen wir einen Editor dazu? Wenn ja, was soll der alles unterstützen? Welche C-Funktionen sind für den Anfang wichtig? ...

Mein Vorschlag: Jeder schreibt seine Fragen und Ansichten zusammen. Dann haben wir mal eine erste Diskussions-Grundlage.
 
Das fetzt ja schon richtig...

Hallo und einen Guten Abend allseits.
Ich bin gerade erst aus dem Büro gekommen und wie ich sehe, ist die Diskussion schon richtig in Fahrt gekommen :)

Supa, doa san mir joa richtig z'sammen :)

Ich werd heute noch etwas Nachtschicht einlegen und mir alle Beiträge ansehen. Ein Diskussionspapier hab ich in Stichworten schon fertig. Ich werde versuchen, auf die verschiedenen Punkte schon mal einzugehen. Laßt mir ein wenig Zeit. Mein Vorschlag ist, erst einmal einen formalen Fahrplan zu erstellen/zu diskutieren, der Fahrplan soll vermeiden, dass wir unsere Resourcen vergeuden und damit den Spaß an der Sache verlieren.

Rainer hat schon einen wichtigen Punkt angesprochen. Es geht dabei um die rechtliche Situation, über die wir uns alle im Klaren sein sollten. Da die Programmierung von SPSen zu 99,8% immer einen kommerziellen Hintergrund hat, sollten wir unsere Arbeit nicht für lau abgeben. Wenn wir es schaffen sollten, den S7-C-Compiler zu erstellen, ist das immerhin ein Wettbewerbsvorteil, den wir für uns reklamieren sollten. Über das wie usw. usf. sollten wir zusammen sprechen.

Alles weitere stelle ich später ins Forum.

Gruß Barnee
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Nachtschicht

Hallo @all

So, jetzt hab ich mir doch glatt 'nen redaktionellen Job angeschafft :oops: :oops: :oops:
Na ja, ich hab's ja auch nicht anders gewollt 8) 8) 8)

Vorweg mal eine Feststellung: Wir wollen GUT sein und wir wollen ggf. auch etwas Geld verdienen! Gut wollen wir deswegen schon sein, weil wir es uns nicht leisten können, etwas schlechteres abzuliefern, als es Siemens manchmal tut. Deswegen alleine müssen wir schon besser sein und dann sind wir auch gut.

Ich arbeite derzeit an einem Projekt einer Sinteranlage (Erzsinterung zur Hochofenbeschickung) für Russland, WinCC, Step7 (neueste Version) mit aufgesetztem CFC (vergleichbar mit PCS7, aber eben eine etwas preiswertere Ausführung). Zeitweilig schlage ich mich mit dem CFC herum und mit dem, was der Compiler dabei so hinterlässt! Dort gibt es eine Möglichkeit einen CFC-Plan als FB zu übersetzen. Aber oh Graus, bei der Nachbearbeitung in SCL kann man den Code locker auf ca. 30% kürzen, ohne dass dabei der Informationsgehalt auch nur um ein einziges Bit geringer wird. Bei einer Nachbearbeitung in AWL sind dann noch einmal gute 20% an Optimierung möglich. Ich denke, wir haben ein gutes Potential, einen guten Compiler hinzubekommen, wenn man nicht die gleichen Fehler wie Siemens macht.

Womit fangen wir an?

seeba schrieb:
.... Natürlich sollte er erstmal C zu AWL- oder besser MC7-Code "compilieren" können.
Klar doch, das ist doch unser Thema. Doch wie weiter unten auch schon bemerkt wird, sollten wir mit dem einfachsten beginnen. Wir sollten uns den Weg zum Erfolg nicht zu schwierig gestalten. In meinem Diskussionspapier werde ich versuchen einen Weg aufzuzeigen, den wir gehen sollten.

Rainer Hönle schrieb:
Speedy schrieb:
Den Debugger würde ich erstmal nach hinten schieben.
Wir müssen erstmal etwas zum debuggen haben.
Vollkommen richtig.
Ja richtig bemerkt, bis jetzt ist ja nur der Wunsch der Vater aller Gedanken. Und aus unseren Wünschen sollten Gelüste werden. Das wird dann der Fall sein, wenn wir erste kleine Erfolge vorweisen können, das wird dann der Fall sein, wenn wir die ersten kleinen Schritte machen.

Rainer Hönle schrieb:
@barnee:
Wie wollen wir die ganze Sache angehen? Soll jeder seine Vorstellungen sammeln und zu Papier (äh Mail) bringen?
Wir sollten erst einmal das von mir vorgestellte Diskussionspapier zerfetzen. Jeder ist aufgerufen, seine Meinung dazu zu äußern und seinen Beitrag dazu zu machen. Ich hab mir zwar den redaktionellen Teil an den Hals geschafft :ROFLMAO: werde aber aktiv mitarbeiten. Wir sollten Beschlüsse gemeinschaftlich fassen, d.h. ich werde mich dem demokratischen Prinzip unterordnen und werde aber zu moderieren versuchen, damit für alle ein Erfolg gesichert ist.

Welche Plattformen?

seeba schrieb:
...Soll das ganze ein Windows Programm werden, oder noch mehr Plattformen unterstützen? Ich denke Windows wäre ausreichen, da es sowieso keinen SIMATIC Manager unter Linux oder so gibt.....
Rainer Hönle schrieb:
...Das ist jetzt eine Glaubensfrage. Aber unter Linux wird es eher schwierig. Ich würde vorschlagen, dass wir mit Windows anfangen und Linux soweit möglich nicht sofort ausschließen. Aber zuerst müssen wir die Grundlagen schaffen.
Momentan untersuchen wir bei uns qt in der Version 4.1, da wir einige portable Applikationen benötigen. Mal sehen wie das voran geht.....
Nach meiner Ansicht stellt sich für den Augenblick nicht die Frage nach den Plattformen, zumindest nicht direkt. In meinem Diskussionspapier habe ich einmal grob eine Unterteilung in verschiedene Entwicklungsstufen vorgenommen sowie eine weitere Unterteilung in verschiedene Teilprojekte. Der Kern des Compilers sollte portierbar sein. Es ist mir schon klar, dass der S7-C-Compiler schlussendlich in seiner Gesamtheit nur auf einer Windoof-Kiste laufen wird. Aber...

Aber nach meiner Ansicht hängt es von den verschiedenen Arbeitsmethoden des Einzelnen ab, auf welcher Plattform eine Step7-Bausteinentwicklung stattfindet. Meine Arbeitsweise findet nicht auf der Basis von Try&Error statt, sondern ich code meine Projekte meist zu 98% fertig, bevor ich ans testen denke. Seit einiger Zeit hat ja nun Siemens auch mal ans menschliche gedacht und ASCII-Schnittstellen für den Quellenaustausch geschaffen. Man möge mir die Bezeichnung "Windoof" verzeihen aber in meinem privaten Bereich arbeite ich auf Mac unter UNIX und da ist die Editieroberfläche eines Texteditors 10 mal besser als das was BG mit Microschrott bzw. Siemens zu bieten hat. Aber das soll uns hier nicht in zwei Lager spalten.

Daher meine Meinung: Soweit wie möglich sollte eine Unabhängigkeit von Plattformen doch schon erreicht werden. Daher sollte MFC nur dort eingesetzt werden, wo es wegen HMI auf Windowkisten unumgänglich ist. Aber das sollten wir später noch im Detail diskutieren.

Compilerbau
Rainer Hönle schrieb:
....Hier ist die Frage der Umsetzung. Wer von uns hat Erfahrung mit Compilerbau, Syntaxbäumen und dem Ganzen darumherum. Ansonsten bleibt uns nur in erster Fassung ein 1:1-Übersetzer....
Speedy schrieb:
....Den Compiler könnte man als reine Konsolen Anwendung programmieren. Ließe sich auch besser auf andere Systeme portieren.....
Auch hier verweise ich auf mein Diskussionspapier weiter unten. Compilerbau ist nicht so schwierig, wie es den Anschein hat. Man kann den eigentlichen Compiler in verschiedene Teile (Prozessoren) zerlegen.

Nach meiner Ansicht ist das der wichtigste Diskussionspunkt überhaupt, um den wir uns zu allererst kümmern sollten.

Der Preprozessor und der Parser bedingen nach meiner Ansicht eine Menge vorarbeiten, die uns sicher keiner abnehmen wird. Denn der Gedanke, C-Programmierung von Step7-Bausteinen vornehmen zu wollen, orientiert sich m.E. nach dem, was mit dem MC7-Befehlsvorat realisiert werden kann. Anders als bei einem "richtigen" C-Compiler haben wir ja keinen direkten Zugriff auf den uP, sondern MC7 ist ja selbst ein Interpreter. Wir können also von den Methoden in C nur das übernehmen, was somit auch in MC7 umgesetzt werden kann. Somit sind üblich Libraries wie stdio, math usw.usf. sicher nicht so ohne weiteres anwendbar. Aber lasst uns später darüber diskutieren.

Debugging
seeba schrieb:
....Ein Problem dürfte das Debugging werden, welches aber schon möglich sein sollte. Wenn sich das ganze etwas in den SIMATIC Manager integrieren könnte, wäre ganz schön, allerdings kenne ich die APIs nicht. Haltepunkte und Einzelschritte wären schon 'ne tolle Sache, aber ich frage mich gerade, wie man das am bestens umsetzt....
Rainer Hönle schrieb:
Der Status zu Zeiten unseres ProSys erfolgte auf Basis von Variablenstatus. Ein entsprechende Programmstatus mit Haltepunkte etc. war nicht möglich. Meine Kenntnisse des Simatic-Managers reichen momentan auch nicht aus, um ihn um diverse Programme zu erweitern. Habe allerdings auch noch nicht gebohrt. Eine Integration in unser S7-PG (ok, es bekomt noch Hardwarekonfig etc.) ist da einfacher möglich. Auch können wir den erzeugten Code direkt in ein originales Step7-Projekt einfügen.
Speedy schrieb:
...Den Debugger würde ich erstmal nach hinten schieben.
Wir müssen erstmal etwas zum debuggen haben....
Ich schließe mich da Speedy an. Zwar sollten wird den Gedanken nicht zu weit nach hinten schieben, sonst geht später irgendwann das Gefrikel los, um den Debugger in das Projekt einzubauen. An entsprechende Schnittstellen sollten wir schon denken. Wir sollten uns also schon Gedanken machen, welche Anforderungen ein Debugger erfüllen sollte.

Freeware
Rainer Hönle schrieb:
Speedy schrieb:
Um Portable zu sein währe qt eine Möglichkeit. Gibt es auch als Freeware.
Gibt es als GPL. Nur wenn alles was damit erstellt wurde auch der GPL unterliegt, also Open Source ist, dann darf diese Version verwendet werden. Bei Open Source bin ich allerdings etwas zugeknöpfter, da ich in das Projekt etwas von dem bei uns über Jahre erarbeiteten KnowKnow einbringen würde. Und das sollte nicht jeder für lau bekommen, denn mit etwas muss ich meine Brötchen ja auch verdienen :wink:
Die Frage ist sowieso noch, was wir mit dem Teilchen wollen. Zeigen dass wir (vielleicht) gut sind oder Geld verdienen?
Hier gebe ich Rainer vollkommen recht. Und darüber sollten wir uns im klaren sein. Auch jetzt schon! Wir werden ein paar Nahziele haben. Und auch diese Erfolge sollten wir nicht für lau aus der Hand geben. Selbst, wenn in dem SIMATIC-Forum unter meinem Thread teilweise mit gegensätzlicher Meinung argumentiert wurde, wird sicher ein Potential für einen S7-C-Compiler vorhanden sein. Einschränkend wird man sagen können, dass den S7-C-Compiler nicht jeder SPS-Programmierer anwenden wird, muß ja auch nicht jeder, einfache Bitbumserei kann man auch auf herkömmliche Art und Weise erzeugen. Aber in Bereichen, die ich z.B. bestens kenne, gibt es eine Vielzahl von Anwendungsmöglichkeiten. Mit den Nahzielen wird auch schon das Fernziel definiert, das heißt wir wollen versuchen, den S7-C-Compiler in den S7-Manager einzubinden. Ob und das gelingen könnte, werden wir untersuchen müssen.

Diskussionspapier
Ich stelle mir mehrere Entwicklungsstufen vor:

Stufe 1: nimmt Textdateien mit C-Code an und übersetzt in AWL (ASCII)
Stufe 2: Editor mit Syntax-Highlightning
Stufe 3: Erweiterung des Code-Generator für die Umsetzung nach MC7
Stufe 4: Einbindung in den Simatic-Manager
Stufe 5: Debugger

Die Stufe 1 wäre somit unser erstes Nahziel. Mit dem Erreichen dieser Stufe hätten wir schon etwas, was man in der tägliche Arbeit anwenden könnte. Und wir könnten schon mal im SIMATIC-Forum etwas strunzen gehen :ROFLMAO: :ROFLMAO: :ROFLMAO: :ROFLMAO:
Doch hier liegt schon der Teufel im Detail. Wir müssen uns schon hier Gedanken machen, welche Sprachmittel von C übernommen werden können. Das ist ein Thema für AWL-Spezialisten, ich schließe mich da ein, die Machbarkeit der Umsetzung zu prüfen, d.h. was ist in C adäquat zu AWL, das gilt es zu prüfen. Ich kenne verschiedene Beispiele aus der Umsetzung von SCL nach MC7, die sind m.E. grauenvoll. Aber das werden wir noch diskutieren.

Die Stufe 2 sorgt schon für Komfort. Der Editor soll die C-Sprachmittel unterstützen. Ich habe hier auf dem Mac einen Editor, der schon etwas besonders ist. Vergleichsweise gibt es für Windows den Ultraedit, der auch nicht schlecht ist. Wir sollten uns z.B. auch überlegen, wie wir die Step7-Symbollisten vom Editor aus anwenden können. Selbstverständlich sollte der Editor auch Suchfunktionen beinhalten usw.usf. In der Diskussion um dieses Thema sind keine Schranken gesetzt, jeder konstruktive Beitrag ist willkommen.

In der Stufe 3 sollte es wahlweise möglich sein, je nach Anforderung MC7-Code zu erzeugen, oder auch AWL, oder auch beides. Spätestens zu diesem Zeitpunkt sollten wird geklärt haben, wie wir eine Integration in den S7-Manager herstellen können (Stufe 4). Denn in einem Projekt, das z.B. mit CFC gemacht wird, wäre es sinnvoll, mit dieser Integration aufwarten zu können. Man kann zwar auch AWL-Bausteine in ein CFC-Projekt über die ASCII-Schnitstelle integrieren. Aber der direkte Weg wäre eleganter und überzeugender.

Die Stufe 4 sollte die Einbindung in den S7-Manager darstellen. Ich weiß nicht, ob es ein Klacks ist oder ob es völlig unmöglich ist. Hier sind Leute gefragt, die vielleicht wissen, an welcher Stelle man bei Siemens bohren müsste. Zu S5-Zeiten hätte ich eine Lösung aus dem Ärmel geschüttelt aber das ist ja nicht mehr :cry: :cry: :cry: :cry: :cry:

In der Stufe 5 kommen wir endlich zu dem Debugger. Ich hab zur Zeit keinen Plan, wie man da vorgehen sollte. Es klang ja schon an, das man eine SPS eigentlich nicht anhalten kann. Ggf. sollte man überlegen, wie man die verfügbaren S7-Simulationen anwenden könnte. Ein anderer Gedanke wäre, eine eigene Simulation zu betreiben. MC7 ist ja im Prinzip kein direkt ausführbarer Code, d.h. wir könnten selbst einen Simulator erstellen, der unseren mit dem S7-C-Compiler erzeugten MC7-Code interpretiert.

Wenn ich bisher die Projektstufen vorgestellt habe, so darf nicht vergessen werden, dass das Projekt selbstverständlich aus verschiedenen Teilprojekten besteht. Ich stelle die Teilprojekte hier nur kurz vor, ohne dabei allzusehr in die Tiefe zu gehen:

Teil 1: Preprozessor
Teil 2: Parser
Teil 3: Code-Generator nach AWL
Teil 4: Editor
Teil 5: Code-Generator nach MC7
Teil 6: Debugger, ggf mit Simulator

Die Teilprojekte 1...3 fallen in die Stufe 1.

Unter einem Preprozessor verstehe ich einen Prozess, mit dem die C-Quelle erst einmal formgerecht auf Vordermann gebracht wird und erste Syntaxfehler erkannt werden. Makros müssen ebenfalls dort umgesetzt werden. Es müssen Listen erstellt werden mit Verweisen auf den Original-Quelltext, um gezielte Compilermeldungen absetzen zu können. Der unspezifische Hinweis, dass ein Fehler vorhanden ist, reicht m.E. nicht aus, die Fehlerausschriften des GNU-Compilers sollten mindestens unser Vorbild sein.

Der Parser fahndet nach Konstrukten, die mit C-Sprachmittel erstellt wurden. Er erstellt erste Listen mit Verweisen auf das Produkt des Preprozessors und löst C-Konstrukte auf. Der Parser ist die Vorstufe zum Code-Generator.

Der Code-Generator nach AWL besagt mit seinem Namen schon alles was er machen soll. Er erzeugt eine Textdatei, die mit "Bordmitteln" schon in die Step7-Umgebung eingebunden werden kann.

Alle bisher vorgestellten Teilprojekte sollten portierbar sein. D.h. hier verbietet sich m.E. der Einsatz von MFC, da dies propietäres Zeugs von BG ist. Es dürfte sicher keine Schwierigkeit sein, in C++ eigene Klassen zu entwerfen, die Plattform übergreifend portiert werden können. Das Wenige was an HMI notwendig ist, sollte über eine Schnittstelle auf diesen Kern zugreifen, so dass man für andere Plattformen, das notwendige HMI anpassen kann.

Der Editor besteht nach m.E. auch aus mehreren Teilen. Hier müßte noch fleißig diskutiert werden. Zumindest sollte der Kern des Editors auch nicht mit MFC erzeugt werden (gilt Gleiches wie bei den ersten drei Teilprojekten). Das HMI hängt natürlich wieder von der Plattform ab, aber auch hier sollte das über eine neutrale Schnittstelle geschehen.

Der Code-Generator nach MC7, ja das dürfte in dieseer Phase des Projektes eine einfache Sache sein. Wenn es da nicht eine z.Zt. unbekannte Größe gäbe: die Einbindung in den S7-Manager! Klar, das dieser teil des Code-Generator auf den dann bereits vorhandenen AWL-Code-Generator aufsetzt und somit MFC sicher nicht notwendig ist.

Der Debugger ist ein weites Feld für Diskussionen. Gibt es eine Möglichkeit direkt auf der S7-CPU zu arbeiten? Wenn nicht, könnte ich mir auch einen Simulator vorstellen, der außerhalb der CPU auf dem PC läuft. Macht man einen solchen Simulator von der CPU unabhängig, so sollte die Simulation auch unabhängig von der Plattform sein.


Der rechtlichen Seite des Projektes widme ich hier vorab ein paar Gedanken. Es dürfte wohl klar sein, das in den wenigsten Fällen jemand eine SPS zum ausschließlichen Spielvergnügen programmiert, sondern das es aus kommerziellem Antrieb erfolgt. Wenn in dem Laufe des Projektes kommerzielle Produkte einfließen, dann hat derjenige, der es beisteuert, ein Recht darauf, das dies nicht zum Vorteil von Dritten gerät. Wir werden daher ernsthaft über dieses Thema reden müssen. Ich für meinen Teil sehe dieses Projekt unter einem sportlichen Gesichtspunkt, was aber trotzdem heißt, dass ich mein Wissen ebenfalls nur im Kreise dieses Teams unentgeltlich angewendet wissen will, die Weitergabe an Dritte behandle ich ebenso wie ein Tabu. Unter Dritte verstehe ich jedweden, der sich außerhalb dieses Teams befindet.

Wir sollten die Vorschläge diskutieren und uns entsprechend dem Ergebnis in Arbeitsgruppen aufteilen. Für jede Arbeitsgruppe/Thema machen wir dann einen Thread auf, so dass die Themen nicht so wild durch einander gehen.

Noch was zu C++. Ich selbst bin im C mehr zu hause als im C++, hab aber das dicke Buch von Bjarne Stroustrup (alter Schwede) schon unter meinem Kopfkissen liegen :ROFLMAO: :ROFLMAO: :ROFLMAO: :ROFLMAO:

So das war's für heute - Nachtschicht beendet 8) 8) 8)


Gruß Barnee
 
Guten Morgen zusammen,

für den Teil Code-Generator nach MC7 kann ich einiges beisteuern, d.h. der Punkt kann als erledigt geklennzeichnet werden. Ebenfalls das Schreiben der erzeugten Bausteine in ein originales Siemens-Projekt.
Der Zugriff auf die Symbolik ist ebenfalls gelöst, wenn es unter Windoof geschieht. Grund: Innerhalb der Projekte sind u.a. auch die Namen der wieteren Dateien und Datenbanken enthalten. Und so wie ich meine Freunde bei Siemens kenne, schreiben die Dateinamen in der Datenbank nicht unbedingt so wie beim Datei anlegen (Groß-Kleinschreibung). Damit haben wir natürlich unter Linux dann Probleme. ACHTUNG: Das ist vorerst meine Vermutung bzw. Befürchtung (resultierend aus langer Erfahrung), noch keine verifizierte Tatsache.
Das Thema Simulation/Debuggen können wir auch mit unserem ACCONtrol angehen. Dort habe ich wenigstens etwas Einflussmöglichkeiten auf die Features die dort eingebaut werden :wink: Vom Prinzip her ist ACCONtrol eine CPU416 auf dem PC. Ist ebenfalls portabel geschrieben und existiert in verschiedenen Varianten, von der Simulation bis hin zur harten Echtzeitlösung basierend auf CEWin von Kuka. Auch die Debug-Möglichkeiten (Status Bausteine) sind bei uns im Hause vorhanden und müssen somit nicht erneut erfunden bzw. analysiert und entwickelt werden.
Soweit zu den Dingen die wir beisteuern können.
Aus Erfahrungen mit anderen Gemeinschaftsentwicklungen bin ich der Meinung, dass wir uns vor einem richtigen Projektstart über die rechtliche Seite einig sein müssen. Wenn nachher ein gutes Projekt deshalb scheitert, wel sich jeder dabei etwas anderes gedacht hat, wäre das schade.
Als nächstes kommt dann die technische Definition. Was soll das Ganz umfassen, welchen Sprachumfang, was ist überhaupt auf S7 umsetzbar (Anm.: printf über Textausgabe z.B. an CP340 o.ä. :lol: :?: ). Für die Realisierung bevorzuge ich eindeutig C++. Die Kapselung und Wiederverwertbarkeit der Klassen (wenn einigermassen sauber implementiert) ist ein klarer Vorteil für die Aufgabe.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Moin allseits

War ne kurze Nacht für mich. Wollte heute morgen gar nicht so recht entscheiden, ob ich meine Augenlider heben sollte oder nicht. war fast eine Nor/Nand/Xor-Entscheidung :ROFLMAO:

Rainer hat den wichtigen Punkt schon angesprochen:

Rainer Hönle schrieb:
Aus Erfahrungen mit anderen Gemeinschaftsentwicklungen bin ich der Meinung, dass wir uns vor einem richtigen Projektstart über die rechtliche Seite einig sein müssen. Wenn nachher ein gutes Projekt deshalb scheitert, wel sich jeder dabei etwas anderes gedacht hat, wäre das schade.

Wir sollten versuchen ein persönliches Treffen zu arrangieren, zumindest aber mal eine Audiokonferenz, des wegen nochmals meine Frage in die Runde, ob ihr schon was wegen Skype unternommen habt? Technnische Fragen klären wir im Anschluß daran.

Als Initiator dieser Runde, gestatte ich mir vorläufig den Hut aufzuhaben, bin aber gerne bereit, den auch wieder abzugeben, wenn dies ein anderer machen möchte. Ich überlasse dies einer gemeinschaftlichen Entscheidung. Aber ich denke mir, jemand sollte die Fäden in einer Hand halten, sonst geht das Projekt den Bach herunter, bevor es richtig gestartet ist. Was aber nicht heißen soll, das niemand mehr seinen Gedanken freien Lauf lassen sollte. Auch in einem Team gibt es gewisse Spielregeln, sonst kann man sich nicht in Arbeitsgruppen aufteilen. Ich würde daher vorschlagen, daß wir/ich bestimmte Kernfragen formuliere und dann darüber abstimmen.

Deswegen stelle ich hier schon mal die ersten Kernfrage:

Seit ihr damit einverstanden, dass ich vorerst die Projektführung machen soll? Ja/Nein?

Könnt ihr euch mit dem von mir vorgestellten Stufeplan einverstanden erklären? Ja/Nein?

Findet ihr die Unterteilung der Projekt so OK? Ja/Nein?

Bezüglich der rechtlichen Situation würde ich gerne jeden bitten, sich hierüber einmal Gedanken zumachen und sich dazu zu äußern. Ich werde gleiche einen anderen Thread "rechtliche Klärung" aufmachen, wo ihr eure Gedanken nur zu diesem Thema reinschreiben solltet.

Und diesen Punkt sollten wir wirklich zuerst klären.

Gruß Barnee
 
Barnee schrieb:
Seit ihr damit einverstanden, dass ich vorerst die Projektführung machen soll? Ja/Nein?
Ja.

Barnee schrieb:
Könnt ihr euch mit dem von mir vorgestellten Stufeplan einverstanden erklären? Ja/Nein?
Ja.

Barnee schrieb:
Findet ihr die Unterteilung der Projekt so OK? Ja/Nein?
Als Grobstruktur Ja. Muss natürlich in weitere Feinschritte gegliedert werden. Deshalb auch meine Anmerkungen zu dem was als nächstes kommen sollte (ohne Hüte haben zu wollen, ich stehe unter dem Pantoffel, da ein Hut keinen Platz mehr :lol: ). Dies war ein Anfang der Aufteilung von Stufe 1.
 
Zurück
Oben