Grundsätzlich: Warum AWL ?

Zuviel Werbung?
-> Hier kostenlos registrieren
Ich denke mal, vierlagig wollte mit seinem Code ein Beispiel pro AWL geben.

Dabei zeigt sich aber fast alles, was AWL "ausmacht".
Der Code ist trotz Kommentaren schlecht lesbar, nach einem viertel Jahr Pause muss man wahrscheinlich selber nochmal drüber nachdenken, was man da eigentlich gemacht hat.
Durch AWL noch äußerst kryptisch und dank der Adressregisterbefehle für einen Nicht-AWL Kenner absolut nicht nachvollziehbar.
Die Krönung sind dann die Sprungbefehle, damit wir einen schönen und zurecht gefürchteten Spaghetticode fabrizieren können.
Das ist keine Kritik am eigentlichen Code, der ist ja für AWL Verhältnisse ganz ordentlich geschrieben, führt mir aber immer wieder vor Augen, warum auf Nicht-S7-Steuerungen keiner freiwillig in AWL programmiert.

Wahrscheinlich machen die Leute einfach mit AWL rum, weil sie zeigen wollen, das mans einfach drauf hat.....;)
 
Achtung: politische Hetze.

Ich denke mal, vierlagig wollte mit seinem Code ein Beispiel pro AWL geben.

Dabei zeigt sich aber fast alles, was AWL "ausmacht".
Der Code ist trotz Kommentaren schlecht lesbar, nach einem viertel Jahr Pause muss man wahrscheinlich selber nochmal drüber nachdenken, was man da eigentlich gemacht hat.
Durch AWL noch äußerst kryptisch und dank der Adressregisterbefehle für einen Nicht-AWL Kenner absolut nicht nachvollziehbar.
Die Krönung sind dann die Sprungbefehle, damit wir einen schönen und zurecht gefürchteten Spaghetticode fabrizieren können.
Das ist keine Kritik am eigentlichen Code, der ist ja für AWL Verhältnisse ganz ordentlich geschrieben, führt mir aber immer wieder vor Augen, warum auf Nicht-S7-Steuerungen keiner freiwillig in AWL programmiert.

Wahrscheinlich machen die Leute einfach mit AWL rum, weil sie zeigen wollen, das mans einfach drauf hat.....;)

Das ist doch alles gequirlter Quark.

Der Sage nach soll es Programmierer geben, die verstehen ihren eigenen SCL-Code von vor 4 Wochen nicht mehr.:ROFLMAO:

Die "Leute" machen mit AWL rum, weil es ein Standard ist, den man in der Simaticwelt überall findet und mit etwas Erfahrung auch versteht. Selbst SCL-Programmteile kann man mit AWL-Kenntnissen verstehen, das Kompilat von SCL ist ja auch nur eine Teilmenge von AWL.

Das Beispiel von vierlagig zeigt IMHO vorallem, dass es Situationen gibt, wo AWL einfacher ist als aller andere Krampf. Da schließe ich ausdrücklich auch die Sprungbefehle mit ein. (Goto-freie Programmierung in Assembler geht ja "leider" immer noch nicht)

Spaghetti-Code kannste übrigens in jeder Programmiersprache erzeugen.
Den Überblick verlieren auch!
 
Der Sage nach soll es Programmierer geben, die verstehen ihren eigenen SCL-Code von vor 4 Wochen nicht mehr.:ROFLMAO:
*ACK*
Das kommt mit jeder Programmiersprache vor

Ich denke mal, vierlagig wollte mit seinem Code ein Beispiel pro AWL geben.
...
Der Code ist trotz Kommentaren schlecht lesbar, ...
Durch AWL noch äußerst kryptisch und dank der Adressregisterbefehle für einen Nicht-AWL Kenner absolut nicht nachvollziehbar.
Die Krönung sind dann die Sprungbefehle, damit wir einen schönen und zurecht gefürchteten Spaghetticode fabrizieren können.
... führt mir aber immer wieder vor Augen, warum auf Nicht-S7-Steuerungen keiner freiwillig in AWL programmiert.

Ich bin ein Nicht-AWL-Kenner und verstehe den Code von vierlagig überhaupt nicht.
Die Schlüssel-"Buchstaben" T, L, SRW, +AR1, BTI, SPA, TAK, SPBN ... usw sind für mich nicht verständlich, bzw. ansatzweise selbstklärend.
Alle anderen Programmiersprachen kann ich wenigstens halbwegs nachvollziehen, auch wenn ich nie mit denen programmiere.
SCL (ST) ist für alle, die mal ein wenig in die Welt der Hochsprachen reingeschuppert haben gut verständlich, da die Schlüsselwörter und Operatoren meist selbstklärens sind (IF, CASE, <, >=, OR, AND, uws.)

Die "Leute" machen mit AWL rum, weil es ein Standard ist, den man in der Simaticwelt überall findet und mit etwas Erfahrung auch versteht.
Das wird's sein. Hat sich seit den Anfängen, wo auch Assembler noch weit verbreitet war, als Grundlagensprache gehalten, ist in der Welt der Simatic wohl auch die mächtigste Sprache und wurde durch die Verbreitung der Siemens-Steuerungen allgemein als "Standard"-Sprache fortgeführt.
Aber "mächtigste" vielleicht nur, weil die anderen Sprachen der Siemens-Welt defizite Aufweisen bzw. im Fall von SCL zusätzliche Kosten verursachen, würde ich mal vermuten.

Ich als Nicht-Siemens-Nutzer glaube dennoch, dass man AWL heutzutage nicht "braucht". Erst recht nicht in der Nicht-Siemens-Welt.
Natürlich bin ich durch TwinCAT (CoDeSys) verwöhnt, da man kein Register-Schieben, Speicher-Wurschteln macht. Die konsequente Verwendung von Variablen anstatt absolute Speicherbereiche ist für mich zudem ein genormer Vorteil bzgl. Vermeidung von Programmierfehlern.
Mit SCL (ST) kommt man meiner Meinung nach mindestens genauso weit, bei besserer Übersichtlichkeit.
 
Das wird's sein. Hat sich seit den Anfängen, wo auch Assembler noch weit verbreitet war, als Grundlagensprache gehalten, ist in der Welt der Simatic wohl auch die mächtigste Sprache und wurde durch die Verbreitung der Siemens-Steuerungen allgemein als "Standard"-Sprache fortgeführt.
Aber "mächtigste" vielleicht nur, weil die anderen Sprachen der Siemens-Welt defizite Aufweisen bzw. im Fall von SCL zusätzliche Kosten verursachen, würde ich mal vermuten.

Wobei Siemens-SCL immer noch die Mächtigkeit von AWL fehlt, weil es spezielle Konstrukte gibt die sich immer noch nur in AWL lösen lassen (auch wenn das sehr spezielle Fälle sind).

Hauptgrund dafür ist meiner Meinung nach das Fehlen eines "echten" Pointers in SCL. Bei meinen ersten Schritten in Codesys-ST habe ich immer das ANY-Konstrukt von Siemens vermisst. Mittlerweile habe ich aber erkannt, dass der "Pointer to xy" in Codesys viel mächtiger und auch einfacher zu handhaben ist.
Das ANY-Konstrukt von Siemens ist wohl der quasi-segmentierten Speicherverwaltung geschuldet (E/A-Abbild, Merker, Lokaldaten, DBn). Das macht eben auch die indirekte Adressierung in AWL so kryptisch, 4l hat ja gerade ein schönes Beispiel geliefert.

Ich schaue des öfteren bei plctalk.com rein. Dort tauchen auch regelmäßig Fragen zur indirekten Adressierung in Siemens AWL auf. Vor allem verstehen die Leute nicht, warum z.B. Schleifenkonstruktionen in AWL so aufwändig sein müssen. Ich kenne z.B. die in den USA üblichen AB Steuerungen nicht, aber dort kann ich, wenn ich das richtig verstanden habe, wohl auch in KOP ein Array mittels eines variablen Schleifenindex ansprechen.
Für soetwas muss bei Siemens-AWL gleich wieder die Adressregister-Keule rausgeholt werden. Gut, wenn man das einmal verinnerlicht hat tippt sich das schnell runter, aber warum so kompliziert? Für Bausteinaufrufe, Zugriffe auf UDT-Parameter und dergleichen schafft es der Step7-Editor auch verschiendene Makros einzusetzen, warum gibt es sowas nicht auch für Arrays mit variablem Index?
 
Zuviel Werbung?
-> Hier kostenlos registrieren
@trinitaucher: falls du mal zeit und lust hast, kannste folgendes mal in SCL umsetzen ... würde mich interessieren, hab selber aber leider grad keine zeit.

so, jetzt hab ich mir die 15minuten mal genommen

Code:
*
FUNCTION FC1500 : VOID
VAR_INPUT
    dtSource : DATE_AND_TIME;
    anyDestination : ANY;
END_VAR
VAR_TEMP
    myDateTime : DATE_AND_TIME;
    myDateArray AT myDateTime : ARRAY[0..7] OF BYTE;    
    myAnyDestination : ANY;    
    myDestination AT myAnyDestination : ARRAY[0..4] OF WORD;            
    myByte : INT;    
    i : INT;       
END_VAR

    myAnyDestination := anyDestination;
    myByte := (WORD_TO_INT(myDestination[4])/8 + WORD_TO_INT(myDestination[3])*8192);
        
    myDateTime := dtSource;
                
    IF myDestination[2] <> 0 THEN
        FOR i:= 0 TO 12 BY 2 DO
            CASE i/2 OF
                0..5: WORD_TO_BLOCK_DB(myDestination[2]).DW[myByte+i]:= INT_TO_WORD(BCD_TO_INT(myDateArray[i/2])); 
                   6: WORD_TO_BLOCK_DB(myDestination[2]).DW[myByte+i]:= INT_TO_WORD(BCD_TO_INT(myDateArray[i/2])*10 + BCD_TO_INT(myDateArray[i/2 + 1] AND 16#00F0)/10);
                      WORD_TO_BLOCK_DB(myDestination[2]).DW[myByte+i+2]:= INT_TO_WORD(BCD_TO_INT(myDateArray[i/2 + 1] AND 16#000F)) ;
            END_CASE; 
        END_FOR;
    ELSE
        FOR i:= 0 TO 12 BY 2 DO
            CASE i/2 OF
                0..5: MW[myByte+i] := INT_TO_WORD(BCD_TO_INT(myDateArray[i/2])); 
                   6: MW[myByte+i] := INT_TO_WORD(BCD_TO_INT(myDateArray[i/2])*10 + BCD_TO_INT(myDateArray[i/2 + 1] AND 16#00F0)/10);
                      MW[myByte+i+2] := INT_TO_WORD(BCD_TO_INT(myDateArray[i/2 + 1] AND 16#000F)) ;
            END_CASE;                 
        END_FOR;
    END_IF;
    
END_FUNCTION

jetzt brauch ich nur noch nen SCL-guru, der mir erklärt, wie ich in SCL auf die lokaldaten des vorgängerbausteins zugreifen kann, damit aus der quelle wieder ein any werden kann...
 
Zuletzt bearbeitet:
Was ich bei der Diskussion nicht nachvollziehen kann ist, dass die AWL-Fans hier so schlecht von SCL reden, im Sinne der Handhabung.

Im Studium ist es eine Selbstverständlichkeit zuerst eine Hochsprache zu lernen (heutzutage wohl C++) und im späteren Verlauf erlernt man dann Essembler.
Das hat denke ich den Grund, dass ST erstmal leichter zu verstehen ist. Wenn man ganz am Anfang des Progrmmieren steht muss man ja erstmal mit der Kommunikation und Denkweise dieser Maschinen zurecht kommen. Und in ST schreibt man, wie man denkt. Eine IF-Anweisung ist auch nur eine Erweiterung der IF-Clauses die man im Englischunterricht lernt. "Wenn ich zu viel Eis esse, dann bekomme ich Kopfschmerzen" Logisch!

Essembler ist erst dann zu verstehen, wenn man die ALU eines Prozessors verstanden hat und sich mit den Registern auskennt. Vorher macht das für mich keinen Sinn. Ich hatte dann Leute neben mir sitzen, denen bis zum Ende nicht klar war, warum jeder so lustige Speicheradressen wie 20FF benutzt. Er dachte man denkt sich da einfach was aus. So macht das keinen Sinn.

Damit will ich sagen, wer angeblich so gut Programmieren kann, der kann mir nicht erzählen, dass ST kompliziert ist. Vielleicht programmiet ihr dann nur so gut AWL, weil ihr es vor Jahren gelernt habt und es für euch rotine ist an gewisse Problemstellungen so und so herran zu treten. Ich will da gar nichts gegen sagen. Ich denke so arbeiten die meißten.

Nur als ich Essembler gelernt habe, da war der Hintergrund für mich ein ganz anderer. Da haben wir µC programmiert weil wir kein OS hatten oder sonst irgendeine Umgebung in der man programmieren konnte. Aber solange ich ein Programm geschrieben habe, habe ich wieder auf C oder später C++ zurück gegriffen, weil es doch bequeme ist. Ich käme nie auf die Idee ein Windows-Tool für den täglichen Gerauch anders zu schreiben.
 
Code:
*
FUNCTION FC1500 : VOID
VAR_INPUT
    dtSource : DATE_AND_TIME;
    anyDestination : ANY;
END_VAR
VAR_TEMP
    myDateTime : DATE_AND_TIME;
    myDateArray AT myDateTime : ARRAY[0..7] OF BYTE;    
    myAnyDestination : ANY;    
    myDestination AT myAnyDestination : ARRAY[0..4] OF WORD;            
    myByte : INT;    
    i : INT;       
END_VAR

    myAnyDestination := anyDestination;
    myByte := (WORD_TO_INT(myDestination[4])/8 + WORD_TO_INT(myDestination[3])*8192);
        
    myDateTime := dtSource;
                
    IF myDestination[2] <> 0 THEN
        FOR i:= 0 TO 12 BY 2 DO
            CASE i/2 OF
                0..5: WORD_TO_BLOCK_DB(myDestination[2]).DW[myByte+i]:= INT_TO_WORD(BCD_TO_INT(myDateArray[i/2])); 
                   6: WORD_TO_BLOCK_DB(myDestination[2]).DW[myByte+i]:= INT_TO_WORD(BCD_TO_INT(myDateArray[i/2])*10 + BCD_TO_INT(myDateArray[i/2 + 1] AND 16#00F0)/10);
                      WORD_TO_BLOCK_DB(myDestination[2]).DW[myByte+i+2]:= INT_TO_WORD(BCD_TO_INT(myDateArray[i/2 + 1] AND 16#000F)) ;
            END_CASE; 
        END_FOR;
    ELSE
        FOR i:= 0 TO 12 BY 2 DO
            CASE i/2 OF
                0..5: MW[myByte+i] := INT_TO_WORD(BCD_TO_INT(myDateArray[i/2])); 
                   6: MW[myByte+i] := INT_TO_WORD(BCD_TO_INT(myDateArray[i/2])*10 + BCD_TO_INT(myDateArray[i/2 + 1] AND 16#00F0)/10);
                      MW[myByte+i+2] := INT_TO_WORD(BCD_TO_INT(myDateArray[i/2 + 1] AND 16#000F)) ;
            END_CASE;                 
        END_FOR;
    END_IF;
    
END_FUNCTION
Anscheinend gibt's in SCL mehrere Befehle, die in CoDeSys/TwinCAT nicht gehen. ANYs z.B.. Aber wenigstens verstehe ich jetzt einigermaßen, was gemacht wird.

Im Studium ist es eine Selbstverständlichkeit zuerst eine Hochsprache zu lernen (heutzutage wohl C++) und im späteren Verlauf erlernt man dann Essembler.
Bei uns war's umgekehrt. Zuerst die "Mikrocomputertechnik" mit Assemmbler, um die Computer zu "verstehen", später dann die Hochsprachen für die Applikationen.
Allerdings war Assembler nach rund 3 Wochen abgehakt und ich hab's bis heute nicht mehr gebraucht. Selbst mir bekannte Firmware-Programmierer nutzen nur noch C, da heutige Compiler angeblich genauso schlanken Code produzieren können, wie mit Assembler ... C is halt nur einfacher und führt daher bestimmt (zeit)effizienter zum Ziel :cool:

Je nach Aufgabenstellung und Gewohnheit bzw. Möglichkeiten sucht man sich "seine" Programmiersprache aus.

[...]Für einen Ausstieg aus dem Siemens AWL spricht die Inkonformität mit der IEC 61131-3 in Hinblick auf die Syntax. Siemens AWL stellt aber darüber hinaus Befehle zur Verfügung die die Norm nicht definiert, welche für die Mehrzahl der Anwender zum guten Ton gehören.

Für eine Verbannung des Gesamtkonstruktes Instruction List, wie sie in der Norm definiert gibt es objektiv keine nachvollziehbaren Gründe. Der Aufwand, aus SCL oder ST Maschinenverwertbaren Code zu generieren ist groß und das Ergebnis mit dem der IL-Kompilierung im Hinblick auf Speicherbedarf und Nachvollziehbarkeit nicht zu vergleichen. Auch sind die Freiheitsgrade der so oft als Maschinennah bezeichneten Sprache größer wenn es darum geht Register- und Speicherindirekt zu Adressieren. Geht es allerdings um Berechnungen, Schleifen- und Auswahlkonstrukte eignet sich die Umsetzung in SCL.

Eine Ablösung von Siemens-AWL durch SCL würde keinen adäquaten Ersatz schaffen.[...]
Diesen Abschnitt des zitierten Textes (woher ist der übrigens?) halte ich im übrigen nicht für ein Argument.
Mich als Programmierer kümmert es einen Dreck, ob der Compiler viel oder wenig Aufwand mit der Codeerzeugung hat. Und ob das Compilat ein Paar Bytes mehr weniger hat, kümmert mich eigentlich auch nicht. Heutzutage sollte der Speicher einer Hardware-SPS doch eigentlich ausreichend bemessen sein. Oder gibt's immer noch Situationen, wo man aufgrund von knappem Speicher zwingend in AWL programmieren muss, nur um Speicher zu sparen?
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ich versteh eure ziemlich dusselige Grundsatzdiskussion ohnehin nicht. Es ist wie immer jeder findet das, was er am Besten kennt als das besonders Gute, das ist doch ohnehin natürlich.

@trinitaucher
Ich finde es in jedem Falle besser, wenn man weiß, was genau hinter dem steckt, was man da gerade programmiert. Bei ST/SCL steht genau dieses spezifische Wissen aber rel. weit im Hintergrund. Das macht an sich nichts, aber ich hab schon eine ganze Menge Leute (auch Informatiker) erlebt, die eine Maschine nicht vernünftig zum laufen gebracht haben, weil sie eben nicht gut genug Bescheid wußten und nur in ihrem Hochsprachenturm lebten.

@4L
Dein AWL-Code ist aber nun auch nicht gerade alltäglich :)

@tymanis
Es geht da eher um den leider ziemlich simplen und bescheidenen SCL-Editor von Step7. Der kann in keinerlei Hinsicht mit einem modernen Werkzeug mithalten, die Debugfunktionen sind m.E. nach ebenfalls recht bescheiden.

Eine Maschine zu programmieren braucht es eigentlich nicht unbedingt so hochgreifender Mittel, wie Hochsprachen usw. Früher hat man das mit simplen Schützen erledigt, mußte aber genau nachdenken, wo denn der Strom seinen Weg nimmt und ob noch genügend Kontakte auf einem Schütz übrig waren für einen neue Funktion. Wenn ich sehe, was ich heute für Dinge in eine Maschinen hineinproggen muß (Weil irgendein Depp mal gehört oder gelesen hat...), die dann niemals genutzt werden, finde ich das teilweise schon bedenklich, denn es ist vergeudete Arbeitszeit, meine Arbeitszeit. Ich durfte mal in eine WinCC-Anlage mit 10 WinCC-Stationen jeweils einen Button einbauen, der dann ein Fenster mit einem Schulungsvideo für den Bediener öffnete. Das war absoluter Schwerpunkt, die Funktion der Anlage an sich trat da völlig in den Hintergrund. Das ist 3 Jahre her, ihr dürft raten, ob bisher ein Video zu Schulungszwecken hinterlegt wurde oder nicht...

Also wie immer bei diese Diskussion. Jeder darf Nutzen, was er am Besten kann, aber man sollte in der Wahl der Mittel auch einfach mal auf dem Boden bleiben. Für ein paar simple Bitverknüpfungen, braucht nun mal keiner eine Hochsprache.

Wenn ich daran denke, daß Codesys 3 Vererbung erlaubt (zumindest eingeschränkt), dann wird mit jetzt schon übel ob der Programme, die besonders kluge Leute daraus fabrizieren. Aber so ist das nun mal, ihr wißt ja, mit jeder Sprache kann man fürchterliche Programme zusammenferkeln.
 
Zuletzt bearbeitet:
Was ich bei der Diskussion nicht nachvollziehen kann ist, dass die AWL-Fans hier so schlecht von SCL reden, im Sinne der Handhabung.

Wenn du den SCL-Editor mal z.B. mit dem ST-Editor von Codesys vergleichst, dann weißt du warum.
Und das hat rein gar nichts mit Pro/Kontra SCL bzw. ST zu tun ...
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ich versteh eure ziemlich dusselige Grundsatzdiskussion ohnehin nicht. Es ist wie immer jeder findet das, was er am Besten kennt als das besonders Gute, das ist doch ohnehin natürlich.
Volle Zustimmung für den letzten Satz, aber die Eröffnungsfrage des Thread war:
Ich hab mal an erfahrene Softwareentwickler eine einfache Frage:

Warum lese ich hier im Forum noch so oft AWL ? Ich denke wenn man keinen µC programmiert und nicht darauf angewiesen ist, dann bietet die Norm bei der SPS-Programmierung doch denkbar einfache alternativen um zu programmieren.
Hat das den Hintergrund, dass hier viele damit "aufgewachsen" sind oder seht ihr entscheidende Vorteile in AWL, warum ich SCL kaum hier im Forum lese?
Als Fazit bisher sehe ich die Schwerpunkte:
- AWL ist bei Siemens schlicht am mächtigsten
- AWL ist "eingebürgert" und viele erfahrene Programmierer nutzen es, da sie die Möglichkeiten gut zu nutzen wissen
- SCL wird vom S eher stiefmütterlich behandelt.

Eine Maschine zu programmieren braucht es eigentlich nicht unbedingt so hochgreifender Mittel, wie Hochsprachen usw. Früher hat man das mit simplen Schützen erledigt, mußte aber genau nachdenken, wo denn der Strom seinen Weg nimmt und ob noch genügend Kontakte auf einem Schütz übrig waren für einen neue Funktion.

Also wie immer bei diese Diskussion. Jeder darf Nutzen, was er am Besten kann, aber man sollte in der Wahl der Mittel auch einfach mal auf dem Boden bleiben. Für ein paar simple Bitverknüpfungen, braucht nun mal keiner eine Hochsprache.

Wenn ich daran denke, daß Codesys 3 Vererbung erlaubt (zumindest eingeschränkt), dann wird mit jetzt schon übel ob der Programme, die besonders kluge Leute daraus fabrizieren. Aber so ist das nun mal, ihr wißt ja, mit jeder Sprache kann man fürchterliche Programme zusammenferkeln.
Natürlich braucht es für die simpelten Aufgaben nicht unbedingt Hochsprachen, aber wieso verteufeln viele das Zusammenwachsen der SPS- und Hochsprachen-/IT-Welt?

Die SPSen sollen heutzutage nicht nur viel leisten, sie können heutzutage auch viel leisten.
Kann wieder nur für Beckhoffs TwinCAT sprechen, aber ich brauche dort keine extra NC-CPU, sondern alles läuft auf der SPS. Komplexe Berechnungen, einfache Logik und dazu noch Datenhandling mit Archivierungen (inkl. Datei lesen/schreiben), Kommunikation mit nahezu jedem beliebigen "Partner" ... alles aus der "SPS" (bzw. dem PC) heraus.
Laut Beckhoff sind wir erst am Anfang der "Scientific Automation". Mit den Möglichkeiten steigen die Anforderungen und dann braucht man auch entsprechende Werkzeuge, um diese effizient zu erfüllen.
Und so wie man heutzutage Applikationen nicht mehr unbedingt in Assembler programmieren muss, braucht man meiner Meinung nach auch AWL nicht mehr unbedingt.
 
Zuletzt bearbeitet:
Ich habe heute etwas ganz neues gesehen.
Ein Teil der Gesamtanlage wird erneuert, daher muss das Programm geändert und erweitert werden.
Ich habe schon Programe gesehen, die zu 99% in AWL geschrieben sind und welche, die zu 100% in FUP geschrieben sind. Das geht ja noch.

Heute hab ich gedacht ich sehe nicht richtig. Ca. 50% AWL und 50% FUP.
Die Siemensbausteine in FUP beschaltet, eigene FCs mal in AWL und mal in FUP. Dazu Kommt eine Symbolik ohne Symbolkommentare und DBs die nicht strukturiert sind.
Ganz frei nach dem Motto: Reinklatschen, einschalten und wenns läuft nach mir die Sinnflut.
So sieht es jedenfalls für mich aus.

Meine Freude ist Grenzenlos... :sb5:
 
Und wer ist jetzt eigentlich der Depp ?

Hallo,

Onkel Dago schrieb:
Die vielen Sprungbefehle zeugen oftmals, wie auch in diesem Fall, vom reinen Unvermögen des Programmierers.

Könnte aber auch im Umkehrschluß bedeuten : Wer die Sprungbefehle in AWL nicht versteht und das auch nicht interpretieren kann, ist letztendlich der Depp :ROFLMAO:

Gruß

Question_mark
 
Zurück
Oben