# Hilfe ich bin ein Newbie. AWL, FUP, KOP oder SCL ????



## DotNet (18 Juni 2007)

hallo Leute,

seit ca. 2 Wochen beschäftige ich mich mit Simatic SPS. Dazu habe ich auch eine umfangreiche Recherche gemacht. Die Informationen im internet sind sehr weit verstreut.

Ich programmiere seit vielen Jahren mit den Entwicklungswerkzeugen von Microsoft (VB, C#) und hatte gehofft, dass im Zusammenhang mit den .Net-Technologien SPS möglich ist. Diesbezüglich habe ich nix gefunden. Also habe ich mich mit den aktuelle Technologien um SPS beschäftigt. Insbesondere habe ich mir in diesem Zusammenhang die Tools von Siemens angeschaut, die recht interessant sind. Auch mit CodeSys lassen sich komplexe SPS Aufgaben lösen. So hab ich das zumindest verstanden. 

So wie ich das gesehen habe gibt es AWL, FUP und KOP, um SPS Programme zu implementieren. Diese sind aber bei wachsender Kompläxität sehr unübersichtlich. Anders schein das ST (Structured Text) zu sein. Es ist eine Hochsprache, ähnlich wie Pascal, was für mich auch viel verständlicher ist. 

Mein Frage an dieser Stelle ist nun, wie ich am besten vorgehen soll ? Reicht es aus, wenn ich AWL, FUP und KOP prinzipiell verstehe und mich hier auf ST (SCL) spezialisiere ? Ich habe gelesen, dass SCL viel mehr Möglichkeiten anbietet. Ist das wirklich so ? Wie ist die Verbreitung von SCL ? 

Ich habe jahrelang mich mit dem Management von Softwaresystemen beschäftigt und hatte mich auch während meines Informatik-Studiums darauf spezialisiert, Systeme zu managen. Mit Maschinen hatte ich bis jetzt nix zu tun. Leider. Ich finde dieses Thema faszinierend und möchte daher von Euch einen Rat, wie man am besten in die Welt der Automatisieren einsteigen kann.


----------



## TobiasA (18 Juni 2007)

Hallo!

FUP und KOP eignen sich recht gut zum Darstellen binärer Operationen (wenn diese Bedingung und Eingang soundso, dann schalte Ausgang XY). Mit AWL kann man Rechenoperationen etc. relativ einfach und unkompliziert programmieren, und solche Sachen wie z.B. Pointer gehen halt nicht in FUP oder KOP. Es gibt auch eine Art kleinen Glaubenskrieg zwischen AWL und KOP  
Wer AWL gewohnt ist, schreibt häufig auch binäre Funktionen in AWL, statt dafür nach FUP oder KOP zu wechseln. Zwischen FUP und KOP kann man auch hin- und herschalten, zu AWL lässt sich immer umschalten, nur um von AWL nach KOP oder FUP umzuschalten, muss man eine bestimmte Syntax einhalten.
SCL kann ich leider selbst nicht (muss mir mal 'n Buch kaufen...), das ist aber eine Sprache, mit der man sehr schön z.B. Abfrageroutinen, Schleifen und komplexere Rechenoperationen machen kann (soweit ich weiß).
ST gibt's bei Siemens glaube ich nicht... CoDeSys kann's, aber befasst habe ich mich damit noch nicht.
Es kommt auch immer auf den Bereich an, in dem du arbeitest- ich habe zum Beispiel am meisten mit AWL zu tun (Sinumerik). Binäre Verknüpfungen sind in FUP oder KOP sehr übersichtlich, mit ein bisschen Übung auch in AWL, weil man eben einfach dran lang lesen kann
U E0.0
E E 0.1
= A 0.0
und dann entweder im Verknüpfungsergebnis (VKE, online) oder eben an den Linien sofort den Signalstatus erkennt.
Für z.B. die Platzsuche im Hochregallager mit 2000 Plätzen sind die drei "Grundsprachen" aber nich so dolle.

Wenn du ein komplexes Programm schreibst, ist das auch in AWL, FUP, KOP übersichtlich zu machen- du musst es aber sauber dokumentieren (was man eh machen sollte). Siemens lässt sich prima kommentieren und dokumentieren (das ist z.B. bei Fanuc schon wieder anders). Wenn du natürlich deine Netzwerkkommentare nicht mitschleifst, suchst du dich nachher blöd. Aber das ist ja allgemein beim Programmieren so.

Es gibt übrigens auch ein Paket zur Programmierung in C für S7. Irgendwo im Forum hatte auch jemand 'n Link dafür.

Gruß, Tobias


----------



## TagebauCoder (18 Juni 2007)

*In SCL bist du zu Hause!*

Moin DotNet!

Mit deinen Vorkenntnissen würde ich eindeutig auf SCL Coden, aber um ein Grundwissen in AWL und SPS'n, wirst du nicht herumkommen. Da eine Inbetriebnahme nicht nur in SCL erfolgen kann, bzw. sehr unkomfortabel ist.

SCL müsste deinen bekannten Sprachen am nächsten liegen, vonwegen Schleifen, Kontrollstrukturen und so.
Wenn du in SCL codest, wird dieser Code in einen SPS verständlichen code namens AWL übersetzt vom SCL Compiler.
SCL ist sehr mächtig für komplexe Rechenaufgaben. Für reine Steuerung ist dem Instandhalter zu Liebe, FUP eindeutig vorzuziehen.

mfg
 TagebauCoder


----------



## TobiasA (18 Juni 2007)

Zwei neue Benutzer an einem Tag...  

Herzlich Willkommen im Forum!

Gruß, Tobias


----------



## zotos (18 Juni 2007)

Bevor hier wieder ein Glaubenskrieg über Sprachen ausbricht.

Jeder Programmierer hat da seine Vorlieben und noch viel schlimmer Jeder Kunde hat seine Vorschriften. Das ist bei SPSen oft noch schlimmer als bei PC-Software. Da der Kunde mittels der Debug Funktionen (online Betrachtung vom Programmablauf) Hardware Fehler finden muss.

Meine Einschätzung zu den Sprachen:

FUP (und KOP) sind sehr SPS spezialisierte Sprachen und eigen sich hervorragend um Bitverknüpfungen darzustellen. Die sprachen sind sehr visuell und man kann schnell einen Überblick erhalten welche Bedingungen erfüllt sein müssen das eine Aktion erfolgt. FUP und KOP lassen sich oft auch einfach umschalten. Wenn man andere Dinge als Bitverknüpfungen damit löst wird es aber schnell unsauber.

AWL ist sehr Assembler ähnlich man kann sehr kleine Programme schreiben und die tollsten Tricks damit anstellen und die Übersichtlichkeit geht auch schnell flöten. Es fehlen viele Strukturelemente die man von Hochsprachen gewöhnt ist. Also für wirklich komplexe Sachen eher ungeeignet.

SCL ist sehr komfortabel die Befehle sind sehr an Pascal angelegt und da her gut zu lesen da es wenige Symbole gibt und viel ausgeschrieben wird. Also ein logisches Und ist "AND" und nicht wie z.B. in C "&&", eine Negation ist NOT und kein "!". Die Strukturelemente sind in großer Anzahl vorhanden. 
Man kann auch Komplexe Aufgabenstellungen übersichtlich lösen.


----------



## o.s.t. (18 Juni 2007)

TobiasA schrieb:


> ST gibt's bei Siemens glaube ich nicht...


ST=SCL http://de.wikipedia.org/w/index.php?title=Structured_Control_Language&redirect=no

zum ganzen gibts noch zu sagen, dass je nach Klientel die eine oder andere Programmiersprache vorgeschrieben bzw. abgelehnt wird (v.a. SCL) da das  Unterhaltspersonal damit Mühe hat  (ist zumindest in unserer Branche so)

gruss, o.s.t.


----------



## zotos (18 Juni 2007)

TobiasA schrieb:


> ...
> ST gibt's bei Siemens glaube ich nicht... CoDeSys kann's, aber befasst habe ich mich damit noch nicht.
> ...



@TobiasA:

SCL und ST sollten weitgehend kompatibel sein.
Wenn Du Lust hast schau dir mal die OSCAT Lib an die gibt es in einer ST Version für CoDeSys und in einer Angepassten Version für Step7.


----------



## TagebauCoder (18 Juni 2007)

o.s.t. schrieb:


> ST=SCL http://de.wikipedia.org/w/index.php?title=Structured_Control_Language&redirect=no
> 
> zum ganzen gibts noch zu sagen, dass je nach Klientel die eine oder andere Programmiersprache vorgeschrieben bzw. abgelehnt wird (v.a. SCL) da das  Unterhaltspersonal damit Mühe hat  (ist zumindest in unserer Branche so)
> 
> gruss, o.s.t.



Das ist das was ich mit: " Dem Instandhalter zu Liebe" meinte


----------



## Jochen Kühner (18 Juni 2007)

*Scl...*

Also, Ich bin nun auch schon seit 5 Jahren in der automatisierungstechnik tätig, und habe schon in 3 Softwarehäusern gearbeitet. Aber SCL haben wir in noch keinem eingesetzt. Vorallem wenn man Anlagen für größere Industiebetriebe Programmiert, dann gibts genaue vorgaben was verwendet werden darf und was nicht! Und das ist bei uns meist nur KOP/FUP und AWL!


----------



## zotos (18 Juni 2007)

Die Automatisierung ist schon ein komisches Feld alle wollen immer sooo... Innovativ sein und schreiben das frech weg auf ihre Homepage.

Allerdings wenn es es um ST/SCL geht berufen sie sich auf Kundenwünsche die noch aus den 80igern stammen. Wenn es um den dreifachen Quellcode Ausdruck geht werden die Leute meist findig und erklären dem Kunden das es eh kein Sinn macht da das Papier keiner mehr in die Hand nimmt. Bei dem Thema ST/SCL wird nur selten der Kunde mit der Option seine Leute zu Schulen konfrontiert. Wo bei sich doch damit auch gut Geldverdienen lässt. 

Aber mir kommt es so vor als ob viele Leute denken ST/SCL wäre nur erfunden worden um es den Hochsprachen Programmieren recht zumachen.
Was quatsch ist. Es ist eine Erweiterung um komplexe Aufgaben strukturiert  zu lösen das man sie auch leichter Nachvollziehen kann. 

Um einen werten Kollegen aus dem Forum zu zitieren: "wer nicht mit der Zeit geht, der geht mit der Zeit" (nade)


----------



## Dumbledore (18 Juni 2007)

zotos schrieb:


> Was quatsch ist. Es ist eine Erweiterung um komplexe Aufgaben strukturiert zu lösen das man sie auch leichter Nachvollziehen kann.


 
Ich kann das nur unterschreiben.

Ich leite eine Abteilung die u.a. die Steuerungen für Transportanlagen plant und baut bzw. bauen lässt, üblicherweise mit Siemens Hard- und Software.

Dabei haben wir i.d.R. keine genauen Kundenvorgaben.

Ich habe das dazu ausgenutzt, für jeden Zweck die geeignetste Sprache einzusetzen. Ich gehe üblicherweise so vor:

- Basisverriegelungen : FUP (Funktionsplan)
- einfache Automatikabläufe : FUP oder GRAPH7
- Automatik komplexer Maschinen : Higraph
- Logistikfunktionen und Datenbanken etc.: SCL
- Systemfunktionen (soweit nötig) : AWL
- unterlagerte FBs von div. Komponenten : gesperrte FBs der Lieferanten

Das hat den Vorteil, dass ich für jede Aufgabe die wirklich passenden Tools habe. Logistik und Datenbanken in AWL ? Schauder ... komplexe Schrittketten ? Graph oder Higraph sind ideal dafür. Systemfunktionen - anders als in AWL meist gar nicht machbar. Für die Planung ist dieser Zustand meines Erachtens ideal.

Bei gut dokumentierten Schnittstellen ist das alles auch kein Problem. Die Programmierung muss natürlich so erfolgen, dass $Schichtelektriker einen fehlerhaften Endschalter in FUP (oder wahlweise KOP) leicht finden kann, was aber bisher ohne Probleme möglich war.

Schulung für die Kunden ist dann ein Nebeneffekt, den wir ebenfalls gerne verkaufen. 

Eingriffe in zum Beispiel die Logistik einer Transportanlage gehen sowieso über das Verständnis von $Elektriker hinaus (meine Erfahrung, sorry).

Und nebenbei haben wir so ein wenig Know-how-Schutz in unseren Anlagen eingebaut, denn ein simpler Speicherabzug ist nicht mehr möglich bzw. nicht mehr analysierbar 

Ich kann aber nur unterstreichen, dass dies das Ergebnis einer bestimmten Konstellation ist und keinesfalls bei allen Kunden und Branchen so machbar wäre, meine Vorredner hatten da ja teils ganz andere Erfahrungen.

Gruss Michael aka Dumbledore


----------



## zotos (18 Juni 2007)

100% Ack.
Für die Aufgabe die Passende Sprache zuwählen ist ein wichtiger Schritt zum Erfolg. Nutze die Stärken des Systems.



Dumbledore schrieb:


> ...
> Eingriffe in zum Beispiel die Logistik einer Transportanlage gehen sowieso über das Verständnis von $Elektriker hinaus (meine Erfahrung, sorry).
> ...



Ich kenne auch Firmen die, die Logistik der Transportanlagen in eine Übergeordnete Steuerung (Server) legen da kann auch der Kunde nicht in den Quellcode schauen und akzeptiert dies ohne zu heulen.


----------



## Ralle (18 Juni 2007)

Dumbledore schrieb:


> Dabei haben wir i.d.R. keine genauen Kundenvorgaben.



Habt ihr es gut, womit hast du deine Kunden verhext ?

Amikunden--> alles in LADDER (auch Schauder).

Datenbanken in AWL--> gar nicht so schlimm , aber du hast Recht, das kann man mit SCL viel einfacher haben und die Instandhalter wollen meißt gar nicht so tief unseren "Programmiersumpf" einsteigen.


----------



## zotos (18 Juni 2007)

Ralle schrieb:


> ...
> Amikunden--> alles in LADDER (auch Schauder).
> ...



Bei uns nicht ;o)


----------



## nade (18 Juni 2007)

Also ersteinmal die Frage, wie weit willst du ins Steuerungs-/Regelungs-Gebiet rein?
Soll es "einfache" Steuerung ohne Analogwerte und Datenbanken sein, so würde ich aus meiner Sicht sagen, FUP oder bei etwas mehr Einblick AWL.
Willst du mit Allen´s Brötchen /Allen Breadly was machen, mußt du schon richtung AWL und KOP gehen. Im Groben wer einen Schaltplan gelesen bekommt hat mit KOP strichemalerrei weniger Probleme.
Zudem wäre es trotz Programierkenntnisse auch von Vorteil in praktische Steuer und Regeltechnik etwas einzuarbeiten, das macht das ein oder andere etwas verständlicher.
Meine richtung, um tiefer in die Materie einzusteigen:

Steuerungstechnik allgemein vertiefen
↓
FUP/KOP // wobei selbst mit KOP noch nie was zu tun gehabt, außer in VPS                       
                "programieren"
↓
AWL // erst jetzt, weil durch genannte Ansichtwechsel die Befehlsstruktur klar 
           wird
↓
ST/SCL // wissen die Vollblutprogramierer bestimmt nach AWL ehr was noch 
               oder wie besser

Und zu den Transportanlagen, hatte ich meines grauen Wissens bei einer Firma auch die servergestütze Fassung gesehn. Problem um das nachzuprüfen ist, die Firma ist schon vor ca 7 Jahre pleite gegangen... die Recyclingfirma, die nacher in der Halle war hatte diese Bandanlage nie benutzt, und die Firma ist seit ca 1 Monat in Flammen und Rauch aufgegangen. Kollega Zotos müßte evtl was dadrüber gehört haben, Standort war in WND-City.
Und Ralle das mit in die Programierung tiefer einsteigen, wird allein schon durch Stillstandszeiten und fehlende Kenntnis bzw tiefe der Kenntnisse vorkommen.
Wenn ersichtlich ist, wo der Fehler liegt, dann läßt sich der z.B. deffekte Endschalter oder was auch immer recht schnell ohne tiefere Kenntnis des Programs beheben.Beim PC interessiert ja schließlich die Programierstruktur den Anwender und Servicemenschen recht wenig. Bauteil ist kaputt, austauschen und das wars.. 
Da kein Waffenhändler, ist dies alles ohne Gewehr.


----------



## zotos (18 Juni 2007)

nade schrieb:


> ... die Recyclingfirma, die nacher in der Halle war hatte diese Bandanlage nie benutzt, und die Firma ist seit ca 1 Monat in Flammen und Rauch aufgegangen. Kollega Zotos müßte evtl was dadrüber gehört haben, Standort war in WND-City.
> ...


Ja das war doch die Geschichte mit dem Feuerwehrmann und dem Millionenschaden wo ich im Radio gehört habe. Der wird nun auch nicht mehr froh.


----------



## nade (18 Juni 2007)

Japp genau diese. Also unbestätigt ist das er in einem Betrieb der in dem Gebäude ansässig war gearbeitet hatte und er soll vor Jahren Heuballen angesteckt haben, was allerdings nicht bewiesen werden konnte.
Und dabei war das doch eine sooo schöne Bandanlage, mit 2 Doppeltürigen Rittalschränken voll SPS und Barcode Lesesysteme.
Nun ja ich denke der wird wirklich nimmer froh, mal von ab, das er in Therapie gesteckt worden ist. Die Firma die da Insolvent gewesen sein soll wird sich drüber bestimmt freuen.


----------



## TobiasA (18 Juni 2007)

An den Sinumerik kann man dann wiederum kaum was mit Graph anfangen...

Wir haben dann meist mit AWL zu tun- aber als Händler und Service muss man eh nehmen, was kommt. Die Sprache zu benutzen, die am Besten zum Einsatzzweck passt, ist sicherlich der richtige Weg.

Danke für den Tip mit dem ST/SCL- muss mir irgendwann wohl doch mal das SCL- Implantat für Step7 besorgen. Ist nur für Jux leider doch ein bisschen teuer.

Gruß, Tobias


----------

