TIA V15: In SCL GOTO-Befehl verwenden?

Zuviel Werbung?
-> Hier kostenlos registrieren
Es ist für mich immer wieder lustig, wie Programmierer über Programmierer urteilen.
Sollte das Wort Toleranz in die Bedienungsanleitung von z.B. TIA einführt und erklärt werden?
Ich versuche auch ein GOTO zu vermeiden, obschon es vor vierzig Jahren bei IBM PC mit eingebautem Basic oder Pascal oder Fortran nicht immer möglich war.

Aber ein vernünftig programmiertes PLC Programm, das klar dokumentiert ein paar GOTOs hat, was ist daran so schlecht?
Ist es besser mit komplizierten IF THEN ELSE oder CASE Konstruktionen ein GOTO zu umgehen?
Ist es nicht besser vernünftig zu programmieren, dokumentieren, auch zusätzlich zum Programmcode, und zu akzeptieren, dass nicht jeder geistiger Durchfall in ein Programm muss?
Neben mir sitzen einige Freunde, die den selben Beruf wie ich haben, und die anders als ich ticken, doch zu klassifizieren was ist besser oder schlechter ist masse ich mir nicht an.
Solange ein Programm das macht wozu es erstellt wurde ist es ein gutes Programm.
@ralle: löschen nur wegen bikeismus :ROFLMAO:


bike
 
Mein Beispiel ist doch gar keine "leere" REPEAT-Schleife, sondern sie ist genau deshalb drin, weil da tatsächlich ein Programmteil bedingt wiederholt werden soll. Wieso soll man dafür keine REPEAT-Schleife einsetzen dürfen? Mit dem REPEAT hat man wenigstens ein "Achtung!"-Zeichen, daß da ein Rückwärtssprung ist, was man bei mehreren GOTO nicht so deutlich sehen würde.

Das Ungewöhnliche an der Schleife ist doch lediglich, daß die Abbruchbedingung nicht aufwändig über eine Variable realisiert ist sondern über ein einziges "EXIT". Ist sowas für "Hochsprachen-Programmierer" schon zu hoch? ;)

Harald

Sorry "leere Schleife" war der falsche Ausdruck. Ich meine damit einfach Schleifen bei denen die Bedingung immer erfüllt ist.
Hier steckt die Logik eben irgendwo anders. Verwende ich auch und ist völlig legitim. Ich weiß halt, dass man bei sowas genauso wie bei Goto den Code genauer anschauen muss wie bei einer "normalen" Schleife.

Gruß
Blockmove
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Danke für die Vielen Antworten und darin enthaltenen Meinungen.

Diese zeigen mir, dass die Antwort auf meine Frage nicht so einfach ist. Ich erhoffte (er-)schlagende Argumente, die klar die Nachteile von GOTO aufzeigen.

Ich persönlich finde es von Nachteil, dass bei Verwendung von CASE-Schritten in einer Trace-Aufzeichnung mehrere Schritte bearbeitet wurden und das Fehlersuchen so verkomplizieren kann...
 
Danke für die Vielen Antworten und darin enthaltenen Meinungen.

Diese zeigen mir, dass die Antwort auf meine Frage nicht so einfach ist. Ich erhoffte (er-)schlagende Argumente, die klar die Nachteile von GOTO aufzeigen.

Wenn man GOTOs Strukturiert einsetzt kann es auch ein Programm ggf. leserlicher machen, z.B. bei Hochsprachen mit dem "On Error GOTO" oder wenn man auf einen definierten Punkt im Programm springt um dort definiert eine Funktion zu beenden.
Teils ist halt GOTO die einzigste Möglichkeit bestimmt Funktionen vorab zu beenden (glaube ist ja bei For-Schleifen der Fall).
Würde man im Compiler entsprechende Möglichkeiten schaffen, könnte man auf GOTO bestimmt verzichten.
Aber im Maschinencode wird man bestimmt sehr viele Jumps finden, was ja auch nur GOTOs sind ;)

Problematisch ist es halt, wenn GOTO's einsetzt anstatt Strukturiert zu programmieren und den Code dadurch unleserlich macht.



Ich persönlich finde es von Nachteil, dass bei Verwendung von CASE-Schritten in einer Trace-Aufzeichnung mehrere Schritte bearbeitet wurden und das Fehlersuchen so verkomplizieren kann...

Hierzu kann man ohne den Code zu kennen auch kaum eine Aussage treffen.
Man könnte auch sagen, das halt ggf. an der Fehlerbehandlung wegen schlechtem Still gespart wurde, oder Du die falschen Variablen aufgezeichnet hast!
Aber wie geschrieben, müsste man den Code sowie den Fehler und die Aufzeichnung kennen um hier genaueres Aussagen zu können ...
 
Im MISRA-C Standard (Motor Industry Software Reliability Association) gibt es übrigens auch Regeln die nicht nur goto, sondern auch continue und break (außer zum Beendigen eines case in C) verbieten. Genauso ist nur ein einziges return pro Funktion erlaubt.
Was man von Programmierern hört die sich daran halten müssen, ist es aber alles andere als schön wenn wirklich alle Regeln verpflichtend eingehalten werden müssen.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hier die selbe Lösung wie #7 mit ohne GOTO, aber ohne die bösen CONTINUE und EXIT und mit nur ganz einfachen Hochsprachen-Anweisungen ;) ist doch gleich viel verständlicher :D :cool:
Code:
[COLOR="#0000FF"]REPEAT[/COLOR] [COLOR="#008000"]//eine Schleife für den Rückwärtssprung zur sofortigen Schrittweiterschaltung[/COLOR]
  xExitLoop := TRUE;       [COLOR="#008000"]//Voreinstellung: bei den meisten Durchläufen Schleife nicht wiederholen[/COLOR]

  CASE Schrittnummer OF
    1: TuWas1();
       Schrittnummer := 2; [COLOR="#008000"]//mit Schrittnummer 2 im nächsten Zyklus fortsetzen[/COLOR]

    2: TuWas2();
       Schrittnummer := 3; [COLOR="#008000"]//mit Schrittnummer 3 fortsetzen sofort[/COLOR]
       [COLOR="#0000FF"]xExitLoop := FALSE;[/COLOR] [COLOR="#008000"]//Schleife wiederholen für sofortige Schrittweiterschaltung[/COLOR]

    3: ...

  END_CASE;

[COLOR="#0000FF"]UNTIL xExitLoop = TRUE
END_REPEAT[/COLOR]; [COLOR="#008000"]//ggf. Rückwärtssprung zurück zu REPEAT wenn xExitLoop = FALSE[/COLOR]

[COLOR="#008000"]//weiter...[/COLOR]

Harald
 
Nicht falsch verstehen Harald ... ich fand das (Beitrag #7) nicht böse - ich kannte die Variante nur nicht ... 8)

Gruß
Larry
 
Hi
Ich muss sagen, das mit dem Repeat ist eigentlich eine intressante Lösung. Wäre jetzt mir nicht in den Sinn gekommen. Allerdings musste ich jetzt auch noch nie im CASE wieder im selben Zyklus in eine andere Nummer springen.
Aber sicher gut zu wissen. [emoji3]

Gesendet von meinem BLN-L21 mit Tapatalk
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo zusammen,
generell versuche ich Sprünge auch zu vermeiden, aber in meinen Automatikabläufen nutze ich den Goto an einer Stelle gerne und finde das auch deutlich übersichtlicher als ein IF.
Im Automatik gibt es 2-3 Netzwerke die Zyklisch aufgerufen werden danach kommt der Goto der alle anderen Netzwerke überspringt wenn Einrichten aktiv ist.... d.h. Ich habe ein Sprunglabel ENDE und bei Bedarf kann ich immer zu diesem Springen und wo Ende dran steht ist auch Ende drin:)

Gruß Softi
 
Hallo zusammen,
generell versuche ich Sprünge auch zu vermeiden, aber in meinen Automatikabläufen nutze ich den Goto an einer Stelle gerne und finde das auch deutlich übersichtlicher als ein IF.
Im Automatik gibt es 2-3 Netzwerke die Zyklisch aufgerufen werden danach kommt der Goto der alle anderen Netzwerke überspringt wenn Einrichten aktiv ist.... d.h. Ich habe ein Sprunglabel ENDE und bei Bedarf kann ich immer zu diesem Springen und wo Ende dran steht ist auch Ende drin:)

Gruß Softi

Warum benutzt du dafür nicht den Return Befehl ? Der beendet die Bearbeitung des aktuellen Bausteins.
Finde ich besser weil das halt definitiv Ende bedeutet ;)


Der Aussage das viele if Elsif Anweisungen unübersichtlich werden stimme ich zu, nutze um es übersichtlich zu gestalten aber lieber die Möglichkeit mit REGION / END_REGION die einzelnen Anweisungen im Baum links kurz zu erläutern.

Wenn ich goto Befehle sehe läuft es mir immer kalt den Rücken runter ;) aber jedem das seine.

Grüße

Balu
 
In STEP7 Classic habe ich GOTO verwendet um Programmfehler zu fangen und behandeln.
Also nicht Maschinen Störungen o.Ä, sondern meine eigene Fehler.
In STEP7 Classic konnte man den Option setzen das der SCL Compiler den "OK" bit steuern sollte. Dann konnte man einfach den OK bit abfragen, etwa wie..

//.. komplizierte Code mit ein gut versteckte Fehler der nur zur Laufzeit auftritt.
IF NOT OK THEN
Error_string := 'Code error after calculation' ;
GOTO Exit ;
END_IF ;
Sollte nicht notwendig sein wenn man nur perfekt programmiert. Aber wenn man nicht perfekt ist, dann..

IN TIA scheint es das es gibt den OK bit nicht mehr.
Umgekehrt gibt es ein neuen --|OK|-- Kontakt in KOP/FUP. Damit kann man Operanden checken (z.B. dass ein REAL nicht NaN ist) bevor man ein Berechnung durchführt.
In SCL wird ENO gesetzt, aber erst am Exit von den Baustein. Wie man böse Fehler innerhalb von den Code in TIA SCL abfangt, weis ich nicht !
 
@Onkel. Ich habe immer gedacht, das für SCL wird ENO erst am Ende von den Baustein gesetzt.
Nach dein Hinweis und ein bisschen Forschung, ist es mir klar das ENO wird aktualisiert nach jeden Befehl, auch innerhalb von ein CL Baustein, und man kann ENO abfragen nach ein Befehl um zu checken ob es korrekt durchgeführt wurde.
Habe wieder was gelernt, danke !

@PN/DP. Es wäre interessant zu sehen wie OK in TIA übersetzt wird. Werde ich checken.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Wenn es jemand interessiert:

SCL V5.6:
Code:
real_temp := real_in_1 / real_in_2 ;
IF OK THEN
    real_out := real_temp ;
ELSE
    real_out := 0.0 ;
END_IF ;    

OK_status := OK ;

STL V5.6 erzeugt durch SCL compiler:
Code:
      SET         SAVE  
      =     L      4.1
      L     #real_in_1
      L     #real_in_2
      /R    
      JO    I007
      JU    I008
I007: CLR   
      =     L      4.1
I008: T     #real_temp
      CLR   
      A     L      4.1
      JCN   A7d0
      L     #real_temp
      T     #real_out
      JU    A7d1
A7d0: L     0.000000e+000
      T     #real_out
A7d1: CLR   
      A     L      4.1
      =     #OK_status
      L     100
      T     #RET_VAL
      SAVE  
      BE
Es scheint das "OK" ist eigentlich ain Abfrage von OV (über JO, Sprung wenn OV bit gesetzt).

Nach Migrierung nach SCL V15:
Code:
#real_temp := #real_in_1 / #real_in_2 ;
IF ENO THEN
    #real_out := #real_temp ;
ELSE
    #real_out := 0.0 ;
END_IF ;    

#OK_status := ENO ;
Tatsächlich wirk OK mit ENO ausgetauscht.
Nach Hans Berger wird (in V5.6) ENO gesetzt nach ein Bausteinaufruf.
Nach den online hilfe (in V15) wird ENO gesetz nach ein Bausteinaufruf, und wenn "Set ENO Automatically" gewählt ist auch nach jeden Befehl. Es kostet aber Prozessorzeit.
 
Zurück
Oben