# IEC 61131-3 oder S7



## drunkenmunky (5 Februar 2008)

Hallo,

ich wollte mal wissen wer in IEC 61161-3 programmiert. Hab in S7 bis jetzt nur "Grundkenntnisse". Lohnt es sich dann gleich IEC zu lernen?

Was wird im Studium vermittelt?

Wenn ich es richtig verstanden haben, können alle Siemens 300er und 400er mit IEC (CoDeSys) programmiert werden!? Kann man auch mit dem Simatic Manager IEC konform programmieren?


----------



## zotos (5 Februar 2008)

drunkenmunky schrieb:


> ...
> Wenn ich es richtig verstanden haben, können alle Siemens 300er und 400er mit IEC (CoDeSys) programmiert werden!? Kann man auch mit dem Simatic Manager IEC konform programmieren?



Nein und Nein

Die S7 kann nicht mit CoDeSys programmiert werden.

Und auch wenn die Marketingabteilung vom großen S das gerne anders darstellt kann man mit Step7 nicht wirklich IEC61131-3 konform programmieren.


----------



## Gerhard Bäurle (5 Februar 2008)

drunkenmunky schrieb:


> Wenn ich es richtig verstanden haben, können alle Siemens 300er und 400er mit IEC (CoDeSys) programmiert werden



Da gab es mal was, das Accon-Prosys. Wurde aber ein-
gestellt, näheres im Forum z. B. *hier*. Mit der Forumsuch-
funktion findest Du sicher noch ein paar Diskussionen
dazu. Oder im großen *Langzeitgedächtnis*.

Nachtrag: Der große Marktführer ist sicher nicht an einer echten 
Austauschbarkeit interessiert.


----------



## IBFS (5 Februar 2008)

Propritär 

ist immer kompatibler als

inkompatibles Kompatibles




habe mit 3S leidvoll erfahren müssen, als hier und da LIBs fehlten
Hardware-files spezieller Hersteller nicht zu bekommen waren usw. usw.


----------



## kiestumpe (5 Februar 2008)

Grundsätzlich ist Programmierung viel learning-by-doing. Wenn IEC-61131 bei euch angeboten wird, nimms mit. Wenn S7 angeboten wird, nimms auch mit.
Wenn von beidem gar nichts, mach nen Kurs in Pascal oder einer anderen Hochsprache und evt. einen in Microcontroller-Programmierung.

Siemens kann zwar theoretisch rein nach IEC-61131 programmiert werden, du wirst in der Praxis es so nie in der rein Form finden.


----------



## stift (9 Februar 2008)

Also ich habe in meiner Lehrzeit noch nie was von IEC 61131-3 gehört. 
Das hat nie jemand erwähnt, geschweige denn näher erläutert. 
Wir bekommen nur noch S7 beigebracht (und das seit 3 Jahren)


----------



## zotos (9 Februar 2008)

stift schrieb:


> Also ich habe in meiner Lehrzeit noch nie was von IEC 61131-3 gehört.
> Das hat nie jemand erwähnt, geschweige denn näher erläutert.
> Wir bekommen *(nur)* *immer* noch S7 beigebracht (und das seit 3 Jahren)




Das "nur noch" ist wohl eher eine "immer noch" ;o)


----------



## nightworker (10 Februar 2008)

*Iec 61131*

Mahlzeit zusammen,

also falls ich hier was flasch verstanden habe - korrigiert mich. IEC 61131-3 ist die Norm - daher ja auch IEC=International Electrotechnical Commission. Die haben sich irgendwann mal hingesetzt und gesagt so wird ne SPS programmiert. Dafür nimmt man die und die Sprache. Dann kam das große "S" und hat gesagt - nee nich mit uns, da müssen wir ja unser auch offenlegen. 

Aus der dritten Teil der IEC 61131 leiten sich die unterschiedlichen Programmiersprachen ab: AWL und ST, sowie FDB(FUP) und LD(KOP). Zwischen den Programmiersprachen kann man barrierefrei umschalten. D.h. hat man ne AWL zur Hand und versteht aber nur FUP, kann man problemlos die AWL in FUP umschalten und sieht das Programm VOLLSTÄNDIG in FUP. 

Das probiere einer mal beim SiMan...da funktioniert das nur teilweise bis gar nicht.

Die S7  Programmierung ist somit keine andere Programmiersprache, sondern ist lediglich nicht Normkonform.

MfG

Night


----------



## PeterEF (11 Februar 2008)

nightworker schrieb:


> Zwischen den Programmiersprachen kann man barrierefrei umschalten. D.h. hat man ne AWL zur Hand und versteht aber nur FUP, kann man problemlos die AWL in FUP umschalten und sieht das Programm VOLLSTÄNDIG in FUP.
> 
> Das probiere einer mal beim SiMan...da funktioniert das nur teilweise bis gar nicht.


 
Kennt jemand ein Programmiersystem, in welchen dieses Feature wirklich brauchbar implementiert ist?
Sogar bei Codesys (welches ja der Norm am nächsten kommt) ist eine nachträgliche Umwandlung nicht trivialer Netzwerke nicht sinnvoll möglich, ohne die Lesbarkeit nachhaltig zu beinträchtigen...


----------



## Werner29 (12 Februar 2008)

Um das nochmal klarzustellen: Die Norm sagt nichts davon, dass man zwischen den Sprachen umschalten können soll. Die Norm definiert nur die Sprachen.
Im Gegenteil, so wie die Norm definiert ist, wird das Umschalten sehr erschwert. Beispielsweise kann man prinzipiell nicht nach ST umschalten, solange ST keine Sprünge erlaubt.
Eigentlich ist es eher andersherum, Siemens hat diese Umschaltbarkeit, und das ist der Grund, warum alle anderen es auch brauchen. Eine wirklich befriedigende Lösung dafür kenne ich nicht. Alle haben ihre Macken. Bei Codesys ist das auch kein Highlight. 

Bernhard Werner (3S-Smart Software Solutions)


----------



## Dumbledore (12 Februar 2008)

nightworker schrieb:


> IEC 61131-3 ist die Norm - daher ja auch IEC=International Electrotechnical Commission. Die haben sich irgendwann mal hingesetzt und gesagt so wird ne SPS programmiert. Dafür nimmt man die und die Sprache. Dann kam das große "S" und hat gesagt - nee nich mit uns, da müssen wir ja unser auch offenlegen
> 
> ...
> 
> Die S7 Programmierung ist somit keine andere Programmiersprache, sondern ist lediglich nicht Normkonform.


 
Historisch gesehen stimmt das aber nicht, da war Siemens zuerst da, samt AWL/KOP/FUP und der S5, und dann wurde erst genormt. 

Siemens steht dabei wohl auf dem Standpunkt, daß die bestehende Software nicht den (später entwickelten) Normen anzupassen ist, die "normative Kraft des Faktischen" eben ... wobei meines Wissens ja die Implemetierungen der 61131-3 durchaus nicht alle so kompatibel sind wie die Theorie das will. Insofern ist STEP7 eben nur eine "etwas weiter" abweichende Variante.

In anderen Bereichen hat sich Siemens ja durchaus den später auf Basis von Siemens-Produkten entwickelten Normen angepasst, z.B. L2-Bus --> Profibus.

Gruß Michael aka Dumbledore


----------



## Erik Böhm (12 Februar 2008)

Mahlzeit

Nach meiner Erfahrung können einem S7 Programmierer die nicht auch mal über den Tellerrand schauen eigentlich nur leid tun.
Ich kenne diverse Kollegen, die sowohl S7/S5 programmieren (überwiegend in AWL, aber nicht nur) die nach einer Stunde Einweisung in ST unter CoDeSys nicht mehr zurück wollen.
Ganz davon abgesehen, dass Siemens Hardware im Vergleich zu den meisten anderen Herstellern um den Faktor 3-5 mal teurer ist.
Und was mir am besten gefällt, ist die Hersteller unabhängige portierbarkeit des Quellcodes. Das glaubt mir zwar wieder keiner, aber wenn man das richtig aufzieht können Programme von einer SPS auf eine andere nur durch Neucompilierung übernommen werden. Ohne ein Bit am Quellcode zu ändern.
Was mit selbstgeschriebenen Libraries sowieso funktioniert.
z.B. Oscat-lib (OpenSource).

Meiner Meinung nach hatte die S7 durchaus mal eine Existenzberechtigung, aber die ist schon vor Jahren ausgelaufen.
Wie Stift (welch passender Nickname...) bereits sagte, wird in den Berufsschulen leider immer noch (ausschliesslich) S7 gelehrt.
Das ist für ein 'Hightech'-Land wie Deutschland eigentlich ein Armutszeugnis.
Eigentlich sollte es nicht heissen, 'IEC oder S7' sondern 'Warum eigentlich S7 ?'

Wir sollten uns mal auf der nächsten SPS in Nürnberg zusammentun und so alle halbe Stunde auf dem Siemens Stand nachfragen ob die S7 denn auch unter CoDeSys programmierbar ist...

Und ich werde nicht von 3S bezahlt, falls das jemand vermutet...

Gruss
Erik


----------



## Werner29 (12 Februar 2008)

Das geht ja runter wie Öl.
Ich habe übrigens versehentlich an der Abstimmung teilgenommen, eigentlich wollte ich nur sehen, wie die Abstimmung ausging. Kann man seine Stimme irgendwie wieder zurückziehen?
(Ich werde von 3S bezahlt).

Bernhard Werner


----------



## Ralle (12 Februar 2008)

Gähn, ehrlich, immer wieder das Selbe durchgekaut, ich kanns nimmer mehr hören. Und Beifall geklatscht. Und noch mehr gelangweilt. 
Kauft euch ein Sabbertuch und haltet es euch gegenseitig unter die Lefzen.
Diese Dis ist genauso dämlich wie das ganze dumme KOPkontraAWLkontraFUP-Gelaber von einigen trotzdem sehr geehrten Kollegen.


----------



## lorenz2512 (12 Februar 2008)

hallo,
ja codesys ist schon toll, die eingebaute visu schlägt winccflex um längen


----------



## Erik Böhm (12 Februar 2008)

Nochmal Hallo

Ich denke nicht, daß das nur eine 'ideologische' Frage ist.
Von einer solchen Diskussion halte ich genauso wenig.

Das ist ein ganz klarer Wettbewerbsnachteil gegenüber nicht S7 verstrahlten Konkurrenten.

Das ganze wär mir ja auch relativ egal, wenns nicht alle Berufsschüler, Meister und Studenten vorschädigen würde.
Von einer umfassenden Ausbildung sollte nicht SPS = S7 an unsere zukünftigen Fachkräfte vermittelt werden.
Egal ob CoDeSys oder B&R oder was auch immer.

Gruss
Erik


----------



## Ralle (12 Februar 2008)

Erik Böhm schrieb:


> Das ganze wär mir ja auch relativ egal, wenns nicht alle Berufsschüler, Meister und Studenten vorschädigen würde.
> Von einer umfassenden Ausbildung sollte nicht SPS = S7 an unsere zukünftigen Fachkräfte vermittelt werden.
> Egal ob CoDeSys oder B&R oder was auch immer.
> 
> ...



Das ist das selbe Geheule, das immer von Sun, Novell, IBM und und und angestimmt wurde, wenn es um Microsoft ging. Haben doch alle die Chance gehabt, nur genutzt haben sie sie jeweils auf ihre Art. Wenn erstmal genug Leute mit IEC-Kenntnissen unterwegs sind, wer weiß. Aber ehrlich, dieses "mit dem Finger auf die Bösen zeigen" ist sowas von affig.

PS: Mir den ganzen IEC-Sachen gabs ja auch einige Probleme, gerade wenn man unterschiedliche Versionen auf einem Laptop brauchte, oder Hersteller, die unterschiedliche Versionen genutzt haben. So ist das nun mal am Anfang und das haben einige Leute gleich wieder zum Ausstieg genutzt.


----------



## Erik Böhm (12 Februar 2008)

Vielen Dank für die (pein-)sachliche Antwort.
Hat uns allen sehr geholfen.


----------



## Ralle (12 Februar 2008)

Erik Böhm schrieb:


> Vielen Dank für die (pein-)sachliche Antwort.
> Hat uns allen sehr geholfen.



Bist ein toller Witzbold, ich verkneif mir jetzt echt was ...


----------



## Erik Böhm (12 Februar 2008)

Sag mal, hast du eigentlich ne Ahnung wovon du redest ? Oder kommen diese blöden Sprüche nur aus Mangel an Alternativen ?

Ich hab meine persönliche, und wie ich finde auch sachlich fundierte Meinung kundgetan. Für so was sind Foren eingerichtet worden.

Wenn jemand anderer Meinung ist, bitte. Das ist ein freies Land.
Aber wenn du das nur als Witz betrachtest, bitteschön.
Dann träum weiter. Aber lass uns doch dann bitte in Ruhe.


----------



## Ralle (12 Februar 2008)

Erik Böhm schrieb:


> Sag mal, hast du eigentlich ne Ahnung wovon du redest ? Oder kommen diese blöden Sprüche nur aus Mangel an Alternativen ?
> 
> Ich hab meine persönliche, und wie ich finde auch sachlich fundierte Meinung kundgetan. Für so was sind Foren eingerichtet worden.
> 
> ...



Au Backe, du bist wirklich ein Witzbold, laberst Scheiße, heulst rum und kannst nicht mal dein eigenes Gesülze lesen ! Klar kannst du deine Meinung sagen, ich machs ja auch, also laber weiter, tu dir keinen Zwang an, die Meute langweilt sich um diese Zeit eh meistens!


----------



## lorenz2512 (12 Februar 2008)

hallo,
meine ersten erfahrungen mit codesys war asisys, der mump konnte noch nicht mal einen ton oder tof ohne das ich ne bibli nachgeladen habe, genau das gleiche mit beckhoff, eine saublöde hardwareanbindung.


----------



## Erik Böhm (12 Februar 2008)

Hallo Lorenz

In CoDeSys (TwinCat von Beckhoff ist prinzipiell das Selbe) kommen ALLE Funktionen aus Bibliotheken. TON und TOF z.B. aus der Standard.lib.
Diese erstmalig einzubinden ist ungefähr ein Aufwand von 15 Sekunden und nicht Hardware abhängig.
Das gibt dir unter Anderem die Freiheit auch Bibliotheken von anderen Herstellern oder OpenSource einzubinden. Ich betrachte das als Vorteil.

Sicher ist nichts perfekt, und alles hat spezifische Vor- und Nachteile.
Von persönlichen Gewohnheiten und Vorlieben der Programmierer mal ganz abgesehen.

Gruss
Erik


----------



## lorenz2512 (12 Februar 2008)

hallo,
na also, da ist auch nicht alles gold was glänzt. und wenn in der schule, oder studium s5/s7 gelehrt wird, können diejeniegen sich glücklich schätzen, denn mit codesys, fanuc, ab usw kommt man im berufsleben nicht weit, wir haben x systeme bei und in der firma aber nicht eine kiste mit codesys, wird kaum angeboten, meist siemens, mitsubishi, ab und das wars, und das kommt von den maschinenbauern rund um die welt.
mann kann später sich auch mal umschauen, aber zum anfang taugt codesys nicht, siehe die azubis die von bosch kommen, die können erstmal umlernen.


----------



## zotos (12 Februar 2008)

Wer hat denn die alle wollen Siemens Laier aus dem Keller geholt? Wer für weniger Komfor und deutlich weniger Leistung mehr Geld ausgeben will kann dies gerne tun. Siemens wird sich freuen. Ich kenne immer mehr Firmen die auf CoDeSys oder TwinCAT setzen.


----------



## Ralle (12 Februar 2008)

zotos schrieb:


> Wer hat denn die alle wollen Siemens Laier aus dem Keller geholt? Wer für weniger Komfor und deutlich weniger Leistung mehr Geld ausgeben will kann dies gerne tun. Siemens wird sich freuen. Ich kenne immer mehr Firmen die auf CoDeSys oder TwinCAT setzen.



Da spricht ja auch überhaupt nichts dagegen!


----------



## Markus (12 Februar 2008)

grundsätzlich kann ich ralle zustimmen, solche diskussionen kann man nicht wirklich objektiv führen. jemand der in der s7 welt nur mit merkern, timern und fups rumgeiert hat und dann in der codeys welt erklärt bekommt wie man das richtig macht. so einer ist sicherlich total begeistert, aber das hätte man ihm in der s7 welt auch FAST bieten können wenn er nur mal die pilosophie der s7 programmierung verstaden hätte...

ich war letzte jahr auf einer codesys schulung, ein anderen freiberufler aus meiner gegend der früher sogar für siemens gearbeitet hat programmiert inzwischen nur noch beckhoff und wenn ich ihm über die schulter schaue bin ich begeistert!

das zeug ist genial - sicher vom programmieren her wesentlich komfortabler wie s7! keine datenbausteine, keine adressen, kein lästiges neu generieren von ibds, saubere symbolik, alles dynamisch,...

die visu sieht auf den ersten blick geil aus, man kann jeden scheiss dynamisch gestalten, aber mit einem winccflex oder gar wincc darf sie dann doch nicht gemessen werden. das täuscht am anfang - ging mir auch so...


programmierkomfort ist das eine, aber die welt darumherum ist das andere. die einzigen mir bekannten hersteller die siemens da das wasser auch nur ein bischen reichen können sind b&r und beckhoff. gut möglich das es noch andere gibt, aber das ist jetzt erst mal wurscht...

von siemens bekomme ich von der elektrischen zahnbürste bis zum atomkraftwerk alles, mich interessiert ein teil der welt dazwischen - nämlich TIA ich finde es einfach geil ein simtaic projekt zu haben in dem alle parameter der siemens fu liegen, in dem die siemens visu liegt, in dem die parameter der sensoren liegen,... das GANZE passt eben so schön zusammen.

beckhoff ist auf dem besten weg dahin, aber speziell bei den umrichtern noch recht schwach auf der brust.

über b&r darf ich nicht zuviel sagen, kenne die produkte zu wenig aber ich gehe mal davon aus ich bekomme keine ultaschallsensoren und keine integrierte wägetechnik...

ich lege wert auf eine gewisse durchgängigkeit und "ästätik" in der steuerungstechnik, und wenn hersteller xy noch so tolle fu zu einem noch so tollen preis hat, die kann ich nicht so integrieren wie ich das will...

ich bin was das angeht recht siemens verliebt, aber es kommt speziell bei der dezentralen e/a immer mehr beckhoff zum einsatz, die haben schon geile sachen. (wobei ich sobald ne f-cpu drin ist mit beckhoff wieder nix anfangen kann).
bei kommenden projekten ist meinerseits großes interesse da zb. bekhoff zu nehemen statt siemens, gut ich muss mich noch überwinden eine visu von was weis ich wem einzusetzen und eventuell fu von xy aber irgendwann werde ich mich mit dieser multi-hersteller-mix steuerungsphilosopie wohl abfinden müssen wenn ich nicht immer nur siemens machen will... 

bei bestehenden anlagen die auf siemens bassieren sind andere fabrikate sowieso völlig uninteressant, ich denke das ist verständlich.

aber auch bei neuen projekten ist das nicht so einfach, angenommen der kunde hat vor 2 jahren einen bananenbieger mit einer siemens sps gekauft, und jetzt will er wieder einen. sage ich zu dem dann: ok der ist völlig anders als der alte, du hast keine ersatzteile und must dein personal neu auf den kram schulen, aber ich verspreche dir wir machen da was saugeiles mit codesys! was soll daran saugeil sein?


desahlb kann ich codesysfanatikern (   ) wie erik nur das selbe sagen wie meinem beckhoffvertreter: seit nicht so hart mit uns verkalkten s7 programmierern! der wille oder zumindest das interesse ist da aber es ist halt numal nicht soooo einfach!


----------



## Ralle (12 Februar 2008)

Yep, es ging mir ja auch gerade nicht um irgendwelche Vor- und Nachteile, sondern um diese dämliche Art. Da krieg ich glatt immer das K.... 
Ansonsten Markus 99% Ack  !


----------



## Erik Böhm (13 Februar 2008)

Hallo nochmal

Ich weiss leider nicht was Ralle in den falschen Hals gekriegt hat, und ich bin auch kein CoDeSys Fanatiker. Ich finds eben nur schlecht, dass in Berufs- oder sonstigen Schulen andere Systeme als S7 seit Jahren ignoriert werden.
Monokultur war auf Dauer noch nie sehr förderlich für den Fortschritt.

Auf jeden Fall wollte ich niemanden beleidigen oder diskriminieren oder so.

@Ralle
Vermutlich hast du diese Diskussion schon öfter geführt und mir dann die gleiche bornierte Einstellung wie deinen vorigen 'Gegnern' unterstellt.
Normalerweise bin ich bemüht mit jedem auszukommen und es würde mich freuen, wenn wir die paar unnötigen Postings (beiderseits) zukünftig weglassen könnten.

Wollt ich nur mal gesagt haben...

Gruss
Erik


----------



## Dotzi (13 Februar 2008)

Mal als kleinen Einwurf zwischendurch,

es gibt tatsächlich Schulen, die beides unterrichten.

Bei unserer Technikerschule bekommen wir CoDeSys genauso, wie Step7 vermitteln. 

Was meine persönliche Meinung angeht, so sehe ich es wie Markus.


----------



## Maxl (14 Februar 2008)

Ich schließe mich Markus' Meinung ebenfalls an.

Im Grunde genommen ist es doch egal, ob man jetzt S7 programmiert, oder IEC oder CodeSys oder B&R usw. usw.
S7 ist meiner Meinung nach eine Programmierumgebung, mit der auch eine Laie relativ schnell zurecht kommt und schnell mal ein kleines Programm mit UND und ODER Gattern zusammenbastelt.
Die IEC-Geschichte (muss dazusagen, hab noch keine echte IEC-Steuerung programmiert, kenne nur B&R, S7 und die IEC-Optionen für S7) ist zwar leicht zu bedienen und auch flott zu programmieren, allerdings erfordern diese Systeme auch viel Disziplin beim Programmieren, um Programme ähnlich gut nachvollziehbar zu schreiben wie ein S7-Programm.

Bei uns im Betrieb (wir liefern zu 80-90% nach Österreich, Deutschland und Nachbarländer) ist nach wie vor Siemens die absolute Nr. 1. Weniger deshalb weil wir alle davon so überzeugt sind - vielmehr ist S7 doch eine Steuerung, mit der sich fast alle Anwendungsfälle abdecken lassen - und die meisten Firmen in A und D wollen einfach Siemens-Steuerungen haben (warum auch immer). Der Mehrpreis für Hardware gegenüber Alternativanbietern bewegt sich, gemessen an der Projektgröße und solange man keine Sinumerik einsetzt, unter 10% - die Softwarelizenzen für PGs sind sowieso vorhanden. Abgesehen davon beherrscht bei uns jeder der knapp 30 Programmierer S7 mehr oder weniger gut.

Derzeit wird zwar bei uns auch B&R in gewissen Bereichen forcierct (vor allem wenn viel Rechnerei gefordert ist oder bei kleinen Motion- und CNC-Anwendungen), es ist aber mittelfristig undenkbar, alle Anwendungen mit B&R zu lösen.


Ein Beispiel: Zerspanungstechnik

Hier ist derzeit Sinumerik die erste Wahl. Die Hardware und die Optionen kosten zwar ne Wahnsinnskohle, aber dafür sind in dieser Steuerung alle nur erdenklichen Funktionen für Zerstpanungstechnik drinnen - vor allem für Sonderanwendungen wie Mehrkanal-CNC, Kanalkoordination aus dem NC-Programm heraus, Synchronspindel usw. UND (was ja nicht zu verachten ist) es gibt eine fertige HMI, die bei jeder Sinumerik annähernd gleich aussieht.

Wenn ich mir vorstelle, so manches Zerspanungs-Projekt, welches wir in den letzten jahren umgesetzt haben, mit B&R zu machen, na dann Prost Mahlzeit! Kein Standard, keine NC-HMI, keine fertigen Standardzyklen, keine MSTT --> 12 Monate Arbeit für 2-3 Programmierer (welche zufälligerweise von Zerspanungstechnik Ahnung haben sollten).

Fazit: Für eine Serienmaschine würde sich eine B&R als Alternative anbieten (ich geh jetzt mal davon aus, dass Beckhoff nicht viel anders ist), aber für Sonderanwendungen bleibt Siemens die erste Wahl.


2. Beispiel: Heikle Prozess

Man stelle sich eine Leichtmetall-Gießanlage vor. Während der Inbetriebnahme müssen immer wieder kleinere Änderungen gemacht werden. Bei einer S7 mache ich diese Änderung und lade sie - der Zustand von sämtlichen Merkern und DBs bleibt davon unberührt - dank fixer Speicherarchitektur.
Mache ich nun diese Änderungen bei einer Steuerung á la B&R, kann es schon mal vorkommen, dass diese beim Transfer den Speicher für Lokale PV neu organisieren muss, was zur Folge hat, dass plötzlich von vielen Tasks die lokalen variablen mit 0 initialisiert werden --> absolut geil wenn grade Alu im Gießlöffel ist :twisted:.


Das ganze hier liest sich vermutlich so, als ob ich ein großer Siemens-Fan bin. Ganz im Gegenteil - ich verwende sehr gerne Alternativen. Aber bei vielen Anwendungen liegen die Vorteile der S7 einfach auf der Hand. Sebstverständlich gibt es auch Anwendungen, welche mit einer S7 nicht oder nur mit Wahnsinns-Aufwand realisierbar sind - hier kriegen Alternativanbieter in jedem Fall ihre Chance.


Zum Thema Anbieter X, Y und Z vermischen. Ich sehe da grundsätzlich kein Problem, solange man nicht ständig die Zusammensetzung ändert. Bei uns z.B. kommen immer gleiche oder Ähnliche Kombinationen zum Einsatz. z.B. S7 + ET200S + SEW Antriebstechnik über Profibus; B&R + X20 + Acopos über Powerlink; AB + FlexIO + SEW-Antriebe über DeviceNet. Solange ich nicht ständig meine IO-Serien ändere (beim ersten mal ET200S, dann Beckhoff, dann Wago und zuletzt Phönix-IOs über Interbus) und auf bekannte und bewährte Komponenten-Kombinationen setze, sollte das Mischen von herstellern kein Problem sein.
Mittlerweile kenne ich auch einige Kombinationen, welche sich nicht so gut vertragen (z.B. SEW Movidyn und Interbus). Nur aus dem Grund, weil man sich beim anderen Anbieter ein paar Cent pro Eingang spart, ist sicherlich kein Grund mehr, von heute auf Morgen den Hersteller zu wechseln.


Ok, jetzt bin ich etwas abgeschwieft - zurück zum Thema:
Ich denke, hier sollte es nicht (schon wieder) um eine Grundsatzdiskussion gehen ob IEC gut und S7 böse oder umgekehrt, sondern vielmehr sollte man sich immer wieder die Vor- und Nachteile der einzelnen Systeme zu Gemüte führen und dann abwägen, was man verwenden will - sowohl bei der Systemauswahl, als auch bei der Auswahl der Programmiersprachen.

Ich für meinen Teil programmiere auf S7 so viel wie nur möglich mit FUP - den Rest zu 98% AWL und 2% SCL.
Bei B&R wiederum kommen FBD (FUP, ab AS3) und LAD (KOP) nur für einfache logische Verknüpfungen zum Einsatz - der Rest wird in Basic oder Ansi-C programmiert. Wobei es auch hier wieder stark vom Projekt abhängt. Mein aktuelles Projekt (CNC) besteht zu 90% aus C, alle anderen zu 90% aus Basic. Also wie gesagt - was eben grade besser passt!


mfg
Maxl


----------



## Gerhard Bäurle (14 Februar 2008)

Erik Böhm schrieb:


> Das ganze wär mir ja auch relativ egal, wenns nicht alle Berufsschüler, Meister und Studenten vorschädigen würde.
> Von einer umfassenden Ausbildung sollte nicht SPS = S7 an unsere zukünftigen Fachkräfte vermittelt werden.
> Egal ob CoDeSys oder B&R oder was auch immer.



An beruflichen Schulen und bei der Technikerausbildung muss 
man sich wohl an dem orientieren, was in den Betrieben überwiegend
vorhanden ist.

Und einen Anfänger parallel auf mehrere Systeme los zu lassen,
macht auch keine Sinn.

Weiter bin ich der Meinung, dass bei der Ausbildung mehr Wert
auf das Abstrahieren der Aufgaben und deren technische 
Umsetzung gelegt werden sollte - und weniger auf die Umsetzung
auf einem speziellen System.

Weiter habe ich mal gehört, dass ein großer Anbieter durch gezielte
Lehrerfortbildung die Verbreitung seines Systems auf hohem Niveau 
hält. Ein BaWü soll das z. B. über das Kultusministerium bzw. die
Regierungspräsidien laufen. Vielleicht sollten die anderen Hersteller 
hier mal aktiv werden.


----------



## trinitaucher (14 Februar 2008)

Gerhard Bäurle schrieb:


> An beruflichen Schulen und bei der Technikerausbildung muss
> man sich wohl an dem orientieren, was in den Betrieben überwiegend
> vorhanden ist.


Mir wurde letztens von einem Kollegen erzählt, dass ein Vertriebler eines namhaften Steuerungsherstellers bei einem Termin zu ihm sagte, er müsse nun weiter zu einer Berufsschule und dort ein gutes Angebot machen, damit die ihren "alten Lieferanten" rauswerfen.
Ich bin da eher skeptisch, ob man sich an Berufsschulen/Hochschulen an dem tatsächlichen Bedarf, oder doch eher am Preis, bzw. "guten Angeboten" orientiert.


Gerhard Bäurle schrieb:


> Weiter habe ich mal gehört, dass ein großer Anbieter durch gezielte
> Lehrerfortbildung die Verbreitung seines Systems auf hohem Niveau
> hält. Ein BaWü soll das z. B. über das Kultusministerium bzw. die
> Regierungspräsidien laufen. Vielleicht sollten die anderen Hersteller
> hier mal aktiv werden


Würde meinen Verdacht bestätigen.
Außerdem schließt sich der Kreis dann wieder, wenn "Entscheidungsträger" von Berufs- oder Hochschulen dann doch später aufgrund dessen zu einem bestimmten Hersteller/System tendieren.


Gerhard Bäurle schrieb:


> Und einen Anfänger parallel auf mehrere Systeme los zu lassen,
> macht auch keine Sinn.
> 
> Weiter bin ich der Meinung, dass bei der Ausbildung mehr Wert
> ...


Schon richtig, ich glaube aber, dass die Leute später im Job, wenn mal eine Entscheidung diesbezüglich ansteht, eher zu dem tendieren, was sie kennen und was für sie am bequemsten ist (Technologiewechsel sind ja meistens erstmal unbequem). Und bestimmt genau deswegen möchten einige Firmen auch unbedingt ihre Technologie direkt an die Quelle der Nachwuchskräfte bringen.


----------



## zotos (14 Februar 2008)

Auf welchen Steuerungen an den Schulen unterrichtet wird ist doch zweitrangig und hat nichts mit dem Bedarf zu tun. Das Step7 leicht erlernbar sein soll, was ja öfters als Argument gebracht wird, ist auch eine leere Phrase. Ich kann mich daran erinnern dass es früher (ende 80iger Anfang 90iger Jahre) im Informatik unterrichten eine Dominanz von Basic und Pascal gab wobei der der unterricht in dem Basic mit GOTO 10 usw. verwendet wurde nicht gerade der Hit war, da war Pascal ja wohl die bessere Alternative um das strukturierte programmieren zu erlernen und IMHO kein deut schwieriger zu erlernen. 

Das Problem von Step7 ist doch das es recht nah an der Step5 liegt und an vielen Schulen veraltete Techniken gelehrt werden.
Klar kann man heute in den Schulen weiter hin Step7 und Merkerschrittketten  wie zu den Step5 Zeiten unterrichten (was ich zu genüge gesehen habe) wenn das der Bedarf vom Maschinenbau Land Nr. 1 ist, soll das ok sein. Den Erfolg sieht man ja an den Fragen hier im Forum ;o)


----------



## stift (27 Februar 2008)

Ich finde so langsam nervt diese "sch.. Ausbildung - Mentalität". 



> Klar kann man heute in den Schulen weiter hin Step7 und Merkerschrittketten wie zu den Step5 Zeiten unterrichten (was ich zu genüge gesehen habe) wenn das der Bedarf vom Maschinenbau Land Nr. 1 ist, soll das ok sein. Den Erfolg sieht man ja an den Fragen hier im Forum ;o)


 
Klar könnte die Ausbildung besser sein. Ich bin auch nicht mit meiner Ausbildung zufrieden. Aber ich finde unsere Ausbildung ist immer noch um welten besser als die unserer nachbarländer. 
War letztens in England, deren Elektriker im Betrieb konnten einen Drahtbruch in der Zuleitung einer Anlage nicht lokalisieren. 
Also haben die einen Elektriker aus Deutschland eingeflogen - nach 5 min war das Problem behoben. 
Da lobe ich mir doch die Ausbildung - auch wenn sie sich nur auf S7 konzentriert. 
Ich finde außerdem das Betriebe die andere Systeme verwenden auch selbst dafür Sorge tragen müssten, dass ihren Auszubildenden ander Systeme beigebracht werden. 
In der Berufschule kommt eigentlich S7 schon zu kurz. Für etwas anderes ist daneben keine Zeit mehr.

Ich finde man müsste auch bedenken das man einen S7-Lehrgang und die Kurse zu S7 in der Ausbildung nicht miteinander vergleichen darf. 
Man muss schließlich bedenken dass man in der Berufsschule alle 7-Wochen mal für 3 Stunden ein bisschen mit Simatic arbeitet. Im nächsten Block sind dann gute 70% von der voherigen Unterrichtsstunde wieder vergessen. 
Bei mir war es außerdem so dass ich nach meinem Ausbildungsplan nur eine Woche mit S7 im Betrieb arbeiten durfte. 
Und diese Woche ist bei mir entfallen. 
Jetzt hab ich mir halt für daheim eine Version organisiert und versuche mir das meiste selbst beizubringen.


----------



## Gerhard Bäurle (28 Februar 2008)

stift schrieb:


> ... man in der Berufsschule alle 7-Wochen mal für 3 Stunden ein bisschen mit Simatic ...



Welcher Ausbildungsberuf?


----------



## Ludewig (29 Februar 2008)

Ich programmiere seit 17 Jahren kleine Anlagen, seit nunmehr 11 Jahren mit Sucosoft, neuerdings Codesys. 
Dabei musste ich einmal aus dem Stand ein S5-Projektchen machen. Dabei scheiterte ich an Step5 und rettete mich mit Ibh, weil ich schon mit Bedienung nicht klar kam.

Im letzten Jahr musste ich dann ein kleineres S7-300-Projekt (mit Step 7 lite) ausführen, nachdem der Versuch, dies extern programmieren zu lassen, auf Grund der zu großen Arbeit, dem Programmierer die ihm völlig fremde Aufgabenstellung zu erklären, gescheitert war.

Dabei habe ich nach kurzer Zeit festgestellt, dass die Siemens-Software mich eigentlich auch gut versteht, wenn ich einfach IEC programmiere. Ich habe dann konsequent alle Timer und Merker rausgeworfen und so getan, als wurde ich mit einem IEC-System arbeiten. Und siehe da, das geht!!

Der größte Mangel an Step 7 ist mittlerweile in meinen Augen der krankhafte Versuch, verkalkte Step5-Programmierer als Kunden zu halten. Dehalb werden reihenweise unsaubere Programmmiertechniken zugelassen, insbeondere das direkte Schreiben in Speicheradressen anderer Bausteine. 

In einer internen Diskussion haben wir jetzt entschieden, dass Step 7 für unsere Anlagen aus Sicherheitsgründen nicht als Standardsystem in Frage kommt. Ein sicheres Programmiersystem sollte heute *für unsere Anlagen *(nicht sehr aufwendig, aber schnell lebensgefährlich)  mindestens folgende Eigenschaften haben. (Gedächtnisauszug)

1. Möglichkeit zur Erstellung eigener, innerbetrieblich zertifizierter Bibliotheken, die nur noch als Kompilat in der IDE und der Maschine vorliegen, und die vom Programmierer vor Ort nur parametriert werden, wobei eine bausteinbezogene Hilfe unabdingbar ist.

2. keine Rücklesemöglichkeit aus der Maschine, so dass Programmänderungen nur unter definierten Bedingungen möglich sind.

3. keine Möglichkeit, Speicheradressen direkt, sondern nur symbolisch und nur dort anzusprechen, wo sie auch zugelassenermaßen deklariert sind.

4. Kostengünstiger, schneller und weltweiter Fernzugriff, notfalls per Handy 9,6 analog.

Richtig ist, dass wir unsere Anlagen problemlos kurz anhalten können, wir brauchen keinen lokalen Bus, selten eine Visu, und FUs (ganz selten)  können wir auch mit 0-10V ohne Probleme integrieren und Geschwindigkeitsproblem haben wir nur mit der PS3 gehabt.

Für solche Anwendungen ist Siemens definitiv das Falsche. 

Und das nicht nur, weil S5Timer nur zwei Stunden können. (Ich sage das hier nur, weil eine von mir als Bauleiter betreute Anlage jetzt alle 2h ihren Hydraulikmotor anwirft, weil der Programmierer in einer völlig aktuellen S7 alte Standardtimer statt IEC-Timer verwendet und die Zeiten für den Druckverlust falsch eingeschätzt hat. 24h hätten auch gereicht)


----------



## OHGN (29 Februar 2008)

Ludewig schrieb:


> .........
> Der größte Mangel an Step 7 ist mittlerweile in meinen Augen der krankhafte Versuch, verkalkte Step5-Programmierer als Kunden zu halten.
> .........


Der Hauptgrund ist eher, Step 5 Programme auf S7 konvertieren zu können.


----------



## IBFS (29 Februar 2008)

OHGN schrieb:


> Der Hauptgrund ist eher, Step 5 Programme auf S7 konvertieren zu können.


 

...und genau dabei stürzt der S7-Konverter bei komplexen Programmen ab.


Ich mein für .....

```
U Ex.x
U Ex.y
= Ax.x
```
....brauche ich keinen Konverter

Gruß


----------



## nightworker (29 Februar 2008)

IBFS schrieb:


> ...und genau dabei stürzt der S7-Konverter bei komplexen Programmen ab.




Also ich hatte mit dem S7-Konverter bisher keine Abstürze und ich bin der Meinung das waren auch nicht gerade kleine Programme.

Vielleicht mal den Rechner bzw. die Installation überprüfen...ansonsten ein Beispiel.

MfG

Night


----------



## Ludewig (29 Februar 2008)

Das ist nicht wirklich der Punkt. Siemens Programmierer haben genauso Schwächen wie Moeller- oder 3S-Programmierer.

Ich denke aber, dass der Ansatz der IEC der modernere und leistungsfähigere ist, sonst hätte Siemens den Spagat wohl auch nicht versucht.

Sicherlich gibt es (noch) technische Grenzen, wenn man im oberen Geschwindigkeitsbereich arbeiten muss. Viele müssen das aber gar nicht.

Insofern muss es schon Ziel sein, die Prinzipien der IEC-Programmierung in die Ausbildung zu transportieren, wo bisher boolsche Algebra aus den 80er gelehrt wird. 

Ich persönlich würde keinen mehr einstellen, der noch Merker und E/A-Adressen direkt in den Code schreibt.


----------



## Ralle (29 Februar 2008)

Ludewig schrieb:


> Ich persönlich würde keinen mehr einstellen, der noch Merker und E/A-Adressen direkt in den Code schreibt.



Das ist nun wirklich ausgemachter Unsinn, aber sicherlich Ansichtssache !


----------



## Ludewig (29 Februar 2008)

Es wundert mich an dieser Stelle mehr, dass sich niemand zu unseren allgemeinen Anforderungen an die Programmierung von sicherem Code äußert.


----------



## Perfektionist (29 Februar 2008)

Ludewig schrieb:


> Es wundert mich an dieser Stelle mehr, dass sich niemand zu unseren allgemeinen Anforderungen an die Programmierung von sicherem Code äußert.


 
warum auch ... führt nur wieder zu einer ermüdenden Diskussion über saubere Programmierung, ob Code geschützt werden soll/darf etcpp. Bin ich leid, haben wir 1000x durch - danke, kein Bedarf  

Mein persönlicher Standpunkt: die Anforderungen von Ludewig sind m.E. richtig - aber leider praxisfremd, wenn man real existierende S7-Programme anschaut.


----------



## IBN-Service (29 Februar 2008)

Ludewig schrieb:


> Ich persönlich würde keinen mehr einstellen, der noch Merker und E/A-Adressen direkt in den Code schreibt.



Wenn man deinen Beitrag undifferenziert liest,
möchte ich Ralle zunächst zustimmen.


_In Bezug auf Step7 _muss ich allerdings sagen,
dass mich unter gewissen Umständen die Verwendung absoluter
Operanden schon mal gewaltig ärgert, und zwar:

Im SCL - Code sowie bei FUP/AWL in parametrierbaren FB und FC 
(Bausteine mit Formaloperanden).
Da haben absolute Operanden (nicht nur E/A/M sondern auch Z/C)
m.E. nichts verloren.

Letztendlich wird ein parametrierbarer Baustein ad absurdum
geführt, wenn er dann doch noch intern über absolute Adressen 
verfügt.


.


----------



## vierlagig (29 Februar 2008)

IBN-Service schrieb:


> Da haben absolute Operanden (nicht nur E/A/M sondern auch Z/C)
> m.E. nichts verloren.



...es sei denn, sie nennen sich schmiermerker *ROFL* *duck und weg*


----------



## Markus (29 Februar 2008)

Ludewig schrieb:


> In einer internen Diskussion haben wir jetzt entschieden, dass Step 7 für unsere Anlagen aus Sicherheitsgründen nicht als Standardsystem in Frage kommt. Ein sicheres Programmiersystem sollte heute *für unsere Anlagen *(nicht sehr aufwendig, aber schnell lebensgefährlich) mindestens folgende Eigenschaften haben. (Gedächtnisauszug)


 
sicherheit?
die begriffe "Sicherheitskategorie" "Stopkategorie" oder "SIL" sind dir geläufig?
Selbst wenn ich noch so toll programmiere muss ich mit einer Fehlfunktion der SPS rechnen - abgesehen von F-Steuerungen.

ich kann deiner argumentation im groben und ganzen folgen.
aber die anforderugnen an euer "sicheres" system finde ich dann doch etwas seltsam...
ihr schaltet also lebensgefährliche sachen über die normale sps und erreicht eure sicherheitskategorie durch ein """sicheres programmiersystem"""

  *ROFL* 

Wenn wir Ende 2008 das (un)Wort des Jahres im SPS-Forum wählen, dann werde ich für """sicheres Programmiersystem""" voten.

naja - als projektleiter sei dir verziehen...


----------



## IBN-Service (29 Februar 2008)

vierlagig schrieb:


> ...es sei denn, sie nennen sich schmiermerker *ROFL* *duck und weg*




Stimmt.

*Visierung auf weglaufenden vierlagig justierend*


----------

