SCL und OOP

Pico1184

Level-2
Beiträge
332
Reaktionspunkte
9
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo zusammen,

ich war auf der Suche nach einem guten Buch zum Thema SCL im TIA Portal und bin auf folgendes gestoßen:

http://www.amazon.de/SCL-OOP-mit-Portal-objektorientierte/dp/3800734362

Der Buch Titel verwundert mich ein wenig. Ich komme aus der Hochsprachenwelt (C++ / C#) und kann
nicht verstehen wie die "Gesetze" der Objektorientierung in SCL umgesetzt werden sollen!

Da es in SCL keine Objekte bzw. Klassen, Methoden, Eigenschaften geschweige denn Vererbung und Polymorphie gibt kann man meines erachtens hier nicht von Objektorientierung sprechen.

Oder muss man von einem anderen Konzept ausgehen, z.B. man nehme einen FB == Klasse, dessen Parameter(IN, OUT, STAT, TEMP etc) == Eigenschaften, Aufrufe von anderen FCs (Funktionen) innerhalb dieses FBs == Methoden???????

Grüße Pico
 
Hallo,
direkt kannst du OOP in SCL und Konsorten nicht umsetzen.
Du kannst zwar mit viel Fanatsie den FB als Klasse verstehen und die FB-Schnittstelle als die Properties - mit den Methoden wird es dann aber schon problematisch.
Was ich an dieser Stelle mache ist, dass ich in dem FB unterschiedliche Teil-Funktionen habe und die dann über Binär-IN's anwähle. Das kommt dem Ganzen noch am Nächsten ...

Gruß
Larry
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
Wenn ich die Buchbeschreibung richtig verstanden habe, soll ja irgendwann UML ins TIA-Portal.

Das ganze könnte dann in etwas so funktionieren:

http://www.computer-automation.de/s...rweiterung_der_SPS-Software_um_UML-Diagramme/

aber um genau zu wissen, was der Autor mitteilen will, wird man wohl ums lesen des Buches nicht herum kommen ;)

Gruß.

PS: evtl. soll das Ganze dann CFC im TIA Portal ersetzen??? Weil von CFC hört man ja im Zusammenhang mit TIA Portal nicht viel...
 
Zuletzt bearbeitet:
Ohne das Buch gelsen zu haben ... ich habe meine Antwort aus meinen Wissenstand um die Möglichkeiten von Step7 geschrieben. Vom Step7 her wird es schon schwer, das Eine oder Andere, umzusetzen ...

Gruß
Larry
 
Liest sich ganz nett, ich bin gespannt, wer so etwas dann wirklich mal auf einer Anlage implementiert, die mehr als nur 2 Zylinder und einen Motor enthält.

Auf die UML-Diagramme dürfen wir sicherlich gespannt sein. Wenn man dann soweit ist, dass das Ganze halbwegs praxistauglich funktioniert, wird man dann binnen 10-20 Jahren keinen einzigen Programmierer mehr auffinden, der in der Lage ist, einen simplen Ausgang anzusteuern, ohne vorher eine halbe Diplomarbeit darüber zu verfassen. Ich sehe das Ganze mit einer gewissen (hoffentlich gesunden ;) )Skepsis und hoffe, dass alle, die daran entwickeln, wenigstens mal eine mittlere Anlage in der Praxis komplett durchprogrammiert haben und nicht irgendwo in ihrem Uni-Kämmerlein an tollen Doktorarbeiten basteln. OOP kann uns bei einigen Dingen sicher das Leben erleichtern, aber ich fürchte, dass auch hier kräftig an der Praxis vorbeientwickelt wird. So wird zum Schluß vielleicht Bedarf geschaffen, der so eigentlich nicht besteht, ähnlich wie es sie Sicherheitstechnikbranche ja schon vorgemacht hat (Oder kann hier irgend jemand den PL seiner Anlage ohne Software berechnen?) . Darauf kann ich dann gerne verzichten.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Liest sich ganz nett, ich bin gespannt, wer so etwas dann wirklich mal auf einer Anlage implementiert, die mehr als nur 2 Zylinder und einen Motor enthält.

Auf die UML-Diagramme dürfen wir sicherlich gespannt sein. Wenn man dann soweit ist, dass das Ganze halbwegs praxistauglich funktioniert, wird man dann binnen 10-20 Jahren keinen einzigen Programmierer mehr auffinden, der in der Lage ist, einen simplen Ausgang anzusteuern, ohne vorher eine halbe Diplomarbeit darüber zu verfassen. Ich sehe das Ganze mit einer gewissen (hoffentlich gesunden ;) )Skepsis und hoffe, dass alle, die daran entwickeln, wenigstens mal eine mittlere Anlage in der Praxis komplett durchprogrammiert haben und nicht irgendwo in ihrem Uni-Kämmerlein an tollen Doktorarbeiten basteln. OOP kann uns bei einigen Dingen sicher das Leben erleichtern, aber ich fürchte, dass auch hier kräftig an der Praxis vorbeientwickelt wird. So wird zum Schluß vielleicht Bedarf geschaffen, der so eigentlich nicht besteht, ähnlich wie es sie Sicherheitstechnikbranche ja schon vorgemacht hat (Oder kann hier irgend jemand den PL seiner Anlage ohne Software berechnen?) . Darauf kann ich dann gerne verzichten.

100% ACK .......... ich habe das nette "SCL und OOP mit dem TIA Portal V11" Büchlein gekauft aber noch nicht angefangen ...... Denke werde mal in den nächsten 3 Wochen bestimmt etwas darin lesen....
Auf der Buch CD ist neben Beispielen auch "Trial Enterprise Architect 9.3" und "Amuse 2.1" zum erstellen der netten UML-Diagramme drauf........

Und wer die ganzen Stunden zum programmieren und dokumentieren bezahlen will...... oder muß...... da bin ich mal gespannt drauf...... ein zusätzliches Ventil..... ok macht 2.400 hahaha


Gruß
 
Zuletzt bearbeitet:
Okay dann können wir hier nicht von OOP sprechen!

Meiner Meinung ist dann der Buchtitel falsch, da SCL diese Paradigmen einfach nicht bietet.

Ich fände es wünschenswert in der SPS Welt richtige OOP verwenden zu können.

Es bietet doch einiges an Vorteile Vererbung etc. verwenden zu können.

OOP hat außerdem noch viele mehr Vorteile welche auch in der SPS Welt genutztz werden können!

Natürlich muss man beachten wenn man z.B. nur 2-3 EAs hat, ob sich diese Vorgehensweise dann noch lohnt.

Dies liegt ja aber im ermessen des Programmierers / der Programmierer

Grüße Pico
 
Okay dann können wir hier nicht von OOP sprechen!

Meiner Meinung ist dann der Buchtitel falsch, da SCL diese Paradigmen einfach nicht bietet.

Ich fände es wünschenswert in der SPS Welt richtige OOP verwenden zu können.

Es bietet doch einiges an Vorteile Vererbung etc. verwenden zu können.

OOP hat außerdem noch viele mehr Vorteile welche auch in der SPS Welt genutztz werden können!

Natürlich muss man beachten wenn man z.B. nur 2-3 EAs hat, ob sich diese Vorgehensweise dann noch lohnt.

Dies liegt ja aber im ermessen des Programmierers / der Programmierer

Grüße Pico

Ich habe den Wunsch von OOP in der SPS noch nicht ganz verstanden. Wenn ich die Dinge (FB, Multiinstanz) nutze, die bereits vorhanden sind, dann kann ich Bausteine erstellen, die wiederverwendbar sind, wenn es denn sein soll kann ich einen Baustein durch einen zweiten kapseln und dann dort noch Funktionen integrieren, was einer Vererbung ja schon ein wenig ähnelt. Aber immer weiß ich, was da genau passiert. Eine SPS mit Events, Eventhandlern usw. programmiert möchte ich in meinen Maschinen eher nicht haben, da bin ich mir nicht mehr sicher, ob das nun immer klappt oder dann auch mal nicht. Die berühmte Schutzrechtsverletzung (ok, das gibt es auch in Windows kaum noch) oder ein Programm das ganz plötzlich ausgeknipst ist, das wäre wohl der Supergau. Also halte ich es lieber etwas einfacher.
Ich denke dann immer an den Cartoon aus der ct, da saßen zwei Piloten in ihrem unterwegs A310-Cockpit und auf dem Bildschirm erschein die Meldung "Allgemeine Schutzrechtsverletzung, bitte starten sie neu!" (So ähnlich jedenfalls)
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo Ralle,
ich kann deine Einwände in manchen Punkten sogar ganz gut verstehen. Es gibt ein paar Aspekte aus der OOP, die in der SPS-Welt ganz sinnig sind und ein paar nicht. Vererbung und Klassen mit Methoden sind so Dinge, die ich gut finde / fände. Event-Handling kann schon so eine Sache sein (wobei es ja auch jetzt schon OB's in der SPS gibt, die in etwa das machen), da man eventuell nicht mehr überblicken kann woher mal was gekommen ist - da hast du vollkommen Recht - vor Allem wenn ich dann berücksichtige, was man daraus dann so Alles machen kann (im Sinne von "sich einen Ausklinken"). Es gibt da ja noch einen anderen Thread (das AWL-Thema) wo das so und so auch thematisiert wird. Grundsätzlich gilt ja : wenn man etwas Sch...e programmieren kann dann wird es auch irgendwann von irgendwem gemacht.

Ich würde aber deshalb trotzdem nicht sagen wollen, dass das Ganze deshalb nicht sinnvoll wäre. Die Zeit wird es schon richten ... 8)

Gruß
Larry
 
Hallo Ralle,
ich kann deine Einwände in manchen Punkten sogar ganz gut verstehen. Es gibt ein paar Aspekte aus der OOP, die in der SPS-Welt ganz sinnig sind und ein paar nicht. Vererbung und Klassen mit Methoden sind so Dinge, die ich gut finde / fände. Event-Handling kann schon so eine Sache sein (wobei es ja auch jetzt schon OB's in der SPS gibt, die in etwa das machen), da man eventuell nicht mehr überblicken kann woher mal was gekommen ist - da hast du vollkommen Recht - vor Allem wenn ich dann berücksichtige, was man daraus dann so Alles machen kann (im Sinne von "sich einen Ausklinken"). Es gibt da ja noch einen anderen Thread (das AWL-Thema) wo das so und so auch thematisiert wird. Grundsätzlich gilt ja : wenn man etwas Sch...e programmieren kann dann wird es auch irgendwann von irgendwem gemacht.

Ich würde aber deshalb trotzdem nicht sagen wollen, dass das Ganze deshalb nicht sinnvoll wäre. Die Zeit wird es schon richten ... 8)

Gruß
Larry

Immer wieder meine Meinung: Für jede Aufgabe die richtige Sprache/Ansicht.
Komplexe Berechnungen in FUP sind genau so sch...e wie Schrittketten in SCL. Und das Thema ist ja nur ein weiterer Gedankengang.
 
Für jede Aufgabe die richtige Sprache/Ansicht.

Interessanterweise fehlt in dieser Diskussion immer CFC... warscheinlich weil sich das nur die wenigsten leisten (wollen)...

Da schreib ich meine Bausteine in der passenden Sprache, meist SCL, aber auch AWL, FUP etc. und verschalte sie dann grafisch in CFC, das macht schon laune... Vor Allem wenn dann durch AS-OS-Übersetzen auch noch der meiste Kram für WinCC automtisch mit angelegt wird...

Gruß.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hmmm ... @Ralle: Ich frage mich warum beim Thema "Hochsprachentechnologie in der SPS Welt anwenden" immer die Front so schnell hochgefahren wird und das ganze Thema in die Welt der Theoretiker und Phantasten verschoben wird.

Ich habe ja nicht gelesen daß jemand eine Anlage in C# oder Java automatisieren will sondern nur daß manche Leute (und da zähle ich mich auch dazu) versuchen Ansätze aus Hochsprachenentwicklung in die SPS Welt umzulegen. Ich denke mal das ist weder anrüchig noch per se dumm. Natürlich gibt es Konzepte bei denen es weniger Sinn macht als andere aber deswegen das Kind mit dem Bade auszuschütten halte ich schlichtweg für falsch.

Dabei wird auch imho sehr viel falsches Gedankengut verbreitet denn z.B. hat das Thema UML mal grundsätzlich gar nichts mit dem Thema OOP zu tun da UML (#5). Laut Wiki ist UML
Die Unified Modeling Language (Vereinheitlichte Modellierungssprache), kurz UML, ist eine graphische Modellierungssprache zur Spezifikation, Konstruktion und Dokumentation von Software-Teilen und anderen Systemen.[SUP]http://www.sps-forum.de/#cite_note-0[/SUP]
Sie bietet verschiedene Diagrammarten um Software zu beschreiben von denen sich manche eignen können um SPS Programme zu beschreiben und manche eher nicht, thats it. Daß in der Hochspracheentwicklung Technologien vorhanden sind um aus den UML Diagrammen Code zu generieren ist ein anderer Aspekt aber auch hier würde ich nicht kategorisch ausschließen daß das Anwendungsfälle in der SPS Prograqmmierung haben kann.

Auch so tun als habe OOP irgendwas mit unsauberer oder schlampiger Programmierung, mit Windows Fehlermeldungen oder ähnlichem zu tun (#8) halte ich für schlechte Propaganda.

Was ist also der Grund für die startek Ablehnung gegen das Thema "Läßt sich was aus der Hochsprachenwelt in der SPS nutzen"?
 
Also ... ich kann Ralle schon ganz gut verstehen ... Er hat den gleichen Ballast wie ich selbst auch - langjährige Erfahrung.
Das ist Segen und Fluch zugleich ... Je nach Umfeld, in dem man sich jeweils bewegt, kann einen das schon ganz schön konservativ werden lassen ...
 
Hmmm ... @Ralle: Ich frage mich warum beim Thema "Hochsprachentechnologie in der SPS Welt anwenden" immer die Front so schnell hochgefahren wird und das ganze Thema in die Welt der Theoretiker und Phantasten verschoben wird.

Ich habe ja nicht gelesen daß jemand eine Anlage in C# oder Java automatisieren will sondern nur daß manche Leute (und da zähle ich mich auch dazu) versuchen Ansätze aus Hochsprachenentwicklung in die SPS Welt umzulegen. Ich denke mal das ist weder anrüchig noch per se dumm. Natürlich gibt es Konzepte bei denen es weniger Sinn macht als andere aber deswegen das Kind mit dem Bade auszuschütten halte ich schlichtweg für falsch.

Dabei wird auch imho sehr viel falsches Gedankengut verbreitet denn z.B. hat das Thema UML mal grundsätzlich gar nichts mit dem Thema OOP zu tun da UML (#5). Laut Wiki ist UML
Sie bietet verschiedene Diagrammarten um Software zu beschreiben von denen sich manche eignen können um SPS Programme zu beschreiben und manche eher nicht, thats it. Daß in der Hochspracheentwicklung Technologien vorhanden sind um aus den UML Diagrammen Code zu generieren ist ein anderer Aspekt aber auch hier würde ich nicht kategorisch ausschließen daß das Anwendungsfälle in der SPS Prograqmmierung haben kann.

Auch so tun als habe OOP irgendwas mit unsauberer oder schlampiger Programmierung, mit Windows Fehlermeldungen oder ähnlichem zu tun (#8) halte ich für schlechte Propaganda.

Was ist also der Grund für die startek Ablehnung gegen das Thema "Läßt sich was aus der Hochsprachenwelt in der SPS nutzen"?

Ne verdammen wollte ich das nicht, aber ich glaube nicht mehr daran, dass die Entwicklung insgesamt einem Sinn folgt. Viele Dinge gibt es z.T. nur, weil jemand damit Geld verdienen will (Ein Teil der Sicherheitstechnik und die dazu erfundenen Vorschriften gehört definitiv dazu) oder weil er endlich mal was Neues bringen will/muß. Das befürchte ich auch für die Steuerungstechnik. Und aus langjähriger Erfahrung darf ich sagen, die schlechtesten SPS-Programme in meiner Laufbahn kamen bisher von Informatikern, gerne mit viel Uni-Erfahrung und Dr.-Titel. Das soll keine Pauschalverurteilung sein, ist nur meinen Erlebnissen geschuldet. Wenn nun jemand anfängt, seine weitreichenden OOP-Erfahrungen (die sollte man dann schon haben) auf SPS-Gebiet umzusetzen, fürchte ich um das, was wir im eigentlichen Sinne machen sollen, das Steuern und Regeln von Prozessen aller Art. Viele Fragen hier im Forum die mit OOP zu tun haben, zeugen denn auch oftmals von einigem Unverständniss der Prozesse und Abläufe die in einer SPS und damit auch in einer Maschine stattfinden. Eine Maschine, ist nun mal kein Windows-Programm.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Zu diesen 2 Sachen gibt´s nicht mehr zu sagen :
die schlechtesten SPS-Programme in meiner Laufbahn kamen bisher von Informatikern, gerne mit viel Uni-Erfahrung und Dr.-Titel.

Eine Maschine, ist nun mal kein Windows-Programm. [/quote ]

100% Zustimmung. Obwohl ich mich auch ein bisschen mit C und OOP befasse (totaler beginner), wünsche ich mir doch sehr für die Zukunft, das alles was über SCL hinausgeht bitte keinen Einzug in die SPS Welt hält.

Auch wenn ich mit dieser Aussage jetzt keine Freunde gewinnen werde , aber aus sehr sehr schlechten Erfahrungen noch eine Bitte : Meine jungen Herren, studierten Informatiker mit C# und was weiß ich noch für Hochsprachenkenntnissen... Bitte programmiert Computersoftware aber keine SPS. Bitte. Danke.
Hochkomplexe Anlagen sind in den letzten Jahren auch ohne Hochsprache, OOP usw. ausgekommen.
 
Hmmm ... und ihr tut es wieder! Ihr zeichnet ein Bild in der die bösen Theoretiker, verspielten jungen C# Programmierer, Uni Professoren usw, ohne Ahnung vom "echten Leben" auf der einen Seite sitzen und euch bodenständigen, ehrlichen und guten SPS Leute auf der anderen Seite "etwas erzählen wollen".
Besonders eine Aussagen a la
[...]eine Bitte : Meine jungen Herren, studierten Informatiker mit C# und was weiß ich noch für Hochsprachenkenntnissen... Bitte programmiert Computersoftware aber keine SPS. Bitte. Danke.
Hochkomplexe Anlagen sind in den letzten Jahren auch ohne Hochsprache, OOP usw. ausgekommen.

halte ich für voreingenommen und total entbehrlich. Ich frage mich auch welches Selbstverständnis da dahinter steckt: Ich bin eh gut und mir braucht keiner was sagen?
Also ich bin kein studierter Uni-Professor und auch kein Informatiker und kein Uni-Professor und auch sonst nix was hier als dämonisch angesehen wird. Aber wenn ich, wie jetzt gerade, an einem 472 Seiten Prosa-Pflichtenheft sitze frage ich mich warum der ach so praxisbezogenen Teil der Community anscheinend Angst hat an eine formale, standartisiere Sprache zur Beschreibung von Software (könnte z.B. Teile von UML enthalten, muß aber natürlich nicht) zu !!!denken!!! und darüber sachlich zu diskutieren. Da scheint man lieber, wie bis jetzt in der ach so idyllischen SPS Welt, den schriftstellerischen Fähigeiten des Prozess-Vorgänger ausgeliefert, Romane lesen zu wollen.

Ich frage mich wie jemand der in der Praxis kommt anscheinend keinen Sinn darin sieht, mittels einer Objekt-Orientierten-Analyse (OOA ... fürchtet euch, es heißt was mit Objekt Orientiert!!) strukturiert herauszuarbeiten (und entsprechend zu dokumentieren) welche Funktionalitäten man abstrahieren kann und als Bausteine ausprogrammieren sollte statt zeilenweise mit Copy&Paste unwartbaren Spaghetticode zu produzieren. Das kann nämlich passieren wenn ein ach so erfahrener SPS-Maschinen-Automatisierer sich vor eine >3000EA Prozesstechnikanlage setzt. (Das Gegenstück zu den Uni-Informatik-Professor-Geschichten)

Ich muß mich wiederholen wenn ich sage ich
[...]habe ja nicht gelesen daß jemand eine Anlage in C# oder Java automatisieren will sondern nur daß manche Leute (und da zähle ich mich auch dazu) versuchen Ansätze aus Hochsprachenentwicklung in die SPS Welt umzulegen [EDIT]um die Qualität zu heben und die Kosten zu senken[/EDIT]. Ich denke mal das ist weder anrüchig noch per se dumm. Natürlich gibt es Konzepte bei denen es weniger Sinn macht als andere aber deswegen das Kind mit dem Bade auszuschütten halte ich schlichtweg für falsch.[...]

Wenn das impliziert daß ich denke daß man eine SPS wie ein C# Projekt angehen sollte -> NEIN
Wenn das impliziert daß junge Informatiker automatisch tolle SPS Programmierer sind -> NEIN
Wenn das impliziert daß Informatik = Automatisierungstechnik -> NEIN

Aber was ich denke ist: Man darf doch wohl vorurteilsfrei über die Grenzen seiner Zunft schielen und schauen was es da noch für eine Welt gibt und was davon interessant für mein eigenes Handwerk sein könnte oder?

Und ja, ich verstehe auch eure negative Einstellung zT. Ich verstehe daß hier im Forum auch viele Kommentare von Usern kommen die vielleicht (anscheinend) aus Unwissenheit in eine falsche Richtung denken und arbeiten und sich nicht eines Besseren belehren lassen wollen. Es ist aber ziemlich beleidigend, zeugt imho von schlechtem Benehmen und schmettert immer alle sachlichen Argumente vom Tisch, jedem der anscheinend in "eine falsche Richtung zu denken scheint" Unwissenheit und mangelnde Erfahrung vorzuwerfen. Und ich finde das passiert hier bei jedem Thread zum Thema "Hochsprachentechnologien in der SPS Welt nutzen".
 
Zuviel Werbung?
-> Hier kostenlos registrieren
@norustnotrust
Ach Gott, natürlich schrei ich nicht immer gleich "hier", das war mal.

Aber ohne Scheiß, ich war mal bei einem Prof. für Automatisierungstechnik an einer Uni, ich hatte eine Zusammenarbeit im Sinne. Er saß vor seiner SUN und auf meine Frage, was denn so an Programmiersprachen und -umgebungen zum Einsatz käme, meinte er kurz und knapp "Wir machen alles in C". OK, das ist schon ein paar Jährchen her, damals war aber schon Step7 im Einsatz. Zusammenarbeit war nicht, auf meine Niederungen wollte der sich gar nicht herablassen, es sei denn, es käme ordentlich was rum für seinen Bereich. Seitdem bin ich nun mal skeptisch.

PS: Hast du schon mal nach V-Modell programmiert, also sicherheitsrelevante Software. Da muß man ja auch alles ordentlich festlegen und definieren, ich denke mal ein gutes Feld für UML. Allerdings dauert eine Entwicklung sehr lange und verschlingt eine Menge Geld und Mann-Monate. Das will heut kaum jemand zahlen.

PS2: Früher hab ich viel mit Delphi programmiert. Aber irgendwann hat es mit gelangt, dass ich jedes Jahr eine neue Version teuer updaten mußte. Ok, bei Siemens muß ich das auch, aber ich will einfach nicht noch mehr Software auf meinem Rechner anhäufen, bezahlen, erlernen und beherrschen müssen. Wenn am Ende Code dabei herauskommt, der lesbar, verstehbar und auf der Codeebene auch wart- bzw. änderbar ist, dann mag das noch gehen, aber daran zweifle ich eben.

Und zum guten Schluß: Man sollte sich doch eine gesunde Kritikfähigkeit erhalten, denn nicht immer ist es sinnvoll alles nur Mögliche auch zu machen. Für große Produktionsanlagen ist ein Standard vielleicht auch eine Beschreibungssprache mit einem guten Werkzeug durchaus sinnvoll, aber ich mache nur kleinere Anlagen im Sondermaschinenbau, mit einem eigenen Baukasten und da wäre UML und OOP vielleicht doch etwas zu viel des Guten. Und meine Kunden nehmen mir nicht einmal Graph7 ab...
 
Zuletzt bearbeitet:
Interessanterweise fehlt in dieser Diskussion immer CFC... warscheinlich weil sich das nur die wenigsten leisten (wollen)...

Da schreib ich meine Bausteine in der passenden Sprache, meist SCL, aber auch AWL, FUP etc. und verschalte sie dann grafisch in CFC, das macht schon laune... Vor Allem wenn dann durch AS-OS-Übersetzen auch noch der meiste Kram für WinCC automtisch mit angelegt wird...

Beim Siemens CFC holt man sich aber so viele Nachteile durch die Verwendung von CFC ins Haus, dass es die Vorteile wieder aufwiegt.

Beispiele:
- Kein Undo
- Kein "nicht speichern"
- Keine verschachtelten Strukturen/Arrays möglich
- Öfters mal ein Komplettladen inkl. SPS Stop notwendig
- Kein aussagekräftiger Vergleich Online/Offline-Stand möglich (gut, das ist bei SCL auch schlecht)
- Fast alles muss per Maus zusammengeklickt werden, oftmals langsamer
- Kein automatisches Generieren von Programmencode z.B. über Quellenimport möglich (dann brauchts PCS7)

Ich fahre mit FUP als grafischen Ersatz eigentlich ganz gut, da bleibt wenigstens noch etwas Kontrolle über das Programm.
 
Beim Siemens CFC holt man sich aber so viele Nachteile durch die Verwendung von CFC ins Haus, dass es die Vorteile wieder aufwiegt.

naja, sicherlich ist bei CFC auch nicht alles Gold... aber ich würd gerade zu FUP einige Vorteile sehen:

- übersichtlicher (mehr Bausteine auf einer Seite darstellbar als in einem FUP-Netzwerk
- Analoge Berechnungen können einfach schnell zusammengeklickt werden, ohne extra Temp-Variablen zu "erfinden"
- Online Test und Beobachten, einfache Online-Änderung von Parametern
- IDBs werden automatisch generiert, Parametrierung direkt im DB
- keine Merker erforderlich. keine Temp.Variablen erforderlich
- Attribute fürs AS-OS-Übersetzen. Manche funktionieren in FUP garnicht.
- Übersichtlichkeit durch Planordner
- deulich einfacher zu lesen als AWL, und eigentlich auch als FUP

mit PCS7 (Prozessobjektmanager) geht CFC natürlich nochmal angenehmer.

Zum Thema "undo" und "nicht speichern" hat mal ein Siemens-Mensch gesagt: ist auf Grund der Mehrbenutzer-Programmierung weggefallen...

Komplettladen, naja muss man wissen, bei welchen Programmänderungen es notwendig ist. (Was passiert denn in FUP, wenn ich Bausteinein-, ausgänge verändere?)

Gruß.

Gruß.
 
Zurück
Oben