RANT: Konstrukte bei denen man sich manchmal fragt

vollmi

Level-3
Beiträge
5.435
Reaktionspunkte
1.409
Zuviel Werbung?
-> Hier kostenlos registrieren
Ich bin grad an einem Projekt dran das seit 5 Jahren läuft und jetzt erweitert wird. Ich muss mich also in die denke eines anderen Programmierers eindenken.
Und vor allem Fehler suchen die nur sporadisch auftauchen.

Ich bin weit entfernt ein Pro zu sein. Aber bei manchen Konstrukten zweifle ich echt an der Zurechnungsfähigkeit und der Qualitätskontrolle.

Das hier wäre so ein Beispiel.
Code:
      U     #Obj_Schalten      
SPBN  AU01
      ON    #Obj_Freigabe
      O     #Obj_SA_Abschaltung
      O     #Obj_SA_SGK_Schalten
      SPBN  AU01
      R     #Obj_Schalten
AU01: NOP   0

Was denkt man sich wenn man so was konstruiert? Denkt man da auch an den nächsten der da online Fehler suchen soll? Wie macht man mit sowas ne Inbetriebnahme?

Das wird dann in anderen Programmteilen noch etwas exzessiver.
Code:
      O     "Instanz DB11".Betrieb_Im_Obj1_Ein
      O     "Instanz DB11".Prg_Immission_Obj1_aktiv
      O     "Instanz DB11".Betrieb_IM_Obj2_Ein
      O     "Instanz DB11".Prg_Immission_Obj2_aktiv
      O     "Instanz DB11".Betrieb_Manuell_Ein
      O     "Instanz DB11".Prg_Manuell_aktiv
      SPBN  FR01
      U     "IODB"._DBX_2_1          // Drehrichtung
      SPB   FR00
      U(                                // Drehzahl
      L     "SPS -> MMI"._DBW_60_0
      L     50
      <=I   
      )     
      SPBN  FR01
FR00: O(    
      L     "SPS -> MMI"._DBW_86_0
      L     150
      >=I   
      )     
FR01: UN    #Obj_SA_Alarme_Anfahrt
      UN    #Obj_SA_SGK_Schalten
      UN    #Obj_SA_Abschaltung
      U     #Obj_Freigabe
      SPBN  FR02
      S     #Obj_Schalten
FR02: NOP   0

Was habt ihr da so zu bieten wo ihr euch schonmal gefragt habt was sich derjenige dabei dachte.

mfG René
 
Was habt ihr da so zu bieten wo ihr euch schonmal gefragt habt was sich derjenige dabei dachte.

mfG René[/SIZE]

Hallo René

das ist der Progger-Stil eines Programmierers, der noch
mit Sicherheit in S5-Zeiten aufgewachsen ist.
Dort war es so üblich, in AWL das "Setzen" so wie hier
aufzurufen und das Rücksetzen erst Netzwerke später
oder gar in einem anderem Baustein auszuführen (was
sicher auch funktioniert, aber nicht unbedingt
nachvollziehbar ist).

Bleibt dir nur eins:
"reinpfriemeln"
ODER
auseinander nehmen und neu programmieren.


Gruss
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo René

das ist der Progger-Stil eines Programmierers, der noch
mit Sicherheit in S5-Zeiten aufgewachsen ist.

Leider nicht. Darum kann ich mir diesen Stil ja auch nicht erklären.

Dort war es so üblich, in AWL das "Setzen" so wie hier
aufzurufen und das Rücksetzen erst Netzwerke später
oder gar in einem anderem Baustein auszuführen (was
sicher auch funktioniert, aber nicht unbedingt
nachvollziehbar ist).

Ich setze und rücksetze ja manchmal auch in verschiedenen Netzwerken. Dann wenn es der Uebersichtlichkeit oder Sicherheit geschuldet ist.
Aber ich war mir sicher das man auch bei der S5 ein S und R Ergebnisabhängig ausgeführt hat. Und nicht überspringen musste wenn es nicht ausgeführt werden sollte.

Und in diesen Programmteilen ist es dann ja sogar so dass zwingens S oder R ausgeführt werden. Also die Funktion garnicht benötigt wird sondern ein = den selben Zwecke erfüllte.

Ich versuche möglichst mit aus dem Programm rauszuhalten und die Erweiterungen in getrennten Bereichen zu halten. Aber es hat da drin auch hochsporadisch auftauchende Fehler die echt schwierig zu finden sind.

mfG René
 
Der gezeigte Programmierstil hat nichts mit "alter S5-Programmierer" zu tun, sondern eher mit "junger größenwahnsinniger S7-Programmierer", der nach kurzer Erfahrung schon meint, er wäre ein AWL-Genie ("übersichliches KOP/FUP ist was für Weicheier und Platzverschwendung").

Es war auch zu S5-Zeiten nicht üblich, mitten in Verknüpfungen zu springen - erst recht nicht mit SPB/SPBN *ROFL*, weil das nämlich gar nicht so funktioniert, wie das kleine Genie wohl gewollt hat. :cool:
siehe die zweimal "SPBN FR01"

Ich kann mir gut vorstellen, daß der Code mit den Vergleichern gar nicht so funktioniert wie er soll, man sieht aber leider nicht welchen Sinn die Parameter _DBW_60_0 und _DBW_86_0 haben.

Damit "S #Obj_Schalten" ausgeführt wird:
  • WENN _DBX_2_1 = 0 und _DBW_60_0 > 50 DANN wird _DBW_86_0 ignoriert
  • WENN _DBX_2_1 = 0 und _DBW_60_0 <= 50 DANN muß _DBW_86_0 >= 150 sein
  • WENN _DBX_2_1 = 1 DANN wird _DBW_60_0 ignoriert aber _DBW_86_0 muß >= 150 sein
  • WENN keines der "DB11"-Bits true ist, dann werden beide _DBW_60_0 und _DBW_86_0 ignoriert


"FR00: O("
Ob hier O( oder U( steht ist egal, weil immer eine neue Verknüpfung mit Erstabfrage angefangen wird und später kein O mehr kommt. Das verwendete O( ist aber irreführend weil es wie U( wirkt!


"SPBN FR02" und "SPBN AU01"
Die einzelnen S oder R zu überspringen ist Ansichtssache. Man kann es so machen, weil es evtl. die Übersichtlichkeit erhöht. Solange nur S und R nach dem SPBN folgen ist das Überspringen nicht notwendig. Vielleicht war da aber auch noch weiterer (auskommentierter) VKE-unabhängiger Code nach dem SPBN (oder die Stelle soll für sowas freigehalten werden)?

Harald
 
Es war auch zu S5-Zeiten nicht üblich, mitten in Verknüpfungen zu springen ...

Hast du 'ne Ahnung ... ;) Derartige Merkwürdigkeiten habe ich auch schon des Öfteren gesehen ... und ich mache mit dir eine Wette, dass noch viele "erfahrene" Programmierer auch heute noch so programmieren ...
In meinem heutigen Zuständigkeitsbereich gibt es so etwas nicht ... und früher habe ich solche Konstrukte dann regelmäßig elemeniert, streng nach der vielleicht etwas größenwahnsinnigen Devise : wenn ich es nicht auf Anhieb verstehe - wie sollen es dann Andere tun ...



Gruß
Larry
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Die Devise ist aber sehr gut...

Ich nehme mir immer vor, etwas so zu programmieren, dass ich auch in 5 Jahren mir einer Kiste Bier intus noch verstehe was ich programmiere. Aber wenn ich heute Programme anschaue die ich vor 10 Jahren gebastelt hab, glaub ich eher, dass ich damals besoffen war....
 
Aber wenn ich heute Programme anschaue die ich vor 10 Jahren gebastelt hab, glaub ich eher, dass ich damals besoffen war....

Das geht mir heute auch so. Wenn ich mir die Merkerverballerei von vor 10 Jahren anschaue die ich programmiert habe. Wo ich heute alles versuche in Bausteine zu kapseln.

Aber man lernt ja auch dazu. Zumindest versucht man es.

Aber selbst vor 10 Jahren habe ich auch meinen wesentlich unübersichtlicheren Programmierstil ausführlich mit Kommentaren und Datum versehen dass ich auch auch heute noch weiss um was es ging und was die Intention hinter einer Programmzeile war.

mfG René
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Wir können ja mal schauen ob es da Ähnlichkeiten gibt ;)

Code:
      U     #Obj_Schalten      
SPBN  AU01
      ON    #Obj_Freigabe
      O     #Obj_SA_Abschaltung
      O     #Obj_SA_SGK_Schalten
      SPBN  AU01
      R     #Obj_Schalten
AU01: NOP   0

Code:
      O     "Instanz DB11".Betrieb_Im_Obj1_Ein
      O     "Instanz DB11".Prg_Immission_Obj1_aktiv
      O     "Instanz DB11".Betrieb_IM_Obj2_Ein
      O     "Instanz DB11".Prg_Immission_Obj2_aktiv
      O     "Instanz DB11".Betrieb_Manuell_Ein
      O     "Instanz DB11".Prg_Manuell_aktiv
      SPBN  FR01
      U     "IODB"._DBX_2_1          // Drehrichtung
      SPB   FR00
      U(                                // Drehzahl
      L     "SPS -> MMI"._DBW_60_0
      L     50
      <=I   
      )     
      SPBN  FR01
FR00: O(    
      L     "SPS -> MMI"._DBW_86_0
      L     150
      >=I   
      )     
FR01: UN    #Obj_SA_Alarme_Anfahrt
      UN    #Obj_SA_SGK_Schalten
      UN    #Obj_SA_Abschaltung
      U     #Obj_Freigabe
      SPBN  FR02
      S     #Obj_Schalten
FR02: NOP   0


Code:
FUNCTION FC 1 : VOID
TITLE =
VERSION : 0.1

BEGIN
NETWORK
TITLE =
//E0.0 =Schalter
//A0.1 = AUSGANG1
//A0.2 = AUSGANG2
//M0.0 = Flanke
//M0.1 + M0.2 = Hilfsmerker
//M0.3 = Schalter+Flanken Ersatz
      U     E      0.0; 
      FP    M      0.0; 
      =     M      0.3; 
      U     M      0.3; 
      UN    M      0.1; 
      UN    M      0.2; 
      SPB   o1; 
      U     M      0.3; 
      UN    M      0.1; 
      U     M      0.2; 
      SPB   o2; 
      U     M      0.3; 
      U     M      0.1; 
      UN    M      0.2; 
      SPB   o3; 
      U     M      0.3; 
      U     M      0.1; 
      U     M      0.2; 
      SPB   o4; 
      BE    ; 
o1:   R     M      0.1; 
      S     M      0.2; 
      S     A      0.1; 
      BE    ; 
o2:   S     M      0.1; 
      R     M      0.2; 
      R     A      0.1; 
      BE    ; 
o3:   S     M      0.1; 
      S     M      0.2; 
      S     A      0.2; 
      BE    ; 
o4:   R     M      0.1; 
      R     M      0.2; 
      R     A      0.2; 
      BE    ; 

END_FUNCTION

:D ( ...würde auch einfacher gehen aber nicht verständlicher !)
 
Wenigstens hats bei mir keine Symbollosen Merker dabei. Aber die externen IDB zugriffe sind ja auch nicht wirklich besser.

Aber meine güte. Selbst wenn man online davor sitzt. Ist es richtig übel den Auslöser für irgendeine Funktion zu finden.

Da gibts auch so veroderungen welche ein Objekt sperren so dass man es rücksetzen muss. Aber es wird nicht der auslösende Fehler gespeichert sondern das Objekt wird als gestört gestört.

Super wenn irgendwo ein Wackelkontakt ist, und das MMI die Einzelmeldung garnicht mitkriegt.

Finde den Fehler wenn nur das Resultat bekannt ist, der Fehler aber schon wieder weg. Vor allem wenn das Resultat aus 100 verschiedenen Auslösern gebildet wird.

mfG René
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Manche "Kollegen" haben einfach nicht begriffen, dass ihre Programme wie Kindersachbücher (Im Sitle von "Was ist Was") schreiben sollten.
Einige schreiben Romane, andere Prosa und wieder andere Esotherik.

Gruß
Dieter
 
Hier mal eine Auswahl was ich sehr oft sehe:

- Rücksetzen einer boolschen Variable nur nach vorheriger Prüfung, ob die denn auch gesetzt ist
- Verknüpfen aller Rücksetzbedingungen bei SR-Flipflop auch nochmal im Setzen-Zweig
- seitenlange "Angst-Rücksetz-Orgien" von 'zig Variablen bei "Ereignissen" - die zeigen mir immer, daß der Programmierer seinem eigenen Programm nicht traut.
- Verarbeiten von HMI-Eingaben ohne Wertebereichsprüfung oder höchstens Grenzwertprüfung bei der Eingabe im HMI

Was in neuerer Zeit mit ST und SCL leider immer mehr zunimmt: diese oft logisch unvollständig(!) ausprogrammierten IF..THEN mit 'zig extra Sonderbehandlungen für 'zig möglicherweise auftretende Ereignisse, statt sich mit vernünftiger Logik ala Karnaugh und Wahrheitstabellen zu beschäftigen ...

Harald
 
- seitenlange "Angst-Rücksetz-Orgien" von 'zig Variablen bei "Ereignissen" - die zeigen mir immer, daß der Programmierer seinem eigenen Programm nicht traut.

Bei diesen Setz\Rücksetzorgien oder auch verriegelungsorgien ist das doofe. Übersichtlicher werden die Programme dadurch nicht. Und auf einmal gibts dann ne konstellation wo sich alles ineinander verriegelt.

Mit freundlichen Grüßen René
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ich arbeite hier an einem Programm, das im Prinzip 4 Modi und 3 Submodi implementiert. Als Randbedg. kommen noch Grenzwerte dazu. Der damalige Progammierer hat alles mit Merkern gemacht. Die IF-THEN-ELSE Exzesse sehen in etwa so aus:

IF Merker1 THEN Merker5=False
IF Speed<4 then Merker7=True;
END_IF;
ELSIF Merker3 THEN ....

Auf diese Weise hat er einen Rampengenerator für eine Position realisiert...

Ich habe dann die Modes in einen Mode-Controller ausgelagert und dort errechnet und habe jetzt eine wunderschöne State-Machine mit einem

CASE Mode OF
Mode 1:
Mode 2:
....

END_CASE;

Ich bestreite das man Merker benötigt
 
Zuletzt bearbeitet:
Zurück
Oben