# FUP als Technikersprache



## Anonymous (17 Dezember 2004)

Hallo allezusammen !

Habe eine Frage. Bin frischer Programmierer und soll  nur 
in FUP programmieren, weil mein Vorgesetzter behauptet,
das FUP die Techikersprache ist. Ich selbst programmiere vor allem kompexere Funktionen, wo viel gerechnet wird (z.B.:Regler) mit AWL, weil ich das einfacher und übersichtlicher finde.
Kann mir jemand sagen ob FUP tatsächlich  "die"  Technikersprache ist. 

Gruß Marek[/u]


----------



## Heinz (17 Dezember 2004)

Sysko schrieb:
			
		

> Hallo allezusammen !
> 
> Kann mir jemand sagen ob FUP tatsächlich  "die"  Technikersprache ist.
> 
> Gruß Marek[/u]



Es hängt von der Definition ab.
FUP können viele Techniker aus den Zeiten der Logik-Gatter CMOS 40xx oder in TTL 74xx 

KOP können viele Elektriker, weil Stromlaufplan ähnlich

AWL ist die mächtigste Sprache mit dem meisten Funktionsumfang.

Bei unseren Kunden ist meisten für das Gro KOP angesagt. AWL nur in Ausnahmefällen.


Ich habe in FUP angefangen (Auf Wunsch meines Chefs)
Später (S5 und FB's) AWL
und nun bei KOP und AWL angekommen 
Man bei FUP müßte ich echt überlegen  so lang ist das her.


Aus meiner Sicht gibt es nicht "DIE TECHNIKERSPRACHE" 

Letztlich bestimmt der Kunde was er haben will. Wenn es ihm egal ist s.o.


----------



## Limbo (17 Dezember 2004)

Du kannst doch programmieren wie Du willst., und Dein Vorgesetzter kann sich die Bausteine in dem Modus ansehen, wie er will. Bekommt er dann die Meldung "Baustein in FUB nicht darstellbar, ist das sein Problem.

Ich verfolge die Funktion einer laufenden, oder gestörten Maschine gern in FUB-Darstellung. Neu programmieren oder ändern tue ich aber meist in AWL. In AWL kann man Alles programmieren, in KOP ist das nicht möglich, und auch in FUP gibt es da Grenzen, gerade wenn es um Berechnungen geht.

Sag Deinem Vorgesetzten "AWL ist die Sprache der Ingenieure!", und frage Ihn wie er Laden und Transferieren eines Wertes in FUP schreibt.
 :lol: 

Limbo


----------



## RaiKa (17 Dezember 2004)

Bin zwar nicht der Chef von sisko, aber für Laden und Transferieren gibt es das Programmelement "Move".
Gruß
raika


----------



## kpeter (17 Dezember 2004)

hallöchen

also aus meiner sicht verlangen es viele kunden das man in fup programmiert

das problem ist nur das man wie jeder weis viele funktionen nur in awl programmieren kann

ausser man sieht mal zu anderen programmiersprachen zb Rockwell CLX SLC PLC dort gibt es hauptsächlich KOP und es geht auch
aber dot kann ich wirklich alles in kop machen auch complexe berechnungen ohne umwege

aber es kommt dort auch schon fup zur anwendung


aber wenn man mal weitersieht und scl programmiert ist doch wieder alles anders und es können nur noch wenige lesen


----------



## Anonymous (17 Dezember 2004)

Also bei uns in der Firma wird alles in AWL programmiert.
Es geht auch schneller.

In den Hochsprachen wie z.B. C wird ja auch nicht gemahlt.


----------



## volker (18 Dezember 2004)

hallo

fup ist imho standart. für komplexe funktionen benutzt man logischerweise awl (für regelungen , datenbankanwendungen, etc auch scl). kop ist meiner meinung nach nur für leute gut die von 'logik' eher weniger ahnung haben und nur stromlaufpläne lesen können.

*für die störungssuche ist fup einfach optimal*, da man allein durch die darstellung die verknüpfungen leicht überblicken kann. maschinenstillstandzeiten kosten eine menge geld.

ich habe schon eine menge programme gesehen die von irgendwelchen 'informatikern' programmiert wurden und die bei der inbetriebnahme bzw bei der störungssuche schwer ins stracheln gekommen sind weil sie den code so ohne weiteres gar nicht mehr überblicken konnten.

aber das scheint auch ein problem des lerninhalts beim studium zu sein. die ganze leute die studiert haben glauben wohl alle, hochsprache ist das non plus ultra. aber das ist es nicht. jedenfalls nicht in diesem bereich. es gibt halt manchmal auch dinge die kann man nicht besser machen. ;-)
Ich habe 'nur' einen techniker, diverse kurse, und viele jahre erfahrung.

vor kurzem hatten wir eine inbetriebnahme einer maschine eines fremdherstellers die die komplette steuerung in scl geschrieben haben. der hatte mächtige probs wenn mal was nicht ins raster passte. der wusste 0 von awl / fup /kop. als ich dem mal so ein paar grundsätzliche dinge zu dieser art der programmierung erklärt habe kam der grosse AHA-Effekt.


@h.schischeg
was soll daran schneller gehen?

@RaiKa
für ein move gibt es durchaus eine fup-funkktion


----------



## RaiKa (18 Dezember 2004)

@volker,

ich kann Deine Äußerungen nur unterstützen. 
Sicherlich hast Du mich mißverstanden. Ich wollte auf das Programmelement "Move" im Katalog unter "Verschieben" hinweisen; als Antwort auf Limbos Kommentar bzgl. Laden und Transferieren.

Gruß raika


----------



## Gerhard Bäurle (18 Dezember 2004)

Hallo,

grundsätzlich ist die Fehlersuche in den graphischen Sprachen KOP und FUP einfacher, weil das SPS-Programm graphisch dargestellt wird und man besser die Übersicht hat.

FUP ist vermutlich in Europa mehr verbreitet, KOP dagegen in Nordamerika. FUP verstehen bei uns vielen, weil in Ausbildung und Studium von Anfang an Funktionspläne verwendet werden.

AWL ist wie Assembler beim PC, nicht besonders einfach aber sehr effektiv, wenn man es beherscht.

Viele Grüße
Gerhard Bäurle


----------



## Anonymous (23 Dezember 2004)

Es gibt sie also doch nicht "Die Technikersprache"
Finde auch das man schnell und effizient vorankommen muss,
egal ab man FUP,AWL  zusammen kombieniert was ich gerne mache, 
oder nur FUP/KOP benutzt

Danke für die Antworten und frohes Fest

Marek


----------



## Guste (18 September 2006)

Kann dem Volker nur voll zustimmen. Gehts um Maschinenstillstandszeiten und SPS von Fremdherstellern so gehts mit Fub am schnellsten


----------



## MSB (18 September 2006)

Das Problem liegt aber meiner Meinung nach wo anders,
wenn Siemens, und um die geht es ja hier hauptsächlich,
schon eine Übersetzung zwischen AWL -> KOP/FUP bzw. umgekehrt anbietet,
was bei den meisten IEC-Systemen neuerer Bauart ja nicht der Fall ist,
dann hat da normalerweise auch jeder Code zu funktionieren,
unabhängig wie er geschrieben ist, ohne NOP0 BLD, und was weiß ich was.

Normalerweise sollte man gar nicht vor die Wahl gestellt werden, ob man irgendwas in FUP oder AWL macht.
Grundsätzlich bin ich schon der Meinung das ich mit AWL tendenziell schneller bin, als mit diesem Mausrumgeschiebe (beim Programmieren).
Bei der Fehlersuche dürfte FUP ziemlich sicher geschwindigkeitsmäßig vorne liegen.

Lange Rede kurzer Sinn:
AWL sollte auf FUP IMMER übersetzt werden können, vielleich gibts das ja bei Step7 V21.9

Mfg
Manuel


----------



## maxi (19 September 2006)

Hallo,

wenn er so kommt ist AWL die Technikersprache;
Denn jeder Techniker müsste Assembler vom 8086 und 8051 kennen.


FUP ist für mich eher mehr für Anfänger, da es schon eine enorme Bastelei ist und bei grösseren Prgrammen dann total mit hunderten Netzwerken aufgebläht. Vor allem ein Arbeiten mit VKE sehr schwer ist.

Für reine Regelungen ist es allderdings recht schön. Die sind ja ohnehin meist leichter in einer Logic und über FB auszuklügeln. Jedoch auch nur wenn nahezu keine Sprungbefehle vorhanden sind.

Die Technikersprache ist übrigens X=AvBvNC usw.
Aus einen komplexen Ablauf lassen sich dann zum Beispiel Funktionen kürzen. 

Hoffe ist dir vielleicht hilfreich.


----------



## CrazyCat (19 September 2006)

Mit AWL kann man die Bausteine übersichtlich halten, da man nicht dutzende Netzwerke für eine Berechnung benötigt.

Ich muss euch recht geben, Fehler findet man mit FUP etwas schneller, aber auch hier habe ich schon so meine diversen Tricks um auch in AWL den Fehler schnell zu finden.

@Volker: Ein 100%iger KOP/AWL/FUP Umsetzer wäre schon was feines, nur leider gibt es den bis dato noch nicht.


----------



## maxi (19 September 2006)

Ich stelle zur Prgrammfehlersuche das FUP immer in AWL.
Mag immer den VKE und Sprungbereiche sehen.

Zur Fehlerdiagnose in Regleung verwende ich die VAT.

In Schritketten Fehlerdiagnose geht ohne nur in AWL gescheit.


Persönlich bemerkt habe ich das Leute die im FUP fehelersuche machen meist nicht so begabt in der Programmierung waren und eigentlich gar nicht so recht wussten was sie eigentlich da tun.

Mag mir aber jetzt keien Feinde machen oder Haue bekommen.

Jedoch wenn die mal einen standart programmierten Kommunikationsbaustein, eine Encoderauswertig, Buskopplung etc. sahen der dazu noch super gut Kommentiert war, war deren Durchblick gleich Bodennebel London 6:00 Uhr 

Ich verdreh dann immer die Augen wenn sie Anfangen *Das muss man so machen #tipsl, tipsl#* und auf speichern drücken. 
Aber muss ihnen ja immer vergeben werden, denn sie wussten ja nicht was sie tun *fg*


So, mich nun schnell verstecke bevor von FUP Sektis ordentlich Haue bekomme.


----------



## maxi (19 September 2006)

Bissel Spass muss sein


----------



## Ma_su (19 September 2006)

Also ich kann Volker nur zustimmen! 
Fehlersuche in FUB geht, bei komplexer Logik wesentlich einfacher, weil man sofort auf einen Blick die Funktion erfassen kann. 

Bei Programmen mit Berechnungen und Sprüngen, finde ich AWL wesentlich übersichtlicher als wenn man Tausende Logik Elemente in FUB hintereinander baut. Wenn man das dann noch vernünftig kommentiert, "SOLLTE" das eigentlich jeder lesen können, der an einer SPS an Anlagen Programmieren darf.

Meiner bescheiden Meinung nach  FUB für Logik usw. und AWL und SCL für Berechnungen und Hantierung mit Daten usw.

Es gibt nichts Schlimmeres als unkommentierte Programme in AWL wo man mal Kurz eine Kleinigkeit ändern soll.


----------



## Graph&SCL_Freak (19 September 2006)

Also ich finde AWL nicht sehr übersichtlich, wer z.B. aus der PC-Programmierung kommt wird sich damit gar nicht anfreunden können, ausser er hat vorher in Assembler programmiert. Allein schon ein Sprung-Befehl hat in modernen Sprachen eigentlich nichts mehr zu suchen. Die 'Sprache der Ingenieure' ist meiner Meinung nach SCL, da kann man auch mal mit Kollegen über einen Algorithmus diskutieren auch wenn der von SPS-Programmierung keine Ahnung hat. Von Sachen wie objektorientierter Programmierung, Vererbung etc. ist die SPS-Welt ja leider noch meilenweit entfernt.

Schrittketten gehen am besten in Graph, musste mich auch davon überzeugen lassen, das Debugging damit ist einfach kinderleicht. Sonst steh ich eigentlich auch nicht so auf 'Mal'-Sprachen. SPS-Speicher ist ja nicht mehr so teuer (ausser bei Siemens).

Leider werden die beiden Systeme viel zu wenig benutzt, aber was der Bauer nicht kennt...


----------



## nade (19 September 2006)

deltalogic schrieb:


> Hallo,
> 
> grundsätzlich ist die Fehlersuche in den graphischen Sprachen KOP und FUP einfacher, weil das SPS-Programm graphisch dargestellt wird und man besser die Übersicht hat.
> 
> ...



Auch ein hallo.
Also während meiner Ausbildungszeit zum Elektroinst. hatte ich noch auf der AEG A020 gelernt, und die war zumindest in meinen Überbetrieblichen Ausbildungen nur in AWL.
Ok ist "nur" eine Wendeschaltung eines Motors über 2 Endschalter gewesen aber halt in AWL.
Letztes Jahr den Meister gemacht und da ging alles in FUP. Auch nicht die Welt für Leute die ihren Techniker und Kurse im Bereich Steuerungs und Regelungstechnik gemacht haben, aber schon etwas umfangreicher einn "Kompressor" mit Aussetz und Dauerbetrieb angetrieben über einen Stern-Dreieck-Anlauf.
KOP weiß ich was es ist aber nie verwendet.
Alles in allem ist FUP auch für Kleinsteuerungen wie die Theben TS oder Siemens LOGO ehr die Programiervariante.
Da ich mich aber Privat wieder mehr für Steuerungen und weil nun auch die Möglichkeit mir Analogwerte zu nutze zu machen zum "Spielen" werde ich mich auch versuchen noch in die Regelungstechnik reinzu"fressen".
FUP hat aus meiner sicht bei überschaubaren Netzwerken wie schon gesagt wurde den vorteil das "einfacher" zu Überschauen ist was alles zusammen auf was sich auswirkt.
Wenn weil hier oft gesehen ist wohl die AWL trotz "Zeichensammlung" für sich rein zu versetzen und die Struktur zu erkennen besser, wenn man die Syntax halt kann und weiß wie Strukturiert.
Kurz würde mich auch interessieren ob es bei verschiedenen Programiermethoden die so ziemlich alle irgentwie genutzt werden eine "Technikersprache" drunter ist.
Denke aber nicht, weil Siemens und Co die würden sich bestimmt nicht die Arbeit machen eine Programiersoftware mit mehreren Varianten auszustatten wenn es eine festgelegete Programiersprache gäbe.


----------



## CrazyCat (20 September 2006)

@SCL - Freak:

SCL wäre gar nicht so schlecht, aber es bläst das Programm etwas auf.
Das gilt allerdings, wenn auch in geringerem Ausmaß für FUP.


@maxi:

Da hast du gar nicht so unrecht.


----------



## maxi (20 September 2006)

Graph&SCL_Freak schrieb:


> Also ich finde AWL nicht sehr übersichtlich, wer z.B. aus der PC-Programmierung kommt wird sich damit gar nicht anfreunden können, ausser er hat vorher in Assembler programmiert. Allein schon ein Sprung-Befehl hat in modernen Sprachen eigentlich nichts mehr zu suchen. Die 'Sprache der Ingenieure' ist meiner Meinung nach SCL, da kann man auch mal mit Kollegen über einen Algorithmus diskutieren auch wenn der von SPS-Programmierung keine Ahnung hat. Von Sachen wie objektorientierter Programmierung, Vererbung etc. ist die SPS-Welt ja leider noch meilenweit entfernt.
> 
> Schrittketten gehen am besten in Graph, musste mich auch davon überzeugen lassen, das Debugging damit ist einfach kinderleicht. Sonst steh ich eigentlich auch nicht so auf 'Mal'-Sprachen. SPS-Speicher ist ja nicht mehr so teuer (ausser bei Siemens).
> 
> Leider werden die beiden Systeme viel zu wenig benutzt, aber was der Bauer nicht kennt...


 
Huhu,

ich muss die da gänzlich Wiederpsrechen.
In Basic und C++ habe ich genauso die Sprungbefehle und nutze sie natürlich auch.

Das Problem ist das die meisten meinen das FUP die Logic darstellt.
Das ist die Logic in der Digitaltechnik, jedoch nicht in der Microcontrolertechnik. Da muss ich ja mit den VKE und Programmteilen arbeiten.

Ich persönlich tendiere dazu das jeder der meint wirklicher Programmierer zu sein einfach Assembler für 8086 können muss. Ansonsten kann man gar nicht verstehen wie die Hochsprache oder ein Operating System funktioniert und wie sie zustande kommt. Das ist wie in der Mathematik. Ohne Grundrechenfunktionen kein gescheites Algebra.
Die Informatik Ingenieure übrigens lernen alle anfänglich Assembler. 
Telekommunikationstechniker, Energieanlagenelektroniker, manche Mechatroniker, Steuerngstechniker, etc. auch. Ist dort Lehrinhalt. 

Ich habe habe zwei gleiche Bausteine, einmal in Fup und einmal in AWL.
Habe den mal in AWL umwändeln und Kommentieren müssen da der Spriecherplatz der CPU nicht reichte. 
Ich bau dir da mal in beide dreimal die gleichen Fehler, ganz was gängis, Status, VKE fehler etc. ein und du kannst mal selbst testen wo du sie findest. in Fup wirst du dich richtig schwer tun und bezweifle auch das du eine VKE Fehler, den du in AWL in 1 Minute hats, im FUP innerhalb 10 Minuten Finden wirst.


----------



## Graph&SCL_Freak (20 September 2006)

maxi schrieb:


> ich muss die da gänzlich Wiederpsrechen.
> In Basic und C++ habe ich genauso die Sprungbefehle und nutze sie natürlich auch.
> 
> Ich persönlich tendiere dazu das jeder der meint wirklicher Programmierer zu sein einfach Assembler für 8086 können muss. Ansonsten kann man gar nicht verstehen wie die Hochsprache oder ein Operating System funktioniert und wie sie zustande kommt. Das ist wie in der Mathematik. Ohne Grundrechenfunktionen kein gescheites Algebra.
> ...



Danke, hab mich im E-Technik-Studium selbst mit Assembler rumgeärgert. Später hab ich mich dann mit Windows-Programmierung rumgeschlagen und da nützt es dir gar nichts. Du musst auch nicht wissen wie ein Compiler funktioniert, ausser du willst selbst einen schreiben oder musst hardwarenah irgendwelche Treiber entwickeln. Das Problem bei den reinen SPS-Programmierern ist, dass sie von strukturierter oder gar objektorientierter Programmierung meist keine Ahnung haben und das sieht man auch an deren Code. Und nochmal: Sprünge haben in modernen Sprachen nichts mehr zu suchen, das gilt auch für 'On Error'-Behandlungen etc.. Der Inhalt bei Ausbildungen/Studium hängt meist eh meilenweit hinter aktuellen Programmiersprachen hinterher, die mittlerweile sehr populäre Sprache C# z.B. gibt's ja erst seit 4 Jahren.


----------



## Graph&SCL_Freak (20 September 2006)

CrazyCat schrieb:


> @SCL - Freak:
> 
> SCL wäre gar nicht so schlecht, aber es bläst das Programm etwas auf.
> Das gilt allerdings, wenn auch in geringerem Ausmaß für FUP.



SCL ist optimal für Analogwertverarbeitung, algorithmische Geschichten wie Regler, Prüfstände etc.. Für Schrittketten bringt es nichts. Der Code lässt sich recht kompakt programmieren. Ist ja im Prinzip Pascal.


----------



## afk (20 September 2006)

Graph&SCL_Freak schrieb:


> Danke, hab mich im E-Technik-Studium selbst mit Assembler rumgeärgert. Später hab ich mich dann mit Windows-Programmierung rumgeschlagen und da nützt es dir gar nichts.


Es ist grundsätzlich hilfreich zu wissen, wie der Rechner intern "tickt", egal in welcher Sprache man programmiert, ob OOP oder strukturiert, und darum sind ausreichende Kenntnisse in Assembler immer eine gute Grundlage.



Graph&SCL_Freak schrieb:


> Du musst auch nicht wissen wie ein Compiler funktioniert, ausser du willst selbst einen schreiben oder musst hardwarenah irgendwelche Treiber entwickeln. Das Problem bei den reinen SPS-Programmierern ist, dass sie von strukturierter oder gar objektorientierter Programmierung meist keine Ahnung haben und das sieht man auch an deren Code.


Da ein SPS-Programmierer aber wohl hauptsächlich hardwarenah programmiert (Maschine ), ist es dementsprechend dann ja auch sehr sinnvoll, wenn er sich gut mit "SPS-Assembler" (AWL) auskennt.



Graph&SCL_Freak schrieb:


> Und nochmal: Sprünge haben in modernen Sprachen nichts mehr zu suchen, das gilt auch für 'On Error'-Behandlungen etc..


Auch wenn Du in Deinen Sourcecode keine Sprünge einhackst, der Compiler baut in Dein Programm für jedes Schleifenkonstrukt und jede Fallabfrage bedingte Sprünge ein. 

Ich stimme maxi völlig darin zu, daß ein guter Programmierer eine Vorstellung davon haben sollte, was in seinen Programme "unter der Oberfläche" so vor sich geht, und für maschinennahe Programmierung ist es ein Muß. 

Obwohl ich selbst seit über 15 Jahren PCs in objektorientierten Hochsprachen programmiere, möchte ich meine Assemblerkenntnisse dabei nicht missen.  


Gruß Axel


----------



## Graph&SCL_Freak (21 September 2006)

afk schrieb:


> Ich stimme maxi völlig darin zu, daß ein guter Programmierer eine Vorstellung davon haben sollte, was in seinen Programme "unter der Oberfläche" so vor sich geht, und für maschinennahe Programmierung ist es ein Muß.
> 
> Obwohl ich selbst seit über 15 Jahren PCs in objektorientierten Hochsprachen programmiere, möchte ich meine Assemblerkenntnisse dabei nicht missen.



Mag ja alles richtig sein, aber in der Praxis z.B. im Windows-Umfeld bringt es dir gar nicht's, da moderne Compiler so hochkomplex sind dass man eh nicht weiss wie sie optimieren. Und bei mindestens 90% aller Applikationen ist Assembler-Optimierung aufgrund der leistunsfähigen Prozessoren eh nicht mehr nötig. 
Und die maschinennahheit von AWL hat leider den grossen Nachteil das der Code leider relativ unkompatibel zwischen den verschiedenen Herstellern ist.

Mich interessiert nur ob ich oder jemand anderes den Code auch nach einiger Zeit noch versteht und da hab ich bei manchen AWL-Spezie's doch so manchmal meine Zweifel, wenn ich sehe wie lange die vor ihren oder fremdprogrammierten Einfach-Steuerungen hocken.


----------



## afk (21 September 2006)

Graph&SCL_Freak schrieb:


> Mag ja alles richtig sein, aber in der Praxis z.B. im Windows-Umfeld bringt es dir gar nicht's, da moderne Compiler so hochkomplex sind dass man eh nicht weiss wie sie optimieren.


Eins weiß ich aber ganz sicher: bedingte Sprünge für Schleifen und Fallabfragen braucht er trotz aller Optimierungen.  



Graph&SCL_Freak schrieb:


> Und die maschinennahheit von AWL hat leider den grossen Nachteil das der Code leider relativ unkompatibel zwischen den verschiedenen Herstellern ist.


Auch die allerwenigsten Windows-Programme kommen ohne die Windows-API aus, sind damit also auf Windows oder Windows-Emulatoren angewiesen. DotNet ist da zwar ein netter Ansatz, aber mehr eben auch noch nicht, denn die meisten .net-Programme laufen bisher auch nur unter Windows.

Andererseits hat Zottel ausgerechnet im maschinennahen C  mit libnodave eine Bibliothek geschaffen, die nicht nur auf verschiedenen Plattformen läuft, sondern auch noch von vielen verschiedenen Programmiersprachen aus genutzt werden kann. 



Graph&SCL_Freak schrieb:


> Mich interessiert nur ob ich oder jemand anderes den Code auch nach einiger Zeit noch versteht und da hab ich bei manchen AWL-Spezie's doch so manchmal meine Zweifel, wenn ich sehe wie lange die vor ihren oder fremdprogrammierten Einfach-Steuerungen hocken.


Bei uns arbeiten 7 SPS-Programmierer mit einem recht umfangreichen Pool von gemeinsamen (gut kommentierten) AWL-Quellen, die je nach Bedarf für die Maschinensteuerungen (alles S7-Platform) eingesetzt und mit maschinenspezifischen Code ergänzt werden (vereinfachte Beschreibung der Situation bei uns).

Von denen kannst Du beliebig einen nehmen und nach einem Problem in Maschine suchen lassen, von der wir seit 3 Jahren nichts mehr gehört haben, er wird mit dem Code ohne große Probleme zurecht kommen, auch wenn er mit der Maschine vorher noch nie etwas zu tun hatte.

Es gibt zwar bestimmt auch andere Fälle (nach dem Motto: ich verstehe meinen Code von vor zwei Monaten selbst nicht mehr ), aber die habe ich bei Hochsprachen-Programmierern auch schon zu genüge erlebt.

Wie gut sowas funktioniert, hat nichts mit der eingesetzten Sprache, sondern nur mit aufgestellten Regeln und deren Einhaltung (Disziplin!) zu tun. Um damit wieder zur Ausgangsfrage des Threads zurückzukommen: *die Sprache* für Techniker (Ingenieure, ...) gibt es meiner Meinung nach nicht, aber mit der entsprechenden Qualifikation sollte man in der Lage sein, die für den jeweiligen Einzelfall am besten *geeignete Sprache* auszuwählen.


Gruß Axel


----------



## Fanta-Er (24 September 2006)

*Stimmt*

Die meisten Programmiereerererere  dich ich kenne mischen. (ich auch)

Boolsche Geschichten immer in KOP/FUP wenn Berechnungen, Regelungen, Strings oder Pointer ins spiel kommem, muß man in KOP/FUP einen Handstand machen um sie da zu stellen. :-( 

Um auf die eigentliche Frage zurück zu kommen:

Viele "alte" Hasen lieben KOP bzw FUP weil sie schnell erkennen was los ist und sie es gewöhnt sind mit den Elementen zu arbeiten. Vor allem Konstructöööre. Denen ist nichts zu schwööööörrrr. 

Wenn er dir nochmal damit kommt, soll ER dir mal zeigen wie man eine Pointerfunktion in KOP programiert. Trink dann 1,2,3,4.....Kaffee und tipps dann in AWL.  Er dürfte dann kuriert sein.:twisted:  

Aber wie oben erwähnt: DER KUNDE IST KÖNIG!!!!!!


----------



## kiestumpe (10 Oktober 2006)

*Mischen*

... und genau hierin liegt imho die Kunst. 
Es stimmt zwar, dass man mit OOP mehr Werkzeuge zum strukturierten Programmieren hat als in AWL, aber es ist bei weitem nicht immer so, dass sie auch in diesem Sinne angewendet werden.

Aber man kann ja Daten auch in S7 mit den FB's kapseln (wenn man sich daran hält, tunlichst nicht von ausserhalb in die Istanzen zu schreiben).

Und SCL halt ich auch dann für sinnvoll, wenn der Baustein-Code (Ohne Schnittstellen) übersichtlich bleibt und auf 1 bzw 2 DIN A4 Seiten passt bzw. in den anderen Sprachen schnell auf 10 oder mehr seiten anwächst.
Es ist meiner Meinung nach weniger entscheident, ob man im Speicher ein paar Bytes einspart, als dass der Code Optisch kompakt  und verständlich bleibt. Wenn einer z.B anfängt in AWL mehrfach geschachtelte Schleifen zu programmieren, dann ist die dort kaum nachvollziehen.

Gruss

kiestumpe


----------



## Ralle (10 Oktober 2006)

Graph&SCL_Freak schrieb:


> Mag ja alles richtig sein, aber in der Praxis z.B. im Windows-Umfeld bringt es dir gar nicht's, da moderne Compiler so hochkomplex sind dass man eh nicht weiss wie sie optimieren. Und bei mindestens 90% aller Applikationen ist Assembler-Optimierung aufgrund der leistunsfähigen Prozessoren eh nicht mehr nötig.
> Und die maschinennahheit von AWL hat leider den grossen Nachteil das der Code leider relativ unkompatibel zwischen den verschiedenen Herstellern ist.
> 
> Mich interessiert nur ob ich oder jemand anderes den Code auch nach einiger Zeit noch versteht und da hab ich bei manchen AWL-Spezie's doch so manchmal meine Zweifel, wenn ich sehe wie lange die vor ihren oder fremdprogrammierten Einfach-Steuerungen hocken.


 
Na  ja, so ganz kann ich deiner Meinung nicht folgen.
Unkommentierte Programmcode kannst du "fast" immer vergessen, das gilt übrigend ganz besonders auch für SCL. Hatte letztens einen SCL-Code von mir in der Nacharbeit (der war sogar recht gut kommentiert) und hab eigenlich genauso lange überlegen müssen, wie bei AWL-Code (logisch, denn, nur wenns für AWL zu kompliziert wird nehme ich SCL und dann wird es auch da nicht einfacher ). Ohne Nachdenken sollte man ja auch generell nichts anfassen an einer Steuerung, das wissen aber so manche FUP-Clickies offensichtlich nicht. Ansonsten neige ich auch dazu, immer die einfachste *und* übersichtlichste Form zu wählen, also KOP/FUP wo es geht und sinnvoll ist, z.Bsp. bei binären Verknüpfungen. Aber schon beim Einsatz des MOVE-Befehls in FUP, nur um eine einfache Rechnung mit mehreren Operanden oder Vergleichern in FUP darstellbar zu machen (möglichst noch mit Temp-Vars, die der Editor selbst einfügt) ruft bei mir echte Würgreflexe hervor.  

Sicher muß keiner, der Win-Programme schreibt absoluter Assembler-Spezialist sein, aber wenn du das erste Mal nach Speicherlecks, nicht beendeten Threads, höheren Nutzerrechten etc. suchst, kommst du schin um die Win-API nicht herum. Wenn du dann damit nichts anfangen kannst, kommen Programme raus, die alle 2 Stunden abstürzen, immer langsamer werden, na ja und noch so viele andere schöne Nebeneffekte erzeugen.


----------



## kiestumpe (10 Oktober 2006)

Ralle schrieb:


> Sicher muß keiner, der Win-Programme schreibt absoluter Assembler-Spezialist sein, aber wenn du das erste Mal nach Speicherlecks, nicht beendeten Threads, höheren Nutzerrechten etc. suchst, kommst du schin um die Win-API nicht herum. Wenn du dann damit nichts anfangen kannst, kommen Programme raus, die alle 2 Stunden abstürzen, immer langsamer werden, na ja und noch so viele andere schöne Nebeneffekte erzeugen.


 
Bin mit den Ablegern von Thread-Klassen von Borland eigentlich immer gut zurecht gekommen, zumindest besser als mit API-Funktionsaufrufen und -zig Zeigerparameter. Naja, gut ist vielleicht etwas übertrieben, die Handhabung von Threads ist an sich schon kompliziert genug  

Die Speicherlecks rühren nach meiner Erfahrung eher von schlechter Synchronisation und/oder fehlenden Destruktor-Aufrufen her.


----------



## afk (10 Oktober 2006)

kiestumpe schrieb:


> Bin mit den Ablegern von Thread-Klassen von Borland eigentlich immer gut zurecht gekommen, zumindest besser als mit API-Funktionsaufrufen und -zig Zeigerparameter. Naja, gut ist vielleicht etwas übertrieben, die Handhabung von Threads ist an sich schon kompliziert genug


Es spricht ja auch nichts dagegen, solche Vozüge zu nutzen (wäre eher blöd es nicht zu tun ), aber falls mal was nicht so funktioniert wie es soll, dann ist es schon eindeutig von Vorteil, wenn man mit dem "Unterbau" auch klar kommt, und sei es nur, um zu verstehen, warum z.B. Borland die Thread-Klasse so programmiert hat wie sie ist. Sonst verliert man bei Problemen viel früher den Durchblick, und dann sieht das Ergebnis schnell mal so aus, wie Ralle es beschrieben hat:



Ralle schrieb:


> Wenn du dann damit nichts anfangen kannst, kommen Programme raus, die alle 2 Stunden abstürzen, immer langsamer werden, na ja und noch so viele andere schöne Nebeneffekte erzeugen.



Gruß Axel


----------



## maxi (10 Oktober 2006)

Graph&SCL_Freak schrieb:


> Danke, hab mich im E-Technik-Studium selbst mit Assembler rumgeärgert. Später hab ich mich dann mit Windows-Programmierung rumgeschlagen und da nützt es dir gar nichts. Du musst auch nicht wissen wie ein Compiler funktioniert, ausser du willst selbst einen schreiben oder musst hardwarenah irgendwelche Treiber entwickeln. Das Problem bei den reinen SPS-Programmierern ist, dass sie von strukturierter oder gar objektorientierter Programmierung meist keine Ahnung haben und das sieht man auch an deren Code. Und nochmal: Sprünge haben in modernen Sprachen nichts mehr zu suchen, das gilt auch für 'On Error'-Behandlungen etc.. Der Inhalt bei Ausbildungen/Studium hängt meist eh meilenweit hinter aktuellen Programmiersprachen hinterher, die mittlerweile sehr populäre Sprache C# z.B. gibt's ja erst seit 4 Jahren.


 
Das kommt dann so Mist wie Windos nur bei raus.
Sprünge werden gemacht um Programmteile auszublenden damit diese nicht verarbeitet werden.
Was hilft es wnen jedesmal ein hauffen Rechenleistung und Zykluszeit dafür drauf geht das ein Programmteil durchlaufen wird der nicht gebraucht wird.

Das ist ja auch genau das warum Windows soviel Leistung benötig und immer mehr und mehr langsamer wird, bzw. das System Crashet.

Eine CPU soll das machen was sie tun soll und nichts anderes.
Alles andere ist verschwendetet Leistung und Zeit.

Eien weitere optimierung ist der Aufruf eines Unterprogrammes je nach bedarf nach Paremetern. (Lade Parametersatz, Springe in Programm, Springe zurück, Lese Parametersatz) Dies spart Speicher aber benötigt Zeit.

Für einen Techniker oder richtigen SPS Programmierer ist es keien Frage das er versucht die Zykluszeiten klein zu halten.

Als blödes Beispiel ist es wie mit der Kabelverlegung. Die meisten nehmen ein Kabel, legen es quer durch die Halle und wenn sie vorne einen Schalter drücken läuchtet hinten die Lampe, bzw. geht wieder aus.
Für eine Meister oder Techniker stecken da aber Absicherung, Leitungslänge, Häufung, Erdung , etc. dahinter.

Die Behauptung FUP währe eine Technikersprache ist der totale Quatsch.
Das ist was für Anfänger die mit der Logo und ihrer FUP-Bastellösung arbeiten aber für weitreichend weitergende Programmierung einer Steuerung oder esines Microcontrolers gänzlich ungeignet.

Die besten udn sichersten Programmierergebnisse erhält man nur durch gut strukturierts und kommentiertes AWL, bzw. Assembler.

Ein weiterer Faktor ist die Zeit.
Ein AWL Programm erstelle ich manchmal in 5-10 Minuten.
Mache ich das gleiche in FUP dauert es Stunden und hat unzählige Netzwerke.
Erst das ganze Rumgebastel mit den Symbolen. Dann alle Parameter eingeben. und Komentare nur im Bausteinkomentar. 
Dazu kein arbeiten mit VKE oder Status, für schnelles arbeiten keine PAB ansteuerung etc.

grüsse


----------



## Graph&SCL_Freak (11 Oktober 2006)

maxi schrieb:


> Die besten udn sichersten Programmierergebnisse erhält man nur durch gut strukturierts und kommentiertes AWL, bzw. Assembler.



Ist ne Behauptung von dir, kann ich für mich genauso für SCL sagen. Bei der S7-Programmierung ist es grundsätzlich ein Problem das die ganze Programmierung viel zu Prozessor-nah  ist, d.h. um Speicher-/Merkerbereiche muss ich mir bei modernen Sprachen eigentlich keine Gedanken mehr machen müssen. CoDeSys und die Derivate zeigen ja, dass es viel einfacher und hardwareunabhängiger geht.


----------



## Graph&SCL_Freak (11 Oktober 2006)

Ralle schrieb:


> Sicher muß keiner, der Win-Programme schreibt absoluter Assembler-Spezialist sein, aber wenn du das erste Mal nach Speicherlecks, nicht beendeten Threads, höheren Nutzerrechten etc. suchst, kommst du schin um die Win-API nicht herum. Wenn du dann damit nichts anfangen kannst, kommen Programme raus, die alle 2 Stunden abstürzen, immer langsamer werden, na ja und noch so viele andere schöne Nebeneffekte erzeugen.



Es gibt seit ca. 4 Jahren das .NET-Framework, damit hat sich das erledigt. Wer was anderes behauptet hat noch nie richtig damit gearbeitet.


----------



## knabi (11 Oktober 2006)

maxi schrieb:


> Als blödes Beispiel ist es wie mit der Kabelverlegung. Die meisten nehmen ein Kabel, legen es quer durch die Halle und wenn sie vorne einen Schalter drücken läuchtet hinten die Lampe, bzw. geht wieder aus.


Das ist wirklich ein äußert fragwürdiger Vergleich  



maxi schrieb:


> Die Behauptung FUP währe eine Technikersprache ist der totale Quatsch.
> Das ist was für Anfänger die mit der Logo und ihrer FUP-Bastellösung arbeiten aber für weitreichend weitergende Programmierung einer Steuerung oder esines Microcontrolers gänzlich ungeignet.


Das ist Deine Meinung, dann solltest Du sie aber auch als solche kennzeichnen und dies hier nicht als die endgültige Wahrheit verkaufen :???: 



maxi schrieb:


> Ein weiterer Faktor ist die Zeit.
> Ein AWL Programm erstelle ich manchmal in 5-10 Minuten,


Das wird sicher ein tolles Programm sein, das man in 5 Minuten erstellt hat.



maxi schrieb:


> Mache ich das gleiche in FUP dauert es Stunden und hat unzählige Netzwerke.
> Erst das ganze Rumgebastel mit den Symbolen. Dann alle Parameter eingeben. und Komentare nur im Bausteinkomentar.


Das widerum spricht nur dafür, daß Du offensichtlich nicht firm in FUP bist, sonst würdest Du mir leid tun. Ich denke mal, daß es eine reine Geschmacks- und Übungsfrage ist, ob man nun FUP oder AWL oder vielleicht auch SCL/GRAPH bevorzugt (wobei es eben immer auch auf den konkreten Anwendungsfall ankommt und auch auf die Finanzen - nicht jede Firma leistet sich GRAPH).
Sich hier hinzustellen und alle Leute, die bevorzugt FUP programmieren, als Anfänger und Diletanten abzutun, finde ich - gelinde gesagt - sehr großspurig.

Gruß

Holger


----------



## maxi (12 Oktober 2006)

Mag mich doch nicht rechtfertigen 

Habe doch auch mal Telekommunikationstechniker gemacht.
Muss doch Firm in Fup sein.
Ich find es aber für Programmierung sehr unmöglich.
Da mag ich ja noch lieber Kop (Wie bei der alten Modicom) als FUP.
Da weiss ich wenigstens das das Programm in Zeilen von oben Links abläuft.


----------



## afk (12 Oktober 2006)

Graph&SCL_Freak schrieb:


> Es gibt seit ca. 4 Jahren das .NET-Framework, damit hat sich das erledigt. Wer was anderes behauptet hat noch nie richtig damit gearbeitet.


Und wer behauptet, man kann mit den aktuellen Fähigkeiten von .net alle Problemstellungen lösen, der hat IMHO ein recht eingeschränktes Sichtfeld.  

An der von Ralle beschriebenen Problemstellung ändert .net außerdem gar nichts. Wer keine Ahnung hat, was im "Untergrund" abläuft, kann auch bei einer gut funktionierenden Garbage-Collection in seiner Unwissenheit wunderbare "Speicherfresser" zusammenprogrammieren, oder trotz managed Code endlos laufende Threads, die sich gegenseitig blockieren, oder ...



knabi schrieb:


> Ich denke mal, daß es eine reine Geschmacks- und Übungsfrage ist, ob man nun FUP oder AWL oder vielleicht auch SCL/GRAPH bevorzugt (wobei es eben immer auch auf den konkreten Anwendungsfall ankommt und auch auf die Finanzen - nicht jede Firma leistet sich GRAPH).


So isses, *die Sprache* für alle Anwendungsfälle gibt es nicht, nur jeweils die für den einzelnen Anwendungsfall am besten geeignete. Glücklich schätzen kann sich derjenige, der im Einzelfall weiß, welche Sprache das ist, und die dann auch noch beherrscht.  
Ich denke, das gilt für SPS und PC gleichermaßen.


Gruß Axel


----------



## Graph&SCL_Freak (12 Oktober 2006)

afk schrieb:


> Und wer behauptet, man kann mit den aktuellen Fähigkeiten von .net alle Problemstellungen lösen, der hat IMHO ein recht eingeschränktes Sichtfeld.
> 
> An der von Ralle beschriebenen Problemstellung ändert .net außerdem gar nichts. Wer keine Ahnung hat, was im "Untergrund" abläuft, kann auch bei einer gut funktionierenden Garbage-Collection in seiner Unwissenheit wunderbare "Speicherfresser" zusammenprogrammieren, oder trotz managed Code endlos laufende Threads, die sich gegenseitig blockieren, oder ...



Hat ja keiner behauptet. Die Thread-Programmierung z.B. ist unter .NET wesentlich einfacher zu programmieren als mit dem API. Und um die Garbage-Collection zu verstehen braucht man keine Assembler-Kenntnisse. Die Windows-Assembler-Programmierung ist immer noch mindestens eine Stufe unter dem API einzuordnen. Ich denke vielmehr, je weniger man Abstaktionsschichten und Frameworks benutzt umso fehleranfälliger wird der Code.


----------



## afk (12 Oktober 2006)

Graph&SCL_Freak schrieb:


> Ich denke vielmehr, je weniger man Abstaktionsschichten und Frameworks benutzt umso fehleranfälliger wird der Code.


Zumindest nimmt mit jeder zusätzlichen "Astraktionsschicht" die Menge der Fehler ab, auf die Du Einfluß hast ...  

Fehleranfälliger wird es nur dann, wenn man die entsprechende Programmiertechnik nicht beherrscht, das gilt umgekehrt auch für den Assembler-Spezialisten, der zum ersten Mal in VB programmiert.

Aber wenn Du davon überzeugt bist, daß jeder einzelne Programmierer bei Microsoft, Siemens & Co. weniger Fehler in seinen Code einbaut als Du in Deinen, dann hast Du in Bezug auf die Fehleranfälligkeit vielleicht doch Recht ... 

Ich verwende Hochsprachen, Frameworks und Bibliotheken um Zeit zu sparen, und um das Rad nicht zum X-ten mal neu zu erfinden. Der Illusion, daß ich dadurch ein fehlerfreie(re)s Ergebnis erhalte, gebe ich mich erst gar nicht hin.  


Gruß Axel


----------



## maxi (12 Oktober 2006)

Graph&SCL_Freak schrieb:


> Hat ja keiner behauptet. Die Thread-Programmierung z.B. ist unter .NET wesentlich einfacher zu programmieren als mit dem API. Und um die Garbage-Collection zu verstehen braucht man keine Assembler-Kenntnisse. Die Windows-Assembler-Programmierung ist immer noch mindestens eine Stufe unter dem API einzuordnen. Ich denke vielmehr, je weniger man Abstaktionsschichten und Frameworks benutzt umso fehleranfälliger wird der Code.


 
So mir mal Mühe gebe und auch langsam tippsle.

Kann auch seind as unsere Ansichten einfach anders sind.
Einige von uns wirden von der Basis her ausgebildet. 
Physik, Chemie, Mathe; Elektromagnetische Felder und Ladungen, Halbleider, Optoelektronik, Pneumatik, Hydraulik, Logic, Microcontrolertechnike usw. usw.

Wir haben zum Beispiel zu MS Dos auch gelernt wie man dies selber in Assembler erstellt. Da steckt auch nicht viel dahinter.
Oder als anderes Beispiel müssen wir uns ja mit allen Aktoren und Sensoren auskennen um diese in all unseren Anwenundgsbedürfnissen einsetzen zu können. Hört sich bei der Mänge an Artickeln die es gibt, ist es aber nicht. Da alles irgendwo immer wieder das gleiche ist udn auf den gleichen Grundlagen aufbaut.

Damit ist das Grundwissen für sehr vieles vorhanden.

Je näher wir an die Basis gehen, desto sicherer könen wir uns sein von allen verstanden zu werden. Die Azubis heute (Bin auch Ausbilder) haben immer noch das gleiche in den Grundthemen wie wie vor 15 Jahren. 

Die Diskussion hier lässt sich auch mit Politik vergleichen.
Es ist zwar nicht so, aber annhemen könnte man manche (Ich zum Beispiel) vertreten eine Konservative haltung. Wieder andere eine rein Fortschritt orientierte. Wieder andere rein Zielorentiert.
Die Sikussion hier an sich von den vielen Betrachtern erinnert auch etwas an Politik. Jeder probiert seinen Standpunkt durch zu pauken.

Daraus ergibt sich auf die Grundlegende Frage *Ist Fup die Technikersprache* die philosophische Antowrt:
Nur aus sicht des Betrachters gesehen.


Hoffe ist hilfreich.
Ist meine Meinung zu den Thema, andere haben natürlich eine andere.

Grüsse (Jeah gerade Frei habe)


----------



## Graph&SCL_Freak (12 Oktober 2006)

afk schrieb:


> Ich verwende Hochsprachen, Frameworks und Bibliotheken um Zeit zu sparen, und um das Rad nicht zum X-ten mal neu zu erfinden. Der Illusion, daß ich dadurch ein fehlerfreie(re)s Ergebnis erhalte, gebe ich mich erst gar nicht hin.



Na prima, dann sind wir ja dann da einer Meinung.  Fehlerfreier Code ist eh Utopie in welcher Sprache auch immer und auch Assembler hat sicher auch unter Windows in speziellen Bereichen (z.B. Treiberprogrammierung) noch seine Daseinsberechtigung. Das Verständnis der Assembler-Programmierung kann sicher nie schaden, wird aber IMHO immer weniger wichtig .


----------



## afk (12 Oktober 2006)

Graph&SCL_Freak schrieb:


> Na prima, dann sind wir ja dann da einer Meinung.  Fehlerfreier Code ist eh Utopie in welcher Sprache auch immer und auch Assembler hat sicher auch unter Windows in speziellen Bereichen (z.B. Treiberprogrammierung) noch seine Daseinsberechtigung. Das Verständnis der Assembler-Programmierung kann sicher nie schaden, wird aber IMHO immer weniger wichtig .


Na dann sind wir uns ja am Ende doch noch einig geworden, daß im Endeffekt jede Sprache ihre Daseinsberechtigung und Ihren Anwendungszweck hat, und es nie schadet, möglichst viel davon zu beherrschen ... :lol: 

... also dann, hoch die Tassen !
:sm24: 


Gruß Axel


----------



## maxi (16 Oktober 2006)

afk schrieb:


> Na dann sind wir uns ja am Ende doch noch einig geworden, daß im Endeffekt jede Sprache ihre Daseinsberechtigung und Ihren Anwendungszweck hat, und es nie schadet, möglichst viel davon zu beherrschen ... :lol:
> 
> ... also dann, hoch die Tassen !
> :sm24:
> ...


 
Ne,

die sollen alle noch Assembler lernen 
*grins breit* so wie wir damals auch mussten.

Und davor in die Werkstadt U Eisen Feilen! *lach*


----------



## afk (16 Oktober 2006)

maxi schrieb:


> Und davor in die Werkstadt U Eisen Feilen! *lach*


Bei mir war's ein Würfel, und mit dem zeitlichen Abstand kann ich mittlerweile auch drüber lachen ...  

Gruß Axel


----------



## maxi (16 Oktober 2006)

afk schrieb:


> Bei mir war's ein Würfel, und mit dem zeitlichen Abstand kann ich mittlerweile auch drüber lachen ...
> 
> Gruß Axel


 
*Bub* Wenns fürs Leben ist!

*Bub* In 20 Jahren wirst du froh sein das du das gemacht hast!

Ich bin ja nun selber auch Ausbilder. Den Sinn eines Ustückes oder Würfel feilen habe ich jedoch bis heute nicht begriffen 

Das beste war ja Relaisspulen wickeln und Kupfernieten 
Brauche ich täglich nun im Leben *fg*


der Unterscheid war aber dennoch das die uns mit Gesellenschein auf die Welt loslassen konnten. Heute bei manchen Mechatgronikern frag ich mich ob die nur 1. Lehrjahr hatten


----------

