Diskussion:Strukturierter Text

aus Wikipedia, der freien Enzyklopädie
Zur Navigation springen Zur Suche springen

Beispiele

[Quelltext bearbeiten]

Ich würde die Beispiele, die im aktuellen Artikel genannt sind etwas überarbeiten. Meines Erachtens sind die Beispiele mit viel Inhalt gefüllt, der nicht notwendig ist und das ganze Beispiel somit unübersichtlich macht. Das aktuelle Beispiel zu if Anweisung würde ich folgendermaßen umbauen:

IF Bedingung THEN
  Anweisung1;
ELSIF Bedingung2
  Anweisung2;
ELSE
  Anweisung3;
END_IF

Was meint ihr dazu? Ich würde es als Verbessung empfinden, wenn die Beispiele übersichtlicher und allgemeiner dargestellt werden. --DerTechniker (Diskussion) 14:12, 29. Apr. 2017 (CEST)Beantworten

Habe nun einmal das erste Beispiel abgändert, werden die anderen in den nächsten Tagen vereinfachen und vereinheitlichen. Auch würde ich die Überschriften "Beispiel1" , "Beisspiel 2" ,.... gerne abändern. Ich würde vorschlagen: Ähnlich wie bei anderen Programiersprachen einen Abschnitt mit der Überschrieft "Sprachelemente von Strukturiertem Text" erstellen. Als Unterüberschriften würde es dann ein "IF-Statement" , CASE-Statement",... geben. Zu jedem Sprachelement gibt es dann eine kurze Beschreibung und ein Codebeispiel. Der aktuelle Artikel sieht nämlich nur wie eine Beispielsammlung aus... --DerTechniker (Diskussion) 22:04, 3. Mai 2017 (CEST)Beantworten
Werde nun noch zwei Sprachelemente hinzufügen, die bisher nicht im Artikel waren: Zuweisung und POINTER Oder spricht etwas dagegen? --DerTechniker (Diskussion) 16:35, 10. Mai 2017 (CEST)Beantworten

END_ Statements mit ; abschließen?

[Quelltext bearbeiten]

An allen Codebeispielen wurde zum Abschluss eines END_ Statements ein ";" hinzugefügt!

@Schnatterfleck:: Im Strukturierten Text ist ein END_ Statement mit und ohne ";" möglich. Alle Steuerungen die ich bis jetzt programmiert habe funktionieren ohne ein ; am Ende eines END_ Statements. Hast du andere Erfahrungen gemacht? Oder was veranlasst dich ein END_ Statement ohne ; als Syntaxfehler zu bezeichnen?

Bemerkung: Da beide Varianten zulässig sind, ist es mir egal welche im Artikel bei den Beispielen verwendet wird. Mich interessiert nur, warum die Variante ohne ; als Syntaxfehler bzeichnet wird! --DerTechniker (Diskussion) 20:26, 18. Jun. 2017 (CEST)Beantworten

@DerTechniker:: Gerade nochmal probiert: Ein aktuelles Siemens TIA-Portal wirft mir beim Übersetzen eine Fehlermeldung, wenn hinter einem END_IF kein Semikolon steht. Also zumindest die Steuerungen eines Hersteller scheinen mit einem fehlenden Semikolon an der Stelle nicht klar zu kommen.
--Schnatterfleck (Diskussion) 06:37, 31. Aug. 2017 (CEST)Beantworten
Vielen Dank für die Info, werde es bei Gelegenheit einmal im TIA Portal ausprobieren. Bei Codesys, sowie Twincat funktioniert es ohne Semikolon!--DerTechniker (Diskussion) 14:14, 3. Sep. 2017 (CEST)Beantworten

Quelle 1 ist als Link nicht mehr vorhanden.

Keine Unterscheidung von Groß- und Kleinschreibung bei Schlüsselworten

[Quelltext bearbeiten]

Meine IDE (eine recht frühe Codesys-Implementierung) schreibt Schlüsselworte automatisch in Großbuchstaben. Wenn ich Text mit dem Texteditor eingebe und das nicht mache, bekomme ich einen Syntax-Fehler: "Schlüsselworte müssen groß geschrieben werden". Was ist denn nun falsch? Dieser Satz in Wikipedia oder meine Implementierung? Variablen sind allerdings "case insensitive". --188.97.43.67 10:37, 6. Aug. 2021 (CEST)Beantworten


Hallo, ich hab es gerade in einer aktuellen Version getestet, dort lässt sich folgendes fehlerfrei übersetzen und ausführen
IF TRUE THeN
;
end_if
Laut Standard ist ST nicht Casesensitive daher ist es ein Implementierungsfehler, wenn dadurch ein Fehler erzeugt wird
-- JE - Diskussion - Bewertung -- 11:45, 6. Aug. 2021 (CEST)Beantworten

While und Repeat Schleifen

[Quelltext bearbeiten]

Diese Schleifen sollte man als SPS-Programmierer aber nur in Ausnahmefällen und dann auch nur mit größter Vorsicht einsetzen. Die meisten SPS verfügen ja über einen Watchdog. Wenn die Abarbeitung dieser Schleife zu lange dauert, schlägt der unweigerlich zu. Eine Anweisung wie WHILE NOT Eingang_1 DO .. geht also in 99,9% aller Fälle schief. Da ist vielleicht eine Warnung angebracht? --188.97.43.67 10:58, 6. Aug. 2021 (CEST)Beantworten