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
! 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!
