# Diskussion: SCL Compiler Einschränkungen, Erweiterungen



## rrauch (10 August 2010)

An alle, die mit SCL-Programmierung unter Step7 Erfahrung haben:

Welche Einschränkungen des SCL-Compilers erschweren die tägl. Arbeit und welche Erweiterungen würden auf einer Wunschliste ganz oben stehen?

Grüße


----------



## JesperMP (10 August 2010)

Auf die Schnelle:

Symbolische "Adressen-Picker". So das man nicht Manuell die Symbolische Namen aussuchen muss.

Verlinken von Die Symbolische Namen. Wenn ein Symbol geändert wird, werden die in SCL Code verwendete Symbole automatisch aktualisert.

Wenn man das "OK" bit in SCL Code auswertet, aber die Einstellung "OK Bit setzen" auf irgendeiner Grund ist _nicht_ gesetzt, dann kommt es beim Kompilieren ein Warnmeldung.

Globale Konstanten.
So das man z.B. die Grösse von Arrays nur eine Stelle einstellen muss.

Wenn das Kompilieren scheitert, bessere hinweis worauf die Kompiler meckert.


----------



## dalbi (10 August 2010)

Hi,

http://sps-forum.de/showpost.php?p=227983&postcount=1 

Gruss Daniel


----------



## rrauch (10 August 2010)

Ich dachte bei der Frage eher um Erweiterungen der Sprache SCL, nicht des Bedienkomforts des Editors.
Zum Beispiel könnte ich mir vorstellen, die Verwendbarkeit der Pointer zu erweitern. Ähnlich wie in C/C++ müßte es möglich sein, ein Feld von Funktionspointern zu erstellen, und Funktionen indiziert aufzurufen.

Der Vorschlag von JesperMP zu globalen Konstanten ist auch interessant.


----------



## vierlagig (10 August 2010)

rrauch schrieb:


> Ich dachte bei der Frage eher um Erweiterungen der Sprache SCL, nicht des Bedienkomforts des Editors.
> Zum Beispiel könnte ich mir vorstellen, die Verwendbarkeit der Pointer zu erweitern. Ähnlich wie in C/C++ müßte es möglich sein, ein Feld von Funktionspointern zu erstellen, und Funktionen indiziert aufzurufen.
> 
> Der Vorschlag von JesperMP zu globalen Konstanten ist auch interessant.



Das ist doch Schwachsinn! Die ganze Hochsprachenwelt wendet sich von Pointern ab und Ihr wünscht euch das Dritte Reich zurück.
Weder Visual Basic noch C# kennen Pointer, nicht mal Java - und das bezeichne ich nicht häufig als Programmiersprache - kennt sie.
Warum diesen NonSens nun also in SCL verfügbar machen? Langeweile? Sommerloch? Leere Auftragsbücher?
Es gibt objektiv keinen Sinn! Genauso wie eben in den anderen Hochsprachen!
Und hättet Ihr die scheiß Pointer gebraucht, dann hättet ihr euch die M7 kaufen sollen, aber die wollte auch keiner - nicht mal wegen den Pointern!

Und woher der Blödsinn mit den indizierten Funktionsaufrufen? Ist symbolische Programmierung tatsächlich immer noch kein Begriff?


----------



## vierlagig (10 August 2010)

was dieser SCL-Compiler wirklich braucht ist:
 eine (hardwareunabhängige) F U N K T I O N I E R E N D E Debugfunktion
einen intelisens wie ihn dalbi entworfen hat und
eine vernünftige eigenschaften, aufgaben, beobachten Ansicht

alles andere ist pfeffer und von mir aus kann jeder, der meint die sprache gehört erweitert, dahin gehen wo er wächst

alter...unklar...


----------



## Thomas_v2.1 (10 August 2010)

vierlagig schrieb:


> Das ist doch Schwachsinn! Die ganze Hochsprachenwelt wendet sich von Pointern ab und Ihr wünscht euch das Dritte Reich zurück.
> Weder Visual Basic noch C# kennen Pointer, nicht mal Java - und das bezeichne ich nicht häufig als Programmiersprache - kennt sie.



Achso, und was meinst wie eine Referenz in deinen Sprachen intern abgebildet wird? Ein Pointer ist nunmal eine sehr effektive Variante des Speicherzugriffs. Wenn sich da _alle_ von abwenden, wieso hat man dann die Referenzen eingeführt? Man hätte doch auch alles per Value und Speicherkopiererei machen können.


----------



## vierlagig (10 August 2010)

Thomas_v2.1 schrieb:


> Achso, und was meinst wie eine Referenz in deinen Sprachen intern abgebildet wird? Ein Pointer ist nunmal eine sehr effektive Variante des Speicherzugriffs. Wenn sich da _alle_ von abwenden, wieso hat man dann die Referenzen eingeführt? Man hätte doch auch alles per Value und Speicherkopiererei machen können.



schätzelein, nu passe mal uff. es geht um die implementierung durch den programmierer, also den endanwender, nich um des dahinter. und des dahinter, und da weeß ich sehr genau, dass du des och weeßt arbeitet mit pointerchen, och bei scl. also so nich, mein engelchen!


----------



## Thomas_v2.1 (10 August 2010)

vierlagig schrieb:


> schätzelein, nu passe mal uff. es geht um die implementierung durch den programmierer, also den endanwender, nich um des dahinter. und des dahinter, und da weeß ich sehr genau, dass du des och weeßt arbeitet mit pointerchen, och bei scl. also so nich, mein engelchen!



Warum denn nicht in SCL? In Codesys ST gibt es auch Pointer. Diese umständliche Handhabung des ANY-Pointers in SCL finde ich zumindest alles andere als schön. Und der Siemens Parametertyp POINTER ist ja den Namen nicht Wert.
Aber das ist imho auch dieser bei S7 nicht unbedingt flachen Speicherstruktur mit den Datenbausteinen geschuldet.


----------



## vierlagig (10 August 2010)

Thomas_v2.1 schrieb:


> Warum denn nicht in SCL?



gib mir ein praktisches beispiel wofür du es brauchst und wir diskutieren das aus! mir fällt keins ein!
in awl mit pointern zu operieren ist normal, da es nicht anders geht, da man da nicht bekannt machen kann, was bekannt ist und so eben auch einfach mal drauf los forschen muß, in SCL sehe ich keinen nutzen geschweigedenn einen sinn!


----------



## IBFS (10 August 2010)

ALSO vom hochgelobten 3S will ich hier garnicht weiter ausbreiten.

Ich sag nur TOTDEKLARIEREN!!!!

Ehe da mal was geht - da fehlt die LIB und jene LIB - ist mir Egal.


Der Grund mir damals vor 10 Jahren SCL zu kaufen war, das ich
schön symbolisch auf die DBs zugreifen kann. Ich versuche 
Pointergräber weitesgehend im AWL zu vermeiden.

Ich sach nur:

1. Nich alles wos goil is mussta machen.

2. Ma muss nich ständig seine Pointer als Monstranz vor sich hertragen um zu zeigen, dass man ein toller Programmier ist wenns auch transparenter und einfach geht.

Frank


----------



## bike (10 August 2010)

Also da geht es mir wie den Menschen:
Warum etwas nehmen, das nicht nötig ist?
In den ganzen Hochsprachen sind Pointer für den Entwickler nicht immer sinnvoll oder nötig., es ist cool, Pointer zu verwenden, damit man in einem Jahr bestimmt nicht mehr weiß was man selbst programmiert hat.

Doch in einer PLC? Die soll eigentlich nur richtig steuern. Je mehr in die Dinger geschaufelt wird, um so fehleranfällig wird das Ergebnis. Das gilt für Programm und Betriebssystem.

Was der Compiler hinter der Entwicklungsumgebung macht ist mir, um ganz ehrlich zu sein, egal.

SCL ist so eine Entwicklung, die nach meiner Meinung begonnen wurde, ohne, dass an das Ziel gedacht wurde. 
Es war schick, C zu implemtieren, es wurde ein schmales Pascal daraus und glücklich wird man damit wohl eher weniger.
Daten Dinge schreibe ich schon lange nur in SCL, da ja Schleifen und ähnliches besser zu schreiben und zu verstehen sind.(Solange man den AWL Code nicht anschaut   )

bike


----------



## Chefmech (10 August 2010)

Was ich mir am meisten wünsche was die Sprache an sich betrifft:

- Dynamische Speicherverwaltung, zb. Array deklaration mit einer Variable (Glob. Konstante) anstatt mit einem Zahlenwert.
Wird aber wahrscheinlich von der HW-Architektur der CPU's nicht möglich sein :-(

- Make-Dateien sollten in anderen Make-Dateien aufrufbar sein. So könnte ich eine Make-Datei für jede SW-Komponente und einen Make-All Datei haben ohne immer in beiden anpassen zu müssen.

- Gobale Konstanten wären natürlich generell Schön


----------



## Larry Laffer (11 August 2010)

@Thomas:
du solltest nicht die Adressierung "byRef" mit Pointern verwechseln - es ist zwar richtig, dass hier unterschwllig mit einem solchen gearbeitet wird aber wirklich, da gebe ich meinen Vorrednern Recht : vordergründig hatte ich dafür noch keinen Anwendungsfall.

@TE:
- den Workflow von SCL generell zu verbessern halte ich für einen guten Ansatz (siehe z.B. das Beispiel von Dalbi).
- Darüber hinaus fände ich es schön, wenn es einen Pendant zum VB-Befehl WITH gäbe. Das könnte auch helfen, dass der Compiler den AWL-Spagetticode etwas sauberer gestalten könnte. Wenn ich viel mit Strukturen oder/und Array's arbeite so werden fast alle Variablenzugriffe (im AWL-Code) über Pointer gehandelt wobei der Pointer für jede variable neu errechnet wird - wozu ?
- Ich bin schon oft darüber gestoplert, dass sich FB's, SFB's etc. nicht in Strukturen integrieren lassen - gut das kann AWL auch nicht - aber warum eigentlich nicht ? Gleiches gilt für Array's ...
- AT-Sicht ist eine schöne Sache. Warum kann ich aber z.B. keine solche auf eine Gruppe von IN-Parametern machen ?

Gruß
Larry


----------



## rrauch (11 August 2010)

*Anwendungsfälle für Pointer*

also zum Thema Pointer (speziell Pointer auf FCs bzw FBs) hätte ich schon sinnvolle Anwendungsmöglichkeiten.

1. Beispiele: Programmieren einer Zustandmaschine:
Oft programmiert man hierfür eine ellenlange CASE Anweisung. Intern erzeugt der Compiler für jeden Fall eine Bedingung mit Sprung, was ja nicht besonders effektiv ist. Viel effektiver wäre es, ich könnte ein Feld von Pointern auf Funktionen anlegen und mit dem Status der Zustandsmaschine indiziert die Funktionen aufrufen:

```
nextstate := fkttab[state](par,...);
```
ähnliches wäre auch sinnvoll für Protokollhandler, Meldungsverarbeitung usw.

2. Beispiel
Ich hatte mal eine Jalousiensteuerung programmiert. Für jede Jalousie habe ich eine Instanz eines Kontroll-FBs angelegt. Jeden Instanzaufruf musste ich einzeln programmieren. Ich hätte mir viel Schreibarbeit gespart, wenn ich z.b. folgendes hätte schreiben können:


```
FOR  i := 0 TO JAL_ANZ DO
   JAL_CTRL[i](T_UP := %E[i,0], T_DN:= %E[i,1], M_DN := %A[i,1],...);
END_FOR;
```


----------



## IBFS (11 August 2010)

rrauch schrieb:


> 2. Beispiel
> Ich hatte mal eine Jalousiensteuerung programmiert.


 
Auch wenns etwas OT ist.  Für eine Jalousiensteuerung nimmt man KNX. Da muss man nur "etwas" parametrieren und das wars. (man muss nicht für alles und jedes eine SPS nehmen)  

Frank


----------



## rrauch (11 August 2010)

IBFS schrieb:


> Auch wenns etwas OT ist. Für eine Jalousiensteuerung nimmt man KNX. Da muss man nur "etwas" parametrieren und das wars. (man muss nicht für alles und jedes eine SPS nehmen)
> 
> Frank


 
bzw. es reichen doch zwei Taster (Einer für AUF und Einer für ZU) ;-)

also, meine Jalousiensteuerung kann etwas mehr (Sonnenaufgang u. Untergang berechnen, Sonnenstand berechnen, beim Beschatten die Lammellen jeder Jalousie entsprechend Ihrer Himmelsrichtung so stellen, daß max. Tageslicht einfällt, aber kein direktes Sonnenlicht)....astronomische Formeln und etwas Geometrie muß die Steuerung schon rechnen.


----------



## Perfektionist (11 August 2010)

rrauch schrieb:


> 1. Beispiele: Programmieren einer Zustandmaschine:
> Oft programmiert man hierfür eine ellenlange CASE Anweisung. Intern erzeugt der Compiler für jeden Fall eine Bedingung mit Sprung, was ja nicht besonders effektiv ist. Viel effektiver wäre es, ...


wenn der Compiler erkennen könnte, dass der Programmierer in AWL hier gerne eine SPL-Liste erzeugt haben wollte. Allerdings haben Zustandsnummern auch schon wieder den Nachteil, keinerlei Symbol darzustellen.



rrauch schrieb:


> Ich hätte mir viel Schreibarbeit gespart, ...


das ist in meinen Augen aber auch nur ein schwacher Grund.


----------



## IBFS (11 August 2010)

rrauch schrieb:


> also, meine Jalousiensteuerung kann etwas mehr (Sonnenaufgang u. Untergang berechnen, Sonnenstand berechnen, beim Beschatten die Lammellen jeder Jalousie entsprechend Ihrer Himmelsrichtung so stellen, daß max. Tageslicht einfällt, aber kein direktes Sonnenlicht)....astronomische Formeln und etwas Geometrie muß die Steuerung schon rechnen.


 
Das gibt es ALLES schon fertig zu kaufen.

http://www.bms-solutions.de/produkte.asp?productKategorieID=9

http://www.elsner-elektronik.de/knx...roducts_pi1[product_uid]=307&cHash=d8be17a7af

http://knx-user-forum.de/knx-eib-fo...terzentrale-257-21-a.html?highlight=suntracer

Ich programmiere auch sehr gerne SPSen, aber für manches
sind mir zugekaufte fertige Lösungen lieber.

Grüße

Frank


----------



## rrauch (11 August 2010)

IBFS schrieb:


> Das gibt es ALLES schon fertig zu kaufen.
> 
> ...
> Ich programmiere auch sehr gerne SPSen, aber für manches
> ...


 
das könnte man ja in einem weiteren thread ausdiskutieren...


----------



## IBFS (11 August 2010)

@rrauch
wollte eigentlich ne PN schreiben - egal.


SCL:

Ja das Hauptproblem bei SCL ist, das im Hintergrund 
keine "Vorinterpretierung" stattfindet. Dadurch ist SCL nix 
weiter als ein Texteditor mit NACHGESCHALTETEM Compiler. 

Das läßt sich im bestehenden System m.E. nicht so ohne weiters 
ändern. Die Diskussion ist sowieso auch hinfällig, weil die 
komplette INDISCHE PROGRAMMIERERTRUPPE nur noch am 
Portal herumexperimentiert. Da bleibt einfach keine Zeit
an einem 15-20 Jahre altem System herumzuändern.
Das Thema Abwärtskompatibilität ist in dem Zusammenhang
auch zu beachten. 

Frank


----------



## rrauch (11 August 2010)

IBFS;275280 
...Die Diskussion ist sowieso auch hinfällig schrieb:
			
		

> ich habe das Thema gestartet, weil ich aktuell an einem SCL-Compiler arbeite...natürlich nicht für den Simatic Manager, sonder für ein anderes Programmierpacket. Der Compiler ist also eine Neuentwicklung und daher
> besteht die Möglichkeit für Erweiterungen.


----------



## corrado (11 August 2010)

Um auf dieanfängliche Frage zurückzukommen:
Mich stören in SCL vor allem die notwendigen Typwandlungen. Ein einfacher casting-operator wie in C bzw. Ansi-C wuerde einiges erleichtern und auch lesbarer machen.

Gruss Corrado


----------



## Perfektionist (11 August 2010)

rrauch schrieb:


> ...natürlich nicht für den Simatic Manager, sonder für ein anderes Programmierpacket.


dann könnte man das aus dem Bereich "Simatic" raus- und bei "sonstige Steuerungen" reinschieben?


----------



## IBFS (11 August 2010)

rrauch schrieb:


> ich habe das Thema gestartet, weil ich aktuell an einem SCL-Compiler arbeite...natürlich nicht für den Simatic Manager, sonder für ein anderes Programmierpacket. Der Compiler ist also eine Neuentwicklung und daher besteht die Möglichkeit für Erweiterungen.


 
Dann schreibe das doch in deinen 1. Beitrag rein!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Dann bekommt du ganz andere Anworten, wenn man nicht so am SCL festgetackert ist.

Wenn das nämlich so ist, dann müßte ich sagen:

3S-ST und SCL ist KEIN gutes Bespiel.
Allen Bradley sieht auf den ersten Bilck ganz gut aus,
weil die verwendeten Varablen (ob Interne oder Extene) sofort
einen TOOLTIP haben in eine Wellenlinie unterlegt wird wenn der Code nicht korrekt ist.

Gruß

Frank


----------



## rrauch (11 August 2010)

Perfektionist schrieb:


> dann könnte man das aus dem Bereich "Simatic" raus- und bei "sonstige Steuerungen" reinschieben?


 
falsch...es geht um Step7-Steuerungen und deren Programmierung, nicht um Codesys/IEC1131 o.ä.


----------



## IBFS (11 August 2010)

rrauch schrieb:


> falsch...es geht um Step7-Steuerungen und deren Programmierung, nicht um Codesys/IEC1131 o.ä.


 
Du eierst ganz schön rum hier 

Ich vermute mal du bist INDER und weißt nicht weiter *ROFL*

Es wäre schon für alle hier hilftreich zu wissen, welche 
Einschränkungen exsistieren. Muß alles auf dem MC7-Code
und den darausfolgenden Einschränkungen basieren oder nicht.

Frank


P.S.   gerade noch gelesen   [Ort: Nürnberg]      verdächtig, verdächtig


----------



## rrauch (11 August 2010)

corrado schrieb:


> Um auf dieanfängliche Frage zurückzukommen:
> Mich stören in SCL vor allem die notwendigen Typwandlungen. Ein einfacher casting-operator wie in C bzw. Ansi-C wuerde einiges erleichtern und auch lesbarer machen.
> 
> Gruss Corrado


 
ich habe vorgesehen, dass es optional nur eine Warnung gibt, wenn im Anwenderprogramm die Typwandlung nicht explizit angegeben wurde...ähnlich wie bei C, wenn man den casting-operator nicht angegeben hat.


----------



## Blockmove (11 August 2010)

IBFS schrieb:


> P.S. gerade noch gelesen [Ort: Nürnberg] verdächtig, verdächtig


 
Wieder einer von der "fränkischen SPS-Mafia" *ACK*


----------



## rrauch (11 August 2010)

IBFS schrieb:


> Du eierst ganz schön rum hier
> Ich vermute mal du bist INDER und weißt nicht weiter *ROFL*
> P.S. gerade noch gelesen [Ort: Nürnberg] verdächtig, verdächtig


 
zu meiner Person...auf meiner Homepage unter http://www.itrgmbh.de/de/companieshistory gibt es genügend Informationen über mich; die Produkte, die ich entwickelt habe, sind hier im Forum auch den meisten Leuten bekannt!


IBFS schrieb:


> Es wäre schon für alle hier hilftreich zu wissen, welche
> Einschränkungen exsistieren. Muß alles auf dem MC7-Code
> und den darausfolgenden Einschränkungen basieren oder nicht.


Grundlage ist der MC7-Befehlssatz, der Compiler-Output muß auf allen Step7 Steuerungen (und kompatiblen) lauffähig sein


----------



## rostiger Nagel (11 August 2010)

rrauch schrieb:


> gibt es genügend Informationen über mich; die Produkte, die ich entwickelt habe, sind hier im Forum auch den meisten Leuten bekannt!


 
...und hast du dich dafür schon endschuldigt?


----------



## rrauch (11 August 2010)

Helmut_von_der_Reparatur schrieb:


> ...und hast du dich dafür schon endschuldigt?


bei wem... bei Siemens? ;-)


----------



## rostiger Nagel (11 August 2010)

rrauch schrieb:


> bei wem... bei Siemens? ;-)


 
hi hi,

Also Richard wie habe ich mir das den Vorzustellen mit deinen Editor,
soll der als Addon in Stimatic Manager laufen, ist der Autark oder
baust du funktionen ein wie es der Daniel gemacht hat.

Hast du überhaubt schon etwas fertig, das du mal etwas zeigen kannst?


----------



## LowLevelMahn (11 August 2010)

*...hört sich Interessant an*

hört sich Interessant an, wenigstens jemand der Versucht die Entwicklungs-Tool Monogami (ein wenige) aufzubrechen 
auch wenn die SCL-Pointer-Diskussion ein wenig aus dem Ruder gelaufen ist

gibts es mehr Projektdetails zum nachlesen? Wie soll die Toolchain aussehen - hoch integriert in eine IDE? oder eher so Komponentenenweise als Kompiler, Linker usw.

MfG der Kompilerbauinteressierte LowLevelMahn...


----------



## rrauch (11 August 2010)

Details zum Produkt/Termin möchte ich (noch) nicht nennen! Das überlasse ich meinem Auftraggeber. Es hat aber nichts mit dem Simatic Manager von Siemens zu tun.

zurück zum Thema...soviele Wünsche sind ja noch nicht zusammengekommen. Entweder sind die meisten relativ zufrieden mit dem SCL Compiler von Siemens oder es arbeitet kaum jemand mit SCL.
Für mich persönlich ist SCL oft der einzige Weg, eine SPS zu programmieren. Mit AWL würde ich wahnsinnig werden...ich kenne zwar *jeden* AWL-Befehl, kann aber damit trotzdem keine sinnvollen SPS-Programme schreiben!


----------



## Perfektionist (11 August 2010)

rrauch schrieb:


> ...ich kenne zwar *jeden* AWL-Befehl, kann aber damit trotzdem keine sinnvollen SPS-Programme schreiben!


Hast Du schonmal Deinen Lebenslauf gelesen? Dort steht bei "besondere Kenntnisse und Fertigkeiten":





> Assembler für versch. Prozessorfamilien


----------



## rrauch (11 August 2010)

Perfektionist schrieb:


> Hast Du schonmal Deinen Lebenslauf gelesen? Dort steht bei "besondere Kenntnisse und Fertigkeiten":
> Zitat:
> Assembler für versch. Prozessorfamilien :


na...klappern gehört zum Handwerk *ROFL*
aber wer würde ernsthaft *A*n*w*eisungs*l*iste mit einem ausgewachsenen Assembler z.b. für Intel oder ARM vergleichen?


----------



## BoxHead (11 August 2010)

Ich würde eine an codesys angelehnte ST Variante auch was die Pointer angeht bevorzugen. Bei codesys kann man auch Arrays von Funktionsblöcken anlegen was die halbe Miete bei dem Jalousien Beispiel wäre.

Ein externer SCL Compiler alleine ist aber wenig wert ohne eine IDE wo man online Debuggen kann.


----------



## Larry Laffer (11 August 2010)

rrauch schrieb:


> Details zum Produkt/Termin möchte ich (noch) nicht nennen! Das überlasse ich meinem Auftraggeber.


 
Na ... da bin ich denn mal gespannt ... 

Aber zu dem Thema fällt mir auch noch etwas ein :
- Man kann nicht einfach so eine AT-Sicht auf einen POINTER machen.
- Man kann gar keine AT-Sicht auf den RET_VAL machen.
- Eine Type-Definition muß immer eine UDT sein bzw. wird zu einer solchen. Auch wenn ich sie außerhalb des FB/FC gar nicht benötige. Auch dies müßte der Compiler frei handeln können.
- das mit der Type-Geschichte könnte ich mir auch für Funktionen (oder Prozeduren) vorstellen. Wenn ich in einem Script eine Funktion deklariere, die ich nur in dem Script verwende - warum muß daraus unbedingt ein FC (oder FB) werden ?

Wenn ich noch ein wenig überlege, dann fallen mir sicherlich noch ein paar mehr Sachen ein. Auf der anderen Seite - man bräuchte sich hier eigentlich nur an dem orientieren, was andere Compiler, die es auf dem Markt gibt (z.B. VS) so können. Vieles liesse sich m.E. auch in der Mach-Art heutzutage auch ohne Weiteres in die SPS-Welt übertragen - vorrausgesetzt man lößt sich "ein bißchen" von der typischen Siemens-Denke ...

Gruß
Larry


----------



## rostiger Nagel (11 August 2010)

rrauch schrieb:


> Details zum Produkt/Termin möchte ich (noch) nicht nennen! Das überlasse ich meinem Auftraggeber. Es hat aber nichts mit dem Simatic Manager von Siemens zu tun.
> 
> zurück zum Thema...soviele Wünsche sind ja noch nicht zusammengekommen. Entweder sind die meisten relativ zufrieden mit dem SCL Compiler von Siemens oder es arbeitet kaum jemand mit SCL.
> Für mich persönlich ist SCL oft der einzige Weg, eine SPS zu programmieren. Mit AWL würde ich wahnsinnig werden...ich kenne zwar *jeden* AWL-Befehl, kann aber damit trotzdem keine sinnvollen SPS-Programme schreiben!


 
wenn das ding nicht intregiert arbeitet, ist es für mich eine Totgeburt
und hört eher in den Thread "Fun zum Feierabend"
Aus welchen grund soll mann sich noch verschlechtern. 

Und dann verstehe ich deine ganze vorgehensweise nicht, du rührst hier
indirekt die Werbetrommel (also mit Zeigern auf das zukünftige Produkt und
mit Pointern auf dich selber), in wirklichkeit ist das eine Projektarbeit für einen Kunden.

Was schon mal garnicht geht ist um Mitarbeit betteln aber keine Gegen-
leistung bringen und auf den Auftraggeber verweisen.

Aber die Kollegen aus dem Forum haben das schon gut erkannt was mit
dir los ist....


----------



## IBFS (11 August 2010)

Hier kann mal geschaut werden wie es der selbsternannte Marktführer macht:

Übersich:
http://www.rockwellautomation.de/applications/gs/EMEA/GSDE.nsf/pages/Programmiersprachen


ST-DOKU_Englisch:
http://samplecode.rockwellautomation.com/idc/groups/literature/documents/pm/1756-pm007_-en-p.pdf

ST-DOKU-Deutsch:
http://samplecode.rockwellautomation.com/idc/groups/literature/documents/pm/1756-pm007_-de-p.pdf


Außer dem oben gesagten, will ich mir zurzeit da mal noch kein abschließendes Urteil erlauben.

Frank


P.S.

hier noch was:
http://www.eod.gvsu.edu/~jackh/books/plcs/chapters/plc_st.pdf


----------



## rrauch (11 August 2010)

Helmut_von_der_Reparatur schrieb:


> wenn das ding nicht intregiert arbeitet, ist es für mich eine Totgeburt
> und hört eher in den Thread "Fun zum Feierabend"
> Aus welchen grund soll mann sich noch verschlechtern.
> 
> ...


 
ich wollte nicht die werbetrommel rühren, dafür ist es im moment zu früh, sondern input für echte wünsche von anwendern, die zu diesem zeitpunkt noch berücksichtigt werden können. natürlich wird die lösung auch komfortabel sein, das thema des threads ist ja "erweiterungen" und nicht "einschränkungen".
aber leider wird es in diesem Forum immer mehr Usus, lieber zu polemisieren als technische fragen aufzugreifen...vielleicht ja aufgrund mitteilungsbedürfnis trotz mangelnden fachwissens....
ich habe eigentlich keine lust, auf dieser basis zu diskutieren...ich halte den thread deswegen für gescheitert.... @admin: kann man den irgendwie schliessen?


----------



## IBFS (11 August 2010)

@rr

na nun sei mal nicht gleich eingeschappt.

Hast du denn schon mal in die AB-Dokus reingeschaut.

Ich hätte schon gerne mal eine exotische ST-Implemenation gesehen.

Aber so wie ich das sehe ähnelt sich der Sprachwortschatz doch sehr.
Ich konnte in anderen ST-Fakrikationen nicht großartig anderes finden.

Einzig beim Aufbau des Editors und solchen Helferlein wie Symolikvervollständigung 
und -prüfung LIVE (nicht erst BEIM Übersetzen) trennt sich die Spreu vom Weizen.

Am MC7-Unterbau kannst du ja leider auch nicht ändern.

Frank


----------



## rrauch (11 August 2010)

Larry Laffer schrieb:


> Na ... da bin ich denn mal gespannt ...
> 
> Aber zu dem Thema fällt mir auch noch etwas ein :
> - Man kann nicht einfach so eine AT-Sicht auf einen POINTER machen.
> ...


 
da hat sich dann doch mal jemand gedanken gemacht! ;-)
die lokal gültigen strukturen sind eine gute idee, das müsste auch machbar sein...ich könnte mir dafür ein Schlüsselwort "static" vorstellen!
das mit den lokale bekannten FCs/FBs wäre auch eine gute Idee, aber leider arbeitet der Bausteinaufruf in AWL ( UC ... ) mit einer Bausteinnummer. Was gehen würde, wäre so etwas wie eine Inline-Funktion. Der Code der Inline-Funktion wird direkt in den Baustein eingefügt und muß dann auch nur lokal bekannt sein. So ähnlich arbeiten auch verschiedene interne Funktionen ( wie z.b EXPD() )


----------



## IBFS (11 August 2010)

so wie das klingt, läuft ews darauf hinaus sehr vielen innerhalb
eines SCL-Bausteines zu machen. Dabei muß man natürlich die 
16kByte Grenze beachten. 

Gruß

Frank


----------



## rrauch (11 August 2010)

IBFS schrieb:


> so wie das klingt, läuft ews darauf hinaus sehr vielen innerhalb
> eines SCL-Bausteines zu machen. Dabei muß man natürlich die
> 16kByte Grenze beachten.
> 
> ...


 
Hallo Frank,

16kByte wegen Einschränkungen bei bestimmten CPUs? Oder gibt es noch andere Gründe? Eigentlich kann der Code eines MC7-Baustein 64kB groß sein.


----------



## IBFS (11 August 2010)

rrauch schrieb:


> Hallo Frank,
> 16kByte wegen Einschränkungen bei bestimmten CPUs? Oder gibt es noch andere Gründe? Eigentlich kann der Code eines MC7-Baustein 64kB groß sein.




Hallo RR

16kByte wegen Einschränkungen bei bestimmten CPUs!!!

Das gilt dann sowohl für FCs/FBs als auch für DBs

Gruß

Frank


Speziell die kleineren und älteren CPUs haben oft noch diese Grenze:

Diese  315er kann es:

http://support.automation.siemens.c...tandard&viewreg=WW&objid=33519671&treeLang=dehttp://support.automation.siemens.com/WW/view/de/36816516/td

Das ist aber bei den 315ern noch nicht sollange her , dass die 16er Grenze überwunden ist.
Es ist sowohl Firmware als auch Speichergrößenabhängig.
Auch waren die Nummernbänder für extrem eingeschränkt

Diese kann nur 16kByte:

http://support.automation.siemens.com/WW/view/de/4067858/td


----------



## Perfektionist (11 August 2010)

IBFS schrieb:


> ...
> Diese kann nur 16kByte:
> ...


auf derartige Fossilien würde ich jetzt keine Rücksicht nehmen. Erst die heutigen CPUs lassen mich überhaupt erst an die Verwendung von SCL/ST denken.

Was allerdings auch mir Sorge bereitet: der Abstand von 16kB zu 64kB ist auch aus meiner Sicht nicht groß. Ich habe einmal ein(en) Programm(baustein) in AWL entwickelt, bei dem ich aufgrund der erforderlichen Kapselung auch die Subroutinen darin untergebracht habe (genau wegen dem Problem, weil ja der Aufruf eines FB/FC im Baustein sonst über eine Absolutadresse erforderlich gewesen wäre, was eben der Kapselung entgegen stand). Dieser Baustein wurde auf einer 318 ausgeführt und hatte rund 16kB.

Wenn ich mir vorstelle, das gleiche in SCL/ST zu tun, so kann ich mir vorstellen, dass der Code zur Ausführung auf ein mehrfaches anschwillt. Das wird die 64k-Grenze zwar nicht durchbohren, aber dieser doch recht nahe kommen. Von der Ausführungsgeschwindigkeit her mache ich mir mal weniger Sorgen - es gibt ja inzwischen die 319er.

Damit der Compiler nicht alles in einen Baustein packen muss: wäre es denkbar, als Ziel optional ein Nummernband anzugeben?


----------



## rrauch (12 August 2010)

*SIZEOF usw...*

würde eine Erweiterung wie SIZEOF() Sinn machen? Damit kann man die Größe von Feldern, Strukturen, usw. ermitteln. Dann muß man im Programmteil nicht mit Konstanten arbeiten und die Wartbarkeit des Codes wird besser:
Beispiele:
  size := SIZEOF(feld);
  anzahl_elements := SIZEOF(feld) / SIZEOF(feld[0]); 

oder gibt es das schon? hab zumindest nichts in der Doku gefunden!


----------



## Blockmove (12 August 2010)

rrauch schrieb:


> würde eine Erweiterung wie SIZEOF() Sinn machen?


 
Sehr gute Idee, besonders wenn es bei allen Datentypen klappt (UDT, Structur,...)

Gruß
Dieter


----------



## Larry Laffer (12 August 2010)

Nein ... gibt es nicht und hätte ich auch schon das eine oder andere Mal gebrauchen können.

Was mich hier noch interessieren würde :
Es ist keine fiktive Diskussion hier - in welcher Umgebung findet sich denn der Rauch-SCL-Compiler wieder ? Ist es dann wirklich, wie Helmut schon angedeutet hat, ein Stand-alone-Programm oder integriert es sich in die (schon vorhandene) Entwicklungs-Umgebung ?

Gruß
Larry


----------



## BoxHead (12 August 2010)

rrauch schrieb:


> würde eine Erweiterung wie SIZEOF() Sinn machen?


Ja würde und tut es auch bereits in codesys und TwinCAT. 



> SIZEOF
> Arithmetischer Operator: Diese Funktion ist nicht von der Norm IEC61131-3 vorgeschrieben.
> Als Ergebnis liefert SIZEOF die Anzahl der Bytes, die die angegebene Variable benötigt.
> 
> ...


----------



## JesperMP (12 August 2010)

Beide zu haben wäre nicht schlect.
Globale Compiler-Konstanten werden nur beim Kompilieren verwendet.
SIZEOF wird zum Laufzeit berechnet.
Oder ?


----------



## rrauch (12 August 2010)

JesperMP schrieb:


> Beide zu haben wäre nicht schlect.
> Globale Compiler-Konstanten werden nur beim Kompilieren verwendet.
> SIZEOF wird zum Laufzeit berechnet.
> Oder ?


soweit ich das momentan überblicke, wird sizeof auch zur Compilezeit bestimmt und wie eine Konstante behandelt


----------



## frankenmafia (12 August 2010)

Blockmove schrieb:


> Wieder einer von der "fränkischen SPS-Mafia" *ACK*


 
mal ein spaß am rande...das mit der "fränkischen SPS-Mafia" hat mir gefallen, deswegen habe ich mir hier mal schnell einen zweiten account zugelegt.
in zukunft werde ich unsachliche beiträge  über diesen account beantworten 

gruß von rrauch


----------



## Larry Laffer (12 August 2010)

Larry Laffer schrieb:


> Was mich hier noch interessieren würde :
> Es ist keine fiktive Diskussion hier - in welcher Umgebung findet sich denn der Rauch-SCL-Compiler wieder ? Ist es dann wirklich, wie Helmut schon angedeutet hat, ein Stand-alone-Programm oder integriert es sich in die (schon vorhandene) Entwicklungs-Umgebung ?


 
Ob nun Franken-Mafia oder R.Rauch - wie wäre es mit einer Antwort auf die Frage ...?


----------



## JesperMP (12 August 2010)

rrauch schrieb:


> soweit ich das momentan überblicke, wird sizeof auch zur Compilezeit bestimmt und wie eine Konstante behandelt


Boxhead's Beispiel scheint mir wird zur Laufzeit berechnet.


----------



## rrauch (12 August 2010)

Larry Laffer schrieb:


> Nein ... gibt es nicht und hätte ich auch schon das eine oder andere Mal gebrauchen können.
> 
> Was mich hier noch interessieren würde :
> Es ist keine fiktive Diskussion hier - in welcher Umgebung findet sich denn der Rauch-SCL-Compiler wieder ? Ist es dann wirklich, wie Helmut schon angedeutet hat, ein Stand-alone-Programm oder integriert es sich in die (schon vorhandene) Entwicklungs-Umgebung ?
> ...


es ist keine fiktive Diskussion. Der Compiler wird in einer integrierten Entwicklungsumgebung laufen, die auch den Anspruch an Komfort erfüllt!


----------



## gravieren (12 August 2010)

Hi

Wie sieht das Zeitfenster für das fertige Produkt aus  ?


Was sollte das Produkt kosten  ?



Gruss Karl


----------



## Larry Laffer (13 August 2010)

Gut ... dann spiele ich mal noch ein bißchen mit ...

Da fällt mir dann noch etwas ein :
In AWL kann ich z.B. einem FC einen Datenbaustein als IN-Parameter vom Typ BLOCK_DB übergeben. In dem FC kann ich dann einen FB aufrufen und diesem den genannten DB als Instanz übergeben (das ich hier aufpassen muß, dass die zusammen passen ist klar). 
SCL (und auch Siemens, an die ich dass schon mal angefragt habe) wehrt sich wehement dagegen, das in SCL machen zu können. 
Jedenfalls ... diese Funktion könnte ich häufiger gebrauchen ...

Gruß
Larry


----------



## rrauch (13 August 2010)

Larry Laffer schrieb:


> Gut ... dann spiele ich mal noch ein bißchen mit ...
> 
> Da fällt mir dann noch etwas ein :
> In AWL kann ich z.B. einem FC einen Datenbaustein als IN-Parameter vom Typ BLOCK_DB übergeben. In dem FC kann ich dann einen FB aufrufen und diesem den genannten DB als Instanz übergeben (das ich hier aufpassen muß, dass die zusammen passen ist klar).
> ...


 
könnte ich dazu ein AWL-Beispiel bekommen, wie das genau aussehen sollte? dann kann ich mir Gedanken machen, ob und wie man das in SCL realisieren könnte


----------



## Larry Laffer (13 August 2010)

rrauch schrieb:


> könnte ich dazu ein AWL-Beispiel bekommen, wie das genau aussehen sollte? dann kann ich mir Gedanken machen, ob und wie man das in SCL realisieren könnte


 
na klar ...


----------



## IBFS (13 August 2010)

Larry Laffer schrieb:


> na klar ...


 
@LL
unabh. vom Thema - ich finde die Symbolik mit dem Unterstrich am Anfang recht hübsch. Da sieht man gut die Symbolikstrukturierung.

Frank


----------



## rrauch (26 November 2010)

*aktuelles*

um den Thread etwas wiederzubeleben, kann ich zu dem Entwicklungsthema etwas neues berichten!
da ich häufig gefragt wurde, ob es sich um ein echtes Projekt handelt, hier die Auflösung:
Die Firma MHJ hat die neue Version V5 ihrer Programmiersoftware WinSPS-S7 auf der SPS-Messe vorgestellt. In dieser Entwicklungsumgebung ist auch der diskutierte SCL-Compiler enthalten.
Weitere Informationen findet Ihr unter diesem Link:
http://www.mhj-online.de/de/shop_content.php?coID=27


----------



## LowLevelMahn (26 November 2010)

*gibt es mehr Details?*

Du also für die MHJ-Leuten einen kompletten SCL Kompiler gebaut - sehr schön
auf der Seite sieht man aber leider nicht so viel - gibts mehr Details zu deinem Projektteil?

nur so als Frage nebendrann: 
die genannte Spracherkennung ist wirklich sinnvoll einsetzbar?, hat MHJ Anfragen diesbezüglich gehabt - oder ist das ein Versuch ob Bedarf da ist

MfG LowLevelMahn


----------



## Larry Laffer (26 November 2010)

... ich kann mich dem Beitrag von LowLevelMahn nur anschliessen ... Da würde ich auch sehr gern mehr dazu erfahren ...


----------



## rrauch (26 November 2010)

LowLevelMahn schrieb:


> Du also für die MHJ-Leuten einen kompletten SCL Kompiler gebaut - sehr schön


 
naja, Compilerbau ist ja nicht wirklich anspruchsvoll...eigentlich ist es mehr Fleißarbeit ;-) außerdem habe ich schon Erfahrung in dem Bereich. Mein allererstes Projekt im Rahmen meiner Diplomarbeit war die Mitarbeit an einem C-Compiler für die S5!!! (wen's interessiert, ich hab mal ein PDF angehängt) Das Projekt war zwar wirtschaftlich ein Reinfall, für mich war es aber der Einstieg in die Siemens S5/S7 kompatible Welt . Daraus sind ja dann schließlich ein paar S5/S7 kompatible CPUs entstanden.



LowLevelMahn schrieb:


> auf der Seite sieht man aber leider nicht so viel - gibts mehr Details zu deinem Projektteil?


dazu gibt es noch nicht soviel Show-Material. Die Einbindung in die IDE ist aber recht komfortabel gelungen, da wurden auch einige Vorschläge aus diesem Thread berücksichtigt. Zum SCL Sprachumfang ist zu sagen: Im Moment ist der "Standard"-Sprachumfang vorgesehen, den der Siemens-Compiler unterstützt. Sinnvolle Erweiterungen sind zwar jederzeit möglich, sind bisher aber noch nicht beauftragt worden...



LowLevelMahn schrieb:


> nur so als Frage nebendrann:
> die genannte Spracherkennung ist wirklich sinnvoll einsetzbar?, hat MHJ Anfragen diesbezüglich gehabt - oder ist das ein Versuch ob Bedarf da ist


ich hab es selbst noch nicht ausprobiert...wäre natürlich schon interessant, wenn es zuverlässig funktioniert!


----------



## Thomas_v2.1 (26 November 2010)

rrauch schrieb:


> naja, Compilerbau ist ja nicht wirklich anspruchsvoll...eigentlich ist es mehr Fleißarbeit ;-) außerdem habe ich schon Erfahrung in dem Bereich.



Naja, für einen Informatiker vielleicht nicht anspruchsvoll ;-)
Als Elektrotechniker muss man erstmal lernen wie das mit den formalen Sprachen überhaupt funktioniert, wenn man davor nur entfernt etwas gehört hat (das war vielleicht der Grund warum ich beim ersten Lesen von Gödel, Escher, Bach nicht viel verstanden habe...).
Ich habe mal angefangen so etwas mittels flex/bison umzusetzen (aber nicht weit gekommen), und da muss man ja wenigstens die Grundbegriffe kennen.
Mich würde mal interessieren ob bei MHJ auch auf diese Tools gesetzt wurde, oder ob alles selber ausprogrammiert wurde. Wird dort auch der Zwischenschritt über AWL gemacht, oder direkt MC7-Code generiert?



rrauch schrieb:


> Mein allererstes Projekt im Rahmen meiner Diplomarbeit war die Mitarbeit an einem C-Compiler für die S5!!! (wen's interessiert, ich hab mal ein PDF angehängt) Das Projekt war zwar wirtschaftlich ein Reinfall, für mich war es aber der Einstieg in die Siemens S5/S7 kompatible Welt . Daraus sind ja dann schließlich ein paar S5/S7 kompatible CPUs entstanden.


Ich habe immer nach Dokumentationen zu diesem S5 C-Compiler gesucht, aber nie gefunden. Auf der Siemens Seite sind keine Handbücher mehr zu finden. Hast du da noch mehr Informationen zu? Vielleicht ein paar Code-Beispiele? Mich interessiert vor allem wie die Parameterübergabe, Rückgabewerte usw. umgesetzt wurde.


----------



## Jochen Kühner (26 November 2010)

Thomas_v2.1 schrieb:


> Wird dort auch der Zwischenschritt über AWL gemacht, oder direkt MC7-Code generiert?



AWL kann man doch in dieser hinsicht nicht wirklich als zwischenschritt bezeichnen, der AWL code entspricht ja direkt dem Maschinencode, nur anderst dargestellt (ok ausser bei den calls) oder seh ich das fallsch?


----------



## Thomas_v2.1 (26 November 2010)

Jochen Kühner schrieb:


> AWL kann man doch in dieser hinsicht nicht wirklich als zwischenschritt bezeichnen, der AWL code entspricht ja direkt dem Maschinencode, nur anderst dargestellt (ok ausser bei den calls)


Ja, das meine ich ja. Funktionsaufrufe, Parameterübergaben, Zugriff auf Strukturen/UDT und den ganzen Krams...da ist AWL eben nicht MC7.


----------



## Superkater (26 November 2010)

*SCL Wünsche*

1.  Die Deklaration von Konstanten, sollte mit dem Einbinden einer externen Datei möglich sein (ähnlich eine Headerdatei in C).
2.  Der Siemens Compiler müsste im RAM arbeiten und nicht auf der Festplatte. Jetzt übersetzt der Compiler in einer VM um den Faktor 10 schneller als im XP SP3.
3.  Man sollte Namen im gesamten Projekt suchen können.
4.  Man sollte seinen eigenen Editor verwenden können.
5.  Die Größe der definierten Arrays kann jetzt nur mit Konstanten deklariert werden. Das sollte verbessert werden.
6.  Bei Datenkonvertierungen auf kleinere Typen wie z.B. Word auf Byte sollten Warnungen ausgegeben werden (sollte schaltbar gemacht werden).


----------



## rrauch (26 November 2010)

Thomas_v2.1 schrieb:


> Ich habe mal angefangen so etwas mittels flex/bison umzusetzen (aber nicht weit gekommen), und da muss man ja wenigstens die Grundbegriffe kennen.
> Mich würde mal interessieren ob bei MHJ auch auf diese Tools gesetzt wurde, oder ob alles selber ausprogrammiert wurde. Wird dort auch der Zwischenschritt über AWL gemacht, oder direkt MC7-Code generiert?


also, flex und bison nehmen einen viel arbeit ab. Auf diese Tools kann man auf jeden fall setzen; allerdings muß man die Theorie dahinter verstehen (lexikalische, syntaktische Analyse)...trotzdem muß man darüber hinaus noch viel programmieren, bis mal ein Compiler-Output rauskommt. Der ist im übrigen wirklich AWL!



Thomas_v2.1 schrieb:


> Ich habe immer nach Dokumentationen zu diesem S5 C-Compiler gesucht, aber nie gefunden. Auf der Siemens Seite sind keine Handbücher mehr zu finden. Hast du da noch mehr Informationen zu? Vielleicht ein paar Code-Beispiele? Mich interessiert vor allem wie die Parameterübergabe, Rückgabewerte usw. umgesetzt wurde.


es gibt wirklich jemanden, der diesen S5_C Compiler kennt? Wow, das hätte ich nicht gedacht! Der läuft ja schon fast unter "modernem antiquariat" *lach* aber leider habe ich dazu außer ein paar Flyer gar nichts mehr dazu! Zu der Parameterübergabe weiß ich noch, daß wir das über LIR/TIR gemacht haben. Bei den größeren S5-CPUs (AG155) konnte man ja auf alle Systemspeicher und auch auf den Code selbst zugreifen. Interessant war auch der Trick, einen Source-Level Breakpoint zu setzen: Es wurde ein ungültiger Opcode an die Breakpointstelle gesetzt, dadurch wurde dann ein Fehler-OB aufgerufen (war's OB13 oder OB19). Dieser musste dann den alle Statusinformationen wegspeichern und im Falle eines Einzelschrittes musste dann der Original-Befehl noch irgendwie ausgeführt werden.


----------



## Thomas_v2.1 (27 November 2010)

rrauch schrieb:


> es gibt wirklich jemanden, der diesen S5_C Compiler kennt? Wow, das hätte ich nicht gedacht! Der läuft ja schon fast unter "modernem antiquariat" *lach* aber leider habe ich dazu außer ein paar Flyer gar nichts mehr dazu! Zu der Parameterübergabe weiß ich noch, daß wir das über LIR/TIR gemacht haben. Bei den größeren S5-CPUs (AG155) konnte man ja auf alle Systemspeicher und auch auf den Code selbst zugreifen.



Es gab hier im Forum ja mal Bestrebungen einen eigenen C-Compiler für S7 zu erstellen. Zu der Zeit war ich hier im Forum aber noch nicht so aktiv. Die Diskussionen zu diesem Thema sind aber recht interessant.
Letztendlich war imho die fehlende Debugging-Möglichkeit der ausschlaggebende Grund in dieser Richtung nicht weiter zu entwickeln. Denn was bringt es wenn ich in C-Code schreiben kann, aber nicht in der SPS-üblichen "Brille-Aufsetz"-Manier beobachten zu können? Denn das ist das was alle wollen, und auch im SPS-Umfeld zwingend notwendig ist.

Zumindest kam damals auch die Idee auf, den GCC als Frontend zu verwenden und nur das Backend neu zu schreiben.
Nun ist aber eine Siemens SPS von der Architektur her grundsätzlich zu den "normalen" CPUs/Controllern verschieden. Denn in der S7 kann ich keinen Stack aufbauen, habe keine Register, der Speicher ist über die Datenbausteine extrem fragmentiert usw. Selbst bei dem AVR-8 Bit Controller der ja mehr oder weniger offiziell unterstützt wird entstehen da einige Probleme, weil der GCC vorranging auf x86 ausgelegt ist.
Darum könnte ich mir vorstellen, dass sich vom GCC nicht viel mehr als die lexikalische und syntaktische Analyse für eine S7 verwenden lässt.


----------



## rrauch (29 November 2010)

dieses C-Compiler Thema ist ein bisschen Off-Topic;man könnte es ja wieder in einem eigenen Thread aufleben lassen. 
ich weiß nicht, wieviele Programmierer eine SPS in C programmieren möchten. wahrscheinlich ist der Markt zu klein, um daraus ein kommerzielles Projekt zu machen. aber vielleicht finden sich ja ein paar Leute, die gemeinsam ein OpenSource Projekt starten wollen. Ich denke, ich könnte einiges dazu beitragen.
Und MHJ würde sich bestimmt freuen, den C-Compiler in ihr Programmierpacket zu integrieren.


----------



## Blockmove (29 November 2010)

rrauch schrieb:


> dieses C-Compiler Thema ist ein bisschen Off-Topic;man könnte es ja wieder in einem eigenen Thread aufleben lassen.
> ich weiß nicht, wieviele Programmierer eine SPS in C programmieren möchten. wahrscheinlich ist der Markt zu klein, um daraus ein kommerzielles Projekt zu machen.


 
Zu S5-Zeiten war der Wunsch nach einer Hochsprache verständlich. Bei der S7 hab ich SCL. Wo sollen die Vorteile von C sein?
Ich wäre eher für eine Weiterendwicklung / Ergänzung von SCL.

Gruß
Dieter


----------



## rrauch (29 November 2010)

Blockmove schrieb:


> Zu S5-Zeiten war der Wunsch nach einer Hochsprache verständlich. Bei der S7 hab ich SCL. Wo sollen die Vorteile von C sein?
> Ich wäre eher für eine Weiterendwicklung / Ergänzung von SCL.
> 
> Gruß
> Dieter


 
das ist eigentlich richtig...aber ich hatte immer wieder mal mit Kunden zu tun, die ihre bestehenden C-Programme auf der S7 laufen lassen wollten.
das war meist dann der Fall, wenn beim Maschinenbauer irgendeine Sonderelektronik Spezialaufgaben hatte und die Aufgabe dank der Weiterentwicklung in der SPS-Technik locker von der SPS mit übernommen werden kann. Der Kunde hätte sich dann vorgestellt, er könnte seine teure Spezialelektronik einsparen und sein Programm mit relativ wenig Aufwand auf die SPS portieren.


----------



## LowLevelMahn (29 Mai 2015)

Ist ja schon ein bisschen Zeit vergangen - und wie ich festgestellt habe hat zur Zeit keine Step7 alternative einen funktionierenden SCL Support - oder?


----------



## vollmi (29 Mai 2015)

LowLevelMahn schrieb:


> Ist ja schon ein bisschen Zeit vergangen - und wie ich festgestellt habe hat zur Zeit keine Step7 alternative einen funktionierenden SCL Support - oder?



Also du meinst, ob man bei einem anderen Automatisationsanbieter SCL programmieren kann?
Codesys hat einen IMHO wirklich guten SCL/ST Editor.

mfG René


----------



## JesperMP (29 Mai 2015)

SCL ist nur eine andere Name für IEC 61131-3 Structured text.
ST gibt es bei fast allen heutigen SPSen.

Zur Thema C-Compiler, dann wäre es vielleicht besser mit ein C-nach-ST Konverter.
Das musste fast 1-zu-1 möglich sein, solange das es nicht Pointer umfassen soll.
Und dann hat man Code das man in sein Programmierumgebung bearbeiten und testen kann.


----------



## LowLevelMahn (29 Mai 2015)

Ich meinte schon Step7 (nicht S7) alternativen wie  IBHs "S7 für Windows" oder MHJs "WinSPS-S7" (gibts noch andere?)


----------

