# AWL In Kop anzeigen lassen ????



## thony77 (1 Dezember 2007)

Hallo

Ich habe folgendes Problem nach Übergabe einiger Neuen Anlagen, ist mir aufgefallen das sehr viel in AWL Programmiert wurde. 
Ich habe die Anlagen nicht abgenommen!!!!
Nun bin ich nicht der Beste in AWL-Programmierung:???:.
Es klappt natürlich nicht im Programm auf kop umzustellen.......

Und da will ich doch mal fragen ob es nicht andere möglichkeiten gibt (irgendwelche Programme oder andere Dinge vielleicht noch sehr viel einfacher  ???) sämtliche AWL-Programmierungen in Kop Um zu Wandeln???

Danke im Voraus


----------



## Gecht (1 Dezember 2007)

thony77 schrieb:


> sämtliche AWL-Programmierungen in Kop Um zu Wandeln???



Nein, die gibt es nicht.
Um AWL in KOP oder FUP anzeigen zu lassen muss eine bestimmte Syntax eingehalten werden die kein Mensch freiwillig einhält.


----------



## vierlagig (1 Dezember 2007)

Gecht schrieb:


> Nein, die gibt es nicht.
> Um AWL in KOP oder FUP anzeigen zu lassen muss eine bestimmte Syntax eingehalten werden die kein Mensch freiwillig einhält.



dann könnte ich es ja gleich in kop/fup programmieren .. nee, nee, nee


----------



## Gecht (1 Dezember 2007)

vierlagig schrieb:


> dann könnte ich es ja gleich in kop/fup programmieren .. nee, nee, nee



Eben darum.
Ausserdem sind bestimmte Funktionen nur in AWL möglich. Gerade eben nicht das "Übliche".


----------



## vierlagig (1 Dezember 2007)

Gecht schrieb:


> Eben darum.
> Ausserdem sind bestimmte Funktionen nur in AWL möglich. Gerade eben nicht das "Übliche".



jep und durch weggelassene NOP 0 sind wir bei AWL auch schneller unterwegs als üblich


----------



## arcis (1 Dezember 2007)

*Awl <-> Kop*

Das Problem haben wir diesmal auch. 

Ein Kunde kriegt dieses mal den SPS-Source mitgeliefert. Der Krempel wurde halt so verkauft, was tut man nicht alles für den Kunden. Und die wollen das natürlich in KOP, während wir alles in AWL machen.   

Grundsätzlich gilt, dass für eine Ausgabeanweisung  =,  R ,  S , ...  ein  Netzwerk verwendet werden muss. Was schon mal nicht mit unserem üblichen Programmierstil zusammenpasst. 

Ein Anruf bei der Hotline lieferte die Empfehlung, jedes einzelne Netzwerk in AWL zu programmieren und immer wieder die Ansicht nach KOP umzuschalten, um gleich zu sehen, wo es hackt. Und wenn dann mal irgendwas nicht konvertiert werden kann, solle man doch mit NOP und  BLD  Befehlen  rumtricksen. So richtig verstanden haben wir das nicht und so richtig zufriedenstellend ist das alles auch nicht. Der Kunde wird den Grossteil in KOP kriegen, aber bestimmte Teile sind einfach in KOP nicht darzustellen.


----------



## vierlagig (1 Dezember 2007)

arcis schrieb:


> Grundsätzlich gilt, dass für eine Ausgabeanweisung  =,  R ,  S , ...  ein  Netzwerk verwendet werden muss.



na, ob das wohl stimmt? 

z.b.:


```
U E0.7
S M1.0
U E0.8
R M1.0
NOP 0
```

oder:


```
U M1.0
= A2.0
= A2.1
= A2.2
```

die nicht darstellbaren, sind dann wohl nur die in AWL verfügbaren, aber bei solchen code-abschnitten kann man ja eine abgeschlossene funktion bauen, die kann, mit entsprechend ausführlichen kommentar auch gern in AWL sein...


----------



## Larry Laffer (1 Dezember 2007)

Hallo,
es lassen sich viele AWL-Befehlsfolgen auch so eingeben, das sie in KOP und/oder FUP auch darstellbar sind. Das ist meisst kein Problem, wenn man es direkt beim Erstellen des Programms berücksichtigt. Im Nachhinein kann das zur Sissiphus-Arbeit werden - ist aber machbar.

In der Grundlage ist es hier schon genannt worden: Du musst halt an der richtigen Stelle in Verknüpfungen "NOP 0"-Befehle bzw. Klammern einfügen. Da könnte man aber ein Buch darüber schreiben. Da ich viel mit Instandhaltung zu tun hatte/habe weiss ich einige der Befehlsketten:

```
Timer:
U E0.0
L S5T#1s
SE T100
NOP 0
NOP 0
NOP 0
NOP 0
 
oder 
 
U E0.0
L S5T#1s
SE T100
NOP 0
NOP 0
NOP 0
U T 100
= A 10.0
 
oder
 
U (
U E0.0
L S5T#1s
SE T100
NOP 0
NOP 0
NOP 0
)
U E 4.7
= A 10.1
```
 

```
Zähler:
 
U E 0.1
ZV Z10
NOP 0
NOP 0
NOP 0
U E 0.2
R Z10
NOP 0
NOP 0
NOP 0
```
 

```
Vergleicher:
 
U (
L MD 100
L MD 200
>= D
)
= M 10.0
```
 
bei Sprung-Befehlen gibt es grundsätzlich Probleme bzw. es geht gar nicht. Manche Rechen-Operationen, die in AWL machbar sind gibt es in KOP oder FUP gar nicht.

und noch viele mehr ...

Aber wie schon gesagt, wenn du ein vorhandenes Programm daraufhin umarbeiten willst, dann ist das viel Arbeit. Vielleicht solltest du dir doch ein bisschen AWL angewöhnen ...

Gruß
LL


----------



## vierlagig (1 Dezember 2007)

Larry Laffer schrieb:


> bei Sprung-Befehlen gibt es grundsätzlich Probleme bzw. es geht gar nicht.



ich hab damit eigentlich keine probleme...


```
Network C

      U   M0.3
      SPB ende

....

Network Y

ende: U M0.3
      R M0.3
```

funktioniert in KOP, FUP und AWL


----------



## Larry Laffer (1 Dezember 2007)

vierlagig schrieb:


> ich hab damit eigentlich keine probleme...
> 
> 
> ```
> ...


 
   
Sollen wir jetzt versuchen für jedes Beispiel ein Gegenbeispiel zu finden ?
Das von dir genannte Beispiel funktioniert natürlich. Ich habe das ja auch nicht vollkommen ausgeschlossen ...


----------



## vierlagig (1 Dezember 2007)

Larry Laffer schrieb:


> Sollen wir jetzt versuchen für jedes Beispiel ein Gegenbeispiel zu finden ?
> Das von dir genannte Beispiel funktioniert natürlich. Ich habe das ja auch nicht vollkommen ausgeschlossen ...



"grundsätzlich Probleme" ... klingt schon ziemlich ... naja ... endgültig ... aber wir wollen ja nicht spitzfindig sein 

mich würde aber schon interessieren, bei welchen sprungbefehlen du probleme vermutest ... nicht das ich das nächste mal darauf stoße und extra einen thread auf mache...


----------



## Larry Laffer (1 Dezember 2007)

@Vierlagig:
SPL , LOOP ...

darüber hinaus wirst du grundsätzlich Schwierigkeiten haben so manche in AWL erschaffenen Sprung-Konstellationen KOP/FUP-fähig auf x Netzwerke zu verteilen (z.B. bei Schleifen-Bearbeitung). Es ist aber in vielen Fällen durchaus machbar ... ob da aber der Aufwand das Ergebnis rechtfertigt halte ich für fraglich, da man sich da auch schnell das im Moment noch funktionierende Programm abschiessen kann ...

Und dann hätte ich da noch etwas schönes :
Meinst du, dass wenn man das Folgende KOP/FUP-fähig macht man noch ohne weiteres den Sinn dahinter versteht ?

```
U M 100.0
UN M 100.1
SPBN nCnt
 
L MD200
L 1
+D
T MD 200
 
nCnt: U M 100.0
        = M 100.1
```


----------



## vierlagig (1 Dezember 2007)

notiert...danke dafür!


----------



## OHGN (1 Dezember 2007)

Ist zwar ein bischen OT, aber was sind das denn für bescheuerte Kunden, die unbedingt das gesamte Programm in KOP darstellbar haben wollen.???

IMHO sollten solche Auftraggeber sich ihr "verwurschteltes" Programm gleich selber schreiben und nicht professionelle Programmierer mit ihren sehr zweifelhaften Vorgaben nerven.

Ich halte es jedenfalls so, dass ich Kunden mit derlei ominösen Vorgaben rechtzeitig in die Schranken weise, oder den Auftrag ablehne (wenn es noch nicht zu spät ist).:s3:


----------



## Larry Laffer (1 Dezember 2007)

@OHGN:
Der Wunsch des Verfassers ist in gewisser Weise für mich nachvollziehbar.
Ich war selbst mehr als ein Jahrzehnt für die Instandhaltung in einem großen Betrieb verantwortlich. Viele Fehler an den Anlagen liegen irgendwann zwar nicht mehr am Programm, sind aber aufgrund der Komplexität der Anlagen in der Regel nur mit dem Programm zu finden. Hier ist meisstens der Schichtelektriker der Erste vor Ort und der kann zwar oft mit dem PG umgehen, aber versteht in der Regel nur einfache Zusammenhänge (KOP mit nicht zu vielen Parallel-Zweigen). Da ich selber nicht unbedingt Lust dazu hatte, bei auftretenden Störungen immer mitten in der Nacht auszurücken, habe ich dann schon zugesehen, dass die Programme (zumindestens meine eigenen) für die Schichtelektriker so verständlich wie nur möglich waren (Selbstschutz). Und ich muss dir sagen ... wenn man sich da ein bißchen Mühe gibt, dann lässt sich da schon eine Menge erreichen.
So nebenher würde ich mich auch nicht davor scheuen einem externen Programmier vorzuschreiben, wie das Programm auszusehen hat. Die Anderen habe es ja auch viele Jahre bei mir so gemacht und es hat mienen Programmen auch nicht geschadet ...

Gruß
LL


----------



## vierlagig (1 Dezember 2007)

@OHGN

und du gehörst zu den lieferanten die wir nicht gebrauchen können 

nichts gegen AWL, aber für die instandhaltung ist es nicht so einfach zu sehen...

deswegen vertreten wir die philosophie: was geht, wird in KOP gemacht und was in AWL muss, gehört ordentlich kommentiert ... soweit mal grob, wenn da mal ein awl netzwerk dazwischen rutscht, passiert, aber über längere strecken sollte dann doch eine funktion erstellt werden, die in sich abgeschlossen, getestet und ordentlich kommentiert ist ...

grund: nicht jeder schichtelektriker und anlagenverantwortliche ist programmierer, bei der fehlersuche fällt er bei AWL schnell auf die nase


----------



## Larry Laffer (1 Dezember 2007)

... ich habe gerade mal bei Vierlagig ins Profil gelinst ...
und ...
gleicher Job - gleiche Einstellung zu den Dingen.
Ist also was dran und ich stehe da nicht alleine da ...


----------



## MW (1 Dezember 2007)

Larry Laffer schrieb:


> Viele Fehler an den Anlagen liegen irgendwann zwar nicht mehr am Programm, sind aber aufgrund der Komplexität der Anlagen in der Regel nur mit dem Programm zu finden. Hier ist meisstens der Schichtelektriker der Erste vor Ort und der kann zwar oft mit dem PG umgehen, aber versteht in der Regel nur einfache Zusammenhänge (KOP mit nicht zu vielen Parallel-Zweigen). Da ich selber nicht unbedingt Lust dazu hatte, bei auftretenden Störungen immer mitten in der Nacht auszurücken, habe ich dann schon zugesehen, dass die Programme (zumindestens meine eigenen) für die Schichtelektriker so verständlich wie nur möglich waren (Selbstschutz). Und ich muss dir sagen ... wenn man sich da ein bißchen Mühe gibt, dann lässt sich da schon eine Menge erreichen.


 
100% ACK

Für den Programmierer ist es eine Leichtigkeit in AWL oder FUP zu schreiben (KOP lass ich aus Persönlicher Abneigung weg) aber für die Instandhalter nützt ein umfangreiches AWL Programm wenig, wenn es um die schnelle ortung einer Störung geht, denn oftmals verschlingt die Zeit zum Einlesen ins AWL -Programm kostbare Zeit, die man aber bei einer Störung nicht hat. Deshalb ist FUP (meinetwegen auch KOP), je nach Anwendung sinnvoller als AWL. Logisch ist auch, dass dies nicht immer funktioniert.

Bitte jetzt keine Belehrung über die Nachteile von FUP und KOP ---> die kenne ich !!!!!


@vierlagig: Wittstock = Heiligengrabe = Kronotex ????


----------



## Rudi (1 Dezember 2007)

OHGN schrieb:


> Ist zwar ein bischen OT, aber was sind das denn für bescheuerte Kunden, die unbedingt das gesamte Programm in KOP darstellbar haben wollen.???
> 
> IMHO sollten solche Auftraggeber sich ihr "verwurschteltes" Programm gleich selber schreiben und nicht professionelle Programmierer mit ihren sehr zweifelhaften Vorgaben nerven.
> 
> Ich halte es jedenfalls so, dass ich Kunden mit derlei ominösen Vorgaben rechtzeitig in die Schranken weise, oder den Auftrag ablehne (wenn es noch nicht zu spät ist).:s3:


 
Hoffentlich findest Du auf Dauer noch Kunden. Hast sicher keine eigene Firma ?


----------



## Jo (1 Dezember 2007)

@Larry,

```
NW: Larrys Code in KOP übersetzbar (Ctrl+1)

      U(    
      U     M    100.0
      UN    M    100.1
      SPBNB _00b
      L     MD   200
      L     1
      +D    
      T     MD   200
      UN    OV
      SAVE  
      CLR   
_00b: U     BIE
      )     
      U     M    100.0
      =     M    100.1

NW: kürzerer Code, auch übersetzbar

      U     M    100.0
      FP    M    100.1
      SPBNB _013
      L     MD   200
      L     1
      +D    
      T     MD   200
_013: NOP   0
```
ich gebe zu, dass der obere Code in AWL schrecklich aussieht, aber in KOP/FUP für jeden Wartungselektriker verständlich sein sollte.
Ich will jetzt nicht wieder den Glaubenskrieg lostreten, habe dazu bisher auch immer geschwiegen, aber die "Superprogrammierer", für die nur AWL das Wahre ist, sind oft so super nicht.
Liefervorschriften sind  kein Selbstzweck und dort wird nicht ohne Grund meist FUP verlangt.
mfG. Jo


----------



## Markus (1 Dezember 2007)

zum thema:
sollte es sich um s5 handeln, dann kann ich dir accon-s5 von deltalogic empfehlen, die software ist relativ unempfindlich was die syntax zur umwandlung angeht.


@die kopgeilen
ich sehe das genauso wie ohgn
ich programmiere nur in awl und scl, selbst wenn es jemand von mir verlangen würde, ich könnte es nicht in kop. da gehen weder schleifen noch indirekte adressierung und diese dinge verwende ich generell...

als ich noch in der instandhaltung war fand ich awl auch grausam.
das lag aber daren das ich mit meinen lächerlichen sps kenntnissen furchtbares fup programmiert habe und die ansicht auf awl gestellt habe - der awl code war dann wirklich zum kotzen...

aber wenn direkt in awl geschrieben wurde kann man sehr schönen code mache, man hat viele informationen auf display ohne wie ein irrer überall hinzuscrollen und kann sauber zeilenweise kommentieren.

in kop und fup kann man ja praktisch garnicht kommentieren.

ich finde mein awl wesentlich instandhaltungfreundlicher!
und ich hatte damit auch bei keinem kunden probleme.

abgesehen daon wüsste ich nicht was ein instandhalter mit einem pg an meinen anlagen verloren hat, ich lege wert auf eine anständige visu über die alles parametriert und diagnostiziert werden kann. ich mache den jungs nichteinmal ein display auf die fu das geht alles komfortabel über die visu...

vielleicht sollten bestimmte eingefahrene instandhalter einfach mal etwas offener sein und die pilosophie die hinter der steuerungstechnik des lieferanten steckt versuchen zu verstehen - man kann dadurch nur dazulernen...


----------



## OHGN (1 Dezember 2007)

vierlagig schrieb:


> @OHGN
> 
> und du gehörst zu den lieferanten die wir nicht gebrauchen können


Lieber Kollege Vierlagig, seien Sie versichert, dass wir mit 100% Wahrscheinlichkeit nie zu Ihren Lieferanten gehöhren werden, auch wenn unser Firmensitz garnicht alzuweit von Wittstock entfernt ist.

Was ich sagen will ist, und dazu stehe ich auch, dass für mich die korrekte Funktion einer Anlage im Vordergrund steht, egal auf welchem Wege und mit welchen Hilfsmitteln sie programmiert worden ist. 
Soillten irgendwelche "Schichtelektriker" oder andere Leute mit meinem/unserem Programmierstil nicht klarkommen, gibt es immer noch die Möglichkeit mich/uns telephonisch zu kontaktieren und bei Problemen gemeinsam Lösungswege zu finden. Bis jetzt jedenfalls hat diese Herangehensweise mit unseren Kunden tadellod geklappt.

*Tipp:* Versuch doch mal der Firma Microsoft, deren Produkt Du ja sicherlich täglich nutzt, den Programmierstil und die Programmiersprache für die Erstellung von MS-Windows vorzuschreiben. Auf das Ergebnis bin ich mal gespannt.....

Um das alles was ich eben geschrieben habe etwas zu relativieren sei allerdings gesagt, dass die typischen *"Greifer hin und Greifer her"* bzw. *"Rundtakttisch, Eimerketten und was weis ich noch was für Steuerungen"* nicht zu unserem Aufgabenspektrum gehöhren (vielleicht bräuchte man ja dazu auch KOP).

Ansonsten bleibe ich dabei: An von mir programmierten Anlagen haben reine KOP-Elektriker nichts zu suchen....


----------



## vierlagig (1 Dezember 2007)

1. such mir die mitarbeiter nicht aus, die sind da und da kann ich auch nichts dran ändern, will ich auch nicht, das gehört nicht in meinen aufgabenbereich

2. nicht jeder lieferant, der steuerung und visualisierung liefert, stimmt beides so aufeinander ab, dass man zur fehlersuche nur mit der visualisierung arbeiten kann und selbst wenn da dann ein fehler detektiert werden kann, bieten die wenigsten visualisierungen, wohl auch aus sicherheitsgründen, die möglichkeit ein signal temporär, z.b. zum frei fahren, zu "brücken"

3. ich bin nicht ausschließlich KOPler, mit AWL kann ich eben soviel anfangen und markus, ja, in AWL kann man wesentlich schöner kommentieren und ich bin auch dafür, dass das vom lieferanten auch genutzt wird

4. ich brauch den quellcode von microsoft-produkten nicht verstehen, da ich an meinem system keine umbauten, erweiterungen, optimierungen in dem sinne durchführen möchte

5. manchmal ärger ich mich wirklich über die programmier-götter und snobs in diesem forum, wann kommt bei euch endlich an, erlaubt ist was a) gefällt und funktioniert und b) praktikabel ist, für entwickler und endkunde

(wir reden hier nicht von kinderspielzug alá drei förderbänder in reihe, die bißchen komfortabler an- und abfahren sollen, es geht hier um produktionsstrecken, deren stillstand mehrere 10.000€/h kostet und da sollte das elektrische betriebspersonal fehler so schnell wie möglich aufspüren und beheben oder, bei bedarf und sicherheitstechnischer vertretbarkeit, überbrücken können)


----------



## Pizza (1 Dezember 2007)

*Vorderung KOP - wer macht denn sowas ??*

Wieder mal eine Grundsatzdiskusion.
Also ich bin einer von denen, die später mit den Anlagen leben müssen (Instandhaltung)
Aber grundsätzlich KOP als Vorgabe ??

Ordentlich strukturiert und dokumentiert sind mir AWL tausendmal lieber als diese Malerei in FUP/KOP.

Wir haben hier eine Anlage (die, die auch die Einzeladerbeschriftung so lieben) wo fast ausschließlich in FUP programmiert wurde.
Damit das Ganze darstellbar ist, wurde jedesmal am Anfang ein Merker "stat_Eins" verknüpft und dann mit Verzweigungen weitergeführt.
Die Netzwerke sind nun so gross, dass es garnicht mehr auf den Bidschirm passt.
Tolle Sache, wenn man ständig am hin- und her-scrollen ist.

Ich würd sagen: Netzwerke in FUP/KOP ja(da wo es Sinn macht)
ansonsten AWL (da kann ich viel mehr und besser kommentieren).

P.S. Instandhalter, die nur KOP lesen können, machen mir Angst:???:


----------



## MW (1 Dezember 2007)

Markus schrieb:


> aber wenn direkt in awl geschrieben wurde kann man sehr schönen code mache, man hat viele informationen auf display ohne wie ein irrer überall hinzuscrollen und kann sauber zeilenweise kommentieren.
> 
> ich lege wert auf eine anständige visu über die alles parametriert und diagnostiziert werden kann. ich mache den jungs nichteinmal ein display auf die fu das geht alles komfortabel über die visu...


 
JA so machst du es, so soll es ja auch sein. Dann kann man auch verstehen, dass dich kein Kunde anrufen muss. 

Aber es gibt noch genug schwarze Schaffe, die der Meinung sind, sie können in der SPS machen was sie wollen, sprich: Komplett Komentarlos oder so caotisch geschrieben dass keiner durchblickt:twisted: :twisted:

Edit:
Ich muss eindeutig schneller Schreiben

@Vierlagig = Kronotex ???


----------



## OHGN (1 Dezember 2007)

Rudi schrieb:


> Hoffentlich findest Du auf Dauer noch Kunden. Hast sicher keine eigene Firma ?


Ja, Kunden haben wire schon...  Und die sind auch alle zufrieden mit uns, weil sie begriffen haben worauf es letztendlich ankommt!

Aber Ihr könnt Euch meinethalben allesamt wegen der Gunst Eurer Kunden im Dreck wälzen! Wenn Ihr sie nicht von der Qualität Eurer Software überzeugen könnt...... mir doch egal! :s3:


----------



## vierlagig (1 Dezember 2007)

MW schrieb:


> @Vierlagig = Kronotex ???



...ply

die osb-schiene von krono


----------



## zotos (1 Dezember 2007)

Also ich glaube ja nicht daran das die Instandhaltung da wirklich die Ursache ist. Viel schlimmer sind doch die Programmierer die dann lächeln und sagen das sie das ja schon immer so machen. Also dann kommt es eben auch dazu das man in neuen Anlagen so Relikte wie Schmiermerker und Co. 

Ich glaube auch nicht das es die Instandhaltung in der Firma eine Gute Position hat wenn sie als Technologiebremse da stehen.

Es ist einfach schön wie sozial der Hochtechnologie Standort Deutschland ist. Man orientiert sich immer an den Schwachen. 

Statt gute Leute in der eigenen Firma groß zu ziehen oder eben einzukaufen Spart man an der Ecke. Anstatt eine Firma mit Kompetenz zu beauftragen die eine Moderne Anlage liefert mit sehr guter Diagnose (in der Visu). Wird lieber eine Firma beauftragt die da sowas in KOP und ohne ausreichende Fehleranalyse liefert. Oder sie Kaufen bei den Italienern irgend einen Schrott den eh keiner kapiert. 

Es gibt genügend Länder die auf Deutsche Technik setzen. Der Maschinen und Anlagenbau brummt. Nur die Kunden sind eben nicht mehr so oft in Deutschland.

Dann spart euch eben arm ;o)


----------



## OHGN (1 Dezember 2007)

@ZOTOS:
Und deswegen fordern die Kunden KOP ???


----------



## vierlagig (1 Dezember 2007)

@zotos: wenn man mal das betriebspersonal und die instandhalter in die planung und entscheidungsfindung einbeziehen würde...
am ende geht es um den preis und da wird bei den verantwortlichen eben gespart wo es geht, koste es was es wolle...


----------



## zotos (1 Dezember 2007)

OHGN schrieb:


> @ZOTOS:
> Und deswegen fordern die Kunden KOP ???


Ein Kunde der ausschließlich KOP zulässt hat:
1. Weiterbildungsresistentes Instandhaltungspersonal.
2. Zulieferer die es entweder nicht besser können oder eben dem Kunden Technologisch nicht überzeugen können.

Wenn beides Zusammen kommt Läuft die Firma noch so wie es die Vorgaben aus den 80ziger Jahren vorgesehen haben.

Dann lügen sie sich noch in die Tasche das alles super ist. Das die Stillstandszeiten höher sind als bei der Konkurrenz die auf moderne Steuerungstechnik setzen.


----------



## vierlagig (1 Dezember 2007)

zotos schrieb:


> Ein Kunde der ausschließlich KOP zulässt hat:
> 1. Weiterbildungsresistentes Instandhaltungspersonal.
> 2. Zulieferer die es entweder nicht besser können oder eben dem Kunden Technologisch nicht überzeugen können.
> 
> ...



du bist ausschließlich zulieferer? schon immer gewesen? ... auf der anderen seite sieht es anders aus...wie ich in dem post zuvor schon beschrieb... sicher, deine 2 punkte können durchaus zutreffen aber vergiss nie die geschäftsführung und den einkauf und wenn da ein zulieferer kommt und sagt: "wir bauen euch die selbe anlage wie die, aber für den halben preis" da wird nicht nachgefragt ob die denn auch entsprechend liefervorschriften ausstatten, nö, die haben dann narrenfreiheit...die folgekosten sind zu dem zeitpunkt ganz weit weg...


----------



## zotos (1 Dezember 2007)

vierlagig schrieb:


> du bist ausschließlich zulieferer?
> ...



Ja und ja und die Firma für die ich tätig bin hat die besten Kunden der Welt.

Ich kenne dieses Gejammer auch nur hier aus dem Forum. Also ich hatte mal einen Job in einem Ing. Büro wo der Kunde schreckliche Vorgaben gemacht hat. Allerdings war der Kunde auch der Anlagenbauer und der Programmiert halt schon immer so. Das ist wie die Dorfkneipe die schon immer die selbe Tapete hat und sich wundert das die Gäste aussterben. 
In der Bude war ich aber auch nicht lange.

Nur damit kein falscher eindruck entsteht ich finde AWL grausamer Schrott und finde das man es locker durch ST/SCL ersetzen kann.
Bei Bitverknüpfungen finde ich FUP sehr schön und wenn es jemand lieber in KOP mag dann soll er es in KOP schreiben (explizit nicht malen).

Nerven tut mich nur das Gejammer (hier im Forum) das die Instandhalter überfordert sind und darum muss alles so sein wie 1988 als die Welt noch in Ordnung war.


----------



## vierlagig (1 Dezember 2007)

zotos schrieb:


> Nerven tut mich nur das Gejammer (hier im Forum) das die Instandhalter überfordert sind und darum muss alles so sein wie 1988 als die Welt noch in Ordnung war.



88 hab ich noch mit autos und bauklötzen gespielt...ja, da war alles besser 

aber mal ernsthaft: wieviele instandhalter abseits des forums kennst du? haben diese keine probleme mit entscheidungen, auf die sie keinen einfluß haben? ... dann würde mich interessieren wo die arbeiten, ich will auch ins paradies und auch in AWL programmieren, wo ich es für sinnvoll halte...


----------



## Pizza (1 Dezember 2007)

vierlagig schrieb:


> @...wenn man mal das betriebspersonal und die instandhalter in die planung und entscheidungsfindung einbeziehen würde...
> am ende geht es um den preis und da wird bei den verantwortlichen eben gespart wo es geht, koste es was es wolle...


 
ja, leider ist es so 
Also, ich geb ja auch meine Wunschlisten beim Chef auch ab
Welche Hardware und Fabrikate sollen verwendet werden u.s.w.( richte mich nach den vorhandenen Anlagen, um den Ersatzteilbestand nicht unnötig aufzublähen)
Was davon am Ende übrig bleibt, entscheiden leider andere:twisted: 

Ich bin nicht der SPS-Guru, irgendwie kann ich mir nicht vorstellen, einem SPS-Programmierer vorzuschreiben wie er zu arbeiten hat.
Vorausgesetzt die Dokumentation stimmt.

Aber, wieso haben soviele Leute Probleme mit AWL  

Zu meiner SPS-Ausbildung wurde damals immer wieder auf AWL gepocht.
Gut es wurde gleichberechtigt mit FUP und KOP behandelt.
Aber irgendwie hat man gleich die Vorzüge von AWL kennengelernt.

Muss aber kleinlaut zugeben, dass es bei uns in der Firma ettliche Leute gibt, die nichts mit AWL anfangen können.
Als Einstellungskriterium hieß es damals "SPS-Kenntnisse erwünscht"
Leider stellte sich bald heraus, dass sich diese Kenntnisse auf "Sicheres finden der SPS im Schaltschrank" bis hin zu Äußerungen wie "Warum kann der blöde Programmierer nicht in FUP programmieren" beschränken.

Wenn ich dann höre, Kollege XY war gestern mit dem PG an der Anlage (Angst)

Ich versuche nun hausinterne Weiterbildung durchzuführen.
Mal sehen was bei rauskommt.


----------



## Question_mark (1 Dezember 2007)

*Immer schön flexibel sein*

Hallo,



			
				Vierlagig schrieb:
			
		

> es geht hier um produktionsstrecken, deren stillstand mehrere 10.000€/h kostet und da sollte das elektrische betriebspersonal fehler so schnell wie möglich aufspüren und beheben oder, bei bedarf und sicherheitstechnischer vertretbarkeit, überbrücken können



Um dann mal wieder ein bißchen Feuer unter dem Kesselchen zu machen : An solche Anlagen sollte man keine KOP-Programmierer heranlassen  

Bei den Kosten für einen Anlagenstillstand rentiert sich ein qualifiziertes, gut bezahltes Wartungspersonal sehr schnell ...
Die haben dann auch kein Problem mit AWL, SCL und Co.
Wer natürlich beim Einkauf der Anlage 25% spart und dafür sich mit unkommentierten, italienischen Spaghetti-Code vergnügen darf, zahlt dies später mit barer Münze an Instandhaltungs- und Wartungskosten mehrfach wieder drauf (auch wenn die Instandhalter noch so gut sind). Wenn ich höre, dass der Maschinenlieferant und das SPS-Programm aus Italien kommt, ducke ich mich weg und haue ab  
Geht doch nichts über jahrelange Erfahrung.



			
				Markus schrieb:
			
		

> ich lege wert auf eine anständige visu über die alles parametriert und diagnostiziert werden kann. ich mache den jungs nichteinmal ein display auf die fu das geht alles komfortabel über die visu...



Du hast ja recht, ist auch meine Philosophie. Ich bemühe mich immer, dass der Instandhalter sein Programmiergerät nicht aus dem Schrank holen muss. Dieses Streben nach der (möglichst) perfekten Programmierung (also SPS und Visu) erledigt sich aber meist bei der Auftragsverhandlung, da werden dann eben Abstriche gemacht. Ist aber zum Glück nicht immer so   
Da ich meine Kunden schon viele Jahre kenne und einschätzen kann, orientiere ich mich immer etwas bei den Kenntnissen des Wartungspersonals, da kommt dann bei mir schon mal FUP (mit etwas unvermeidlichem AWL), meistens AWL oder auch schon mal SCL heraus. Aber niemals KOP ....

Immer schön flexibel sein, aber keine unvertretbaren Kompromisse eingehen.

Gruß

Question_mark

PS : Und mit breitem Grinsen muss ich gestehen : wenn ich FUP abliefere, dann habe ich den in AWL unter Berücksichtigung der entsprechenden Syntax erstellt.  
PPS  : Und den Menüpunkt zur Umstellung der Darstellung AWL, FUP, KOP kennen die KOP-Progammierer sowieso nicht ....


----------



## vierlagig (1 Dezember 2007)

Question_mark schrieb:


> Um dann mal wieder ein bißchen Feuer unter dem Kesselchen zu machen




zu spät...also zumindest für mich, man kann nicht ständig die grundsätze diskutieren... und es ging hier übrigens nicht um KOP-programmierer, hat sich in der form, glaub ich auch keiner geoutet (übrigens kann man zwischen KOP und FUP problemlos umschalten, also wenn dir KOP nicht gefällt, dann schau es dir in FUP an) ... eins noch: als sps-programmierer sollte man alle sprachen verstehen und die vor- und nachteile von allen kennen und auch um den nutzen, außerhalb des warmen büros wissen... so, gute nacht!


----------



## Question_mark (1 Dezember 2007)

*Ohh, nneeee*

Hallo,



			
				Vierlagig schrieb:
			
		

> zu spät...also zumindest für mich, man kann nicht ständig die grundsätze diskutieren... und es ging hier übrigens nicht um KOP-programmierer, hat sich in der form, glaub ich auch keiner geoutet



Auch über Grundsätze kann man diskutieren, oder sind die bei Dir so festgemeißelt und unverrückbar ? Wenn man 30 Jahre die gleichen Fehler macht, ist das dann Erfahrung ? Ich habe eigentlich aus dem Fred letztendlich herausgelesen, dass die Qualität einer Software in Richtung Funktionalität wichtig ist (siehe Beitrag von Markus) und auch die Qualität der Software in Richtung Wartungsfreundlichkeit für das Instandhaltungspersonal beim Kunden (und das war eigentlich der überwiegende Teil der Beiträge). Und dazu gehört auch die Wahl der Programmiersprache und der Darstellungsart, damit muss letztendlich der Instandhalter klarkommen. Und daraus definiert sich eben Qualität der Software in Anpassung an die Gegebenheiten des Servicepersonals beim Kunden. Wenn Du da was anderes verstanden hast oder anderer Ansicht bist, ist mir auch egal.



			
				Vierlagig schrieb:
			
		

> (übrigens kann man zwischen KOP und FUP problemlos umschalten, also wenn dir KOP nicht gefällt, dann schau es dir in FUP an)



Auch wenn Dir mein Post nicht gefallen hat, lies Ihn doch einfach mal durch, vor allem unter PPS. Nicht jeder hat die Gabe, Ironie zu erkennen, darum der kleine Hinweis.

Gruß

Question_mark


----------



## Question_mark (2 Dezember 2007)

*Mensch, watt bin ick doof ...*

Hallo,



			
				Vierlagig schrieb:
			
		

> programmierer sollte man alle sprachen verstehen und die vor- und nachteile von allen kennen



Ich bin so bescheiden : Ich kenne nicht alle Sprachen und Programmiersprachen, ich kann nur den Hut ziehen wenn ich jemanden treffe, der das alles beherrscht. Ist mir bis jetzt aber noch nicht passiert.
Übrigens, Waldy sucht noch einen Job ...

Gruß

Question_mark


----------



## MW (2 Dezember 2007)

Was nicht alles aus so einer simplen Frage werden kann, dass war(ist) ja malwieder ne schöne Grundsatzdiskusion geworden.


----------



## Zefix (2 Dezember 2007)

MW schrieb:


> Was nicht alles aus so einer simplen Frage werden kann, dass war(ist) ja malwieder ne schöne Grundsatzdiskusion geworden.


Kann man gerne weiterführen ..
Zur IH Aufklärung:

Jungs, ich bin jetz auch schon ein paar Jährchen in der IH.
Anfangs war noch S5, als ich hier einsteigen wollte kam bei uns S7...
Durch guten Zufall kam ich günstig privat zu ner 315-2DP, nur was tun ohne EA.. ok Ebay. Mittlerweile hab ich fast über nen Meter  EA zu Hause. Hab heute "fast" keine Probleme mit eurem Drecks AWL.(Kann hier auch sagen ihr seid bei S5 stehen geblieben IHR PENNER  ).

Meiner Meinung und dem des Stils unserer Progger Firma passt KOP ganz gut, da auf den ersten Blick erkennbar welches "bit" fehlt.
nur mal so als Beispiel.
Ich hab zwischendurch auch mal mit Neulingen zu kämpfen, gebt es zu, wer von euch hätte euren AWL Code kurz nach der Lehre schon verstanden? Vielleicht noch ein paar Schleifen und Pointer dazu?
Ich kann die AWL Scheisse die IHR immer noch abliefert wenigstens noch lesen, aber schreiben will ich diesen mist nicht.
Strukturiert eure Daten usw. sauber lässt sich vieles easy mit Kop usw. ausführen, wenns sein muss auch mal ein zwei drei Netzwerke mit AWL, aber mehr nicht.
Bevor ich mit Pointern und AR rumscheiss mach ich gleich SCL auf.
Mit gut Strukturierten Daten bzw. DBs liest sich das hingegen wie eine Bettlektüre.


Euer Drecks AWL geheule kann hier langsam keiner mehr hören.
Wenn einer Auf S5 oder schlimmer s3 Zeiten stehen geblieben ist dann ist das die AWL PRO Fraktion hier.
Sorry, aber wenn sich einer zu schön für Kop/fup ist der hat seinen Beruf verfehlt.

Und noch was , wer Zahlt schafft an , fertig. Wer zu "doof "für KOP ist, ist grad genug für Hartz IV. Entweder Ihr wollt "Programmierer" sein und beherscht alles oder Ihr lasst die Finger weg und geht putzen oder Lampen wechseln. 

Und kommt mir nicht mit UG, der Penner meint auch er hat die Weisheit mit der Schaufel gefressen...die hau ich ihm auch gern drüber.

Übrigens, seit Freitag als "dummer" IHler Urlaub bis 2.1.08 hab  
Schöne Weihnachten und guten Rutsch


----------



## arcis (2 Dezember 2007)

*+*

@ vierlagig



> na, ob das wohl stimmt?


Stimmt, meine Formulierung war nicht genau genug.

Also alles was prinzipiell ausschaut wie

U M2.0
U M1.0
R M1.1
R M1.2
= M1.3

muss in genau ein Netzwerk.


----------



## arcis (2 Dezember 2007)

*+*

Ich kann Euch auch sagen, wo der ganze elende KOP Zinnober herkommt.

Wir haben in den letzten Jahren vermehrt Anlagen nach Asien geliefert und als SPS
Mitsubishi vorgeschrieben bekommen. Die AWL von Mitsubishi ist der letzte Mist. 
Das kann wirklich keiner verstehen. Es gibt keine Klammern und wie das VKE in 
etwas komplizierteren Ausdrücken weitergerreicht wird, ist absolut undurchschaubar. 
Mitsubishi kann man nur in KOP proprammieren. In ganz Asien werdet ihr höchstens
5 SPS Programmierer finden, die Mitsubishi in AWL programmieren. Der Rest macht 
KOP. Ich habe keinen gesehen, der AWL programmiert.

Und man kann in KOP genauso undurchschaubaren, unstrukturierten Code fabrizieren, 
wie in AWL. Das ist nicht eine Frage von KOP oder AWL, sondern eine Frage der
Fähigkeiten des Programmierers.


----------



## Zefix (2 Dezember 2007)

```
m2.0   m2.1     m1.2
--| |----| |--|---(R)
              |  m1.2
              |---(R)
              |  m1.3
              |----()
```
 
So oder?

Klar du kannst KOP noch schlimmer Scheisse Programmieren,
aber du siehst wenigstens die scheisse auf einen Blick ;-)


----------



## Oberchefe (2 Dezember 2007)

> Wenn ich höre, dass der Maschinenlieferant und das SPS-Programm aus Italien kommt, ducke ich mich weg und haue ab


 
Also da gibt's auch fähige Leute, die wunderbaren Code abliefern. Da habe ich schon wirkliche gute Programme gesehen. Vielleicht nicht in AWL, aber das mag ich sowieso nicht. Ich bevorzuge die folgende Reihenfolge:

1. KOP (aber nur in Verbindung mit vernünftiger Programmiersoftware, d.h. z.B. Rockwell, kein Codesys/S7)
2. Strukturierter Text
3. FUP
4. AWL


----------



## MSB (2 Dezember 2007)

@arcis
Ich spreche hier jetzt vor allem für den GX-Developer, NICHT den IEC-Dev.
Mitsubishi AWL gehört imho zu den besten Programmiersprachen die ich bisher im SPS-Bereich kennengelernt habe.
Nur weil du dich nicht genug damit auseinander gesetzt hast, kannst du das nun nicht Mitsubishi zum Vorwurf machen.
Ist aber letzten Endes auch egal, da AWL und KOP im Unterschied zu Siemens zu 100% umschaltbar ist.


An die Instandhalter hier (Das gilt jetzt mehr für die Siemens-Schiene):
Bei Digitalgeschichten sollt ihr ja meinetwegen KOP haben, da habe ich persönlich kein Problem damit,
zumal da auch die Übersetzungsfunktion meistens kein Problem darstellt, und ich es da mit question-mark halte, ich Code AWL so, dass es übersetzbar ist.
Aber so sachen wie Berechnungen, Zähler ... werde ich persönlich NIE in KOP machen.
Irgend ein wie auch immer geartetes Datenhandling: Never in KOP,
jedenfalls solange KOP bei Siemens nich ähnlich umfangreich wie z.B. bei Allen Bradley ist.

Also wenn eure Anlagen mit reinen Digitalverknüpfungen auskommen, könnt ihr auch auf KOP bestehen.

P.S. Scheiße ist immer alles, das den eigenen Horizont sprengt,
oder vom gewohnten abweicht.

Wenn man dann auf die zeitgemäßeste Sprache wechselt, nämlich SCL/ST, dann passt das ja auch wieder keinen Instandhalter,
zumindest nicht denen, die sich bei solchen Themen immer so zu Wort melden,
ich persönlich kenne andere.

Mfg
Manuel


----------



## vierlagig (2 Dezember 2007)

muss ich da jetzt humormäßig irgendwie reagieren, wenn hier auf instandhaltern rumgehackt wird


----------



## MSB (2 Dezember 2007)

Wenn du zu der "Ich will KOP um jeden Preis - Fraktion" gehörst, evtl.
Ansonsten kannst du das als etwas offener Instandhalter getrost ignorieren.

Siehe hier: " ich persönlich kenne andere."

Mfg
Manuel


----------



## vierlagig (2 Dezember 2007)

MSB schrieb:


> Wenn du zu der "Ich will KOP um jeden Preis - Fraktion" gehörst, evtl.
> Ansonsten kannst du das als etwas offener Instandhalter getrost ignorieren.




"etwas offener" *lach* ...klingt nicht schlecht ... mit mitte 20 ab ich keine probleme mit neuem und auch nicht damit älteren semestern die technik zu erklären


----------



## Onkel Dagobert (2 Dezember 2007)

Zefix schrieb:


> ..Übrigens, seit Freitag als "dummer" IHler Urlaub bis 2.1.08 hab  ..


Einer meiner Kollegen sagt immer "Stell dich frühs für fünf Minuten dumm, und du hast den ganzen Tag lang deine Ruhe". Nun, KOP und FUP werde ich mir mal genauer ansehen, vielleicht hilft's  . Bei mir ist leider nichts mit Urlaub.

Ich habe in diesem Jahr den Umbau einer FUP-programmierten Anlage verweigert. Unzählige Netzerke, keine Kommentare, keine Dokumentation, keine Übersicht. Wenigstens war der Kunde so fair, mir das Programm vor der Abgabe eines Angebots zu zeigen. Man hat mit Step7 sehr viele Möglichkeiten, richtig schöne Scheiße zu programmieren. Das schafft man sowohl mit FUP, KOP, SCL als auch mit AWL.

@Zefix
Schönen Urlaub! Vielleicht findest du eine ruhige Minute, um dich weiter zu bilden, du PENNER.


Gruß, Onkel


----------



## Perfektionist (2 Dezember 2007)

Die Argumente und Standpunkte hier kommen mir alle reichlich bekannt vor ... :???: 

also:
 L AWL
 T Perfektionist
bitte in KOP/FUP wandeln ...  

in meinen Programmen kommen übrigens keine Klammern vor, dafür werden Zwischenergebnisse mal als Temp zwischengespeichert, was meiner Meinung nach bei geeigneter Benennung der Temp-Variablen die Lesbarkeit stark erhöht.

Ansonsten ist m.E. eine Maschine/Anlage, zu deren Betrieb regelmäßig ein PG erfoderlich ist, von vorneherein Sch... ähhh BRAUN, unabhängig von verwendeter Steuerung und verwendeter Programmiersprache.


----------



## Onkel Dagobert (2 Dezember 2007)

Hallo Perfektionist,



Perfektionist schrieb:


> L AWL
> T Perfektionist
> bitte in KOP/FUP wandeln ... ..


Geht denn das?

Gruß, Onkel


----------



## arcis (2 Dezember 2007)

*+*

@ MSB



> Ich spreche hier jetzt vor allem für den GX-Developer, NICHT den IEC-Dev.
> Mitsubishi AWL gehört imho zu den besten Programmiersprachen die ich bisher im SPS-Bereich kennengelernt habe.


Und warum programmiert dann keiner in Asien mit der Mitsubishi AWL? Selbst in den
Handbüchern von Mitsubishi, wenn es um Programmbeispiele geht, wird fast ausschliesslich KOP verwendet.


----------



## MSB (2 Dezember 2007)

Die etwas neueren Handbücher bei Mitsubishi beziehen sich von der Optik her meistens auf den IEC-Dev.
Zugegebenermaßen hat sich da der AWL-Editor gegenüber dem normalen Dev. extrem verschlechtert.
KOP im normalen Dev. ist meines erachtens so gut wie nicht anwendbar,
auf jeden Fall furchtbar umständlich.

Mfg
Manuel


----------



## Perfektionist (2 Dezember 2007)

Onkel Dagobert schrieb:


> ...
> Geht denn das?
> ...


weiß nicht, kann nur AWL - deswegen frag ich ja


----------



## zotos (2 Dezember 2007)

Perfektionist schrieb:


> ...
> Ansonsten ist m.E. eine Maschine/Anlage, zu deren Betrieb regelmäßig ein PG erfoderlich ist, von vorneherein Sch... ähhh BRAUN, unabhängig von verwendeter Steuerung und verwendeter Programmiersprache.



Dafür ein 100% Ack.

Aber folgendes:


Perfektionist schrieb:


> weiß nicht, kann nur AWL ...


Glaube ich Dir nicht.

Wie ich auch bei einigen Kollegen hier gelesen habe nutze ich nach Möglichkeit eine Mischung. Für jede Aufgabe das richtige Werkzeug. 

Aber AWL empfinde ich als persönlich als eine überholte Sprache. Wobei es m.E. eben an dem großen S liegt. Das 1. SCL schlecht implementiert ist und 2. nur für professionelle Anwendungen gedacht ist da es in den unprofessionellen Versionen vom Sepp7 ja nicht vorhanden ist.


----------



## Perfektionist (2 Dezember 2007)

zotos schrieb:


> ...
> Aber AWL empfinde ich als persönlich als eine überholte Sprache. Wobei es m.E. eben an dem großen S liegt. Das 1. SCL schlecht implementiert ist und 2. nur für professionelle Anwendungen gedacht ist da es in den unprofessionellen Versionen vom Sepp7 ja nicht vorhanden ist.


 
darf ich nachhaken? ich hab ja als unprofessioneller kein SCL ...  

inwiefern schlecht implementiert?

was denkt Siemens, was eine (un-)professionelle Anwendung ist?


----------



## Solaris (2 Dezember 2007)

darf ich auch mal fragen:

  zozos: in den unprofessionellen Versionen vom Sepp7


was ist Sepp7 und welche Versionen sind davon unprofessionell?


----------



## marlob (2 Dezember 2007)

Solaris schrieb:


> darf ich auch mal fragen:
> 
> zozos: in den unprofessionellen Versionen vom Sepp7
> 
> ...


Die Frage ist nicht ernst gemeint, oder?


----------



## Solaris (2 Dezember 2007)

Heute ist Sonntag, darf man da nich auch mal was unernstes fragen?


----------



## marlob (2 Dezember 2007)

Solaris schrieb:


> Heute ist Sonntag, darf man da nich auch mal was unernstes fragen?


Stimmt, hatte ich nicht dran gedacht


----------



## Solaris (2 Dezember 2007)

Da ich noch ganz am Anfang stehe mit Stepp7 würde mich jetzt doch mal interessieren welche Programmierart als "sauber" zu empfehlen ist. 

Und warum sollten "Schichtelektriker" in einer Software nach Fehlern suchen die doch von Profis tagsüber in einen funktionierenden Zustand verbracht wurden? Ich meine das in Bezug auf KOP.


----------



## marlob (2 Dezember 2007)

Solaris schrieb:


> Da ich noch ganz am Anfang stehe mit Stepp7 würde mich jetzt doch mal interessieren welche Programmierart als "sauber" zu empfehlen ist.


Mit dieser Frage könntest du eine heftige Diskussion heraufbeschwören



Solaris schrieb:


> Und warum sollten "Schichtelektriker" in einer Software nach Fehlern suchen die doch von Profis tagsüber in einen funktionierenden Zustand verbracht wurden? Ich meine das in Bezug auf KOP.


Schichelektriker brauchen doch auch eine Daseinsberichtigung, wenn wir Profis keine Fehler einbauen würden, hätten die Schichelektriker ja nichts mehr zu tun. 
Wir können übrigens auch Fehler in FUP, AWL und SCL einbauen


----------



## marlob (2 Dezember 2007)

Solaris schrieb:


> Da ich noch ganz am Anfang stehe mit Stepp7 würde mich jetzt doch mal interessieren welche Programmierart als "sauber" zu empfehlen ist.


Jetzt mal eine ernsthafte Antwort. Beginne mit der Programmierart die dir am meisten liegt. Normale Logik kannst du in allen Programmierarten (FUP, KOP, AWL und SCL) hinbekommen. Da solltest du die Sprache nehmen, die dir am meisten liegt. Bestimmte Dinge kann man aber nur in AWL lösen (oder SCL wenn man nicht nur in Besitz von "Sepp7 unpressionell" ist)


----------



## vierlagig (2 Dezember 2007)

Solaris schrieb:


> Und warum sollten "Schichtelektriker" in einer Software nach Fehlern suchen die doch von Profis tagsüber in einen funktionierenden Zustand verbracht wurden? Ich meine das in Bezug auf KOP.



sie suchen nicht nach fehlern in der software, sondern lokalisieren da fehler in der hardware, defekter sensor z.b. ... und dann können sie da, wenn der sensor z.b. in einem bereich mit umgebungstemperaturen von 120°C installiert ist, ein wechsel nur nach abschalten und abkühlen möglich ist UND es genug andere funktionen zur sicherstellung des betriebs vorhanden sind, diesen sensor im programm auf eins setzen, z.b. durch eine brücke mit einem immer-1-merkers ... und, jetzt muß ich doch noch mal auf KOP zurückkommen, wo kann man schöner brücken als in KOP


----------



## Solaris (2 Dezember 2007)

Ja ich beschwöre gerne.

Das hört sich an als wenn du nicht so auf das Können der "Schichtelektricker" vertraust. Aber andererseits kann ich nicht verstehen warum andere "Schichtexperten" in einer SPS-Software rumfummeln sollen/dürfen, da wirds doch seltenst Besser von. (hört sich an wie maxi-grammatik)


----------



## Solaris (2 Dezember 2007)

Zum suchen defekter Sensoren muß man das Programm bemühen?


----------



## vierlagig (2 Dezember 2007)

Solaris schrieb:


> Zum suchen defekter Sensoren muß man das Programm bemühen?



es geht am schnellsten ... aber es geht ja auch nicht immer nur um die suche, sondern eigentlich um die brücke


----------



## Solaris (2 Dezember 2007)

Das ist ja dann schon eine Operation am offenem Herzen.


----------



## marlob (2 Dezember 2007)

Solaris schrieb:


> Zum suchen defekter Sensoren muß man das Programm bemühen?





vierlagig schrieb:


> es geht am schnellsten ... aber es geht ja auch nicht immer nur um die suche, sondern eigentlich um die brücke


In einem gutem Programm mit guter Diagnose, sollten solche Fehler übers Op, Panel, SCADA oder ... angezeigt werden und auch behebbar sein. 
z.B. PDiag in Kombination mit WinCC flex und ProAgent
Dann sollte man eigentlich kein Programm mehr gebrauchen. Eigentlich!


----------



## vierlagig (2 Dezember 2007)

Solaris schrieb:


> Das ist ja dann schon eine Operation am offenem Herzen.



nö, eigentlich nicht, geht ja nur darum, nicht erst alles abzufahren, abkühlen zu lassen, sensor zu tauschen, wieder anzufahren ... da gehen gut und gerne 16 stunden drauf ... bis zum turnusmäßigen stillstand muss es dann meist weitergehen können und dazu sollte nicht immer der ingenieur aus der wohlverdienten nachtruhe gerissen werden...


----------



## Solaris (2 Dezember 2007)

marlob schrieb:


> In einem gutem Programm mit guter Diagnose, sollten solche Fehler übers Op, Panel, SCADA oder ... angezeigt werden und auch behebbar sein.
> z.B. PDiag in Kombination mit WinCC flex und ProAgent
> Dann sollte man eigentlich kein Programm mehr gebrauchen. Eigentlich!




ja so dachte ich mir das eigentlich


----------



## vierlagig (2 Dezember 2007)

marlob schrieb:


> In einem gutem Programm mit guter Diagnose, sollten solche Fehler übers Op, Panel, SCADA oder ... angezeigt werden und auch behebbar sein.
> z.B. PDiag in Kombination mit WinCC flex und ProAgent
> Dann sollte man eigentlich kein Programm mehr gebrauchen. Eigentlich!



von der visu aus behebbar? ohje, da wäre unser elektrisches betriebspersonal schnell arbeitslos, wozu bräuchte man es dann noch, wenn auch ein anlagenfahrer dafür sorgen kann, dass es weitergeht? passwordgeschützt? das ich nicht lache...

auffindbar bin ich sehr dafür!


----------



## Solaris (2 Dezember 2007)

Damit hätte sich ja auch die Frage der Programmierart erledigt, wenn das Programm alle Betriebszustände interpretiert dann muß ja kein Dritter dran rumfummeln. Also wäre Kop nicht unbedingt erforderlich nur wegen der "Schichtelektriker". (welch abwertender Begriff)


----------



## marlob (2 Dezember 2007)

vierlagig schrieb:


> von der visu aus behebbar? ohje, da wäre unser elektrisches betriebspersonal schnell arbeitslos, wozu bräuchte man es dann noch, wenn auch ein anlagenfahrer dafür sorgen kann, dass es weitergeht? passwordgeschützt? das ich nicht lache...
> 
> auffindbar bin ich sehr dafür!


Ich habe schon so einige Anlagen programmiert, wo man von der Visu aus die meisten Fehler lokalisieren und beheben kann. Z.B. indem man die von dir angesprochenen defekten Sensoren in der Visu überbrücken/abschalten kann.
Und ja, da werden die meisten Fehler vom Betreibspersonal behoben.
Natürlich passwortgeschützt mit verschiedenen Berechtigungsstufen.


----------



## Solaris (2 Dezember 2007)

Wenn dann genug Sensoren abgeschaltet sind gibts bald ne neue Maschine?


----------



## Rudi (2 Dezember 2007)

*"Gute Programme"*

Für mich sind "gute Programme" solche die sich auf das notwendige beschränken. Der Trend geht aber leider dazu das Programmierer ihren Spieltrieb nicht bändigen können oder zu viel Zeit haben.

So nun meckert alle mit mir !


----------



## vierlagig (2 Dezember 2007)

schichtelektriker ist nicht abwertend, es ist der betriebselektriker im schichtdienst, der schichtelektriker halt ... nein, für den brauchst du nicht programmieren...

berechtigungsstufen...ähm...ja...is ok, will da jetzt nicht darüber philosophieren wie sich die stufen verschieben, nur weil einer mal keine lust hat vor ort zu sein und dann am telefon sagt: "mach mal so und so" oder der eine kennt den anderen, ist sein nachbar und beim feierabend bier werden dann passwörter getauscht...schnell ist das stufensystem verwischt und so gut wie nutzlos...


----------



## vierlagig (2 Dezember 2007)

Solaris schrieb:


> Wenn dann genug Sensoren abgeschaltet sind gibts bald ne neue Maschine?



"UND es genug andere funktionen zur sicherstellung des betriebs vorhanden sind" ... ein weiterer grund warum da elektrisches betriebspersonal gefragt ist, sicherheit ist das A und O, zum glück sind bei uns die meisten sensoren so ausgeführt, dass sich die funktionalitäten überlappen


----------



## Solaris (2 Dezember 2007)

Wär es nicht einfacher wenn "Sensor defekt" angezeigt wird und der dann vom Schichtelektriker einfach ausgetauscht wird?


----------



## vierlagig (2 Dezember 2007)

Solaris schrieb:


> Wär es nicht einfacher wenn "Sensor defekt" angezeigt wird und der dann vom Schichtelektriker einfach ausgetauscht wird?



sensor defekt wird angezeigt...meist...

austauschen läßt sich nicht immer realisieren, ich weiß nicht welche vorstellungen du von anlagen hast, aber es gibt welche die zum abfahren und anfahren sehr lange brauchen und bei denen auch hohe temperaturen herrschen... 100-180°C ... wenn es sich nicht mehr vermeiden läßt, ja dann müßen wir abschalten, aber ansonsten wird bis zum nächsten stillstand gebrückt ... eine stunde stillstand kostet irgendwas zwischen 10 und 30k€, da kann man nich mal eben 16 stunden wegen nur eines sensors stehen...


----------



## Solaris (2 Dezember 2007)

Bei den Kosten könnte man ja schon einige Sensoren doppelt ausführen...


----------



## vierlagig (2 Dezember 2007)

Solaris schrieb:


> Bei den Kosten könnte man ja schon einige Sensoren doppelt ausführen...



deswegen ist es ja auch so einfach mal einen aus der bearbeitung rauszunehmen


----------



## marlob (2 Dezember 2007)

vierlagig schrieb:


> berechtigungsstufen...ähm...ja...is ok, will da jetzt nicht darüber philosophieren wie sich die stufen verschieben, nur weil einer mal keine lust hat vor ort zu sein und dann am telefon sagt: "mach mal so und so" oder der eine kennt den anderen, ist sein nachbar und beim feierabend bier werden dann passwörter getauscht...schnell ist das stufensystem verwischt und so gut wie nutzlos...


Das passiert öfter, aber dann sollte man die Berechtigungsstufen einfach halten. Aber es bringt viele Vorteile, wenn das geschulte Betriebspersonal oder der Schichtelektriker z.B. Sensoren direkt in der Visu überbrücken können und nicht erst ein Programmiergerät anschliessen müssen. Zeit ist schliesslich Geld wie du selbst schon angemerkt hast.


----------



## vierlagig (2 Dezember 2007)

marlob schrieb:


> Das passiert öfter, aber dann sollte man die Berechtigungsstufen einfach halten. Aber es bringt viele Vorteile, wenn das geschulte Betriebspersonal oder der Schichtelektriker z.B. Sensoren direkt in der Visu überbrücken können und nicht erst ein Programmiergerät anschliessen müssen. Zeit ist schliesslich Geld wie du selbst schon angemerkt hast.



programmiergerät ist teil des netzes


----------



## marlob (2 Dezember 2007)

vierlagig schrieb:


> programmiergerät ist teil des netzes


Dann kann ja sowieso jeder dran und Dinge ändern.


----------



## vierlagig (2 Dezember 2007)

marlob schrieb:


> Dann kann ja sowieso jeder dran und Dinge ändern.



die vermutung ist berechtigt, aber seit version works sind wir mittlerweile fast sicher ... passwort kommt monatlich neu ...


----------



## marlob (2 Dezember 2007)

vierlagig schrieb:


> die vermutung ist berechtigt, aber seit version works sind wir mittlerweile fast sicher ... passwort kommt monatlich neu ...


Siehe deinen eigenen Beitrag



vierlagig schrieb:


> berechtigungsstufen...ähm...ja...is ok, will da jetzt nicht darüber philosophieren wie sich die stufen verschieben, nur weil einer mal keine lust hat vor ort zu sein und dann am telefon sagt: "mach mal so und so" oder der eine kennt den anderen, ist sein nachbar und beim feierabend bier werden dann passwörter getauscht...schnell ist das stufensystem verwischt und so gut wie nutzlos...


----------



## vierlagig (2 Dezember 2007)

ich glaub das funktioniert ganz gut...

also, wie bereits erwähnt, password für den rechner wird monatlich geändert, beim VW hat jeder der ran darf ein benutzerkonto und die steuerungen sind selber nochmal mit einem password geschützt ... und jeder der da ran geht, der es nicht darf, bekommt auf die finger ...


----------



## Larry Laffer (2 Dezember 2007)

...
da ist man mal ein paar Stunden nicht mit an Bord und was wir dann aus der Sache ...?
Hat mal einer während der letzten 60 - 70 Beiträge auf die ursprüngliche Fragestellung geschaut ?

Aber zur Diskussion - ich möchte auch noch ein bißchen mitstreiten.
Die Leute, due hier wehement behaupten, dass alle SPS-Programme an den in Betrieb befindlichen Anlagen ab einem bestimmten Anspruch an den Programmierer (und die Programmierung) gut sind, denen sage ich jetzt hiermit und sehr gerne : 
*Weit gefehlt ...*

Um den Kollegen Vierlagig ein bißchen den Rücken zu stärken möchte ich hier erwähnen, dass ich ziemlich genau weiss von welchen Anlagen er spricht. In der Holzindustrie (vielleicht ja nur dort - ich war auch da tätig, deshalb weiss ich es vielleicht auch nicht besser) und für dieselbe werden die SPS-Programme noch von Menschen erstellt. Diese Programme kosten zwar vielleicht etliche 100T€, sind aber letztlich auch nur SPS-Programme. Sie haben Fehler, es sind Dinge nicht berücksitigt usw. Manches findet man erst nach Jahren.

Ob ein SPS-Programmierer gut ist oder nicht beurteilt er nicht selbst, sondern die Anderen, die mit seinen Schüpfungen leben müssen.

Um in Steuerungen Ablauf-Fehler zu finden wird normalerweise nur der Teile des Programms durchsucht in dem die Zuweisungen erfolgen. Das ist meisst auf der Binär-Ebene. Dort sollte es einem guten Programmierer keine Probleme bereiten seine Programme so zu gestalten, dass sie der Kunde sich die NW's in KOP oder FUP ansehen kann. Punkt - Ende.

Ich selbst erstelle meine Programme in AWL oder SCL. Meine Visu's können alles anzeigen, was ich berücksichtigt habe. Aber leider auch nicht mehr. Ich würde aus dem von mir schon genannten Grund deswegen nicht so vermessen sein zu behaupten, das man in meinem Programm, obwohl gut dokumentiert, alles ohne die Programmier-SW finden kann ... und ... manchmal schalte ich mir selbst mal ein BOOL-NW in KOP oder FUP um weil ich dann selbst besser sehen kann, wo es hängt.
Ich schreibe meine Programme nicht in KOP, aber ich versuche nach Möglichkeit sie doch in der Ansicht lesbar zu machen - wo es geht ...!

So, ich denke, jetzt habe ich wieder etwas Stoff für weitere Diskussionen geliefert ...

Gruß
LL


----------



## jabba (2 Dezember 2007)

Proagent und PDiag sind zwar eine schöne Sache, erhöhen aber bei einer kleinen Anlage die Kosten um einiges.

Ich hab auch die Überwachung der Sensoren drin, aber halt nur 98%, 
manche werden halt vergessen,und da ist Pdiag und Proagent schön, weil man kein PG holen muss.
Aber selbst wenn wir den Fehler genau anzeigen, früher hab ich nur Störung Greifer geschrieben, heute sind es drei Meldungen
Störung Laufzeitfehler Greifer schliessen Y510 B510
öffnen, und Schalterpaarfehler.
Nützt alles nix, die Leute lesen nicht , fummeln, und wenn gar nix mehr geht, wird laut gebrüllt. Ich weiss es gibt auch andere Betriebe .
Ich hab mal aus versehen in ein OP eine komplett anderen Maschine eingespielt, hat 4 Wochen keiner gemerkt.
Bei den Prozessanlagen ist eine gute Diagnose umumgänglich, bei den Maschinen die ich so mache, erledige ich nur durch Beobachtung 90% der Störungen. 
Da wird man rausgerufen weil nix geht, ich sehe auf das Display "Auslauf belegt" , die Lichtschranke wieder gerade gerückt , das war´s. Eine Fehlermeldung wurd bewusst nicht angezeigt, da es bei Pausen oder so, immer zu Meldungen kam. 
Prinzipell ist die Sprache (Kop,AWL,FUP,SCL) keine Sprache sondern eine Art Interpretionsanweisung die später immer in AWL endet.
Und in jeder Sprache kann man Scheisse schreiben.
Ein gut strukturiertes Programm, müßte jeder Programmierer in allen Sprachen lesen und verstehen können.
Durch den Einsatz von Step7 wurden erhebliche Verbesserungen zur Lesbarkeit gegenüber der S5 gemacht. Es gibt aber immer noch Leute die das nicht akzeptieren wollen. Klar kann man in AWL kompakter schreiben, man sollte dies aber nur machen wenn man muss. In Standardanwendungen sollte immer so geschrieben werden, das alle drei Formen angezeigt werden können.
Wenn ich manchmal fremde Maschinen sehe , geht mir auch die Hutschnur hoch, das ist für jeden Scheiss ein FB in AWL drin, das sind oft Leute die das aus der S5 Zeit so kennen. Ich musste auch früher z.B. für die Visualisierung einen FB machen, der z.B. 3 Zustände anzeigt, weil es Sprünge nur im FB gab, und nur da AWL. Aber muss das heute noch sein?


----------



## Larry Laffer (2 Dezember 2007)

...
Vielleicht noch zur Ergänzung meines Beitrages von eben.
Bevor ich zur Instandhaltung kam war ich bei einem Anlagenbauer - heute bin ich beides (Anlagenbauer und Instandhalter).
Ich habe vormals sehr viele Dinge auch ganz anders gesehen. Man lernt aber dazu ... und da habe ich sehr viele neue Dinge gelernt.
Vielleicht sollte jeder Programmierer bei einem Anlagenbauer auch mal ein oder zwei Jahre in der Instandhaltung einer größeren Firma herummachen ... nur so eine Anregung ...


----------



## marlob (2 Dezember 2007)

Larry Laffer schrieb:


> ...
> da ist man mal ein paar Stunden nicht mit an Bord und was wir dann aus der Sache ...?
> Hat mal einer während der letzten 60 - 70 Beiträge auf die ursprüngliche Fragestellung geschaut ?


Ja, so eine kleine Diskussion ist schon was schönes



Larry Laffer schrieb:


> .
> Aber zur Diskussion - ich möchte auch noch ein bißchen mitstreiten.
> Die Leute, due hier wehement behaupten, dass alle SPS-Programme an den in Betrieb befindlichen Anlagen ab einem bestimmten Anspruch an den Programmierer (und die Programmierung) gut sind, denen sage ich jetzt hiermit und sehr gerne :
> *Weit gefehlt ...*
> ...


Also sowas, wir Programmiergötter sind unfehlbar

Aber ernsthaft, ich habe selbst jahreland als Betriebselektriker gearbeitet bevor ich zum Programmiergott aufgestiegen bin.
Und dann probiert man schon so zu programmieren, das es so ziemlich jeder verstehen kann und auch mal ein Betriebselektriker Änderungen vornehmen kann.


----------



## marlob (2 Dezember 2007)

jabba schrieb:


> Proagent und PDiag sind zwar eine schöne Sache, erhöhen aber bei einer kleinen Anlage die Kosten um einiges.


Das stimmt leider. Proagent und PDiag sind ne schöne Sache aber die zusätzlichen Kosten lohnen bei kleinen Anlagen nicht



jabba schrieb:


> Nützt alles nix, die Leute lesen nicht , fummeln, und wenn gar nix mehr geht, wird laut gebrüllt. Ich weiss es gibt auch andere Betriebe .
> ..
> Da wird man rausgerufen weil nix geht, ich sehe auf das Display "Auslauf belegt" , die Lichtschranke wieder gerade gerückt


Leider, ich bin schon nachts zu Anlagen gefahren wo nur ne Sicherung rausgefallen ist und das stand dann auch gross in der Visu.
Ich frage mich manchmal ob die Leute wirklich so doof sind oder mich nur ärgern wollen.


----------



## Perfektionist (2 Dezember 2007)

zotos schrieb:


> ... Aber folgendes:
> "kann nur AWL"
> Glaube ich Dir nicht. ...


Hallo Zotos,

habs mal probiert - siehe anhängende Grafik  

aber dabei gleich auch :???: , weil

#Perfektio
nist

erhöht auch nicht gerade die Lesbarkeit.

aber gerne nochmal Frage stell: SCL?
Also, Siemens-AWL ist nicht gleich Rockwell-AWL, und 300er-AWL ist nicht 200er-AWL. KOP ist nicht gleich KOP, FUP ist nicht gleich FUP. Micrologix-Ladder kann ich nicht nach Compact-Logix-Ladder kopieren. Wie ist das bei SCL? ist dieser genormte ST portierbar? oder gibts da auch Dialekte? Davon mal abgesehen, scheint ST zumindest bei Siemens nicht sonderlich Code- und Laufzeiteffizient zu sein?

Gruß, Perfektio
nist


----------



## Question_mark (2 Dezember 2007)

*Nicht portierbar*

Hallo,



			
				Perfektionist schrieb:
			
		

> Wie ist das bei SCL?



Nicht portierbar, da aus dem Pascal-ähnlichen SCL dann Bausteine in knallhartem AWL generiert werden. Ich sage eben Pascal-ähnlich, weil vieles an der Syntax von Pascal abgeleitet ist. Irgendjemand hat hier im Fred geschrieben, dass SCL schlecht implementiert ist (ich glaube, das war Zotos). Das liegt m.E. überwiegend daran, dass sich nicht alle Pascal-Funktionen 1:1 in AWL übertragen lassen. Also nichts für Perfektionisten  , aber doch schon ganz brauchbar...

Gruß

Question_mark


----------



## Ralle (2 Dezember 2007)

Question_mark schrieb:


> Hallo,
> 
> 
> 
> ...



Ja klar, der generierte Code ist nicht portierbar, aber das reine SCL kann man schon portieren, wenn auch nicht 1:1, da gehört dann noch etwas Anpassung dazu (leider). Das kann man ganz gut am Oscat-Projekt sehen.
SCL soll ja die IEC1131-Implementierung in der Simatic sein, aber das ist natürlich wie immer und überall in der PC-Banche nicht 100% kompatibel, siehe nur die Browser und ihre HTML-Interpretationen .

PS: Da noch'n aktueller Link: http://www.sps-forum.de/showthread.php?t=16883


----------



## Question_mark (2 Dezember 2007)

*Ralle, das sehe ich anders ...*

Hallo,



			
				Ralle schrieb:
			
		

> da gehört dann noch etwas Anpassung dazu (leider).



Ja, und das ist das Problem, das man nicht mit der Phrase "etwas Anpassung" verniedlichen sollte. Der Quelltext mag noch so einfach portierbar sein, was dann letztendlich als Maschinencode herauskommt kann wohl nicht auf jeder SPS ausführen, da z.B. unterschiedliche Leistungsfähigkeit, Befehlsvorrat etc. der SPS dann entscheidend ist. 
Mir ist beim Arbeiten mit Simatic SCL immer aufgefallen, dass wirklich nur eine ganz geringe Untermenge der Pascal Syntax angewendet werden kann. Wundert mich auch eigentlich nicht, es muss ja schließlich ein Kompilat für einen MC7-Code erzeugt werden und nicht für eine Windows xxx.exe.
Träumt mal schön weiter vom Programmierstandard, vielleicht wird eine EU-Kommission das dann doch mal reglementieren. Aber die kümmern sich lieber um die Standardmaße für Gewürzgurken  

Gruß

Question_mark


----------



## Ralle (2 Dezember 2007)

Question_mark schrieb:


> Hallo,
> 
> 
> 
> ...



Die verwendete "Untermenge" wurde von den IEC-Standardisierern festgelegt. Anpassung ist immer Mist, ich hätte mir auch gewünscht, daß es 100% austauschbar ist, aber das ist wirklich Utopie. Ich persönlich bin auch nicht so unglücklich darüber, auch wenn es blöd klingt, man möchte doch als Programmierer gefragt bleiben, oder?


----------



## Question_mark (3 Dezember 2007)

*Schön wär's*

Hallo,



			
				Ralle schrieb:
			
		

> Die verwendete "Untermenge" wurde von den IEC-Standardisierern festgelegt.



Die Untermenge in Simatic SCL wurde bestimmt nicht vom einer IEC-Kommission festgelegt, sondern hält sich m.E. wohl eher daran : Was kann ich aus Pascal-Syntax nach AWL compilieren. Und da gibt es eben ein Ende der Fahnenstange, was nicht in AWL compiliert werden kann (eben durch die Möglichkeiten der CPU begrenzt), wird auch im Funktionsumfang weggelassen. Und fertig, oder ???



			
				Ralle schrieb:
			
		

> man möchte doch als Programmierer gefragt bleiben, oder?


Richtig, machen wir einfach weiter und irritieren die anderen Forumsteilnehmer, die OSCAT für den break through in der SPS-Programmierung halten.  

Gruß

Question_mark


----------



## Question_mark (3 Dezember 2007)

*Ein Telegramm für Ralle ...*

Hallo,



			
				Ralle schrieb:
			
		

> aber das ist wirklich Utopie.



STX Dafür gibt es ein 100% ACK von mir ETX     

Gruß

Question_mark


----------



## zotos (3 Dezember 2007)

Question_mark schrieb:


> ...
> Die Untermenge in Simatic SCL wurde bestimmt nicht vom einer IEC-Kommission festgelegt, sondern hält sich m.E. wohl eher daran : Was kann ich aus Pascal-Syntax nach AWL compilieren.
> ...



Also das ist doch quatsch. Also ich bin ja kein großer Siemens Fan, aber den Compiler der aus SCL -> AWL macht, ist denke ich schon Ok. 

Die wirklichen Unterschiede zwischen SCL und dem ST aus der IEC beruhen m.E. eher auf dem Datenmodel von Siemens. 

Aber dazu können die Übersetzer die, die OSCAT auf die Step7 portiert haben sicher mehr sagen.


Also ST/SCL ist ja als Hochsprache für die SPS gedacht. Soll es also dem Programmierer einfacher machen und unleserlichen AWL Code ersetzen.

Wenn ich mir anschaue wie hier im Forum in letzter Zeit die "Pointerei auf der S7" im vollen Gang ist, frage ich mich ob das der Weisheit letzter Schluss sein soll. Wenn man es mit SCL kompakt und übersichtlich darstellen kann.

Beispiele:
http://www.sps-forum.de/showthread.php?t=16784
SLW/SLD,  LAR1 Stolpereien oder in SCL ein Einzeiler.

http://www.sps-forum.de/showthread.php?t=16840
Eine For-Schleife von Handbauen sich gedanken machen über das Sichern von Adressregister und das Wiederherstellen davon. Im vergleich zu einer simplen FOR-Schleife.


----------



## marlob (3 Dezember 2007)

zotos schrieb:


> Also ST/SCL ist ja als Hochsprache für die SPS gedacht. Soll es also dem Programmierer einfacher machen und unleserlichen AWL Code ersetzen.
> 
> Wenn ich mir anschaue wie hier im Forum in letzter Zeit die "Pointerei auf der S7" im vollen Gang ist, frage ich mich ob das der Weisheit letzter Schluss sein soll. Wenn man es mit SCL kompakt und übersichtlich darstellen kann.
> 
> ...


Genau meine Meinung. Gerade bei solchen Sachen, wo man Adressregister sichern muss usw. ist es von Vorteil, diese Dinge in SCL zu programmieren, wenn man denn in Besitz dieser Software ist.
Aber da liegt ja auch schon der Haken. Viele besitzen halt nur die Standarversion von Step7 (@Zotos: Step7 unprofessional, du erinnerst dich). Wir haben auch viele Kunden, die wollen die Software nachher weiterbearbeiten und haben nur diese Standardversion. Dann bleibt uns gar nichts anderes übrig, als es in AWL zu programmieren und mit ARs usw. zu hantieren


----------



## Perfektionist (3 Dezember 2007)

*mal Danke rundrum für die SCL-Aufklärung*

ja, es ist also so, wie befürchtet: es gibt auch da Dialekte.

Bei mir kommen in den Programmen nur wenig Pointergeschichten vor, wenngleich öfter mal höhere Mathematik. Aber das konnte ich bisher immer Laufzeiteffizient auf DINT-Arithmetik reduzieren, für SQRT und COS hab ich mir FB mit ausreichender Genauigkeit und hoher Laufzeiteffizienz mit Hilfe von pointeradressierten Tabellen geschrieben. Auf den FP-CPU wie 317/318 haben diese Bausteine zwar keinen Vorteil, aber auf so GammelCPU wie 314 läuft das dann auch recht schön.

na, ja, bleib ich mal bei AWL. Sehe in SCL für MICH keinen entscheidenden Vorteil ...


----------



## maxi (3 Dezember 2007)

Hallo,

bei Regelungen mache ich den Regelbaustein in AWL und den Aufruf immer in Kop. Der Kunde muss ja nichts am geprüften Regelbaustein ändern.
diesen in Kp zu programmieren währe meist ein totales unding und eine grosse Knobelaufgabe, da dort meist einiges an Berechnungen darin steckt.

Ebenso halte ich es bei Schritketten, diese nur in AWL.
Auf Wunsch des Betreibers benutze ich auch gerne einen Compiler.
Für Ingenieure sind Compiler meist sehr vorteilhaft, da Sie sich das Programm dann in Excel ansehen können und kein Wissen über die SPS brauchen. Meist ist es dann mit einer kleiner Funktionsbeschreibung für die Schritkette sehr praktikabel abgetan.

Was ich immer wichig finde, bei der Übergabe einer Anlage den zuständigen Techniker das Programm zu erklären und er soll sich Notitzen machen, bzw. zusätzliche Komentare.


----------



## kiestumpe (3 Dezember 2007)

marlob schrieb:


> Genau meine Meinung. Gerade bei solchen Sachen, wo man Adressregister sichern muss usw. ist es von Vorteil, diese Dinge in SCL zu programmieren, wenn man denn in Besitz dieser Software ist.
> Aber da liegt ja auch schon der Haken. Viele besitzen halt nur die Standarversion von Step7 (@Zotos: Step7 unprofessional, du erinnerst dich). Wir haben auch viele Kunden, die wollen die Software nachher weiterbearbeiten und haben nur diese Standardversion. Dann bleibt uns gar nichts anderes übrig, als es in AWL zu programmieren und mit ARs usw. zu hantieren



Im Zirkus bekommen sie Geld, wenn sie entsprechende Verrenkungen machen...


----------



## Larry Laffer (3 Dezember 2007)

So wie ich das festgestellt habe kann man SCL auch nachträglich erwerben und dazu-installieren (wenn man Step7 unprof gekauft hat).

@Perfektionist:
Auch einfache Berechnungs-Formeln sehen in SCL sehr viel schöner aus und man kann sich viele Kommentare ersparen weil sich der Sinn der Berechnung oft schon aus der Formel ergibt.

@Maxi:
Gerade bei Schrittketten finde ich es für die, die nach mir kommen recht praktisch, wenn man sie sich auch in KOP oder FUP ansehen kann - aus den von mir schon genannte Gründen ...

Gruß
LL


----------



## thony77 (3 Dezember 2007)

*Wow !!*

*Moin erstmal, ich sehe es genau so , bin auch Instler. ich habe diese Frage aus 2 Gründen gestellt und muss mit erschrecken festellen was für eine zum größten teil DUMME Grudsatzdiskussionen hier enstanden ist.
Es kann mir keiner der SPS-Spezialisten erzählen er würde einen 30000€ Auftrag ausschlagen weil er als Vorgabe eine KOP oder FUP "Sprache" Vorgesetzt bekommt. Da lache ich mich echt kaputt!!! 
Es gibt mit Sichherheit auch Bausteine die gar nicht anders möglich sind als sie in AWL darzustellen bzw. zu Programmieren.
Um auf das eigentliche Problem noch mal zurück zu kommen.......

1.Entweder es gibt ein Programm um sich von AWL in KOP Sprache nzeigen zu lassen (Habe mal ein Video im Netz gesehen ES GEHT AUF ALLE FÄLLE weiss leider nicht mehr von wem es ist oder wie es heisst).
Oder......
2.Ich lerne etwas AWL damit ich den Programmablauf vestehe und Störungen so besser uns schneller beseitigen kann.

Das Wichtigste hätte ich fast vergessen... ICH BIN NICHT DUMM !!!
Wer solch einen Blödsinn über Instandhaltugspersonal schreibt lebt in einer anderen Welt meiner Meinung nach. 
Die SPS ist nur einfach nicht mein Schwerpunktgebiet , 
nicht mehr und nicht weniger!!!

Ich Danke allen die mir versucht haben eine "Hilfestellung" zu geben und sich dem Problem wirklich angenommen haben.
Allen anderen sogenannten Spezialisten sollten (meiner Meinung nach) etweder schweigen oder wirkliche Hilfestellungen geben denn dafür ist dieses Forum da.

MFG Thony77*



Jungs, ich bin jetz auch schon ein paar Jährchen in der IH.
Anfangs war noch S5, als ich hier einsteigen wollte kam bei uns S7...
Durch guten Zufall kam ich günstig privat zu ner 315-2DP, nur was tun ohne EA.. ok Ebay. Mittlerweile hab ich fast über nen Meter  EA zu Hause. Hab heute "fast" keine Probleme mit eurem Drecks AWL.(Kann hier auch sagen ihr seid bei S5 stehen geblieben IHR PENNER  ).

Meiner Meinung und dem des Stils unserer Progger Firma passt KOP ganz gut, da auf den ersten Blick erkennbar welches "bit" fehlt.
nur mal so als Beispiel.
Ich hab zwischendurch auch mal mit Neulingen zu kämpfen, gebt es zu, wer von euch hätte euren AWL Code kurz nach der Lehre schon verstanden? Vielleicht noch ein paar Schleifen und Pointer dazu?
Ich kann die AWL Scheisse die IHR immer noch abliefert wenigstens noch lesen, aber schreiben will ich diesen mist nicht.
Strukturiert eure Daten usw. sauber lässt sich vieles easy mit Kop usw. ausführen, wenns sein muss auch mal ein zwei drei Netzwerke mit AWL, aber mehr nicht.
Bevor ich mit Pointern und AR rumscheiss mach ich gleich SCL auf.
Mit gut Strukturierten Daten bzw. DBs liest sich das hingegen wie eine Bettlektüre.


Euer Drecks AWL geheule kann hier langsam keiner mehr hören.
Wenn einer Auf S5 oder schlimmer s3 Zeiten stehen geblieben ist dann ist das die AWL PRO Fraktion hier.
Sorry, aber wenn sich einer zu schön für Kop/fup ist der hat seinen Beruf verfehlt.

Und noch was , wer Zahlt schafft an , fertig. Wer zu "doof "für KOP ist, ist grad genug für Hartz IV. Entweder Ihr wollt "Programmierer" sein und beherscht alles oder Ihr lasst die Finger weg und geht putzen oder Lampen wechseln. 

Und kommt mir nicht mit UG, der Penner meint auch er hat die Weisheit mit der Schaufel gefressen...die hau ich ihm auch gern drüber.


----------



## zotos (3 Dezember 2007)

thony77 schrieb:


> *...**
> 1.Entweder es gibt ein Programm um sich von AWL in KOP Sprache nzeigen zu lassen (Habe mal ein Video im Netz gesehen ES GEHT AUF ALLE FÄLLE weiss leider nicht mehr von wem es ist oder wie es heisst).
> Oder......
> 2.Ich lerne etwas AWL damit ich den Programmablauf vestehe und Störungen so besser uns schneller beseitigen kann.
> *...



1) Geht nicht und bei 2) habe ich Zweifel.

PS: Denkst Du das Dein Beitrag in der Farbe rot irgendwie wichtiger oder gar intelligenter wirkt?


----------



## Larry Laffer (3 Dezember 2007)

@Thony77:
Wäre vielleicht nicht schlecht gewesen, du hättest so zwischendurch mal was dazu geschrieben. Deine Antwort deckt sich im Wesentlichen mit meiner Sicht der Dinge - vielleicht ein bißchen krass, aber gut ...

Für mich war es auch sehr interessant zu Lesen, wie über welche Dinge so gedacht wird. Von daher von meiner Seite ein Danke für deinen Beitrag. Außerdem war es eine schöne kontroverse Diskussion - übrigens war das Thema von Anfang an prädistiniert dafür ...
Ich hoffe, du kannst mit den ca. 10 bis max. 20 Beiträgen, die sich mit deiner Problemstellung beschäftigen etwas anfangen ...

Gruß
LL


----------



## OHGN (3 Dezember 2007)

@thony77:
Wenn Du aus Beiträgen zitierst nutze doch bitte den "Zitieren"- Button oder setze den Beitrag wenigstens zwischen die Quote- Tags.


----------



## OHGN (3 Dezember 2007)

thony77 schrieb:


> *1.Entweder es gibt ein Programm um sich von AWL in KOP Sprache nzeigen zu lassen (Habe mal ein Video im Netz gesehen ES GEHT AUF ALLE FÄLLE weiss leider nicht mehr von wem es ist oder wie es heisst).*


Vieleicht meinst Du ja diesen sogenannten KOP-Konverter, aber der wandelt, soviel wie ich weis, nur Bausteinaufrufe die in AWL geschrieben wurden in einen KOP/FUP-konformen Bausteinaufruf um.

Programme, die ein komplexes, in AWL geschriebenes Programm in KOP/FUP übersetzen können gibt es IMHO nicht.


----------



## thony77 (3 Dezember 2007)

*Genau )*

*KOP-Konverter genau das ist das Progr. das ich meinte.
Das bringt mich schon einen großen Schritt weiter.


Danke noch mal ich werde mich mal genauer über das Progr. Erkundigen.

* Programme, die ein komplexes, in AWL geschriebenes Programm in KOP/FUP übersetzen können gibt es IMHO nicht

*Das Glaube ich Dir gerne, aber darum ging es mir ja gar nicht. In den neuen Programmen ist gut 70% in AWL Programiert 
(ohne Standartbausteine) und um diese geht es mir.
Und dafür scheint mir dieses Prog. eine Alternative zu sein.
** 

Mfg 


*


----------



## Perfektionist (3 Dezember 2007)

OHGN schrieb:


> @thony77:
> Wenn Du aus Beiträgen zitierst nutze doch bitte den "Zitieren"- Button oder setze den Beitrag wenigstens zwischen die Quote- Tags.


Danke!
ach, daher kam mir der schwarze Teil so bekannt vor, habe schon das Forum durchsucht, bin aber nicht sofort auf die Idee gekommen, dass das hier im gleichen Thread steht ...


----------



## zotos (3 Dezember 2007)

thony77 schrieb:


> *...
> **In den neuen Programmen ist gut 70% in AWL Programiert
> (ohne Standartbausteine) und um diese geht es mir.
> Und dafür scheint mir dieses Prog. eine Alternative zu sein.
> ...



Also der Autor des Programms ist ja hier im Forum aktiv. Vielleicht kann er Dir ja weiter helfen.

Wenn ich das richtige verstanden habe geht es nur um die Aufrufe von Bausteinen. Um Bausteinaufrufe in KOP/FUP darstellen zu können müssen die Eingangsparameter erst auf Lokale Variablen kopiert werden. Das ist IMHO bei einem Programm das zu 70% aus AWL besteht nicht gerade der große Sprung in Richtung KOP.


----------



## D-DNRN (3 Dezember 2007)

So und jetzt mal eine Art Zusammenfassung von einem der (nur) hier ziemlich neu ist und seit ca. 1 Std. lachend vor dem Kasten sitzt.

Das Problem AWL<> KOP/FUP ist doch genaugenommen nur von Siemens gemacht! Hätten die sich ein wenig mehr Mühe gegeben könnte man sicher auch von/in jede Variante umwandeln. 
ALSO: Geht nicht! Schluss!
Eine vernünftige Hochsprache (SCL ist eben nur Option und nicht gut integriert) hat Siemens dazu noch nicht entwickelt.

*Die beste Variante *ist doch mit Sicherheit die jetzt oft genug erwähnte:
*Binäre Logik > *wenn es möglich ist* KOP/FUP  kompatibel*erzeugen.
*Datenverarb.> in AWL* weil's einfach sonst nicht gut geht.


Vorteile: 
*Die einfachen Sachen* kann fast jeder verstehen, sind ja umschaltbar und so für jeden in seiner bevorzugten Sprache verfügbar.
*Die komplizierten Dinge* in AWL versteht der KOP Leser warscheinlich auch in KOP nicht wirklich.

Damit dürfte alles gedient sein und *das wichtigste ist sowieso die gute Dokumentation mit Kommentaren!

*Gruß
dD

uns jetzt schlagt auf mich ein ......


----------



## Perfektionist (3 Dezember 2007)

D-DNRN schrieb:


> So und jetzt mal eine Art Zusammenfassung von einem der (nur) hier ziemlich neu ist und seit ca. 1 Std. lachend vor dem Kasten sitzt.
> ....uns jetzt schlagt auf mich ein ......


 
*aushohl* *patsch* *niederstreck*  

na, ja, mal ernsthafter: war doch erfrischend, mal so ne Stunde Lachen?

Und noch ernsthafter: hier werden weltanschaulicjhe Dinge diskutiert - die soll man nicht so auf die leichte Schulter nehmen.

:sm17: wo kämen wir da hin :sb6: wenn jeder koden würde, wie er mag :sb9: ?


damit ich nicht selbst aus Versehen zwischen die Mühlsteine gerate: klar, der Kunde ist König. Doof immer dann, wenn es zu Missverständnissen gekommen ist ... wer da dann wen über den Tisch gezogen hat, ist dann immer etwas schwierig zu beantworten.


----------



## D-DNRN (3 Dezember 2007)

Es ist doch wie bei den Hochsprachen für PC's ..... 

Es gibt VisualBasic, C(++),  Delphi/Pascal, Java, ..... und 100 weitere Dialekte
und Assembler ist für manche Programmierer oder spezielle Aufgaben auch immer noch zu haben und wird auch genutzt.
(AWL ist dann wohl Assembler in seiner reinsten Form )

und ...

Der beste Beweis für die Notwendigkeit von ALLEN Varianten ist doch, das es sie immer noch gibt.

Wozu sollte Siemens zig Milliönchen  in die Entwicklung einer solchen Sprache stecken (immer noch) wenn es nicht für alles seine Berechtigung gäbe.


----------



## Question_mark (3 Dezember 2007)

*Zotos in der Ritterrüstung*

Hallo,



			
				zotos schrieb:
			
		

> Also das ist doch quatsch. Also ich bin ja kein großer Siemens Fan, aber den Compiler der aus SCL -> AWL macht, ist denke ich schon Ok.
> 
> Die wirklichen Unterschiede zwischen SCL und dem ST aus der IEC beruhen m.E. eher auf dem Datenmodel von Siemens.



Wenn das Quatsch war, wieso wiederholst Du dann eigentlich das, was ich vorher festgestellt habe (oder darstellen wollte, wenn es nicht so rübergekommen ist) ?
Ich denke mal, ich habe deutlich dargelegt, dass nach meiner Meinung der Funktionsumfang von S7-SCL durch die nach Simatic S7 AWL compilierbaren Funktionen begrenzt ist. 
Wenn aber Kritik an OSCAT aufkommt, zieht unser Fönig Zotos das Königsgewand aus, die Ritterrüstung an und schwingt den Morgenstern    

Gruß

Question_mark

PS : Bin im Moment sowieso angefressen, weil ich mich hier alle 2 Minuten wieder neu anmelden muss :sb7: :sb7:


----------



## zotos (4 Dezember 2007)

Question_mark schrieb:


> ...
> Wenn das Quatsch war, wieso wiederholst Du dann eigentlich das, was ich vorher festgestellt habe (oder darstellen wollte, wenn es nicht so rübergekommen ist) ?
> ...



Also das lag wohl daran das ich AWL auf die Befehle bezogen habe und das Datenmodel von der S7 auf das System bezogen habe unabhängig von der Programmiersprache.

Ich will aber keine Haarspalterei betrieben. Daher habe ich Dich wohl Deine Aussage einfach falsch interpretiert.


----------



## kiestumpe (4 Dezember 2007)

*Umschaltsperre*

Da der  Thread ja eh schon so lang ist, kommt es auf das nun auch nicht mehr an:
:!:
Wenn ihr von KOP/FUP nach AWL umschaltet, dann eine tempVariable einfügt in der Deklaration und wieder zurückschalten wollte, gehts nicht mehr.


----------



## MSB (4 Dezember 2007)

kiestumpe schrieb:


> Da der  Thread ja eh schon so lang ist, kommt es auf das nun auch nicht mehr an:
> :!:
> Wenn ihr von KOP/FUP nach AWL umschaltet, dann eine tempVariable einfügt in der Deklaration und wieder zurückschalten wollte, gehts nicht mehr.



Vorher aber die Warnung die Step7 einem da freundlicherweise gibt, total ignorieren. (Ohne zu lesen mit OK bestätigen)


----------



## kiestumpe (4 Dezember 2007)

@MSB:
Ich gratuliere dir, du bist ein Schnellckecker, wenn du bereits aus der Warnung auf Anhieb diesen Zusammenhang herauslesen konntest, dass man danach nicht mehr Umschalten kann-mir war's erst klar, als es schon zu spät war, davor wollte ich die anderen warnen. 

Na, mal im Ernst, man muss sie halt im FUP/KOP Ansicht einfügen, dann erspart man sich den Ärger.


----------



## zotos (4 Dezember 2007)

D-DNRN schrieb:


> ...
> Eine vernünftige Hochsprache (SCL ist eben nur Option und nicht gut integriert) hat Siemens dazu noch nicht entwickelt.
> ...



ST sprich SCL ist auch auf der S7 ein gutes Werkzeug. Es ist in der professionellen Version von Step7 auch keine Option sondern integrierter Bestandteil. 

Andere Steuerungshersteller gruppieren die Kunden auch nicht in Lite/Standard = unprofessionell und in die professionelle Gruppe.

Step7 ohne Graph7, SCL und am wichtigsten ohne PLCsim ist doch echt unbrauchbar.


----------



## sps-concept (4 Dezember 2007)

*KOP-Konverter*

Hallo,

ja das ist richtig! Der KOP-Konverter wandelt Bausteinaufrufe die in AWL geschrieben wurden in einen KOP/FUP-konformen Bausteinaufruf um. Oft gefragt ist dies bei konvertierten S5-Programmen. Aber auch wenn der Kunde kein AWL will kommt dies zum Einsatz. Wie auch im Video zu sehen ist muss man nur Haken setzen und dann konvertieren. Diese Haken kennzeichnen einen IN-Parameter im BOOL-Format.

André


----------



## vierlagig (2 Januar 2008)

*ein wenig wasser auf die mühlen der AWL vs. KOP diskussion*

so, mal was für die KOP-"programmierer"

ein kollege stolperte über folgendes problem.
er hat einen baustein geschrieben, in dem am ende ein rotierendes bit bei #next_step gesetzt werden soll. mal ganz davon ab, das man das sicher auch anders lösen kann als er, hatte er ein problem, welches er aufgrund mangelnder AWL-kenntnisse nicht lösen konnte.

eigentlich, also wenn man sich die screenshots unter dem gesichtpunkt der logik betrachtet, machen sie beide das selbe, aber halt nur eigentlich ...

warum sieht man hier:

FUNZT NICHT:

```
end:  [COLOR=Red]U     #next_step
      =     L      4.0[/COLOR]
      U     L      4.0
      U     #lub4
      UN    #lub1
      S     #lub1
      R     #lub4
      [COLOR=Red]R     #next_step[/COLOR]
      U     #next_step
      U     #lub1
      UN    #lub2
      S     #lub2
      R     #lub1
      R     #next_step
      U     L      4.0
      U     #lub2
      UN    #lub3
      S     #lub3
      R     #lub2
      R     #next_step
      U     L      4.0
      U     #lub3
      UN    #lub4
      S     #lub4
      R     #lub3
      R     #next_step
      U     L      4.0
      UN    #lub1
      UN    #lub2
      UN    #lub3
      UN    #lub4
      S     #lub1
      R     #next_step
```
FUNZT:

```
end:  U     #always1
      =     L      4.0
      U     L      4.0
      [COLOR=Red]U     #next_step[/COLOR]
      U     #lub4
      UN    #lub1
      S     #lub1
      R     #lub4
      [COLOR=Red]R     #next_step[/COLOR]
      U     L      4.0
      U     #next_step
      U     #lub1
      UN    #lub2
      S     #lub2
      R     #lub1
      R     #next_step
      U     L      4.0
      U     #next_step
      U     #lub2
      UN    #lub3
      S     #lub3
      R     #lub2
      R     #next_step
      U     L      4.0
      U     #next_step
      U     #lub3
      UN    #lub4
      S     #lub4
      R     #lub3
      R     #next_step
      U     L      4.0
      U     #next_step
      UN    #lub1
      UN    #lub2
      UN    #lub3
      UN    #lub4
      S     #lub1
      R     #next_step
```
also auch mal links und rechts vom eingefahrenen weg gucken, sonst fällt man schnell mal auf die nase ...

zu den anhängen:

funzt nicht ............... funzt


----------



## godi (3 Januar 2008)

vierlagig schrieb:


> so, mal was für die KOP-"programmierer"
> 
> ein kollege stolperte über folgendes problem.
> er hat einen baustein geschrieben, in dem am ende ein rotierendes bit bei #next_step gesetzt werden soll. mal ganz davon ab, das man das sicher auch anders lösen kann als er, hatte er ein problem, welches er aufgrund mangelnder AWL-kenntnisse nicht lösen konnte.
> ...


 
Warum sollten beide Programme unter dem Gesichtspunkt der Logik das selbe machen?

Eine SPS ist eben keine Relaisschaltung!
Also werft das KOP weg!  

godi


----------



## vierlagig (3 Januar 2008)

godi schrieb:


> Warum sollten beide Programme unter dem Gesichtspunkt der Logik das selbe machen?




in der KOP-darstellung sieht man halt nicht, dass auf lokaldaten zugegriffen wird


----------

