Diskussion: SCL Compiler Einschränkungen, Erweiterungen

rrauch

Level-1
Beiträge
45
Reaktionspunkte
0
Zuviel Werbung?
-> Hier kostenlos registrieren
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
 
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.
 
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.
 
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?
 
Zuviel Werbung?
-> Hier kostenlos registrieren
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...
 
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.
 
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!
 
Zuviel Werbung?
-> Hier kostenlos registrieren
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.
 
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!
 
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
 
Zuviel Werbung?
-> Hier kostenlos registrieren
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 :rolleyes: )

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

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

Ich hätte mir viel Schreibarbeit gespart, ...
das ist in meinen Augen aber auch nur ein schwacher Grund.
 
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
 
Zurück
Oben