# Jobwechsel - Softwarestandard in neuer Firma



## Simotion84 (3 April 2015)

Guten Tag liebe Experten hier im Forum,

ich habe zum 1.4 diesen Jahres, sprich vorgestern, eine neue Herausforderung begonnen. Nun habe ich in den letzten Tagen Einblick in die Software (Siemens Step7) bekommen. 
Natürlich habe ich noch keinen gesamten Überblick aber das was ich bisher gesehen habe entspricht nicht meiner Vorstellung vom moderner Software. Keine Frage versteht mich nicht falsch, die Software ist mit Sicherheit nicht schlecht und hat sich auch schon in sehr vielen Anlagen bewährt. Die Anlagen sind auch anspruchsvoll (viel Antriebstechnik, Regelungen etc.).

Was mich jetzt durch die ersten Einblicke stört ist, dass sehr viele FCs und Merker und Global DBs verwendet sind. Der Stil ist relativ alt.....

Die Bausteine haben alle Abhängigkeiten ins System und man könnte da einiges "moderner" lösen, um dann einen Standard zu haben welcher auch einigermaßen auf andere Platformen portierbar ist.

Da ich aber erst so kurz da bin weiß ich nicht wie ich das Thema angehen soll, will ja niemand verägern oder als Besserwisser rüber kommen. Was meint ihr dazu? Einfach still bleiben und alles so annehmen oder seine Meinung kundtun? Wie würdet ihr da vorgehen?

Grüße Simon


----------



## Ralle (3 April 2015)

Du hast das schon ganz richtig erkannt. Es kann problematisch werden, wenn man falsch rüberkommt.
Zuerst würde ich mal schauen, was der neue Arbeitgeber so genau von mir erwartet. Vielleicht sollst du ja durchaus innovativ sein und Neues machen.
Auch ist es wichtig zu wissen, wer hat die Software bisher entwickelt, ist der Kollege noch da, wenn ja, wie steht er Neuerungen gegenüber.
Als "Neuer" solltest du versuchen nicht sofort in die Offensive zu gehen, damit bringst du die "Alten" unnötig gegen sich auf. Mit Fingerspitzengefühl erreicht man da sicher am meisten.
Auch wichtig, wenn man anfängt Änderungen vorzunehmen, die Kollegen mitnehmen und erklären was besser ist, warum usw.


----------



## Simotion84 (3 April 2015)

Würdest du/ihr meiner Aussage / Meinung zur Software so zustimmen? Ich weiß du kennst die Software jetzt nicht aber den ganz groben Aufbau hab ich ja erläutert.

Es gibt bestimmt noch ganz viele die so arbeiten (zig Merker und FCs....) aber es soll ja auch mit Blick auf die Zukunft entsprechend vorbereitet sein.


----------



## rostiger Nagel (3 April 2015)

du kannst ja alle Variablen wie Merker und Global-DBs rausschmeißen und durch Schmiermerker
ersetzen, dann die ganze Programmstruktur in einen Baustein packen, am besten in den OB1,
dann muß man nicht lange suchen. 
Durch die Einsparung können bestimmt eine Vielzahl deiner neuen Kollegen ein anderes Aufgabenfeld 
bekommen, so hast du in null Komma nichts deine neue Firma, endlich Wettbewerbsfähig gemacht.

Es gibt doch nichts besseres als alte vertrocknete Strukturen aufzubrechen.


----------



## Simotion84 (3 April 2015)

rostiger Nagel schrieb:


> du kannst ja alle Variablen wie Merker und Global-DBs rausschmeißen und durch Schmiermerker
> ersetzen, dann die ganze Programmstruktur in einen Baustein packen, am besten in den OB1,
> dann muß man nicht lange suchen.
> Durch die Einsparung können bestimmt eine Vielzahl deiner neuen Kollegen ein anderes Aufgabenfeld
> ...



So und genau das meinte ich. Du hast es mir bewiesen das es einfach nicht angebracht ist irgendwo Verbesserungsvorschläge einzubringen bzw mal eine andere Sicht der Dinge einzubringen. Ich weiß dass viele so denken wie du und das ich dann auf einiges an Gegenwehr stoßen werde, weil sich Leute ans bein gepisst fühlen.

Leider hab ich es ja so nicht gemeint (will niemandem schlecht machen) sondern ich wollte damit nur zum nachdenken anregen. 

Software bleibt nunmal nicht immer gleich sondern lebt und verändert sich mit neuen Platformen.


----------



## Thomas_v2.1 (3 April 2015)

Ich würde mich erstmal einarbeiten, und zumindest mal eine Anlage in dem bestehenden Standard programmieren und inbetriebnehmen.
Du weißt vielleicht noch nicht alle Hintergründe, warum dieses und jedes so gemacht wurde. Evtl. gibt es Schnittstellen oder spezielle Software / Tools die darauf aufsetzen und nur aufwändig anzupassen wären.

Wenn du gleich mit deinem neuen Konzept kommst und es passt dann nichts mehr zusammen, stehst du womöglich doof da.


----------



## Simotion84 (3 April 2015)

Ja so werde ich das wohl machen!


----------



## Boxy (3 April 2015)

Erst einmal etwas abwarten und sehen wie es in der Firma zu geht!
Dann ganz langsam einmal die Verbesserungen ggf. anbringen.

Die alten Hasen der Firma sind ja mit dem bisherigen groß geworden und evtl. ist es auch deren Lebenswerk!
Da kann keiner kommen und sagen, das ist alles falsch was ihr da macht ...
Kommt ja evtl. wie schon geschrieben auch auf die Hintergründe darauf an, warum es so gemacht wurde.

Denke dieses Problem kennt jeder von uns der den Job wechselt.
Auch ich bin nicht mit dem zufrieden was ich in der neuen Firma so aufgefunden habe.
Sei es einmal die Tools (da wird z.B. kein SCL genutzt und die Bedienoberfläche nur das nötigste) und auch die Art und weise der Programmierung.
Viele Köche verderben den Brei 
Aber von jetzt auf gleich kann man da nix umstellen! Ich würde zwar auch gerne Standardisieren um die Arbeit für alle zu erleichtern, aber so einfach ist das auch nicht!
Man merkt auch wie man angesehen wird, wenn man mit neuem kommt! Sind halt viele, welche die Art und wiese der S5 Programmierung so auf S7 umgesetzt haben und sich halt einfach nicht verändern wollen (bis sie in Rente gehen) ...


----------



## de vliegende hollander (3 April 2015)

Hallo Simon,

Erst mal so machen wie Ralle und Thomas sagt.

Und in der Regel liegen die karten sowieso neu auf dem Tisch wenn Mann nach TIA umsteigt.
Dann kannst du dich austoben..

Bram


----------



## vollmi (3 April 2015)

Und bedenke man muss damit arbeiten was man hat. Step7 hat nunmal zwei Jahrzehnte auf dem Buckel.
Und so ist es halt auch aufgebaut. Vor zwanzig jahren war das richtig modern.
Viele FCs und FBs sind nunmal nötig um das Programm sauber zu strukturieren. Klar kann man die Sortierfunktion in ein Netzwerk des FB der Stapelmaschine einbauen ohne darin nur den SortierFC aufzurufen. Aber das macht die Sache nicht moderner. FCs und FBs sind die Subfunktionen moderner Programmiersprachen.

Ich finds auch übel das man in Step7 die Bausteine nicht in Ordnerstrukuren einsortieren kann. Muss man halt damit leben.
Und die Scrollorgie die ich in Programmen mit über 100 FBs und FCs habe mag ich garnicht beschreiben.

Wie willst du denn den vielen FCs und FBs Herr werden? Bedenke die das ein FB/FC maximal 64kb gross sein darf. Kannst dir vorstellen dass man bei einer Grossen SPS mit 20 und mehr MB Ladespeicher kommt man um eine grössere Anzahl Bausteine nicht herum.
Wenn du alles in einen Baustein Packst selbst wenn der dann an die Maximalgrösse geht, hast du das Problem dass du immer alles Komplett laden musst. Das öffnen von riesigen Bausteinen dauert auch in Step7 entsprechend lange.

mfG René


----------



## Cassandra (3 April 2015)

Hallo Simon,

bitte höre nicht auf diese Warmduscher!

Wenn du ernst genommen werden willst, dann musst du alles was dir auf den Ersten Blick als nicht "Genial" auffällt, kritisieren. Neue Besen fegen gut!

Nur so werden deine neuen Kollegen richtig überrumpelt und du kannst deinen neuen Standard durchsetzen. Wichtig ist, dass du diesen Standard stetig und ohne Rücksprache verbesserst. Stillstand ist Rückschritt. Auf keinen Fall deine Verbesserungen dokumentieren. Hier könnten Kollegen merken, dass bei dir auch nicht alles auf Anhieb perfekt ist.

Lasse auch die Vorgesetzten oder besser sogar die Geschäftsleitung wissen, was deine Vorgänger alles falsch gemacht haben. Das sichert dich ab, falls deine Kollegen Angst vor deiner Innovation bekommen und dich verunglimpfen wollen.

Auch solltest du alte bestehende Steuerungen optimieren, die gerade keine Probleme machen. Nur so kannst du beweisen, dass mit deiner Technik alles viel harmonischer läuft.

Mit diesen wenigen Tipps, wirst du in kürzester Zeit sehr viel erreichen...  

LG Cassandra


----------



## SPS-freak1 (3 April 2015)

Ich finde diese Diskussion im Grundsatz schon komplett falsch. Ich habe das Glück ziemlich viele Programme zu sehen und bin mittlerweile der Meinung, daß es für einen Instandhalter definitiv leichter ist, wenn er eine klassische schrittkette mit normalen merkern sieht bevor er sich erstmal in Sachen reindenken muss die total abstrakt wirken. Und mit absoluten merkern zu arbeiten hat immer noch seinen scharm, Vorallem wenn es viele ähnliche Abläufe gibt. Str+c, Str+V und suche ersetzen sind da meine Freunde


----------



## RobiHerb (3 April 2015)

Der "Neue" hat schon mit Recht festgestellt, dass er auf einer anderen Wellenlänge schwingt als die Firma.

In der Regel geht das schief, wenn das ein grösserer Laden ist und man als neuer unter den Kollegen erst einmal der "Kleine" ist.

Da wir in unserem Job zum Glück uns den Arbeitgeber aussuchen können, wenn wir uns etwas zutrauen, ist somit das Kind nicht gleich in den Brunnen gefallen.

Wenn mir nach 3 Monaten Probezeit (man kann das ja auch von seiner Seite sehen) das immer noch so vorkommt wie am Anfang, dann würde ich wechseln. Vielleicht hat man aber auch Glück und die Chefs haben das Problem erkannt und genau deshalb jemanden mit anderen Ideen an Bord geholt.

Man ist Softwerker nicht Missionar.


----------



## Draco Malfoy (4 April 2015)

Ich würde da keinen großen Aufstand deswegen machen. Sofern neue Bausteine entwickelt werden müssen, kann man da einen besseren Standard anregen, aber GRUNDSÄTZLICH spricht ja nichts gegen etwas Globalmerker und Global-DBs.

Du musst das so sehen, moderne Standards bringen dann nur wirklich etwas, wenn die effektiv sind. Wenn beispielsweise 20-30 verschiedene Anlagenvarietäten verfügbar sind, und die derzeit alle unterschiedliche Merkerbereiche haben - da würde ich tatsächlich eine Vereinheitlichung anstreben. Aber solange es nur dieselben 2-3 Serienmaschinen sind, die vielleicht 4-6 verschiende Ausbaustufen jeweils zulassen, und die Merkerbereiche sowieso überall gleich belegt und gleich symbolisiert sind - wo ist denn dabei das Problem ? Stell Dir vor, Du müsstest auf einmal mehrere Mitarbeiter umschulen, die möglicherweise alle diese Globalmerker bisher nachts im Schlaf mit Absolutadressen aufsagen konnten. Das wäre schon eher ein Problem, weil darunter zunächst einmal die Arbeitseffizienz leidet.

Beim Umstieg auf die 1500er Steuerungsgeneration kann man sich dann grundlegendere Gedanken über den Systemaufbau machen und diese Unebenheiten beseitigen.


----------



## rostiger Nagel (4 April 2015)

Aber Grundsätzlich ist er ja gegen Merker und Global-DBs, da bleibt ja nicht viel übrig um Variablen zu Deklarieren.
Am besten ein Program ganz ohne Variablen.


----------



## Blockmove (4 April 2015)

Wenn man Qualität, Wartbarkeit und Modularität nur an FC, Global-DBs und Merkern festmacht, dann ist das schlichtweg ein Fehler.
Es gibt Firmen die seit über 30 Jahren ihren Standard gepflegt und weiterentwickelt haben. Bestimmte Bezeichnungen, Symbole und Programmstrukturen findest du da an 25 Jahre alten Maschinen schon.
Für Kunden, Inbetriebnehmer und Instandhalter gibt es eigentlich kaum was besseres. Vorallem bei Maschinenlaufzeiten von >20Jahren.

Bei der ganzen Diskussion muss man immer betrachten, dass Programmieren nicht Selbstzweck sein darf.
Im "Ökosystem" Maschine gibt es eben viele Tiere und nicht nur den Programmierer

Gruß
Dieter


----------



## norustnotrust (4 April 2015)

Gegenfrage: Ist es nicht etwas vermessen nach drei Arbeitstagen zu glauben man weiß es besser als die, die das schon Jahre machen?

Ansonsten möchte ich mich meinen Vorrednern im Großen und Ganzen anschließen und noch das eine oder andere ergänzen.

1.) Du wirst einige Zeit brauchen um überhaupt zu erkennen ob das was "die" machen Sinn macht oder verbesserbar ist. Man weiß in ein paar Wochen (oder Tagen) noch nicht "wie der Hase läuft"! Auch kenne ich das Thema dass manche Kunden eigene Standards durchsetzen und man seinen "Hausstandard" nicht in Konflikt mit seinen wichtigsten Kundenstandards bringen wird.

2.) Grundlegende Änderungen im Standard sollten immer wohl überlegt sein. Die müssen sich alle mal amortisieren und das ist nicht so leicht. Bedenke neben den reinen Initialkosten (programmieren, dokumentieren und schulen) auch immer die Folgekosten (Verwendbarkeit alten Codes sinkt, du musst den alten Code nach ein paar Jahren mit erhöhtem Aufwand servicieren  usw...) Summa Summarum kommen da bald mal große Summen bei gar nicht großen Änderungen raus und das muss man erst mal verdienen.

3.) Ist Vieles einfach nicht endgültig zu entscheiden. Manchmal sind mehrere Ansätze richtig UND falsch! Ein guter Standard ist immer ein Kompromiss verschiedenster Aspekte und Meinungen. Und da werden imho oftmals fundamentale Aspekte wie "dass es einfach ist" viel zu leicht abgetan.

4.) Würde ich in einen Pre-TIA Standard grundsätzlich nicht mehr all zu viel Mühe investieren.

Das soll natürlich nicht heißen dass du nicht was Anderes vorschlagen sollst, nur würde ich mal versuchen zu verstehen warum das jetzt so gemacht wird. Die Frage "Warum macht ihr das so?" tut nicht weh. Und halt nicht zu beleidigt sein wenn die Kollegen oder Chef Gründe hat warum er/sie es so machen.


----------



## rostiger Nagel (4 April 2015)

norustnotrust schrieb:


> Gegenfrage: Ist es nicht etwas vermessen nach drei Arbeitstagen zu glauben man weiß es besser als die, die das schon Jahre machen?



Wenn man es genau nimmt sind es sogar nur zwei Tage, wenn man den Karfreitag 
mit rechnet. Deshalb finde ich es nicht nur vermessen, sondern dreist.


----------



## Blockmove (4 April 2015)

rostiger Nagel schrieb:


> Wenn man es genau nimmt sind es sogar nur zwei Tage, wenn man den Karfreitag
> mit rechnet. Deshalb finde ich es nicht nur vermessen, sondern dreist.



Ich hab schon einige Programme (auch von "Marktführern") gesehen bei denen mir 10 Minuten gereicht haben um zu erkennen, dass sie Scheiße sind ...

Schöne Ostern
Dieter


----------



## lilli (4 April 2015)

Also ich finde, ihr tut Simon ein bisschen Unrecht.

Klar kann man in den ersten zwei Arbeitstagen nicht alles sichten und sich ein unfassendes Urteil bilden. In dieser Zeit gleich mit ausführlichen Verbesserungen rüberzukommen, ist auch kein guter Stiel.

Andererseits braucht es auch keine zwei Tage, um grundsätzliche Strukturschwächen zu erkennen. 
Da wären:
- nahezu keine Verwendung standardisierter Bausteine für wiederkehrende Funktionen
- keine Verwendung von IEC- Timer (hat sich noch nicht überall rumgesprochen, dass es so was gibt) :roll:
- Sehr umfangreicher Einsatz von Merkern, verteilt über de ganzen Adressbereich
- Vielfaches verteiltes Setzen und Rücksetzen diverser Signale
- Flankenmerker im Temp- Bereich 
- keine logische durchgängige Namensgebung bei Variablen
- fehlende Netzerwerküberschriften, Symbolnamen oder Kommentare 
- kein Bezug der E/As zum Schaltplan (z.B. andere Namensgebung)
- kompletter Verzicht auf UDT und Multiinstanzen

Sollte das so sein und zudem noch alles auf S7-Klassik basieren, dann wäre es doch sinnvoll, beim Umstieg auf TIA gewisse alte Praktiken zu hinterfragen. 


Wenn ich manchmal Genossen sehe, die ihre Altlasten um biegen und brechen portieren wollen, könnte ich kotzen! In solchen Fällen, kann TIA nicht oft genug abstürzen... :twisted:

Liebe Grüße
Lilli


----------



## JaJa (4 April 2015)

Simotion84 schrieb:


> Guten Tag liebe Experten hier im Forum,
> 
> Nun habe ich in den letzten Tagen Einblick in die Software (Siemens Step7) bekommen.
> aber das was ich bisher gesehen habe entspricht nicht meiner Vorstellung vom moderner Software.



Kann es sein das Du vom TIA Portal sprichst ...


----------



## Simotion84 (4 April 2015)

Ich will ja niemand direkt angehen bzw kritisieren. Wie gesagt ich glaube ja das alles bisher etabliert und auch in Vergangenheit genau das richtige war. Aber mit Blick auf die weitere Zukunft wird sich einiges verändern, auch in der SPS Programmierung. 

Ich spreche im Bezug auf S7 1500 und natürlich auch TIA. Schaut euch die Software Guidlines von Siemens dazu an. Es wird Veränderungen geben, auch Siemens wird in Zukunft auf objektorientierung setzen. 

Klar bin ich einfach nur ein kleiner Programmierer und meine Meinung zählt in einer neuen Firma nicht viel. Aber ich werde diese Veränderungen annehmen und nicht komplett ignorieren. Wie gesagt ich will niemanden verärgern oder schlecht machen deswegen werde ich auch nichts dazu sagen und die Zukunft abwarten....

Grüße Simon


----------



## Simotion84 (4 April 2015)

lilli schrieb:


> Also ich finde, ihr tut Simon ein bisschen Unrecht.
> 
> Klar kann man in den ersten zwei Arbeitstagen nicht alles sichten und sich ein unfassendes Urteil bilden. In dieser Zeit gleich mit ausführlichen Verbesserungen rüberzukommen, ist auch kein guter Stiel.
> 
> ...



Genau das trifft alles zu, sogar die Flankenmerker im TEMP Bereich....


----------



## vollmi (5 April 2015)

Flankenmerker im Temp Bereich sind aber einfach Fehler. Keine philosophiefrage. Die kann man ruhig aufzeigen. 


Sent from my iPhone using Tapatalk


----------



## Blockmove (5 April 2015)

Simotion84 schrieb:


> Es wird Veränderungen geben, auch Siemens wird in Zukunft auf objektorientierung setzen.



Dazu hätte Siemens bei der 1500er die Gelegenheit gehabt ... Was sie da aber abgeliefert haben hat nur sehr sehr wenig mit OOP zu tun.
Ich habe seither schon mit Classic vollsymbolisch programmiert und mache viel Gebrauch von UDTs und Strukturen. Bei der 1500er kann ich nicht viel Fortschritt in Richtung OOP erkennen.
Ich würde sagen, dass Siemens einfach die Prozedurale Programmierung vervollständigt hat (Zugriff auf Array in KOP und FUP, Verwendung von Views).

Wenn du den Standard deines Arbeitgebers modernisieren willst, dann musst du auch die Einsatzbedingungen der Maschinen oder Anlagen bedenken.
Ein Kollege von mir hat bei einer Fördertechnik alle Funktionen in FBs gepackt. Wenn sich nun was ändert, dann ändern sich natürlich oft auch die Instanz-DBs.
Ein Einspielen im laufenden Fertigungsbetrieb ist so kaum möglich. Ähnliche Themen findest du auch in der Verfahrens und Prozesstechnik.

Gruß
Dieter


----------



## Simotion84 (5 April 2015)

Blockmove schrieb:


> Dazu hätte Siemens bei der 1500er die Gelegenheit gehabt ... Was sie da aber abgeliefert haben hat nur sehr sehr wenig mit OOP zu tun.
> Ich habe seither schon mit Classic vollsymbolisch programmiert und mache viel Gebrauch von UDTs und Strukturen. Bei der 1500er kann ich nicht viel Fortschritt in Richtung OOP erkennen.



Aus bestimmten sicheren Quellen weiß ich, dass OOP in Zukunft Einzug in das TIA Portal erhält. Siemens hat da zwar etwas verschlafen zur Konkurrenz aber es wird daran gearbeitet. Und wenn diese Funktionen integriert sind, dann wird sich der Aufbau und die Struktur eh komplett ändern (zumindest wenn man nach OOP programmiert)

Grüße Simon


----------



## Thomas_v2.1 (5 April 2015)

Simotion84 schrieb:


> Aus bestimmten sicheren Quellen weiß ich, dass OOP in Zukunft Einzug in das TIA Portal erhält. Siemens hat da zwar etwas verschlafen zur Konkurrenz aber es wird daran gearbeitet. Und wenn diese Funktionen integriert sind, dann wird sich der Aufbau und die Struktur eh komplett ändern (zumindest wenn man nach OOP programmiert)



Auweia, vor dem Ergebnis des Ganzen habe ich jetzt schon Angst. Eine neue Quelle für viele schöne Bugs im TIA-Portal.


----------



## Ralle (5 April 2015)

lilli schrieb:


> Also ich finde, ihr tut Simon ein bisschen Unrecht.
> 
> Klar kann man in den ersten zwei Arbeitstagen nicht alles sichten und sich ein unfassendes Urteil bilden. In dieser Zeit gleich mit ausführlichen Verbesserungen rüberzukommen, ist auch kein guter Stiel.
> 
> ...



Von den Temp mal abgesehen.
Sicher tust du da eher den "alten Programmen" etwas unrecht. Es kommt immer darauf an, wie es gemacht ist, ich persönlich habe nichts gegen Merker, wenn die Bereiche klar geordnet sind, auch IEC-Timer sind kein muß, man hat von den S7-Timern eine ganze Menge, kann die ebenfalls klar zuteilen (so man will) und braucht keine DB dafür!!!!!!! Und Multiinstanzen sind auf der S7 ein Quell steten steigenden Blutdrucks bei Fehlersuche und Änderungen am lebenden Objekt. "Alte" Programme sind, entgegen der Meinung manche junger Programmierer, eben nicht nur Müll, sondern oft mit viel Erfahrung und auch bitteren Erfahrungen entstanden. Wer meint, das mal eben gegen "Neue tolle" Software tauschen zu können und das mit vielleicht 3 Jahren Berufserfahrung, den lass ich das gerne probieren. Ich setz mich einfach ans Ufer und warte, bis er wieder verbeitreibt.... Und glaub mir, bis auf die wenigen ganz Genialen (und auch die gibt es), kamen sie bisher alle angetrieben!
Das heißt nicht, dass man nichts Neues machen soll, aber den Verstand sollte man dabei benutzen und das rate ich auf jeden Fall dem TE.


----------



## Blockmove (5 April 2015)

Simotion84 schrieb:


> Aus bestimmten sicheren Quellen weiß ich, dass OOP in Zukunft Einzug in das TIA Portal erhält. Siemens hat da zwar etwas verschlafen zur Konkurrenz aber es wird daran gearbeitet. Und wenn diese Funktionen integriert sind, dann wird sich der Aufbau und die Struktur eh komplett ändern (zumindest wenn man nach OOP programmiert)
> 
> Grüße Simon



Ja, es wird daran gearbeitet. Das hab ich auch gehört. Aber zur Zeit hat wohl die Stabilisierung und Vervollständigung von TIA die höchste Prio.
Ob es allerdings soviel Auswirkung auf die Programmierung haben wird, weiß ich nicht.
Bei Siemens gibt es ein Projekt "Digitale Fabrik".Ein Teil davon ist Schaffung von Schnittstellen zwischen TIA und NX (3D-CAD).
Hört sich in mancher Hinsicht interessant an (Simulation, Code-Generierung, Visualisierung ...). In wie weit aber die Objekte die dann in NX erstellt werden auch eine OO-Programmierung nach sich ziehen bleibt abzuwarten.

Gruß
Dieter


----------



## lilli (5 April 2015)

Ralle schrieb:


> Von den Temp mal abgesehen.
> Sicher tust du da eher den "alten Programmen" etwas unrecht. Es kommt immer darauf an, wie es gemacht ist, ich persönlich habe nichts gegen Merker, wenn die Bereiche klar geordnet sind, auch IEC-Timer sind kein muß, man hat von den S7-Timern eine ganze Menge, kann die ebenfalls klar zuteilen (so man will) und braucht keine DB dafür!!!!!!! Und Multiinstanzen sind auf der S7 ein Quell steten steigenden Blutdrucks bei Fehlersuche und Änderungen am lebenden Objekt. "Alte" Programme sind, entgegen der Meinung manche junger Programmierer, eben nicht nur Müll, sondern oft mit viel Erfahrung und auch bitteren Erfahrungen entstanden. Wer meint, das mal eben gegen "Neue tolle" Software tauschen zu können und das mit vielleicht 3 Jahren Berufserfahrung, den lass ich das gerne probieren. Ich setz mich einfach ans Ufer und warte, bis er wieder verbeitreibt.... Und glaub mir, bis auf die wenigen ganz Genialen (und auch die gibt es), kamen sie bisher alle angetrieben!
> Das heißt nicht, dass man nichts Neues machen soll, aber den Verstand sollte man dabei benutzen und das rate ich auf jeden Fall dem TE.



Hallo Ralle,

ich kritisiere weder das Alter von Programmen noch das Alter von Kollegen. Meine Kritik gilt einzig dem fehlen gewisser Strukturen. Und diese finde ich, kann man mit gewissen "modernen Mitteln"(*) besser erreichen, als mit Programmrelikten die aus der S5-Zeit aus Kompatibilitätsgründen nach S7 übernommen worden sind. 

Gegen welches der 9 aufgezählten Punkte kannst du ein vernünftiges Gegenargument liefern?

Liebe Grüße
Lilli 

*Diese "modernen Mittel" sind auch schon 20 Jahre alt!


----------



## Thomas_v2.1 (5 April 2015)

Blockmove schrieb:


> Ja, es wird daran gearbeitet. Das hab ich auch gehört. Aber zur Zeit hat wohl die Stabilisierung und Vervollständigung von TIA die höchste Prio.
> Ob es allerdings soviel Auswirkung auf die Programmierung haben wird, weiß ich nicht.
> Bei Siemens gibt es ein Projekt "Digitale Fabrik".Ein Teil davon ist Schaffung von Schnittstellen zwischen TIA und NX (3D-CAD).
> Hört sich in mancher Hinsicht interessant an (Simulation, Code-Generierung, Visualisierung ...). In wie weit aber die Objekte die dann in NX erstellt werden auch eine OO-Programmierung nach sich ziehen bleibt abzuwarten.



Unschön an allem was Siemens momentan im TIA-Portal entwickelt ist, sich in allem bestimmte Entwicklungen wiederfinden:
- Es werden keine offenen Schnittstellen verwendet
- Bekannte Standards und Vorgehensweisen werden ignoriert, wenn diese nicht von Siemens selber entwickelt wurden (not invented here Syndrom). Es muss eine eigene Lösung her, auch wenn diese schlechter ist. Und da Codesys die OO schon etwas länger beackert und Erfahrungen hat, wird es von Siemens garantiert etwas komplett anderes geben.

Aber back2topic:
Bezüglich globalen Merkern habe ich wieder einen Schritt zurück hin zu den Merkern gemacht. Merker kommen bei mir hauptsächlich zum Einsatz um Befehle von Automatiken an Antriebsbausteine weiterzugeben. Ich wollte die Merker dann wegoptimieren, und mit den Befehlen komplett über die Schnittstelle gehen. Vom Prinzip her funktioniert das zwar, hat aber einige Nachteile. 
Man deklariert sich "einen Wolf", d.h. erst an der Schnittstelle vom Automatikbaustein heraus, dann in den Baustein der Antriebsbausteine wieder hinein, und dazwischen will man ja auch keiner Merker haben, d.h. in den Temp Variablen nochmal die Variablen anlegen, damit auch alles schön mit Symbol und auch nachvollziehbar ist.

Nächster Nachteil: Ich bin in Freund der "Gehe zur Verwendungsstelle" Funktion. Wenn es in einem Programm ein Fehler gibt, gehe ich oft erst zum Antriebsbaustein, und prüfe über die Verwendungsstelle des Startbefehls woher der Startbefehl kommt. Mit Merkern ist das nur ein Schritt um zu der Stelle zu springen von der der Automatikstart kommt. Wenn man das über zig Schnittstellen nachvollziehen muss, war das im Nachhinein sehr nervig.
Darum habe ich das Konzept verworfen und habe jetzt wieder Merker dafür verwendet. Ich habe auch schonmal direkt in den Instanz-DB des Antriebs geschrieben, was aber noch mehr Nachteile hat.


----------



## MSB (5 April 2015)

Simotion84 schrieb:


> Aus bestimmten sicheren Quellen weiß ich, dass OOP in Zukunft Einzug in das TIA Portal erhält. Siemens hat da zwar etwas verschlafen zur Konkurrenz aber es wird daran gearbeitet. Und wenn diese Funktionen integriert sind, dann wird sich der Aufbau und die Struktur eh komplett ändern (zumindest wenn man nach OOP programmiert)


Ganz ehrlich bis TIA überhaupt mal einen derart zuverlässigen Stand erreicht hat wie z.B. Step7, sollte Siemens an sowas wie OOP noch nicht mal denken.
Zumal das ja dann scheinbar auch wieder nur irgendwie dazugebastelt sein wird, da im jetzigen Stand noch nicht mal wie auch immer geartete zarte Ansätze erkennbar sind.
Desweiteren sprechen wir da wohl wenn dann von Zeiträumen, die es für  die Berücksichtigung in heutigen Standards quasi vollkommen  uninteressant machen.
Die nächste Problematik wird dann natürlich sein, das die Kollegen dann  endgültig auf Block gehen, weil das dann nicht mal mehr in Ansätzen  deren offensichtlicher Denkweise entspricht.

Ob das ganze dann über Jahre bis Jahrzehnte betrachtet "wartbarer"  oder einfacher wird möchte man dann sowieso noch dahingestellt lassen,
dazu werden die meisten SPS-Projekte einfach mit viel zu schlechter Planung in viel zu kurzer Zeit durchgezogen, und letzten Endes von Teilfunktionen abgesehen auch viel zu individuell.


----------



## Ralle (5 April 2015)

lilli schrieb:


> Hallo Ralle,
> 
> ich kritisiere weder das Alter von Programmen noch das Alter von Kollegen. Meine Kritik gilt einzig dem fehlen gewisser Strukturen. Und diese finde ich, kann man mit gewissen "modernen Mitteln"(*) besser erreichen, als mit Programmrelikten die aus der S5-Zeit aus Kompatibilitätsgründen nach S7 übernommen worden sind.
> 
> ...



Darum geht es gar nicht, es geht nur um Sinn und Unsinn, ständig zu meinen alle, die schon graue Haare haben, sind ein wenig senil und dusselig und haben ihr halbes Leben lang nur Schwachsinn getrieben, keine Ahnung von Struktur und schon gar keine Ahnung vom Business. Sie halten oft an den Gewohnheiten fest, weil sie diese Gewohnheiten genau kennen und gut damit umgehen können. Ihre Programme laufen und die laufen oft 10 Mal besser als irgendwelches abgehobenes OOP-Informatikergestammel, genau weil es eher praxisorientiert ist. Solchen Kollegen kann man ja mal mit den vom TE wohlgemeinten Argumenten kommen, da hast du gleich verloren. Ich denke, das ein Prozess der Änderung nur langsam vorgenommen werden kann, sonst wird das nichts. Ich hab auch schon Firmen erlebt, die haben es probiert, 2 neue Leute, die haben eine neue Software aufgesetzt, alles toll, Multiinstanzen, UDT, tief verschachtelte Strukturen. Dauerte ganz schön lang, lief auch so lá lá, aber dann zogen die Kollegen weiter, die hatten keinen Bock mehr und fanden einen neuen Arbeitgeber, der mehr zahlte. Dann saß man da mit einem schicken Standard, 80% war ok, aber keiner wollte oder konnte so richtig damit. Und es gibt wirklich auch ältere Kollegen,denen fällt es durchaus auch schwer, noch einmal "von vorn" anzufangen. 

Deine Kritik ist überspitzt und es ist alles zusammengetragen, was man so an negativem in SPS-Programmen finden kann. Wenn ich suche, finde ich das bei mir im übrigen auch und wenn du glaubst, bei dir wäre alles toll, schick mir halt mal deine Wundersoftware.


----------



## MSB (5 April 2015)

lilli schrieb:


> Andererseits braucht es auch keine zwei Tage, um grundsätzliche Strukturschwächen zu erkennen.
> Da wären:
> - nahezu keine Verwendung standardisierter Bausteine für wiederkehrende Funktionen
> Was sind denn wiederkehrend Funktionen in aller Pauschalität ... bei mir bleibt da außer wie auch immer gearteten "Treiberbausteinen" für Sensoren oder Aktoren meist nicht sehr viel übrig.
> ...



Anmerkungen im Text ...


----------



## bike (6 April 2015)

lilli schrieb:


> Also ich finde, ihr tut Simon ein bisschen Unrecht.
> 
> Klar kann man in den ersten zwei Arbeitstagen nicht alles sichten und  sich ein unfassendes Urteil bilden. In dieser Zeit gleich mit  ausführlichen Verbesserungen rüberzukommen, ist auch kein guter Stiel.
> 
> ...



Also so leid es mir tut, ich kann deiner "Stellungsnahme" keinerlei sinnvolle Aussage erkennen.
Alles was war ist schlecht?
Die "alten" Programmierer können nichts und sind nicht lernfähig?
OOP ist die Lösung? (Kann ich mein Problem zurück bekommen?)
Die haben auch noch keine Maschine oder Anlage zum funktionieren gebracht.
Gut dass es dich gibt.

Ich denke du solltest einmal nachdenken.
Dass sich die Technik weiterentwickelt ist gut und wichtig.
Doch aus einer Maschine Win$ zu machen ist eben nicht sinnvoll und auch nicht möglich.
Und wenn in einer Firma Standards bestehen, dann macht das Sinn, auch wenn es nicht sofort von dem Neuen erkannt wird.
Was  ist schlecht von den "Alten" zu lernen? Es macht keinen Sinn, das Ras  neu zu erfinden, denn es läuft schon seit Jahrtausenden.
Wenn jeder seinen Stuß, den er oder sie gerade im Kopf hat, wird es für eine Firma unbezahlbar.
Der Kollege tut gut daran zuerst zu verstehen, warum was wie realisiert wird und dann über Neuerungen nachzudenken.
Wenn er das nicht will, dann eben wechseln.
Mir gehen die "revolutionärem" Neuerungen, die von Studis eingeführt werden die Hutschnur  hoch. 
Was denkst du wie es möglich ist, dass  wie bei uns ca 800 Techniker weltweit unsere Programme verstehen?

Zu dem Bezug der E/A auf die Hardware noch ein Hinweis:
Erkläre das den Kunden, die das wollen und auch dafür bezahlen.
Aber wenn ihr kein Geld verdienen müsst, wir müssen.


bike


----------



## lilli (6 April 2015)

MSB schrieb:


> Anmerkungen im Text ...



@All: Ich bleibe mal bei der sachlichen Diskussion von MSB, dann wird das etwas weniger Polemisch... 

Andererseits braucht es auch keine zwei Tage, um grundsätzliche Strukturschwächen zu erkennen.
Da wären:
- nahezu keine Verwendung standardisierter Bausteine für wiederkehrende Funktionen
Was sind denn wiederkehrend Funktionen in aller Pauschalität ... bei mir bleibt da außer wie auch immer gearteten "Treiberbausteinen" für Sensoren oder Aktoren meist nicht sehr viel übrig.
- Füllstandsüberwachung die mit Analogwert und Grenzwerten versorgort wird und hinten die Warnungen und Störungen ausspukt
- Laufzeitüberwachungen die universell einzelne Signale, oder auch gleich alle Rückmeldungen an Stellorganen wie pneumatischen/hydrauschen/motorischen Schieber auswertet
- Treiberbausteine für Antriebe, die diese Laufzeitüberwachung bereits integriert haben...

- keine Verwendung von IEC- Timer (hat sich noch nicht überall rumgesprochen, dass es so was gibt)
Macht aber auch nur in FB's mit Multiinstanzen wirklich sinn, wobei es das in Bezug auf Änderbarkeit im laufenden Betrieb die Sache definitiv nicht leichter macht
- Sehr wahrscheinlich wird das Programm in einem FB geschrieben sein. Wenn nicht, wäre es Zeit dies zu tun. Wenn man dann noch pauschal 10-20% Timer mehr deklariert als notwendig, ist man immer gut aufgestellt. Somit muss man den IDB bei den meisten Änderungen nicht mit übertragen. Für andere "Standardbausteine" gilt das selbe...

- Sehr umfangreicher Einsatz von Merkern, verteilt über de ganzen Adressbereich
Merker sind nüchtern betrachtet auch nur globale Variablen, was anderes gibt es bei Siemens effektiv ja eh nicht, auch nicht bei der Spezialität DB in den div. Variationen.
- Da hast du recht. Warum sollte man die dann nicht gleich in einen Global-DB packen, damit der Merkerbereich für Inbetriebnahme oder Sonderanwendungen mit lockierten Adressen (z.B. Modbus) zur Verfügung steht?

- Vielfaches verteiltes Setzen und Rücksetzen diverser Signale
Damit magst du wohl recht haben

- Flankenmerker im Temp- Bereich 
Ist keine Struckturschwäche sondern einfach ein Fehler, steht so gesehen also nicht zur Diskussion.

- keine logische durchgängige Namensgebung bei Variablen
- fehlende Netzerwerküberschriften, Symbolnamen oder Kommentare
Das wäre ja jetzt relativ leicht zu ändern ...
- Anscheinend nicht! Aber vernünftig...

- kein Bezug der E/As zum Schaltplan (z.B. andere Namensgebung)
Gab es auch schon mal eine Diskussion zu ... kommt ein wenig drauf an würd ich sagen, sicherlich keine pauschale Sache ...
- kommt auch durch die Beschränkung auf 25 Zeichen die Siemens bisher im Symbol zugelassen hatte. Immerhin der Kommentar ist etwas länger.

- kompletter Verzicht auf UDT und Multiinstanzen
Keine Ahnung warum das jetzt in aller Pauschalität ein Nachteil sein muss.
Bei durchsichten von fremden Programmen ... deren Logik man nicht auf den ersten Blick erfasst ist das alles defintiv zunächst mal kein Vorteil.
z.B. weil einem Querverweise in aller Regel nichts bringen, und auch weil da (leider) noch viel mehr Schweinereien möglich sind, die sicherlich auch jeder schon mal in der ein oder anderen Form gesehen hat.
IEC- Timer ohne Multiinstanzen? - Das wäre übel!
Keine fertigen Strukturen für sich zig mal wiederholenden Variablen mit identischen Schnittstellensignalen? - Tippt Ihr so schnell und so Fehlerfrei, als dass Ihrs solch tolle Hilfsmittel nicht nötig hättet?
Das verstehe wer will! 


Liebe Grüße
Lilli


----------



## Draco Malfoy (6 April 2015)

lilli schrieb:


> - Füllstandsüberwachung die mit Analogwert und Grenzwerten versorgort wird und hinten die Warnungen und Störungen ausspukt
> - Laufzeitüberwachungen die universell einzelne Signale, oder auch gleich alle Rückmeldungen an Stellorganen wie pneumatischen/hydrauschen/motorischen Schieber auswertet



Also bei Stellventilen und Füllstandsüberwachung klingt mir das eigentlich immer weniger nach Fertigungsautomation und immer mehr nach Prozessautomation. Das muss man trennen, da gelten nämlich auch andere Standards. In der Prozessautomation werden alle Bausteine in SCL geschrieben, Verschaltung erfolgt im CFC / SFC und eigentlich benutzt man dafür auch die APL zusammen mit WinCC und PCS 7. Wenn man ganz crazy drauf ist, dann ersetzt man die APL durch eine eigens entwickelte Library, wenn man meint daß es damit besser geht. Einen aktuellen Bezug zu der momentanen Diskussion kann ich darin nicht erkennen, weil nach allem was bisher gesagt wurde, arbeitet der TS nicht in der Prozessbranche.

Klar kann ich in einer Maschine auch ein Paar Proportionalventile und Füllstände haben, aber falls wir uns dabei nicht in der Prozesswelt befinden, werden daraus simple kleine Treiberbausteine, so wie MSB gesagt hat.


----------



## MSB (6 April 2015)

@Lilli
Nicht das ich dir grundsätzlich widersprechen würde, meine Programme nutzen auch zahlreiche deiner gerühmten Struckturierungen,
aber gerade deshalb sind mir auch die Nachteile dieser Arbeitsweise voll bewusst, und eben jene klammerst du in deinem pauschalierten Statement vollkommen aus.
Und das ist pauschal genau so falsch wie richtig.


----------



## rostiger Nagel (6 April 2015)

Ich finde es schön etwas komisch das hier Leute für jemanden einsetzen, den
Sie nicht kennen, gegen einer Firma die sie nicht kennen, deren Arbeitsweise 
und Grund für diese. Der User hat erst zwei Tage die Firma von innen gesehen,
stellt im Internet alles in Frage, anstatt mal die neuen Kollegen direkt zu fragen.

So einen Mitarbeiter wünsche ich keinen Arbeitgeber.


----------



## UniMog (6 April 2015)

Draco Malfoy schrieb:


> Also bei Stellventilen und Füllstandsüberwachung klingt mir das eigentlich immer weniger nach Fertigungsautomation und immer mehr nach Prozessautomation. Das muss man trennen, da gelten nämlich auch andere Standards. In der Prozessautomation werden alle Bausteine in SCL geschrieben, Verschaltung erfolgt im CFC / SFC und eigentlich benutzt man dafür auch die APL zusammen mit WinCC und PCS 7. Wenn man ganz crazy drauf ist, dann ersetzt man die APL durch eine eigens entwickelte Library, wenn man meint daß es damit besser geht. Einen aktuellen Bezug zu der momentanen Diskussion kann ich darin nicht erkennen, weil nach allem was bisher gesagt wurde, arbeitet der TS nicht in der Prozessbranche.
> 
> Klar kann ich in einer Maschine auch ein Paar Proportionalventile und Füllstände haben, aber falls wir uns dabei nicht in der Prozesswelt befinden, werden daraus simple kleine Treiberbausteine, so wie MSB gesagt hat.



Soll man auf den Quatsch wirklich was antworten ??........ Liegt das an dem "Wenn man ganz crazy drauf ist" oder wo kommen diese intelligenten Lebensweisheiten her ??


----------



## Draco Malfoy (6 April 2015)

UniMog schrieb:


> Soll man auf den Quatsch wirklich was antworten ??........ Liegt das an dem "Wenn man ganz crazy drauf ist" oder wo kommen diese intelligenten Lebensweisheiten her ??


Was zum Geier soll daran Quatsch sein ? Daß man Prozessautomation auch ohne APL aufbauen kann ? Und wie das geht!

```
FUNCTION_BLOCK BST_VALVE_400
NAME:BSTVALVE
FAMILY:BST
AUTHOR:BADBIT
//VERSION:'2.0'
//FB 630

// Typical-Attribute
{
  S7_tasklist:='OB100,OB101';
  S7_m_c:='true';
  S7_blockview:='big'
}

// Parameterattribute
// S7_visible       sichtbar/unsichtbar (default='true')
// S7_m_c           WinCC - Tag         (default='false')
// S7_dynamic       Testmodus           (default='false')
VAR_INPUT
    LOCK        {S7_dynamic:='true'} : BOOL := FALSE; // Interlock
    ERR_EXTERN  {S7_dynamic:='true'} : BOOL := FALSE; // External Error
    LIOP_SEL    {S7_dynamic:='true'} : BOOL := FALSE; // 0=Operator 1=Linking
    L_AUT       {S7_dynamic:='true'} : BOOL := FALSE; // 0=Manual 1=Automatic
    L_REMOTE    {S7_dynamic:='true'} : BOOL := FALSE; // 0=Lokal 1=Remote
    L_SIM       {S7_dynamic:='true'} : BOOL := FALSE; // 0=Normal 1=Simulation
    L_RESET     {S7_dynamic:='true'} : BOOL := FALSE; // 1=Reset Error Peripherie
    AUT_OP      {S7_dynamic:='true'} : BOOL := FALSE; // 1=CMD OPEN Automatic
    MAN_OP      {S7_dynamic:='true'} : BOOL := FALSE; // 1=CMD OPEN Manual
    SIM_OP      {S7_dynamic:='true'} : BOOL := FALSE; // 1=CMD OPEN Simulation
    FB_OPEN     {S7_dynamic:='true'} : BOOL := FALSE; // Feedback VALVE open
    FB_CLOSE    {S7_dynamic:='true'} : BOOL := TRUE;  // Feedback VALVE close
    L_MON       {S7_dynamic:='true'} : BOOL := TRUE;  // 1=Monitoring Feedback OPEN
    MON_T       {S7_dynamic:='true'; S7_m_c := 'true'} : REAL := 10.0; // Monitoring Time

    SAMPLE_T    {S7_sampletime:='true'} : REAL := 0.0; // Sample Time
   
    // Message blocks
    MSG1_EVID { S7_visible  :='false';
                S7_link     :='false';
                S7_param    :='false';
                S7_server   :='alarm_archiv';
                S7_a_type   :='alarm_8p'}: DWORD :=0;
    MSG2_EVID { S7_visible  :='false';
                S7_link     :='false';
                S7_param    :='false';
                S7_server   :='alarm_archiv';
                S7_a_type   :='notify_8p'}: DWORD :=0;
END_VAR

VAR_IN_OUT
    OP_dwCmd    {S7_dynamic := 'true'; S7_m_c := 'true'} : DWORD :=0;   // control word wincc
END_VAR

VAR_OUTPUT
    QdwState    {S7_dynamic:='true'; S7_m_c:='true'}: DWORD:=0;     // status wincc
    QabyState AT QdwState : ARRAY [0..3] OF BYTE;                   // look at state byte-wise

    QwState     {S7_dynamic:='true'}: WORD:= 0; //0=close, 1=opening, 2=open, 3=closing
    
    QCLOSE     {S7_dynamic:='true'} : BOOL := FALSE;     // 1=Closed
    QOPENING   {S7_dynamic:='true'} : BOOL := FALSE;     // 1=Opening
    QOPEN      {S7_dynamic:='true'} : BOOL := FALSE;     // 1=Open
    QCLOSING   {S7_dynamic:='true'} : BOOL := FALSE;     // 1=Closing
    
    QCMD_OP    {S7_dynamic:='true'} : BOOL := FALSE;     // 0=Close 1=Open

    QMON        {S7_dynamic:='true'} : BOOL := FALSE;     // 1=Monitoring Feedback
    QMON_ERR    {S7_dynamic:='true'} : BOOL := FALSE;     // 1=Monitoring Error
    QMON_T      {S7_dynamic:='true'; S7_m_c := 'true'} : REAL := 0.0; // Current Monitoring Time Feedback
    
    QMAN_AUT   {S7_dynamic:='true'} : BOOL := FALSE;     // 0=Hand 1=Automatic
    QREMOTE    {S7_dynamic:='true'} : BOOL := FALSE;     // 0=Local 1=Remote
    QSIM       {S7_dynamic:='true'} : BOOL := FALSE;     // 1=Simulaition is active
    QLOCK      {S7_dynamic:='true'} : BOOL := FALSE;     // 1=Lock is active
    QERR       {S7_dynamic:='true'} : BOOL := FALSE;     // 1=ERROR
    QERR_EXT   {S7_dynamic:='true'} : BOOL := FALSE;     // 1=External ERROR

    
    //Alarm
    MSG1_bDone  {S7_visible:='false'} : BOOL; // A8P
    MSG1_bError {S7_visible:='false'} : BOOL; // A8P
    MSG1_wState {S7_visible:='false'} : WORD; // A8P
    MSG1_wAck   {S7_visible:='false'} : WORD; // A8P
    MSG2_bDone  {S7_visible:='false'} : BOOL; // N8P
    MSG2_bError {S7_visible:='false'} : BOOL; // N8P
    MSG2_wState {S7_visible:='false'} : WORD; // N8P
END_VAR

VAR
    OPdwCmdHMI : DWORD := 16#0;                       // Operator Commands in HMI format
    OPabyCmdHMI AT OPdwCmdHMI : ARRAY [0..3] OF BYTE; // look at HMI command byte-wise
    OPdwCmdPLC : DWORD := 16#0;                       // Operator Commands in PLC format
    OPabyCmdPLC AT OPdwCmdPLC : ARRAY [0..3] OF BYTE; // look at plc command byte-wise
    OPabCmdPLC AT OPdwCmdPLC : ARRAY [0..31] OF BOOL; // look at plc command bit-wise
    
    QdwStatePLC : DWORD := 16#0;                        // State word in PLC format
    QabyStatePLC AT QdwStatePLC : ARRAY [0..3] OF BYTE; // look at state byte-wise
    QabStatePLC AT QdwStatePLC : ARRAY [0..31] OF BOOL; // look at state bit-wise
        
  
    A8P   : ALARM_8P;
    N8P   : NOTIFY_8P;
    //---time stamp structure for alarm_t call
    STRUCT_TS : STRUCT     
        wFormat : WORD ; //time format
        aDT : ARRAY [1..8] OF DATE_AND_TIME;         //array date and time
    END_STRUCT ;
    
    // TAGS for Operation´
    OP_RESET : BOOL := FALSE;
    
    // TAGS for Edge detect
    L_RESET_OLD : BOOL := FALSE;
    AUT_OP_OLD : BOOL := FALSE;
    MAN_OP_OLD : BOOL := FALSE;
    QOPENING_OLD : BOOL := FALSE;
    QCLOSING_OLD : BOOL := FALSE;
    
    // TAGS for Simulation
    FB_SIM_OPEN  : BOOL := FALSE;
    FB_SIM_CLOSE : BOOL := TRUE;
    SIM_T    : REAL := 5.0;
    QCMD_SIM : BOOL := FALSE;
    
END_VAR

VAR_TEMP
TOP_SI: STRUCT
      EV_CLASS  : BYTE;
      EV_NUM    : BYTE;
      PRIORITY  : BYTE;
      NUM       : BYTE;
      TYP2_3    : BYTE;
      TYP1      : BYTE;
      ZI1       : WORD;
      ZI2_3     : DWORD;
END_STRUCT;

START_UP_SI: STRUCT
      EV_CLASS  : BYTE;
      EV_NUM    : BYTE;
      PRIORITY  : BYTE;
      NUM       : BYTE;
      TYP2_3    : BYTE;
      TYP1      : BYTE;
      ZI1       : WORD;
      ZI2_3     : DWORD;
END_STRUCT;
iRet          : INT;

END_VAR


BEGIN

// START UP =====================================================================
    iRet := SFC6 (TOP_SI:= TOP_SI, START_UP_SI:= START_UP_SI);
    IF (TOP_SI.NUM = 100 OR TOP_SI.NUM = 101) THEN
        
        OPabCmdPLC[9] := TRUE;  // Disable Feedback Monitoring
        OPabCmdPLC[19] := TRUE; // Activate Remote Control
        
        QCMD_OP   := FALSE;
        QCLOSE    := TRUE;
        QOPENING  := FALSE;
        QOPEN     := FALSE;
        QCLOSING  := FALSE;
        QwState := 0;
        
        iRet := 0;
    END_IF;
// END STARTUP ==================================================================

// Change lowbyte to highbyte for HMI command word ==================
    OPdwCmdHMI := OP_dwCmd;
    OPabyCmdPLC[0] := OPabyCmdHMI[3];
    OPabyCmdPLC[1] := OPabyCmdHMI[2];
    OPabyCmdPLC[2] := OPabyCmdHMI[1];
    OPabyCmdPLC[3] := OPabyCmdHMI[0]; 

// ******************************************************************************
// Begin: Operation functions ***************************************************
    
// MANUAL / AUTOMATIC Operation =======================================
    IF (LIOP_SEL AND NOT L_AUT) OR (OPabCmdPLC[16] AND NOT LIOP_SEL) THEN 
        QMAN_AUT := FALSE;
    ELSIF (LIOP_SEL AND L_AUT) OR (OPabCmdPLC[17] AND NOT LIOP_SEL) THEN 
        QMAN_AUT := TRUE;
    END_IF;
    
// LOCAL / REMOTE Operation =========================================
    IF (LIOP_SEL AND NOT L_REMOTE) OR (OPabCmdPLC[18] AND NOT LIOP_SEL) THEN
        QREMOTE := FALSE;
    ELSIF (LIOP_SEL AND L_REMOTE) OR (OPabCmdPLC[19] AND NOT LIOP_SEL) THEN
        QREMOTE := TRUE;
    END_IF;
    
// SIMULATION ON / OFF ==============================================
    IF (LIOP_SEL AND NOT L_SIM) OR (OPabCmdPLC[20] AND NOT LIOP_SEL) THEN
        QSIM := FALSE;
    ELSIF (LIOP_SEL AND L_SIM) OR (OPabCmdPLC[21] AND NOT LIOP_SEL) THEN
        QSIM := TRUE;
        QCMD_OP := FALSE;
    END_IF;
    
// RESET Operation ==================================================
    IF (LIOP_SEL AND L_RESET AND NOT L_RESET_OLD) OR (OPabCmdPLC[24] AND NOT LIOP_SEL) THEN
        OP_RESET := TRUE;
    ELSE
        OP_RESET := FALSE;
    END_IF;
    
// MONITORING FEEDBACK ON / OFF =====================================
    IF (LIOP_SEL AND L_MON) OR (OPabCmdPLC[8] AND NOT LIOP_SEL) THEN
        QMON := TRUE;
    ELSIF (LIOP_SEL AND NOT L_MON) OR (OPabCmdPLC[9] AND NOT LIOP_SEL) THEN
        QMON := FALSE;
    END_IF;
    
// OPEN / CLOSE Valve (AUTOMATIC)====================================
    IF (QMAN_AUT AND AUT_OP AND NOT AUT_OP_OLD AND NOT QSIM) THEN
        QCMD_OP := TRUE;
    ELSIF (QMAN_AUT AND NOT AUT_OP AND NOT QSIM) THEN
        QCMD_OP := FALSE;
    END_IF;
    
// OPEN / CLOSE Valve (MANUAL)=======================================
    IF (NOT QMAN_AUT AND NOT QREMOTE AND MAN_OP AND NOT MAN_OP_OLD AND NOT QSIM) OR (OPabCmdPLC[1] AND NOT QMAN_AUT AND QREMOTE AND NOT QSIM)  THEN
        QCMD_OP := TRUE;
    ELSIF (NOT QMAN_AUT AND NOT QREMOTE AND NOT MAN_OP AND NOT QSIM) OR (OPabCmdPLC[0] AND NOT QMAN_AUT AND QREMOTE AND NOT QSIM) THEN
        QCMD_OP := FALSE;
    END_IF;

// OPEN / CLOSE Valve (SIMULATION)===================================
    IF (QSIM AND NOT QREMOTE AND SIM_OP) OR (OPabCmdPLC[1] AND QREMOTE AND QSIM) THEN
        QCMD_SIM := TRUE;
    ELSIF (QSIM AND NOT QREMOTE AND NOT SIM_OP) OR (OPabCmdPLC[0] AND QREMOTE AND QSIM) THEN
        QCMD_SIM := FALSE;
    END_IF;
// END: Operation functions *****************************************************
// ******************************************************************************

//=================================
//            QwState
//0 = Close
//1 = Opening
//2 = Open
//3 = Closing
//=================================

//--------------------------
//QwState = 0; CLOSE
//--------------------------
    IF NOT QSIM THEN    // *** Process Mode ***
        IF 
            (NOT QCMD_OP AND QwState=3 AND NOT QMON_ERR AND FB_CLOSE) OR
            (NOT QCMD_OP AND QwState=3 AND NOT QMON)
        THEN
            QCLOSE    := TRUE;
            QOPENING  := FALSE;
            QOPEN     := FALSE;
            QCLOSING  := FALSE;
            QwState := 0;
        END_IF;
    ELSE                // *** Simulation Mode ***
        IF 
            (NOT QCMD_SIM AND QwState=3 AND FB_SIM_CLOSE) OR
            (NOT QCMD_SIM AND QwState=3 AND NOT QMON)
        THEN
            QCLOSE    := TRUE;
            QOPENING  := FALSE;
            QOPEN     := FALSE;
            QCLOSING  := FALSE;
            QwState := 0;
        END_IF;
    END_IF;
        
//--------------------------
//QwState = 1; OPENING
//--------------------------
    IF NOT QSIM THEN    // *** Process Mode ***
        IF (QCMD_OP AND (QwState = 0 OR QwState = 3)) THEN 
            QCLOSE    := FALSE;
            QOPENING  := TRUE;
            QOPEN     := FALSE;
            QCLOSING  := FALSE;
            QwState := 1;
        END_IF;
    ELSE                // *** Simulation Mode ***
        IF (QCMD_SIM AND (QwState = 0 OR QwState = 3)) THEN 
            QCLOSE    := FALSE;
            QOPENING  := TRUE;
            QOPEN     := FALSE;
            QCLOSING  := FALSE;
            QwState := 1;
        END_IF;
    END_IF;
    
    
//--------------------------
//QwState = 2; OPEN
//--------------------------
    IF NOT QSIM THEN        // *** Process Mode ***
        IF 
            (QCMD_OP AND QwState=1 AND NOT QMON_ERR AND FB_OPEN) OR
            (QCMD_OP AND QwState=1 AND NOT QMON)
        THEN
            QCLOSE    := FALSE;
            QOPENING  := FALSE;
            QOPEN     := TRUE;
            QCLOSING  := FALSE;
            QwState := 2;
        END_IF;
    ELSE                    // *** Simulation Mode ***
        IF  
            (QCMD_SIM AND QwState=1 AND FB_SIM_OPEN) OR
            (QCMD_SIM AND QwState=1 AND NOT QMON)
        THEN
            QCLOSE    := FALSE;
            QOPENING  := FALSE;
            QOPEN     := TRUE;
            QCLOSING  := FALSE;
            QwState := 2;
        END_IF;
    END_IF;
        
//--------------------------
//QwState = 3; CLOSING
//--------------------------
    IF NOT QSIM THEN        // *** Process Mode ***
        IF (NOT QCMD_OP AND (QwState = 1 OR QwState = 2)) THEN
            QCLOSE    := FALSE;
            QOPENING  := FALSE;
            QOPEN     := FALSE;
            QCLOSING  := TRUE;
            QwState := 3;
        END_IF;
    ELSE                    // *** Simulation Mode ***
        IF (NOT QCMD_SIM AND (QwState = 1 OR QwState = 2)) THEN
            QCLOSE    := FALSE;
            QOPENING  := FALSE;
            QOPEN     := FALSE;
            QCLOSING  := TRUE;
            QwState := 3;
        END_IF;
    END_IF;
    
// Feedback Monitoring =================================================
    IF QMON THEN
        IF (QOPENING AND NOT QOPENING_OLD) OR (QCLOSING AND NOT QCLOSING_OLD) THEN
            QMON_T := 0.0;
        END_IF;
        
        IF NOT QSIM THEN    // *** Process Mode ****
            IF (QOPENING OR QCLOSING) THEN
                QMON_T := QMON_T + SAMPLE_T;
                IF (QMON_T >= MON_T) THEN
                    QMON_ERR := TRUE;
                END_IF;
            ELSE
                QMON_T := 0.0;
            END_IF;
            IF (QOPEN AND (NOT FB_OPEN OR FB_CLOSE)) OR (QCLOSE AND (FB_OPEN OR NOT FB_CLOSE)) THEN
                QMON_ERR := TRUE;
            END_IF;
        ELSE               // *** Simulation Mode ***
            IF (QOPENING) THEN
                QMON_T := QMON_T + SAMPLE_T;
                FB_SIM_CLOSE := FALSE;
                IF (QMON_T >= SIM_T) THEN
                    FB_SIM_OPEN := TRUE;
                END_IF;
            ELSIF (QCLOSING) THEN
                QMON_T := QMON_T + SAMPLE_T;
                FB_SIM_OPEN := FALSE;
                IF (QMON_T >= SIM_T) THEN
                    FB_SIM_CLOSE := TRUE;
                END_IF;
            ELSE
                QMON_T := 0.0;
            END_IF;
        END_IF;
    END_IF;
// END Monitoring ======================================================
    
// Check Errors ========================================================
    QERR_EXT := ERR_EXTERN;
    IF LOCK AND (QOPENING OR QOPEN) THEN
        QLOCK := TRUE;
    END_IF;
    QERR := QERR_EXT OR QMON_ERR OR QLOCK;
    
// RESET Errors ========================================================
    IF OP_RESET THEN
        QMON_ERR  := FALSE;
        QLOCK     := FALSE;
    END_IF;

// If Error then Stop ==================================================        
    IF QERR THEN
        QCLOSE    := TRUE;
        QOPENING  := FALSE;
        QOPEN     := FALSE;
        QCLOSING  := FALSE;
        QCMD_OP   := FALSE;
        QCMD_SIM  := FALSE;
        QwState   := 0;
        QMON_T    := 0.0;
    END_IF;
   
// Set State for HMI ===================================================
    QabStatePLC[0]  := QCLOSE;      // 1=Close
    QabStatePLC[1]  := QOPENING;    // 1=Opening
    QabStatePLC[2]  := QOPEN;       // 1=Open
    QabStatePLC[3]  := QCLOSING;    // 1=Closing
    QabStatePLC[4]  := 0;
    QabStatePLC[5]  := 0;
    QabStatePLC[6]  := 0;
    QabStatePLC[7]  := 0;   
    QabStatePLC[8]  := QMON;        // 1=Feedback Monitoring ON
    QabStatePLC[9]  := QMON_ERR;    // 1=Error Feedback Monitoring
    QabStatePLC[10] := 0;
    QabStatePLC[11] := 0;  
    QabStatePLC[12] := 0;
    QabStatePLC[13] := 0;
    QabStatePLC[14] := 0;
    QabStatePLC[15] := 0;
    QabStatePLC[16] := QMAN_AUT;    // 0=Manual 1=Automatic
    QabStatePLC[17] := QREMOTE;     // 0=Local 1=Remote
    QabStatePLC[18] := QSIM;        // 0=Process 1=Simulation
    QabStatePLC[19] := 0;
    QabStatePLC[20] := 0;
    QabStatePLC[21] := 0;
    QabStatePLC[22] := 0;
    QabStatePLC[23] := 0;
    QabStatePLC[24] := QERR;        // 1=Error
    QabStatePLC[25] := QERR_EXT;    // 1=External Error
    QabStatePLC[26] := QLOCK;       // 1=Block Locked
    QabStatePLC[27] := LOCK;        // 1=INTERLOCK
    QabStatePLC[28] := 0;  
    QabStatePLC[29] := 0;  
    QabStatePLC[30] := 0;
    QabStatePLC[31] := 0;
    
    QabyState[0] :=QabyStatePLC[3];
    QabyState[1] :=QabyStatePLC[2];
    QabyState[2] :=QabyStatePLC[1];
    QabyState[3] :=QabyStatePLC[0];
    
// Alarm_8P ==============================================
    A8P(            
        EN_R := 1,
        SIG_1 :=QMON_ERR,   // Monitoring Error
        SIG_2 :=0,
        SIG_3 :=0,
        SIG_4 :=0,
        SIG_5 :=QLOCK,      // Interlock Error
        SIG_6 :=0,
        SIG_7 :=QERR_EXT,   // External Error
        SIG_8 :=QERR,       // General Error
        ID := w#16#eeee,
        EV_ID := MSG1_EVID,
        SEVERITY := w#16#40
    );
    MSG1_bDone := A8P.DONE;
    MSG1_bError := A8P.ERROR;
    MSG1_wState := A8P.STATUS;
    MSG1_wAck := A8P.ACK_STATE;

// Notify_8P ==============================================
    N8P(            // NOTIFY AP
        SIG_1 :=QCLOSE,     // CLOSE
        SIG_2 :=QOPENING,   // OPENING
        SIG_3 :=QOPEN,      // OPEN
        SIG_4 :=QCLOSING,   // CLOSING
        SIG_5 :=LOCK,       // Interlock
        SIG_6 :=QREMOTE,    // Remote
        SIG_7 :=QMAN_AUT,   // Automatic
        SIG_8 :=QSIM,       // Simulation
        ID := w#16#eeee,
        EV_ID := MSG2_EVID,
        SEVERITY := w#16#40 
    );
    MSG2_bDone := N8P.DONE;
    MSG2_bError := N8P.ERROR;
    MSG2_wState := N8P.STATUS;
    
    // Set Tags for edge detect =====================================
    L_RESET_OLD := L_RESET;
    AUT_OP_OLD := AUT_OP;
    MAN_OP_OLD := MAN_OP;
    QOPENING_OLD := QOPENING;
    QCLOSING_OLD := QCLOSING;
    
    //reset commands ================================================
    OP_dwCmd := 16#0;
END_FUNCTION_BLOCK
```


----------



## UniMog (6 April 2015)

Wunderschön.... jetzt hab ich auch mal einen Baustein von BADBIT..... Wenn du mal einen hast wo BATMAN steht... der ist von mir ;-) das war der Comedy Blog 



Draco Malfoy schrieb:


> Was zum Geier soll daran Quatsch sein ? Daß man Prozessautomation auch ohne APL aufbauen kann ? Und wie das geht!
> 
> ```
> FUNCTION_BLOCK BST_VALVE_400
> ...





Draco Malfoy schrieb:


> da gelten nämlich auch andere Standards. In der Prozessautomation werden alle Bausteine in SCL geschrieben, Verschaltung erfolgt im CFC / SFC und eigentlich benutzt man dafür auch die APL zusammen mit WinCC und PCS 7.



Das hier habe ich gemeint ...... Wo stehen denn die Standards ???? Oder sollte ich in den letzten 25 Jahren was verpasst haben ????? In Verbindung mit PCS7 bin ich ja noch einer Meinung mit Dir aber was ist mit den 90% Prozessautomation von
kleinen und mittleren Anlagen ??? Wo steht geschrieben das es in SCL, CFC geschrieben werden muß ????? Könnte ich mal eine Kopie der "Standards" haben !!!!! Danke


----------



## Draco Malfoy (6 April 2015)

> Wo stehen denn die Standards ???? Oder sollte ich in den letzten 25  Jahren was verpasst haben ????? In Verbindung mit PCS7 bin ich ja noch  einer Meinung mit Dir aber was ist mit den 90% Prozessautomation von
> kleinen und mittleren Anlagen ??? Wo steht geschrieben das es in SCL,  CFC geschrieben werden muß ????? Könnte ich mal eine Kopie der  "Standards" haben !!!!! Danke


Es wird so empfohlen. Der Aufbau einer Prozessautomation-Anlage, sagen wir mal, eines Abwasserwerk, beginnt mit dem Verfahrensfließbild und geht weiter mit einem Messstellen- und Instrumentenfließbild. Dort werden sämtliche Anlagenbestandteile bzw. Betriebsmittel wie Stellventile, Reaktoren, Rührwerke etc. mit einem ziemlich kryptischen Zeichen-Buchstabensalat der EMSR-Technik nach EN 62424 -DIN 19227 (Beispielsweise wäre "FFIC" ein Durchfluß-Verhältnis-messinstrument mit Anzeige und selbtstätiger Regelung) und laufender Nummer versehen und erfasst. 

Weiter habe ich die Möglichkeit, entweder irgendwie völlig unstrukturiert vorzugehen, oder - den Empfehlungen von Siemens folgend - im CFC Plan meine Anlage quasi 1:1 nachzuzeichnen, indem ich den Betriebsmitteln entsprechende Bausteine zuordne und deren Instanzen mit meinen Codes nach EN 62424 (DIN 19277) benenne. Die kann ich dann sinnvoll verschalten und erhalte so ein übersichtliches Bild dessen, was in der Anlage passiert.

So, ganz grob und vereinfacht geschildert, läuft die Projektierung einer kleinen Prozessanlage.

Wenn ich jetzt also einen FV 9 Stellventil als Einlauf an einem Reaktor habe, dann gibt es im CFC Plan dazu einen entsprechenden Baustein "VALVE", dessen Instanz den Namen "FV 9" trägt, wobei mein CFC Plan den Namen der Teilanlage (bsplsw. "Reaktor-Vorkessel") trägt, und in der technischen Hierarchie an der entsprechenden Stelle abgelegt wird. Wenn jetzt also mein FV 9 ein ein Problem hat, dann wird die Fehlermeldung: "Reaktor-Vorkessel / FV 9 / Text der Fehlermeldung" automatisch erzeugt.

So kenne ich das nur, und erachte das als die sinnvollste Variante eine Prozessanlage aufzubauen. Alles andere ist m.E. Murks.


----------



## de vliegende hollander (6 April 2015)

Hallo Draco,

Bei PCS7 kenn ich der APL Bibliothek nur von der PCS7 Kurs.
Ich kenn aber kein einziges Projekt bei uns (Turbinenleittechnik) was mit der APL umgesetzt ist. In der Regel Kundenbibliothek oder eigene Bibliothek.
Ich kenn auch keine Anlage die rein nur mit PCS7 gemacht ist. Mann hat immer mischbetrieb.

Sonnst ist bei uns in der Anlagen FUP und AWL gang und geben und sehr seltsam die SCL. Auch im Wasserdampfkreis und sauber nach KKS (oder Kunden Tagsystem) ausgearbeitet.


Bram


----------



## Draco Malfoy (6 April 2015)

> Ich kenn aber kein einziges Projekt bei uns (Turbinenleittechnik) was  mit der APL umgesetzt ist. In der Regel Kundenbibliothek oder eigene  Bibliothek.



Wie gesagt, ich habe ja oben geschrieben, daß dem Kunden die Auswahl offen steht, entweder die APL (die halt von dem Resourcenverbrauch schon ziemlich fett und hässlich ist, möchte ich meinen) anzuwenden, oder eben eine proprietäre Bibliothek zu entwickeln. Ich würde auch nur in äußersten Fällen zu der APL greifen, weil man einige Funktionen davon in der Regel nicht braucht, oder im Gegenteil, man braucht was komplett eigenes.

Grundsätzlich gibt es aber Empfehlungen von Siemens, wie prozesstechnische Anlagen aufgebaut werden sollen, und es gibt auch den PCS7 Standard, den Siemens definiert hat. Es steht natürlich jedem offen, sich daran zu halten, oder es nicht zu tun.


----------



## MSB (6 April 2015)

Ich wusste doch gleich,  das TIA für Prozesstechnik vollkommen ungeeignet ist...  so ohne CFC kann das ja nichts werden. 

Langsam wirds echt affig...


----------



## Draco Malfoy (6 April 2015)

MSB schrieb:


> Ich wusste doch gleich,  das TIA für Prozesstechnik vollkommen ungeeignet ist...  so ohne CFC kann das ja nichts werden.
> Langsam wirds echt affig...


Affig ? Soso, sachkundige Meinung also. Dann mach mir mal *das hier* ohne CFC und ohne Faceplates und ohne automatische Bildergenerierung !!
P.S: ... und davon dann noch 40 Seiten oder so !!


----------



## UniMog (6 April 2015)

Draco Malfoy schrieb:


> Affig ? Soso, sachkundige Meinung also. Dann mach mir mal *das hier* ohne CFC und ohne Faceplates und ohne automatische Bildergenerierung !!
> P.S: ... und davon dann noch 40 Seiten oder so !!
> Anhang anzeigen 28131



Genau das mache ich Dir ohne CFC und ohne automatische Bildergenerierung .... auch 80 Seiten wenn es einer bezahlt....... Das ist mein Job..... wo soll hier ein Problem sein ????


----------



## de vliegende hollander (6 April 2015)

UniMog schrieb:


> Genau das mache ich Dir ohne CFC und ohne automatische Bildergenerierung .... auch 80 Seiten wenn es einer bezahlt....... Das ist mein Job..... wo soll hier ein Problem sein ????



*ACK*


Auch mein tagtägliches Brot.. und sogar in TIA

Bram


----------



## MSB (6 April 2015)

Draco Malfoy schrieb:


> Affig ? Soso, sachkundige Meinung also. Dann mach mir mal *das hier* ohne CFC und ohne Faceplates und ohne automatische Bildergenerierung !!
> P.S: ... und davon dann noch 40 Seiten oder so !!
> Anhang anzeigen 28131



Interessiert mich doch gar nicht, du verwechselst hier nur gerade ein paar Sachen.
Eine große Menge Prozesstechnikanlagen hat noch nie auch nur eine einzige Zeile SCL gesehen, geschweige denn CFC noch halb bis vollautomatische Bildgenerierung.
Und die Anlagen laufen seit Jahrzehnten ganz wunderbar.

Und auch dein Bildchen, wenn man mal von ein paar Details absieht fällt wahrscheinlich auf 1-2 Schrittketten die auf ein paar Regler/Ventile wirken zusammen.
Der Rest sind ein paar Dinger die dynamisch Werte anzeigen oder dynamisch ihre Farbe wechseln, kein Grund gleich die große Keule auszupacken.
Natürlich kann man das ganze auch bis ins kleinste Detail struckturieren und paramtrierbar machen ... ganz wie man will.


----------



## Draco Malfoy (6 April 2015)

> Genau das mache ich Dir ohne CFC und ohne automatische Bildergenerierung  .... auch 80 Seiten wenn es einer bezahlt....... Das ist mein Job.....  wo soll hier ein Problem sein ????


Es gibt kein Problem. Du kannst das machen wie du möchtest, aber - meiner Meinung nach - wird dies weder besonders übersichtlich noch entspricht es den Empfehlungen des Herstellers. Es ist mir im Übrigen auch egal wie ihr eure Anlagen programmiert und was ihr dem Kunden verkauft, aber ich habe es nicht so gelernt. 

Von der COMOS Software in der Anlagenplanung wollt ihr bestimmt auch nichts wissen, nehme ich mal an.

Ich sehe da keinen Sinn in dieser Diskussion weiter. Klar, kann man kleine Anlagen aufbauen wie man möchte, und APL sollte man sich vielleicht für ganz schwere Fälle aufheben, gerade angesichts der Lizenzkosten, aber ab einer bestimmten Anlagengröße wird das alles unumgänglich, auch mit technischer Hierarchie, Messtellen, Ablaufplänen, COMOS und auch APL. Mit einem CFC Plan kann auch ein Verfahrenstechniker was anfangen, während in FUP und AWL erstellte STEP 7 Projekte für die nicht so leicht zugänglich sind. 



> ganz wie man will.


Genau so.


----------



## norustnotrust (6 April 2015)

@Draco: ich verstehe manchmal echt nicht wieso du so schnell die Nerven wegwirfst. Dein Sendungsbedürfnis finde ich ja normalerweise eher unterhaltsam aber mir mein Tapatalk völlig OT mit Bausteincode vollzuspammen finde ich daneben.
Es gibt eine ganz große Welt da draussen und ganz viele von uns machen ihre Arbeit auf ihre Art und Weise gut, auch wenn sie nicht von SIEMENS zertifiziert ist.


----------



## UniMog (6 April 2015)

@Draco: Wie lange machst du den Job schon ???? Auch schon mal die Firma gewechselt oder noch bei der Firma wo Du gelernt hast ????

Gruss


----------



## Draco Malfoy (7 April 2015)

norustnotrust schrieb:


> aber mir mein Tapatalk völlig OT mit Bausteincode vollzuspammen finde ich daneben


Sorry, hier im Browser wird das unter Spoiler angeizeigt und stört so eigentlich niemand.


> Dein Sendungsbedürfnis finde ich ja normalerweise eher  unterhaltsam


Sendungsbedürfnis - meinst Du im Sinne von Missionierungswahn ? Den habe ich nicht. Ich wollte nur meine Sicht der Dinge mitteilen. Wenn derjenige, der sich über "veraltete Standards" aufregt, der Meinung ist, daß wiederkehrende Routinen in Standard-Bausteine verpackt werden müssen, dann mag er ja Recht haben, aber die Bedürfnisse in der Fertigungsautomation und in der Prozessautomation sollten trotzdem nicht über einen Haufen geworfen werden, weil es sind gänzlich verschiedene Dinge, unabhängig davon, ob ich das nach dem PCS7 Standard in SCL schreibe und APL-tauglich mache, oder in FUP in einer CPU 315 ablaufen lasse.


----------



## mariob (7 April 2015)

Hi,
auch ich habe seit Jahresanfang einen neuen Job, bis jetzt macht es einen sehr guten vom Umfeld, die Arbeitsaufgabe beschäftigt sich auch mit sagen wir mal älterer Software. Dummerweise ist das ganze aber Kleinserienfertigung. Infolge des Zeitdruckes ist da so manches halt so wie es ist. Und damit nicht unbedingt schön.
Es ist aber wichtig sich auch mit diesen alten, teilweise verkorksten Sachen zu beschäftigen da man im Falle einer Frage auch eine hoffentlich problemlösende Antwort geben kann. So kommt man erst einmal hinter die bisherigen Prinzipien und kann Stück für Stück neue Module in das bestehende System einbringen ohne das man die gesamte Technik neu erfinden muß. Aber auch das ist kein Grund alles infrage zu stellen.

Gruß
Mario


----------

