Codegenerierung in der Praxis

Alles andere führt sofort zu einem kompletten Chaos.

Ich sehe es nicht ganz so negativ.
Egal ob nun Sonder- oder Serienmaschine ... du hast immer viel Routineaufgaben.
Wir nutzten z.B. einen Aktorbaustein zur Ansteuerung von Aktoren, Laufzeitüberwachung, Verriegelungen und Freigaben.
Hier wäre ein automatisches Erstellen der Variablen und der Grundparametrierung durch einen Codegenerator durchaus sinnvoll und würde auch erheblich Arbeit sparen.

Ich wollt sowas schon mal umsetzen, aber bisher hat mich die TIA-Versionshölle abgeschreckt
 
Zuviel Werbung?
-> Hier kostenlos registrieren
.. Ich wollt sowas schon mal umsetzen, aber bisher hat mich die TIA-Versionshölle abgeschreckt
Das ist im TIA-Portal gar nicht so schlimm. Man muss nicht alles importieren. Ein bisschen Code oder Meldetexte hat man auch schnell mal aus generierten Textdateien kopiert. Das war in Classic sehr viel schlechter möglich, vor allem wenn man spaltenweise kopieren wollte.


Was das Generieren im Allgemeinen angeht, so gibt es ja grundlegend verschiedene Ansichten und Möglichkeiten, wie die Beiträge hier auch zeigen. Man kann auch Schaltpläne aus irgendwelchen Listen generieren und aus diesen wiederum hinterlegten Programmcode für die Steuerung erzeugen. Im Prinzip hört sich das alles sehr verlockend an. Gesehen habe ich so etwas bisher nur auf Messen. In der Praxis bedarf so etwas sehr viel Disziplin und Vorarbeit. Zudem muss das ganze Team mitziehen und sich streng an Regeln einhalten. Ich weiß nicht wie es euch geht, in meinem Umfeld ist das absolut nicht denkbar.

Ich glaube, man sollte es als kleiner "Allrounder" mit dem Generieren auch nicht zu weit treiben. Einfach die Routineaufgaben damit erschlagen und man hat im Handumdrehen ein perfektes Grundgerüst für sein Programm. Das projektspezifische Programmieren kann ein Generator so wie so nicht übernehmen. Je allgemeingültiger der generierte Code ist, um so flexibler kann man den Generator einsetzen. Ich mache es seit vielen Jahren so, dass ich in Excel die Symbolik der Eingänge und Ausgänge erstelle. Jedes Symbol besteht aus drei Teilen (z.Bsp. Anlage, Ort, BMK). Zu jeden dieser drei Teile gibt es einen Kurztext und einen Langtext, nebeneinander in Spalten angeordnet. In einer weiteren Tabelle setze ich aus diesen drei Teilen meine E/As zusammen. Aus den Kurztexten entsteht per Auswahl das Symbol, aus den Langtexten automatisch der Kommentar. Somit hat man schon mal eine fehlerfreie und einheitliche Syntax, egal wie groß das Projekt auch wird. Auf Knopdruck werden aus diesen Daten eine Hand voll Textdateien erzeugt. Einmal für die Symbolik, für die Analogwerte, für Störungsmeldungen, jeweils mit FBs, DBs und UDTs, alles einheitlich und fehlerfrei kommentiert. Dann noch eine Datenbasis für mein persönliches System und natürlich eine Liste mit den Störmeldetexten. Für jeden dig. Eingang wird eine Störmeldung vorgesehen, für analoge Signale jeweils vier. Die Bausteine für die Analogwerte und für die Störmeldungen werden anschließend händisch überarbeitet. Ich hatte auch schon die Normierung der Analogwerte und die verschiedenen Auswertungen für Störungen generierbar gemacht. Aber selbst das war meistens schon zu spezifisch und musste spätestens zur IBN so wie so noch einmal überarbeitet werden. Ein sauberes Grundgerüst mit Kommentaren, vollständig und fehlerfrei ist hingegen schon eine sehr zuverlässige Grundlage.

Für die Classic-Welt haben alle diese Text-Dateien das entsprechende Format zum Importieren. Für TIA handhabe ich es so, dass ich aus den Textdateien oder aus Excel den Code, die Symbole oder die Meldetexte kopiere. Nach dem ich alles übernommen habe, ist das Generieren beendet. D.h., die Quellen sind ab diesen Zeitpunkt hinfällig.


 
tja, sehr viel interessante Dinge. Zwei Sachen noch von mir.
Wenn man eine ordentlich Strukturierte Programmierweise in der SPS hat, ist das die Grundvoraussetzung für ne Codegenerierung. Aber genau dann ist die "händische" Programmerstellung auch nicht so irre langwierig bzw. fehleranfällig. Vor allem wenn man aus ähnlichen Anlagen kopiert und bestimmte Dinge/Texte aus der Excel oder Eplan kopiert.

Zweites hab ich die Erfahrung gemacht, dass dann eher minder erfahrene und bezahlte SPS Programmierer eingestellt werden, wenn doch so ein toller Codegenerator vorhanden ist. Wie Draco schon schreibt, geht dann mal schnell alles den Bach runter, wenn man nicht aufpasst...
 
Aus aktuellem Anlass habe ich mir das Osterwochende gegönnt um mir Openness mal wieder anzuschauen.

Vorweg:
Einen Codegenerator auf Excel-Basis entwickle, pflege und nutze ich seit fast 8 Jahren. (95% Fördertechnik)
Generiert werden Projektspezifische Symbole, UDT, DB, und Bausteine in KOP (AWL-Quelle) und SCL.
Das größte Manko seit TIA ist, dass die Generierung von KOP oder gar FUP (falls Kundenwunsch) per Quelle nicht mehr "einfach" möglich ist.
Grade die Logik-Bausteine und unsere Aufrufstrukturen sollen nach Möglichkeit in KOP erstellt werden.

Am Wochenende habe ich mir also, die Export/Import per Openness angeschaut, nicht für die gesamte SW, sondern hauptsächlich für die ca 30 verschiedenen Förderer-FB (im aktuellen Projekt) und die ca 90 (* 24 Anlagen) Verwendungsstellen.
Beispielaufrufe erstellt und exportiert, anschließend Try&Error bei den Imports.

Ergebnis:
Mit minimalen Aufwand lassen sich brauchbare Templates erstellen, aus dehnen wiederum wieder importierbare XML-Quellen entstehen...
Falls sich jemand hiermit noch nicht beschäftigt hat, folgende Tipps:
  • Alle Tags mit ReadOnly="true" und Informative="true" können direkt gelöscht werden
  • Selbiges gilt für die kompletten <sections>-Bereiche im Deklarationsbereich der Instanzierten FB oder UDT
  • Eigene Kennungen und Identifikatoren in den Variablen/Parametern durch Platzhalter ersetzt.
  • Die UID sind nur Netzwerk-weise Unique, können also belassen werden
  • Die ID ist muss im kompletten XML Unique sein und kann von Anfang bis Ende hochgezählt werden (Hexa-Formatierung beachten)
  • Wer will kann den Openness Scripter zum Export und Import nutzen am Anfang reicht der allemal


Bei der Hardware CAxx Import sind ist mir noch 2 Makel aufgefallen:
  • Die Position zuvor Exportierter Komponenten wird beim Import wahllos bestimmt, auch bei bereits vorhandenen, zu überschreibender Komponenten (Super bei bereits fertigen Topologie-Strukturen :rolleyes:)
  • Ich habe keine Möglichkeit gefunden die Busadresse zu übergeben, im Gegensatz zu bestimmbaren Adressbereiche, IP und DNS-Namen, wird diese bei mir beim Import vom Portal neu vergeben... Da die Bus-ID Teil unserer E-Doku und auch Fehlertexte ist, heißt das an allen Teilnehmern immer wieder neu zuordnen :sb7:

Vielleicht kennt ja jemand nen Workarround o.a., da ich mich hiermit nur sehr kurz beschäftigt habe, habe ich bestimmt was übersehen.


Gruß Semo
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
Servus,

ich bin aktuell bei einem Kunden an einem größeren Projekt dran.

Dabei wird aus Eplan ein XML exportiert und daraus über Powershell die Applikation komplett generiert. Das Ganze
zieht einen größeren Kreis da die gesamte Applikation zusätzlich über einen Jenkins Server automatisiert getestet wird.
Continous Delivery, Digitaler Zwilling usw. ist da ganz stark Fokus.

Ziel ist es das der Endkunde seine Maschine konfigurieren kann, die Elektrokonstruktion den Schaltplan erstellt (was
auch schon teilweise automatisiert passiert) und dann der Quellcode inklusive Simulationsumgebung erstellt wird.
Die Maschine sozusagen schon im Büro "getestet" werden kann.

Dafür hab ich mir ein kleines Framework ausgedacht das es ermöglicht Maschinenmodule unabhängig voneinander
zu erstellen. Die Basis ist streng objektorientiert und die Bausteine haben keine direkte Verbindung zueinander.
Dadurch können diese recht einfach per Skript eingebunden werden.

Nachträglich können Bausteine ebenso noch angepaßt werden, bzw können trotzdem schnell Sonderwünsche
für Kunden einfließen.

Die Visualisierung bekommt die gleiche XML Datei und kann sich entsprechend die Infos zur Maschine auslesen
und sich anpassen.

Allerdings arbeite ich nicht mit TIA Portal sondern mit Beckhoff (Twincat3) und Sigmatek (Lasal2) Steuerungen.
Da dort die Objektorientierte Entwicklung recht gut umgesetzt ist.
 
Hallo zusammen,

der letzte Eintrag ist schon eine her...ich versuch das mal wieder aufzugreifen.
Ich habe mich auch bei meinem letzten Arbeitgeber der Entwicklung eines Softwarestandards und darauf aufgesetzt einem Codegenerator für die SPS über TIA.Openess gewidmet.

Leider, wie ich hier auch schon gelesen habe wurde das Projekt als zu pflege-intensiv eingestuft und eingestampft. Das aber momentan ein E-Konstrukteur / Sofwareler mind. 3 Wochen pro Anlage für Vorbereitungen und "abtippselarbeit" vergeudet und dieser Aufwand auf wenige Stunden hätte reduziert werden können wollte keiner einsehen.

Die Projekt-Durchlaufzeit und die Qualität von Schaltplan und Software wäre sicherlich deutlich besser geworden...

Wir hatten dort das E-CAD ELTime im Einsatz. Sehr rudimentär im vergleich zu EPlan, aber immerhin mit einem Schaltplangenerator ausgestattet den ich auch noch gleich angebunden habe.

Somit konnte ich aus einer Excel-Datei (Export aus der mech. Konstruktion) Schaltplan und SPS Software auf Knopfdruck erzeugen. Also durchaus sinnvoll, aber leider verkannt. Auch bei Kollegen hatte ich teilweise den Ruf ihre Arbeitsplätze wegrationalisieren zu wollen :)

Ich habe mein Tool in das von Siemens zur Verfügung gestellte TIA Openess Demo integriert. Wen's interessiert, aus Youtube gibt's ein Bildschirmvideo von einer frühen, etwas rudimentären Version:

https://www.youtube.com/watch?v=f43TARWnrlk

Wer ist denn aktuell auch an solchen Themen dran?
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hi,

ja die Angst Arbeitsplätze wegzurationalisieren kenn ich. Das haben komischerweise sehr viele, da die neue Arbeitsweise
sich niemand vorstellen kann. Ich hab jetzt für Beckhoff und Sigmatek jeweils eine Bibliothek die die Grundlage bildet
um eine Applikation generieren zu können.

Die Applikation selbst muss natürlich auch dazu passen... das Ganze macht nur bei sehr modularen Anlagen Sinn die
entsprechend kundenspezifisch immer anders ausgeliefert werden.

Beim letzten Kunden war das schon ein ziemlicher Kampf die Vorteile darzustellen... und alle haben das immer noch
nicht erkannt, leider.
 
ja die Angst Arbeitsplätze wegzurationalisieren kenn ich. Das haben komischerweise sehr viele, da die neue Arbeitsweise sich niemand vorstellen kann.
Wohl dem, der dann für die zehn Wegrationalisierten arbeiten muss, weil die Anlagen ja in NullKommaNix zu projektieren sind! :ROFLMAO:
Irgendwie war ich eigentlich hin und wieder froh, wenn mal Routinearbeiten anfielen, weil ich dann Zeit hatte, mich gedanklich mit dem jeweiligen Projekt anzufreunden. Schliesslich macht es keinen guten Eindruck, wenn man nur da sitzt, Löcher in die Luft guckt und auf dem Bleistift kaut - da ist es schon nicht schlecht, wenn man solche Phasen durch eifriges Tippen kaschieren kann!!!
 
Beim letzten Kunden war das schon ein ziemlicher Kampf die Vorteile darzustellen... und alle haben das immer noch
nicht erkannt, leider.

Vielleicht liegts auch daran, dass der Codegenerator auch einige Nachteile hat. Die Wichtung der Vorteile / Nachteile ist natürlich immer Ansichtssache.

Bei ner Industrieanlage auch interessant, wer kennt sich nach 10 Jahren, bzw. von den Instandhaltern denn mit der "neuen" Programmierweise aus?

Gruß.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Bei ner Industrieanlage auch interessant, wer kennt sich nach 10 Jahren, bzw. von den Instandhaltern denn mit der "neuen" Programmierweise aus?
Meinst Du mit 'der "neuen" Programmierweise' etwa die Benutzung eines CodeGenerators? Warum sollte ausgerechnet ein Instandhalter (nach 10 Jahren) merken bzw. darunter leiden, ob/wenn ein CodeGenerator die Basis geliefert hat, die dann ggfs noch manuell überarbeitet wurde?
Wenn das Programm nicht lesbar ist, dann hat man es anscheinend nicht geschafft, dem CodeGenerator brauchbare Eigenschaften in die Wiege zu legen.
Oder der Aufwand an manueller Überarbeitung ist zu umfangreich bzw. wird immer umfangreicher, z.B. bedingt durch ständig neue Upgrades, Downgrades, Updates, Releases und die Rücksichtnahme auf diverse KompatibilitätsProbleme.
In diesem Sinne: unser täglich Update gib uns heute!

Gruss, Heinileini
 
Mal ein Feedback aus der Praxis.

Mittlerer süddeutscher Maschinenbauer, etwa an die 200 Mitarbeiter. Gibt ja viele von. Setzt seit Kurzem solche "Features" wie IO-Link, busfähige Ventile, verschiedentliche Antriebstechnik von verschiedenen Herstellern ein, und so weiter.

Eine mittlere Anlage des mittleren süddeutschen Maschinenbauers: 40-50 Achsen, an die 120 Hydraulikventile, ein Bisschen Sonderhardware im Feld.

Programmierung: Wüster Haufen verschiener FCs, in denen serielle Kommunikation, zyklische Kommunikation, azyklische Kommunikation, Schaltpunkte die da gebildet werden, Positionsvorgaben und Schwellen, jeweils EINZELN HÄNDISCH IN KOP mit Einschlüssen von AWL unter Zugriff auf globale Variablen programmiert sind.

Heißt, ein FC hat so 150-250 Netzwerke, wo dann die komplette Parametrierung eines Ventils über azyklische Schnittstelle stattfindet. Lustig ? Nein. Von den Ventilen gibts einige dutzend, also auch von den FCs so viele, und alle 150 Netztwerke sind vermutlich jeweils händisch getippt und editiert worden. Mit der Schnittstelle zur VISU, versteht sich.

Ich frage mich: Wer bezahlt sowas ? Sind die Ingenieure, die sowas veranstalten, völlig bescheuert ? Brauchts denn hier einen Codegenerator oder eher einfach mal ne Schulklasse zum Thema "Umgang mit Librarys" ?
 
Zuletzt bearbeitet:
@Draco

"Moderne" Programmierung ist nicht immer von Vorteil.
Wir haben auch einen Maschinenlieferanten:
Fast alles in Kop, keine parametrierten FBs, Symbolik = BMK + Kommentar.
Programm im S5-Stil.
Also im Prinzip alles das, was man bei einer Maschine heute nicht erwarten würde.
Aber:
Die eigenen Inbetriebnehmer kommen damit zurecht, unsere Instandhaltung ist absolut zufrieden damit und der Preis liegt auf Wettbewerber-Niveau (trotz Made in Germany)
Die Firma hat einen Standard, der über die letzten Jahrzehnte nur ganz moderat angepasst wurde.
Für langjährige Mitarbeiter (und davon haben sie viele) und Kunden im Prinzip ein riesen Vorteil.
Meine Fazit daraus:
Man darf die SPS und Visu nicht losgelöst betrachten sondern im Gesamtumfeld.

Gruß
Blockmove
 
Zuviel Werbung?
-> Hier kostenlos registrieren
@Draco: Da kenn ich auch was von.
Sollte eine relativ einfache Anlage zum Verschweißen von Kunststoffteilen von 0 an programmieren. Etwas was ich eigentlich nicht gerne mache, denn ich habe bis heute, trotz mehrjähriger Programmiererfahrung, keinen Plan wie man an sowas strukturiert herangeht von der Planung über die Durchführung. Ich fühle mich bei Firmen am wohlsten, wo es klare Strukturen und Vorgaben gibt an denen ich mich orientieren kann.
Außer eine Beschreibung wie die Anlage funktioniert und welche Bedienelemente es gibt gab es keine Vorgaben was die Sprache und andere Dinge angeht. Da ich meist in ST programmiert hatte nutzte ich diese Sprache und lieferte nach ein paar Tagen das Programm ab. Beim Anblick des ST Codes wurde mein Ansprechpartner etwas blass und meinte, dass er vielleicht noch einigermaßen mein Programm verstehen würde, der Monteur aber nur grafische Sprachen versteht. Da noch reichlich Zeit war stellte ich alles auf FUP um, um dann zu erfahren das bei grafisch eher an KOP gedacht wurde, autsch.
OK, wenn auch relativ schwer, aber das konnte ich noch halbwegs verstehen. Was dann folgte aber weit weniger. In der Anlage kamen zwei identische Baugruppen zum Einsatz, daher habe ich einen FB genutzt und den Instanzen jeweils die benötigten Eingänge übergeben und die Ausgänge der Hardware zugewiesen. Beim Blick auf mein Programm stellte man mir dann die Frage, wo denn der Code für die zweite Baugruppe sei. Meine Erklärung, dass es für beide nur ein Programm gebe und dann Instanzen angelegt werden, denen die Daten dann übergeben werden, sorgte für verständnislose Blicke. Man wollte alle Baugruppen direkt im Code sehen. Ich habe also alle FBs kopiert und in diesen dann die I/Os direkt genutzt. Richtig schön war dann die Fehlerkorrektur, weil ich dann nicht an einer Stelle Änderungen machen musste, sondern an vielen und prompt auch was übersehen hatte.
Dann habe ich mal deren anderen Programme gesehen. Das praktisch alles in KOP war hatte ich ja erwartet, aber ansonsten praktisch nur PRGs und alles über globale Variablen abgewickelt.

Von irgendwas mit Internetzugang gesendet.
 
Zuletzt bearbeitet:
@Oliver
FBs mit ellenlangen Parameterlisten sind jedem Instandhalter ein Graus.
Die Forderung nach direktem Verschalten der EAs kann ich verstehen.
Natürlich steigt der Aufwand für Programmierer erheblich.

Ähnliches gilt für komplette Programme in ST.
Nach einigen negativen Erfahrungen mit Anlagen, haben wir nun auch Programme komplett in ST verboten.
Man kann in ST / SCL verständlich programmieren, aber es erfordert viel Disziplin.
In SCL hab ich schon mehr Murks als in AWL gesehen. Ganz besonders von SPS-Quereinsteigern mit IT-Hintergrund.


Deshalb fordern wir auch Schrittketten in Graph.
Der Instandhalter hat nur noch eine Art von Ketten und muß nicht erst analysieren wie die Kette funktioniert bevor er den eigentlichen Fehler suchen kann.

Letztlich gilt:
Wir schreiben die Programme nicht für uns.

Gruß
Blockmove
 
@Draco

Die eigenen Inbetriebnehmer kommen damit zurecht, unsere Instandhaltung ist absolut zufrieden damit und der Preis liegt auf Wettbewerber-Niveau (trotz Made in Germany)
Die Firma hat einen Standard, der über die letzten Jahrzehnte nur ganz moderat angepasst wurde.
Für langjährige Mitarbeiter (und davon haben sie viele) und Kunden im Prinzip ein riesen Vorteil.

Lieber Blockmove

vielen Dank für deine höflichen Schlichtungsversuche (Ich stelle mir Blockmove immer mit so einer großen Feile vor, der herumgeht und scharfe Kanten zu glätten versucht. Macht er wahrscheinlich bei sich im Betrieb auch.). In dem konkreten Fall zerstört es aber eine sachorientierte Diskussion.

Code:
Meine Fazit daraus:
Man darf die SPS und Visu nicht losgelöst betrachten sondern im Gesamtumfeld.

Ich rede jetzt ausschließlich vom Gesamtumfeld. Meine Einwände wenden sich nicht gegen eine Kleinstanlage auf einer 315er CPU, die einen Scherenubtisch steuert, von der Firma Heinz & Kunz als Sublieferant vom Sublieferant geliefert. Was und wie auf solchen CPUs programmiert wird, ist mir völlig schnuppe.

Ich rede jetzt von wirklichen Industrieanlagen. 30 bis 40 hydraulische Proportionalventile aus FCs in KOP einzeln verdrahtet anzusteuern, ist ein wirtschaftlicher Schaden für die Firma und ein Armutszeugnis für die Qualitätssicherung in der Ekonstruktions-Abteilung. Ganz abgesehen davon, daß die Anlage damit nicht als Vorlage für spätere Projekte dienen kann, weder flexibel erweiterbar noch irgendwie wartbar durchschaubar oder modifizierbar ist. Diese Hunderte von Netzwerken müssen nämlich von irgendwelchen zu bessern Tippsen degradierten Heinys händisch angelegt und korrigiert werden. Die Stundenvolumina gehen da in die Hunderte, wenn nicht Tausende, alleine schon in der Projektierungsphase. Und was passiert, wenn da an einer Stelle von 1500 mal "Obertisch_Frachtwerk.Querausleger_Rechts_Unten.ILCK" mit "Obertisch_Frachtwerk.Querausleger_Links_Unten.ILCK" versehentlich vertauscht wird ?

Dem häufig geäußerten Einwand, "Inbetriebnehmer/instandhalter würden mit SCL nicht zurechtkommen", kann man eingentlich sachgemäß nur auf eine einzige Art begegnet werden: Herr, schicke Hirn vom Himmel. Nicht den Inbetriebnehmern - den Managern, die solche Argumente im Munde führen.

Wir leben heute nicht mehr im Jahr 1990 - es ist eine irre Anmaßung, aufgrund von welch auch immer geführter Argumentation, von Lieferanten Programmierweisen von 1990, im Verbund aber mit der prozesstechnischen Technologie von 2020 zu verlangen. Die Technologie von 2020 und solche Sachen wie IO-Link, Kameradatenerfassung, RFID-Tracking, Materialflußberechnung, Predictive Maintenance können eben nicht (vernünftig) mit den Programmiermitteln von 1990 umgesetzt werden, sondern nur mit denen von 2020. Wenn man aber nach 2000h die Anforderungen in dem Stil der Oma Emma dennoch abgebildet hat, dann findet sich dort anschließend in der Regel überhaupt niemand mehr zurecht, weder die eigenen Leute noch die Fremden. Es ist dann schlicht und ergreifend undurchschaubar. Eine "einfache" Programmiersprache bringt eben nicht automatisch einfache Prozessabläufe mit sich. Es ist ja die Feldtechnologie, die den Konstrukteuren ihre Anforderungen an eine Programmiersprache aufzwingt, und nicht umgekehrt. Wenn wir heute noch wie 1990 bloß zwei White-Black 5/3 Wege Ventile für einen kompletten Tiefziehvorgang hin und her steuern würden, wäre das ja in AWL und KOP doch kein Problem. Aber es ist ja leider nicht so.

Weiterhin ist es also eine Zumutung, von einem ordentlich aufgestellten Lieferanten, der eine gut gedeihende Softwareabteilung mit tüchtigen Kerlen hat, die eben ihre Bibliotheken und Bildbausteine und SIVARc Vorlagen und Ähnliches schon angelegt haben, zu verlangen, dies alles hinzuschmeißen und zu einer Steinzeittechnologie zurückzukehren, nur weil der Endabnehmer es bislang nicht für nötig gehalten hat, seine Leute in sachen zeitgemäßer Programmierung zu ertüchtigen.

Darüber hinaus ist es so, daß in die allermeisten SCL-programmierten Bausteine ein Instandhalter eh nicht rein soll. Wenn die so programmiert sind wie die Philosophie hinter einer Library es verlangt, dann funktionieren diese Bausteine gemäß ihrer Beschreibung und ein Inbetriebnehmer oder Instandhalter hat da nichts dran verloren. Man könnte natürlich den IBN-Leuten die Quellen zugänglich machen der besseren Nachvollziehbarkeit willen, aber generell laufen die Schrittketten im GRAPH und alles wo EA-Variablen direkt beschaltet werden, in KOP.
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
@Draco: Da kenn ich auch was von.
Sollte eine relativ einfache Anlage zum Verschweißen von Kunststoffteilen von 0 an programmieren. Etwas was ich eigentlich nicht gerne mache, denn ich habe bis heute, trotz mehrjähriger Programmiererfahrung, keinen Plan wie man an sowas strukturiert herangeht von der Planung über die Durchführung. Ich fühle mich bei Firmen am wohlsten, wo es klare Strukturen und Vorgaben gibt an denen ich mich orientieren kann.

@Oliver: Nun, wie man so schön sagt, jedem das Seine. Ich bin als Softwareentwickler mittlerweile aus diesen Umfeld raus, wo man "Malen nach Zahlen" praktiziert, habe mich aber bereits zu Beginn meiner Karriere extrem schwer getan mit Firmen, wo man alles besser zu wissen glaubt und das gerne alles so bewahrt wissen möchte, wie es dort seit 35 Jahren praktiziert wird. Am besten noch, als "Standard" deklariert - was in Wirklichkeit überhaupt kein Standard ist, sondern bloß autistische Programmierweisen irgendwelcher 60-jähriger Knacker, die weder in sich stringent sind, noch eine innere Logik mitbringen, un dnatürlich schon gar nicht irgendwo kodifiziert sind. Meine Aufgabe ist die Entwicklung von Software, Konzepten und Architekturen und die Ausschöpfung von Verbesserungspotentialen.

Programmierer, die gerne klare Strukturen hätten, wurden und werden weiterhin massenhaft im Mark gebraucht. Das sind die pflegeleichten Inbetriebnehmer, die in jedem noch so schwierigen Umfeld mit bescheuerten Managern und völlig unsachgemäßen Vorgaben einen ausgezeichneten Job machen, wenn nur das Gled fleißg fließt, immer alle noch so bescheuerten Vorgaben erfüllen, immer fleißig alle möglichen Listen führen und alle Emails beantworten, immer pünklich kommen, und eine Freude für jeden freizeitorientierten Manager sind, der auf die technischen Details mehr oder weniger verächtlich niederblickt.

Wie auch immer, ich gehöre nicht zu solchen Menschen, die selbstvertändlich ihre Existenzberechtigung haben und guten Job machen mögen, aber dieser Job ist nicht meiner.

Da noch reichlich Zeit war stellte ich alles auf FUP um, um dann zu erfahren das bei grafisch eher an KOP gedacht wurde, autsch.
Ist doch umschaltbar.

OK, wenn auch relativ schwer, aber das konnte ich noch halbwegs verstehen. Was dann folgte aber weit weniger. In der Anlage kamen zwei identische Baugruppen zum Einsatz, daher habe ich einen FB genutzt und den Instanzen jeweils die benötigten Eingänge übergeben und die Ausgänge der Hardware zugewiesen. Beim Blick auf mein Programm stellte man mir dann die Frage, wo denn der Code für die zweite Baugruppe sei. Meine Erklärung, dass es für beide nur ein Programm gebe und dann Instanzen angelegt werden, denen die Daten dann übergeben werden, sorgte für verständnislose Blicke. Man wollte alle Baugruppen direkt im Code sehen. Ich habe also alle FBs kopiert und in diesen dann die I/Os direkt genutzt. Richtig schön war dann die Fehlerkorrektur, weil ich dann nicht an einer Stelle Änderungen machen musste, sondern an vielen und prompt auch was übersehen hatte.
Dann habe ich mal deren anderen Programme gesehen. Das praktisch alles in KOP war hatte ich ja erwartet, aber ansonsten praktisch nur PRGs und alles über globale Variablen abgewickelt.

Wie gesagt, ich hätte dann argumetiert daß die Herren für solche Jobs gerne einen Wald-und Wiesen-Programmierer engaieren möchten, aber ich bin es nicht. Schrittketten in GRAPH, Kommunikation in SCL, Wartungsintensive Bausteine in KOP, Visualisierung in Bildbausteinen, Bibliotheken und Multiinstanzen sind das A und O. Aber vermutlich bei der Anlagengröße so oder so nicht mein Fall gewesen, sondern eher etwas für tüchtige Praktikanten unter strenger Aufsicht.
 
Zuletzt bearbeitet:
@Draco

Jeder darf hier mitdiskutieren, auch wenn er nicht deiner Meinung ist. Darin sollten wir doch übereinstimmen. Ich zumindest gebe Blockmove hier Recht und gehe an Hand der von dir gestellten Fragen und deiner sonstigen Einlassungen inzwischen mal davon aus, dass du eigentlich Informatiker bist. :ROFLMAO: Und ja, ich bin keiner, gehe auch eher den praktischen Ansätzen nach, liebe aber durchaus auch Ordnung im Programm!
 
@Draco

Jeder darf hier mitdiskutieren, auch wenn er nicht deiner Meinung ist.

Um Jesu Willen, ich suche doch gerade die offene Diskussion ? Dafür sitzen wir ja hier ?

gehe an Hand der von dir gestellten Fragen und deiner sonstigen Einlassungen inzwischen mal davon aus, dass du eigentlich Informatiker bist. :ROFLMAO:

Leider völlig falsch. Ich komme von der Feldseite her. War Azubi im Schaltschrankbau und habe selber ganze Anlagen verdrahtet bevor ich mich für das Studium der Elektrotechnik entschieden habe.
 
Zurück
Oben