# AWL in der Zukunft



## Miffi (21 Oktober 2012)

Hallo,

wisst ihr den Grund dafür, warum die Sprache AWL in Zukunft nicht mehr von Siemens unterstützt wird? Bedeutet es dann, dass man die Sprache nicht beherrschen muss? Dann nur noch KOP, FUB und Graph?


----------



## rostiger Nagel (21 Oktober 2012)

AWL gibt es noch und ist nicht abgekündigt, außnahme in der 1200er.SCL wird aber immer mehr als AWL-Ersatz in den vordegrund treten.


----------



## Boxy (21 Oktober 2012)

Bis AWL bei Siemens tot ist, wird es wohl noch lange dauern. 
Liegt schon daran, das man die alten Steuerungen weiterhin unterstützt. 
Auch gibt es für FB's viele Dinge welche man mit KOP oder FUP nicht machen kann 
Es wird wohl aber mehr dahin gehen, das wie bei CoDeSys mehr STL / SCL eingesetzt wird. 
Es wird aber wohl auch die Kombination von verschiedenen sprachen in einen Baustein geben, wie zb bei Bosch. 
D.h. Man wird z.B. KOP und SCL in einem Baustein programmieren können. 
Macht die Dinge für Instandhaltung halt einfacher.


----------



## Perfektionist (21 Oktober 2012)

ich denke mal, auch KOP und FUP werden zunehmend aufs Abstellgleis geschoben werden. Ob Graph vernünftig durch SCL/ST ersetzbar sein wird, entzieht sich mangels Erfahrung meiner Kenntnis. Jedoch habe ich seither in Ermangelung von SCL und auch Graph vieles dann in AWL gemacht. Aber ich denke, mit TIA V11 wird SCL meine bevorzugte Sprache werden. Ob ich da auf Graph verzichten möchte und auch kann, wird sich erst zeigen.

Fazit: zur Zeit sieht es noch so aus, dass man auf das Wissen um die anderen Sprachen noch nicht verzichten kann.


----------



## Aventinus (22 Oktober 2012)

Ich gehe auch davon aus, dass AWL über kurz oder lang von der Bildfläche verschwindet. Bis dahin wird aber sicher noch ein langer Weg sein. Ich denke grad an S5. Die ist auch schon lang tot und doch hat man immer wieder so ein Ding in den Fingern.


----------



## c.wehn (22 Oktober 2012)

Also ich glaub ich weiss da schon etwas mehr, ich sags mal so, geduldet euch bis zur IPC Messe


----------



## peter(R) (22 Oktober 2012)

Beim Wechsel von S5 auf S7 gab es bereits das Gerücht " AWL stirbt". Totgesagte leben länger !!

peter(R)


----------



## Perfektionist (22 Oktober 2012)

c.wehn schrieb:


> Also ich glaub ich weiss da schon etwas mehr, ich sags mal so, geduldet euch bis zur IPC Messe


also darf ich aus diesem Satz in etwa schliessen: es gibt einen S5/S7-Kompatilitätsmodus bei der 1500er, die neuen Möglichkeiten von V11 werden mit AWL aber nicht nutzbar sein.


----------



## MSB (22 Oktober 2012)

Ich sehe das ganze jetzt mal ganz nüchtern:
AWL bzw. IL ist von der IEC als Sprache ganz klar definiert, und wird vermutlich alleine deshalb nicht verschwinden.

Wie man an den diversesten IEC-Programmiersystemen sieht, widerspricht sich AWL(IL) und "modernes" Speicherhandling ebenfalls nicht,
außerdem, wenn man (Siemens) weiterhin eine wenigstens halbwegs problemlose Migration bieten will, wird an AWL wohl ebenfalls kein Weg vorbeiführen.
Da Siemens diesen scheinbar komplexen Weg mit TIA ja nun bestreitet (Migrationsmöglichkeit von S7-Classic) wird sich daran wohl auch nichts ändern können.

Wie "wir" als Programmierer mit diesen Möglichkeiten in naher Zukunft umgehen werden, wird die Zeit oder der "Markt" regeln,
die Tendenz wird wohl wirklich eher zu SCL(ST) gehen, aber das nicht wegen des "Zwangs" der verwendeten Programmierumgebung.

Mfg
Manuel


----------



## Miffi (22 Oktober 2012)

Danke für eure Meinungen. Dann lohnt es sich noch, lange Abende in AWL zu investieren... 

Soweit ich bis jetzt erfahren habe, kann man mit FUB/KOP und Graph ca. 70% bis 80% aller Lösungen abdecken.

Mit  AWL 100%. Nun soll es mit SCL erheblich leichter sein, diese 100% umzusetzen.


----------



## Perfektionist (23 Oktober 2012)

MSB schrieb:


> ...die Tendenz wird wohl wirklich eher zu SCL(ST) gehen, aber das nicht wegen des "Zwangs" der verwendeten Programmierumgebung.
> ...


m.E. gerade deswegen, wenn es möglich werden würde, diesen Code dann zwischen verschiedenen Prorammierumgebungen austauschen zu können.


----------



## PhilippL (30 Oktober 2012)

Perfektionist schrieb:


> also darf ich aus diesem Satz in etwa schliessen: es gibt einen S5/S7-Kompatilitätsmodus bei der 1500er, die neuen Möglichkeiten von V11 werden mit AWL aber nicht nutzbar sein.



Hallo,

ich weiß da auch bischen mehr... aber soviel sei gesagt an den Perfektionisten... nein dem ist nicht so auch die neuen Funktionen sind nutzbar...


----------



## Werner29 (31 Oktober 2012)

MSB schrieb:


> Ich sehe das ganze jetzt mal ganz nüchtern:
> AWL bzw. IL ist von der IEC als Sprache ganz klar definiert, und wird vermutlich alleine deshalb nicht verschwinden.



Ja, AWL ist Teil der IEC, aber Siemens hat diesen AWL nicht implementiert. Da ist doch nur der Name gleich. Das ist deshalb für Siemens sicher kein Argument. 

Neuere Implementationen des Standards verzichten (fast) alle auf AWL.
In der 3rd Edition der IEC 61131-3 (wird voraussichtlich im Februar erscheinen) hat man deswegen den IL als "Deprecated" bezeichnet. Das heisst, der IL ist unverändert
von der 2nd Edition übernommen worden wird aber in zukünftigen Versionen nicht mehr drin sein.
Was das für die Strategie von Siemens bedeutet, kann ich natürlich nicht sagen. Für Siemens ist es sicher wichtiger kompatibel zu sich selbst zu bleiben als zum Standard.


----------



## Larry Laffer (31 Oktober 2012)

Miffi schrieb:


> Soweit ich bis jetzt erfahren habe, kann man mit FUB/KOP und Graph ca. 70% bis 80% aller Lösungen abdecken.
> 
> Mit  AWL 100%. Nun soll es mit SCL erheblich leichter sein, diese 100% umzusetzen.



Hallo,
das stimmt so nicht ganz ...
Es ist immer eine Frage dessen, was du machen willst.
Willst du eine Schleife programmieren, dann geht das in KOP-FUP eigentlich gar nicht, in AWL bekommt man es hin und in SCL ist es kein Problem.
Willst du eine Bit-Verknüpfung machen, so geht es grundsätzlich in jeder der Möglichkeiten, in SCL könnte es aber "etwas" unübersichtlich aussehen - bei KOP-FUP-AWL ist es dann eher eine Geschmacksfrage ...

Gruß
Larry


----------



## Perfektionist (31 Oktober 2012)

Larry Laffer schrieb:


> Willst du eine Bit-Verknüpfung machen, so geht es grundsätzlich in jeder der Möglichkeiten, in SCL könnte es aber "etwas" unübersichtlich aussehen - bei KOP-FUP-AWL ist es dann eher eine Geschmacksfrage ...


für viele ist AWL keine Geschmacksfrage, sondern NoGo für Bitverknüpfungen. Für mich gibts jedoch KOP/FUP schon lange nicht mehr. Ich bereite mich gerade auf den Umstieg nach SCL vor (wegen der 1200er) und hoffe, dass ich auch dort die Bitverknüpfungen so übersichtlich hinbekomme, wie ich es bei AWL zu formulieren verstanden habe.


----------



## zotos (31 Oktober 2012)

Perfektionist schrieb:


> ...
> Ich bereite mich gerade auf den Umstieg nach SCL vor (wegen der 1200er) und hoffe, dass ich auch dort die Bitverknüpfungen so übersichtlich hinbekomme, wie ich es bei AWL zu formulieren verstanden habe.


ich sehe da kein Hindernis. 
Pseudo-AWL

```
U Start
UN Stop
=RUN
```

Preudo-SCL

```
RUN := Start AND NOT Stop;
```

oder alternativ wenn es denn mal etwas länger ist, kann man die Sachen auch untereinander schreiben.


----------



## Larry Laffer (31 Oktober 2012)

Perfektionist schrieb:


> für viele ist AWL keine Geschmacksfrage, sondern NoGo für Bitverknüpfungen. Für mich gibts jedoch KOP/FUP schon lange nicht mehr.



Da kann man mal wieder sehen, wie unterschiedlich die Ansichten so sind ...


----------



## PN/DP (31 Oktober 2012)

zotos schrieb:


> Preudo-SCL
> 
> ```
> RUN := Start AND NOT Stop;
> ```


Schön wär's, wenn die meisten Programmierer sowas könnten.
Doch meine Erfahrung sagt, daß SCL (wie CoDeSys ST) zu leicht zu falscher (ereignisorientierter) Denkweise verführt und Hochsprachen-Programmierer zu sehr denken läßt, sie verstünden auch was von PLC-Programmierung.

Wenn ich Bitverknüpfungen in SCL/ST sehe, dann eher solche abartigen Konstrukte:

```
IF Start = TRUE THEN RUN := TRUE ELSE RUN := FALSE;
IF Stop = TRUE AND RUN = TRUE THEN RUN := FALSE;
```

Von den nicht vollständig für jede Operandenkombination ausprogrammierten und deshalb nicht immer funktionierenden Varianten ganz zu schweigen.

Harald


----------



## zotos (31 Oktober 2012)

PN/DP schrieb:


> Schön wär's, wenn die meisten Programmierer sowas könnten.
> ...



Naja beim zweiten Blick war mein Beispiel doof da die Sache mit Start, Stop und Run eher was für Setzen/Rücksetzen mit der entsprechenden Dominanz wäre und nicht für eine Zuweisung.

Was man selbst bevorzugt ist wohl Geschmackssache



```
IF Stop OR Fault THEN
    Run := FALSE;
ELSIF Start THEN
    Run := TRUE;
END_IF;
```


```
U Start
S Run

U Stop
O Fault
R Run
```


----------



## borromeus (31 Oktober 2012)

Wunderbares Beispiel Zotos, Danke!
In welcher Zeit versteht man es nun schneller zur Gänze?

Variante 1
oder
Variante 2

;-)

[x] Variante 2


----------



## zotos (31 Oktober 2012)

50/50 Also ich verstehe beide Varianten zügig zur "Gänze" um bei Deinen Worten zu bleiben. Dies liegt aber wohl daran das ich mit Beiden Sprachen recht viel zu tun habe.
Dennoch sind beide Sprachen in Sachen Bitverknüpfungen KOP/FUP und CFC unterlegen.

Aber Bitverknüpfungen sind halt auch nicht alles ;o)


----------



## Perfektionist (31 Oktober 2012)

Also, ich kann jetzt nicht finden, dass SCL/ST in Sachen Bitverknüpfung KOP/FUP unterlegen wären. Es gibt halt ungeschickte Möglichkeiten, diese Verknüpfungen in SCL/ST darzustellen und eben geeignetere. Aber alle sind auch für mich verständlich. Dagegen ist die Vielfalt wohl eingeschränkter dies in KOP/FUP darstellen zu wollen? Na, ich behaupte mal, auch da lässt sich ein "=" Sachverhalt problemlos in einen "S/R"-Sachverhalt umschreiben. Und es ist halt trotzdem lesbar, auch wenn sich der Leser denkt: "das hätte ich nun anders (einfacher) gemacht".


----------



## borromeus (1 November 2012)

zotos schrieb:


> 50/50 Also ich verstehe beide Varianten zügig zur "Gänze" um bei Deinen Worten zu bleiben. Dies liegt aber wohl daran das ich mit Beiden Sprachen recht viel zu tun habe.
> Dennoch sind beide Sprachen in Sachen Bitverknüpfungen KOP/FUP und CFC unterlegen.
> 
> Aber Bitverknüpfungen sind halt auch nicht alles ;o)



Nun, alleine das SCL zu "lesen" dauert (bei mir) schon länger, da es einfach länger ist. Für mich hat AWL eben Vorteile, auch wenns manchmal (Datenhantierung) umständlich zum programmieren ist. Da ist SCL endeutig besser.

"Dennoch sind beide Sprachen in Sachen Bitverknüpfungen KOP/FUP und CFC unterlegen."
Sehe ich nicht so.... in AWL kann ich neben jede Zeile den Grund dazuschreiben, das liest sich flüssig und aufklärend. In KOP/FUP geht das mal gar nicht! In meiner "Lieblingsdisziplin" CFC (ich programmiere seit Jahren fast nur mehr PCS7 (in Verbindung mit AWL)) ist die Dokumentierfähigkeit- sagen wir mal- alles andere als perfekt aber immer noch weit besser als KOP/FUP.

In dem Punkt "Dies liegt aber wohl daran das ich mit Beiden Sprachen recht viel zu tun habe." hast Du wohl Recht, jedem was ER selbst am Besten kann. In 20 Jahren können sie AWL abschaffen, bis dahin "habe ich fertig", vorher brauch ich es wie einen Bissen Brot.

;-)


----------



## vierlagig (1 November 2012)

Perfektionist schrieb:


> Also, ich kann jetzt nicht finden, dass SCL/ST in Sachen Bitverknüpfung KOP/FUP unterlegen wären.



Stichwort: mit'n Finger die KOP-"Programmierung" nachfahren ... da hat es bei Bit-Verknüpfungen schon enorme Vorteile....


----------



## UniMog (1 November 2012)

vierlagig schrieb:


> Stichwort: mit'n Finger die KOP-"Programmierung" nachfahren ... da hat es bei Bit-Verknüpfungen schon enorme Vorteile....



Stimmt...... im Online Status ist KOP & Co durch nichts zu ersetzen ..... SCL ist da genauso schlecht wie AWL......


----------



## vierlagig (1 November 2012)

UniMog schrieb:


> SCL ist da genauso schlecht wie AWL......



na na na ... durch die ein Befehl pro Zeile Restriktion von AWL ist da der online Status ja schon nahezu übersichtlich!


----------



## UniMog (1 November 2012)

vierlagig schrieb:


> der online Status ja schon nahezu übersichtlich!



ok......nahezu


----------



## UniMog (1 November 2012)

Ich bin auf alle Fälle mal gespannt was es auf der SPS IPC Drives in Punkto TIA neues gibt und

wann ich alle meine Sinamics Komponenten (Simotion Scout ) auch in TIA finde.....


----------



## vollmi (1 November 2012)

zotos schrieb:


> ```
> U Start
> S Run
> 
> ...



Ich lauf leider oft an Software ran die sehen dann so aus:

```
U M10.0
S M11.0

U M10.1
O M10.2
R M11.0
```

So kommentar und Symbollos 

Aber ich persönlich kann SCL viel abgewinnen, vor allem seit ich das mal auf Wago in Codesys2 verwenden durfte, wirklich genial, einfach und umfangreiches onlinedebugging möglich.

Bei Siemens würde ich es viel öfter verwenden und es gefällt mir auch da. Aber das Onlinedebugging vor allem von FBs als Multiinstanzen ist schlicht und einfach unbrauchbar. Oder ich bin einfach zu blöd genau diesen einen Baustein unter hundert aufrufen online zu betrachten.

Aber ich glaub unter TIA wird das SCL onlinedebuging deutlich besser behandelt.

mfG René


----------



## sailor (2 November 2012)

vollmi schrieb:


> Aber ich persönlich kann SCL viel abgewinnen, vor allem seit ich das mal  auf Wago in Codesys2 verwenden durfte, wirklich genial, einfach und  umfangreiches onlinedebugging möglich.
> 
> Bei Siemens würde ich es viel öfter verwenden und es gefällt mir auch  da. Aber das Onlinedebugging vor allem von FBs als Multiinstanzen ist  schlicht und einfach unbrauchbar. Oder ich bin einfach zu blöd genau  diesen einen Baustein unter hundert aufrufen online zu betrachten.



Hi,

Was ist denn dann mit Online-Änderungen (Online-Change) bei CoDeSys/Beckhoff und Konsorten? Schon aus diesen Grund ein absolutes NOGO!!!!!
Onlinedebugging von Multiinstanzen ist kein Problem, soweit man das überhaupt braucht --> mach mal ne Weiterbildung.
Es gibt ja soooo viele Wartungsleute und "Feldinbetriebnehmer", die SCL können !!!!!
FUP  ist ja schön und gut, vor allen für die o.a. Leute, aber man muss bei  komplexeren Aufgabe doch immer wieder auf AWL ausweichen. Ausserdem gibts keinen Kommentar.
Also warum nicht gleich alles in AWL!? Sauber kommentiert mit aussagekräftiger Symbolik? Ich kenne keinen Nachteil von AWL. Mit sauberen und klaren Code das Ideal!
Hier gibts zu viele Theoretiker auf Wolke 7!

Gruß aus Bayern

Sailor


----------



## zotos (2 November 2012)

Hallo  		sailor,
bist du der kleine Bruder von unserem maxi?


----------



## UniMog (2 November 2012)

Und mit SCL wird aus dem Mist der intelligentere Mist...... 
Viele verwechseln ereignisorientierte Programmierung aus Windows und Co. mit der SPS...... besonders Master, Bachelor usw. 
die eigentlich erstmal 20 Jahre Berufserfahrung nach dem Studium brauchen bevor man mit den was anfangen kann......


----------



## MSB (2 November 2012)

sailor schrieb:


> Hi,
> 
> Was ist denn dann mit Online-Änderungen (Online-Change) bei CoDeSys/Beckhoff und Konsorten? Schon aus diesen Grund ein absolutes NOGO!!!!!
> Onlinedebugging von Multiinstanzen ist kein Problem, soweit man das überhaupt braucht --> mach mal ne Weiterbildung.
> ...



- Onlineänderungen von Codesys, OK ist ab einem gewissen Punkt ein Problem, hier wäre durchaus noch potential
- Onlinedebugging von Multiinstanzen ist bei Step7 ziemlich kompliziert gelöst, bei SCL sogar noch komplizierter, bei Codesys hingegen so simpel als möglich
- Diese sog. Leute sollten vielleicht mal ein wenig offener an die Sache rangehen, oder die von dir beschriebene "Weiterbildung" machen
- Wenn deine oben genannten Leute die komplexere AWL-Aufgabe verstehen, dann würden die sich bei SCL wohl sinngemäß denken "Wow ist das einfach"
- Jetzt mal ganz ehrlich: Wieviele Netzwerke "sauberem und klaren" AWL-Code kennst du? Berechnungen, Datenhandling all das ist mit SCL ziemlich sicher leichter lesbar und somit leichter nachvollziehbar

Gruß, ebenfalls aus Bayern
Manuel


----------



## Zersch (2 November 2012)

> besonders Master, Bachelor usw.
> die eigentlich erstmal 20 Jahre Berufserfahrung nach dem Studium brauchen bevor man mit den was anfangen kann......



Vorweg, ich bin auch einer von denen, die laut deiner Meinung 20 Jahre Berufserfahrung brauchen.
Mich würde interessieren, woher du die Gründe nimmst, diese Aussage zu treffen.


----------



## Ralle (2 November 2012)

@Alle
Wir hatten diese und ähnliche Diskussion doch schon so oft, langsam sollte jedem klar sein, dass so etwas eher einem Religionsstreit gleichkommt. Man sollte dem anderen zuhören, seine Argumente versuchen zu verstehen aber nicht versuchen, ihn um jeden Preis zu bekehren, das geht i.d.R. eh nicht gut. Wer 20 Jahre AWL-Erfahrung hat, der findet das nicht so schwer und OOP ist dann oft für ihn konzeptionell nicht wirklich klar, denn wir programmieren im Grunde immer schön linear. Die neue Generation der Programmierer wird anders ausgebildet und kennt andere Herangehensweisen, welche besser ist, muss sich noch herausstellen, vielleicht kann man das nicht mal so genau sagen, ein schlechter Programmierer wird auch mit guten Tools viel Mist produzieren. Die ganze Computerentwicklung geht nun mal immer mehr zu Clickibunti, siehe WIN8. Wenn heute eine Visualisierung einen einfachen grauen Windows-Btn hat, dann kann man damit keine Maschine mehr steuern, es muß schon 3D-Design her, denkt so mancher, aber das liegt nun mal daran, dass er damit aufgewachsen ist. Anders herum ist es für so manchen schwierig, sich in die einfachen Niederungen einer "simplen" Produktionsmaschine zu begeben. Jede Gerneration an Programmierern muss ihren Weg finden, das wird auch klappen. Aber ich bin mir ziemlich sicher, dass in 50 Jahren kaum noch einer in der Lage sein wird mit einer einfachen Schützschaltung und ein paar Kabeln einen Blinker oder eine Wendeschützschaltung aufzubauen, dazu braucht es dann 10 GByte große Softwaretools und OOP, aber so ist nun mal die Entwicklung, ich mag inzwischen auch nicht mehr um jeden Preis mit einem PG675 ans Werk gehen.

PS: Wir sehen ja die Entwicklung im Forum, immer wieder kommen Leute und fragen nach fertigen Bausteinen für wirklich simple Funktionen.


----------



## zotos (2 November 2012)

Ralle schrieb:


> ...
> Wer 20 Jahre AWL-Erfahrung hat, der findet das nicht so schwer und OOP ist dann oft für ihn konzeptionell nicht wirklich klar...



Ich denke Du wirfst da etwas durcheinander. AWL, SCL usw sind Programmiersprachen. OOP ist ein Konzept welches sich mit der Abbildung von Objekten die aus Daten und Funktionen bestehen. 

In diesem hier vorherrschenden Glaubenskrieg erinnert mehr an Assembler vs Hochsprache. 

Hochsprachen wurden entwickelt um die Programmierung zu vereinfachen und fremde Programme leichter verständlich zu machen. Die Kontrollstrukturen (IF THEN ELSE, CASE, Schleifen) und der Zugriff auf Arrays mit Index basierendem Zugriff, sind nun mal leichter verständlich als die Springerei und unsägliche pointerei in AWL. 
Warum Siemens es nicht auf die Reihe bekommen hat Array in AWL einfach per Index anzusprechen und die Pointer etwas übersichtlicher zu gestalten ist mir ein Rätsel.

Hier im Forum gibt es nun mal Anwender die unterschiedliche Aufgaben lösen müssen. Vielen die einen machen simple Bitverknüfungen und einfache Ablaufsteuerungen, die anderen müssen halt noch einiges an Datenhandling bewältigen und Kommunikationen zu Fremdsystemen aufbauen.

Wobei die Akzeptanz gegenüber SCL in den letzten Jahren deutlich gestiegen ist und dieser Prozess geht wohl weiter.


----------



## Ralle (2 November 2012)

zotos schrieb:


> Ich denke Du wirfst da etwas durcheinander. AWL, SCL usw sind Programmiersprachen. OOP ist ein Konzept welches sich mit der Abbildung von Objekten die aus Daten und Funktionen bestehen.
> 
> In diesem hier vorherrschenden Glaubenskrieg erinnert mehr an Assembler vs Hochsprache.
> 
> ...



Ne, ich werfe da nichts durcheinander, die Frage nach OOP kommt ja auch in allen möglichen Threads immer wieder mal hoch und das habe ich eben auch gleich mit aufgegriffen und die ganze Sache etwas vereinfachend darauf zugespitzt. Die Erkenntnis, dass eine Aufgabe auch mit einer der einen oder anderen Sprache besser zu erledigen ist, setze ich nun wirklich langsam voraus, auf dem Niveau brauchen wir nun wirklich nicht mehr zu diskutieren, denke ich.

Und Assembler oder Hochsprache oder/und OOP, ist ja nun als Vergleich nicht so falsch.


----------



## Boxy (2 November 2012)

Man sollte auch nicht immer nur von sich selbst ausgehen und somit auf andere schließen.
 D.h. AWL/SCL und ST können natürlich wenn die Anweisungen einfach gehalten werden von sehr vielen leicht gelesen werden.
 Es geht natürlich auch so, da man nix lesen kann. Habe da selbst dies erfahren müssen, weil einfach keine Aussagekräftigen Variablenbezeichner Verwendung finden und weil es total umständlich programmiert wird (sage einmal die Kollegen haben da einfach zu wenig Erfahrung in der Entwicklung). Dann ist der Effekt des einfacheren schon wieder weg und schlägt um!

 Allerdings sollte man nach meinem Empfinden ggf. auch einmal an die Instandhalter usw. bei Kunden denken welche z.B. 5 oder 10 versch. Systeme warten müssen.
 Beginnt doch auch schon wenn diese die Maschinen von versch. Herstellern warten müssen. Da helfen dann solche Sprachen wie FUP oder KOP für diese sehr viel!

 In meinen Augen wird es halt so sein, das AWL nicht "tot" sein wird und SCL/ST mehr kommen wird.
 Es wird aber eher ne Kombi aus allem werden, bzw. die Möglichkeit dies in einem Baustein zu verwenden!

 Hoffe auch, das Big S sich bei einigen Dingen von CoDeSys beeinflussen lässt und paar weiter Dinge implementiert ...
 Dinge wie Pointer ist wie oben schon geschrieben worden ist, bei Siemens halt doch nicht einfach zu lesen 

 Aber auch noch zum Themen Tittel, AWL wird auch in Zukunft bei "S" vorhanden sein.
 Man hat ja auch mitte der 90'er Jahre gesagt S5 sei tot! Aber da hat wohl keiner an die weit verbreiteten Anlagen und Steuerungen gedacht welche da im Feld sind!
 S5 lebt auch heute noch und lebt auch noch länger! Genau so wird es mit den S7 Steuerungen und den Maschinen gehen!
 Daher wird es eine kontinuierliche Veränderung der Sprache AWL bei Big S sein ...


----------



## Perfektionist (5 November 2012)

vierlagig schrieb:


> Stichwort: mit'n Finger die KOP-"Programmierung" nachfahren ... da hat es bei Bit-Verknüpfungen schon enorme Vorteile....


Das hat unser werter Kollege Stollentroll auch schonmal so festgestellt.

Naja, Videotelefonie wird dieses "mit dem Finger nachfahren" ja in Zukunft sehr erleichtern.

Wie lange gibts schon Video-Telefonie?

...bin ich froh, dass ich in dieses Forum mit Worten schreiben darf - ich könnt kein Comic zeichnen (obwohl: unsere Vorfahren, die in Höhlen lebten, wir wissen nicht sicher, ob sie eine Sprache hatten. Aber bildliche Darstellungen konnte sie).


----------



## Perfektionist (5 November 2012)

Ralle schrieb:


> Ne, ich werfe da nichts durcheinander, die Frage nach OOP kommt ja auch in allen möglichen Threads immer wieder mal hoch und das habe ich eben auch gleich mit aufgegriffen und die ganze Sache etwas vereinfachend darauf zugespitzt. Die Erkenntnis, dass eine Aufgabe auch mit einer der einen oder anderen Sprache besser zu erledigen ist, setze ich nun wirklich langsam voraus, auf dem Niveau brauchen wir nun wirklich nicht mehr zu diskutieren, denke ich.
> 
> Und Assembler oder Hochsprache oder/und OOP, ist ja nun als Vergleich nicht so falsch.


KOP und FUP sind sterbende Sprachen. Latein aus einem vorherigen Jahrhundert. Von KOP ist heut grad mal noch ne NOT-AUS-Verkettung übrig, von den TTL-CMOS-OPAMP-Jogis gibts nur noch angegraute Figuren.

Assembler proggt heut auch schon kaum einer mehr auf einem Microcontroller.

OOP ist ein Konzept. Hat nichts damit zu tun, welche Sprache man nutzt. Aber es gibt Sprachen, die das besser unterstützen als andere. Und Entwicklungsumgebungen, die das besser unterstützen. Der IDB des S7 war ein wichtiger Schritt dazu. davor musste man das händisch erledigen, z.B. die Temps in Schmiermerkern ablegen, und dort landeten auch die IN/OUT.


----------



## floppy (6 November 2012)

Perfektionist schrieb:


> KOP und FUP sind sterbende Sprachen. Latein aus einem vorherigen Jahrhundert. Von KOP ist heut grad mal noch ne NOT-AUS-Verkettung übrig



Sterbend evtl ja, aber noch sehr lange nicht tot! Wir haben Anlagen in Betrieb die größtenteils in SCL / AWL  geschrieben sind. Und auch da gibt es FUP / KOP Bausteine. Es ist ja einfach übersichtlicher als andere Sprachen bei "Kleinigkeiten" - jedenfalls online. 
Mich ärgert  immer, bei awl, das man die VKE´s manchmal nicht gut sehen kann - war´s jetzt E1.0 oder E1.1 der kurz weg ging? Bei FUP sieht auch ein kurzsichtiger Instandhalter was grün ist und was nicht 
Aber, so traurig das ist, sehe ich ein das AWL und SCL bei größeren NW und vor allem bei etwas komplizierteren Dingen besser zu schreiben und besser zu lesen sind.
Aber bitte, liebe Profi-SPSler, haltet Euch mit Pointern zurück. Egal in welcher Sprache


----------



## bike (6 November 2012)

Man kann mit SCL Code schreiben, den kein Mensch versteht, so wie auch in AWL.
Es kommt wie meist auf den Programmierer an.

Dass FUP und KOP tot sind, wird seit Beginn von S7 erzählt.
Zu Beginn gab es kein FUP und jetzt? In TIA oder Codesys ist es vollständig integriert.


bike


----------



## Perfektionist (6 November 2012)

bike schrieb:


> Man kann mit SCL Code schreiben, den kein Mensch versteht, so wie auch in AWL.
> Es kommt wie meist auf den Programmierer an.


wie oft noch: es ist immer möglich, in jeder Sprache mit jedem Entwicklungswerkzeug Sachen zu stricken, dass ein Anderer die Hände überm Kopf zusammen schlägt. Was also ist Deine Aussage?



bike schrieb:


> Dass FUP und KOP tot sind, wird seit Beginn von S7 erzählt.
> Zu Beginn gab es kein FUP und jetzt? In TIA oder Codesys ist es vollständig integriert.


ja, warum gab es kein FUP? weil die Klappertechnik vor der Käfertechnik da war. Die Elektroniksteuerungsgötter der ersten Stunde haben dann mit Begeisterung FUP in die SPS-Welt rübergeholt. KOP war für die, die nur Relais kannten und entsprechend wenig neuer Möglichkeiten nutzen wollten/konnten, FUP für die, die eben schon mit Gattern OPAMP mehr gemacht haben, als mit Klappertechnik ging, AWL war das Werkzeug für Leute, die mit Aufkommen der Mikroprozessoren in Maschinesprache zu fassen in der Lage waren, einen Ablauf zu steuern.

tot ist davon noch nichts, weil es eben in der Lage ist, virtuell weiterleben zu können.

selbst für 8085-Code gibt es noch heute Microcontroller - ob der heute noch nativ ausgeführt wird?

...aber die Erde dreht sich weiter. FUP hat zwar überlebt, S7-Basis hatte kein SCL, V11 gibt es ohne SCL nicht mehr.

Man darf ja das alte bewahren - muss es bisweilen sogar. Wenn ich jedoch mal die Chance habe, etwas grundsätzlich neues anpacken zu dürfen, dann denke ich persönlich jedoch sehr intensiv darüber nach, was von dem alten ich noch brauche oder möglicher Weise nur noch Ballast darstellt, der nur unnötige Vielfalt sein könnte.

In Classic haben schon zu Handquetschzeiten sich die AWLer Gedanken darüber gemacht, wie der Code zu schreiben ist, dass er sich sowohl in KOP wie auch in FUP alternativ darstellen lässt. SCL stellt nun die Instandhaltungen von Produktionsfirmen vor neue Herausforderungen. Oder die Maschinenhersteller vor die Herausforderung, endlich Programme zu schreiben, die nicht mehr vom Kunden mit dem Entwicklungssystem debugt werden müssen.


----------



## Larry Laffer (6 November 2012)

Hatte Ralle nicht ein paar Beiträge zurück (#35) auf m.E. charmante Weise von einem "Glaubenskrieg" geschrieben ?
An dieser Aussage hat sich nach meinem Dafürhalten nichts geändert.
Richtig und Falsch bzw. Besser und Schlechter liegen hier (wie auch bei vielen anderen Threads dieser Art) im Auge des jeweiligen Betrachters.
Etwas, was von der Machart her für (z.B.) Bike gut und richtig ist braucht für (z.B.) Perfektionist nicht automatisch auch gut und richtig sein. Das heißt dann aber auch nicht, dass der Eine oder Andere in seinen Ansichten falsch liegt - es ist eben so.

Meiner Ansicht nach führt diese Diskussion in dieser Weise zu Nichts ...

Gruß
Larry


----------



## Django2012 (6 November 2012)

> Allerdings sollte man nach meinem Empfinden ggf. auch einmal an die  Instandhalter usw. bei Kunden denken welche z.B. 5 oder 10 versch.  Systeme warten müssen.
> Beginnt doch auch schon wenn diese die Maschinen von versch.  Herstellern warten müssen. Da helfen dann solche Sprachen wie FUP oder  KOP für diese sehr viel!


Mööööp. Als das hört sich jetzt so an als könnten Instandhalter nur FUP & KOP lesen.  Mag vielleicht bei manchen Firmen so sein, bei uns definitv nicht. 
Manchmal versteh ich auch nicht wie sich das einige so vorstellen.    Was sollen die Leute denn machen wenn eine Maschine nicht mehr in Garantie ist und etwas nicht mehr funktioniert? Nen Programmierer anrufen ?  Sorry aber gibt´s das wirklich?   Also bei uns in der Firma ist jeder  in AWL, GRAPH , FUP und bisschen SCL so fit, das er die Anlagen wieder in gang bringt.    Vor allem mit AWL wurde von den "alten Hasen" viel gelernt. 
Aber man sollte auch nicht unmögliches verlangen... Pointer usw. in AWL ist eine Sache,   jedoch die "Hochsprachenkonzpete" (OOP,  Scripte, usw usw. ) wird von jmd. der einfach mal "Elektriker" gelernt hat irgendwann zum Verhängniß.


----------



## Perfektionist (6 November 2012)

Larry Laffer schrieb:


> Hatte Ralle nicht ein paar Beiträge zurück (#35) auf m.E. charmante Weise von einem "Glaubenskrieg" geschrieben ?
> ...
> Das heißt dann aber auch nicht, dass der Eine oder Andere in seinen Ansichten falsch liegt - es ist eben so.
> 
> ...


Diskussion ist, Gründe für die eigene Ansicht anführen zu können. Meinungen zu teilen und damit ggf. die eigene Sicht der Dinge zu korrigieren.

Glaubenskrieg ist, mit dem Totschläger "das ist so" stur auf seiner Meinung (seinen Stereotypen) unverrücklich zu beharren.


----------



## bike (7 November 2012)

Ich denke Larry hat recht.
Eine unversielle Lösung für alle Anforderungen und Aufgaben gibt es nicht, daher verschiedene Werkzeuge.

Und, ich habe bisher keinen stichhaltigen Grund gelesen warum KOP, FUP oder AWL keine Daseinsberechtigung haben.


bike


----------



## rostiger Nagel (7 November 2012)

Das stimmt, in der F-Technik wäre es fatal in SCL oder AWL zu Programmieren.


----------



## Perfektionist (7 November 2012)

bike schrieb:


> Und, ich habe bisher keinen stichhaltigen Grund gelesen warum KOP, FUP oder AWL keine Daseinsberechtigung haben.


um daraus eine Diskussion zu machen, setze Dich halt mal mit den nicht stichhaltigen Gründen auseinander. Wozu also FUP, wenn man das alles in KOP auch kann, was FUP kann.

Warum mit einem dreifach ausgestatteten Werkzeugkoffer rumrennen, wenn man 90% der Aufgaben optimal mit einem Leatherman ausführen kann, die restlichen 10% zwar nur suboptimal, aber dennoch...

Es gibt immer das zu seiner Zeit optimale Werkzeug. Wenn ich meine Aufgaben zu 90% bequem mit dem zeitgemäßen Werkzeug erledigen kann, tue ich das nach Möglichkeit. Falls es bei den restlichen 10% Schwierigkeiten gibt, die altes Werkzeug noch instande war, zu überwinden, dann kommt ausnahmsweise wieder das alte zum Zug. Daseinsberechtigung ja, so wie eben die Apotheker und Pfarrer noch Latein und sonstige sterbende Sprachen benutzen.

*AchtungPolemik* was soll ich mit Latein, Althebräisch, Aramäisch und Altgriechisch. Aus uralten Geschichts- und Gesetzestexten vorlesen, die schon tausendfach übersetzt wurden? Das hat Luther bereits getan. Es gibt jedoch sogar heute noch Menschen, die das Neue Testament noch nicht wirklich zu Kenntnis genommen haben. Und für ihr unsichtbares rosafarbenes Einhorn sogar zu Morden fähig sind, weil sie mit der Möglichkeit, dass es eventuell nicht existieren könne, nicht zurecht kommen. Und keine Alternative sehen, ohne es zurechtkommen zu können.


----------



## Perfektionist (7 November 2012)

rostiger Nagel schrieb:


> Das stimmt, in der F-Technik wäre es fatal in SCL oder AWL zu Programmieren.


wobei ich Dir versichern kann, dass weder Betriebssystem noch der Microprozessormicrocode noch der Compiler und/oder Interpreter in KOP/FUP formuliert sind. Halt eben von Leuten, die das anders machen können. Und es ist so sicher wie das Amen in der Kirche, dass auch mal Fehler in F-CPUs nachweisbar auftauchen werden. So, wie auch die angeblich so sichere Kernenergietechnik von Zeit zu Zeit versagt, was natürlich in der Ukraine für möglicher gehalten wird als in Fukoshima.


----------



## Larry Laffer (7 November 2012)

Sorry ... ich kann es mir nicht verkneifen ...

Also erstmal sind KOP und FUP (und auch SCL) "nur" Darstellungsformen des gemeinsamen Grundcodes, der starke Ähnlichkeit mit AWL hat - somit könnte man mit ein bißchen Fantasie ggf. auch das Betriebssystem in KOP oder FUP darstellen (ob es Sinn machen würde ist da eine andere Frage).

Und dann meine Frage an dich "Perfekter" (Nomen est Omen ?) :
Was möchtest du uns denn mitteilen bzw. zu was möchtest du uns (ich schließe mich da jetzt mal mit ein) denn nun bekehren ? Was ist der tiefere Sinn dieses Teils der Diskussion ?

Gruß
Larry


----------



## rostiger Nagel (7 November 2012)

@Perfekter,
ich möchte nicht in einen Fahrstuhl, Karusell oder Seilbahn sitzen, wo ein Programmierer in F-Technik mal
eben Fehlersicherer Signale mit einen Zeiger in AWL oder SCL verbiegt. Ich finde eine Grafisch Orientierte
Programmierung für F-Technik nicht ganz so verkehrt.


----------



## borromeus (7 November 2012)

Ich denke man sollte nutzen was vorhanden ist, ein guter Programmierer wird ein Problem mit dem richtigen (passenden) Tool (KOP, FUP, AWL, SCL, SFC, CFC,....) und je nach Plattform (und auch Kundenwunsch) umsetzen. 
Drum sollte ein guter Programmierer auch den gesamten Bereich abdecken können. Zwei gute Programmierer werden jedoch nicht ZWANGSWEISE dasselbe Tool verwenden- weil auch Geschmackssache.
Jegliche "Überzeugungsarbeit" geht hier- zwischen Experten- ins absolut Leere!

Und ich denke mehr gibts  dazu nicht zu sagen.


----------



## Perfektionist (7 November 2012)

Larry Laffer schrieb:


> Und dann meine Frage an dich "Perfekter" (Nomen est Omen ?) :
> Was möchtest du uns denn mitteilen bzw. zu was möchtest du uns (ich schließe mich da jetzt mal mit ein) denn nun bekehren ? Was ist der tiefere Sinn dieses Teils der Diskussion ?


reiner Selbstzweck. Ich will SCL/ST verwenden, andere Leute nicht. Und ich hab keine Lust, eine Maschine, die ich einmal fertigprogrammiert habe, auch noch in KOP und FUP umcoden zu müssen. Und wenn dann auch noch Rockwell oder CoDeSys ansteht, dann mag ich nicht auch wieder alles neu erfinden müssen. Nun sammle ich anhand dieser Diskussion Erfahrung, um meinen ganz persönlichen Glaubenskrieg durchfechten zu können. Das ist der Selbstzweck hinter dieser Diskussion. Vielleicht liest sogar einer meiner Kunden hier mit. Dann hab ich entweder bereits hier Vorarbeit geleistet oder einen Kunden weniger. Aber AWL hab ich auch durchgeboxt bekommen, als ich von S5 auf S7 gewechselt bin. Der Kollege, der bei KOP blieb, wunderte sich dann, warum meine Programme so laufzeiteffizient waren und sind.

So, nun boxe ich für SCL, da die Zeit reif ist, überreif. Reiner Selbstzweck...



rostiger Nagel schrieb:


> @Perfekter,
> ich möchte nicht in einen Fahrstuhl, Karusell oder Seilbahn sitzen, wo ein Programmierer in F-Technik mal
> eben Fehlersicherer Signale mit einen Zeiger in AWL oder SCL verbiegt. Ich finde eine Grafisch Orientierte
> Programmierung für F-Technik nicht ganz so verkehrt.


 Auch mit KOP und FUP kann man Fehler programmieren. Und jemand, der wild im Programm rumpointert statt sauber zu kapseln, dem traue ich auch in einer fehlersicheren Umgebung zu, mit KOP/FUP ganz sicher ausgeführte Fehler einbauen zu können.



borromeus schrieb:


> Ich denke man sollte nutzen was vorhanden ist, ein guter Programmierer wird ein Problem mit dem richtigen (passenden) Tool (KOP, FUP, AWL, SCL, SFC, CFC,....) und je nach Plattform (und auch Kundenwunsch) umsetzen. Drum sollte ein guter Programmierer auch den gesamten Bereich abdecken können. Zwei gute Programmierer werden jedoch nicht ZWANGSWEISE dasselbe Tool verwenden- weil auch Geschmackssache.
> Jegliche "Überzeugungsarbeit" geht hier- zwischen Experten- ins absolut Leere!


Da sehe ich Parallelen zu der Mechatroniker-Diskussion. Demzufolge bin ich der Meinung, dass sich ein jeder in Richtung seiner persönlichen Präferenzen entwickeln können sollte. Das Verharren im und Bewahren des alten ist dabei m.E. einer Weiterentwicklung im Weg.


----------



## bike (7 November 2012)

Perfektionist schrieb:


> um daraus eine Diskussion zu machen, setze Dich halt mal mit den nicht stichhaltigen Gründen auseinander. Wozu also FUP, wenn man das alles in KOP auch kann, was FUP kann.



Also da ist je nach Lust, Laune und Vorgaben.
Ich sehe keinen Grund auf die grafischen Editoren zu verzichten.
Ein Bild sagt mehr als tausend Worte.


bike


----------



## Aventinus (7 November 2012)

Bilder wo Bilder sinnvoll sind.

Darum wurden KOP, FUP, GRAPH  und CFC erfunden. Und wo SCL und AWL sinn machen sollte man eben SCL und AWL einsetzten. Ich bin auch für sinnvolle Kapselung - was ja grundsätzlich mal einen Touch von Objektorientierung hat.

Ich sehe aber auch die Gefahr, dass man alles übertreiben kann:
[ironie]
Wenn nicht die blöde Beschränkung auf 64kB pro DB wäre würde ich die ganze Anlage in einem FB proggen. Alles schön multiinstanziert...
[/ironie]


----------



## Perfektionist (7 November 2012)

bike schrieb:


> Ein Bild sagt mehr als tausend Worte.


deswegen haben die Menschen zuerst gelernt, an Höhlenwände zu malen. Und irgendwann wurde es ihnen im Dekalog schriftlich untersagt, sich ein Bild von Gott machen zu wollen. Ein Bild kann verständlicher sein, wenn man gelernt hat, es zu lesen. Und es geeignet ist, einen Sachverhalt verständlicher darzustellen.



Aventinus schrieb:


> [ironie]
> Wenn nicht die blöde Beschränkung auf 64kB pro DB wäre würde ich die ganze Anlage in einem FB proggen. Alles schön multiinstanziert...
> [/ironie]


Da muss ich sagen, ist es gut, diese Aussage als Ironie zu kennzeichnen. Denn ich verstehe Deine Ironie nicht, ich würde es wirklich so machen.


----------



## Larry Laffer (7 November 2012)

Perfektionist schrieb:


> Da muss ich sagen, ist es gut, diese Aussage als Ironie zu kennzeichnen. Denn ich verstehe Deine Ironie nicht, ich würde es wirklich so machen.



Das schockt mich jetzt ein bißchen, da es sich mit deinen sonstigen (nach eigener Aussage) fortschrittlichen Ideen komplett widerspricht.

Ansonsten bin ich auch jemand, der für sich und seine Firma feste Prinzipien bei der Erstellung und Ausführung von Programmen hat. Ich würde aber nicht jemanden (es sein denn er arbeitet für mich - dann ist es komplett etwas Anderes) bekehren wollen. Ich denke, da reicht es Tipps zu geben und ggf. seine eigene Denkweise vorzustellen ... Aber das ist - denke ich - in diesem Thread ja schon ganz gut praktiziert worden ...

Gruß
Larry


----------



## UniMog (7 November 2012)

rostiger Nagel schrieb:


> @Perfekter,
> Ich finde eine Grafisch Orientierte
> Programmierung für F-Technik nicht ganz so verkehrt.



Nicht nur in der F-Technik..... auch sonst



Perfektionist schrieb:


> Aber AWL hab ich auch durchgeboxt bekommen, als ich von S5 auf S7 gewechselt bin. Der Kollege, der bei KOP blieb, wunderte sich dann, warum meine Programme so laufzeiteffizient waren und sind.



Denke das Dein Kollege das mit AWL auch nicht geschafft hätte..... hat nichts mit KOP oder FUP zu tun.
Und wenn du Programme mit so zeitkritischen Abläufen hast die sich mit KOP oder FUP nicht machen lassen ....... davon hätte ich gerne mal ein Stück per eMail.... 



Perfektionist schrieb:


> So, nun boxe ich für SCL, da die Zeit reif ist, überreif. Reiner Selbstzweck...



Ja mir gefällt SCL auch....... aber dort wo es meiner Meinung nach Sinn macht........ also nicht alles in SCL



Perfektionist schrieb:


> Auch mit KOP und FUP kann man Fehler programmieren. Und jemand, der wild im Programm rumpointert statt sauber zu kapseln, dem traue ich auch in einer fehlersicheren Umgebung zu, mit KOP/FUP ganz sicher ausgeführte Fehler einbauen zu können.



100% ACK........



Perfektionist schrieb:


> Da sehe ich Parallelen zu der Mechatroniker-Diskussion. Demzufolge bin ich der Meinung, dass sich ein jeder in Richtung seiner persönlichen Präferenzen entwickeln können sollte. Das Verharren im und Bewahren des alten ist dabei m.E. einer Weiterentwicklung im Weg.



Mechatroniker ?? Das sind doch die Jungs die von allem etwas können ... lach ne Spaß. 



Perfektionist schrieb:


> Das Verharren im und Bewahren des alten ist dabei m.E. einer Weiterentwicklung im Weg.



Stimmt aber nur auf SCL verharren ist auch nicht das Non plus ultra........


----------



## Perfektionist (7 November 2012)

Larry Laffer schrieb:


> Das schockt mich jetzt ein bißchen, da es sich mit deinen sonstigen (nach eigener Aussage) fortschrittlichen Ideen komplett widerspricht.


ich verstehe immer noch nicht...
Wo ist die Ironie? Wenn man von der 64k-Grenze absieht, spricht doch nichts dagegen, alles in eine Multiinstanz zu packen ???
Oder gehts um die Gliederung? dafür sind doch die einzelnen FB gegeben.
Oder ist hier jemand der Meinung, dass 64k grundsätzlich immer und für alles ausreichend sind?



Larry Laffer schrieb:


> Ansonsten bin ich auch jemand, der für sich und seine Firma feste Prinzipien bei der Erstellung und Ausführung von Programmen hat. Ich würde aber nicht jemanden (es sein denn er arbeitet für mich - dann ist es komplett etwas Anderes) bekehren wollen. Ich denke, da reicht es Tipps zu geben und ggf. seine eigene Denkweise vorzustellen ...


programmiert Ihr Eure Produktionsanlagen ausschliesslich selbst? Gibt es keine Kundenwünsche? Gibt es keine Lieferanten, die was anders machen würden, würde man sie nur lassen?


----------



## MSB (7 November 2012)

Perfektionist schrieb:


> So, nun boxe ich für SCL, da die Zeit reif ist, überreif. Reiner Selbstzweck...


Was ich mich jetzt seit ca. 25 Beiträgen (wenigstens) frage,
wenn du so auf SCL stehst, dann verwende es und gut is.

SCL gibt es jetzt lauffähig seit wenigstens 10 Jahren, und strenggenommen hätte es das sogar bei der S5 schon gegeben.
SCL ist ebenfalls seit diesen 10 Jahren quasi unverändert, lediglich unter der Haube, bei der Codeerzeugung des Compilers wurde mehr oder weniger umfangreich geändert bzw. optimiert.
Was haben wir, Siemens, oder sonstwer jetzt also damit zu tun, das du mindestens 10 Jahre lang deinem selbst definierten Fortschritt hinterhergelaufen bist?
Das allereinzige was bei TIA jetzt anders, und auch besser ist: Der Editor ist nicht mehr nur ein 08/15 Texteditor.

Was das mit einem evtl. Wegfall von AWL, der ja ursprünglich mal Thema des Threads war, 
OOP, oder sonst irgend was vermeintlich fortschrittlichen zu tun hat,
weiß ich nicht, und es ist mir in der hier diskutierten Form auch absolut egal.

Fakt ist und bleibt weiterhin, das Siemens "ihr" AWL nicht sterben lassen können,
sonst würden Sie sich endgültig den ohnehin dünner werdenden Ast auf dem Sie sitzen absägen.

Fakt ist weiterhin:
Ich habe in jeder Programmiersprache oder auch Darstellungsart (um wirklich jeden zu befriedigen) 
gutes sowie grausames gesehen, ich habe sogar schon absolut verhunzte Graph-Schrittketten gesehen.
Who cares, das ist und bleibt kein Kriterium was pauschal fürs eine geschweige denn fürs andere spricht.

Fakt ist auch:
Dieser Thread wurde von Markus für das SPS-Magazin vorgeschlagen,
so wie er sich im Moment liest, taugt er bestenfalls noch für den leider unsichtbaren S..Vergleich.

Mfg
Manuel


----------



## Oberchefe (7 November 2012)

> Und wenn du Programme mit so zeitkritischen Abläufen hast die sich mit  KOP oder FUP nicht machen lassen ....... davon hätte ich gerne mal ein  Stück per eMail....



an mich bitte auch


----------



## Ottmar (7 November 2012)

Hi!

Ich denke wir alle können doch dankbar sein, dass jeder seine "Lieblingsprogrammiersprache" verwenden kann.
So wie jeder Programmierer anders denkt, so frei wählt er auch das Werkzeug mit dem er diese Denke umsetzt.

Auch wenn ich AWL nie gerne mochte (manche Dinge ließen sich damit schon besser/übersichtlicher machen) schaute ich schon doof als ich es bei TIA nicht mehr fand.
Vielleicht sieht Siemens SCL als Nachfolger von AWL - hier bin ich mir aber sicher, dass sie falsch gedacht haben und dass AWL in TIA bald wieder Einzug hält.


gruß,

Ottmar


----------



## rostiger Nagel (7 November 2012)

AWL gibt es doch in TIA, nur nicht für die 1200er!


----------



## Perfektionist (7 November 2012)

MSB schrieb:


> Fakt ist und bleibt weiterhin, das Siemens "ihr" AWL nicht sterben lassen können,
> sonst würden Sie sich endgültig den ohnehin dünner werdenden Ast auf dem Sie sitzen absägen.


Der dickste Ast, auf dem m.E. Siemens sitzt, ist doch gerade die Instanzierbarkeit. AB/Rockwell scheint das nicht können zu wollen - zumkindest nach den Antworten, die ich auf entsprechende Fragen hin bekam. Wie weit CoDeSys damit ist? k.A., hab ich bislang auch noch nichts drüber gelesen.

Siemens´ IDB ist doch wegweisend. wo gibts das anderswo? Das Konzept ist doch unabhängig von KOP/FUP/AWL/Graph/SCL nutzbringend? ...wenigstens für mich...


----------



## Oberchefe (7 November 2012)

> AB/Rockwell scheint das nicht können zu wollen -  zumkindest nach den Antworten, die ich auf entsprechende Fragen hin  bekam.


dann ist Dein "Wissen" schon ein paar Jahre alt, Stichwort "AOI",
Du scheinst auch viel nach "Hörensagen" zu beurteilen, mache persönlich AB seit fast 20 Jahren, S7 und Codesys noch nicht ganz so lange


> Wie weit CoDeSys damit ist?


Schon mal über den Tellerrand geschaut?



> Siemens´ IDB ist doch wegweisend.


Träum weiter, Stichwort SCL und Online beobachten


----------



## MSB (7 November 2012)

Falsch, in meinen Augen!

Der dickste Ast auf dem Siemens sitzt, ist die Tatsache, das ich ein vor 25 Jahren erstelltes 
S5-Programm mehr oder weniger unverändert in eine S7 spielen kann.

Der dickste Ast ist des weiteren die Jahrzehntelange Marktführerschaft von Siemens in allen möglichen Branchen,
und daraus folgend dann etliche Mannjahrhunderte erzeugten, getesteten Code, oft eben auch in AWL.
Da gibt es bei etlichen Firmen sicherlich Bausteine, die seit 10 und mehr Jahren mehr oder minder unverändert Verwendung finden,
und durch die Bank, als kleinsten gemeinsamen Nenner sozusagen, in AWL geschrieben wurde.

Mfg
Manuel


----------



## Perfektionist (8 November 2012)

Oberchefe schrieb:


> dann ist Dein "Wissen" schon ein paar Jahre alt, Stichwort "AOI",
> Du scheinst auch viel nach "Hörensagen" zu beurteilen, mache persönlich AB seit fast 20 Jahren, S7 und Codesys noch nicht ganz so lange


für das Hörensagen gibts ja dieses Forum hier. Und ich lass mich gerne eines besseren belehren, wenn die Grundlagen für mein Urteil nicht stimmen.



Oberchefe schrieb:


> Träum weiter, Stichwort SCL und Online beobachten


ist Grundlage dieses Urteils Classic, TIA V11 oder andere Steuerungen?



MSB schrieb:


> Falsch, in meinen Augen!
> ...


Zu S5-Zeiten war ich gezwungen, als kleinsten gemeinsamen Nenner 16-Bit-Mathematik zu verwenden, damit meine Programmbausteine auch auf Kleinsteuerungen lauffähig waren. Mit S7 war es nun möglich, durchweg 32-Bit-Arithmetik zu verwenden, also erfolgte der neuen Rechenkraft entsprechend eine Umstellung meiner Bausteine auf diese neue Möglichkeit. Als dann auch noch leistungsfähige Gleitkommamathematik im S7-Bereich erschwinglich wurde, wurden z.B. Wurzelfunktionen oder Kreisfunktionen, die wegen der Laufzeiteffizienz seither auf DINT-Tabellen beruhten, endlich in Gleitkomma umgestellt.

Nun suche ich meinen ganz persönlichen, dicken Ast, den kleinsten gemeinsamen Nenner in Sachen SCL/ST, um plattformunabhängig meinen Code entwickeln zu können. Da ich Siemens-verseucht bin (insofern, dass ich seither nichts anderes in die Hand bekam), muss ich mich derzeit auf das Hörensagen verlassen, um mich zu orientieren, ob dieser von mir beabsichtigte Weg wirklich gangbar ist, vielleicht ist ja vor mir bereits jemand diesen Weg gegangen.


----------



## Oberchefe (8 November 2012)

> ist Grundlage dieses Urteils Classic, TIA V11 oder andere Steuerungen?


Classic, andere Steuerungen können das und TIA kommt bei mir im Moment nicht in Frage, es gibt anscheinend genügend Freiwillige für Betatests. Ich sehe im Moment keinen Vorteil da wir überwiegend keine Siemens HMI einsetzen.


----------



## bike (8 November 2012)

Also eines habe ich heute zum erstenmal gesehen:
Eine Schrittkette in SCL.
Danke, dass das ein Gag war und nicht im echten Einsatz. 



bike


----------



## Matze001 (8 November 2012)

Bin mal gespannt wie unbeliebt ich mich mache, wenn ich folgende Aussage treffe:

Ich mache Schrittketten sehr gern in SCL! 
Man nehme einen CASE, und alle Sorgen sind vergessen.

(Dies ist für meinen Fall nur auf kleine Standardbausteine mit <10 Schritten beschränkt, ob ich mich wirkliche trauen würde eine komplette Schrittkette die ich womöglich debuggen muss in SCL zu schreiben weis ich auch nicht)

Grüße

Marcel


----------



## georg28 (8 November 2012)

So da ich diese Beiträge schon intensiv beobachte muß ich meinen  Senf auch mal drüberstreichen.
Ich gehöre zur Pro AWL Fraktion (will aber keine neue Diskussion über die richtige Programmiersprache entfachen, die gibt es hier schon zu hauf).

AWL wird in Zukunft für die 1500er definitiv vorhanden sein.
Da ich sehr viel oder fast nur AWL programmiere werde ich dies auch weiterhin machen. Für Bitverknüpfungen und einfache Berechnung ist dies optimal und auch gut nachvollziehbar. Vorteil halt wie auch schon erwähnt man kann auskommentieren und mehr Kommentare innerhalb eines Netzwerks machen (klar auch SCL).

Mann bekommt aber mit AWL auch die meisten Informationen auf den Bildschirm, vor allem wenn man 2 oder mehrere Bausteine gleichzeitig beobachten oder vergleichen tut, und die Bildschiraufteilung ist beim TIA definitiv schlechter wie bei der Classic Welt. Aber man kann auch einfach Code in Excel erzeugen (keine AWL Quellen gemeint) und dann in ein Netzerk kopieren per Copy Paste.

Für komplexere Berechnungen oder Datenhandling oder Schrittketten hat SCL schon seinen Vorteil aber halt nicht für Bitverknüpfungen.
KOP/FUP sind halt bei Bitbearbeitung wegen der grafischen/ farblichen Darstellung am Bildschirm auch gut wo man bei AWL genauer hinsehen muß.
Graph und CFC lasse ich jetzt mal aussen vor da ich diese in der Praxis noch nicht benutzt habe und auch momentan nicht gebrauchen kann.
Da ich aber kein Freund von Mischmasch Programmen bin hier ein bisschen KOP, da AWL, da SCL (wo ich allerdings auch denke dass dies in Zukunft mehr kommen wird) wird für mich AWL die Sprache weiterhin sein die ich verwenden werde.

Aber dass muss jeder für sich Entscheiden welche Sprache er verwendet in der Zukunft.


----------



## georg28 (8 November 2012)

Matze001 schrieb:


> Bin mal gespannt wie unbeliebt ich mich mache, wenn ich folgende Aussage treffe:
> 
> Ich mache Schrittketten sehr gern in SCL!
> Man nehme einen CASE, und alle Sorgen sind vergessen.
> ...



*ACK*

Das ist auch eine gute Möglichkeit eine Schrittkette zu programmieren.


----------



## bike (9 November 2012)

Matze001 schrieb:


> Bin mal gespannt wie unbeliebt ich mich mache, wenn ich folgende Aussage treffe:
> 
> Ich mache Schrittketten sehr gern in SCL!
> Man nehme einen CASE, und alle Sorgen sind vergessen.
> ...



Zur Zeit habe ich bei einer Inbetriebnahme eine Studenten dabei.
Mit dem zusammen habe ich eine bestehende Graph 7 Kette mit 56 Schritten in SCL umgesetzt.
Nur zur Übung und zu sehen ob und wie es geht, man lernt ja nie aus.

SCL nehme ich für Daten aber nicht unbedingt für Ablaufsteuerungen.


bike


----------



## Matze001 (9 November 2012)

Primär setze ich SCL nicht für Schrittketten ein, ich denke das konnte man aus dem Beitrag entnehmen!

Ich habe als Anwendung z.B. einen Baustein der sehr viel rechnen/Daten-Schubsen muss. 
In diesem Baustein ist es notwendig eine Schrittkette zu nutzen.
Was tut man also, man programmiert sie schnell, einfach und sauber in einem Case!

Wie schon erwähnt spreche ich hier nicht von Schrittketten mit 200 Schritten und 4-10 Transitionen pro Schritt...

Grüße

Marcel


----------



## Perfektionist (9 November 2012)

Oberchefe schrieb:


> Classic, andere Steuerungen können das und TIA kommt bei mir im Moment nicht in Frage, es gibt anscheinend genügend Freiwillige für Betatests. Ich sehe im Moment keinen Vorteil da wir überwiegend keine Siemens HMI einsetzen.


Das mit der Freiwilligkeit und Betatesterei ist relativ, wenn man Siemens-HMI hat. Totally Integrated heißt halt, dass man Siemens-HMI verwendet. Und die Vorzüge von V11 wiegen die Betabugs von V11 bei mir jedenfalls auf.



bike schrieb:


> Also eines habe ich heute zum erstenmal gesehen:
> Eine Schrittkette in SCL.
> Danke, dass das ein Gag war und nicht im echten Einsatz.


magst das nicht mal herzeigen?


----------



## michi_v (9 November 2012)

Es gibt lediglich Einschränkungen bei der 1200er CPU. Diese unterstützt keinen AWL Code.
Das hat zur Folge das aus Step7 Micro/Win nach Step 7 Basic V11 nur die IEC Sprachen KOP und FUP migriert werden können.

Wird von Step 7 V5.4/V5.5 oder Step 7 Professional 2006/10 nach Step 7 Professional V11 migriert, werden die IEC Sprachen KOP, FUP, SCL, AWL und GRAPH unterstützt.
Hardware und Netzwerk Konfigurationen werdem bis zum Stichtag 1.10.2007 unterstützt.

http://support.automation.siemens.com/WW/llisapi.dll?aktprim=0&lang=de&referer=%2fWW%2f&func=cslib.csinfo&siteid=cseus&groupid=4000003&extranet=standard&viewreg=WW&nodeid0=29156492&objaction=csopen

Keine Migrationsunterstützung ist geplant für HiGraph, IMap und FMS Verbindungen.

Gruß Michi


----------



## PN/DP (9 November 2012)

michi_v schrieb:


> Das hat zur Folge das aus Step7 Micro/Win nach Step 7 Basic V11 nur die IEC Sprachen KOP und FUP migriert werden können.


Oha, ist das tatsächlich möglich? Gibt es für diese Aussage eine Quelle oder ein Tutorial?

Harald


----------



## michi_v (9 November 2012)

PN/DP schrieb:


> Oha, ist das tatsächlich möglich? Gibt es für diese Aussage eine Quelle oder ein Tutorial?
> 
> Harald



Quelle:

SIMATIC TIA Portal System-Umsteigerkurs Handbuch. (TIA-SYSUP V11.1)

Gruß Michi


----------



## PN/DP (9 November 2012)

michi_v schrieb:


> Quelle:
> 
> SIMATIC TIA Portal System-Umsteigerkurs Handbuch. (TIA-SYSUP V11.1)


Gibt es dieses Handbuch auch irgendwo öffentlich zugänglich oder kannst Du mal die betreffende Stelle zitieren oder fotografieren?

Das Migrationstool TIA Portal V11 unterstützt laut Siemens keine Migration von Step7 Micro/Win. Ich finde auch nirgends eine öffentliche Aussage, daß oder wie eine Migration von S7-200 zu TIA V11 möglich wäre.

Harald


----------



## Perfektionist (9 November 2012)

PN/DP schrieb:


> Das Migrationstool TIA Portal V11 unterstützt laut Siemens keine Migration von Step7 Micro/Win.


Das Migrationstool ist, wie auch im verlinkten Beitrag zu lesen, für die Migration eines Projektes gedacht für den Fall, dass Classic auf dem Zielrechner nicht vorhanden ist. Wie sich das bei Microwin verhält, kann ich nichts zu sagen, da erstens ich bei V3.2 stehen geblieben bin, für das wenige, was ich mit der 200er gemacht habe, und zweitens hab ich auf der 200er AWL benutzt.


----------



## michi_v (9 November 2012)

PN/DP schrieb:


> Gibt es dieses Handbuch auch irgendwo öffentlich zugänglich oder kannst Du mal die betreffende Stelle zitieren oder fotografieren?
> 
> Das Migrationstool TIA Portal V11 unterstützt laut Siemens keine Migration von Step7 Micro/Win. Ich finde auch nirgends eine öffentliche Aussage, daß oder wie eine Migration von S7-200 zu TIA V11 möglich wäre.
> 
> Harald



Ich möchte hier keine Fotos aus Simatic Handbüchern einstellen.

Du hast aber Post. 

Gruß Michi


----------



## Perfektionist (9 November 2012)

michi_v schrieb:


> Ich möchte hier keine Fotos aus Simatic Handbüchern einstellen.
> 
> Du hast aber Post.
> 
> Gruß Michi


...und der Rest bleibt doof?
trau Dich ruhig:





> Kleinzitatedürfen weiterreichend verwendet werden. Der Zitierzweck muss erkennbar sein. Das Zitat muss also in irgendeiner Beziehung zu der eigenen Leistung stehen, beispielsweise als Erörterungsgrundlage. Der Umfang des Zitats muss dem Zweck angemessen sein.


Quelle: http://de.wikipedia.org/wiki/Zitat#Zitate_und_Urheberrecht


----------



## Perfektionist (9 November 2012)

PS: ich hab probiert, aber keine einfache Möglichkeit gefunden, S7-200er-Projekte zu migrieren.


----------



## michi_v (9 November 2012)

Alles klar, ich wollte nur keinen Ärger von einem Mod. bekommen...

Hab grad gesehen das bei Step7 Micro/Win nicht Migration sondern Konvertierung steht...

Aber seht selbst:




Gruß Michi


----------



## Perfektionist (9 November 2012)

Wobei Siemens hier den Begriff Konvertierung unscharf benutzt. Konvertierung muss nicht Handarbeit sein.


----------



## michi_v (9 November 2012)

Hier ein link zu einem Webinar das alle Fragen klären sollte:

http://support.automation.siemens.com/WW/llisapi.dll?func=cslib.csinfo&objId=54173103&load=treecontent&lang=de&siteid=cseus&aktprim=0&objaction=csview&extranet=standard&viewreg=WW


----------



## UniMog (9 November 2012)

@michi_v

Danke jetzt sollte es klar sein....... jetzt können unsere lieben und netten Kampfhähne beruhigt ins Wochenende gehen

netten Gruß


----------



## Perfektionist (9 November 2012)

UniMog schrieb:


> Danke jetzt sollte es klar sein....... jetzt können unsere lieben und netten Kampfhähne beruhigt ins Wochenende gehen


was heißt da Kampfhähne? offenbar ist die Mindestvorraussetzung für die Konvertierung Microwin V4SP6 und V11SP2. Bzw. dito und V10.5. Jetzt fehlt uns nur noch jemand, der aus eigener Erfahrung bestätigen kann, dass das wirklich geht und nicht nur auf irgendwelchen Folien zu lesen steht.


----------



## UniMog (9 November 2012)

ist doch Spaß.......... und war auf die gesamte Diskussion bezogen........also allen ein schönes WE...... ich hab für heute Sendepause


----------



## PN/DP (9 November 2012)

OK, ich glaube nun wieder, daß eine Konvertier-Möglichkeit von Micro/WIN zu TIA von Siemens vorgesehen ist. Mir fällt auch wieder ein, daß ich dieses Bild schon Anfang 2011 gesehen hatte. Bei der TIA Portal Innovation Tour 2011 hieß das übrigens noch "Projekt Migration", jetzt also "Konvertierung".
(siehe Folie Seite 12 aus "5_TIA_Portal_V11_Geräteübersicht und Migration.pdf")

Übrigens sind die Vortrags-PDF der TIA Portal Innovation Tour 2011 von den Siemens Servern wieder "verschwunden" ... 

Auffällig für Siemens ist auch, daß die Migrier/Konvertier-Möglichkeit von Micro/WIN zu TIA anscheinend nur in Werbebroschüren und Vorträgen existiert, jedoch in keinen System- und sonstigen Handbüchern beschrieben ist, wie es denn gehen soll. Keine FAQ oder Tutorials oder Beiträge im Siemens Support beschäftigen sich mit dem Thema (jedenfalls finde ich nichts). Auch das Dokument "Umstieg von S7-200 nach S7-1200" schweigt sich über die Programm-Konvertierung aus.

Hat den irgendjemand schonmal tatsächlich ein S7-200-Programm nach TIA konvertiert? Leider habe ich hier kein TIA zur Verfügung um selbst herauszufinden, ob und wie es geht.

Eine Aussage "_das aus Step7 Micro/Win nach Step 7 Basic V11 nur die IEC Sprachen KOP und FUP migriert werden können_" würde ich auch so relativieren, daß nur Programme konvertiert werden können, welche vollständig in KOP oder FUP *darstellbar* sind, weil die Konvertierung selbst wohl über AWL erfolgt, die 1200 aber kein AWL verstehen können soll.

Harald


----------



## michi_v (9 November 2012)

Also eine solche Konvertierung/Migration ist sicherlich entsprechend den Folien vorgesehen. Mein Schluss aus dem Umsteiegrkurs ist, so lange wie nur möglich mit der "alten" Technik zu arbeiten. Selbst die TIA Version mit der ich vor 4 Wochen gearbeitet habe, hatte noch so ihre Problemchen. Mal abgesehen davon das man einen 40 Zöller braucht wenn man umfangreiche Projekte bearbeitet. Aber das ist natürlich Geschmacksache und gehört auch nicht zum Thema hier. 

Alles wird gut... Es dauert halt einfach ein wenig.


----------



## Thomas_v2.1 (9 November 2012)

PN/DP schrieb:


> Eine Aussage "_das aus Step7 Micro/Win nach Step 7 Basic V11 nur die IEC Sprachen KOP und FUP migriert werden können_" würde ich auch so relativieren, daß nur Programme konvertiert werden können, welche vollständig in KOP oder FUP *darstellbar* sind, weil die Konvertierung selbst wohl über AWL erfolgt, die 1200 aber kein AWL verstehen können soll.



AWL ist keine formale Sprache, bzw. die Formalität beschränkt sich auf eine einzelne Anweisung. D.h. in AWL lassen sich auch prinzipiell "falsche" Sätze programmieren, und sowas kann niemals durch einen automatischen Konvertierer geschickt werden der dies in eine völlig andere Sprache übersetzt. Der S5-S7 Konverter hat ja hingegen nur Anweisung für Anweisung übersetzt, Zusammenhänge hat dieser nicht verstanden.
Bei FUP/KOP bei eingeschalteter Typüberprüfung ist ein Netzwerk eine Satz in einer formalen Sprache die FUP heißt. Und sowas lässt sich durchaus automatisch in eine beliebige andere Sprache konvertieren. 
Das ist auch der Grund warum bei sicherheitsrelevanten Programmen AWL nicht erlaubt ist, da hier kein einfacher Nachweis der Korrektheit möglich ist.


----------



## Perfektionist (9 November 2012)

PN/DP schrieb:


> Auffällig für Siemens ist auch, daß die Migrier/Konvertier-Möglichkeit von Micro/WIN zu TIA anscheinend nur in Werbebroschüren und Vorträgen existiert, jedoch in keinen System- und sonstigen Handbüchern beschrieben ist, wie es denn gehen soll. Keine FAQ oder Tutorials oder Beiträge im Siemens Support beschäftigen sich mit dem Thema (jedenfalls finde ich nichts). Auch das Dokument "Umstieg von S7-200 nach S7-1200" schweigt sich über die Programm-Konvertierung aus.
> Hat den irgendjemand schonmal tatsächlich ein S7-200-Programm nach TIA konvertiert? Leider habe ich hier kein TIA zur Verfügung um selbst herauszufinden, ob und wie es geht.


wenn die V4-Projekte vom MicroWin noch immer *.mwp wie in V3.2 heißen, dann bietet V11 nicht die Option an, solche Projekte für eine Migrierung zu öffen. Vielleicht auf anderem Weg?
Dass diese Konvertiermöglichkeit nur in Werbebroschüren steht, halte ich für durchaus möglich.


----------



## hucki (9 November 2012)

Perfektionist schrieb:


> wenn die V4-Projekte vom MicroWin noch immer *.mwp wie in V3.2 heißen, ...


 Heißen sie.




Perfektionist schrieb:


> ... Vielleicht auf anderem Weg? ...


Evtl. über den .awl-Export?


----------



## Voxe (10 November 2012)

Hallo zusammen,

ich hole das Thema einmal hervor. Es interessiert mich einfach, was hier abgeht. Vorab, von Siemens habe ich keine Ahnung.

Aber lest doch einmal den Anfang des Themas. Der Themenstarter, hat sich nie wieder beteiligt. Und die Frage war mit der ersten Antwort hinfällig. Dann ging es los.

Wenn ich einmal 25 Jahre zurück blicke, dann sehe ich AWL, KOP und FUP. Damals habe ich AWL gehasst, genau wie heute. Wie gesagt, es interessiert mich, deswegen spiele ich etwas mit Siemens-Steuerungen. Aber, was passiert denn da? Nutze ich SCL oder Graph, dann geschieht das doch über eine Quelle. Heisst für mich, alles wird in AWL übersetzt und dann in den Maschinencode, der zur CPU geht. Alles kann in AWL dargestellt werden. Es kann aber nicht jeder AWL-Code in den anderen Darstellungen dargestellt werden. Ergo, Siemens kann AWL nicht sterben lassen, das ist deren Grundlage.

Nun schaut einmal über den Tellerrand in Richtung Codesys, wieviele Beiträge beinhalten dort die IL, also AWL. Das geht gegen Null. Da ist das beste ST also SCL. Da ist IL nur Beiwerk, damit auch Siemens-Leute mitspielen können. Nutzen tun das die wenigsten. Schrittketten mit ST sind dort normal. Natürlich versuche ich dort einfache Sachen in FUP zu machen und nutze gerne AS (Graph). Wenn ich damit nicht zum Ziel komme, dann muss halt ST her. Es ist halt laut Google, auch meine Meinung, die für den Menschen lesbarste Sprache. Klar, früher gab es das nicht bei Siemens. Daher, machen die alten Hasen das meiste mit AWL, ging ja nicht anders.

Nun, könnt ihr mich hauen. Bin mal auf die Kommentare gespannt.

Gruß, Voxe.


----------



## MSB (10 November 2012)

@voxe
Was sollte man jetzt auf deinen Kommentar schreiben, was nicht irgendwo in den letzten 90 Beiträgen steht.
Insofern sei dir mit Nachdruck empfohlen, den Thread einfach zu lesen, 
anstatt den selben Blödsinn wie seit rund 80 Beiträgen noch mal hinten ran zu hängen.

Mfg
Manuel


----------



## Voxe (10 November 2012)

@MSB
deine Antwort, verstehe ich nicht. Die Frage des ersten Beitrages wurde nie beantwortet.

Kommt man bei S7 ohne AWL aus oder nicht ??? Ich, habe das Thema gelesen. Ich, spiele nur mit S7, mag AWL nicht, würde aber nicht ohne dort auskommen. Ob andere Sprachen, bzw. Darstellungsarten besser sein sollten, war nicht das Thema.

Gruß, Voxe


----------



## zotos (10 November 2012)

Dann schreibe ich mal den 99. Beitrag des Threads und ich bin sicher es kommen noch einige hinzu.

Warum sollte man bei einem *neuen *Projekt weiterhin AWL einsetzen?

1.1. Man beherrscht AWL sehr gut und hat sich daran gewöhnt und will nicht auf was anderes umsteigen.
1.2. Man hält AWL für die ultimative Sprache und alles andere ist Käse.
2. Man hat sehr viel Code den man von alten Projekten übernehmen kann bzw. neue Projekte sind modifizierte Kopien von alten Projekten.

Die Punkte 1.1 und 1.2 hatte ich ursprünglich als zwei eigenständige Punkte hingeschrieben. Aber eigentlich ist es oft ein Mischmasch und ein das haben wir immer schon so gemacht.

Der Punkt 2 scheint auch sehr relevant zu sein da hier eine Zeit lang das Konvertieren von alten Projekten Thema war. Ich persönlich mag keine Konvertierungen egal ob es von S5->S7, Protool->WinCC flex war ich hätte die Projekte lieber neu gemacht als sie zu konvertieren... bevor hier der Puls in die Höhe schnellt, ich rede hier von neuen Projekten. Nicht von Hardwaretausch weil kein altes Ersatzteil mehr vorhanden und Retrofits.

Manchmal ist es eben Zeit die alten Zöpfe abzuschneiden und mit neuen Techniken an die Sache heran zu gehen. So ein Plattformwechsel wie S5->S7 oder Protool->WinCC flex und nun S7-Clasic->TIA-Portal bietet doch die Möglichkeit mit dem ganzen alten Zeug aufzuräumen. Die Erfahrung von Jahren in ein neues System zu übertragen und einen besseren Grundstock zu verfassen.

Bei der Konvertierung kommt meist etwas raus das nicht ins neue Konzept passt. Ganz klar muss man sich mit neuen Systemen erst einmal befassen bevor man damit produktiv arbeiten will und so kann man auch die Chancen erkennen die das neue System bietet.

Von daher ist die Betatester Phase vielleicht gar nicht so schlecht.


----------



## Perfektionist (11 November 2012)

zotos schrieb:


> Bei der Konvertierung kommt meist etwas raus das nicht ins neue Konzept passt. Ganz klar muss man sich mit neuen Systemen erst einmal befassen bevor man damit produktiv arbeiten will und so kann man auch die Chancen erkennen die das neue System bietet.


Tja, nur wie macht man das dem Kunden klar? Für den ist ja was neues kein Fortschritt, sondern nur Belastung. Bzw. in den Augen mancher Softwareschmieden, wo mehrere Kollegen den gleichen Arbeitsstil (meist noch aus S5-Zeiten) pflegen, wie wollen die sich weiterentwickeln, wenn da ein "das haben wir schon immer so gemacht und hat sich bewährt" im Wege steht?

Sogar Siemens-Bausteine habe ich gesehen, die im alten Stil der S5 gestrickt waren/sind. Ein FC-Aufruf mit Übergabe einer DB-Nummer finde ich in Zeiten des IDB der S7 schlicht nicht nur anachronistisch, sondern insbesondere inzwischen als ganz schlechten Stil.


----------



## bike (11 November 2012)

Perfektionist schrieb:


> Ein FC-Aufruf mit Übergabe einer DB-Nummer finde ich in Zeiten des IDB der S7 schlicht nicht nur anachronistisch, sondern insbesondere inzwischen als ganz schlechten Stil.




Ein FC mit IDB?  


bike


----------



## borromeus (11 November 2012)

(Ich glaube) er meint einen Aufruf eines FC's zu machen und diesem einen DB zu übergeben ist schlecht, da es ja die Möglichkeit eines FB's mit IDB gibt.


----------



## 190B (11 November 2012)

@borromeus,

glaube ich genauso.
Wobei ich die da generell keinen Vorteil ersehen kann. Es kommt doch vielleicht auf den Anwendungsfall an und wer später mit dem Programm klar kommen muß....


----------



## bike (11 November 2012)

Ich verstehe eigentlich nicht, was wirklich gemeint ist.
Denn da ich keine IDB ausserhalb des FB beschreibe, brauche ich  so und so einen Global DB und, dann reicht doch ein DB bei einem FC.

Um wirklich modular zu programmieren, ist ein FB und ein IDB in sich eine Einheit.
Und was im Programm ist wird nur an den FB übergeben, nicht direkt in den IDB geschrieben.


bike


----------



## rostiger Nagel (11 November 2012)

Eigentlich kann es nur der Perfekte aufklären, aber so wie ich ihn verstanden habe meint er
das es ein wenig Altmodisch ist, FC in Verbindung mit *Global-DBs* zu nutzen und die
Endsprechende DB Nr über die Schnittstelle zu übergeben. 
Stattdessen sollte man seiner Meinung nach, gleich einen FB mit mit Instanz-DB verwenden.


----------



## Perfektionist (12 November 2012)

schade, das eine Beispiel finde ich finde nicht mehr...

anderes Beispiel dafür, dass FC + Global-DB generiert wurde ist Highgraph Stand ca. 2001. Instanziert wurde/wird innerhalb des Werkzeuges, es war/ist nicht möglich, statt dessen nur einen FB zu generieren und die Instanzen dann selbst dranzuschalten. Aber ist wohl dem Umstand geschuldet, dass Highgraph ähnlich schlecht in die S7-Classic-Welt integriert war/ist, wie SCL.

Auch wenn es nach wie vor einige hier nicht glauben können/wollen: ich hab ausschließlich FB und IDB, keinen GlobalDB.

Zugegeben, eine Funktion hätte ich, da könnt auch ein FC-Aufruf genügen. Allerdings müsste dann einer der Parameter zwingend an die Schnittstelle verlegt werden, der derzeit in der Instanz vom HMI-Gerät beschrieben wird. Aber dafür werde ich hier im Forum von der Lauer-Fraktion jetzt geprügelt werden.

Hoffentlich werde ich mir mit der optimierten Datenablage auch noch diese saubequemen S5-Timer ab- und die lästigen IEC-Timer angewöhnen können.


----------

