TIA Was ist perfomanteste Art zu programmieren ?

Zuviel Werbung?
-> Hier kostenlos registrieren
Das ist das schöne: "Tausend wege führen nach Rom"
Welcher Weg nun der beste ist, hängt von mindestens genau so vielen Günden ab die auch alle einzeln und zusammen bewertet werden wollen.
 
Habe da aktuell eine Anlage bei der die Taktzeit um mehr als 5s verbessert werden konnte und das nur durch Tausch der CPU, also durch Verringerung der SPS-Zykluszeit!!!
5 Sekunden Maschinentaktzeit einsparen halte ich für nicht repräsentativ. War die CPU davor eine extrem alte/langsame CPU? (Welche CPUs genau wurden da getauscht?) Oder ist das Programm vielleicht sehr ungünstig programmiert? Die 5s werden ja nicht in nur einem OB1-Zyklus eingespart, sondern in hunderten Zyklen, d.h. der Maschinentakt müsste da hunderte Schritte erfordern.

Harald
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hast ja recht...

Mal ein paar grobe Eckpunkte:

CPU-Tausch von 1515 > 1517. Taktzeit vorher 27s > 22s. (Zykluszeit von ca. 15ms-19ms auf unter 7 ms) Kette mit ca. 20 Schritten die aber grob 30 mal abgearbeitet werden muss.

- 14 NC-Achsen (Motion-Control Achen auf der CPU)
- 6 Messtaster (Merkmalbestimmung (Position)(Time-Base iO))
- 5 Zeitkritische Ausgänge ( Selektiv und auf Motion-Position berechnet alle 4ms ) auf 2µs genau (Time-Base iO)
- ...

In einer vergleichbaren Folgeanlage konnte die Zykluszeit dann nochmal deurtlich verringert werden. (Ebern auch durch oben genannte Selektive Berabeitung)
 
Ich denke mal, dass wenn wirklich der CPU-Tausch hier diese doch signifikante Leistungs-Steigerung gebracht hat, es in der CPU extrem zeitaufwändige Berechnungen gegeben hat - da hier die Zykluszeit nicht explodiert zu sein scheint wurden diese dann wahrscheinlich auch noch über viele Zyklen verteilt.
Dazu kann man aber, ohne die Applikation zu kennen, so aus der Ferne ganz wenig sagen ...

Gruß
Larry
 
Ich hatte mal zu S5-Zeiten ein niederschmetterndes Erlebnis mit einer "signifikanten Leistungssteigerung". Von Siemens war eine doppelt so schnelle CPU versprochen worden und sie führte in unseren Anwendungen zu erheblich längeren ZyklusZeiten.
Des Rätsels Lösung: die Ausführungszeiten der BitBefehle waren tatsächlich von Siemens halbiert worden, aber Siemens konnte sich nicht vorstellen, dass wir auch Byte-, Wort- und DoppelWortBefehle benutzen. Diese waren in der "schnelleren" CPU nämlich erheblich langsamer.

Die hier beschriebene Verkürzung der Taktzeit von 27 s auf 22 s durch eine (ca.) Halbierung der ZyklusZeit finde ich schon enorm.
Meistens werden Schrittketten durch Wartezeiten verlangsamt. Warten auf Vollzugsmeldungen der relativ trägen Mechanik/Hydraulik.
Wartezeiten, die weit jenseits der ZyklusZeit liegen. In der Praxis hat sich das Warten auf Rückmeldungen von Druckschaltern als extrem "entschleunigend" erwiesen.

Liegen die Wartezeiten in der GrössenOrdnung der Zykluszeit, so kann u.U. die Taktzeit sogar durch eine Verlängerung der Zykluszeit verkürzt werden. Nämlich dann, wenn die erwartete Reaktion im nächsten (langsameren) Zyklus erfolgt, statt erst im übernächsten (schnelleren) Zyklus.
Aber das dürfte sich in der Praxis wohl selten auswirken. Aber dieser Aspekt kann helfen, zu verstehen, warum Verkürzungen der Zykluszeit meistens nicht so durchschlagend auf die Taktzeit wirken.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Bei Schrittketten konnte ich diesen Effekt schon ein paar mal beobachten. Die SPS wartet ja im Schnitt einen halben SPS-Zyklus länger als Notwendig in jedem Schritt, bis die Transition erfüllt ist. Wenn dann noch bei einem Schritt in Graph zwei SPS-Zyklen verstreichen, obwohl der Schritt logisch übersprungen hätte werden können, wird der Effekt noch verstärkt. Ich erinnere mich an eine Optimierung von gut 8 auch knapp 7 Sekunden Zykluszeit einer Montageanlage nur durch den Wechsel von einer 315 zu einer 317.
Dann reden wir natürlich nicht von Schrittketten, die in jedem Schritt Sekunden oder gar Minuten auf einen Aktor ein Prozess warten...
 
Meistens werden Schrittketten durch Wartezeiten verlangsamt. Warten auf Vollzugsmeldungen der relativ trägen Mechanik/Hydraulik.
Wartezeiten, die weit jenseits der ZyklusZeit liegen.

Auch wenn deine Mechanik noch so langsam ist, wirst du die Verringerung der Taktzeit haben.
Das Weiterschalten dauert in der Regel min. 1 Zyklus. 300 Schritte mal vielleicht 10ms Ersparnis = 3s.
Dazu noch Effekte durch schnelleres Aktualisieren des Prozeeabbilds und schon hast du eine nette Anlagenoptimierung.

Ich hab schon öfter die CPU als Optimierungsmaßnahme getauscht.
Ist manchen Fällen die deutlich einfachere und günstigere Methode.
 
Der Analogwert wird nur alle 20ms aktualisiert und die Zykluszeit beträgt < 2ms.
Warum sollte man nun diese Berechnung denn jetzt zyklisch durchführen wenn doch bei Wertänderung reicht?

Ganz einfach, dass wenn die Analoge-Baugruppe mal upgegraded wird es auch schneller aktualisiert wird. Selbes Thema warum manche SPS Programme nicht mehr funktionieren weil man ne schnellere CPU einbaut wo dann aufeinmal der OB1 schneller ist als die Weckalarme und diese die Flanken aus dem Hauptprogramm nicht mehr sehen. Man könnte auch einfach eine Abfrage auf Änderung einfügen und dann den Teil abarbeiten.

Bei Schrittketten konnte ich diesen Effekt schon ein paar mal beobachten. Die SPS wartet ja im Schnitt einen halben SPS-Zyklus länger als Notwendig in jedem Schritt, bis die Transition erfüllt ist. Wenn dann noch bei einem Schritt in Graph zwei SPS-Zyklen verstreichen, obwohl der Schritt logisch übersprungen hätte werden können, wird der Effekt noch verstärkt. Ich erinnere mich an eine Optimierung von gut 8 auch knapp 7 Sekunden Zykluszeit einer Montageanlage nur durch den Wechsel von einer 315 zu einer 317.
Dann reden wir natürlich nicht von Schrittketten, die in jedem Schritt Sekunden oder gar Minuten auf einen Aktor ein Prozess warten...

In TIA gibt es eine Parametrierung die es erlaubt einen Schritt sofort weiterzuschalten bei erfüllter Transition.

Des weiteren die Aussage dass man bedingte Programmabarbeitung nicht anwenden sollte halte ich persönlich für inpraktikabel. Selber vermeide ich zwar Sprungmarken in meinen Bausteinen allerdings beende ich meine Bausteine vorzeitig wenn die Bedingung für Abarbeitung nicht gegeben ist. In jedes Netzwerk die Bedingung einzufügen dass er jetzt bitte nichts tun soll bläht für mich das Programm unleserlich auf.
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
Des weiteren die Aussage dass man bedingte Programmabarbeitung nicht anwenden sollte halte ich persönlich für inpraktikabel.
Wie immer lässt sich nicht die eine PatentLösung angeben, die für alle Anwendungen gleichermassen gültig ist.

Wenn die PLC nicht ohnehin die Möglichkeit bietet, eine MindestZyklusZeit zu projektieren (auf die die ZyklusZeit aufgebläht wird, wenn die PLC schneller mit einem Durchlauf fertig ist), dann kann man doch selbst am Ende eines "zu kurzen" Zyklus noch eine Wartezeit einfügen.
Warum diese "kontraproduktive" Idee? Häufig ist es wichtiger, eine schmale SchwankungsBreite der ZyklusZeit einzuhalten, als regelmässig eine möglichst kurze ZyklusZeit zu erzielen.

Selber vermeide ich zwar Sprungmarken in meinen Bausteinen allerdings beende ich meine Bausteine vorzeitig wenn die Bedingung für Abarbeitung nicht gegeben ist.
Das ist definitiv übersichtlicher und weniger aufwendig als . . .
In jedes Netzwerk die Bedingung einzufügen dass er jetzt bitte nichts tun soll bläht für mich das Programm unleserlich auf.
Schliesslich führt das Aufblähen des Programms durch das Einbauen vieler "Abkürzungen" auch zu zusätzlicher Ausführungszeit - was gerne mal übersehen wird.
Wenn im EndEffekt als NormalFall die verlängerte ZyklusZeit bleibt und nur in AusnahmeFällen die ZyklusZeit verkürzt wird, dann ist die Effektivität einer solchen Massnahme sowieso fragwürdig.
 
Beispielprogramme wären nicht schlecht ..... wo man sich [FONT=Verdana,Arial,Tahoma,Calibri,Geneva,sans-serif]Tricks und Kniffe für den Alltag abschauen könnte.
Ich bin immer wieder [FONT=Verdana,Arial,Tahoma,Calibri,Geneva,sans-serif]beeindruckt wenn ich so heiße Themen wie dieses hier lese...…. [FONT=Verdana,Arial,Tahoma,Calibri,Geneva,sans-serif]Respekt ...…
Tolle[FONT=Verdana,Arial,Tahoma,Calibri,Geneva,sans-serif] viele Denkanstöße in Punkto "[FONT=Verdana,Arial,Tahoma,Calibri,Geneva,sans-serif]performanteste Art zu programmieren" da muß ich mir mal Gedanken machen was ich bei mir alles ändern kann.

Tolles Thema schönen Abend zusammen
[/FONT][/FONT][/FONT][/FONT]
[/FONT]
 
Zuviel Werbung?
-> Hier kostenlos registrieren
erläuter mir mal was an meiner Aussage bzgl. der bedingten Programmierung nu kontraproduktiv war.
Gar nichts. Ich meinte damit meinen Gedankengang, bei schwankenden ZyklusZeiten die Zykluszeit künstlich zu verlängern, damit sie weniger stark schwankt..
 
Beispielprogramme wären nicht schlecht ..... wo man sich Tricks und Kniffe für den Alltag abschauen könnte.
Ich bin immer wieder beeindruckt wenn ich so heiße Themen wie dieses hier lese...…. Respekt ...…
Tolle viele Denkanstöße in Punkto "performanteste Art zu programmieren" da muß ich mir mal Gedanken machen was ich bei mir alles ändern kann.

Das hier ist von mir. Hier mache ich genau etwas ziemlich gefährliches. Man kann ein mir von der Grösse nicht bekanntes Array anhängen. Welches dann element für element abgearbeitet wird.
Ist beim Roten teil das erste Element erfüllt, dann ist der Baustein ziemlich schnell beendet. Aber im Extremfall kann es ja auch 5 mal das Array durchlaufen und nix finden.
Für mich funktioniert das jetzt da die Arrays eh nur aus wenigen 100 Elementen bestehen. Aber wenn man das nicht beachtet kann bei solchen Konstruktionen aus dem Nichts eine Zykluszeitüberschreitung passieren.
Das ist auch so ein Typisches Beispiel. Schnell geschrieben, leicht zu verstehen aber nicht optimal.

Code:
FUNCTION "GesamtBetriebsart" : Int
{ S7_Optimized_Access := 'TRUE' }
VERSION : 0.1
   VAR_INPUT 
      BA_Array : Array
[*] of Int;   // Hier Array mit allen Objektbetriebsarten anlegen
      P1_Mode : Int;   // Betriebsart mit höchster Anzuzeigender Priorität (Revision = 4)
      P2_Mode : Int;
      P3_Mode : Int;
      P4_Mode : Int;
      P5_Mode : Int;   // Betriebsart mit niedrigster Prio (Automatik = -1)
   END_VAR


   VAR_TEMP 
      Lower : DInt;
      Upper : DInt;
      index : DInt;
   END_VAR




BEGIN
	#GesamtBetriebsart := -1;
	#Lower := LOWER_BOUND(ARR := #BA_Array, DIM := 1);
	#Upper := UPPER_BOUND(ARR:= #BA_Array, DIM:= 1);
	
[COLOR=#ff0000]	FOR #index := #Lower TO #Upper DO[/COLOR]
[COLOR=#ff0000]	    IF #BA_Array[#index] = #P1_Mode THEN[/COLOR]
[COLOR=#ff0000]	        #GesamtBetriebsart := #P1_Mode;[/COLOR]
[COLOR=#ff0000]	        GOTO Ende;[/COLOR]
[COLOR=#ff0000]	    END_IF;[/COLOR]
[COLOR=#ff0000]	END_FOR;[/COLOR]
	    
	FOR #index := #Lower TO #Upper DO
	    IF #BA_Array[#index] = #P2_Mode THEN
	        #GesamtBetriebsart := #P2_Mode;
	        GOTO Ende;
	    END_IF;
	END_FOR;
	
	FOR #index := #Lower TO #Upper DO
	    IF #BA_Array[#index] = #P3_Mode THEN
	        #GesamtBetriebsart := #P3_Mode;
	        GOTO Ende;
	    END_IF;
	END_FOR;
	
	FOR #index := #Lower TO #Upper DO
	    IF #BA_Array[#index] = #P4_Mode THEN
	        #GesamtBetriebsart := #P4_Mode;
	        GOTO Ende;
	    END_IF;
	END_FOR;
	
	FOR #index := #Lower TO #Upper DO
	    IF #BA_Array[#index] = #P5_Mode THEN
	        #GesamtBetriebsart := #P5_Mode;
	        GOTO Ende;
	    END_IF;
	END_FOR;
	
	Ende:;
	    
END_FUNCTION
 
Das hier ist von mir. Hier mache ich genau etwas ziemlich gefährliches. Man kann ein mir von der Grösse nicht bekanntes Array anhängen. Welches dann element für element abgearbeitet wird.
Ist beim Roten teil das erste Element erfüllt, dann ist der Baustein ziemlich schnell beendet. Aber im Extremfall kann es ja auch 5 mal das Array durchlaufen und nix finden.
Für mich funktioniert das jetzt da die Arrays eh nur aus wenigen 100 Elementen bestehen. Aber wenn man das nicht beachtet kann bei solchen Konstruktionen aus dem Nichts eine Zykluszeitüberschreitung passieren.
Das ist auch so ein Typisches Beispiel. Schnell geschrieben, leicht zu verstehen aber nicht optimal.

Code:
FUNCTION "GesamtBetriebsart" : Int
{ S7_Optimized_Access := 'TRUE' }
VERSION : 0.1
   VAR_INPUT 
      BA_Array : Array
[*] of Int;   // Hier Array mit allen Objektbetriebsarten anlegen
      P1_Mode : Int;   // Betriebsart mit höchster Anzuzeigender Priorität (Revision = 4)
      P2_Mode : Int;
      P3_Mode : Int;
      P4_Mode : Int;
      P5_Mode : Int;   // Betriebsart mit niedrigster Prio (Automatik = -1)
   END_VAR


   VAR_TEMP 
      Lower : DInt;
      Upper : DInt;
      index : DInt;
   END_VAR




BEGIN
    #GesamtBetriebsart := -1;
    #Lower := LOWER_BOUND(ARR := #BA_Array, DIM := 1);
    #Upper := UPPER_BOUND(ARR:= #BA_Array, DIM:= 1);
    
[COLOR=#ff0000]    FOR #index := #Lower TO #Upper DO[/COLOR]
[COLOR=#ff0000]        IF #BA_Array[#index] = #P1_Mode THEN[/COLOR]
[COLOR=#ff0000]            #GesamtBetriebsart := #P1_Mode;[/COLOR]
[COLOR=#ff0000]            GOTO Ende;[/COLOR]
[COLOR=#ff0000]        END_IF;[/COLOR]
[COLOR=#ff0000]    END_FOR;[/COLOR]
        
    FOR #index := #Lower TO #Upper DO
        IF #BA_Array[#index] = #P2_Mode THEN
            #GesamtBetriebsart := #P2_Mode;
            GOTO Ende;
        END_IF;
    END_FOR;
    
    FOR #index := #Lower TO #Upper DO
        IF #BA_Array[#index] = #P3_Mode THEN
            #GesamtBetriebsart := #P3_Mode;
            GOTO Ende;
        END_IF;
    END_FOR;
    
    FOR #index := #Lower TO #Upper DO
        IF #BA_Array[#index] = #P4_Mode THEN
            #GesamtBetriebsart := #P4_Mode;
            GOTO Ende;
        END_IF;
    END_FOR;
    
    FOR #index := #Lower TO #Upper DO
        IF #BA_Array[#index] = #P5_Mode THEN
            #GesamtBetriebsart := #P5_Mode;
            GOTO Ende;
        END_IF;
    END_FOR;
    
    Ende:;
        
END_FUNCTION

das tut man ja auch nicht, schleife einmal und in der schleife das Array mit Hilfe einer Case (oder If / Elsif) Konstrukt das Array bzw. dessen Inhalt prüfen - dann brauchst auch keine GOTO und es reicht ein einfaches Exit
Allerdings ändert es dein beschriebenes Verhalten nur bedingt - die Laufzeit ist immer noch abhängig von der Größe des Arrays und dem platz der Übereinstimmung im Array :-)

Wie einer der Vorredner schon gesagt hat, 100 Wege führen nach Rom - gleich kommt noch einer um die Ecke und macht dein Beispiel ganz anders - mit einem Baum zum Bsp. ;-)
VG
 
Zuviel Werbung?
-> Hier kostenlos registrieren
das tut man ja auch nicht, schleife einmal und in der schleife das Array mit Hilfe einer Case (oder If / Elsif) Konstrukt das Array bzw. dessen Inhalt prüfen - dann brauchst auch keine GOTO und es reicht ein einfaches Exit
Allerdings ändert es dein beschriebenes Verhalten nur bedingt - die Laufzeit ist immer noch abhängig von der Größe des Arrays und dem platz der Übereinstimmung im Array :-)

Kannst du mir ein Beispiel machen wie du das meinst? Denn ich will wirklich P1 drin haben wenn eines der Elemente mit P1 übereinstimmt. Also mit welcher Bedingung willst du die Schleife verlassen?

mfG René
 
Kannst du mir ein Beispiel machen wie du das meinst? Denn ich will wirklich P1 drin haben wenn eines der Elemente mit P1 übereinstimmt. Also mit welcher Bedingung willst du die Schleife verlassen?

mfG René

so in der Art hatte ich gemeint:
Code:
FUNCTION "GesamtBetriebsart" : Int{ S7_Optimized_Access := 'TRUE' }
VERSION : 0.1
   VAR_INPUT 
      BA_Array : Array
[*] of Int;   // Hier Array mit allen Objektbetriebsarten anlegen
      P1_Mode : Int;   // Betriebsart mit höchster Anzuzeigender Priorität (Revision = 4)
      P2_Mode : Int;
      P3_Mode : Int;
      P4_Mode : Int;
      P5_Mode : Int;   // Betriebsart mit niedrigster Prio (Automatik = -1)
   END_VAR


   VAR_TEMP 
      Lower : DInt;
      Upper : DInt;
      index : DInt;
      Mode : Int;
   END_VAR


BEGIN
    #GesamtBetriebsart := -1;
    #Lower := LOWER_BOUND(ARR := #BA_Array, DIM := 1);
    #Upper := UPPER_BOUND(ARR:= #BA_Array, DIM:= 1);
    
    FOR #index := #Lower TO #Upper DO
        // get mode from array
        #Mode := #BA_Array[#index];
        // check which mode is active
        IF #Mode = #P1_Mode THEN
            #GesamtBetriebsart := #P1_Mode;
            EXIT;
        ELSIF #Mode = #P2_Mode THEN
            #GesamtBetriebsart := #P2_Mode;
            EXIT;
        ELSIF #Mode = #P3_Mode THEN
            #Mode := #P3_Mode;
            EXIT;
        ELSIF #BA_Array[#index] = #P4_Mode THEN
            #Mode := #P4_Mode;
            EXIT;
        ELSIF #BA_Array[#index] = #P5_Mode THEN
            #Mode := #P5_Mode;
            EXIT;
        ELSE
            ; // no match
        END_IF;
    END_FOR;
        
END_FUNCTION
 
Zuletzt bearbeitet:
so in der Art hatte ich gemeint:
Code:
FUNCTION "GesamtBetriebsart" : Int{ S7_Optimized_Access := 'TRUE' }
VERSION : 0.1
   VAR_INPUT 
      BA_Array : Array
[*] of Int;   // Hier Array mit allen Objektbetriebsarten anlegen
      P1_Mode : Int;   // Betriebsart mit höchster Anzuzeigender Priorität (Revision = 4)
      P2_Mode : Int;
      P3_Mode : Int;
      P4_Mode : Int;
      P5_Mode : Int;   // Betriebsart mit niedrigster Prio (Automatik = -1)
   END_VAR


   VAR_TEMP 
      Lower : DInt;
      Upper : DInt;
      index : DInt;
      Mode : Int;
   END_VAR


BEGIN
    #GesamtBetriebsart := -1;
    #Lower := LOWER_BOUND(ARR := #BA_Array, DIM := 1);
    #Upper := UPPER_BOUND(ARR:= #BA_Array, DIM:= 1);
    
    FOR #index := #Lower TO #Upper DO
        // get mode from array
        #Mode := #BA_Array[#index];
        // check which mode is active
        IF #Mode = #P1_Mode THEN
            #GesamtBetriebsart := #P1_Mode;
            EXIT;
        ELSIF #Mode = #P2_Mode THEN
            #GesamtBetriebsart := #P2_Mode;
            EXIT;
        ELSIF #Mode = #P3_Mode THEN
            #Mode := #P3_Mode;
            EXIT;
        ELSIF #BA_Array[#index] = #P4_Mode THEN
            #Mode := #P4_Mode;
            EXIT;
        ELSIF #BA_Array[#index] = #P5_Mode THEN
            #Mode := #P5_Mode;
            EXIT;
        ELSE
            ; // no match
        END_IF;
    END_FOR;
        
END_FUNCTION

Ich glaub nicht dass das so funktioniert. denn wenn jetzt ein p1 modus später als ein p2 modus im array auftaucht kommt du da ja nicht hin weil du bei übereinstimmunt von p2_mode auf mode die schleife schon verlassen hast.

Den zyklus recht gleichmässig beeinflussen täte man aber z.B. so.

Code:
FUNCTION "GesamtBetriebsart" : Int
{ S7_Optimized_Access := 'TRUE' }
VERSION : 0.1
   VAR_INPUT 
      BA_Array : Array
[*] of Int;   // Hier Array mit allen Objektbetriebsarten anlegen
      P1_Mode : Int;   // Betriebsart mit höchster Anzuzeigender Priorität (Revision = 4)
      P2_Mode : Int;
      P3_Mode : Int;
      P4_Mode : Int;
      P5_Mode : Int;   // Betriebsart mit niedrigster Prio (Automatik = -1)
   END_VAR


   VAR_TEMP 
      Lower : DInt;
      Upper : DInt;
      index : DInt;
   END_VAR




BEGIN
    #GesamtBetriebsart := -1;
    #Lower := LOWER_BOUND(ARR := #BA_Array, DIM := 1);
    #Upper := UPPER_BOUND(ARR:= #BA_Array, DIM:= 1);
    
    FOR #index := #Lower TO #Upper DO
        IF #BA_Array[#index] = #P1_Mode OR #GesamtBetriebsart = #P1_Mode THEN
            #GesamtBetriebsart := #P1_Mode;
        ELSIF #BA_Array[#index] = #P2_Mode OR #GesamtBetriebsart = #P2_Mode THEN
            #GesamtBetriebsart := #P2_Mode;
        ELSIF #BA_Array[#index] = #P3_Mode OR #GesamtBetriebsart = #P3_Mode THEN
            #GesamtBetriebsart := #P3_Mode;
        ELSIF #BA_Array[#index] = #P4_Mode OR #GesamtBetriebsart = #P4_Mode THEN
            #GesamtBetriebsart := #P4_Mode;
        ELSIF #BA_Array[#index] = #P5_Mode OR #GesamtBetriebsart = #P5_Mode THEN
            #GesamtBetriebsart := #P5_Mode;
        END_IF;
    END_FOR;
        
END_FUNCTION
 
Zuviel Werbung?
-> Hier kostenlos registrieren
@Vollmi:
wenn, wie in deinem Beispiel, das Auffinden von P1 immer Vorrang vor P2 und P2 wiederum Vorrang vor P3 hat usw. dann könntest du höchstens, falls du ein Problem mit der Zykluszeit-Erhöhung erwartest, die 5 (oder mehr) Einzel-Überprüfungen (also die 5 Schleifen deines Beispiels) auf 5 Programm-Zyklen verteilen. Das würde die Lesbarkeit des dargestellten Codes nicht verschlechtern (oder jedenfalls nicht gravierend).

Gruß
Larry
 
@Vollmi:
wenn, wie in deinem Beispiel, das Auffinden von P1 immer Vorrang vor P2 und P2 wiederum Vorrang vor P3 hat usw. dann könntest du höchstens, falls du ein Problem mit der Zykluszeit-Erhöhung erwartest, die 5 (oder mehr) Einzel-Überprüfungen (also die 5 Schleifen deines Beispiels) auf 5 Programm-Zyklen verteilen. Das würde die Lesbarkeit des dargestellten Codes nicht verschlechtern (oder jedenfalls nicht gravierend).

Jup das wäre ebenfalls eine Möglichkeit. Ich wollte da nur ein Beispiel bringen das zu unschönen Verhalten führen könnte. Mit den paar Integer Zahlen ist das nicht zu erwarten. Aber wenn man solche Konstrukte hat und da womöglich intensive Arbeiten durchgeführt werden (stringbearbeitung zusätzliche Funktionen etc) sollte man wissen wo man sich sowas (Quit and little dirty) leisten kann und wo man etwas mehr energie auf Optimierung aufwendet.
 
OK ... verstanden ... wobei du so nebenher auch (aus meiner Sicht - wegen der Beteiligung mit Änderungsvorschlägen) auch gleich ein Beispiel für gut lesbaren und verständlichen Code (und dessen Wichtigkeit) gebracht hast ... ;)

Gruß
Larry
 
Zurück
Oben