# Verwendete S7-Befehle



## Rainer Hönle (10 November 2005)

Mich würde mal interessieren, wieviele der S7-Programme 
- ausschließlich mit Binärlogik und Wortarithmetik (/I, +D, ..)
- auch mit Wortlogik (UD, SLD, ...)
- zusätzlich noch mit Pointerarithmetik 
geschrieben werden. 
Welche S7-Programmiersprache 
- AWL
- KOP
- FUP
- SCL
- Graph
kommt dabei überwiegend zum Einsatz?
Und nebenbei noch, wie sieht das Ganze außerhalb der Siemenswelt aus? Gibt es dort die Unterschiede auch in diesem Umfang? 
Danke


----------



## Anonymous (10 November 2005)

Hallo Rainer,

ich denke in einem einigermaßen anspruchsvollen S7-Programm findest du deine drei Kategorien. Bei extrem einfachen Anwendungen kommst du 
vielleicht mit Binärlogik und Wortarithmetik aus aber sobald es etwas
umfangreicher wird kommt im Prinzip alles zum Einsatz. 
Ich kann mich an fast kein S7-Programm erinnern in dem ich kein SLD x, 
UD oder spz (und seine Genossen sind neben LARx, TARx meine absoluten Lieblinge  ) verwendet hätte. 32 Flankenmerker zu bilden ist mit
einem Doppelwortbefehl einfach effizienter als 32 mal die einzelen Bits
auszuwerten.

Auch Pointerarithmetik kommt bei mir oft zum Einsatz, denn leider
kann man in KOP, FUP und AWL immer noch kein Array-Element über einen variablen Index adressieren und ist in vielen Fällen einfach auf
Zeiger angewiesen.

Bei den Programmiersprachen kommt nach meiner Erfahrung bei S7 in erster Linie AWL und FUP (seltener KOP) zum Einsatz. Alles andere kostet zusätzlich Geld und das wird nicht unbedingt ausgegeben, auch wenn SCL
meiner Meinung nach oft sinnvoll einzusetzen wäre und oft leichter
nach zuvollziehen ist als meterlanger AWL-Code mit wilden Sprüngen.
Aber das mag von Branche zu Branche unterschiedlich sein.


----------



## Maxl (12 November 2005)

Kann mich dem nur anschließen!

Ist gibt kaum Projekte, bei denen man mit Binärlogik und Wortlogik auskommt!
Die am meisten zusätzlich gebrauchten Befehle bei mir sind
SPA, SPB, SPL (SPZ nur wenn nicht anders möglich)
SLW, SLD, LAR
TAK, TAW
SET

Ich setze FUP ein, wo immer es nur geht. Berechnungen werden meist in AWL gemacht. SCL habe ich noch nicht verwendet.


Ein Blick über den Tellerand - B&R Automation Studio:

Binärlogik und kurze berechnungen bzw. Sprünge können in KOP gemacht werden, dieser ist aber etwas unübersichtlich!
Alles andere programmiert man in Basic oder C.
Laut B&R ist SFC (ähnlich Graph) hauptsächlich im französischen und nordamerikanischen Raum gebräuchlich.
Strukturierter Text und AWL kommen kaum zum Einsatz.
FUP wird noch nicht unterstützt.



mfg
Max


----------



## Anonymous (25 November 2005)

Also ich komm aus einer relativ großen Anlagenprojektierung (letztes Projekt waren 5 S7-400 vernetzt) und bei uns wird alles in AWL geschrieben auch wenn wir sonst noch Software in hochsprachen schreiben nutzen wir bei der S7 kein SCL, da es meiner Meinung nach einfach nicht ausgereift und Benutzerfreundlich genug ist.

Bevor ich bei meinem jetzigen Arbeitgeber angefangen habe, hab ich von AWL nicht all zu viel gehalten und auch möglichst nie eingesetzt, aber mittlerweile habe ich die Vorzüge davon kennengelernt, denn allein wenn ich daran denke wie Riesengroß die FUP-NWs sind, was sie dadurch total unübersichtlich macht, bin ich immer froh wenn ich vernünftig kommentierte AWL Bausteine vor mir habe.

Eine große Unübersichtlichkeit finde ich auch, das es weder in FUP noch KOP möglich ist mehrere Vernetzungen in ein Netzwerk zu packen. Das ist bei AWL ein riesengroßer Vorteil was die Übersichtlichkeit angeht.

Einen sehr großen Nachteil im Online-Modus hat Step7 aber an sich. Denn man kann sich dort leider nicht die verschiedenen Instanzen eines FBs oder FCs anschauen sondern immer nur eine vorbestimmte (ich glaube es ist die letzte im Aufruf). Das ist z.B. bei CoDeSys von 3S-Software wesentlich besser gelöst, aber das ist ja wieder leider IEC-Norm.


----------



## plc_tippser (25 November 2005)

Brötchen schrieb:
			
		

> Einen sehr großen Nachteil im Online-Modus hat Step7 aber an sich. Denn man kann sich dort leider nicht die verschiedenen Instanzen eines FBs oder FCs anschauen sondern immer nur eine vorbestimmte (ich glaube es ist die letzte im Aufruf). Das ist z.B. bei CoDeSys von 3S-Software wesentlich besser gelöst, aber das ist ja wieder leider IEC-Norm.



Das geht über "Testbetrieb-Aufrufumgebung bzw. markierten Baustein im online öffnen (od. ähnlich)"

pt


----------



## Rainer Hönle (25 November 2005)

Brötchen schrieb:
			
		

> Einen sehr großen Nachteil im Online-Modus hat Step7 aber an sich. Denn man kann sich dort leider nicht die verschiedenen Instanzen eines FBs oder FCs anschauen sondern immer nur eine vorbestimmte (ich glaube es ist die letzte im Aufruf). Das ist z.B. bei CoDeSys von 3S-Software wesentlich besser gelöst, aber das ist ja wieder leider IEC-Norm.


Nicht ganz. Das hängt davon ab wie bzw. wo er aufgerufen wird. Bei Step7 kann ein Aufrufpfad angegeben werden bzw. ein Global- oder Instanz-DB. Dann wird der Status nur angezeigt, wenn diese Bedingungen erfüllt sind. Wenn der FB natürlich immer von selben Baustein aus aufgerufen wird, hilft das nichts.


----------



## plc_tippser (28 November 2005)

Mich würde eine Einrückmöglichkeit bei AWL sehr erfreuen. Dann wird das direkt alles viel lesbarer.

pt


----------



## Boxy (7 Dezember 2005)

Dann gibt es noch solche größer Firmen in der Automobil-Branch, welche gerne gewisse Engeenierung-Tools von Siemens eingesetzt haben wollen.

Daimler ist ein großer Freund von HiGraph und VW/Audi von S7-Grph.
Dort sollte man dann viel (z.B. Abläufe usw.) in der jeweiligen Erweiterung Programmieren. 
Das Pflichtenheft dort wird aber auch von Siemens erstellt und da kann dann jeder denken ob Sinvoll oder nicht!


----------



## Markus (7 Dezember 2005)

hm also ich meine es gibt einen erheblichen anteil an sps programmen die nur mit bitverarbeitung auskommen.

was ist mit den ganzen montagebändern? wo unzählige zylinder und greifer scheinbar chaotisch durcheinanderprügeln?

dahinter verbergen sich nur smple schrittketten die sichquasi auf die befehle U;O;S;R beschränken.

(sicher kann man in awl schöne sk´s mit spl machen, aber meist bestehen die ketten aus unzähligen flipflops...)

in einem solchen programm kommt sogar die wortverarbeitung höchstens zum beschreiben ganzer bitmuster (alle ausgänge auf 0 bei strg aus) oder bei der besagten flankenbildung vor...


naja aber in den anlagen mit dehnen ich hauptsächlich zu tun habe ist jede zweite zeile ein "lar1" oder sowas...
dort arbeite ich ausschlieslich mit awl, da es meiner meinung nach schlichtweg der resourcensparendste code ist.
scl ist sicher ganz nett, manche mögen damit auch schneller sein, wenn ich dann aber wegen dem aufgeblasenen code der rauskommt ne größerer cpu brauche, dann macht der einsatz nicht in allen branchen sinn. 
auf jeden fall macht er keinen sinn wenn man gewisse standarts in der software hat die wiederkehren, und man somit weniger auf die entwicklungszeit und mehr auf die hw kosten achten muss...


----------



## Question_mark (7 Dezember 2005)

Hallo Markus,


			
				Markus schrieb:
			
		

> dort arbeite ich ausschlieslich mit awl, da es meiner meinung nach schlichtweg der resourcensparendste code ist.


Ja, ohne Einschränkung !


			
				Markus schrieb:
			
		

> scl ist sicher ganz nett, manche mögen damit auch schneller sein,


Jeder, der SCL beherrscht ist damit um den Faktor xxx (je nach Aufgabenstellung) schneller als mit AWL-Programmierung. Und bei großen Projekten sind das dann ganz schnell fünfstellige Beträge.


			
				Markus schrieb:
			
		

> ne größerer cpu brauche


Die Mehrkosten für eine größere CPU sind dann in Relation zu den Softwarekosten sch...egal.


			
				Markus schrieb:
			
		

> wenn man gewisse standarts in der software hat


Ja, und nur in diesem Fall gebe ich Dir Recht, Standardanwendungen sind aber bei mir leider nie der Fall.
Es gibt also viel Pro und Kontra zu SCL oder AWL, aber das muss man immer in Abhängigkeit zum jeweiligen Projekt betrachten. Eine generelles Pro für SCL oder AWL gibt es einfach nicht. Und wenn der Kunde FUP oder KOP (schüttel) oder Graph ( schüttel, grauen ....) vorschreibt, ist die Diskussion über die Darstellungsart sowieso vergebens.   :lol: 
Also ist eine Grundsatzdiskussion eigentlich überflüssig, da hier immer das jeweilige Projekt mit den speziellen Kundenvorschriften die Vorgehensweise des Programmierers bestimmt.

Gruß
Question_mark


----------



## Anonymous (19 Dezember 2005)

> Die Mehrkosten für eine größere CPU sind dann in Relation zu den Softwarekosten sch...egal.



Boah, bei so einer Bemerkung krieg ich ja wieder einen dicken Hals. Das ist genau der Grund warum es soviel ineffiziente und aufgeblähte Software gibt. Und wenn ich böse sein wollte, dann könnt ich auch sagen "schlechte Programmierer". Ist jetzt keine Unterstellung anden Vorposter. Bitte nicht falsch verstehen. 

Gut ich bin noch neu in SPS Programmierung und kenne deshalb nicht die gängigen Arbeitsweisen. Aber meiner Ansicht nach sind die Siemens SPS für das was sie leisten können sauteuer. Wenn sie 'ne bessere MTBF-Zeit hätten könnte man für jede Siemens SPS mindestens 3 PC's hinstellen die das gleiche und noch viel mehr verrichten. Aber das ist 'ne andere Geschichte. Wollte nur sagen, dass bei dem Projekt das ich gerade umsetze der Kunde jeden Monat mehrere Dutzend SPS und OPs verbaut und verkauft. Da spielen Mehrkosten für eine großere CPU eine immense Rolle. Die Softwarentwicklung macht da nur einen Bruchteil aus.

Nun ja: Immerhin kann ich mir jetzt zusammenreimen warum die IDEs (WinCC und Micro/Win) so miserabel sind (z.B. Gechwindigkeit oder die Rezepturassistenten). Bei Siemens denken die bestimmt auch: Warum eine effiziente IDE entwickeln? Kostet doch nur. Soll der Entwickler doch lieber 'nen dickeren Rechner kaufen. Oder wieso kann ich mit einem PIII mit 512 MB mit Visual Studio in C++ in Höchstgeschwindigkeit richtig dicke Grafikanwendungen entwickeln während der gleiche Rechner bei KlickiBunti WinCC in die Knie geht.

just my 2 cent


----------



## HeizDuese (19 Dezember 2005)

Durchschnittliches Step7-Programm:

FUP: 70-90%
AWL: <5%
SCL: 5-25%
KOP: 0%  (kann man ja von FUP umschalten)
Graph: 0%

Binärprogrammierung: 90%
Wort- und Rechenadressierung: 9%
Pointeradressierung in AWL, <1%

90% S7-300er Reihe,
10% S7-400er Reihe

Alles geschätzte Werte, natürlich.


----------

