# Wie programmiert der Praktiker ?



## achim532000 (13 März 2008)

Hallo,
ich arbeite als Ausbilder an einer gemeinnützigen Schule in der Automatisierungstechnik und bilde arbeitsuchende Fachkräfte und Azubi aus. SPS gehört im großen Umfang dazu. Habe da aber nur Schulerfahrung oder Angelesenes. In VPS habe ich umfangreiche Industrieerfahrung die ich versuche auf die SPS zu übertragen. 
Um möglichst praxisnah ausbilden zu können steht uns ein MSS von Bosch mit 4Stk. S7-314 128 DI/64 DO und einige Eigenbau-Anlagen mit 315-2DP, PROFIBUS-CP, WAGO-Knoten, AS-I und MPI zur Verfügung.
Da kaum Kontakt zu Praktikern in Unternehmen vorhanden ist, meine Frage: Wie programmiert die Praxis ? AWL, FUP, KOP, GRAPH, SCL, wie verbreitet sind AS-I, PROFIBUS-DP, PROFINET oder andere Systeme ?
Bin dankbar für alle praktischen Tips und Hinweise die in der Ausbildung Anwendung finden können.

Gruss Achim


----------



## vierlagig (13 März 2008)

achim532000 schrieb:


> Da kaum Kontakt zu Praktikern in Unternehmen vorhanden ist, meine Frage: Wie programmiert die Praxis ? AWL, FUP, KOP, GRAPH, SCL, wie verbreitet sind AS-I, PROFIBUS-DP, PROFINET oder andere Systeme ?
> Bin dankbar für alle praktischen Tips und Hinweise die in der Ausbildung Anwendung finden können.



hallo achim,

den kontakt haste ja jetz begonnen aufzubauen, vernünftiger schritt, wenn ich bedenke was bei uns so als azubi durch geht, gilt es das eigentlich nur zu unterstützen ...

meine kleine unbedeutende einschätzung:
AWL - verbreitet wie sau 
FUP - jeder der ein wenig digitaltechnik verstanden hat, versteht FUP, da es viele davon gibt, die nicht mehr verstehen, findet man FUP in fast jedem prog
KOP - minizotos sagt immer "mitn finger die verknüpfungen verfolgen", stromlaufplan verstehen kann man? dann kann man auch KOP verstehen, bei uns sehr verbreitet, da in den liefervorschriften empfohlen ...
GRAPH - ich hab schon mal von leuten gehört, die das einsetzen ... 
SCL - totgeburt oder eierlegende wollmilchsau, bin mir nicht sicher, aber gesehen hab ich davon bis jetzt recht wenig, außer das was ich einsetze ...

bei uns läuft der hauptteil der feld-kommunikation über profibus-dp, steuerungsvernetzung über Industrial Ethernet, die Visualisierung eben so ... profinet spielen wir grad bißchen mit ner test-cpu rum ... leider zu wenig ASi, dafür ganz viel Interbus ...

kannst dich auch bißchen durchs forum wühlen, da wird sehr schnell deutlich was aus der praxis kommt und was einem lehrling aufgetragen wird (ein taster - ein ausgang ... das scheint vielerorts die jahresaufgabe zu sein :twisted

grutz
vierlagig


----------



## Lipperlandstern (13 März 2008)

achim532000 schrieb:


> Hallo,
> ich arbeite als Ausbilder an einer gemeinnützigen Schule in der Automatisierungstechnik und bilde arbeitsuchende Fachkräfte und Azubi aus. SPS gehört im großen Umfang dazu. Habe da aber nur Schulerfahrung oder Angelesenes. In VPS habe ich umfangreiche Industrieerfahrung die ich versuche auf die SPS zu übertragen.
> Um möglichst praxisnah ausbilden zu können steht uns ein MSS von Bosch mit 4Stk. S7-314 128 DI/64 DO und einige Eigenbau-Anlagen mit 315-2DP, PROFIBUS-CP, WAGO-Knoten, AS-I und MPI zur Verfügung.
> Da kaum Kontakt zu Praktikern in Unternehmen vorhanden ist, meine Frage: Wie programmiert die Praxis ? AWL, FUP, KOP, GRAPH, SCL, wie verbreitet sind AS-I, PROFIBUS-DP, PROFINET oder andere Systeme ?
> ...


 
Hallo Achim.

Ich arbeite in einem mittelständischen Maschinenbauunternehmen. Bei uns findest Du KOP/FUP/AWL, Profibus, AS-I, WinCC, WinCCflex.

SCL und GRAPH programmieren wir noch nicht.


----------



## Dabbes vorm Herrn (13 März 2008)

Hallöle,

in unserem mittelkleinem (60-Mann starkem) Betrieb werden von den Programmierern die Progs gerne mit AWL geschrieben, weil sie ja leider nicht jeder lesen kann 

Ich tendiere meist zu KOP, damit die "normalen" Servicetechniker meinen Gedankensprüngen ins Hier und Jetzt evtl. besser versehen können. Das gilt aber nicht für Sprungoperationen. Da muß sich "Normale" eben doch in AWL eindenken.....

... Und was in KOP programmiert ist, läßt sich ja meist auch in FUP übertragen (es gibt Ausnahmen, wie ich letztens sah).

Graph kenne ich nur vom Hören, Gesagt hat noch nie wer was darüber.

SCL wird bei uns (mir bekannterweise) nicht verwendet.


Da wir nicht wirklich viele CPU`s miteinander kommunizieren lassen müssen, wird nur ab und an ASI und Profibus-DP verwendet. Jüngst setzen wir auch Teile für Fernwartung ein. (Mit was für ner Verbindung das läuft, weiss ich aber noch nicht).

Da ProTool ja ausläuft, setzen wir für unsere TP`s und MP`s WinCC ein...

... Ach ja.... wir setzen nur Siemens ein ......


Dein Schritt in dieses Forum finde ich super. Hier findet sich super schnell Hilfe, sei es in älteren Threads oder in der Soforthilfe via Antwort.
... Und geh mal bei Siemens.de was suchen bei nem Problem.....  :twisted:


----------



## Kieler (13 März 2008)

Hi,

ich arbeite seit Jahren in der Verfahrenstechnik. Bei uns wird an Steuerungn eingesetzt :
80 %  Siemens
10 %  Schneider 
10 % sonstiges

Die Siemens SPS werden zu
80 % AWL
10 % KOP (meistens nur Baustein aufrufen, der intern AWL hat)
10 % sonstiges SCL .... fast kein Graph

Bei neueren Anlagen läuft die Kommunikation zwischen den Steuerungen vorwiegend über Ethernet, manchmal auch MPI oder Profibus. In der Feldebene ist Interbus eigentlich ganz weg und von Profibus abgelöst. Das bleibt noch eine Weile so und wird irgendwann wohl in Profinet übergehen. 

Im Kommunikationsbereich wird auch häufiger Modbus/Modbus on TCP eingesetzt.

Gruß aus Kiel


----------



## vladi (13 März 2008)

*S7 Graph*

Hi,
so, jetzt einer von den Verwendern von S7 GRAPH:
Fallunterschiede:
1) Produktionsanlage mit sequentielle Vorgänge(Fließband): Sensor erkennt Teil->Zylinder geht nach vorn... usw.
- Sequenzprogramm im FUP/KOP
2) Anlage mit gemischte Prozesse, Regelungen, Arithmetik, Rezepte:
- Programm mit wenig FUP, AWL, evtl.SCL für die Berechnungen
2) Anlage mit Produktionsprozesse, evtl.rezepturgesteuert, mit viele Anforderungen an Dokumentation und Qualifizierung:
- Programm mit GRAPH, die Prozesse sind somit 1:1 abgebildet, man kann die Schrittkettenausdrücke für *Funktionstest und Qualifizierung* verwenden; beim Einsatz von PCS7 kann man sogar die programmierten Schrittketten in der Visu *beobachten und bedienen*(auto, hand usw.), somit kein weiterer Aufwand Visu.

Ich denke, die Implementierung soll die Anlage und die Anforderungen folgen; pauschalisieren kann man hier schlecht.

Vladi


----------



## vierlagig (13 März 2008)

Dabbes vorm Herrn schrieb:


> ... Und geh mal bei Siemens.de was suchen bei nem Problem.....  :twisted:



ich verweise immer wieder gern auf die *service&support-seiten*, handbücher und getting started als pdf findet man da schnell und problemlos und in den meisten fällen kann man die aufgelaufenen fragen damit erschlagen ...


----------



## kiestumpe (13 März 2008)

*SCL-Verwendung*

Hallo,

für SCL würde ich folgende Anwendungen vorstellen:

FC-Programmieren für Berechnungen (z.B. Skalierung,Kalibrierung)

FB-Programmierung: Motor-FB mit Störungsquitterung,
oder kleine Schrittkette mit CASE-Anweisungen (z.B. für Ampelsteuerung)

Was ich nicht empfehlen kann, sind irgendwelche Sortieralgorithmen
um SCL vorzustellen, hat hier nix mit dem Thema zu tun.

Also ganz ausgelassen werden sollte das Thema SCL auf jeden Fall nicht.

Gruss und hth

kiestumpe


----------



## Larry Laffer (13 März 2008)

...zu diesem Thema muss ich meinen Senf auch noch dazu geben :

AWL, KOP , FUP wie schon genannt ...

SCL für mich ein MUSS, wenn ich Schleifen, Berechnungen oder Auswertungen erstelle - Ist einfach übersichtlicher ... 
Es findet in jedem Fall bei mir mehr und mehr Einsatzfälle.

Vernetzung bei uns : ASI und Profibus-DP - beides hat so seine Einsatz-Berechtigung ...

Gruß
LL


----------



## achim532000 (13 März 2008)

*Wie programmiert ??*

Hallo, 
Dank Allen die bisher geantwortet haben. Hilft mir sehr viel weiter. Würde mich aber auch über weitere Antworten und Tips freuen.

Also erst mal einen Zwischendank aus dem Harz

Achim


----------



## marlob (13 März 2008)

Hallo achim532000,

ich habe letzte Tage auch noch mit einem Lehrer von einer Technikerschule über dieses Thema gesprochen. Er holt sich regelmässig Programmierer und Lieferanten von Hard-/Software in die Schule damit diese eine Präsentation oder eine kleine Schulung geben. Wenn man das geschickt macht, verursacht das auch nicht allzu viel Kosten.
Vielleicht wäre das auch was für eure Schule.


----------



## Dabbes vorm Herrn (13 März 2008)

vierlagig schrieb:


> ich verweise immer wieder gern auf die *service&support-seiten*, handbücher und getting started als pdf findet man da schnell und problemlos und in den meisten fällen kann man die aufgelaufenen fragen damit erschlagen ...





Wenn man genau weiss, wonach man sucht.......

Ab und an stehe ich aber auch vor nem Prob und sehe den Wald vor lauter Bäumen nicht. Da hilft mir dann der Support nicht wirklich weiter. Weder via Internet, noch via Anruf bei der Hotline.

Da kommt diese Seite hier mir schon gelegener. Suchen - meist gefunden - klappert!


----------



## Perfektionist (13 März 2008)

Die Praxis in meinem Umfeld ist AWL, KOP, FUP und Profibus-DP. Ich persönlich programmiere ausschließlich AWL. Welche Sprache man wählt, hängt stark vom Einsatzfall ab - bei mir liegt es daran, dass ich einige Berechnungen in meinen Programmen habe und daher ohnehin oft genötigt bin, AWL einzusetzen. Zu S5-Zeiten hab ich das noch gemischt, für S7 hab ich dann entschieden, alles in AWL zu formulieren.


----------



## Roos (13 März 2008)

Morgen,

also bei uns im Mittelständigen Maschienenbauunternehmen wird von mir eigendlich zu 80% in AWL programmiert die restlichen 20% teilen sich in alle anderen Sprachen (kop,fup,scl und graph) auf je nach wunsch des kunden erstellen wir auch soweit es mir möglich ist die Programme nach seinen Forderungen also z.b. nur fup oder kop.
Scl brauchte ich bis jetzt nur bei meiner dipl. arbeit für die moby anbindung in der großindustrie (Bauknecht).
Graph verwende ich des öfteren bei einfachen sich immer gleich wiederholenden abläufen. z.b Teil einlegen-->start-->Schutz zu-->Zylinder vor-->teil anpressen-->zylinder zurück-->Schutz auf--> teil entnehmen... also einfache Ablaufsteuerungen ohne Servo oder Roboteranbindung....


AWL for ever :twisted:

Anbindungen meißt Profibus und Visualisierung (also panels) mit Profinet... Asi bus meist verwendet für roboteranbindung.

Hoffe ich konnte dir helfen.

MfG Roos


----------



## taucherd (13 März 2008)

Hallo,

für mich ist SCL eine Programmiersprache mit sehr großen Vorteilen. Da der SCL Code auch für andere Steuerungen verwendet werden kann z.B.: auch bei Omron Funktionsbausteinen. Und somit keine doppelte Arbeit, es ist nur ein wenig Anpassung nötig. Im Anhang ein kleines Beispiel von einem Betriebsstundenzähler in AWL, SCL und den SCL in den CX_Programmer kopiert - mit ein wenig Anpassungen. Meine Meinung ist: Durch diesen Vorteil (das ist nur einer von vielen) ist es ein sehr gutes Werkzeug. Bei meiner alten Firma war das komplette Programm (OB, DB, FC, FB, Strukturen) alles in SCL.


----------



## dodo (13 März 2008)

Da geb ich auch mal meinen Senf zu:

AWL: 
Ist und bleibt das Beste Leute, die programmieren wollen und können!
Kästchen aneinanderhäkeln kann ja jeder! 
Mit AWL geht halt Alles!
Versuch mal in FUP einer Integer Variable einen Byte Wert zuzuweisen 
Ausserdem kann man in AWL halt besser kommentieren (Zeilenkommentare)
Einziger Nachteil: Es kann nicht jeder nachvollziehen.




KOP:
Hat halt wie schon beschrieben den Vorteil, dass es Ähnlichkeit mit einem Stromlaufplan hat (vor allem mit einem amerikanischen)
Ich persönliches find's Sch..., weil unübersichtlich.


GRAPH:
GRAPH 5 war super zu programmieren, GRAPH 7 find ich überlastet und unübersichtlich.

SCL: 
Für Steuerungsaufgaben nicht so der Bringer. 
Wenn aber Daten zu verwalten sind, super Sache. Man muss halt Hochsprache programmieren können!
Bsp: Ich habe auf ner Steuerung eine Liste  von Seriennummern.
Bis zu 60 passen in die Liste rein.
Gerät fährt in eine Linie rein, wird in die Liste aufgenommen.
Gerät fährt 2 h später hinten aus der Linie raus und wird aus der Liste wieder gelöscht. Beim Löschen muss man das Gerät in der Liste finden und löschen, beim Aufnehmen einen freien Platz in der Liste finden und Daten reinschreiben. 
In AWL: Viel Spass dabei! 
In SCL: Knapp 20 Zeilen


----------



## vierlagig (13 März 2008)

dodo schrieb:


> Versuch mal in FUP einer Integer Variable einen Byte Wert zuzuweisen




```
____________
           |    MOVE    |
           |            |  
#zuweisen -+ EN     OUT +- #INT_variable
           |            |
           |            |
   B#16#F -+ IN     ENO +- 
           |____________|
```
 ...hatten wir doch heut schon mal...


----------



## M4RKU5 (13 März 2008)

Ich arbeite als Diplom-Ingenieur in einem sehr großen Elektronik-Konzern.  Bei uns wurde bisher in AWL programmiert, doch das Managment schreibt nun Richtlinien zur Verwendung von SCL vor. IMHO geht wohl der Trend bei komplexen Steuerungen zu SCL, und das mit recht.


----------



## Werner54 (13 März 2008)

*Alles eine Frage der Dosis*

Hallo,

wer eine z.B. Schleusensteuerung mit 2 gegenseitig verriegelten Türen mit Multiinstanzen aufbaut, der gehört verhauen.
Und wer eine komplexe Industrieanlage mit mehreren Teilanlagen in AWL runterklopft, gehört nicht vors PG.
Im Übrigen: MOVE funktioniert immer, allerdings nur mit undefinierten Variablen (Merker). Sind die verwendeten Variablen in der Symboltabelle oder in der Bausteinschnittstelle eingetragen, greift die Typüberprüfung. [Scherz EIN] Also möglichst nichts dokumentieren, dann funzts!


----------



## beowonne (13 März 2008)

*Ja wie bloss ?!*

Erst einmal finde ich super das sich jemand Gedanken macht wie es nun wirklich in der Praxis aussieht.
Bei uns geht es vorrangig um Fehlersuche und da ist Fup/Kop ganz weit vorn (z.Bsp.defekten Initiator finden),viele Kollegen klappen bei AWL den Baustein glatt wieder zu .

Auch als Einstieg ist Fup super und wenn das sitzt kommt man automatisch zu AWL .
Jede Sprache hat halt ihre Vor/Nachteile.
Wir haben auf etwa 30 Steuerungen 60%Fup 30%AWL 10% SCL  (Tendenz scheint aber in Richtung SCL zu gehen )


----------



## sps-concept (13 März 2008)

*meine Meinung*

Hallo!

@Werner


Werner54 schrieb:


> MOVE funktioniert immer, allerdings nur mit undefinierten Variablen (Merker). Sind die verwendeten Variablen in der Symboltabelle oder in der Bausteinschnittstelle eingetragen, greift die Typüberprüfung.



das ist mir neu! MOVE kennt keine Typprüfung - es kann alles von 1-4 Byte wild durcheinandertransferieren.

@Taucher


taucherd schrieb:


> Bei meiner alten Firma war das komplette Programm (OB, DB, FC, FB, Strukturen) alles in SCL.



das ist ja für mich noch schlimmer als alles in AWL zu programmieren. Was für einen Sinn machts denn Verknüpfungslogik in SCL zu programmieren? Wohl nur einen - nen gewissen Know-How-Schutz indem man die Quelle nicht mitliefert. So werden doch die einfachsten Sachen masslos aufgebläht. Beispiel Zähler mit Flankenerkennung: das AWL-Ergebnis sieht so aus:



> SET
> SAVE
> =     L      0.1
> U     #ZaehlImpuls
> ...



Ausserdem wie soll man bei nem Fehler etwas sinnvoll finden?

André


----------



## kiestumpe (13 März 2008)

Mir wird's da: :sb5:

Hier die Alternative in SCL, kann mit q und Reset sogar kaskadiert werden.


```
q := FALSE;
    IF Z < 32767 THEN
        IF FLANKE AND NOT FL_BIT THEN
            Z:=Z+1;
        END_IF;
    ELSE
        q := TRUE;
   END_IF;
    IF RESET THEN
        Z := 0;
    END_IF;
    FL_BIT := FLANKE;
  
  FC192 := q;
```

Größe: 146 Bytes


----------



## sps-concept (13 März 2008)

*Scl -> Awl*

na was denkste wovon mir schlechtwird? Setz doch mal rein was im Baustein effektiv drinsteht wenn du ihn in AWL öffnest.

André


----------



## vladi (13 März 2008)

*in AWL öffnen*

Hi,


sps-concept schrieb:


> na was denkste wovon mir schlechtwird? Setz doch mal rein was im Baustein effektiv drinsteht wenn du ihn in AWL öffnest.
> André


 
Kollege, wir sprechen hier wie man Software schnell und gut programmiert, mit dem Einsatz von verschiedene Komponenten: nicht wie man was öffnet! SCL öffnet man im SCL Editor, genauso GRAPH mit dem GRAPH Editor(hatte ich schon mal: GRAPH FB im AWL Editor geöffnet ).

Vladi


----------



## zotos (13 März 2008)

Da % Angaben ja gerade Mode sind ;o)
90% ST (~SCL)
10% AS (~Graph7)

Wobei die Angabe von Prozent völliger Quatsch ist da der Bezug fehlt. Geht das auf Programmgröße im Speicher? Bildschirmseiten? Ich geh mal von benötigter Zeit aus.

Wenn man eine Merkerschrittkette von Hand zu Fuß in KOP programmiert und dokumentiert und dann viel mehr Zeit braucht als für eine Sprungliste in AWL oder eine CASE in SCL oder eben bei der Graphischen Lösung in Graph7. Bekommt dann KOP mehr % als die besseren Alternativen in den anderen Sprachen. Ist KOP dann besser da es mehr % hat?

Wer heute neu in den SPS Bereich einsteigt ohne einen blasen Schimmer von Hochsprachen zu haben, hat sich sicher im Beruf vergriffen.

PS: Als SPSler sollte man unter Maschinennaher  Programmierung nicht an die Poplige SPS denken sondern an die Abläuft in der Maschine bzw. Anlage. Um Die Abläufe dort beschreiben zu können sind Sprachen wie SCL und Graph deutlich besser geeignet als AWL.


----------



## vladi (13 März 2008)

*Genau*



zotos schrieb:


> Wer heute neu in den SPS Bereich einsteigt ohne einen blasen Schimmer von *Hochsprachen zu haben, hat sich sicher im Beruf vergriffen*.
> 
> PS: Als SPSler sollte man unter Maschinennaher Programmierung nicht an die Poplige SPS denken sondern an die *Abläufe in der Maschine bzw. Anlage*. Um Die Abläufe dort beschreiben zu können sind Sprachen wie SCL und Graph deutlich besser geeignet als AWL.


 
*ACK* 

Leider sind viele Firmenchefs oder sonstige "Verantwortliche" der Meinung, SPS ist irgendwie wie zwei Drähte verbinden, das macht schon jeder. Siehe viele viele Anfragen hier im Forum..(.."mein Chef hat mir eine SPS gegeben, bin absoluter Anfänger, und wie programmiere ich jetzt eine Raumfähre damit? Was ist übrigens MPI?")  
Ist doch oft so..

Vladi


----------



## vierlagig (13 März 2008)

persönlich finde ich diese diskussion mittlerweile zu SCL-pro-lastig ... aber macht ruhig weiter, das forum ist geduldig ...

...ja, man sollte von allen möglichkeiten mal was gehört haben, das finde ich wichtig und man sollte um die vor- und nachteile wissen, aber jetzt die komplette automatisierungsschiene plötzlich nur noch mit hochsprachenähnlichen text zu fahren, find ich übertrieben und auch nicht wirklich praktikabel...

sollten die bus-geschichte, die achim angeschnitten hat nicht aus den augen verlieren und auch sonstige strategien mal erwähnen, wenn ich jetz in- und output-scan anschneide kommen gleich wieder proteste, aber man sollte mal gesagt haben das die pointerei ja ganz schön ist, aber in vielen anwendungen einfach unangebracht, darüber hinaus die ganzen sachen die in *"saubere" programme* zur sprache gekommen sind und werden gehören zu den dingen, mit denen man sich in der so called praxis rumschlagen muß ...

... darüber hinaus fänd ich es mal sehr angenehm, wenn sich der fragensteller mal wieder zu wort melden würde, so kann er die diskussion in die von ihm benötigte richtung lenken ...


----------



## Hoyt (13 März 2008)

Hallo



zotos schrieb:


> .Wer heute neu in den SPS Bereich einsteigt ohne einen blasen Schimmer von Hochsprachen zu haben, hat sich sicher im Beruf vergriffen..




Es gibt auch Hochsprachenprogrammierer die in den SPS-Bereich einsteigen und keinen blassen Schimmer von SPS-Programmierung haben.

Die SPS-Sprache sollte nicht nur nach den Vorlieben (und Kenntnissen) der Programmierer ausgesucht werden, sondern der Anwendung entsprechen!


Hoyt


----------



## Lipperlandstern (13 März 2008)

Werner54 schrieb:


> Im Übrigen: MOVE funktioniert immer, allerdings nur mit undefinierten Variablen (Merker). Sind die verwendeten Variablen in der Symboltabelle oder in der Bausteinschnittstelle eingetragen, greift die Typüberprüfung. [Scherz EIN] Also möglichst nichts dokumentieren, dann funzts!


 

Die Typüberprüfung kann man abschalten........


----------



## kermit (13 März 2008)

Hoyt schrieb:


> ...Es gibt auch Hochsprachenprogrammierer die in den SPS-Bereich einsteigen und keinen blassen Schimmer von SPS-Programmierung haben. ...


 
und genau die übersehen manchmal, dass da mehrerer Prozesse gleichzeitig ablaufen - und von wegen EVA-Prinzip: war da was bei den Theoretikern, die da sagen, son Algorithmus müsse ein Ende haben?


----------



## TobiasA (13 März 2008)

Hoyt schrieb:


> Hallo
> Es gibt auch Hochsprachenprogrammierer die in den SPS-Bereich einsteigen und keinen blassen Schimmer von SPS-Programmierung haben.
> Hoyt


 
*ACK* 

Von denen hatte ich auch schon Programme da. Vor allen Dingen Service und Instandhaltung fluchen darüber. Das ist teilweise der letzte Wi.., weil die Leute überhaupt keinen blassen Schimmer von der Materie haben, aber ich kann ja C, also kann ich auch so eine popelige SPS programmieren.
Da werden zum Beispiel Meldungen zur NC im Programm fröhlich weiter benutzt- du änderst eine Meldung, und irgendwas anderes funktioniert nicht mehr, weil die hintenrum in 5 anderen FC's wieder gelesen wird. Dann kannst du die ganze K... wieder mit "Umverdrahten" auf irgendwelche Merker schubsen und reißt damit irrsinnige Baustellen auf.
Sprünge sind auch ganz beliebt. Simpelste Schrittketten werden mit AWL-Sprüngen realisiert, die für einen normalen Instandhalter nicht mehr nachvollziehbar sind (nämlich kreuz und quer durch mitunter drei FC's). Das heißt, dass es im Service mitunter zu Engpässen kommt, weil nun das Ding beim Kunden streikt und dann wieder jemand extra hinfahren muss. Und das alles nur, weil irgendein Spaßkeks frisch von der Schule an das PG gelassen wird und sich dort austoben darf. Wir machen zwar auch Telefonseelsorge für Kollegen, aber nicht jeder hat eben so tiefe SPS- Kenntnisse. Es muss schließlich auch Leute geben, die drehen und fräsen können, Strippen ziehen und Lager tauschen und Strom- sowie Hydraulikschaltpläne lesen können. Das sind zum größten Teil Allrounder- und die kriegen dann irgendwas von irgendeinem Star-Visual-Basic-Programmierer auf die Theke.
Merker kennen die auch nicht- dafür gibt's doch Variablen, die man dann hin- und her und wieder zurückschubsen kann. Im Service kann das echt besch... sein, wenn man den Kunden oder Kollegen vor Ort mal bitten will, doch in der Diagnose an der CNC mal nach dem Zustand eines Merkers zu fragen- wie bitte kriege ich da lokale Variablen eines FC's angezeigt? Merker kann ich nachschauen- und so komme ich weiter.

Aber zurück zum Thema.
gemessen an Netzwerken in den jeweiligen Sprachen, haben wir zu ungefähr...
80% AWL
20% FUP/ KOP
kein SCL
kein Graph
(oder beides zu nur 2%)
An anderen Anlagen haben wir zu ungefähr 80% FUP/KOP, 20% AWL.

Bussysteme setzen wir nur begrenzt ein, wenn, dann Profibus DP.

Ich sage auch nichts gegen Hochsprachen in der SPS- aber es sollte halt schon praxisnah und den Aufgaben angepasst sein sowie übersichtlich und gut dokumentiert bleiben. 

Gruß, Tobias


----------



## zotos (13 März 2008)

TobiasA schrieb:


> ...nach dem Zustand eines Merkers zu fragen- wie bitte kriege ich da lokale Variablen eines FC's angezeigt? Merker kann ich nachschauen- und so komme ich weiter.
> ...


Ja nee is klar Du baust überall Schmiermerker ein. Du bist ja ein ganz cleverer. Böse lokale Variablen ganz böse.



TobiasA schrieb:


> Bussysteme setzen wir nur begrenzt ein, wenn, dann Profibus DP.
> ...


Bussysteme sind auch Böse? 
Ihr setzt also nicht nur begrenzt Bussysteme, nein auch der Horizont ist stark eingeschränkt ;o)

Zum Glück leben wir in einem Sozialen Land und wir orientieren uns immer an den geistig schwachen.


----------



## sps-concept (13 März 2008)

*trollig*

wow trollig zotos! Manchmal kann einen ja auch das Personal beim Kunde helfen. Die gehn an die Visu, rufen das Bild "Variablen beobachten/steuern" auf und du kannst sie was fragen wie das Signal oder das so steht... Geht nicht bei Lokalbits!

André


----------



## zotos (13 März 2008)

sps-concept schrieb:


> wow trollig zotos! Manchmal kann einen ja auch das Personal beim Kunde helfen. Die gehn an die Visu, rufen das Bild "Variablen beobachten/steuern" auf und du kannst sie was fragen wie das Signal oder das so steht... Geht nicht bei Lokalbits!
> 
> André



Werter Herr sps-concept,
ich kann ja auch nichts dafür das Sie Ihr Handwerk nicht beherrschen.


----------



## sps-concept (13 März 2008)

*...*

was soll der Beitrag denn? Stand in meinem Beitrag was falsches? Ausserdem ist nicht jeder Merker ein Schmiermerker. Aber was interessiert denn einen zotos was wahr ist oder nicht.... er will eh nur trollen


----------



## zotos (13 März 2008)

sps-concept schrieb:


> was soll der Beitrag denn? Stand in meinem Beitrag was falsches? Ausserdem ist nicht jeder Merker ein Schmiermerker. Aber was interessiert denn einen zotos was wahr ist oder nicht.... er will eh nur trollen



Werter Herr sps-concept,
warum werden Sie den gleich so pampig? Ich erwarte eigentlich von einem Programmierer, dass er weis wann er zu einer lokalen temporären  Variable oder einer lokalen statischen Variable greifen kann und wann eine globale statische Variable zu der die Merker nun mal gehören greifen muss.
Wenn Sie Programme schreiben die so Buggy sind das der Kunde ihnen ständig die Zustände von Merkern per Telefon durchgeben muss, ist das nicht mein Problem.


----------



## zotos (13 März 2008)

sps-concept schrieb:


> warum? weils dich tiefflieger eh nicht interessiert ob etwas wahr ist oder nicht...



Sehr geehrter Herr sps-concept,
bitte arbeiten Sie noch etwas an Ihren Umgangsformen.

Kann ich Sie mit der Huldigung eines :TOOL: aus Ihrem Haus wieder besänftigen?


----------



## sps-concept (13 März 2008)

*scheinheilig*

diese scheinheilige Schreibweise neuerdings erinnert mich an (wahrscheinlich) deine Beiträge in meinem Forum als Klugfäkalist. Aber als zotos gibts dich ja auch noch als Benutzer - allerdings mit 0 Beiträgen. Es scheiterte wohl an der 5%-Hürde beim IQ

zurück zum Thema:

mein Beitrag sollte zeigen dass ich die Einwände von TobiasA in Punkto Lokalvariablen verstehe. Es heisst nicht dass ich das so mache. Aber mal zum Nachdenken! Nicht alle Kunden haben eine Instandhaltung, nicht alle SPSen haben Fernwartung, nicht alle Kunden sind räumlich um die Ecke. Hilfe - und sei es nur ein Signalzustand helfen teilweise bei der Diagnose. Man kann dann eine Lösung ausarbeiten und damit zum Kunde. Sollte doch Kosten sparen, oder? Genauso wie *innovative SPS-Tools* ;-)

zotos ich weiss nicht wie es in deiner kleinen Trollwelt aussieht.. Aber kein etwas umfangreichere Programm ist ohne Bugs. Nichtmal bei Serienmaschinen.

André


----------



## zotos (13 März 2008)

sps-concept schrieb:


> diese scheinheilige Schreibweise neuerdings erinnert mich an (wahrscheinlich) deine Beiträge in meinem Forum als Klugfäkalist. Aber als zotos gibts dich ja auch noch als Benutzer - allerdings mit 0 Beiträgen. Es scheiterte wohl an der 5%-Hürde beim IQ
> ...



Herr sps-concept,
Sie lassen auch keine noch so peinliche Gelegenheit aus, um Werbung für Ihr Support Forum zu machen.

Ich würde Ihnen eine Schulung zum Thema Marketing ans Herzlegen.


----------



## Question_mark (13 März 2008)

*No Bug gibbet nich ..*

Hallo,



			
				sps-concept schrieb:
			
		

> Aber kein etwas umfangreichere Programm ist ohne Bugs



Gottlob sind alle Tools ohne Bugs ..

Gruß

Question_mark


----------



## vierlagig (13 März 2008)

kinners, contenance, wenigstens ein wenig, SV is wo anners!


----------



## Question_mark (13 März 2008)

*Brauch ich nicht..*

Hallo,



			
				vierlagig schrieb:
			
		

> contenance,



Ist das auch so ein Scheiss-Tool ??
Kannste behalten ..

Gruß

Question_mark


----------



## funkdoc (14 März 2008)

zur effektivität der ausbildung sollte man im FUP prgrammieren.
viele leute verstehen das sogenannte Logik-Gatter bei FUP viel schneller als KOP (ausgenommen elektriker, da braucht man doch etwas planlesekenntisse) oder gar AWL.

in der simatik ist FUP in allen ansichten (KOP,AWL) darstellbar. hingegen ist die AWL das leider nicht, da man hier mit dieser sehr direkten schreibweise viel abkürzt. man müsste zb. für die darstellung in FUP dann beim AWL programmieren viele "no operation"-befehle (=NOP) an nichtbelegte ein- und ausgangsvariablen eines bausteins oder oder zb. eines timers schreiben.
man sollte beim programmieren stets an leute denken, die nach einem kommen und die da dann ein service oder störungsbehebung machen sollen.  

daher find ich FUP als einstieg schonmal eine gute idee.

zudem kann man zunehmend auch an anderen steuerungen wie zb. mitsubishi seit einiger zeit auch in FUP programmieren... was ein umsteigen wieder viel einfacher macht, da ja die grundbefelhe bei jeder steuereung sehr ähnlich (meistens auch gleich) sind.

grüsse


----------



## Roos (14 März 2008)

Also für die Instandhalter bin ich auch der Meinung, dass für die schnelle fehlersuche kop und fup ideal sind.
ich muss aber sagen dass ich trotz dem lieber in awl programme schreibe weils einfach schneller geht...
mfg roos


----------



## dodo (14 März 2008)

vierlagig schrieb:


> ```
> ____________
> |    MOVE    |
> |            |
> ...




Stimmt! War'n schlechtes Beispiel!  
Ich weiss aber, dass es irgendwas mit zuweisen oder Vergleichen gab, was nicht ging.
Und spätestens bei komplexen Berechnungen geht's nicht ohne AWL.




Werner54 schrieb:


> Und wer eine komplexe Industrieanlage mit mehreren Teilanlagen in AWL runterklopft, gehört nicht vors PG.



Den Spruch versteh ich nicht!? 
Wie programmierst Du denn komplexe Industrieanlagen? in FUP? 
Frage ist natürlich, was man unter komplexer Industrieanlage versteht?
Ich hab hier zum Bsp. ne Anlage mit ner 416er CPU, 113 DP-Busteilnehmern an drei Mastersystemen, 52K belegten E/A und etwas über 500 Bausteinen drin. 
Bewegen tun sich allerdings nur 2 Zylinder! 

Ich find's blöd, dass bei Postings, bei denen Meinungen geäussert werden, dann gerne mal der Ton etwas "persönlich" wird. Letzten Endes kann ja jeder programmieren, wie er will und es kommt (siehe oben) auf den Anwendungsfall an, was am besten passt. 



zotos schrieb:


> Wer heute neu in den SPS Bereich einsteigt ohne einen blasen Schimmer von Hochsprachen zu haben, hat sich sicher im Beruf vergriffen.


Wieso? Ich kenn genug Leute, die jeden Tag das Gegenteil beweisen.
Wie oben geschrieben: Kommt drauf an, was man programmiert! 
EIn Kollege von mir programmiert jeden Tag an echt komplexen NC Bearbeitungszentren rum und kennt SINUMERIK hoch und runter. Der kann noch nicht mal ne IF Abfrage programmieren. Brauch er aber auch nicht! 



Hoyt schrieb:


> Es gibt auch Hochsprachenprogrammierer die in den SPS-Bereich einsteigen und keinen blassen Schimmer von SPS-Programmierung haben.



Setz Dich mal als SPS Programmierer vor'n PC und programmier schnell ne Datenbankanwendung  in einer objektorientierten Sprach runter! 
Da wirst Du auch Probleme haben.

Das Kernproblem ist oft, dass immer noch viele Leute denken, programmieren ist programmieren! 
SPS, Hochsprachen, Webprogramierung..., alles verschiedene Welten.
Als würde man einen Hufschmied in eine Goldschmiedewerkstatt stecken und würde sagen "Schmied ist Schmied"! *ROFL*

Wobei ich der Meinung bin,ass viele Hochsprachen-Proggern(ohne denen zu nahe treten zu wollen, bin schliesslich selber gelegentlich einer), die Meinung haben, SPS wäre einfacher zu programmieren und wer Hochsprache kann, kann auch SPS :sc6: :sm11:
Gerade PC Programmierer gehen da oft auch sehr lässig ran. Die kennen das halt nicht anders: Wenn das Programm nicht funzt, stürtzt halt mal der Rechner ab oder so. Dann starten wir neu und fertig.
Aber bei ner SPS...!?
Das ist dann so wie der Unterschied, auf einer gemalten Linie zu laufen oder auf'm Hochseil! :sm14:

Über das Thema "Roboter", die ja irgendwo in der Mitte stehen, lass ich mich jetzt aber nicht mehr aus!


----------



## zotos (14 März 2008)

zotos schrieb:


> ...
> Wer heute neu in den SPS Bereich einsteigt ohne einen blasen Schimmer von Hochsprachen zu haben, hat sich sicher im Beruf vergriffen.
> ...





dodo schrieb:


> ...
> Wieso? Ich kenn genug Leute, die jeden Tag das Gegenteil beweisen.
> Wie oben geschrieben: Kommt drauf an, was man programmiert!
> EIn Kollege von mir programmiert jeden Tag an echt komplexen NC Bearbeitungszentren rum und kennt SINUMERIK hoch und runter. Der kann noch nicht mal ne IF Abfrage programmieren. Brauch er aber auch nicht!
> ...



Ist doch ganz klar wer neu in den SPS Bereich Einsteigt hat wahrscheinlich vor da noch einige viel Jahre (Jahrzehnte) in diesem Bereich zu arbeiten. Die Tendenz geht doch ganz klar weg von IL(AWL) hin zu ST(SCL). Also nur weil heute jemand in dem Bereich heute der Held ist, bedeutet nicht das er sich nicht weiter bilden muss.
Die Anforderungen ändern sich doch auch. Es fallen bei der Produktion immer mehr Daten an, Anbindungen an Leitrechner und Datenbanken. Schon bei einem popligen Datamatrix Code muss man sich Strings zu recht kopieren und wieder auseinander pflücken. 

Auch Siemens hat den Trend erkannt:


			
				http://www.automation.siemens.com/mc/mc-sol/de/e8106425-bdca-11d5-86dc-080006278927/index.aspx schrieb:
			
		

> Bei der Programmierung von SIMOTION haben Sie die Wahl: Ob grafisch mit Motion Control Chart (MCC), wie von der PLC gewohnt mit Kontaktplan (KOP) / Funktionsplan (FUP) oder mit der Hochsprache Structured Text (ST), das Engineeringsystem SCOUT versteht einfach alles.



Aber ein schritt weiter weg von der SPS im Bereich der HMI trifft man immer öfter auf Skriptsprachen. Auch da ist es sicher nicht kein Nachteil sich mal mit Hochsprachen auseinander gesetzt zu haben.


----------



## Perfektionist (14 März 2008)

von Wikipedia http://de.wikipedia.org/wiki/Programm



> Ein Computerprogramm ist eine statische Folge von Anweisungen.


 
in diesem Sinn ist für mich KOP/FUP kein Programm sondern die grafische Darstellung eines Programmes. Wer also programmieren lernen will, muss sich m.E. auf das Verfassen von Anweisungslisten einlassen ...


----------



## derwestermann (14 März 2008)

*Wissenswertes*

Wie der Name schon sagt:

http://www.ipsta.de/seiten_html/wissenswertes_frei.html


----------



## achim532000 (14 März 2008)

*Wie progammiert ??*

Hallo,

und vielen Dank erst mal für die vielen Antworten, Meinungen und Tips.
Manche haben sich zwar etwas unschön ausgelassen aber was solls. 
Klar zu erkennen komplizierte anspruchsvolle Programme in AWL, SCL und GRAPH. Mit den Azubi werde ich weiter vorwiegend in FUP programmieren.
Bei Ablaufsteuerungen habe ich mich selbst für Graph entschieden, eröffnet mehr Möglichkeiten, lässt sich übersichtlich und schnell programmieren. PROFIBUS scheint stark verbreitet zu sein. Waren gestern bei SIEMENS zu "5 bis 7", die erzählten das Gleiche. Der Trend soll jedoch zu PROFINET gehen. 
Also, Allen die mitgemacht haben nochmals vielen Dank, Ihr habt mir geholfen.

Gruss aus dem Harz 

von Achim


----------



## dodo (14 März 2008)

Perfektionist schrieb:


> von Wikipedia http://de.wikipedia.org/wiki/Programm
> 
> in diesem Sinn ist für mich KOP/FUP kein Programm sondern die grafische Darstellung eines Programmes. Wer also programmieren lernen will, muss sich m.E. auf das Verfassen von Anweisungslisten einlassen ...




Da ist insofern was dran, als das das Programm letzten Endes doch immer als Text gespeichert wird!


----------



## vierlagig (14 März 2008)

achim532000 schrieb:


> Waren gestern bei SIEMENS zu "5 bis 7", die erzählten das Gleiche. Der Trend soll jedoch zu PROFINET gehen.



wenn ich siemens wär würd ich das auch verbreiten ... aber was an dieser marketing-strategischen aussage nun wirklich dran ist, sieht man an den wenigen posts, fragen und anregungen hier ... oder ist PROFINET so unkompliziert, dass es selbst der heulende instandhalter versteht?


----------



## funkdoc (14 März 2008)

weder noch.

profinet ist ein "standart" der erst in nächster zeit die kommunikation von steuerungen, geräten und servern bestimmen wird.

dass hier im forum darüber kaum was steht, liegt aber nicht an der komplexität dieser busverbindung (NIC) sondern vielmehr an der wenigen verbreitung (bisher) dieses standarts und den hohen preisen von PROFINET komponenten.

die vorteile liegen ja klar auf der hand: volle bandbreite mit bis zu 100Mbit/s, keine DP adapter mehr, einfache vernetzung mit CAT5 oder CAT7 in sternstruktur oder wie auch immer und herkömmliche switches wie sie in jeder firma vorkommen (ausgenommen PROFINET IO IRT<1ms latenz), unbegrenzte teilnehmerschaft*, gigabit netzwerk backboned möglich, ein kabel von managementebene über  Prozessleitebene bis zur Feldebene,........

übrigens wird PROFINET nicht nur von siemens gepusht sondern vielmehr von der PROFIBUS nutzerorganisation. heisst Profinet wird sich in zukunft auch an anderen steuerungen finden.

ps. zwecks geschwindigkeit: der sprung zum gigabitnetz  scheint auch nicht mehr fern.

grüsse


----------



## arcis (15 März 2008)

*+*

Hochsprachenprogrammierung und SPS-Programmierung sind zwei grundlegend verschiedene Welten.

Leider wird die SPS-Programmierung von vielen Hochsprachenprogrammierern durchgehend als absolutes Pipifax betrachtet. Die paar Ein- und Ausgänge kann doch jeder Ansteuern, was soll daran so schwierig sein? Und so kann es dann schon mal passieren, dass auch ein C-Programmierer auf eine SPS losgelassen wird, mit den entsprechenden oben bereits erwähnten Ergebnissen. 

Ich halte SPS-Progammierung und Hochsprachenprogrammierung vom intellektuellen Anspruch her für absolut gleichwertig. Es geht nicht darum, ein irgendwie lauffähiges SPS-Programm zu fabrizieren, das die paar Ein- und Ausgänge ansteuert, sondern eine robuste, wartbare, verständliche SPS-Software zu machen, mit der gearbeitet werden kann. Das sind dann schon Unterschiede, für die meines Erachtens viele Jahre Erfahrung und der Einsatz von etwas Gehirnschmalz notwendig sind.

Hauptaufgabe wird es aber bleiben, gegen die leider allgemein verbreitete Geringschätzung von SPS-Programmierung fortwährend, unermüdlich und immerzu anzupredigen.


----------



## TobiasA (15 März 2008)

zotos schrieb:


> Ja nee is klar Du baust überall Schmiermerker ein. Du bist ja ein ganz cleverer. Böse lokale Variablen ganz böse.
> 
> 
> Bussysteme sind auch Böse?
> Ihr setzt also nicht nur begrenzt Bussysteme, nein auch der Horizont ist stark eingeschränkt ;o)


 
An der CNC kann ich Merker beobachten, lokale Variablen dagegen nicht. Also setze ich für wichtige Verknüpfungen und für solche Dinge, die ich in anderen Bausteinen benötige, Merker ein. Für andere Dinge nehme ich auch lokale Variablen- nämlich für Dinge, die nur im entsprechenden FC benötigt werden und für die Fehlerdiagnose verzichtbar sind. Hat für mich den Vorteil, dass ich den Kollegen, der vor Ort ist, bitten kann, doch mal nach dem Zustand eines Merkers zu schauen.
Aber ich sehe keinen Sinn darin, für alles nur lokale Variablen zu benutzen, die dann über die Schnittstelle des FC's in einen Merker oder einen DB zu schreiben und dann dieses Bit im Datenbaustein oder den Merker dann hintenrum weiter zu benutzen. Warum zum Henker schreibt man das dann nicht gleich in einen Merker, sondern fummelt sich da einen ab?
Für solche Sachen wie "Futter gespannt", die für die Fehlersuche wichtig sind und/ oder in anderen Bausteinen benötigt werden, benutze ich Merker.
Die Leute, von denen ich spreche, benutzen Merker überhaupt nicht. Stattdessen wird entweder alles in DB's geschrieben oder mit Variablen zurechtgefummelt. Das wäre mit Merkern deutlich eleganter und einfacher gelöst.
Ich hab' irgendwo noch ein Beispiel davon rumliegen.

Dass wir keine Bussysteme einsetzen, liegt nicht daran, dass sie "böse" sind, sondern dass sie in von der Baugröße her kleinen Anlagen (Baugröße 5 auf 5 Meter) und ca. 20-30 Ein- und ca. 20 Ausgängen nicht wirklich relevant sind.
Bei der 840D sl laufen die Sinamics- Antriebe auf Profibus.


----------



## vladi (15 März 2008)

*Kompliziert..*

Hi Kollege,


TobiasA schrieb:


> An der CNC kann ich Merker beobachten,
> ........
> ....Dass wir keine Bussysteme einsetzen, liegt nicht daran, dass sie "böse" sind, sondern dass sie in von der Baugröße her kleinen Anlagen (Baugröße 5 auf 5 Meter) und ca. *20-30 Ein- und ca. 20* Ausgängen nicht wirklich relevant sind.


 
solche komplizierte und grosse   mit SPS angesteuerte Maschinen macht man normalerweise so, dass bei "Werkzeug nicht gespannt" oder sonstige Fehlerzustände irgendwo eine Fehlermeldung kommt  ..bzw. durch z.B. Anzeige von Statuszustände am OP der Bediener selber sieht, was los ist; das ist *gute Programmierung*; und nicht bei jedem Fehler ran mit dem PG und Merker beobachten...
Hatte schon mal ein Auftrag, eine bestehende Anlage(S7, mit DP, OP usw.) Meldungsmässig zu erweitern, da war kaum sowas programmiert: Anlage ist stehengeblieben, keine Meldung, nix  .  Und das ist oft so, leider.

Vladi


----------



## zotos (15 März 2008)

vladi schrieb:


> ...
> solche komplizierte und grosse   mit SPS angesteuerte Maschinen macht man normalerweise so, dass bei "Werkzeug nicht gespannt" oder sonstige Fehlerzustände irgendwo eine Fehlermeldung kommt  ..bzw. durch z.B. Anzeige von Statuszustände am OP der Bediener selber sieht, was los ist; das ist *gute Programmierung*; und nicht bei jedem Fehler ran mit dem PG und Merker beobachten...
> ...


*ACK*



arcis schrieb:


> Hochsprachenprogrammierung und SPS-Programmierung sind zwei grundlegend verschiedene Welten.
> ...


@arcis: Es mag ja für Dich so schön einfach sein, die Programmierer Welt in "SPS-Programmierer" und  Hochsprachen Programmierung zu unterteilen. Die Realität sieht da aber ganz anders aus.
Ein SPS-Programmierer ist der der SPSen Programmiert. Für einige Aufgaben ist eine Hochsprache eben deutlich besser geeignet und da sollte man es auch einsetzten.

Dazu ist jeder Programmierer ein Mensch und somit ein Individuum. Ich würde mich nicht wagen alle auf gerade mal zwei Schubladen aufzuteilen und das noch zu bewerten.


----------



## Ralle (15 März 2008)

vladi schrieb:


> Hi Kollege,
> 
> 
> solche komplizierte und grosse   mit SPS angesteuerte Maschinen macht man normalerweise so, dass bei "Werkzeug nicht gespannt" oder sonstige Fehlerzustände irgendwo eine Fehlermeldung kommt  ..bzw. durch z.B. Anzeige von Statuszustände am OP der Bediener selber sieht, was los ist; das ist *gute Programmierung*; und nicht bei jedem Fehler ran mit dem PG und Merker beobachten...
> ...



Vladi, ich finde es von dir und zotos absolut sinnlos hier Zitiate aus dem Zusammenhang zu reißen bzw. Aussagen bewußt zu verdrehen bzw. falsch zu deuten. Ich glaube kaum, das TobiasA das gemeint hat und ich glaub auch nicht, daß irgend jemand so einen Zustand gut heißen könnte, nicht mal der Programmierer, der das vermurkst hätte.


----------



## zotos (15 März 2008)

Ralle schrieb:


> Vladi, ich finde es von dir und zotos absolut sinnlos hier Zitiate aus dem Zusammenhang zu reißen bzw. Aussagen bewußt zu verdrehen bzw. falsch zu deuten. Ich glaube kaum, das TobiasA das gemeint hat und ich glaub auch nicht, daß irgend jemand so einen Zustand gut heißen könnte, nicht mal der Programmierer, der das vermurkst hätte.



Doch es gibt mindestens einen:



sps-concept schrieb:


> ...
> zurück zum Thema:
> 
> mein Beitrag sollte zeigen dass ich die Einwände von TobiasA in Punkto Lokalvariablen verstehe. Es heisst nicht dass ich das so mache. Aber mal zum Nachdenken! Nicht alle Kunden haben eine Instandhaltung, nicht alle SPSen haben Fernwartung, nicht alle Kunden sind räumlich um die Ecke. Hilfe - und sei es nur ein Signalzustand helfen teilweise bei der Diagnose. Man kann dann eine Lösung ausarbeiten und damit zum Kunde. Sollte doch Kosten sparen, oder? Genauso wie *innovative SPS-Tools* ;-)
> ...


----------



## Ralle (15 März 2008)

zotos schrieb:


> Doch es gibt mindestens einen:



Zotos, es ging ausschließlich um das Zitat, das ich erwähne, nicht um irgendwelche Dinge die irgendjemand, irgendwann abgelassen hat!


----------



## vladi (15 März 2008)

*Ok, Ok*

Hi,


Ralle schrieb:


> Vladi, ich finde es von dir und zotos absolut sinnlos hier Zitiate aus dem Zusammenhang zu reißen bzw. Aussagen bewußt zu verdrehen bzw. falsch zu deuten. Ich glaube kaum, das TobiasA das gemeint hat und ich glaub auch nicht, daß irgend jemand so einen Zustand gut heißen könnte, nicht mal der Programmierer, der das vermurkst hätte.


 
ist ja gut, ich dachte, solche Disskusionen haben zumindest eine gute Seite: vielleicht denkt man mehr an gute hier vorgeschlagene Programmiermethoden bei der nächsten Anlage. Ich mache das. Vom Forum habe mich für einige gute Sachen inspirieren lassen, auch wenn die in KOP waren. Aber es gibt auch Holzköpfe, die wissen alles besser, und ihre Anlagen..na ja.. da muss die Instandhaltung täglich rangehen.  

Ich entschuldige mich für Alles, was evtl. Jemand beleidigt hat!
Schönes Wochenende: 

Vladi  

P.S. Mache zur Zeit je LabView, so interessiert mich euer SPS Sch..überhaupt nicht!  
(falls länger nichts von mir gehört, Account löschen, dann habe ich mich wahrscheinlich umgebracht, oder Klappse..)


----------



## Ralle (15 März 2008)

vladi schrieb:


> Ich entschuldige mich für Alles, was evtl. Jemand beleidigt hat!



Ne, das muß nu nicht sein  , ich seh schon, du bist heut auf der Schiene, die 180 verdreht ist  !



vladi schrieb:


> P.S. Mache zur Zeit je LabView, so interessiert mich euer SPS Sch..überhaupt nicht!
> (falls länger nichts von mir gehört, Account löschen, dann habe ich mich wahrscheinlich umgebracht, oder Klappse..)



Sag wenigstens Bescheid, welche Klappse...


----------



## TobiasA (15 März 2008)

vladi schrieb:


> Hi Kollege,
> 
> 
> solche komplizierte und grosse  mit SPS angesteuerte Maschinen macht man normalerweise so, dass bei "Werkzeug nicht gespannt" oder sonstige Fehlerzustände irgendwo eine Fehlermeldung kommt  ..bzw. durch z.B. Anzeige von Statuszustände am OP der Bediener selber sieht, was los ist; das ist *gute Programmierung*; und nicht bei jedem Fehler ran mit dem PG und Merker beobachten...
> ...


 

Das ist richtig. Trotzdem gibt es nach wie vor Merker, die nur eine untergeordnete Rolle spielen und erst in Verknüpfung mit weiteren Zuständen wirklich zu einer Meldung führen. Es gibt zum Beispiel auch eine Innen- und Außenspannung- und den Merker für die Innenspannung zeige ich nicht direkt an, weil ich sonst 25 Meldungen gleichzeitig habe und alles Wichtige dann untergeht. Also werden solche Merker nur dann zu einer Meldung verarbeitet, wenn dieser Signalzustand wirklich für den Bediener relevant sind, also z.B. die Funktion Innenspannung auch ausgewählt ist.
Probleme habe ich meist nur dann, wenn sich jemand verprogrammiert hat- und das kann der Bediener am HMI schlecht nachvollziehen. Die meisten anderen Dinge kann man mit Diagnose und Meldungen erschlagen.
Für uns sind in erster Linie Erweiterungen relevant. Und leider programmiert nicht jeder in einem eingängigen, überschaubaren und gut dokumentiertem Stil. In einigen Anlagen wird gänzlich auf Kommentare verzichtet...
Und das sind dann meist Leute, die von den Hochsprachen her kommen (oder von Fanuc...).


----------



## Ben (18 März 2008)

*Wie programmiert der Praktiker?*

Hallo Achim,

die am meisten genutzte  Darstellung ist bei uns im Betrieb AWL.
Für den Anfang würde ich Dir aber raten in KOP oder FUP zu programmieren.
Dann kannst Du auch alle Bausteine die Du programmierst in KOP/FUP oder Anweisungsliste darstellen.
Es ist auch für Deine Lehrgangsteilnehmer sich leichter in der SPS-Welt zu recht zu finden.Vor allem sehen sie Bei KOP, bzw. FUP welche Bedingungen erfüllt sind am besten.Wird ein Programm in FUP oder KOP geschrieben, und man stellt die Ansicht nach AWL um, dann sind in den Bausteinen sogenannte Platzhalter die in den Programmzeilen stehen, die da wären (NOP 0, oder BLD-Anweisungen. Also nicht erschrecken, das macht der Editor von selbst.
Bei uns setzen wir folgende Techniken ein (ASI,Profibus,Profinet). Wobei Profinet aber noch in den Kinderschuhen steckt, das nutzen wir hauptsächlich bei den S7 mit Saftetyteil. Das heisst die herkömmlichen Not-Auskombinationen (mit Schütz, oder Pilz-Relais) werden durch sogenannte sichere Eingangs oder Ausgangsmodule ersetzt.
Einen Rat für den Anfang will ich Dir auch noch geben, lass das programmieren in SCL außen vor, dies geht in den Bereich der Hochsprachen und verwirrt nur am Anfang.
Wenn Du noch mehr wissen willst, dann schreibe doch einfach wieder.

Gruß

Ben


----------



## Tom Doll (19 März 2008)

Hallo Leute,
Ich habe die Ganze Diskussion mitverfolgt und aus den Antworten wird mir klar, was der Einzelne programmiert. Ich habe von der Mini-Anlage bis zur großen Verpackungsmaschine schon viel programmiert, hauptsächlich Siemens aber auch Rockwell. Ich bin auch in der PC-Programmierung aktiv und kenne Delphi, VB und C#.
Man sollte doch mit der Sprache programmieren, welche für den jeweiligen Einsatz am geeignetsten ist.
- Kleinere bis mittlere Programme ohne große Wiederverwertbarkeit direkt mit Merkern und in KOP oder FUP möglichst geradeaus programmieren, ohne groß parametrierbare Bausteine und Lokaldaten einzusetzen. Tatsächlich kann man doch solche Programme sehr gut nachvollziehen und erweitern. Der Anteil an Berechnungen und Datenverarbeitung sollte nicht zu hoch sein.
- Große Anlagen und Maschinen, streng gekapselt,modular und symbolisch programmieren. Gundsätzlich versuchen keine Merker zu verwenden. Man kommt zu schnell an die Grenzen und die Wiederverwertbarkeit ist zu gerring, wenn man Merker einsetzt. Bei Datenverarbeitung und Berechnungen bietet sich meiner Meinung nach SCL an.

Ich kann gut AWL programmieren, aber vermeide es wo es nur geht. AWL Programme enden nur zu oft in Spaghetti Code. Man kann sich nicht auf das Wesentliche konzentrieren. Der Code besteht zu 95% aus Lade-/Transferbefehlen und Typwandlungen. Im Grunde genommen ist AWL Assemblerprogrammierung von der übelsten Sorte. Hat man sich längere Zeit mit einem Code nicht befasst, braucht man seine Zeit, um sich wieder reinzulesen.
Für binäre Verküpfungen ist KOP oder FUP doch viel übersichtlicher als ein ellenlanger Code mit vielen Klammerungen.

Das Verständis eines Programmes hängt doch nicht von der Programmiersprache ab, sondern vom Verständnis des Ablaufs. 

Einer der wichtigsten Grundsätze bei der Programmierung sollte doch sein: Kein Maschinenstillstand ohne Meldung! Wenn man das berücksichtigt, kann das Instandhaltungspersonal in vielen Fällen auf den Einsatz eines PG verzichten.

Wir setzen in größeren Umfang Achssteuerungen mit Hochsprachenprogrammierung ein. Ich habe die Erfahrung gemacht, daß selbst für den Elektriker viele Vorgänge in der Hochsprache leichter nachvollziehbar sind. Die Grenzen zwischen klassischer SPS- und Hochsprachenprogrammierung sind im Fallen begriffen. 

Für den, der gerade beginnt SPS programmieren zu lernen ist meiner Meinung nach KOP/FUP der beste Einstieg. Auf AWL kann man getrost verzichten. Später sollte man dann SCL oder eine andere Hochsprache dazulernen.

Busysteme:
Bei uns sind hauptsächlich Profibus DP (S7) und Devicenet(Rockwell) im Einsatz. In etwas weiterer Zukunft wird wohl ein Ethernet basierender Feldbus (PROFINET)eingesetzt werden.


Gruß

Tom


----------



## Perfektionist (19 März 2008)

Hallo Tom,

95% Zustimmung, aber



Tom Doll schrieb:


> ...
> Ich kann gut AWL programmieren, aber vermeide es wo es nur geht. AWL Programme enden nur zu oft in Spaghetti Code. Man kann sich nicht auf das Wesentliche konzentrieren. Der Code besteht zu 95% aus Lade-/Transferbefehlen und Typwandlungen. Im Grunde genommen ist AWL Assemblerprogrammierung von der übelsten Sorte. Hat man sich längere Zeit mit einem Code nicht befasst, braucht man seine Zeit, um sich wieder reinzulesen.
> Für binäre Verküpfungen ist KOP oder FUP doch viel übersichtlicher als ein ellenlanger Code mit vielen Klammerungen.
> ...


ist meines Erachtens Quatsch!!!

AWL ist nicht übelste Assemblerprogrammierung. Wenn der Code zu 95% aus Lade und Transferbefehlen besteht (bestünde?), dann ist KOP/FUP die dümmste Alternative. Und wenn bei Binärverknüpfungen Klammern gebraucht werden, lege ich diese Zwischenergebnisse auf sprechende Variablen - es geht auch ohne ellenlangem Code und Klammern hab ich nicht!


----------



## vierlagig (19 März 2008)

wenn wir schon am zerpflücken sind 



Tom Doll schrieb:


> Gundsätzlich versuchen keine Merker zu verwenden. Man kommt zu schnell an die Grenzen und die Wiederverwertbarkeit ist zu gerring, wenn man Merker einsetzt.



das ist doch kokolores, wenn die symbolik steht, kann man die da definierten merker auf alle baugleichen oder bauähnliche anlagen anwenden ...

und zum thema AWL: da muß ich dem Perfektionist recht geben, L und T sollte nicht der hauptbestandteil sein, da läuft was schief ... UND: klammern sind OK, wenn man sie versteht  ... sie ermöglichen, dass der code in KOP/FUP darstellbar ist ...


----------



## Approx (19 März 2008)

Perfektionist schrieb:


> AWL ist nicht übelste Assemblerprogrammierung. Wenn der Code zu 95% aus Lade und Transferbefehlen besteht (bestünde?), dann ist KOP/FUP die dümmste Alternative. Und wenn bei Binärverknüpfungen Klammern gebraucht werden, lege ich diese Zwischenergebnisse auf sprechende Variablen - es geht auch ohne ellenlangem Code und Klammern hab ich nicht!


 
Wie oft wird im Forum eigentlich noch über KOP/FUP/AWL gestritten???
Ich würde sagen: *JEDER MAL NEN KNÜPPEL IN DIE HAND, UND DANN ENTSCHEIDUNGSFINDUNG!!!*


----------



## zotos (19 März 2008)

vierlagig schrieb:


> ...
> das ist doch kokolores, wenn die symbolik steht, kann man die da definierten merker auf alle baugleichen oder bauähnliche anlagen anwenden ...



Gerade bei der S7 die ja idiotischerweise zur absoluten Adressierung neigt und die rein symbolische Programmierung oft unnötig erschwert, sind Überschneidungen von Merkerbereichen äußerst nervig. Bei jedem bibliotheksfähige Baustein ist die Verwendung von Merkern tabu.


----------



## vierlagig (19 März 2008)

zotos schrieb:


> Bei jedem bibliotheksfähige Baustein ist die Verwendung von Merkern tabu.



*ACK*

...dem ist nichts hinzuzufügen...

*AUSSER:*
ein programm besteht halt nicht nur aus bibliotheksfähigen bausteinen, irgendwo müssen die ja auch aufgerufen werden und schnittstellen zwischen den bausteinen geschaffen werden und auch schnittstellen zur außenwelt


----------



## dodo (19 März 2008)

Diese Diskussion kommt mir langsam vor, als würde jemand fragen 
"Fahr ich besser 3er BMW oder Golf GTI"

Oder noch eher: "Fahr ich lieber Auto oder Boot"

1. Jeder wie er will und kann! 
2. Kommt immer auf den Fall an!


Binäre Verknüpfungen in SCL machen genauso wenig Sinn wie mathematische Berechnungen oder Kommunikationsabläufe in FUP/KOP

Man könnte fast denken, hier wären Maschinenbauer anwesend. 
Die denken ja auch fast immer, SPS wäre U Eingang = Ausgang. 



Bei mir ist es auch so, dass der Kunde vorgibt, wie sein Programm auszusehen hat. Und wenn er das letztendlich in KOP haben will, programmier ich das auch in KOP, damit ich direkt ne saubere Darstellung habe. 




[Zeigefingerhebmodus] 
Leute, müssen eigentlich die klischeehaften Verallgemeinerungen sein?

Sätze wie "AWL Programme enden nur zu oft in Spaghetti Code" unterstellen doch immer, dass AWL Programmierer unsauberer arbeiten als andere Programmierer. 
Ob und wie das unübersichtlich wird, kommt auf den einzelnen Programmierer an und hängt nicht von der Sprache ab.
[/Zeigefingerhebmodus ] 

Ich programmiere am liebsten AWL, weil ich noch aus der S5 Welt komme.
Da ging einfach nicht alles in anderen Sprachen. 
Und ich bin ein Kommentar-Freak. Ich schätze mal, dass ich hinter mindestens 80% der Programmzeilen einen Kommentar schreibe.
Das geht halt nicht in graphischen Darstellungen.


Wir können ja ne neue Sprache erfinden! 
Namensvorchlag: FT   (Freundlicher Text) 
Programmbeispiel:
Liebe Maschine, mach bitte die richtigen Dinge zur richtigen Zeit! 
Wenn irgendwas nicht so klappt, wie's soll, wäre ich Dir sehr dankbar für eine kurze Mitteilung auf dem Operator Panel!


----------



## Perfektionist (19 März 2008)

dodo schrieb:


> ...
> 
> Leute, müssen eigentlich die klischeehaften Verallgemeinerungen sein?
> 
> ...


 
vielen Dank!


----------



## zotos (19 März 2008)

dodo schrieb:


> [Zeigefingerhebmodus]
> Leute, müssen eigentlich die klischeehaften Verallgemeinerungen sein?
> 
> Sätze wie "AWL Programme enden nur zu oft in Spaghetti Code" unterstellen doch immer, dass AWL Programmierer unsauberer arbeiten als andere Programmierer.
> ...



AWL verleitet zum Spaghetti Code. Da die wichtige Strukturelemente fehlen, muss man sehr schnell zu Sprüngen greifen und dies wird schnell unübersichtlich. Die Vermeidung von Sprüngen wie "GOTO" und die Sinnvollen Ausnahmen sind doch ein alter Hut.

Einige Strukturelemente wie z.B. Loop, Sprungleiste wurden zwar nachgepflegt machen aber auch AWL noch keine Hochsprache.

Daher ist sind Verallgemeinerungen wie: "AWL Programme enden nur zu oft in Spaghetti Code" schon nicht ganz unberechtigt. Es liegt immer in der Hand des Programmierers aber der Befehlsumfang einer Sprache ist nicht ganz unbeteiligt.


----------



## Tom Doll (19 März 2008)

Tom Doll schrieb:


> Ich kann gut AWL programmieren, aber vermeide es wo es nur geht. AWL Programme enden nur zu oft in Spaghetti Code. Man kann sich nicht auf das Wesentliche konzentrieren. Der Code besteht zu 95% aus Lade-/Transferbefehlen und Typwandlungen. Im Grunde genommen ist AWL Assemblerprogrammierung von der übelsten Sorte. Hat man sich längere Zeit mit einem Code nicht befasst, braucht man seine Zeit, um sich wieder reinzulesen.
> Für binäre Verküpfungen ist KOP oder FUP doch viel übersichtlicher als ein ellenlanger Code mit vielen Klammerungen.


 
Hallo Leute, 

Da bin ich falsch verstanden worden, bzw. ich habe mich falsch ausgedrückt, darum will ich mich konkreter ausdrücken:
Wenn ich Berechnung oder Datenverarbeitungsfunktionen mit AWL programmiere bestehen diese zum Großteil aus Lade- und Transferanweisungen und Typkonvertierungen, die eigentlichen Anweisungen zur Berechnung u.ä. sind absolut in der Minderzahl. (da kann mir keiner widersprechen).

Weiterhin bin ich der Meinung, daß man binäre Verknüpfungen wegen der Übersichtlichkeit besser in KOP/FUP programmiert. Daß rein binäre Verknüpfungen in AWL Netzwerken auch in KOP/FUB darstellbar sind, ist mir bewusst. Aber nur wenn man sich and die Konvertierungsregeln hält.

Berechnungen und DV in KOP/FUP sind unter Umständen auch nicht besser darzustellen als in AWL.

Kann ich AWL nicht vermeiden, so ist Disziplin bei der Kommentierung unabdingbar. 


Wenn in bibliothekfähigen Bausteinen Merker verwendet werden kommt es immer wieder zu Problem der Adressüberschneidung, das bemerkt man meist erst bein Zusammenkopieren und dann hat man unnötige Arbeit damit. Das habe ich leider schon zu oft durchexerziert.

Ich habe viele Kollegen, die noch lieber in AWL programmieren, weil man da "Alles machen kann" (- Leider!), Sie es immer schon so gemacht haben....
Bemerkenswert ist, dass die Programme dieser Kollegen auch die wüsteten sind, da werden Instanz DB Zugriffe aus irgendwelchen FC's durchgeführt, Merker kreuz und quer verwendet und die Programmteiel sind meist nicht wiederverwendbar. Positiv ist, dass sich die meisten einen besseren Programmierstil aneignen, wenn man Ihnen moderne Programmierweisen zeigt und auch erklärt.


----------



## funkdoc (19 März 2008)

Tom Doll schrieb:
			
		

> Berechnungen und DV in KOP/FUP sind unter Umständen auch nicht besser darzustellen als in AWL


berechnungen und DV sind in kop und fup dermassen ungeeignet und bilden absolut keine bessere übersichtlichkeit als in awl. bitverknüpfungen hingegen schon.
die "einfachen" verschaltungen sollten für servicetechniker und instandhalter so übersichtlich und gut kommentiert wie nur möglich sein. wie kommen denn die leute bei einer störungsbehebung dazu, da stundenlang sich durch einen code zu wühlen, der vielleicht sogar absichtlich verkompliziert wurde und hinter einem noch der chefe steht und die stillstandsminuten zählt. das sind oft arme schweine zugegeben.

aber ich bin auch der meinung das ein programm für zb. eine verfahrenstechnische anlage gar nicht ohne awl auskommen sollte.

grüsse


----------



## zotos (19 März 2008)

funkdoc schrieb:


> ...
> aber ich bin auch der meinung das ein programm für zb. eine verfahrenstechnische anlage gar nicht ohne awl auskommen sollte.
> ...



Sollte? 
Sollte man da ein Gesetz erlassen?


----------



## funkdoc (19 März 2008)

sorry falsches wort... meinte eigentlich "kann"

grüsse


----------



## marlob (19 März 2008)

Bein meiner letzten verfahrenstechnischen Anlage (ABB DCS System + HIMA Sicherheitssteuerung) kam ich wunderbar ohne AWL aus.
Aber ich gucke mal ob ich noch ein wenig AWL einbauen kann,
Vielleicht funktionierts dann besser
Oder ich ändere alles auf PCS7 mit AWL


----------



## Tom Doll (20 März 2008)

funkdoc schrieb:


> berechnungen und DV sind in kop und fup dermassen ungeeignet und bilden absolut keine bessere übersichtlichkeit als in awl. bitverknüpfungen hingegen schon.


Sag ich doch auch, oder? Berechnungen und DV am Besten in SCL.



funkdoc schrieb:


> die "einfachen" verschaltungen sollten für servicetechniker und instandhalter so übersichtlich und gut kommentiert wie nur möglich sein. wie kommen denn die leute bei einer störungsbehebung dazu, da stundenlang sich durch einen code zu wühlen, der vielleicht sogar absichtlich verkompliziert wurde und hinter einem noch der chefe steht und die stillstandsminuten zählt. das sind oft arme schweine zugegeben.


 
Gute Kommentierung ist Grundvoraussetzung, Strukturierter Auffbau auch.
Normalerweise sollte das Ziel sein, daß der Instandhalter / Servicetechniker in fast allen Fällen keine Software zur Störungsbehebung braucht. Ich weiß aber auch, daß das meist nicht der Fall ist, sollte aber Ziel der Programmierung sein ("Kein Stillstand ohne Meldung"). Mit dieser Problematik bin ich inzwischen sehr vertraut, da wir viele Maschinen mit schnellen Vorgängen haben in denen man in der S7 Software nichts sieht, was einem bei der Diagnose helfen würde.




funkdoc schrieb:


> aber ich bin auch der meinung das ein programm für zb. eine verfahrenstechnische anlage gar nicht ohne awl auskommen sollte.


 
Willst Du das Verallgemeinern?

AWL ist grundsätzlich mal sehr maschinennahe Programmierung, vergleichbar mit Assembler. Dadurch fehlen fast alle Elemente zur Strukturierung, selbst ein "if ... then" muß mit mindestens einem Sprung programmiert werden. Dies entspricht einen GOTO und ist meiner Meinung nach ein Kennzeichen für Spaghetti Code.
Rein aufgrund dieser Tatsache ist es sehr schwer dem Spaghetti Code zu vermeiden.

Durch Beschränkungen in der S7 ist es z.B. nicht möglich Felder vernünftig zu indizieren, dadurch wird man immer wieder gezwungen in AWL zu programmieren. Eine Alternative ist in den meisten Fällen SCL, das aber nicht jeder zur Verfügung hat.


----------



## Torsten05 (20 März 2008)

Hi,

das AWL Spaghetti-Coder erzeugt ist ja wohl dummes Zeug. Das Sprünge nicht zu vermeiden sind, liegt daran das L unt T nicht VKE-Abhängig sind. Das sind sie aber bei FUP/KOP auch nicht. Es wird nur anders dargestellt. Es zwingt einen ja auch niemand Sprünge grundsätzlich über 4 Bildschirmseiten zu machen, sondern kann so machen wie es auch der Übersetzer aus FUP/KOP macht, und bleibt im gleichen Netzwerk.

Es scheint eher so als wenn die datenverarbeitenden Hochsprachenprogrammierer ihre gewohnte Umgebung genau so wenig verlassen wollen, wie die Maschinensteuernden Bitschubser.

Und niemals nicht kommen Instandhalter mit reinem SCL Code besser zurecht als mit AWL. Für die ist beides schwer zu verstehen. Dazu kommt noch das der Instandhalter erstmal SCL haben muss.

Es wird halt immer wichtiger die Daten einer Maschine zu verarbeiten, aber steuern sollte man sie auch noch, und das läuft halt immer noch überwiegend auf Bit-Ebene. 



Tom Doll schrieb:


> Durch Beschränkungen in der S7 ist es z.B. nicht möglich Felder vernünftig zu indizieren, dadurch wird man immer wieder gezwungen in AWL zu programmieren. Eine Alternative ist in den meisten Fällen SCL, das aber nicht jeder zur Verfügung hat.



Was meinst du damit?

Torsten


----------



## zotos (20 März 2008)

Torsten05 schrieb:


> ...
> Und niemals nicht kommen Instandhalter mit reinem SCL Code besser zurecht als mit AWL. Für die ist beides schwer zu verstehen.
> ...



Geht es in diesem Thread wieder einmal um die dümmsten Verallgemeinerung? 

Instandhalter sind doch nicht schwer von Begriff warum sollten die alle Probleme mit AWL oder SCL haben?


----------



## Torsten05 (20 März 2008)

Hi,

ja, es geht um Verallgemeinerungen. Ich könnte jetzt auch schreiben: " Die Instandhalter die ich kenne, die noch nie ein Programm selbst geschrieben haben, die normalerweise (schon wieder eine) Sensoren wechseln und Glühlampen, die mal Elektriker gelernt haben und keinen Bock auf PC usw haben, und natürlich auch nicht Bert, der bei Thyssen in Duisburg arbeitet, und auch nicht Fred, der schon nen Kurs gemacht hat, und Thomas nicht, der eigentlich Schlosser ist (wobei hier jemand mal schrieb das der beste Programmmierer den er kennt, Schlosser ist), und dann gibts noch Stefan, der Bäcker lernte und umgeschult hat usw...

Instandhalter sind die, die instand halten, Fehler suchen, defekte Teile wechseln und sich auf Spätschicht auch um überlaufende Toiletten kümmern.
Also Leute die Schaltpläne lesen können, aber mangels Erfahrung eben nicht die Bits im Schlaf hin und her schubsen. Schreibst du Programme, oder änderst dauernt bestehende Anlagen bist du kein Instandhalter. Und wie hier schon so oft bemerkt wurde ist das lesen von KOP für den Schaltplanfesten Elektriker nicht so schwer zu verstehen wenns um Bits geht.

Welche Farbe hat eigentlich der Himmel? Sagst du jetzt blau, oder zählst du alle RAL-Farben auf die er je nach Wetterlage annimmt?

Torsten


----------



## zotos (20 März 2008)

Torsten05 schrieb:


> Hi,
> 
> ja, es geht um Verallgemeinerungen. Ich könnte jetzt auch schreiben: " Die Instandhalter die ich kenne, die noch nie ein Programm selbst geschrieben haben, die normalerweise (schon wieder eine) Sensoren wechseln und Glühlampen, die mal Elektriker gelernt haben und keinen Bock auf PC usw haben, und natürlich auch nicht Bert, der bei Thyssen in Duisburg arbeitet, und auch nicht Fred, der schon nen Kurs gemacht hat, und Thomas nicht, der eigentlich Schlosser ist (wobei hier jemand mal schrieb das der beste Programmmierer den er kennt, Schlosser ist), und dann gibts noch Stefan, der Bäcker lernte und umgeschult hat usw...
> 
> ...



Es gibt aufgaben die sich in FUP/KOP besser lösen lassen als in allen anderen Sprachen und da macht es Sinn diese zu verwenden.
Es gibt aber eben auch Aufgaben die wie geschaffen sind für SCL.

Ich unterstelle nun auch ganz einfach mal.
Wenn jemand der mit SCL überfordert ist und an einen Programmteil geraden der sich mit einer komplexen Aufgabe befasst, die sich nun mal am besten strukturiert mit SCL lösen lässt. Wären dieser Mensch ebenso mit einer Lösung dieser Aufgabe in FUP/KOP überfordert.

Wie so oft erwähnt, es ist wichtig die passende Sprache für die Aufgabe zu wählen. Außerdem sollten sich einige Leute einfach mal mit den neuen Möglichkeiten auseinandersetzen anstatt nur zu jammern wie schwer das alles ist. man lernt eben nie aus.


----------



## Torsten05 (20 März 2008)

Hi,


zotos schrieb:


> Es gibt aufgaben die sich in FUP/KOP besser lösen lassen als in allen anderen Sprachen und da macht es Sinn diese zu verwenden.
> Es gibt aber eben auch Aufgaben die wie geschaffen sind für SCL.


Ich sag ja gar nichts anderes. Bei der Fehlersuche an einer Maschine, die dann der Instandhalter macht, geht es doch wohl zu 99% um defekte Inis oder klemmende Mechanik, und da ist die Fehlersuche für den Elektriker halt viel einfacher wenn er in KOP mal eben gucken kann warum der Ausgang denn nun nicht kommt. Der Instandhalter sucht ja nicht im Programm nach einem Fehler, warum nun die falsche Seriennummer in die Datenbank der Fertigung geschrieben wurde. NORMALERWEISE holt man dann den Maschinenhersteller, oder eben jemanden mit Programmiererfahrung.

Bei dem ganzen Geschrei um die "richtige" Sprache gehts doch meist darum auf welchem "Fahrrad" der Programmierer gelernt hat. Wer aus der Hochsprachen-Welt kommt hält SCL eben für das tollste was es gibt, auch wenn es bei der Bit-Verarbeitung (für mich) ganz klare schwächen bei der Lesbarkeit hat.
Was der Bauer nicht kennt...

Wie war das noch mit der Farbe des Himmels?

Torsten


----------



## zotos (20 März 2008)

Torsten05 schrieb:


> Hi,
> 
> Ich sag ja gar nichts anderes. Bei der Fehlersuche an einer Maschine, die dann der Instandhalter macht, geht es doch wohl zu 99% um defekte Inis oder klemmende Mechanik ...



Für sowas sollte man kein PG brauchen! Klar gibt es immer mal eine Ausnahme aber in der Regel sollte man für einen defekten Ini oder wenn eine Bewegung klemmt kein PG brauchen. Wenn das doch der Fall ist, würde ich den Zulieferer Wechseln und die Bestehenden Anlagen nachrüsten.


----------



## beowonne (20 März 2008)

zotos schrieb:


> Für sowas sollte man kein PG brauchen! Klar gibt es immer mal eine Ausnahme aber in der Regel sollte man für einen defekten Ini oder wenn eine Bewegung klemmt kein PG brauchen. Wenn das doch der Fall ist, würde ich den Zulieferer Wechseln und die Bestehenden Anlagen nachrüsten.


 
Bei Dir liegen wohl die Ini´s bei 20° fein säuberlich auf dem Tisch ?  

Wir haben jedenfalls jede Menge Heiss,Hoch,Verbaut oder einfach nur keimig.
Ansonsten gäbe es da noch geht nicht weiter ohne jede Meldung oder auch ´ne globale Sammelstörung.

Ist auch völlig verständlich das der Programmierer seine Bits in AWL verhakelt auch wenns der Instandhalter nicht mag,die können ja daran die nächsten 10 Jahre lesen üben.

Jede Sprache/Darstellung sollte einfach da eingesetzt werden wo sie am besten passt und vielleicht kann je der Programmierer mal FUP schreiben für einfache logische Operationen, weil das kriegt man nach AWL besser umgeschaltet.


----------



## zotos (20 März 2008)

beowonne schrieb:


> Bei Dir liegen wohl die Ini´s bei 20° fein säuberlich auf dem Tisch ?
> ...


Sicher nicht, die befinden sich eher im heißen Öl.
Aber wenn ein Ini defekt ist und darum der Ablauf nicht weiter läuft muss eine passende Fehlermeldung ausgegeben werden. Um einen solchen defekt zu finden, sollte man in der Regel kein PG brauchen.


----------



## funkdoc (20 März 2008)

Torsten05 schrieb:
			
		

> Instandhalter sind die, die instand halten, Fehler suchen, defekte Teile wechseln und sich auf Spätschicht auch um überlaufende Toiletten kümmern.
> Also Leute die Schaltpläne lesen können, aber mangels Erfahrung eben nicht die Bits im Schlaf hin und her schubsen.



hi

mal kleine einwende. du siehst glaub ich zu viel fern. hab keinen plan welche ausbildung du gemacht hast, aber von der realen elektr. instandhlatung hast du wenig plan.

schon allein deine ansage über die 99% der fehlerquellen seien sensorischer herkunft, halte ich auch für übertrieben. fehler wo initiatoren defekt sind, sind in der regel schnell gefunden. da gibts aber auch eine grausige andere seite der störungsbehebung, wo man wirklich den gesamten grips zusammenreissen muss um da dahinterzublicken oder auch sporadische fehler und und und.
da steht man selbst mit höheren technischen ausbildung wie der letzte schwanz da, weil man keine erfahrung in der fehlersuche hat und nicht weiss wie man denn jetzt den fehler lokalisieren könnte.

und zum klo-strotten sei gesagt, dass da manche techniker in den büros nicht so grosse haufen scheissen sollen, so wie es du gerade tust noch dazu auf hinunterblickende art.

grüsse


----------



## Torsten05 (20 März 2008)

funkdoc schrieb:


> hi
> 
> mal kleine einwende. du siehst glaub ich zu viel fern. hab keinen plan welche ausbildung du gemacht hast, aber von der realen elektr. instandhlatung hast du wenig plan.



Selbst einige Jahre Instandhaltung gemacht. Wenn du glaubst es ist schwieriger eine Maschine zu warten als sie zu entwickeln und zu bauen...




funkdoc schrieb:


> schon allein deine ansage über die 99% der fehlerquellen seien sensorischer herkunft, halte ich auch für übertrieben. fehler wo initiatoren defekt sind, sind in der regel schnell gefunden. da gibts aber auch eine grausige andere seite der störungsbehebung, wo man wirklich den gesamten grips zusammenreissen muss um da dahinterzublicken oder auch sporadische fehler und und und.
> da steht man selbst mit höheren technischen ausbildung wie der letzte schwanz da, weil man keine erfahrung in der fehlersuche hat und nicht weiss wie man denn jetzt den fehler lokalisieren könnte.
> grüsse



Machen wir es kurz an einem Beispiel fest. Nenn mir doch mal einen bei euch aufgetretenen Fehler, den du gefunden hast, der Maschinenhersteller aber nicht.
Und das mit der technischen Ausbildung... Hälst du dich für den Godfather of Instandhaltung weil du nem Ingenieur (frisch von der Uni) erklären konntest was ein Schütz ist, oder weil Du einen Fehler der Dir schon 28 mal in 4 Jahren untergekommen ist, schneller findest als der neu eingestellte Ingenieur, der in seinem bisherigem Berufsleben nur Servomotoren ausgelegt hat?

Torsten


----------



## funkdoc (20 März 2008)

> Wenn du glaubst es ist schwieriger eine Maschine zu warten als sie zu entwickeln und zu bauen...


ne glaub ich nicht... hab ich das irgendwo geschrieben?



> Hälst du dich für den Godfather of Instandhaltung weil du nem Ingenieur (frisch von der Uni) erklären konntest was ein Schütz ist, oder weil Du einen Fehler der Dir schon 28 mal in 4 Jahren untergekommen ist, schneller findest als der neu eingestellte Ingenieur, der in seinem bisherigem Berufsleben nur Servomotoren ausgelegt hat?


deine fähigkeit, sachen aus der luft zu greifen die niemand gesagt oder gemeint hat, ist schon eine beeindruckende.

wenn man als qualifizierter instandhalter (anlagenelektriker, betriebselektriker...) bestehen will, sollte man sich auch der steuerungstechnik widmen. und das ist auch so in den meisten firmen. eine firma wird es sich nicht leisten wollen jedesmal bei einem derartigem problem den maschinenhersteller heranzuziehen. also wird das oft einfach von leuten verlangt, die vielleicht nur grundkurse in SPS programmierung gemacht haben (wenn überhaupt). natürlich gibts hier auch ausnahmen! weiterbildungen sind teuer und manche firmen, wollen unverstänlicher weise auf das verzichten.

ausserdem ists auch unter automatisierungstechnikern gar nicht so selten, das der eine nicht weis wie das der andere progr. hat. und damit meine ich nicht wegen know how-geschützter bausteine (im fall siemens) etc.

grüsse


----------



## Torsten05 (20 März 2008)

Ja ok, ich bin doof. Hast du trotzdem noch ein Beispiel deiner grausamen Fehlersuche?

Torsten


----------



## funkdoc (20 März 2008)

was willst du hören?...

soll ich dir jetzt seitenweise über eine fehlerbehebung berichten, von einer anlage, die du in deinem leben noch nie gesehen hast?

grüsse


----------



## Torsten05 (20 März 2008)

Nein, 

sag mir doch einfach woran es lag das die Anlage nicht mehr lief. Das Bild wie ihr gesucht habt hab ich schon im Kopf 


Torsten


----------



## Larry Laffer (20 März 2008)

... seid ihr immer noch nicht fertig ...?
Das ist doch nicht mehr witzig ... in dem Spiel gibt es nicht den Einen der absolut Recht hat und den Anderen der absolut Unrecht hat.

Zitat von mir: "Ob eine Arbeit gut oder schlecht ausgeführt ist entscheidet nicht man selbst, sondern die anderen ..."

Gruß
LL


----------



## funkdoc (20 März 2008)

ich weiss dass das nicht witzig ist und ich weiss auch das das auch nicht die aufgabe von Ingenieuren ist. 

fehler erscheinen einem wenn man sie mal gefunden hat, dann relativ einfach und sowieso logisch, aber beim suchen hängt man sich nicht selten die haut auf.

ok mal wenn er unbedingt ein kleines beispiel haben will (weiss nicht was ihm das jetzt bringt, ausser sagen zu können "ja ist ja logisch, ihr seit alles dilettanten, ich hätte das sofort gelöst"

kuka depallettierroboter leitrechner - macht keine aktionen mehr, fährt auf befehl von bediener an der visu nicht in grundstellung - die per profibus von der steuerung eintreffenden werte sind in ordnung - vom visu pc kommt iergendwie gar nix - werte von der visu kontrolliert..alles in ordnung - schliesslci mal vom visu pc einen ping befehl per ms dos asugeführt - verlorene pakete 100% - netzwerkkarte des visu pc's in ordnung - netzwerkkarte von leitzrechner scheinbar fehlerhaft, es leuchtet keine status led - neue eingebaut auch nix

2 h später den pci steckplatz der karte gewechselt - volltreffer - defekter pci steckplatz.

geschätzte stillstandskosten 5-10 tausend euro

grüsse


----------



## Approx (20 März 2008)

Also ich hab in der aktiven Instandhalterzeit im Stahlwerk die Erfahrung gemacht, dass es eben NICHT zu 99% nur defekte INIS sind, obwohl auch bei uns oft welche "abrauchen". Zu einem sehr großen Teil liegen Fehler im Prozess einfach an falscher Bedienung der Anlage, Unkenntnis der Bediener usw... Und wer sich in der Stahlindustrie etwas auskennt, der weiss, dass es sich nicht um kleine Anlagen handelt. 

Bye the way, ich kann dieses Gehjaule um die "beste" Programmierweise nicht verstehen. Ich hab neulich mal den Vorschlag mit den Knüppeln gemacht... Also ein halber Meter NYY 50mm² tuts auch!  
Gruß Approx

PS: Meine Instandhalterkollegen von damals haben über meine Proggs noch nicht gemeckert. Scheisse ist nur, dass bei Problemen mit einer Anlage immer gleich mein Telefon klingelt, hihi!


----------



## misconduct (20 März 2008)

also ich dachte schon das ich halbwegs provoziert habe, aber was hier abgeht ist schon krass.
der gute zotos scheint nicht einzusehen das es möglich ist ohne hochsprachenkentnisse vernünftig zu programmieren.
ist da etwa jemand sauer weil sein 4 jahre langes studium und lernen diverser hochsprachen absolut nichts gebracht haben, man aber trotzdem gerne daruaf hineisen will das man könnte wenn man sollte ... hmmmm ....
abgesehen davon sollte jedem selber überlassen sein wie und auf welche art man programmiert, und der nächste depp an der anlage hat dann halt pech.
man kann sich seine arbeit schließlich nicht aussuchen, genauso wenig wie : will ich jemals wieder beiträge von zotos in dem forum lesen?

aber egal,
die irgendwie seit ihr vom eigentlichem thema abgekommen.


----------



## Question_mark (20 März 2008)

*???*

Hallo,



			
				Approx schrieb:
			
		

> man aber trotzdem gerne daruaf hineisen will das man könnte wenn man sollte ... hmmmm ....



Was ist denn jetzt eigentlich Dein persönliches Problem ??

Möchtest Du gerne und kannst nicht ..
Kannst Du schon und darfst nicht...
Fehlt Dir noch irgendeine Bescheinigung um Dich als vollwertiger Mensch zu fühlen, maxi gibt Dir vieleicht ein paar Zertifikate ab

Mann, deine Probleme möchte ich nicht haben. Sind aber wirklich nur hausgemacht ...

Gruß

Question_mark


----------



## Approx (21 März 2008)

Question_mark schrieb:


> Hallo,
> Was ist denn jetzt eigentlich Dein persönliches Problem ??
> Möchtest Du gerne und kannst nicht ..
> Kannst Du schon und darfst nicht...
> ...


 
Sach ma, wo haste denn das merkwürdige Zitat her? Eigentlich habe ich keine Probleme, (falls Du persönliche Probs meinst, technische sind ja so ne Sache), aber ich bekomme gerade Deinen Zusammenhang nicht hin!


----------



## Question_mark (21 März 2008)

*Aufklärung*

Hallo,



			
				Approx schrieb:
			
		

> Sach ma, wo haste denn das merkwürdige Zitat her?



Kann ich Dir gerne sagen : Hab das mit einer Aussage von Misconduct verwechselt und gehörte in einen anderen Fred. Sorry..

Gruß

Question_mark


----------



## marlob (21 März 2008)

misconduct schrieb:


> ...
> der gute zotos scheint nicht einzusehen das es möglich ist ohne hochsprachenkentnisse vernünftig zu programmieren.
> ist da etwa jemand sauer weil sein 4 jahre langes studium und lernen diverser hochsprachen absolut nichts gebracht haben, man aber trotzdem gerne daruaf hineisen will das man könnte wenn man sollte ... hmmmm ....
> ...


Soviel ich weiss ist der gute zotos Techniker und man muss auch nicht studiert haben um eine Hochsprache zu können.
Aber es ist sehr vorteilhaft, wenn man eine oder mehrere Hochsprachen kann, da es Aufgaben gibt die da halt besser mit zu lösen sind.


----------



## Torsten05 (21 März 2008)

funkdoc schrieb:


> i
> ok mal wenn er unbedingt ein kleines beispiel haben will (weiss nicht was ihm das jetzt bringt, ausser sagen zu können "ja ist ja logisch, ihr seit alles dilettanten, ich hätte das sofort gelöst"



Solche seltenen Sachen löst niemand in 5 Minuten, und das ihr den Fehler gefunden habt spricht für euch. 
Heisst das jetzt das Instandhalter besser mit awl und SCL klar kommen als mit FUP oder KOP? Und jedem der anwesenden Kollegen war klar was der Fehlersuchende da macht, als er nen Ping ausführte?

Torsten


----------



## lorenz2512 (21 März 2008)

hallo,
ich hoffe das du nicht über einen schlauen instandhalter stolperst.


----------



## Graph&SCL_Freak (21 März 2008)

Also ich komme aus der Hochsprachenwelt und programmiere sehr viel Prüftstände, d.h. viele algorithmische Geschichten, da gibt's eigentlich nichts besseres als SCL. AWL mag nett sein für Leute die seit 30 Jahren SPS programmieren und nie was anderes kennengelernt haben. Der Code ist einfach zu maschinennah und praktisch kaum auf andere Steuerungen portierbar. Ich kenne niemanden der seine HMI am PC noch in Assembler programmiert.

Über Graph kann man sich trefflich streiten, aber für reine Schrittsteuerungsgeschichten ist es bei der Fehlersuche (Fernwartung) genial. Man sieht halt sofort warum eine Anlage steht. Wer nie damit gearbeitet hat kann das kaum beurteilen. Aber was der Bauer nicht kennt...

Ich habe eher manchmal das Gefühl, dass viele noch in AWL arbeiten, damit sie ihren KnowHow-Schutz wahren, denn meistens versteht's nur der, der es programmiert hat (wenn überhaupt). :-D


----------



## lorenz2512 (21 März 2008)

hallo,
@ graph und scl freak: ist auch einfacher, aber ist wie mit den computer, die ersten programme waren in maschinensprache, die hardware wurde besser es gab die ersten hochsprachen.......


----------



## Graph&SCL_Freak (21 März 2008)

lorenz2512 schrieb:


> hallo,
> @ graph und scl freak: ist auch einfacher, aber ist wie mit den computer, die ersten programme waren in maschinensprache, die hardware wurde besser es gab die ersten hochsprachen.......



Klar, bloss viele SPS-Programmierer sind aus ihrer 'Maschienwelt' nicht rauszubekommen, warum auch, ist ja nur mit Arbeit verbunden. SPS- und PC-Welt fliessen immer mehr zusammen, das hat selbst Siemens schon verstanden.


----------



## lorenz2512 (21 März 2008)

hmmm,
ich seh das so wie ms dos zu vista


----------



## Torsten05 (21 März 2008)

Hi,



Graph&SCL_Freak schrieb:


> Also ich komme aus der Hochsprachenwelt und programmiere sehr viel Prüftstände, d.h. viele algorithmische Geschichten, da gibt's eigentlich nichts besseres als SCL.  Ich kenne niemanden der seine HMI am PC noch in Assembler programmiert.
> 
> Über Graph kann man sich trefflich streiten, aber für reine Schrittsteuerungsgeschichten ist es bei der Fehlersuche (Fernwartung) genial. Man sieht halt sofort warum eine Anlage steht. Wer nie damit gearbeitet hat kann das kaum beurteilen. Aber was der Bauer nicht kennt...
> 
> Ich habe eher manchmal das Gefühl, dass viele noch in AWL arbeiten, damit sie ihren KnowHow-Schutz wahren, denn meistens versteht's nur der, der es programmiert hat (wenn überhaupt). :-D



1. Abschnitt: Stimmt, aber man muss die HMI nicht selbst programmieren. Zumindest nicht grundsätzlich. Es soll Tools z.B. von Siemens dafür geben, die ganz enorme Vorteile bei der Projektierung haben.

2. Das trifft auch auf Dich zu. Es kommt drauf an was man gewohnt ist. Ich finde sicher in anderen Schritteketten den Fehler so schnell wie du in Graph. 
Persönlich mag ich Graph aber nicht. Habs angeguckt und unter "braucht kein Mensch" abgehakt.

3. Gewohnheitssache. Wer sich weiterentwickelt landet bei einem Mix aus allem. Ich weiss nicht warum du glaubst alle müssten SCL sprechen weil du es sprichst, und AWL ist böse weil du es nicht sprichst.
Ich finde das auch ganz klar unterschieden werden muss zwischen der Verarbeitung von Daten und dem Steuern einer Maschine. Beim steuern hat SCL imo nur Nachteile wenn um Bits geht.

Torsten


----------



## Torsten05 (21 März 2008)

lorenz2512 schrieb:


> hmmm,
> ich seh das so wie ms dos zu vista



Du meinst MS-Dos hat funktioniert und Vista meistens auch?

Torsten


----------



## Graph&SCL_Freak (21 März 2008)

Torsten05 schrieb:


> Ich weiss nicht warum du glaubst alle müssten SCL sprechen weil du es sprichst, und AWL ist böse weil du es nicht sprichst.
> Ich finde das auch ganz klar unterschieden werden muss zwischen der Verarbeitung von Daten und dem Steuern einer Maschine. Beim steuern hat SCL imo nur Nachteile wenn um Bits geht.



Hab ich nicht gesagt. Jede Sprache hat Vor- und Nachteile. Am Ende wird jeder damit arbeiten, womit er am besten klarkommt, ausser der Kunde schreibt die Sprache vor. Alles was ich oben geschrieben habe ist daher auch nur IMHO.


----------



## lorenz2512 (21 März 2008)

hallo,
@ torsten: die assembler programme sind schneller


----------



## zotos (21 März 2008)

Graph&SCL_Freak schrieb:


> ...
> AWL mag nett sein für Leute die seit 30 Jahren SPS programmieren und nie was anderes kennengelernt haben. Der Code ist einfach zu maschinennah ...



Wo ist den AWL Maschinennah? Wer die CPU einer SPS als Maschine betrachtet, vergisst recht schnell die Anlage und Maschine die eigentlich mit der SPS gesteuert werden soll. Es geht doch darum die Abläufe und Zustände in der wirklichen Maschine (das was der Kunde braucht) zu beschreiben. Da gibt es eben Bit-Verknüpfungen die sich am besten mit FUP/KOP beschreiben lassen. Abläufe die man am einfachsten mit Schrittketten beschreibt und da bieten sich Werkzeuge wie AS/Graph7 eben an. Bei Berechnungen und Datenhandling ist ST/SCL das beste Werkzeug. 

Für mich sind die Sprachen Maschinennah, mit denen sich die Aufgaben der Maschine am leichtesten beschreiben lassen.

Ich denke Du siehst das ähnlich.


----------



## Torsten05 (21 März 2008)

@Lorenz: Ob das bei er SPS auch so ist? Es gibt ja genug Thread wo man sich die Köpfe einschlägt wenn es darum geht ob SCL (bzw. was daraus wird) langsamer ist als AWL-programmierung.

Interessant finde ich das ganze bei der µc programmierung. Was da so einige Leute im Internet hobbymässig mit ihren kleinen Atmels u.ä. machen...

Torsten


----------



## lorenz2512 (21 März 2008)

hallo,
@ torsten: frag mal den garstig zotos wegen den minisps, wegen der laufzeit


----------



## Torsten05 (21 März 2008)

lorenz2512 schrieb:


> hallo,
> @ torsten: frag mal den garstig zotos wegen den minisps, wegen der laufzeit



Hab mich selbst ne Zeitlang mit Atmel & Co beschäftigt. Nur aus Interesse daran. IMO ist das in der Industrie aber nicht für die Anlagensteuerung geeignet. Für ganz spezielle Anwendungen vielleicht mal, aber auch da... Man findet einfach in der Steuerungstechnik mehr Leute mit S7-Kenntnissen als welche die mal eben nen µc programmieren, und ich kann ja nicht die Maschinen wegwerfen weil mein Fachmann dafür verunglückt ist... Standards sind schon wichtig...

Torsten


----------



## zotos (21 März 2008)

Torsten05 schrieb:


> @Lorenz: Ob das bei er SPS auch so ist? Es gibt ja genug Thread wo man sich die Köpfe einschlägt wenn es darum geht ob SCL (bzw. was daraus wird) langsamer ist als AWL-programmierung.
> ...



Wo schlägt sich hier irgendwer die Köpfe ein?



Torsten05 schrieb:


> Hab mich selbst ne Zeitlang mit Atmel & Co beschäftigt. Nur aus Interesse daran. IMO ist das in der Industrie aber nicht für die Anlagensteuerung geeignet. Für ganz spezielle Anwendungen vielleicht mal, aber auch da... Man findet einfach in der Steuerungstechnik mehr Leute mit S7-Kenntnissen als welche die mal eben nen µc programmieren, und ich kann ja nicht die Maschinen wegwerfen weil mein Fachmann dafür verunglückt ist... Standards sind schon wichtig...



Mumpitz gepaart mit Kokolores!

1. Atmel ARM Prozessoren findet man heute in zahlreichen SPSen.
2. Wie kommst Du darauf: "Man findet einfach in der Steuerungstechnik mehr Leute mit S7-Kenntnissen als welche die mal eben nen µc programmieren" ???  Nur zu Deiner Information die Steuerungstechnik ist mehr als nur SPS (was denkst Du was noch alles zur Steuerungstechnik gehört) und auch die SPS ist mehr als nur die S7. Wenn Du das mal etwas präzessiert hättest, hättest Du sogar recht. Da Du aber gerne verallgemeinerst und nie über den Tellerrand siehst, attestiere ich Dir einen sehr beschränkten Horizont.


----------



## Torsten05 (21 März 2008)

zotos schrieb:


> Mumpitz gepaart mit Kokolores!
> 
> 1. Atmel ARM Prozessoren findet man heute in zahlreichen SPSen.
> 2. Wie kommst Du darauf: "Man findet einfach in der Steuerungstechnik mehr Leute mit S7-Kenntnissen als welche die mal eben nen µc programmieren" ???  Nur zu Deiner Information die Steuerungstechnik ist mehr als nur SPS (was denkst Du was noch alles zur Steuerungstechnik gehört) und auch die SPS ist mehr als nur die S7. Wenn Du das mal etwas präzessiert hättest, hättest Du sogar recht. Da Du aber gerne verallgemeinerst und nie über den Tellerrand siehst, attestiere ich Dir einen sehr beschränkten Horizont.



Ach Zotos... Du bist ja ein Haarspalter. Welche Farbe hatte doch gleich der Himmel?

Ich programmiere die SPS in der dein ARM steckt aber nicht im Atmel-Studio und mir ist es auch wurscht ob der von Atmel oder von Phillips kommt.
Deshalb ist AWL auch nicht so "Maschinennah" wie einige glauben.
Und ja, es gibt mehr als S7 und es gibt mehr als NUR die SPS. Zeig mir doch  mal wie du Antriebe über Profibus an deinen ARM anbindest, oder ne nen Busknoten ansprichst. 
Nein, zeig es mir lieber nicht, denn es funktioniert ja, wenn man genug Zeit investiert. Günstiger ist es aber noch lange nicht! Was bietet der Arbeitsmarkt eher, Leute die sich mit SPS und Maschinenbau auskennen, oder µC Entwickler die das tun? 

Torsten

Edit: Ich habe den Eindruck eine Dich zufriedenstellende Antwort darf nicht aus weniger als 8 Seiten bestehen, in denen man die Kenntniss von allen auftretenden Ausnahmen aufzählt.

Edit: Komm mir jetzt bitte nicht mit Steuerungstechnik in Autos und deinem Radiowecker. Wir sind im Simatic-Forum.


----------



## zotos (21 März 2008)

Torsten05 schrieb:


> Ach Zotos... Du bist ja ein Haarspalter. Welche Farbe hatte doch gleich der Himmel?
> 
> Ich programmiere die SPS in der dein ARM steckt aber nicht im Atmel-Studio und mir ist es auch wurscht ob der von Atmel oder von Phillips kommt.
> Deshalb ist AWL auch nicht so "Maschinennah" wie einige glauben.
> ...



Das ist aber süß, zu erst Verallgemeinerst Du irgend einen Schrott von wegen µC vs. SPS dann unterstellst Du mir ich würde das so schräg sehen wie Du es darstellst. Du hast doch den völlig aus der Luft gegriffenen µC <-> SPS Vergleich ausgepackt. Ich wollte Dir zeigen das dies so nicht vergleichbar ist da es auch SPSen gibt die auf einem µC basieren.

Du kannst einen µC nicht mit einer SPS vergleichen! Das wäre so als würdest einen Dieselmotor mit einem Auto vergleichen. Ein Dieselmotor kann z.B. in einem Auto eingesetzt werden aber auch in ganz anderen Bereichen. Auch ein Auto kann von einem Dieselmotor angetrieben werden da gibt es ja aber noch die Benziner und einige exotische Konzepte.

Liest Du da was da steht, oder das was Du lesen willst?


----------



## Torsten05 (21 März 2008)

Naja, wer hier was reininterpretiert weiss ich nicht.
Wir müssen uns auf jeden Fall erstmal auf den kleinsten Nenner einigen.

Ich stelle mal folgende These auf:
Männer haben Lurche, Frauen Mumus.

Deine Antwort wird wohl so klingen:
Wie kommst Du darauf: Es gibt auch Menschen die sich wie Frauen fühlen und keine Mumu haben.??? Nur zu Deiner Information die Biologie ist mehr als nur der Mensch (was denkst Du was noch alles zur Biologie gehört) und auch die Natur ist mehr als nur die Menschen. Es gibt auch Frauen mit Lurchen, und Männer mit Tittis. Wenn Du das mal etwas präzessiert hättest, hättest Du sogar recht. Da Du aber gerne verallgemeinerst und nie über den Tellerrand siehst, attestiere ich Dir einen sehr beschränkten Horizont. 

Torsten


----------



## vladi (21 März 2008)

*Meinungen..*

Hi,


Torsten05 schrieb:


> ....Ich finde sicher in anderen Schritteketten den Fehler so schnell wie du in Graph.
> Persönlich mag ich Graph aber nicht. Habs angeguckt und unter *"braucht kein Mensch"* abgehakt.
> 
> 3. Gewohnheitssache. Wer sich weiterentwickelt landet bei einem Mix aus allem. Ich weiss nicht warum du glaubst alle müssten SCL sprechen weil du es sprichst, und AWL ist böse weil du es nicht sprichst.
> ...


Sorry, dass ich das sagen muss, aber es scheint so, dass du noch keine komplizierte (z.B. Pharma) Anlage gemacht hast, mit sehr hohe Anforderungen an Doku und Qualifizierung. Dann kommt z.B. GRAPH ins Spiel; wenn der Test so abläuft:
1. Schrittkette laufen lassen, alle Zustände(Ventile/Aggregaten) auf einem *Ausdruck* abhaken.(Positivtest 1)
2. Schrittkette laufen lassen, Schrittabbrüche durch geeignete Störungen verursachen/simulieren, Zustände abhaken.(Negativtest)
3. SPS löschen, gesichertes Programm laden, SK laufen lassen, Zustände abhaken; mit Ablauf gem. Punk 1. vergleichen.(Positivtest 2)

Ich arbeite hier mit den GRAPH Ausdrücke, und Onlinebeobachtung der SKs, Nachweise mit Screenshots. Für Trockentests(Steuermatrix) prüfen wir zuerst mit der Handfunktion alle Schritte. Das ist eine Klasse Sache.
Wie macht man sowas mit AWL und irgendwelche Bits  , na viel Spass dabei.

Nur mal so, als Gedanke..

Gruss: Vladi


----------



## Torsten05 (21 März 2008)

@ Vladi: Es gab schon komplizierte Anlagen bevor Graph erfunden wurde, und was du da machst kann man (viele) auch in AWL,KOP,FUP.
Hört sich so an als wenn in der Pharma-Industrie nur mit Graph gerabeitet werden kann, da es sonst nicht geht...Sorry, aber das ist unsinn.

Torsten


----------



## vladi (21 März 2008)

Hi,


Torsten05 schrieb:


> @ Vladi: *Es gab schon komplizierte Anlagen* bevor Graph erfunden wurde, und was du da machst kann man (viele) auch in AWL,KOP,FUP.
> Hört sich so an als wenn in der Pharma-Industrie nur mit Graph gerabeitet werden kann, da es sonst nicht geht...Sorry, aber das ist unsinn.
> Torsten


 
Früher waren die Anforderungen gaaanz andere..
Hast du solche Anlagen gemacht oder nicht? Nicht, gele..
Klar, du kannst evtl. verwenden, was du möchtest. Wie und wie lange es dauert, um die Anlage zu qualifizieren, ist die andere Frage. Heutzutage sind die Verhältnisse so: 4-6 Wochen programmieren und testen, dann 2-3 Monate Qualifizierung..

V.


----------



## Torsten05 (21 März 2008)

Hi,



vladi schrieb:


> Hi,
> 
> 
> Früher waren die Anforderungen gaaanz andere..
> ...



Nein habe ich nicht.Das es so bei deinem Kunden/Arbeitgeber vorgeschrieben ist, heisst ja nicht das es nicht auch mit FUP usw. gehen würde. Er möchte es so, also bekommt er es so. Mir ist aber keine Norm bekannt, die das fordert. Es scheint eine betriebsinterne Forderung zu sein. Die kommen häufig so dadurch zustande das der, der das entscheidet einen Standard etablieren möchte, der ihm besonders sinnvoll erscheint. Das ist nun bei dir Graph, bei anderen FUP, bei wieder anderen SCL. Du hast dich daran gewöhnt, und hälst das für gut. OK. Der Typ ist aber auch nur ein Mensch.  Er hätte genau so gut SCL o.Ä. fordern können.
Nur glaube mir bitte, nicht jeder möchte Graph, einige lehnen es sogar komplett ab. Kommt immer auf den Kunden an.

Das was dir so Komfortabel erscheint ist die Gewohnheit mit Graph umzugehen. Hättest du das anders gelernt, würdest du auch anders denken...

Torsten


----------



## vladi (21 März 2008)

*Als Schluss:*

Hi,


Torsten05 schrieb:


> Das was dir so Komfortabel erscheint ist die Gewohnheit mit Graph umzugehen. Hättest du das anders gelernt, würdest du auch anders denken...
> Torsten


OK, du hast Recht.  
Nur als Info- ich arbeite mit:
 [angeben]
Step7: GRAPH, AWL, SCL, FUP
S7 200
LOGO
PCS7
WinCC
MITSUBISHI SPSen
NAIS (Panasonic)
CoDeSys 
VisualBasic
LabView
[/angeben ende]  

Vladi


----------



## Torsten05 (21 März 2008)

D.h. aber auch das du bei 90% gar kein Graph nutzen kannst...und es geht doch

Torsten


----------



## MSB (21 März 2008)

@torsten05
Torsten05, irgendwie wenn ich deine Kommentare so lese muss ich irgendwie an "Zurück in die Zukunft" denken,
ich glaube du bist auch von der Kloschüssel gefallen.

Zu Vladis Ausführung: Bei jeder genannten SPS hier, (bis auf Logo, S7-200) kann man Graph nutzen,
bei VB und Co. dafür aber auch kein AWL, nicht mal KOP und schon gar nicht FUP.

Mfg
Manuel


----------



## funkdoc (21 März 2008)

halt kleine einwende... auf mitsubishi kann man auch mit AWL/KOP/FUP programmieren.

man darf nicht vergessen das die hier genannten programmiersprachen nur darstellungsalternativen sind. wenn man das programm erstellt mit diesen sprachen, dann über den compiler schickt (übersetzen bei siemens) kommt am schluss immer nur der für die sps verständliche coder in den ladespeicher/arbeitsspeicher. selbst AWL, KOP, FUP, SCL, JAVA und soweiter
enden immer mit gleicher syntax.

grüsse


----------



## Ralle (21 März 2008)

funkdoc schrieb:


> halt kleine einwende... auf mitsubishi kann man auch mit AWL/KOP/FUP programmieren.
> 
> man darf nicht vergessen das die hier genannten programmiersprachen nur darstellungsalternativen sind. wenn man das programm erstellt mit diesen sprachen, dann über den compiler schickt (übersetzen bei siemens) kommt am schluss immer nur der für die sps verständliche coder in den ladespeicher/arbeitsspeicher. selbst AWL, KOP, FUP, SCL, JAVA und soweiter
> enden immer im gleichen syntax container.
> ...



Aber das ist doch nun mal logisch, oder? Alles was du ißt landet auch im gleichen Container  !


----------



## funkdoc (21 März 2008)

ja dann bleibt aber das diskutieren hier sinnlos, wenn jeder unterschiedliche "tools" benutzt und am ende kommts aufs selbe raus. der eine ist halt mit dem schneller besser... der andere mit dem anderen.

ich halte auch nix von graph weil man schrittketten auch ohne graph progr. kann. 

wer sich damit aber schon öfter beschäftigt hat wird sagen dass  es eine vereinfachung und programmierunterstützung ist...

grüsse


----------



## Torsten05 (21 März 2008)

@MSB
Ich glaube langsam Zotos und ich meinen was ganz anderes. Meine Vorstellung von Mini-SPS auf Atmel-Basis ist das hier:

http://www.microsps.com/

oder aber auch das hier:

http://www.mikrocontroller.net/topic/30453#new

Vielleicht meint ihr auch ein System das sich Mini-SPS nennt, das nach IEC programmiert wird und ich nicht kenne. Es könnte aber auch sein dass das BS aus dem Mikrocontrollerforum schon so weit entwickelt ist, das man es wie eine SPS programmieren und debuggen kann. Ich habe die Sache schon lange nicht mehr verfolgt, da es für mich werder beruflich noch privat interessant war, und so Vorhaben in Foren auch oft im Sand verlaufen...

Mir ging es darum das ich nicht einen Atmega 32, AMR oder was weiss ich, ein paar Transistoren und Optokoppler, in dem das Steuerungsprogramm programmiert in Assembler oder auch C ist,  als vollwertige, industrietaugliche Steuerung ansehe.


Torsten


----------



## zotos (21 März 2008)

@Torsten05: Du hast zwar keine Ahnung, aber dafür hast Du eine rege Phantasie. Du gibst Kommentare auf Äußerungen die keiner gemacht hat.

Unterstellst einigen sehr erfahren Kollegen das sie keine Ahnung haben und stellst Instandhalter als Dumm hin. Ich finde Du gehst eindeutig zu weit!


Torsten05 schrieb:


> ...
> Und niemals nicht kommen Instandhalter mit reinem SCL Code besser zurecht als mit AWL. Für die ist beides schwer zu verstehen.
> ...


Wie Kommst Du darauf? Ist das wie bei Aldous Huxleys "_Brave New World_" die Normung der Instandhalter verbietet das Erlernen von AWL und SCL?



Torsten05 schrieb:


> ...
> Instandhalter sind die, die instand halten, Fehler suchen, defekte Teile wechseln und sich auf Spätschicht auch um überlaufende Toiletten kümmern.
> ...


Zum Glück bin ich kein Instandhalter ;o) Ich glaube auch nicht das dies wirklich die Regel ist.



Torsten05 schrieb:


> ...
> Bei der Fehlersuche an einer Maschine, die dann der Instandhalter macht, geht es doch wohl zu 99% um defekte Inis oder klemmende Mechanik
> ...


Ich habe mich im Chat mit einigen Instandhaltunsprofis unterhalten die sehen das ganz anders. Wahrscheinlich haben die aber auch keine Anlagen von Dir.



Torsten05 schrieb:


> Selbst einige Jahre Instandhaltung gemacht. Wenn du glaubst es ist schwieriger eine Maschine zu warten als sie zu entwickeln und zu bauen...


Du vergleichst wirklich gerne Sachen die nicht zu vergleichen sind. Das Dir das Entwickeln von Maschinen schwer fällt glaube ich Dir aber direkt.



Torsten05 schrieb:


> ...
> Heisst das jetzt das Instandhalter besser mit awl und SCL klar kommen als mit FUP oder KOP?
> ...


Könntest Du diesen Beitrag, in dem Du das geschrieben hast, selbst noch einmal durchlesen und erklären wer das angeblich behauptet hat. Du liest die Beiträge Deiner Kollegen einfach nicht und phantasierst Dir da was zurecht.



Torsten05 schrieb:


> ...
> Ich finde sicher in anderen Schritteketten den Fehler so schnell wie du in Graph.
> ...


Das ist eine echte Frechheit! Kennst Du den Kollegen Graph&SCL_Freak persönlich oder warum behauptet Du so einen Scheiß über ihn? 



Torsten05 schrieb:


> ...
> Persönlich mag ich Graph aber nicht. Habs angeguckt und unter "braucht kein Mensch" abgehakt.
> ...


Nur weil Du damit nicht umgehen kannst ist es unnütz? Das erklärt indirekt auch Deine Meinung zu SCL.



Torsten05 schrieb:


> Hab mich selbst ne Zeitlang mit Atmel & Co beschäftigt. Nur aus Interesse daran. IMO ist das in der Industrie aber nicht für die Anlagensteuerung geeignet.
> ...


Was denkst Du was in den ganzen Geräten drin ist die Du verwendest?



Torsten05 schrieb:


> @ Vladi: Es gab schon komplizierte Anlagen bevor Graph erfunden wurde, und was du da machst kann man (viele) auch in AWL,KOP,FUP.
> ...


Es gab auch komplexe Anlagen bevor es die SPS gab. Kann es sein das Du einfach von Natur aus Fortschrittsfeindlich bist? Das gibt es oft bei Leuten die nicht gerne Lernen.


----------



## vladi (21 März 2008)

*Ruuuuhhhheee..*

Hi Zotos,
nicht aufregen, relax, sind ja Feiertage...entspannen  . Die Leute, die du meinst, sind immer da, werden immer da sein.. sind aber letztendlich mit sich selber nicht zufriden und oft unglücklich. Immer was zu meckern..
Na dann, Prost  .

V.


----------



## zotos (21 März 2008)

Wieso aufregen? Solche Typen sind der Grund dafür das ich das sps-forum super finde. Ich amüsiere mich dabei köstlich ;o)


----------



## HDD (21 März 2008)

Hi,
kurz zu mir ich mache jetzt schon 25 Jahre Instandhaltung ( Toiletten reinigen ) oder wie man das nennen will dazu gehören dann auch Anlagen Erweiterungen auch im Softwarebereich und die Anlagen haben dann meist Hallen Größe. Jeder einigermaßen gute Programmierer egal in welcher Sprache er das dann macht versucht seine Anlagen so zu programmieren das, die Produktqualität und Quantität passt und das der Betreiber damit zurecht kommt. Zurechtkommen bedeutet hohe Verfügbarkeit und passende Produktivität das eine hängt natürlich vom anderen ab! Darin sehe ich den Zweck einer SPS Programmierung wir machen das ja nicht zum Spaß. Es werden jetzt ein paar vom Hocker fallen aber es gibt Sie die IH die auch AWL und Pointer können ja ehrlich und es soll auch tief im Wald einige geben die SCL ST verstehen.
Gut der ein oder andre könnte Spaß daran haben.

Über das Thema Verfügbarkeit kommen wir nun zu Torsten der ja unser Superprogrammierer für die nächsten 10 Jahrtausende ist. Du meinst also das es für einen Instandhalter nur noch nötig ist an die Visu zulaufen und abzulesen was da defekt ist bzw. was so gerade schief läuft.
Ach das braucht der IH ja gar nicht das kann ja der Bediener machen da steht INI XY. Ich frag mich nur warum das immer noch IH in den Firmen sind da die Maschinen doch so super laufen und jeder ablesen kann warum die gerade steht. Hast Du jemals wirklich Probleme an einer Anlage gehabt da sind noch ein paar mehr dinge zwischen Himmel und Hölle als eine paar INI die du ja so liebst. Und Toiletten reinigen ist meine Lieblings Beschäftigung besonders auf der Damentoilette. Ich hab im laufe der Zeit ja schon mit einigen Programmierern gearbeitet da waren meiner Meinung nach wirklich gute Leute bei aber so arrogant wie Du das ist mir noch nicht untergekommen! 

HDD
So jetzt geh ich mal schauen was auf der Damentoilette ansteht!

Edit: Nicht das Ihr mein, Toilettenreinigen ist nichts verwerfliches!


----------



## funkdoc (21 März 2008)

finde ich auch...

das durchlesen kann ganz schöne fragezeichen oder auch schwere lachmuskelkrämpfe hervorrufen.

bei uns in ö nennt man diese die typen wie torsten05 "einifetzer". leute die mit der tür ins haus fahren. reden dabei immer mehr als ihnen selber lieb ist, blamieren sich dabei und merken es nicht.

dabei glaub ich ja gar nicht dass er nix drauf hat....

grüsse


----------



## funkdoc (21 März 2008)

zotos lest aldous huxley:shock:

ist ja interessant:-D


----------



## Torsten05 (21 März 2008)

Ich darf mich mal selbst (vollständig) zitieren :

_Instandhalter sind die, die instand halten, Fehler suchen, defekte Teile wechseln und sich auf Spätschicht auch um überlaufende Toiletten kümmern.
Also Leute die Schaltpläne lesen können, aber mangels Erfahrung eben nicht die Bits im Schlaf hin und her schubsen. *Schreibst du Programme, oder änderst dauernt bestehende Anlagen bist du kein Instandhalter*. Und wie hier schon so oft bemerkt wurde ist das lesen von KOP für den Schaltplanfesten Elektriker nicht so schwer zu verstehen wenns um Bits geht.
_
Ich muss hier noch IMO anhängen für den "fetten" Satz.

Offensichtlich sehen sich viele Instandhalter mit Vorurteilen konfrontiert und reagieren auf einen Satz wie oben echt angepisst. 

Ich war selbst in der Instandhaltung, und kenne es wirklich so das man auf Spätschicht, als Elektriker erstmal für allen Scheiss zuständig ist, für den man eben keinen mehr anrufen kann. Das habe ich bisher so kennen gelernt, und auch in anderen Betrieben so erlebt. Gefallen hat mir das auch nicht, aber wer ist denn bei euch zuständig wenn um 20 Uhr die Toilette überläuft? Der Geschäftsführer?
JA, ich wurde gerufen wenn auf Mittagsschicht die Toilette überlief, und wenn es auch nur dafür war eine "ausser Betrieb" Schild aufzuhängen. Der Facility Manager hatte da nämlich schon Feierabend. Es scheint so zu sein als wenn man bevorzugt den Elektrikern die Verantwortung für "Sofortmassnahmen" überlässt. Die Toilette ist da nur ein Beispiel.

Das mag in riesigen Betrieben anders sein, aber wie ich schon versuchte dem Zotos zu erklären: Es gibt immer auch Ausnahmen. Und natürlich kann ich nur von dem erzählen was ich selbst so kennen gelernt habe. Das macht ihr ja auch nicht anders. 
Für mich haben Männer eben erstmal grundsätzlich einen Lurch, und Frauen eine Mumu. So kenne ich das. Wenn jemand da andere Erfahrungen gemacht hat, heisst es ja nicht das die Aussage grundsätzlich falsch ist, oder man "sowieso keine Ahnung" hat.
Ab wann fängt man eigentlich an "Ahnung" zu haben?
...
Beim letzen Projekt genau so: 450 Leute, 2 Schlosser, 2 Elektriker. Keiner Fit im programmieren. Einer auf Früh, anderer auf Spätschicht. Laptop, Software und Kabel vorhanden, und auch Kurse besucht. 
Vor Jahren! Natürlich vergisst man das wieder ohne Praxis, das geht mir doch auch nicht anders, und bei nur zugekauften Maschinen kommt man auch nicht dazu Praxiserfahrung zu sammeln. Die Programme laufen, und für Änderungen holt man DA den externen, oder halt den Hersteller.
NUR vom lesen fremder Programme bei der Fehlersuche lernt man nicht programmieren. Wenn man 2 mal im Jahr vor dem Laptop sitzt wird man kein Spezialist. Genau das meine ich aber mit Instandhalter. Er sorgt dafür das die Machinen am laufen bleiben, und Progamme gehen eigentlich nicht kaputt.
Wenn nun jemand in der Fa. auch viel Zeit damit verbringt Prozesse zu optimieren und damit auch Programme ändert, dann geht das für mich über die "normale" Instandhaltung hinaus.

Als ich Instandhalter war, gab es 2 Abteilungen: 
1. Elektriker+Schlosser+Schreiner+Klempner
2. Steuerungstechnik

Täglichens Brot waren Lampen aufhängen, Energieversorgung (Steckdosen usw), Elektrische Tore warten, Lüftung, Kompressor und der ganze Kram.
Ich hatte als Betriebselektriker nicht einmal ein Laptop in der Hand.

In der Steuerungstechnik wurden dann Maschinen gebaut für den Eigenbedarf gebaut.

Der Grund warum ich funkdoc so bohrend nach dem Fehler gefragt habe ist folgender:
Der Ansprechpartner beim Kunden ist bei mir oft der Instandhalter der ganz klar meint er hätte die Weisheit mit Löffeln gefressen weil er Fehler an einer Maschinen mal eben mit einer Handbewegung beseitig. Das der Fehler 3x die Woche auftritt und er beim ersten suchen 2 Tage gebraucht hat, verschweigt er natürlich.

*Das Lesen von FUP,KOP usw...*
Wer immer auch in der (elektrischen) Instandhaltung rumrennt, hat doch wohl zumindest eine elektrotechnische Ausbildung. Normalerweise hat man dann auch mal Schaltpläne gelesen, und ist damit schon nicht soweit von KOP entfernt. Deshalb ist für mich KOP erstmal der kleinste Nenner, den auch der "normale" Betriebselektriker versteht, im Zweifel auch dann wenn er nie programmiert. Das ist eben bei SCL und AWL nicht so. Und jetzt kommt eine Erfahrung die man nur kennt wenn man sich schon in mehrere Betrieben aufgehalten hat:
Man möchte bevorzugt FUP und KOP. Das verstehen eben die meisten. 
Das sind meine Erfahrungen die ICH in verschiedenen Betrieben gemacht habe, und ratet doch mal warum? Die Betriebe in denen es eigene Programmierer gibt, sehe ich doch gar nicht von innen, es sein denn die sind so voll mit Arbeit das die keine Zeit haben. Ich bin doch nicht der einzige der die Forderung nach KOP/FUP kennt. Denken sich das alle nur aus?

In meiner alten Fa. wurde sogar mal eine Maschine gebaut die 5! x eine Siemens Logo enthielt, weil eine eben nicht reichte. Klare Aussage: Damit kennt sich unserer Elektiker aus. Was anderes wollen wir nicht.
Noch wärend der Projektphase kam dann der Wunsch dazu einen Robi in die Anlage zu integrieren. Also baut man noch eine Beckhoff dazu.

*SCL...* ich habe nirgendwo behauptet das SCL oder auch was anderes schlecht ist. Wie hier auch schon tausendmal geschrieben wurde ist es immer sinnvoll die richtige Sprache zu wählen, und SCL halte ich bei Bitverknüpfungen schlechter als z.B. FUP. Das ich Graph nicht mag ist eben so. Nirgends habe ich geschrieben dass das keiner anwenden darf. Vladi schien aber der Ansicht zu sein, das kompliziertes nicht ohne Graph geht.

*Maschinenverfügbarkeit:
*Ja, ich versuche tatsächlich FÜR den Anlagenfaher zu programmieren. Das habe ich so gelernt als ich noch für den eigenen Betrieb programmiert habe. Da war das Ziel eben nicht die meiste Kohle für wenig arbeit zu bekommen, sondern mit den Bedienern Lösungen zu finden, die für wenig Störungen sorgten. Ich *versuche* ALLE Fehler anzuzeigen die auftreten können, oder aber diese abzufangen. Das gelingt nicht immer zu 100%, ist aber meist meilenweit von dem: "Handbetrieb geht, Automatik ist 2 mal gelaufen...einpacken..." entfernt wie man es eben auch manchmal sieht.

Ich habe die letzen 2 Monate damit verbracht einem Elektriker einer Sonderbaumaschinenfirma zu helfen ein Programm für einen Kunden fertig zu schreiben und ihm erklärt wie er was machen kann. Der hatte gar keine Ahnung vom Programmieren, aber der, der es machen sollte hat die hängen lassen. Bezahlt hat es der Endkunde für den ich dann auch noch eine Maschine bedienerfreundlich umgeschrieben habe. Da kamen gar keine Meldungen!
Ich weiss auch nicht was daran negativ ist.

Ich nehme mir auch die Zeit dem Instandhalter das Programm und die Struktur genau zu erklären, wenn er danach fragt. Das kann schonmal Stunden dauern wenn der Elektriker nur 1 mal im Jahr mit Laptop nach Fehlern sucht, aber ich versuche es. 

Wenn es euch beruhigt: Der Instandhalter wie ich ihn kenne, ist Generalist. Er muss von allem etwas wissen. Das macht ihn nicht zu einem schlechteren oder dümmeren Menschen.
Wer von euch den halben Tag vor dem Laptop verbringt ist FÜR MICH kein reiner Instandhalter. Wenn ihr euch selbst so seht...

Torsten

Edit: Das mit den Sensoren...Nach meiner Erfahrung, nur von der kann ich berichten geht elektrisch gesehen nun mal am häufigsten die Sensorik kaputt. Das muss nicht der Ini selbst sein, sonder ist häufiger das Kabel. Motoren, Ventile, Schütze und was es sonst noch so gibt hält wesentlich länger. Das gilt natürlich vor allem für Kabel wo "bewegung drin ist".
Und der kaputte PCI - Steckplatz...das ist nun wirklich seeehr selten.


----------



## lorenz2512 (21 März 2008)

hallo,
geht doch torsten, damit kann man leben.


----------



## Torsten05 (21 März 2008)

Danke, ich denke dann wurde es verstanden. Mir ist allerdings nicht klar wo ich was anderes geschrieben habe. Entweder kann ich es nicht erklären, oder einige Reizworte reichen um das Wasser überkochen zu lassen.

Torsten


----------



## HDD (21 März 2008)

Hi,
das hört sich doch schon anders an!
Jetzt noch etwas kürzer fassen dann passt das!    
Und wenn das man Bit-Verknüpfungen mit KOP oder FUP besser lesen kann geht nicht nur den IHlern so. 

HDD


----------



## zotos (21 März 2008)

So zurecht gestutzt bist Du auf einmal nur noch ein normaler Mensch.
z.B. Graph7 ist nun nur nichts für Dich, in den Beiträgen vor her war es noch:


Torsten05 schrieb:


> ...
> "braucht kein Mensch"
> ...



Du berichtest eben auch nur aus Deinen Erfahrungen also Maß Dir nicht wieder an allwissend zu sein.


----------



## Torsten05 (21 März 2008)

HDD schrieb:


> Hi,
> das hört sich doch schon anders an!


Das mag sein, aber gemeint habe ich das schon immer so!
[/quote]



HDD schrieb:


> Und wenn das man Bit-Verknüpfungen mit KOP oder FUP besser lesen kann geht nicht nur den IHlern so.
> 
> HDD


Lies dir doch bitte mal diese Beitrag von mir durch. Eigentlich reicht der letzte Absatz.

http://www.sps-forum.de/showthread.php?t=18429&page=6

Torsten


----------



## Torsten05 (21 März 2008)

zotos schrieb:


> So zurecht gestutzt bist Du auf einmal nur noch ein normaler Mensch.
> z.B. Graph7 ist nun nur nichts für Dich, in den Beiträgen vor her war es noch:
> 
> 
> Du berichtest eben auch nur aus Deinen Erfahrungen also Maß Dir nicht wieder an allwissend zu sein.



Zotos, ich wäre Dir dankbar wenn du mich ganz oder gar  nicht zitierst. 
Wenn ich wählen darf : gar nicht.

Das Orginal lautet:

*2. Das trifft auch auf Dich zu. Es kommt drauf an was man gewohnt ist. Ich finde sicher in anderen Schritteketten den Fehler so schnell wie du in Graph. 
Persönlich mag ich Graph aber nicht. Habs angeguckt und unter "braucht kein Mensch" abgehakt.

*Ich hoffe mal das es nicht deine Absicht ist durch gekürzte Zitate die Leute doof dastehen zu lassen. Da fällt mir als Stichwort Eva Hermann zu ein.

Torsten

*

*


----------



## zotos (21 März 2008)

Auch das original Zitat in voller Länge ist eine Frechheit! Ich denke Du solltest Dich für den Mumpiz den Du da verzapt hast beim Kollegen Graph&SCL_Freak entschuldigen.

Wenigstens habe ich Dich Zitiert und Dich anhand Deiner Worte kritisiert. Du hast ja mit Unterstellungen gearbeitet und somit Kollegen und auch  mir Behauptungen zu geschrieben die nie gefallen sind.

Soll ich Dir das anhand von vollständigen Zitaten Deiner Beiträge zeigen?

Noch mal, Du solltest die Beiträge der Kollegen auch lesen und Deine Phantasie im Zaum halten. Darüber hinaus schreibst Du wirres Zeug beleidigst Kollegen und verunglimpfst ganze Berufsgruppen und kommst dann klein laut an und schreibst das Du das die ganze Zeit anders gemeint hast.

Was denkst Du denn warum Du für Deine Beiträge mit soviel "Gegenwind" beehrt wurdest?


----------



## Torsten05 (21 März 2008)

zotos schrieb:


> Auch das Original Zitat in Voller Länge ist eine Frechheit. Ich denke Du solltest Dich für den Mumpiz den Du da verzapt hast beim Kollegen Graph&SCL_Freak entschuldigen.



Da bin ich nicht wirklich sicher. Ich mag nicht die beste Kinderstube haben, aber diese Aussage als Beleidigung eines Users zu benennen ist schon scharf. Was machst du denn wenn dir jemand sagt das ihm dein Auto nicht gefällt? Heulen?



zotos schrieb:


> Wenigstens habe ich Dich Zitiert und Dich anhand Deiner Worte kritisiert. Du hast ja mit Unterstellungen gearbeitet und somit Kollegen und auch  mir Behauptungen zu geschrieben die nie gefallen sind.
> 
> Soll ich Dir anhand von vollständigen Zitaten Deiner Beiträge zeigen?



Wie ich schon sagte: Ich bevorzuge nicht mehr von Dir zitiert zu werden.



zotos schrieb:


> Noch mal Du solltest die Beiträge der Kollegen auch lesen und Deine Phantasie im Zaum halten. Darüber hinaus schreibst Du wirres Zeug beleidigst Kollegen und verunglimpfst ganze Berufsgruppen und kommst dann klein laut an und schreibst das Du das die ganze Zeit anders gemeint hast.



Da muss ich dich korrigieren: Ich schrieb nicht das ich es anders meinte, sondern das ich es wohl nicht richtig ausgedrückt habe. Genau genommen schriebe ich zu Lorenz:

_Danke, ich denke dann wurde es verstanden. Mir ist allerdings nicht klar wo ich was anderes geschrieben habe. Entweder kann ich es nicht erklären, oder einige Reizworte reichen um das Wasser überkochen zu lassen._
quote=zotos;126359]
Was denkst Du denn warum Du für Deine Beiträge mit soviel "Gegenwind" beehrt wurdest?[/quote]

Weil es wohl falsch rübergekommen ist. Das ist in Foren so. Man sieht den anderen nicht, es fehlt Mimik, Gestik und die Möglichkeit auf Unklarheiten sofort zu reagieren. Dazu kommt das man auch schneller denkt und spricht, als man schreibt. Da bleiben manche Nebensätze schon mal in der Tastatur hängen.

Was du abziehst ist aber davon unabhängig. Versteck dich nicht in der beleidigten Gruppe und sprich nicht für diese. Das ist Schulhofniveau. 
Das Thema Moralapostel gabs erst heute in einem anderem Thread. Wenn dir was nicht passt, schreib es. Lass bitte andere entscheiden ob sie sich beleidigt fühlen. Die sind schon gross, und wie du siehst brauchen die dich nicht um sich zu verteidigen.

Torsten


----------



## zotos (21 März 2008)

Ich stelle fest Das Du Dich nicht richtig ausdrücken kannst und nur der arme unverstandene Torsten bist. 

Du machst Dich gerade lächerlich.


----------



## diabolo150973 (21 März 2008)

Ich kann auch schneller denken als schreiben.
Vielleicht liegt es an den ganzen Instandhaltungen und Inbetriebnahmen.

Es scheint aber immer noch Leute zu geben, die schneller schreiben als sie denken. 
Vielleicht liegt da das ganze Problem!?


----------



## Larry Laffer (21 März 2008)

Bevor sich der Eine oder Andere falsch behandelt fühlt ...
Der Fehde-Handschuh ist mit Beitrag #79 von Torsten05 geworfen worden. Nach meiner Meinung war der fragliche Beitrag für eine blosse Meinungs-Äußerung ein wenig zu scharf formuliert. Pech war, dass nun ausgerechnet Zotos da war, der den geworfenen Handschuh noch im Flug gefangen und wieder zurückgeworfen hat. Daran war nichts ehrenrühriges. 

@Torsten: Ich persönlich würde die Leute nur so heftig angreifen, wenn sie mich vorher extrem gereizt haben. Das war aber nach meiner Meinung bis dahin nicht der Fall ...

Können wir den Scheiß jetzt lassen ...?


----------



## Larry Laffer (21 März 2008)

Nachsatz:

@Torsten:
Könntest du bitte das "Danke" unter dem Beitrag von Zotos wieder zurücknehmen, denn das bewirkt für mich nur das, was Zotos in dem Beitrag geschrieben hat.

Das Ganze sollte jetzt übrigens kein Massregeln sein. Es stellt nur meine eigene Meinung zu der Sache dar. Ich wollte auf diesem Weg auch keine Lanze für Zotos brechen - das ist nämlich nicht nötig ...

Gruß
LL


----------



## kermit (21 März 2008)

Larry Laffer schrieb:


> @Torsten:
> Könntest du bitte das "Danke" unter dem Beitrag von Zotos wieder zurücknehmen, denn das bewirkt für mich nur das, was Zotos in dem Beitrag geschrieben hat.


na, da sag ich mal: ich kann das Danke recht gut verstehen ...


----------



## Torsten05 (21 März 2008)

Hi,


Larry Laffer schrieb:


> Nachsatz:
> 
> @Torsten:
> Könntest du bitte das "Danke" unter dem Beitrag von Zotos wieder zurücknehmen, denn das bewirkt für mich nur das, was Zotos in dem Beitrag geschrieben hat.
> ...



erstmal Danke für den gemässigten Beitrag, aber das mit dem "Danke löschen" lehne ich ab. Mit der Nr. 79 hast du recht, und die 81 hat es wohl nicht wie gehofft aufgehoben. So langsam sollte aber klar sein was für mich Instandhalter sind, und das ich selbst einer war, und nach der Definition von vielen wohl auch noch einer bin.

Wer sich hier gerne angepisst fühlen darf ist funkdoc. Den habe ich bewusst aggessiv gefragt. Allerdings bin ich erstaunt über das Ergebniss, wenn man hier mal ne Zeit mitliest findet man ganz andere Sachen. Die wirklichen persönlichen Beleidigungen sind hier, wie in andere Foren auch (Achtung! meine Erfahrung), den Foren-Ältensten vorbehalten.

§1. Wer nicht mit den Wölfen heult hat keine Ahnung.

Genau wie im richtigem Leben. Da kann man sich aber nicht einfach mit anderem Namen anmelden und auf die Leitwölfe ...

Da bist du ausgenommen, denn in der kurzen Zeit die ich hier wieder mitlese habe ich von Dir nur Beiträge gesehen die schlichten oder aber anderen helfen.

Um deine Frage abschliessend zu beantworten: Ja es ist jetzt Schluss. Popcorn kann wieder weggeräumt werden


----------



## funkdoc (22 März 2008)

also ich fühlte mich nicht angepisst, weder fand ich dass du bis zum beitrag #81 wen beleidigt hast.
als instandhalter kann man (nicht jeder) halt besser mit kritik umgehen als so manch anderer. kritik steht da an der tagesordnung. da wird auch nicht viel über sachen gelabert die man vielleicht ganz gut gemacht hat, sondern nur die man nicht oder schlecht gemacht hat. man muss nur darauf achten dass man beim gegenargumentieren sachlich bleibt und nicht "zuviele" schimpfwörter einbaut.

ich glaub dir schon dass du ein guter s7 programmierer bist, aber ich kann dir eine ganze latte vorlegen wo du eine null bist, so wie jeder andere in diesem forum.. mich eingeschlossen. hat aber keinen sinn da sich die meisten ja nicht kennen und sich nur hinter einem pseudonym verstecken... da kann man auch schnell mal mist schreiben ohne das es wen auffällt.

und zum klo dienst wurde ich in meiner karriere als elektriker noch nie herangezogen. arbeitest du vielleicht bei einer firma die das personal stetig mit solchen sachen tyrannisiert, um sie weich zu halten?

grüsse


----------



## Larry Laffer (22 März 2008)

@Torsten05:
Erstmal Danke, dass du meinen Beitrag richtig aufgenommen hast ...

Nochmal zum Thema Instandhalter ... ich sehe die Definition etwas anders als du ... für mich wäre nach meiner eigenen Auslegung Gordy LaForge auf der Enterprise (oder Mr. Scott in dem Modell ein paar Jahre davor) auch ein Instandhalter. Entsprechend dem sehe ich mich in meinem aktuellen Job auch zu 50% als solcher (die anderen 50% sind Erstellen von Neu-Anlagen). Es könnte sein, das auch andere sich so sehen ...

Mit "den Wölfen heulen" muss man hier m.E. nicht. Allerdings kann ein kleiner Seitenhieb zum unpassenden Zeitpunkt möglicherweise eine Lawine auslösen. Das ist aber im wirklichen Leben auch so.
Falls du dir da jetzt eine andere Meinung gebildet haben solltest, würde ich das bedauern. 


> Die wirklichen persönlichen Beleidigungen sind hier, wie in andere Foren auch (Achtung! meine Erfahrung), den Foren-Ältensten vorbehalten.


Falls du das auf Zotos oder einen der Anderen beziehst, so muss ich dazu sagen, dass (aus meiner Sicht) Zotos nicht unverdient zum "User 2007" gewählt worden ist. Ich selber bin auch erst 1 Jahr aktiv im Forum und kann deiner diesbezügliche Erfahrung nicht teilen. Im Gegenteil, wenn ich mal etwas wissen wollte oder mich bei einem Thema vielleicht etwas abseits der Gleise bewegt habe, dann war ich damit nie allein und bin deswegen auch nicht mit Geringschätzung behandelt worden. Ist aber vielleicht auch eine Sache von "wie man in den Wald hereinruft ..." 

Ich denke, damit ist die Angelegenheit nun wirklich erledigt ...
Ein schönes Osterfest ...
Gruß
LL


----------



## Torsten05 (22 März 2008)

Hi,



funkdoc schrieb:


> also ich fühlte mich nicht angepisst, weder fand ich dass du bis zum beitrag #81 wen beleidigt hast.
> 
> 
> ...
> ...



Beleidigt nicht, aber bewusst agressiv nachgefragt. Ich finde das kann man auch ruhig so sagen. 

Der Klo-Dienst ist wie gesagt nur eine von vielen Möglichkeiten die einem auf Spät-Schicht so begegnen. Die Frage ist doch jetzt eher: Wer denn sonst?
Bei uns war halt ausser dem Bedienpersonal und ein paar Werkzeugmachern niemand mehr. In vielen Betrieben ist es nicht anders. Mittags geht alles ausser Inst und Anlagenfahrer nach Hause. Man hat dann als Elektriker sozusagen erstmal die Verantwortung für alles. Wie ich schon schrieb: Es scheint so zu sein das man von den normalen Facharbeitern die sich in der Industrie so tummeln, am ehesten den Elektrikern sowas anvertraut.
Für mich war das auch keine Schikane oder sowas. Es muss sich ja jemand um sowas kümmern, und du kannst auch nicht für jeden Fall noch einen einstellen, der dann 200 Tage im Jahr Däumchen dreht.  Das wir überhaupt einen eigenen Klempner hatten war schon Luxus.
Nach meiner Erfahrung sieht das in Produktionsbetrieben mit 100-500 Leuten oft so aus. Bei Thyssen mit 4500 Mitarbeitern war das anders, aber frag mich nicht wie. Da gab es auch nicht nur eine Inst, sondern gleich mehrere Stützpunkte. Da sind wir auch zu dritt losgegangen um einen Leuchtstofflampe zu wechseln. Und zwar zwei mal. Erstmal mit 3 Mann gucken, einer besorgt Material, die anderen zum Werkskiosk, und dann: 2 labbern, einer wechselt die Röhre. Dann war es in der Regel schon 11 Uhr, so das man sich langsam auf den Feierabend einstellen konnte.

Auf meiner ersten Mittagschicht die ich je allein hatte, ist kurz nach 16 Uhr der Strom im ganzen Werk (nicht Thyssen) ausgefallen. Und genau so fragend wie mich alle anguckten, guckte ich wohl auch zurück. 
Ein Bagger hat halt ein Kabel gekappt. Zum Glück hat sich mein Chef, der in der Nähe wohnte, dann mit den Stadtwerken auseinandergesetzt. Für so einen Fall gabs dann keinen Plan X.

Was das Programmieren angeht: Ein Kurs allein bringts nicht. Man muss es anwenden. Nach der Führerscheinprüfung ist man auch kein guter Fahrer. Es gibt in diesem Forum sicherlich viele Leute die besser programmieren als ich, und auch viele die mehr Systeme kennen. Wenn du mal andere Posts von mir gelesen hast, wirst du feststellen das es für mich die absolute Wahrheit dabei nicht gibt. Aber natürlich finde ich meine Art zu programmieren am besten, und es gibt auch Ansätze die ich Sch... finde. Logisch, denn sonst würde ich es ja anders machen. Und tatsächlich hat sich das in den letzen Jahren stark geändert. Ich sehe wie andere es machen, und wenn ich das gut finde, wird das übernommen. So gut wie nichts von dem wie ich programmmiere ist vom System her selbst ausgedacht. Überall finden sich Ansätze die ich mal irgendwo sah und gut fand, und die ich für meine Bedürfnisse angepasst habe.
Es ist auch keine Lebensberechtigungnsvorraussetzung überhaupt etwas programmieren zu können. 
Mir ist auch dieses Forum völlig Latte. Ich bin seit ewig und 3 Tagen angemeldet und war ewig lange nicht online. Abgesehen von einem Beitrag des Users Ralle, und einer Frage dich ich am Anfang mal stellte, habe  ich bisher keinen bewusten fachlichen Nutzen aus dem Forum gezogen. Wenn ich ne Aufgabe bekomme schnapp ich mir in der Regel die Handbücher und lese dort nach. Bei einem Problem bei der IBN guck ich als erstes auf der Hersteller Homepage, oder ruf den Support an. Das ist zeitlich meist vorteilhafter. 
Trotzdem finde ich diese Forum und auch viele andere Foren sehr gut. 
Man sollte nur nicht vergessen das man sich in einem virtuellem Raum befindet. Natürlich sitzen vor den Tastaturen Menschen, die sich aber in den meisten Fällen, also bis auf die "seit anbegin der Zeit"- User nicht kennen. Dir kann es völlig egal sein was ich von dir denke, und mir was der Rest denkt. Das ich mir überhaupt die Zeit genommen habe nochmal dieses lange Post zu schreiben, liegt an den Menschen vor der Tastatur. 
Das User die sehr viel Zeit in diesem Forum verbringen, für die es ein Hobby, fast schon eine soziale Bindung ist, das anders sehen verstehe ich natürlich. Deren Meinungen interessieren mich aber nicht wirklich.
Ich kann morgen schon Michael08 heissen wenn mir danach ist. Und vielleicht antwortet mir schon morgen genau dieser User mit dem guten Gefühl, er habe etwas positives bewirkt. Es sei ihm gegönnt

Torsten


----------



## Torsten05 (22 März 2008)

Hi,



Larry Laffer schrieb:


> @Torsten05:
> Erstmal Danke, dass du meinen Beitrag richtig aufgenommen hast ...
> 
> Nochmal zum Thema Instandhalter ... ich sehe die Definition etwas anders als du ... für mich wäre nach meiner eigenen Auslegung Gordy LaForge auf der Enterprise (oder Mr. Scott in dem Modell ein paar Jahre davor) auch ein Instandhalter. Entsprechend dem sehe ich mich in meinem aktuellen Job auch zu 50% als solcher (die anderen 50% sind Erstellen von Neu-Anlagen). Es könnte sein, das auch andere sich so sehen ...



Ja, offenbar ein klarer Irrtum von mir. Vieleicht sind aber auch die vielen Betriebselektriker ohne Laptop hier einfach in der Unterzahl 
Edit: ARGH, ich bin ja gar nicht auf Star Trek eingegangen Die beiden ändern ständig am Antrieb rum und entwickeln neue Kraftfelder... Die Wartung machen da die anderen


Larry Laffer schrieb:


> Falls du das auf Zotos oder einen der Anderen beziehst, so muss ich dazu sagen, dass (aus meiner Sicht) Zotos nicht unverdient zum "User 2007" gewählt worden ist. die Angelegenheit nun wirklich erledigt ...
> Ein schönes Osterfest ...
> Gruß
> LL



Ich bin in unzähligen Foren mehr oder weniger aktiv, meist weniger, da ich recht viele interessen und Hobbies habe. Und egal was man gerade wissen muss, irgendwer hat auch schon ein Forum dazu eröffnet.
Das sind also eher allgemeine Erfahrungen, die man aber auf jede Gruppe von Menschen beziehen kann. Der Neuling im Schützenverein pinkelt dem Vorsitzenden auch nicht ans Bein, selbst wenns absolut berechtigt ist. Auch das aufsehen zu den alten Mitgliedern gibts im real-life in jeder Gruppierung.  Das muss wohl so sein, weils sonst nicht funktioniert. Im Internet kann man sich allerdings den Luxus leisten eben auch solchen "verdienten" Leuten ohne Reue die Meinung zu sagen. Das gilt für beide Seiten. Hier sind erstmal alle gleich.
Das ich mich an Zotos IMO falschen Zitaten so gerieben habe hat einen anderen Grund den viele hier wahrscheinlich für lächerlich halten. Es gab im Jahr 2007 nichts in der Öffentlichkeit was mich so erschreckt hat wie das was in den Medien wegen Kerner/Hermann abging. Mich hats echt schockiert.

Torsten


----------



## dani (23 März 2008)

Torsten05 schrieb:


> Ja, offenbar ein klarer Irrtum von mir. Vieleicht sind aber auch die vielen Betriebselektriker ohne Laptop hier einfach in der Unterzahl



Also das muss ich einfach aufgreifen. In dem Betrieb in dem ich arbeite (mittelständische Molkerei mit eigenem Anlagenbau) sind wir in der E-Werkstatt 9 Elektriker, davon 1 Programmierer rein für die neuen Prozessanlagen. Von den anderen 8 haben 5 einen eigenen Laptop.
Bei den restlichen 3 ist einer in der Nachtschicht und die anderen 2 sind die "Ersatzmänner" für die Früh- und Spätschicht. Es wird eigentlich von jedem erwartet dass er sowohl Fehlersuche  als auch Änderungen an Programmen vollziehen kann.
Zum Thema wie gut manche Programmierer sind: Wir haben die letzten Wochen eine komplette Abfülllinie in Betrieb genommen (8 kleinere bis mittlere Anlagen) davon sind im Laufe der letzten Wochen 3 irgendwo im Wald stehen geblieben. Natürlich dann wenn der Service des Maschinenherstellers nicht mehr erreichbar ist.
Ausbaden kann man es dann als IH wenn man sich durch undurchsichtige Programme hangeln muss um zu sehen dass noch irgendwo eine Negierung falsch war.

Ich denke dass von den IH in der Regel deutlich mehr erwartet wird als nur Inis auszutauschen, was bei uns auch zum grossen Teil die Anlagenfahrer machen.

Ach ja, bei uns wird eigentlich alles in AWL programmiert

PS: Die WC´s machen bei uns die Schlosser sauber


----------



## diabolo150973 (23 März 2008)

Ich möchte Dani voll und ganz Recht geben. Ich habe als Servicetechniker sehr viel mit Instandhaltern zu tun, weil ich gerufen werde, wenn wirklich nichts mehr geht. Das Problem bei vielen Maschinen-/Anlagenherstellern, ist einfach, dass funktionierende Sachen nicht, bzw. kaum verändert werden und von Anlage zu Anlage weitergeführt werden. Ich meine damit, dass bei den Herstellern oft keine Zeit ist, über den Tellerrand zu schauen um zu gucken, wie die "Konkurenz" bestimmte Sachen löst. Das bedeutet für mich: Wenn ich keine Zeit habe, weil die Anlage schnellstmöglich wieder laufen muß, dann wird es so gemacht "wie es immer gemacht wird". 
Aber von Instandhaltern wird verlangt, dass sie alles kennen und können, was in ihrem Betrieb so vorkommt. Egal, welche Anlage und egal, welcher Hersteller. Ich bin manchmal auf's Größte erstaunt, wenn ich sehe, wie manche sich erstmal zu helfen wissen, bis der Kundendienst da ist. Und von vielen Kunden hören wir fast gar nichts mehr (außer Ersatzteilbestellungen), weil die zuständigen IHler voll und ganz in der Lage sind, z.B. bei Produktänderungen, die Anlage selber anzupassen. Leider wird dann aber oft vergessen, uns als Hersteller von Änderungen zu unterrichten und wir stehen dann vor einer "völlig anderen" Anlage und gucken wie die Kühe wenn's donnert.


----------



## Markus (23 März 2008)

ich habe mir jetzt wirklich nicht alle seiten durchgelesen. eigentlich wollte ich mich dem thema auch fernhalten da mir bei diesen ganzen AWL/KOP/FUP/ST/... topic generell der sack platzt.

grundsätzlich darf man zu dem thema sagen das AWL nicht gleich AWL und SCL nicht gleich SCL ist - der programmierer macht daraus was lesbares und strukturiertes oder eben bullshit!


also, ich habe am anfang mit FUP meine ersten schritte gemacht.
bin dann aber relativ schnell u awl gekommen.

KOP und FUP haben für mich in der PRAXIS* maximal eine einzige daseinsberechtingung:
Sie sind ANGEBLICH instandhalterfreundlicher.

*zum lernen primitiver verknüpfungen sind die sprachen sicher genial - also in deinem Fall auf sicher der richtige schritt am anfang der ausbildung.

Schlecheter und vor allem nicht dokumentierter AWL code mit schlampiger Symbolik ist sicher nicht schön, aber meiner meinung nach ist ein AWL code - vor allem danke der möglichkeit zeilenweise zu kommentieren - das wartungsfreunldichste was es gibt...

Ich habe unten mal Beispielcode angehängt um einen meiner meinung nach schönen awl-code zu zeigen - ist ja auch von mir...  

Schneller, sauberer und übersichtlicher programmiert man definitiv mit AWL oder anderern sprachen auf die ich gleich kommen werde.




vierlagig schrieb:


> persönlich finde ich diese diskussion mittlerweile zu SCL-pro-lastig ... aber macht ruhig weiter, das forum ist geduldig ...


 

wie gesagt bin ich sehr AWL-verliebt, aber ich wurde so erzogen!
wenn ich in meiner letzten firma am telefon bei meinen chef rumgeheult habe das ich die zykluszeit bei der 315er nicht unter 30ms bekomme, aber max 20 zulässig sind. dann hat er mir erklärt wie er eine viel größerer solche anlage damals mit der S5-95U auf 18ms hatte. und das durfte man ihm glauben, ich kannte ja seine alten kisten.
naja und aus den perversionen die ich in seinem alten laufzeitoptimierten code gelernt hatte entwickelte sich mein stil. unsere standars cpu war immer die 315, ein konkurent der auch nur mit wasser kochte hatte generell ein 400er rack drin...

ein AWL programm, das sauber strukturiert aufgebaut ist hat natürlich ncht mehr diese super laufzeit, wie der perverse aber recht interessante code von meinen ex-chef, aber es ist sicher schneller als eine kop/fup prg mit dem ganzen "nop 0" und "bld" ballast...


auch ich komme immer mehr weg von AWL in richtung SCL, das liegt daran das es, schneller und übersichtlicher zu programmierern ist.

von graph verstehe ich nicht viel, ich mache meine schrittkette mit sprungleisten in awl (siehe beispielcode).

aber ich denke das die zukunft eideutig SCL im verbund mit GRAPH gehören wird.


AWL verliert seine daseinsberechtigung, und KOP und FUP hatte meiner meinung nach noch nie wirklich eine... 


in der ausbildung ist der aufbau und die struktur von sps prgrammen vielleicht auch noch ein wichtiger punkt.

temporäre variablen anstatt schmiermerker
iec timer anstatt s7 timer
wiederverwendbare und instanzierbare bausteine...



so und jetzt noch der code für eine schrittkette in awl
liebe kollegen aus der isntandhaltung: ist das ganz erhlich so schwer zu verstehen? bisher hatte eure kollegen die mir begeneten damit kein problem...


----------



## Markus (23 März 2008)

```
// -->- Globale Bedingung "SK_Weiter" (kann z.B. für Einzelschrittbetrieb genommen werden)
      SET                               // kein Einzelschrittbetrieb
      =     #SK_Freigabe

// -->- Startbedingung für Schrittkette
      U     #IO_Start
      SPBN  STA1
      L     0
      T     #Schrittnummer
STA1: NOP   0
 
// -->- Schrittkette - Sprungleiste
      L     #Schrittnummer
      SPL   SKED
      SPA   S00                         // Initialisierung
      SPA   S01                         // Reserve
      SPA   S02                         // Flexcontrol+ "STOP" (stoppen damit gespült werden kann)
      SPA   S03                         // Neue Rezeptnummer an Flexcontrol+ schicken
      SPA   S04                         // Reserve
      SPA   S05                         // Roboter in Spülposition fahren
      SPA   S06                         // Flexcontrol+ "SPÜLEN" (Spülvorgang starten)
      SPA   S07                         // Reserve
      SPA   S08                         // Roboter in Wartungsposition fahren (Bediener kann Pistole wechseln)
      SPA   S09                         // Bediener zum Pistolenwechsel auffordern und Quittierung abwarten
      SPA   S10                         // Störung am Roboter quittieren - Roboter hat Störung weil Bediener Schütztüren geöffnet zum Pistolenwechsel geöffnet hat
      SPA   S11                         // Roboter in Homeposition fahren - Roboter kann nach der Störung selbständig keine Routinen mehr starten
      SPA   S12                         // Reserve
      SPA   S13                         // Roboter in Spülposition fahren
      SPA   S14                         // Reserve
      SPA   S15                         // Flexcontrol+ "START" (Lackvorlegen) - Wenn kein Pistolenwechsel mit "Farbwechselspülen"
      SPA   S16                         // Reserve
      SPA   S17                         // Flexcontrol+ "START" (FC+ einschalten - Automatik)
      SPA   S18                         // Reserve
      SPA   S19                         // Roboter in Homeposition zurückfahren
      SPA   S20                         // Reserve
      SPA   S21                         // Reserve
      SPA   S22                         // Rezeptnummer und Farbnummer an Roboter schicken
      SPA   S23                         // Strobe an Roboter schicken -> Roboter kann neuen Job beginnen
      SPA   S24                         // Reserve
      SPA   S25                         // Stopper freigeben und ENDE
SKED: SPA   END1
//-->------------------------------------------------------------------
S00:  NOP   0                           // Initialisierung
      SET   
      R     #O_Robo_HOME
      R     #O_Robo_CLEAN
      R     #O_Robo_SERVICE
      R     #O_Robo_RESET
      R     #IO_Pistole_gewechselt
      R     #O_Pistole_Wechseln
      R     #O_Robo_Strobe
      U     #IO_Start
      U     #SK_Freigabe
      S     #SK_Weiter
      SPA   END1
//-->------------------------------------------------------------------
```


----------



## Markus (23 März 2008)

```
S01:  NOP   0                           // Reserve
      U     #SK_Freigabe
      S     #SK_Weiter
      SPA   END1
//-->------------------------------------------------------------------
S02:  NOP   0                           //  Flexcontrol+ "STOP" (stoppen damit gespült werden kann)
      SET   
      S     #IO_Flex_STOP
      U     #SK_Freigabe
      S     #SK_Weiter
      SPA   END1
//-->------------------------------------------------------------------
S03:  NOP   0                           // Neue Rezeptnummer an Flexcontrol+ schicken
      U     #IO_Flex_STOP               // Flex ist in Stop wenn Taste zurückgesetzt wurde
      SPB   END1
      L     #I_Farbnummer               // In der Flex wird die Farbnummer im Rezept hinterlegt (Rezept-1 = Farbe-1; Rezept-2 = Farbe-2;...)
      T     #O_Flex_RECIPE
      U     #SK_Freigabe
      S     #SK_Weiter
      SPA   END1
//-->------------------------------------------------------------------
S04:  NOP   0                           // Reserve
      U     #SK_Freigabe
      S     #SK_Weiter
      SPA   END1

//-->------------------------------------------------------------------
S05:  NOP   0                           // Roboter in Spülposition fahren
      SET   
      S     #O_Robo_CLEAN
      U     #I_Robo_CLEAN               // Weiter wenn Roboter in Spülposition
      U     #SK_Freigabe
      S     #SK_Weiter
      SPA   END1
//-->------------------------------------------------------------------
S06:  NOP   0                           // Flexcontrol+ "SPÜLEN" (Spülvorgang starten)
      UN    #IO_Pistolenwechsel
      SPBN  M001
      L     15                          // weiter in Schritt-15 wenn kein Pistolenwechsel erforderlich ist
      T     #Schrittnummer
M001: SPA   END1
      SET   
      S     #IO_Flex_SPUELEN
      U     #SK_Freigabe
      S     #SK_Weiter
      SPA   END1
//-->------------------------------------------------------------------
S07:  NOP   0                           // Reserve
      UN    #I_Flex_Flush
      UN    #IO_Flex_SPUELEN            // Weiter wenn Flexcontrol fertig gespült hat
      U     #SK_Freigabe
      S     #SK_Weiter
      SPA   END1
//-->------------------------------------------------------------------
S08:  NOP   0                           // Roboter in Wartungsposition fahren (Bediener kann Pistole wechseln)
      SET   
      R     #O_Robo_CLEAN
      S     #O_Robo_SERVICE
      U     #I_Robo_SERVICE             // Weiter wenn Roboter in Wartungsposition ist
      U     #SK_Freigabe
      S     #SK_Weiter
      SPA   END1
//-->------------------------------------------------------------------
S09:  NOP   0                           // Bediener zum Pistolenwechsel auffordern und Quittierung abwarten
      UN    #IO_Pistole_gewechselt
      =     #O_Pistole_Wechseln
      U     #IO_Pistole_gewechselt      // Taste - Bediener hat Pistolenwechsel bestätigt
      U     #SK_Freigabe
      S     #SK_Weiter
      SPA   END1
//-->------------------------------------------------------------------
S10:  NOP   0                           // Störung am Roboter quittieren - Roboter hat Störung weil Bediener Schütztüren geöffnet zum Pistolenwechsel geöffnet hat
      SET   
      R     #O_Robo_SERVICE
      S     #O_Robo_RESET
      UN    #I_Robo_ERROR               // Weiter wenn Roboter wieder Störungsfrei ist
      U     #SK_Freigabe
      S     #SK_Weiter
      SPA   END1
//-->------------------------------------------------------------------
S11:  NOP   0                           // Roboter in Homeposition fahren - Roboter kann nach der Störung selbständig keine Routinen mehr starten
      SET   
      S     #O_Robo_HOME
      U     #I_Robo_HOME                // Weiter wenn Roboter in Homeposition ist
      U     #SK_Freigabe
      S     #SK_Weiter
      SPA   END1
//-->------------------------------------------------------------------
S12:  NOP   0                           // Reserve
      U     #SK_Freigabe
      S     #SK_Weiter
      SPA   END1
//-->------------------------------------------------------------------
S13:  NOP   0                           // Roboter in Spülposition fahren
      SET   
      R     #O_Robo_HOME
      S     #O_Robo_CLEAN
      U     #I_Robo_CLEAN               // Weiter wenn Roboter in Reinigungsposition ist
      U     #SK_Freigabe
      S     #SK_Weiter
      SPA   END1
//-->------------------------------------------------------------------
S14:  NOP   0                           // Reserve
      U     #SK_Freigabe
      S     #SK_Weiter
      SPA   END1
//-->------------------------------------------------------------------
S15:  NOP   0                           //  Flexcontrol+ "START" (Lackvorlegen) - Wenn kein Pistolenwechsel mit "Farbwechselspülen"
      SET   
      S     #IO_Flex_START
      U     #SK_Freigabe
      S     #SK_Weiter
      SPA   END1
//-->------------------------------------------------------------------
S16:  NOP   0                           // Reserve
      UN    #I_Flex_Prepare
      UN    #IO_Flex_START              // Weiter wenn Flexcontrol fertig vorgelegt hat
      U     #SK_Freigabe
      S     #SK_Weiter
      SPA   END1
//-->------------------------------------------------------------------
S17:  NOP   0                           // Flexcontrol+ "START" (FC+ einschalten - Automatik)
      SET   
      S     #IO_Flex_START
      U     #I_Flex_READY
      U     #SK_Freigabe
      S     #SK_Weiter
      SPA   END1
//-->------------------------------------------------------------------
S18:  NOP   0                           // Reserve
      U     #SK_Freigabe
      S     #SK_Weiter
      SPA   END1
//-->------------------------------------------------------------------
S19:  NOP   0                           // Roboter in Homeposition zurückfahren
      SET   
      R     #O_Robo_CLEAN
      S     #O_Robo_HOME                // wird im Initialisierungsschritt zurückgesetzt
      U     #I_Robo_HOME
      U     #SK_Freigabe
      S     #SK_Weiter
      SPA   END1
//-->------------------------------------------------------------------
S20:  NOP   0                           // Reserve
      U     #SK_Freigabe
      S     #SK_Weiter
      SPA   END1
//-->------------------------------------------------------------------
S21:  NOP   0                           // Reserve
      U     #SK_Freigabe
      S     #SK_Weiter
      SPA   END1
//-->------------------------------------------------------------------
S22:  NOP   0                           // Rezeptnummer und Farbnummer an Roboter schicken
      L     #I_Rezeptnummer
      T     #O_Robo_RECIPE
      L     #I_Farbnummer
      T     #O_Robo_COLOR
      U     #SK_Freigabe
      S     #SK_Weiter
      SPA   END1
//-->------------------------------------------------------------------
S23:  NOP   0                           // Strobe an Roboter schicken -> Roboter kann neuen Job beginnen
      SET   
      S     #O_Robo_Strobe              // Wird im Initalisierungsschritt zurückgesetzt
      U     #SK_Freigabe
      S     #SK_Weiter
      SPA   END1
//-->------------------------------------------------------------------
S24:  NOP   0                           // Reserve
      U     #SK_Freigabe
      S     #SK_Weiter
      SPA   END1
//-->------------------------------------------------------------------
S25:  NOP   0                           // Stopper freigeben und ENDE
      SET   
      S     #IO_Frg_Stopper
      R     #IO_Start
      R     #IO_Pistolenwechsel
      U     #SK_Freigabe
      S     #SK_Weiter
      SPA   END1
END1: NOP   0

//-->- Weiterschalten
      U     #SK_Weiter
      SPBN  SKWE
      L     #Schrittnummer
      +     1
      T     #Schrittnummer
      SET   
      R     #SK_Weiter
SKWE: NOP   0
```


----------



## Ralle (23 März 2008)

@Markus

Du solltest doch nicht bei mit klauen :icon_twisted:  !

PS: Für die Schrittkettenverwaltung hab ich 'nen kleinen FC, aber im Prinzip ist das identisch.


----------



## HDD (23 März 2008)

Hi,
@ Markus


> so und jetzt noch der code für eine schrittkette in awl
> liebe kollegen aus der isntandhaltung: ist das ganz erhlich so schwer zu verstehen? bisher hatte eure kollegen die mir begeneten damit kein problem...


 
Hat das wer gesagt bzw. geschrieben?
Es wurde uns unterstellt das wir es nicht könnten.
Die SPL Sprungleiste ist denke ich für sehr viele IH kein Problem und nie eines gewesen! Habe ich übrigens auch schon so gemacht aber ich liebe meine Merkerketten  deshalb bin ich da hängen geblieben!
Und es ist wirklich so wenn du schnell einen Fehler suchst ist eine KOP oder FUP anschicht für Bit-Verknüpfungen nun mal übersichtlicher.
Alles andere ist besser bei AWL oder SCL aufgehoben.

HDD


----------



## dani (23 März 2008)

Markus schrieb:


> so und jetzt noch der code für eine schrittkette in awl
> liebe kollegen aus der isntandhaltung: ist das ganz erhlich so schwer zu verstehen? bisher hatte eure kollegen die mir begeneten damit kein problem...



Ich komme damit gut zurecht. Ich finde so sollten Programmcodes auch aussehen.
Mir persönlich ist ein schön Kommentierter AWL Code mit guter Symbolik allemal lieber ein irgendein KOP-Gedöns.
Lieber mehrere kleine AWL Netzwerke als ein riesiges 3xscrollen Fup Netzwerk, das ist meine Meinung zu dem Thema.


----------



## HDD (23 März 2008)

> Ich komme damit gut zurecht. Ich finde so sollten Programmcodes auch aussehen.
> Mir persönlich ist ein schön Kommentierter AWL Code mit guter Symbolik allemal lieber ein irgendein KOP-Gedöns.
> Lieber mehrere kleine AWL Netzwerke als ein riesiges 3xscrollen Fup Netzwerk, das ist meine Meinung zu dem Thema.


 
Also man kann beides schlecht machen und ich hab schon Netzwerke in AWL gesehen die waren so lange die hättest du in FUP oder KOP nicht hinbekommen! Es sollte natürlich sinnvoll Prgrammiert werden!
Aber es ist halt mal so jeder hat seine Vorlieben und das ist auch gut so!

HDD


----------



## kermit (23 März 2008)

@Markus: ja, bitte, genauso! Genauso kann ich das als AWL-Proggi sofort verstehen!

OT: da ja gerade Madagascar im Fernsehen läuft: wo ist eigentlich unser User matmer abgeblieben (letzte Aktivität 31.1.)?


----------



## Markus (23 März 2008)

kermit schrieb:


> @Markus: ja, bitte, genauso! Genauso kann ich das als AWL-Proggi sofort verstehen!
> 
> OT: da ja gerade Madagascar im Fernsehen läuft: wo ist eigentlich unser User matmer abgeblieben (letzte Aktivität 31.1.)?


 
kein problem, kostet 60,00€ die stunde - telefon nr steht im impressum...


----------



## Johnnnny (18 Januar 2009)

Hallo zusammen,

hier wurde ja  viel über das Programmieren an sich diskutiert, Fehlersuche einfacher, Code lesbarer,... und immer wieder gesagt, dass es von der Anwendung abhängt, ob Hochsprache oder SPS-Programmierung besser ist. Wie würdet ihr denn aber anhand der Anwendung entscheiden, was besser ist? Ich studiere noch und habe daher nur begrenzte (Praxis-)Programmiererfahrung, deswegen nur mal ein paar Anfänger-Ideen 

SPS-Sprachen gut, wenn
- Flexibilität nötig (z. B. viele Varianten einer Maschine)
- Code-Änderungen im laufenden Betrieb nötig (Online-Changes)
...

Hochsprachen gut, wenn
- komplexe Berechnungen nötig
...

Warum programmiert man z. B. einen Computertomographen in Hochsprache, während man eine Verpackungsmaschinen- oder eine Windkraftanlagensteuerung in 61131 programmiert?


----------



## S7Graph-Nutzer (19 Januar 2009)

Da hat der Johnnnny aber ein recht altes Thema ausgegraben...

Bei mir ist es meistens AWL; Bausteinaufrufe und Logik mache ich wegen der Übersichtlichkeit in FUP. Wobei es da auch den Nachteil gibt, dass bei großen Netzwerken (z. B. Veroderung von vielen Schrittmerkern für die Ansteuerung eines Aktors) schnell unübersichtlich wird. Da schalte ich dann doch lieber auf AWL um. Für die Schrittketten, die in meinen Programmen fast immer vorkommen, nutze ich natürlich Graph. SCL würde ich gern nehmen, soll in der Firma aber nicht verwendet werden, da angeblich für Instandhalter zu schwierig (aber AWL-Pointerrei mit zig Sprüngen können die lesen? ).


----------



## Mike369 (19 Januar 2009)

Hallo,
also wir haben bei uns in der Lehre mit Ablaufketten angefangen damit man sich besser in das programm einarbeiten kann um nicht die übersicht zu verlieren..
AWL und KOP haben wir nur mal angeschnitten(leider) mach den Fehler nicht sondern zeig ihnen viel in KOP und AWL sonst sind sie später arm dran besonderst weil AWL sehr viel gebraucht wird.
FUP haben wir Hauptsächlich verwendet um Programme zu erstellen..

MfG

Maike


----------



## Ralle (19 Januar 2009)

Maike schrieb:


> AWL und KOP haben wir nur mal angeschnitten(leider) mach den Fehler nicht sondern zeig ihnen viel in KOP und AWL sonst sind sie später arm dran besonderst weil AWL sehr viel gebraucht wird.
> FUP haben wir Hauptsächlich verwendet um Programme zu erstellen..



Was erstellt ihr denn dann mit AWL? 

@S7Graph-Nutzer

Ich denke, SCL und Graph7 werden hauptsächlich deswegen nicht so besonders häufig verwendet, weil man das gesondert kaufen muß *und* es auch nicht zur Standardausbildung/Schulung gehört. Ich habe bisher in 18 Jahren noch *keine* Firma erlebt, die Graph oder SCL vorgeschrieben hätte, im Gegenteil, fast immer war es verboten. Dazu muß ich sagen, daß ich hauptsächlich im Sondermaschinenbau unterwegs bin. SCL fällt, zu meinem Leidwesen, u.a. auch deswegen negativ auf, weil die Debugmöglichkeiten einfach unter aller Sau sind.


----------



## Mike369 (19 Januar 2009)

In der arbeit so ziemlich alles...


----------



## BoxHead (19 Januar 2009)

S7Graph-Nutzer schrieb:


> SCL würde ich gern nehmen, soll in der Firma aber nicht verwendet werden, da angeblich für Instandhalter zu schwierig (aber AWL-Pointerrei mit zig Sprüngen können die lesen? ).



*ACK*

Du sprichst mir aus der Seele.


----------



## Gerri (19 Januar 2009)

wahrscheinlich haben die sich schon desöfteren damit auseinander gesetzt.


----------



## Johnnnny (19 Januar 2009)

Hallo Leute,

danke für die schnellen Antworten. ABER : Über die einzelnen IEC-Sprachen wurde ja vorher schon auf 17 Seiten diskutiert. Meine Frage war bzgl. der Abwägung zwischen Hochsprache und IEC-Sprachen ;-) Nach welchen Kriterien entscheidet ihr, was in einem Anwendungsfall geeigneter ist?


----------



## Ralle (19 Januar 2009)

Johnnnny schrieb:


> Hallo Leute,
> 
> danke für die schnellen Antworten. ABER : Über die einzelnen IEC-Sprachen wurde ja vorher schon auf 17 Seiten diskutiert. Meine Frage war bzgl. der Abwägung zwischen Hochsprache und IEC-Sprachen ;-) Nach welchen Kriterien entscheidet ihr, was in einem Anwendungsfall geeigneter ist?



Ah, ok.

Wenn ich ein Stück Software brauche, daß ich so oder so ähnlich schon habe, verwende ich das wieder, da sich über mehrere Jahre einiges ansammelt und das in AWL programmiert wurde, ist das dann wieder AWL.
Wenn ich ein neues Problem habe, überlege ich, wie groß der Aufwand dafür in AWL oder SCL sein wird. Wenn ich viel mit Daten hin- und herwerfen muß bzw. wenn Strings bearbeitet werden sollen, fällt meine Wahl immer öfter auf SCL. Alles was reines Bitschubsen, also Und- und Oder-Verknüpfungen sind würde ich wohl eher nie SCL nehmen. Allerdings, wenn ich einen Pointer brauche, um 2 Worte in einen DB zu schreiben, muß es nicht extra SCL sein, daher ja die erste Frage an mich selbst --> "Zu viel Aufwand?". Wer nicht gerne mit Pointern arbeitet wird sicher auch da SCL vorziehen.

PS: Aufgaben, die ich in SCL erledige, sollten auch eine eindeutige und klare Funktion haben, so daß sich das wirklich lohnt, einen FC oder FB dafür zu bauen.


----------



## maxi (19 Januar 2009)

vierlagig schrieb:


> GRAPH - ich hab schon mal von leuten gehört, die das einsetzen ...
> SCL - totgeburt oder eierlegende wollmilchsau, bin mir nicht sicher, aber gesehen hab ich davon bis jetzt recht wenig, außer das was ich einsetze ...


 
Hallo Dir,

Graph iist voll Klasse in der Anlagen- und Fördertechnik, leider könne die Instandhalter 0 damit anfangen. Also mag es kein Kunde haben 

SCL ist natürlich das non plus Ultra der Regeltechnik. Ansonsten für den Normalgebrauch wird es meistens bei Compilern eingesetzt. Für also PCS7 und Compilern (Habe letztens auch einen hammer Compiler für Positionierung von Schrittmotoren gesehen) ist SCL echt hammer gut.


----------



## maxi (19 Januar 2009)

Ralle schrieb:


> Ah, ok.
> 
> Wenn ich ein Stück Software brauche, daß ich so oder so ähnlich schon habe, verwende ich das wieder, da sich über mehrere Jahre einiges ansammelt und das in AWL programmiert wurde, ist das dann wieder AWL.
> Wenn ich ein neues Problem habe, überlege ich, wie groß der Aufwand dafür in AWL oder SCL sein wird. Wenn ich viel mit Daten hin- und herwerfen muß bzw. wenn Strings bearbeitet werden sollen, fällt meine Wahl immer öfter auf SCL. Alles was reines Bitschubsen, also Und- und Oder-Verknüpfungen sind würde ich wohl eher nie SCL nehmen. Allerdings, wenn ich einen Pointer brauche, um 2 Worte in einen DB zu schreiben, muß es nicht extra SCL sein, daher ja die erste Frage an mich selbst --> "Zu viel Aufwand?". Wer nicht gerne mit Pointern arbeitet wird sicher auch da SCL vorziehen.
> ...


 
Machst du Anlagen und Fördertechnik auch in SCL?

Rein interesse halber. Grüsse dir


----------



## Ralle (19 Januar 2009)

maxi schrieb:


> Machst du Anlagen und Fördertechnik auch in SCL?
> 
> Rein interesse halber. Grüsse dir



Ich mache nur einzelne Funktionen mit SCL, die mir in AWL zu aufwändig wären. Hatte letztes Jahr eine Anlage, da mußte die SPS Strings handeln, also zerlegen, wieder zusammensetzen usw. dafür hab ich mir ein paar FC/FB geschrieben, die in SCL lächerlich einfach waren, in AWL aber doch schon ein wenig mehr Entwicklungszeit beansprucht hätten.


----------



## Shino (19 Januar 2009)

*Meinung vom Azubi*

Hallo,

also ich bin noch ein Azubi (1 woche noch) und arbeite in der Firma sehr viel mit PCS7 Step 7 und WinCC

Meine meinung ist das in der berufsschule viel zu wenig erklärt wird.

Wir haben Hauptsächlich mit FUB programmiert und sonst nichts anderes.

Wenn ich jeze aber bei uns in der Firma schaue wurde ich vor einen Lappi gesetzt und mir wurde gesagt programmiere ma das in einer SCL-Quelle.

Na toll zum Glück hab ich ein paar grundkenntnisse in C und C++ und da es sich ähnelt kam ich schnell dahinter.

Also ganz ehrliche MEinung von mir:

Ich würde es begrüßen hätte ich in der Berufsschule mehr gelernt als nur FUB. Auch wenn FUB sehr verbreitet ist. Es kann nicht schaden wenigstens Grundkenntnisse in allem zu haben. Oder bzw. in den wichtigsten sachen.

Was man auch auf jeden fall lernen sollte ist HMI. Weil das eigentlich überall ( so auf jeden fall in meiner firma ) vorkommt.

Was bei HMI oder mit dem Arbeiten mit HMI ich persönlich wichtig finde sind die Bildbausteine und Bausteinsymbole. Vor dem Thema sitze ich schon seid wochen und komme einfach nicht weiter. Und das ist kein schönes arbeiten.

Alles noch ma kurz zusammengefasst:

Von allem die Grundkenntnisse erlernen oder halt lehren, weil das Spizial Wissen eignet man sich selbst in der Firma an.

MfG Shino


----------



## derwestermann (19 Januar 2009)

maxi schrieb:


> Hallo Dir,
> 
> Graph iist voll Klasse in der Anlagen- und Fördertechnik, leider könne die Instandhalter 0 damit anfangen. Also mag es kein Kunde haben


 
Ich habe Graph7 gerade bei einem Kunden eingeführt und zwar mit der Proagent-Option auf einem Panel. Der Kunde ist darob der Diagnosefähigkeit so begeistert, daß er das für andere Anlagen auch übernehmen wird.
Naja, ...wenn man Daimler und Audi als kein Kunde bezeichnen will.....
Hier muß ich auch aus EDV-Daten reelle Bewegungen machen, also viele Daten auswerten. Ohne SCL programmierte ich vermutlich jetzt noch.


----------



## Ralle (19 Januar 2009)

derwestermann schrieb:


> Naja, ...wenn man Daimler und Audi als kein Kunde bezeichnen will.....



Ich hab ja von meinen Kunden geredet. Die sind Zulieferer von Diamler und Audi und die wollen das definitiv nicht.
Ich kann auch nicht sagen, daß ich traurig bin, nicht direkt Daimler und Audi und VW als Kunde zu haben, denn deren Standards muß man sich auch erst  mal ordentlich aneignen und soviel ich bisher gesehen habe, sind die nicht immer optimal, geht ja kaum, wenn die für ein rel. breites Spektrum passen müssen.


----------



## easyprivate (20 Januar 2009)

Hallo Achim!

Arbeite in einem großen Chemieunternehmen mit ca 4000 Mitarbeitern...

Wir verwenden hier profibus,winCC,Siemens S7,Wago und FSC von Honeywell....

Handhabung ist da wie folgt... Die S7 wird bei uns in der Abfüllung verwendet (Plastikkugeln die in Säcke abgefüllt werden). Programmiert wird da in FUP...
Leider,denn ich habe damals in der Ausbildung mit ner S5 und nem Programmiergerät in AWL angefangen und fand das lehrreicher ;-)
Die FSC findet man in den Produktionsbetrieben da diese Sicherheitsgerichtet sind. (Redundanz,hat ne S7 zb nicht) Hierbei wird allerdings nur in FUP programmiert...
Mit dem Wagobus realisieren wir Alarmmeldungen von eher "unwichtigen" Dingen wie Beleuchtungs/Heizungsausfall...


----------



## maxi (20 Januar 2009)

easyprivate schrieb:


> Hallo Achim!
> 
> Arbeite in einem großen Chemieunternehmen mit ca 4000 Mitarbeitern...
> 
> ...


 
Ihr habt glaub eine Anlage für die Abfüllung von so Kleberkügelchen in AWL :O)


----------



## Golden Egg (20 Januar 2009)

Hallo Achim,

Kann sein das es schon erwähnt wurde, aber du könntest auch im Unterricht auf Beckhoff und CoDeSys (CoDeSys Automation Alliance) mit eingehen. Wenn du noch Zeit übrig hast. Du findest dazu auch hier im Forum einen eigenen Bereich.

Mfg. Golden Egg


----------



## Backdoor (20 Januar 2009)

Hallo Achim,


Wir programmieren automatische Hochregallager und Fördertechniker und alles was dazu gehört.

Unsere Programme sind ausschliesslich in AWL und FUP, wobei FUP nur ein kleiner Teil ist.

CPU´s von Siemens je nach ANforderung, Kommunikation über Profibus DP und Ethernet.

Hardware: 

Siemens (CPU und CP)
Beckhoff (I/O´s)
SICK (Scanner)
LEUZE (Scanner)
LENZE(FU´s)
usw........




LG BAckdoor


----------



## Backdoor (20 Januar 2009)

Achja hät ich fast vergessen

TP´s und OP´s von Siemens 

und auserdem Pro Tool und WinCC..........


----------



## vierlagig (1 Oktober 2010)

@achim: was is eigentlich aus deinem ambitionierten projekt geworden? ...oder hast du uns nun tatsächlich die ganzen lehrlinge aufgehalst?


----------



## Perfektionist (1 Oktober 2010)

gibts denn den Achim noch? letzer Beitrag: Dez letzten Jahres.
Gut, immerhin letze Aktivität vor drei Monaten ...


----------



## vierlagig (1 Oktober 2010)

Perfektionist schrieb:


> gibts denn den Achim noch? letzer Beitrag: Dez letzten Jahres.
> Gut, immerhin letze Aktivität vor drei Monaten ...



letzteres animierte die nachfrage ... hoffe doch, dass es ihn noch gibt und er vielleicht auch noch lehrt, denn so schlecht war sein ansatz nicht


----------

