Diskussion: SCL Compiler Einschränkungen, Erweiterungen

Zuviel Werbung?
-> Hier kostenlos registrieren
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
 
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....

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?
 
Zuviel Werbung?
-> Hier kostenlos registrieren
@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
 
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

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() )
 
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
 
Zuviel Werbung?
-> Hier kostenlos registrieren
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

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 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
 
Zuletzt bearbeitet:
...
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?
 
Zuviel Werbung?
-> Hier kostenlos registrieren
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!
 
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
 
Zuviel Werbung?
-> Hier kostenlos registrieren
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.

Beispiel:

arr1:ARRAY[0..4] OF INT;
Var1:INT;


In AWL:

LD arr1
SIZEOF
ST Var1 (* Ergebnis ist 10 *)


Beispiel in ST:

var1 := SIZEOF(arr1);
 
Zuviel Werbung?
-> Hier kostenlos registrieren
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 :p

gruß von rrauch
 
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 ...?
 
Zuviel Werbung?
-> Hier kostenlos registrieren
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
es ist keine fiktive Diskussion. Der Compiler wird in einer integrierten Entwicklungsumgebung laufen, die auch den Anspruch an Komfort erfüllt!
 
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
 
Zurück
Oben