Diskussion: SCL Compiler Einschränkungen, Erweiterungen

Zuviel Werbung?
-> Hier kostenlos registrieren
@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
 
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.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
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 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
 
falsch...es geht um Step7-Steuerungen und deren Programmierung, nicht um Codesys/IEC1131 o.ä.

Du eierst ganz schön rum hier :ROFLMAO:

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
 
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.
 
Du eierst ganz schön rum hier :ROFLMAO:
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!
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
 
...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...
 
Zuviel Werbung?
-> Hier kostenlos registrieren
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!
 
Zuviel Werbung?
-> Hier kostenlos registrieren
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.
 
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
 
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....
 
Zuletzt bearbeitet:
Zurück
Oben