Sonstiges Toolchain-Desaster: Modernisierung in den nächsten Jahren realistisch?

Zuviel Werbung?
-> Hier kostenlos registrieren
Mal eine Frage am Rande, nachdem hier mit allen möglichen Fremdwörtern so um sich geworfen wird. Was ist eigentlich das Thema?
Wo ist das Problem? Das es mehrere TIA Versionen gibt? Wo liegt hier das Problem. Bei unseren aktiven Abfüllanlagen haben wir
zur Prozesstechnik auch Rechner mit Win95 / WinNT / WinXP / Win7 / Win10. Diese dann jeweils auch noch auf verschiedenen Ständen, SP´s.

Was es halt braucht ist jemand, der sich auskennt und der weiß was er tut ( und getan hat ).

Ich habe schon Anforderungen von der Kunden IT Abteilung bekommen, alle Rechner müssen auf dem letzten Win10 Stand sein.
Bei Rechnern auf denen aktuell WinXP läuft mit ProTool Runtime oder ähnlichem...

Also man kann sich dass eigentlich immer hindrehen, auf welcher Seite da etwas schief läuft.
Meiner Meinung nach haben alle Seiten mit ihren Problemchen zu kämpfen, was es halt braucht sind gute Mitarbeiter
welche wissen was sie tun, keine die alles runterjammern.
 
DeltaMikeAir schrieb:
Mal eine Frage am Rande, nachdem hier mit allen möglichen Fremdwörtern so um sich geworfen wird. Was ist eigentlich das Thema?
Wo ist das Problem? Das es mehrere TIA Versionen gibt? Wo liegt hier das Problem. Bei unseren aktiven Abfüllanlagen haben wir
zur Prozesstechnik auch Rechner mit Win95 / WinNT / WinXP / Win7 / Win10. Diese dann jeweils auch noch auf verschiedenen Ständen, SP´s.

Was es halt braucht ist jemand, der sich auskennt und der weiß was er tut ( und getan hat ).

Ich habe schon Anforderungen von der Kunden IT Abteilung bekommen, alle Rechner müssen auf dem letzten Win10 Stand sein.
Bei Rechnern auf denen aktuell WinXP läuft mit ProTool Runtime oder ähnlichem...

Also man kann sich dass eigentlich immer hindrehen, auf welcher Seite da etwas schief läuft.
Meiner Meinung nach haben alle Seiten mit ihren Problemchen zu kämpfen, was es halt braucht sind gute Mitarbeiter
welche wissen was sie tun, keine die alles runterjammern.
Zum Vergrößern anklicken....

Dieser Thread hat zuerst mit Kritik an SPS-Tools und OPC UA begonnen, und ist dann in Richtung Package-Management abgedriftet.

Ich verstehe es, dass viele Legacy-Tools nur unter bestimmten Windows-Versionen laufen.
Für die Zukunft halte ich es jedoch für nicht mehr zeitgemäß, wenn ein Programmier-Tool von bestimmten Windows-Versionen abhängig ist.
Windows als Ganzes kann wie eine riesige monolithische Dependency gesehen werden.
Je stärker die Windows-Abhängigkeit ist, desto geringer ist mein Vertrauen, dass ein Tool auch in zehn Jahren noch lauffähig ist.

By the way:
Selbstverständlichkeit würde ich auch keinem Programmier-Tool vertrauen, welches von exakten Versionen bestimmter Linux-Distributionen oder macOS abhängig ist.
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
fkrc schrieb:
By the way:
Selbstverständlichkeit würde ich auch keinem Programmier-Tool vertrauen, welches von exakten Versionen bestimmter Linux-Distributionen oder macOS abhängig ist.
Zum Vergrößern anklicken....

Ich programmiere teilweise noch Simadyn Steuerungen, unter SCO Linux. Was wäre deine Erwartungshaltung? Das diese Software nach 30 Jahren auf einem aktuellen Linux
läuft? Inkl. Brenner welcher per ISA auf dem Motherboard hängt.... ??:rolleyes:
 
Glon schrieb:
Ich muss fkrc mal beistehen.

Die Automatisierungswelt ist was das Engineering betrifft grausam in ihrer Welt gefangen.

Echte Versionskontrolle bei Siemens inkl. Hardware und HMI Änderung?
Da gibt es null Möglichkeiten.
Hat mal jemand mit PCS7 V9 und CMT/EMT gearbeitet?
Sündhaft teuer und man kann eigentlich nichts nachvollziehen.

Und ich habe noch nie eine Software gesehen in der man in Listen so langsam Scrollt wie bei Siemens...
Verteiltes Zusammenarbeiten an einem Projekt? Ja da könnte man den Siemens Hauseigenen Multiserver verwenden... *hust*

Aber es gibt auch andere: Festo und Beckhoff zum Beispiel die alles in offenen Formaten speichern und man so die Möglichkeit hat eine richtige Versionsverwaltung aufzubauen.

Ich als "Junger" Programmierer ärgere mich praktisch pausenlos über Siemens und ich habe noch etliche Jahre Berufsleben vor mir. :rolleyes:
Zum Vergrößern anklicken....

Diese fehlende Nachvollziehbarkeit stört mich ebenfalls stark, wie ich bereits zum Thema "Debugging von Hochrüstungen" beschrieben habe.
Mein Problem ist nicht die Existenz von Fehlern, sondern die Schwierigkeit, Fehler mit vernünftigen Compiler-Errors line-by-line lösen zu können.

Siemens Multiuser Server halte ich leider für eine architektonische Fehlkonstruktion. Man müsste zuerst einmal die Basics hinkriegen (nämlich eine bombensichere Versionskontrolle mit unkaputtbaren Tools wie Git), und danach erst könnte man sowas wie Multiuser Server als Addon draufsetzen.

Wenn du kannst, würde ich die Kurve kratzen und von Siemens flüchten, aber das kann selbstverständlich nicht jeder und ist von vielen persönlichen Umständen abhängig.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
DeltaMikeAir schrieb:
und wohin bitte? :ROFLMAO:. Bei wem ist alles besser?
Zum Vergrößern anklicken....

Festo und Beckhoff wurden als Alternativen genannt, aber die haben natürlich auch ihre Probleme.
Egal ob Siemens oder nicht:
Die Probleme, welche ich zu Beginn dieses Threads aufgezählt habe, deuten darauf hin, dass die "freie Marktwirtschaft" dabei versagt, gute Developer-Tools zu liefern.
 
DeltaMikeAir schrieb:
Ich programmiere teilweise noch Simadyn Steuerungen, unter SCO Linux. Was wäre deine Erwartungshaltung? Das diese Software nach 30 Jahren auf einem aktuellen Linux
läuft? Inkl. Brenner welcher per ISA auf dem Motherboard hängt.... ??:rolleyes:
Zum Vergrößern anklicken....

Ich halte es im Jahr 2020 nicht mehr für zeitgemäß, wenn Programmier-Tools eine "übertrieben starke" Abhängigkeit zu einem bestimmten Betriebssystem haben. Es ist vollkommen verständlich, dass nicht jedes Programm auf jeder Linux-Distribution out of the box funktioniert.
Dennoch kann es nicht der Weisheit letzter Schluss sein, wenn Tools in der Automatisierung auf bestimmten Legacy-Versionen von Windows "gelockt" werden.
 
Mal zum Thema "Software ausliefern und mit einem Befehl einspielen":

Einer der Vorteile, die SPS bietet, sind Änderungen bei laufender Anlage.
Hierzu muss der Programmierer aber genau wissen war er in welcher Reihenfolge einspielt.
Änderungen an Datenstrukturen sind teilweise noch komplexer als z.B. Änderungen an Datenbanken.
S7-Classic war hier verglichen mit TIA und auch Codesys (Beckhoff) gut.
Mit einem Packagemanager kannst du sowas nie erreichen. Frag mal die Kollegen, die sich z.B. mit Kraftwerken oder Abwassertechnik beschäftigen.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Blockmove schrieb:
Mal zum Thema "Software ausliefern und mit einem Befehl einspielen":

Einer der Vorteile, die SPS bietet, sind Änderungen bei laufender Anlage.
Hierzu muss der Programmierer aber genau wissen war er in welcher Reihenfolge einspielt.
Änderungen an Datenstrukturen sind teilweise noch komplexer als z.B. Änderungen an Datenbanken.
S7-Classic war hier verglichen mit TIA und auch Codesys (Beckhoff) gut.
Mit einem Packagemanager kannst du sowas nie erreichen. Frag mal die Kollegen, die sich z.B. mit Kraftwerken oder Abwassertechnik beschäftigen.
Zum Vergrößern anklicken....

Ich habe mich eher auf das Einspielen und Updaten von Packages während der Projektierung bezogen.
Dass jemand auf einer laufenden Anlage ein neues Package einspielt, das halte ich für unwahrscheinlich.

Wenn diese Datenstrukturen tatsächlich so komplex sind, dann wundert es mich ohnehin, warum all diese Datenstrukturen ohne einer Versionskontrolle entwickelt werden, die auch den Namen verdient (zb. Git).
 
"This culture clash can be illustrated by comparing the skills of electricians (OT) with software engineers (IT). An industrial electrician does not only know how to build circuits and connect machinery. The electrician also knows how to program circuits via Programmable Logic Controllers (PLCs) or similar tools. However, the electrician does not know very much about how to build reusable and maintainable programs."
Zum Vergrößern anklicken....


Das ist mit Abstand wirklich das dümmste was ich seit langem gelesen habe. Glaubst du ernsthaft ein "Elektriker", gemeint ist im Text damit schlicht und ergreifend jemand der keine Ahnung von SW hat, schreibt die SW für moderne und hochkomplexe Maschinen und Roboter??? Die Leute die das tun sind Experten darin, haben die entspr. Ausbildung oder studiert, u.a. hardwarenahe wie nicht hw-nahe Programmierung gelernt und sind Software engineers, gerade eben für diesen Bereich und wissen gerade erst Recht wie man "reusable and maintainable programs" schreibt, mehr als jemand der mit React Frontends zusammenbastelt es je könnte. Zudem sind sie oft noch im elektrischen Feld bewandert, um eben das Ganze bewerkstelligen zu können, aber das bedeutet nicht dass sie "Elektriker" sind und nicht Software Spezialisten.




Zur Diskussion oder dem "provokanten Titel" kann ich leider nichts sagen, da ich vor lauter schwammigen Buzzwords kein konkretes Diskussionsthema aus den Statements des Threaderstellers ableiten kann.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Fluffi schrieb:
Das ist mit Abstand wirklich das dümmste was ich seit langem gelesen habe. Glaubst du ernsthaft ein "Elektriker", gemeint ist im Text damit schlicht und ergreifend jemand der keine Ahnung von SW hat, schreibt die SW für moderne und hochkomplexe Maschinen und Roboter??? Die Leute die das tun sind Experten darin, haben die entspr. Ausbildung oder studiert, u.a. hardwarenahe wie nicht hw-nahe Programmierung gelernt und sind Software engineers, gerade eben für diesen Bereich und wissen gerade erst Recht wie man "reusable and maintainable programs" schreibt, mehr als jemand der mit React Frontends zusammenbastelt es je könnte. Zudem sind sie oft noch im elektrischen Feld bewandert, um eben das Ganze bewerkstelligen zu können, aber das bedeutet nicht dass sie "Elektriker" sind und nicht Software Spezialisten.




Zur Diskussion oder dem "provokanten Titel" kann ich leider nichts sagen, da ich vor lauter schwammigen Buzzwords kein konkretes Diskussionsthema aus den Statements des Threaderstellers ableiten kann.
Zum Vergrößern anklicken....

Sorry ich habe eh schon zugegeben dass dieses Wording falsch war, und habe den fett markierten Satz deshalb auch weggelöscht.

Gemeint sind in diesem Fall Leute, welche keine Ahnung davon haben, wie Git funktioniert, und auch noch nie im Leben einen modernen Package-Manager wie npm verwendet haben.

Das müssen selbstverständlich keine Elektriker sein, und das bedeutet auch nicht, dass diese Leute schlechte Programmierer sind (sondern nur schlecht in der Versionsverwaltung).
 
Warum Marketing?

Er fordert nur etwas ein was überall in der Software Entwicklung Standard ist.
Die Leute die für TIA Verantwortlich sind werden hoffentlich das Projekt mit GIT oder ähnlichem versionieren.
Die Nutzer von TIA und co wird aber dieser Weg verwehrt.

Hier wird ja gerade so getan als möchte er euch Arbeitslos machen wollen.
Eine Angleichung an die "normale" Software Entwicklungswelt mit den "Besonderheiten" der Automatisierungsbranche finde ich durchweg Wünschenswert.
 
Schonmal benutzt?

Hardware Konfig + HMI geht nicht.

Grob gesagt erzeugt dieses VCI nur einen Export von Bausteinen im SCL Format und kann es dann auch wieder aus einen Ordner Importieren.

Aber es ist schon viel besser als nichts :|
 
DeltaMikeAir schrieb:
Ab V16 gibt es doch ein Versionsmanagment ( VCI )
Anhang anzeigen 51524
Zum Vergrößern anklicken....

Diese Art von Versionsverwaltung kann ich leider nur als Farce auffassen.
Sinn und Zweck einer Versionsverwaltung ist es nicht, jeden einzelnen Commit zu "importieren" oder "exportieren", sondern die versionierten Files direkt zu bearbeiten (ohne Import/Export).
In 7 Jahren Git-Benutzung ist es mir nicht ein einziges Mal passiert, dass Git ein Projekt korrumpiert, nicht einmal ein einziges Byte.

Diese Addons sind hingegen nur das was sie sind: Addons, welche als *zusätzliches* Tool zu einer robusten Versionsverwaltung verwendet werden können, aber nicht als Ersatz für Robustheit.

Es hat mehrere Jahrzehnte(!) gedauert, bis Torvalds eine bombensichere und robuste Datenstruktur gefunden hat und das Problem dadurch ein für allemal gelöst hat.
Es kann doch niemand ernsthaft glauben, dass TIA Multiuser und ähnliche Spielereien auch nur annähernd die Robustheit und Langzeit-Stabilität von Git erreichen.
 
Zuletzt bearbeitet:
DeltaMikeAir schrieb:
Also ich bin raus, vielleicht hat noch jemand anderer Lust dieses sinnlose Gespräch weiterzuführen.

Alles Gute
Zum Vergrößern anklicken....

Sorry das ist jetzt wohl als zu starker Angriff aufgefasst worden ^^

Ich weiß, es ist immer sehr schwierig, Schwächen der eigenen Tools einzugestehen, und die Versuchung ist groß, alle Probleme zu ignorieren (nach dem Motto: "niemand darf meine Workflows angreifen, was gestern gut genug war, ist auch heute gut genug!").
Tools wie TIA haben viele Stärken, aber eines kannst du mir trotzdem glauben:
Von einer modernen Versionsverwaltung und einem modernen Package-Management bist du bei TIA Lichtjahre entfernt.
 
Zurück
Oben