Codegenerierung in der Praxis

Zuviel Werbung?
-> Hier kostenlos registrieren
Der Nutzen ist meines Erachtens eindeutig gegeben.
Aber:
Daraus ein tragfähiges Geschäftsmodell zu machen, stelle ich mir sehr schwierig vor.
Wenn ein Konstruktionsbüro so eine Lösung für den internen Gebrauch entwickelt, dann macht das richtig Sinn.
Es spart Zeit und Aufwand und man kann das Tool genau an die Bedürfnisse und Arbeitsweise anpassen.
Am Markt muss man daraus die eierlegende Wollilchsau machen, und das bedeutet wieder viele Einschränkungen.
Spannend aber schwierig.

Gruß
Blockmove

Ich denke mal, man könnte vielleicht einen flexiblen Baukasten bereitstellen, der so ähnlich wie SiVArc funktioniert. Dort ist ja auch sehr wenig vorgegeben und sehr viel in der Hand des Anwenders, alledrings gibt es auch einen gewissen Rahmen und kodifizierte Befehlssystematik.

Wenn man also eine ähnliche Anwendung hätte, die jedoch die Schnittstelle zwischen EPLAN-Exporten / Listen und der TIA-Welt bilden würde, dann könnte man damit innerhalb der jeweiligen Softwareabteilungen, wenn denn der Wille und der Verstand dafür da sind, schon ziemlich weit kommen. Das Übrigen würde dann der SiVArc in seiner jetzigen Form problemlos erledigen können.
 
Moin,

auch wenn jetzt die Antwort ein bisschen später hier mal mein Vorschlag. In unserer Firma arbeiten wir mit selbst geschriebenen FB's für Motoren (Schütz oder FU), Digitalsensoren und Analogsensoren (Standardelemente). Da uns irgendwann der Projektierungsaufwand zu hoch war, in der HMI Textlisten und HMI Meldungen zu erstellen, wobei die Informationen schon in der SPS in den FB's gespeichert sind, haben wir uns ein Programm geschrieben welches uns automatisch den Aufruf für solche Elemente generiert und HMI Textlisten und HMI Meldungen als Importdatei erstellt.
Dazu haben wir uns ein Tool geschrieben, welches die von ePlan oder WSCAD exportierten EA Listen einliest. Für die Standardelementekann nun jeder Ein- und Ausgang verknüpft werden. Am Ende wird dann mithilfe von TIA Openess den Aufruf der Standardelemente generiert in TIA und Excel Datei erstellt für den Import von HMI-Meldungen und Textlisten in TIA. Die Visualsierung der Elemente findet dann mithilfe vom Multiplexen statt.
Dadurch sparen wir uns viel nervige Schreibarbeit ;)
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Moin,

auch wenn jetzt die Antwort ein bisschen später hier mal mein Vorschlag. In unserer Firma arbeiten wir mit selbst geschriebenen FB's für Motoren (Schütz oder FU), Digitalsensoren und Analogsensoren (Standardelemente). Da uns irgendwann der Projektierungsaufwand zu hoch war, in der HMI Textlisten und HMI Meldungen zu erstellen, wobei die Informationen schon in der SPS in den FB's gespeichert sind, haben wir uns ein Programm geschrieben welches uns automatisch den Aufruf für solche Elemente generiert und HMI Textlisten und HMI Meldungen als Importdatei erstellt.
Dazu haben wir uns ein Tool geschrieben, welches die von ePlan oder WSCAD exportierten EA Listen einliest. Für die Standardelementekann nun jeder Ein- und Ausgang verknüpft werden. Am Ende wird dann mithilfe von TIA Openess den Aufruf der Standardelemente generiert in TIA und Excel Datei erstellt für den Import von HMI-Meldungen und Textlisten in TIA. Die Visualsierung der Elemente findet dann mithilfe vom Multiplexen statt.
Dadurch sparen wir uns viel nervige Schreibarbeit ;)

Herzlichen Glückwunsch, ihr habt PCS7 erfunden.

Die Idee, Elemente aus EPLAN einzulesen, finde ich klasse. Bloß, finde ich, ist die Importierung irgendwelcher Excel-Dateien im TIA ein großer Müll. Dazu gibt es SiVArc. PCS7 arbeitet standardmäßig mit COMOS; dort wird die Instrumentierung und Hardware verplant, und anschließend Musterlösungen definiert, wie mit der Hardware zu verfahren ist. Diese Musterlösungen kann man nachher im PCS7 importieren und an einer zentralen Stelle verwalten.

Für EPLAN gibt es solche Tools bislang nicht, und da sehe ich noch ein hohes Entwicklungspotential. Allerdings sollen dann bitte keine Excel-Listen anschließend rauskommen. Ist unglaublich mühsam und fehlerträchtig damit zu arbeiten. Ich will als Automatisierungsingenieur jedenfalls keine Excel-Makros entwickeln oder editieren müssen. Dafür gibt es andere Werkzeuge.
 
Zuletzt bearbeitet:
@Draco
Excel als Austauschformat ist zwar nicht der Hit, aber es erfüllt eigentlich die Anforderungen.
Die Bearbeitung ist einfacher als mit XML oder JSON.
Für die Automatisierung kannst du Excelmakros nehmen oder du machst es in der Programmiersprache deiner Wahl.

Gruß
Blockmove
 
Herzlichen Glückwunsch, ihr habt PCS7 erfunden.
Das wussten wir noch nicht :rolleyes:

Zudem kann man ja auch aus ePlan Dateien generieren, so dass man die Hardwarekonfiguration einfach reinladen kann.

Ich finde der Vorteil bei der ganzen Excel Sache ist auch die, dass wir dann eine Importliste haben, die wir im späteren Verlauf immer noch bearbeiten können und uns diese auch lesbar durchlese
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo allerseits,

ich bin neu hier im SPS-Forum, angemeldet habe ich mich hauptsächlich wegen dem Thema Code-Generierung für Simatic TIA Protal.

Habt ihr schon mal etwas mit TIA OPENNESS probiert ?

Gruß Torquee :)
 
Einen Vorteil von Codegenerierung hat noch keiner erwähnt:
Man kann aus der gleichen Eingabemenge Code für verschiedene Systeme erzeugen (S7Classic, TIA, CodeSys, Allen Bradley, usw)
Das wird dann natürlich noch aufwendiger und das muss sich schon richtig lohnen.
Ich erzeuge z.B. mit Hilfe von Excel aus einem Schnittstellen Dokument Code für 3 Systeme. Das war sehr aufwendig, aber jetzt wo es geht, ist es schon eine tolle Sache.

Ein weiterer Vorteil ist die Korrektheit: Sofern der Generator gut arbeitet und die Eingangsdaten stimmen, kann man sich auf die Richtigkeit des Ergebnisses verlassen. Egal ob es 2, 10 oder 10000 Elemente sind, alle werden richtig sein. Seien wir doch ehrlich. Wie viel Zeit verbringt man normalerweise mit Kopieren und Anpassen (Langweilig) und hinterher mit Kontrollieren, weil irgendwann doch die Konzentration nachlässt.

Ob man ganze Programme so bauen kann, weiß ich nicht.
Aber für kleine Teilbereich, die sich gut automatisieren lassen, weil die Daten gleichmäßig und listenartig sind, würde ich einen Generator dem händischen erstellen und ändern immer vorziehen.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ich erzeuge z.B. mit Hilfe von Excel aus einem Schnittstellen Dokument Code für 3 Systeme. Das war sehr aufwendig, aber jetzt wo es geht, ist es schon eine tolle Sache.
Noch einmal: Ich möchte als Programmierer keine Office-Tools für die Erstellung meiner Software bemühen. Handelt es sich um eine prozesstechnische Applikation, existiert dafür PCS7. Prozess auf TIA-Steuerungen zu automatisieren widerspricht dem Entwicklungsgedanken dieser Steuerungen, die sind dafür im Moment nicht gedacht, jedenfalls solange es keinen CFC als Programmierwerkzeug dafür gibt. Handelt es sich um eine fertigungstechnische Anwendung, gibt es die Schnittstelle TIA Openess, und die müsste man bemühen und ensprechende Projektgeneratoren und Tools dafür schreiben.

Aber ich möchte als Anlagen-Ingenieur weder Excel-Makros programmieren, noch diese Tools selber entwickeln. Das ist einfach nicht mein Job. Außerdem ist der Wiederholungsgrad in den fertigungstechnischen Maschinen in der Regel relativ gering - oder es wiederholen sich ganze Einheiten, die man bei objektorientierter Programmierung auch ohne größeren Aufwand händisch kopieren kann.

Viel wichtiger ist die stringente, bibliotheksfähige Vorgehensweise über ein umfangreiches Pool mit allen notwendigen Typicals, und angebundenen Faceplates, die jegliche Art der eingesetzten Hardware und Module abbilden, und die ich dank existierender Bildbausteine nicht händisch im HMI verdrahten muss. Heißt aber im Umkehrschluß, daß es eine gegenseitig abgesegnete Liste mit Hardware gibt, die verbaut werden darf, und Abweichungen davon erst durch die Softwarekonstruktion freigegeben werden müssen. Damit haben aber die meisten Firmen ein Problem, die der festen Überzeugung sind, die Elektroingenieure wären bloß irgendwelche ulkige Nerds, mit denen man nach dem Prinzip "fressen was auf den Tisch kommt" umgehen müsste.
 
Zuletzt bearbeitet:
Der letzte Absatz spricht mir aus der Seele. Damit hast du den Kern des Problems genau getroffen. Aber von so etwas wie abgesegneten Listen sind die meisten Firmen bestimmt sehr weit entfernt. Und auch die "Strukturierung" der Anlage ist ein Problem. Die Struktur ist oft nicht softwarefreundlich, sondern richtet sich nach Beschaffung und Mechanischen/elektrischen Baugruppen.

Und auch mit dem Rest hast du eigentlich recht. Diese Excel-Programme können zwar praktisch sein, aber sie sind letztlich nicht viel mehr als kleine Helferlein, die nach ein paar Jahren wirklich kaum jemand warten kann. Ich schon mehrere solcher Dinger schon gemacht und alle sehen anders aus. Trotzdem würde ich sagen, dass das besser ist als nichts. Ich mache das eigentlich recht gern, weil das ein guter Ausgleich zum zähen Programmieren einer SPS ist, besonders, wenn man zu KOP gezwungen wird. :ROFLMAO:

Ich denke die Einstiegshürde in eine API wie OpenNess ist für die meisten einfach zu hoch. Excel kennt jeder und Excel hat auch jeder auf seinem PC. Das kostet gar nichts extra. Wenn aber erst einmal VisualStudio angeschafft werden muss, dass auch noch Lizenzkosten verursacht, dann wird die Bereitschaft schon kleiner. Und dann muss man es ja auch noch lernen.
 
zum Thema "CFC in TIA Portal"

ich habe S.interne Dokumente gesehen, die darauf schließen lassen, daß ein CFC-Editor für TIAP bereits besteht oder sehr sehr weit fortgeschritten ist.

Ich bin seit 21 Jahren bei Siemens und kann sagen, daß das gar nichts heißt.

Es gibt für alles Produktmanager. Deren Interessen haben mit den Bedürfnissen der Anwender nur perifer zu tun.

Treibende Kräfte für TIAP sind große Firmen wie BMW, VW, große ING-Büros und so weiter, die Automatisierung für diskrete Fertigung brauchen.

Die diskreten Fertiger brauchen kein CFC (meinen sie jedenfalls).

Der PM für PCS7 wird kein Interesse daran haben, daß CFC auch in TIAP integriert wird.

Nebenbei: Es gibt auch Interesse von Seiten der Gebäude-Automatisierung CFC mit TIAP zu nutzen.


Es steht also in den Sternen wann CFC in TIAP kommt, in Version V17, V27 oder V127 ! :)
 
Zuviel Werbung?
-> Hier kostenlos registrieren
zum Thema OPNENNESS

das ist meine persönliche "laienhafte" Sicht !!!

Mein Interesse an TIAP und OPENNESS besteht in rein privater Natur. (Haus-Automatisierung für mich)

Ich habe zu Beginn meiner beruflichen Laufbahn mit AEG MODICON A250 Steuerungen gearbeitet.

Da war das, was man mit OPENNES erledigen will schon möglich (auf textueller Basis: Export - Modifikation - Import)


Treibende Kräfte für OPENNES sind auch hier die großen Firmen wie BMW, VW, Bühler, große ING-Büros und so weiter, die Code generieren wollen, warum auch immer.

Es gibt Anwendungen, zum Beispiel in der Fördertechnik, da geht es ohne Generierung gar nicht mehr.


Leider wird aus meiner Sicht die API "OPENNESS" nicht sauber umgesetzt.

Eine API muß auch dokumentieren, wie der Zusammenhang zwischen den Programm-internen Darstellungen (z. Bsp. FUP) und den Export- und Import-Strukturen ist (XML)

Hier hapert es noch bei OPENNESS.

Für FUP existiert keine einzige offizielle Dokumentation dazu !

Die großen Firmen setzen da dann Werksstudenten dran, die das Rätzel analysieren und dokumentieren.

Das gesammelte Wissen ist dann Firmen-internes Know-How, das nicht weitergegeben werden darf.

Der Klein- und Mitter-Programmierer hat dann Pech gehabt.


meine Meinung:

Die Programmierer des Export-Inport-Algorithmus generieren die internen Datenstrukturen einfach in XML-Dateien und legen sie in Dateiverzeichnissen ab.

Das macht am wenigsten Arbeit.

Das Ergebnis sind XML-Strukturen die keiner versteht, auch wegen der fehlenden Dokumentation.

Die internen Strukturen werden innerhalb TIAP ja von den Editoren interpretiert und dargestell, das ist dann für den TIAP Benutzer handlebar.

Ich habe in TIAP V13 einen Export mit dem Sript-Generator gemacht, dann unverändert wieder importiert, der Import lief auf Fehler.

Auf Nachfrage teilte man mir mit, dass der OPENNESS Script-Generator kostenlos ist und man keine Rechte auf funktionierende Software daraus ableiten kann.


Wenn man OPENNESS für alle nutzbar machen möchte, so wäre ein Gemeinschaftsprojekt nötig, in dem alle Intressierten ihr wissen austauschen und zusammentragen und pflegen.

Auf die Vervollständigung der Dokumentation von Seiten Siemens würde ich nicht hoffen.

Ich wünsche ein schönes WE !

P.S.: das mit dem laienhaften ist schon etwas übertrieben
 
Zum Thema CFC:

Ich habe mal da extra ein Thema aufgemacht, aber da hat sich keiner von Siemens zu gemeldet. Ich habe das schon so vermutet - CFC gibt es, aber entweder nicht anwendungsreif, oder vom Produktmanagement nicht freigegeben, wahrscheinlich zweiteres weil ersteres.

Man muß auch festhalten, CFC wäre schön und gut, aber es ist bloß die halbe Miete. So richtig Prozess kann man auf diesen CPUs dann erst betreiben, wenn es auch Technologische Hierarchie und Musterlösungen gibt, und auch entsprechende Bibliotheken wie Basic Library und Advanced Prozess Library. Wie man eine Basic Library für TIA-CPUs schreiben will, ist mir indes schleierhaft, da die relevanten Systemfunktionen, mit denen diese Bibliothek in der Classic Welt funktioniert, in den TIA-CPUs fehlen.
 
Der letzte Absatz spricht mir aus der Seele. Damit hast du den Kern des Problems genau getroffen. Aber von so etwas wie abgesegneten Listen sind die meisten Firmen bestimmt sehr weit entfernt. Und auch die "Strukturierung" der Anlage ist ein Problem. Die Struktur ist oft nicht softwarefreundlich, sondern richtet sich nach Beschaffung und Mechanischen/elektrischen Baugruppen.

Das Problem ist, daß es schlicht unehrlich ist, innerhalb der eigenen Firma, da man jeweils mit Kosten arbeitet, die entweder auf der einen oder auf der anderen Seite anfallen. Diese Kosten zu verschweigen, zu ignorieren oder der "fremden" Abteilung in die Schuhe zu schieben, ist letzten Endes ein Selbstbetrug. Wenn die MK (mechanische Konstruktion) tolle Antriebe von Faulhaber oder Festo anstelle von Siemens verbauen möchte, weil es ihnen nen Haufen Platz spart und die Baugruppen kompakter werden, müsste man eigentlich erst ausrechnen, welchen Kostenvorteil es tatsächlich bringt, und demgegenüber den Aufwand rechnen, welcher entsteht, wenn die EK (Elektrokonstruktion) diese Antriebe bespielen muss. Es werden dann nebenbei auch neue EPLAN-Makros, Überarbeitung von Softwarebasis und Ergänzung der Beschaffungsroutinen notwendig. Überwiegt der Kostenvorteil, oder sprechen andere Gründe für den Einsatz, dann muss die KE diesen Aufwand in Mann-Stunden quantifizieren und das Management es absegnen. Höchstwahrscheinlich werden dann bereits über die Hälfte solcher Anpassungen hinfällig, bevor es überhaupt zum Ausprobieren kommt.

Dasselbe gilt übrigens auch für den Pre-Sales, wenn der Kunde Automatisierung nach Wunschkonzert verlangt.

besonders, wenn man zu KOP gezwungen wird.
Mein Beileid.
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
Wenn die MK (mechanische Konstruktion) tolle Antriebe von Faulhaber oder Festo anstelle von Siemens verbauen möchte, weil es ihnen nen Haufen Platz spart und die Baugruppen kompakter werden, müsste man eigentlich erst ausrechnen, welchen Kostenvorteil es tatsächlich bringt, und demgegenüber den Aufwand rechnen, welcher entsteht, wenn die EK (Elektrokonstruktion) diese Antriebe bespielen muss. Es werden dann nebenbei auch neue EPLAN-Makros, Überarbeitung von Softwarebasis und Ergänzung der Beschaffungsroutinen notwendig.
Bei deiner Aufzählung könnte man folgendes ergänzen:

  • Mehrfacher Aufwand bei der Ersatzteilhaltung
  • Fehle Möglichkeit bei der Fehlersuche Komponenten der Nachbar-Anlage quer zu tauschen
  • Zusätzliche Einarbeitung in Bedienung und Konfiguration
  • Zusätzliche 3. IBN-Software und zusätzliche Sonder-Kabel und Adapter

Wenn in deinem Fall, Siemens nichts im Katalog hat, mit was die Ziele erreicht werden können, dann muss man die oben genannten Nachteile in Kauf nehmen. :rolleyes:

Das Kernproblem sehe ich darin, dass einerseits eine Standardisierung festgelegt wird und im nächsten Atemzug, Flexibilität verlangt wird. :ROFLMAO:
 
Womit auch wieder beim Generieren sind. Einen flexiblen Standard finden, genau das ist die Kunst dabei :ROFLMAO: .

Es fängt schon damit an, daß ein Standard nicht dasselbe wie irgendwelche hysterisch gewachsene Handschriften autistischer Programmierer ist. Letzteres ist kein Standard, sondern Müll. Standard muß inhaltlich stringend, durchgehend, logisch nachvollziehbar und vernünftig dokumentiert sein.

Man verlangt häufig von externen Kräften, "sich bitte an den Standard zu halten". Macht man den Fehler, diese Gutsherrenwünsche unhinterfragt hinzunehmen, findet man sich später in der Situation, völlig systemlose, abartig dokumentierte, gruselige Schmierereien schizoider Firmenprogrammierer auseinander zu nehmen und reverse engineeren zu müssen, und hinterher beschwert sich die Kundschaft, warum man es denn bitte nicht "genau so" gemacht hat, und will die Rechnung nicht bezahlen.

Intern aber scheinen die Wenigsten überhaupt das Verständnis dafür zu haben, warum die externen Kräfte mit der Soße nicht zurechtkommen, und intern die Abteilung regelmäßig horrende Stundenschätzung für jede Abweichung von ihrem "Standard" ausstellt. Es kann nämlich auch nicht sein, daß ein Wechsel der Gerätefamilie von SEW auf Siemens bei einfachsten Förderbandantrieben dazu führt, daß 1000h mehr im Projekt anfallen.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Es fängt schon damit an, daß ein Standard nicht dasselbe wie irgendwelche hysterisch gewachsene Handschriften autistischer Programmierer ist. Letzteres ist kein Standard, sondern Müll. Standard muß inhaltlich stringend, durchgehend, logisch nachvollziehbar und vernünftig dokumentiert sein.

Man verlangt häufig von externen Kräften, "sich bitte an den Standard zu halten". Macht man den Fehler, diese Gutsherrenwünsche unhinterfragt hinzunehmen, findet man sich später in der Situation, völlig systemlose, abartig dokumentierte, gruselige Schmierereien schizoider Firmenprogrammierer auseinander zu nehmen und reverse engineeren zu müssen, und hinterher beschwert sich die Kundschaft, warum man es denn bitte nicht "genau so" gemacht hat, und will die Rechnung nicht bezahlen.

Intern aber scheinen die Wenigsten überhaupt das Verständnis dafür zu haben, warum die externen Kräfte mit der Soße nicht zurechtkommen, und intern die Abteilung regelmäßig horrende Stundenschätzung für jede Abweichung von ihrem "Standard" ausstellt. Es kann nämlich auch nicht sein, daß ein Wechsel der Gerätefamilie von SEW auf Siemens bei einfachsten Förderbandantrieben dazu führt, daß 1000h mehr im Projekt anfallen.

Vielleicht hast du Recht. Aber kann es sein, dass du dich für den Gott der externen Programmierer hältst? Komm ruhig mal ein bisschen runter, nicht Alle sind gleich schizoid und minderbegabt, nur weil sie vielleicht nicht deinen Horiziont erreichen. Wenns denn böser Wille wäre, aber das ist es meißt nicht, eher wenig Zeit, unverständige Chefs, na gut und manchmal auch Unvermögen. :ROFLMAO:
 
Vielleicht hast du Recht. Aber kann es sein, dass du dich für den Gott der externen Programmierer hältst? Komm ruhig mal ein bisschen runter, nicht Alle sind gleich schizoid und minderbegabt, nur weil sie vielleicht nicht deinen Horiziont erreichen. Wenns denn böser Wille wäre, aber das ist es meißt nicht, eher wenig Zeit, unverständige Chefs, na gut und manchmal auch Unvermögen. :ROFLMAO:

Ralle, abgesehen davon, daß die Höflichkeit in deiner Anspache stark nachgelassen hat, der Punkt, auf den ich aufmerksam machen will, ist ein gänzlich anderer. Die Standardsituation in den Firmen ist, künstlerisch überzeichnet, ungefähr so:

- Abteilungsleiter, selber bereits weit weg sowohl von den technischen Realitäten als auch vom inhaltlichen Verständnis, kümmert sich nur noch um die Stunden der Mitarebeiter, politische Intrigen innerhalb der Firma, Projektplanung und Beschaffung von Inbetriebnahmekräften;
- Ingenieure, meistens seit 10-15 Jahren in der Firma, kennen weder die neuesten Technologien noch den technischen Fortschritt auf dem Mark, bilden sich selber nicht weiter, interessieren sich nicht für technische Neuerungen, und generell für kaum etwas, außer ihrer Freizeit und Konstanz der Kaffeetemperatur im Büro;
- Projektmanager und höhere Manager haben überhaupt keine Ahnung wie Automatisierung funktioniert und was die Firma konkret braucht, um dort mehr Effizienz und Anschluß an die Realitäten der heutigen Welt zu erreichen;
- Interne Mitarbeiter, die etwas auf dem Kasten haben und die Zustände eigentlich auch gerne beseitigen würden, werden jahrelang ausgebremst und resignieren am Schluß, weil deren Meinung niemanden interessiert und ihnen nichts anvertraut wird;
- Externe Kräfte werden nur gebucht, um drohenden Personalmangel abzufangen, und haben ohnehin nichts zu sagen.

In Ausnahmefällen bucht so eine Firma, auch mal einen externen Berater, wenn der Unmut über die fehlende Flexibilität und hohe Stundenvolumina irgendwo in den Führungsetagen Überhand nimmt. Dann kommt so ein externer Berater da hinein, und erzählt von Graph, Prodiag, SiVArc, T-CPUs, Bibliotheken, Bildbausteinen usw. Die Leute hören dann in bunten Workshops gelangweilt zu und sorgen dann auf kurz oder lang dafür, daß dieser Mensch dort nichts real bewegen und bewirken kann. Es wird lang und ausufernd diskutiert, warum die Räder, die innerhalb des Mikrokosmos dieser Firma erfunden worden sind, ganz spezielle Räder sind, die nichts mit den Rädern der Firma Siemens zu tun haben, und deswegen kann man davon leider nichts einsetzen.

Als Sahnehaube kommen dann dem einen oder anderen jungen und dynamischen Abteilungsleiter die Ideen, zum Beispiel eine einheitliche Visualisierung quer über alle Steuerungen anzuschaffen, und/oder sich von Produkten der Firma Siemens zu trennen, und stattdessen ganz tolle Phoenix Visu 2+ (minus, sinus, cosinus) und Beckhoff Schießmichtot einzusetzen, weil Siemens ja Boko Haram ist. Noch Fragen ?
 
Zuletzt bearbeitet:
Zurück
Oben