Zuviel Werbung? - > Hier kostenlos beim SPS-Forum registrieren

Seite 9 von 14 ErsteErste ... 7891011 ... LetzteLetzte
Ergebnis 81 bis 90 von 138

Thema: Grundsätzlich: Warum AWL ?

  1. #81
    Registriert seit
    12.02.2008
    Ort
    Westfalen (Dort wo's Schwarzbrot gibt)
    Beiträge
    417
    Danke
    8
    Erhielt 87 Danke für 72 Beiträge

    Standard


    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.....

  2. Folgender Benutzer sagt Danke zu Grubba für den nützlichen Beitrag:

    Uroessler (04.06.2010)

  3. #82
    Registriert seit
    28.10.2005
    Ort
    Ottweiler, Saar
    Beiträge
    940
    Danke
    259
    Erhielt 124 Danke für 109 Beiträge

    Standard

    Zitat Zitat von Grubba Beitrag anzeigen
    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.

    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!
    Zitieren Zitieren Achtung: politische Hetze.  

  4. #83
    Registriert seit
    25.06.2007
    Ort
    Dresden
    Beiträge
    3.930
    Danke
    465
    Erhielt 878 Danke für 634 Beiträge

    Standard

    Zitat Zitat von argv_user Beitrag anzeigen
    Spaghetti-Code kannste übrigens in jeder Programmiersprache erzeugen.
    Den Überblick verlieren auch!
    Man kann sich mit den "echten" IEC-Tools auch TOT-DEKLARIEREN.
    Grüße Frank

  5. #84
    Registriert seit
    19.11.2006
    Beiträge
    1.346
    Danke
    6
    Erhielt 254 Danke für 231 Beiträge

    Standard

    Zitat Zitat von argv_user Beitrag anzeigen
    Der Sage nach soll es Programmierer geben, die verstehen ihren eigenen SCL-Code von vor 4 Wochen nicht mehr.

    Das kommt mit jeder Programmiersprache vor

    Zitat Zitat von Grubba Beitrag anzeigen
    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, [b]warum auf Nicht-S7-Steuerungen keiner freiwillig in AWL programmiert.[b]
    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.)

    Zitat Zitat von argv_user Beitrag anzeigen
    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.

  6. #85
    Registriert seit
    29.03.2004
    Beiträge
    5.800
    Danke
    144
    Erhielt 1.710 Danke für 1.240 Beiträge

    Standard

    Zitat Zitat von trinitaucher Beitrag anzeigen
    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?

  7. Folgende 3 Benutzer sagen Danke zu Thomas_v2.1 für den nützlichen Beitrag:

    Markus (29.05.2010),rostiger Nagel (27.05.2010),Uroessler (04.06.2010)

  8. #86
    Registriert seit
    08.08.2007
    Ort
    Dresden
    Beiträge
    9.648
    Danke
    1.059
    Erhielt 2.046 Danke für 1.627 Beiträge

    Standard

    Zitat Zitat von vierlagig Beitrag anzeigen
    @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...
    Geändert von vierlagig (27.05.2010 um 16:13 Uhr)
    [SIGNATUR]
    Ironie setzt Intelligenz beim Empfänger voraus.
    [/SIGNATUR]

  9. #87
    tymanis ist offline Erfahrener Benutzer
    Themenstarter
    Registriert seit
    20.03.2010
    Beiträge
    134
    Danke
    43
    Erhielt 5 Danke für 4 Beiträge

    Standard

    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.

  10. Folgender Benutzer sagt Danke zu tymanis für den nützlichen Beitrag:

    rostiger Nagel (27.05.2010)

  11. #88
    Registriert seit
    19.11.2006
    Beiträge
    1.346
    Danke
    6
    Erhielt 254 Danke für 231 Beiträge

    Standard

    Zitat Zitat von vierlagig Beitrag anzeigen
    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.

    Zitat Zitat von tymanis Beitrag anzeigen
    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

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

    Zitat Zitat von vierlagig Beitrag anzeigen
    [...]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?

  12. #89
    Registriert seit
    27.05.2004
    Ort
    Thüringen/Berlin
    Beiträge
    12.264
    Danke
    537
    Erhielt 2.708 Danke für 1.957 Beiträge

    Standard

    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.
    Geändert von Ralle (27.05.2010 um 17:16 Uhr)
    Gruß
    Ralle

    ... there\'re 10 kinds of people ... those who understand binaries and those who don\'t …
    and the third kinds of people … those who love TIA-Portal

  13. Folgende 3 Benutzer sagen Danke zu Ralle für den nützlichen Beitrag:

    Hoyt (27.05.2010),Jan (27.05.2010),tymanis (27.05.2010)

  14. #90
    Registriert seit
    22.12.2006
    Beiträge
    43
    Danke
    0
    Erhielt 6 Danke für 6 Beiträge

    Standard


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    Schön gesprochen!



    Gruß Dominik
    Zitieren Zitieren Amen  

Ähnliche Themen

  1. Antworten: 0
    Letzter Beitrag: 18.05.2011, 09:34
  2. Antworten: 9
    Letzter Beitrag: 26.03.2011, 20:47
  3. Grundsätzlich PID mit S7 Programmieren
    Von Bensen83 im Forum Simatic
    Antworten: 4
    Letzter Beitrag: 02.12.2009, 10:29
  4. Grundsätzlich: Unterschied FU - Servoverstärker
    Von trinitaucher im Forum Antriebstechnik
    Antworten: 28
    Letzter Beitrag: 17.05.2009, 20:34
  5. Wie regelt man grundsätzlich die Temperatur
    Von wonderfulworld im Forum Elektronik
    Antworten: 19
    Letzter Beitrag: 28.08.2007, 17:12

Lesezeichen

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •