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

[Blockmove]

Zuviel Werbung?
-> Hier kostenlos registrieren

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.

Also das ist schlichtweg falsch.
Linus hat ewig Bitkeeper zur Versionsverwaltung benutzt.
Irgendwann haben die das Geschäftsmodel geändert und Bitkeeper sollte Geld kosten.
SVN wollte Linus nicht und daher hat er innerhalb weniger Tage Git erfunden und eine erste Version freigegeben.
Die letzten großen Änderungen an Git kamen dann von Microsoft.

 

[Ingmar64]

Also für mich sind die TIA-Fehlermeldungen beim Kompilieren mittlerweile recht klar, wahrscheinlich wie Dir die C-Fehlermeldungen, die wiederum mich vor Rätsel stellen.
Und ein V13-Projekt ist auch auf V16 hochrüstbar aber meist hat die Instandhaltung eben nur V13 und kann mit V16 eben nichts anfangen. Aber ich denke Wordstar von 1990 wird ein Word365-Dokument auch nicht öffnen können, da ja schon die alten Word_Versionen das heutige Format nicht mehr verstehen. Vermutlich läuft es auch nicht nicht mehr unter den aktuellen Windows-Versionen. Aber irgendwann kommt jemand mal auf die Idee, auch die Tankstutzen der Autos dauernd zu ändern ... bei den Elektroautos klappt das schon ganz gut.

Und ich vermute, es wird mit einem modernen C-Compiler ganz schön schwierig, ein Programm für einen MS-DOS-PC von 1990 zu kompilieren.

Wir hatten vor kurzen jemanden bei uns, der mit Phyton ein ganz kleines Problem lösen sollte (Anzeige eines Videostreams). Was der sich tagelang mit Bibliotheksversionen usw. rumgeschlagen hat, bis es dann schlussendlich lief .... Nein, dann lieber TIA.

 

[Fluffi]

Zuviel Werbung?
-> Hier kostenlos registrieren

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).

Du musst aber nicht nur den fett markierten Satz weglöschen... Ich verstehe deinen seltsamen personenbezogenen Ansatz nicht: OT vs IT, PLC Programmierer = Elektriker der "circuit diagrams umsetzt??? vs software engineer = zwingend IT Bereich, aber natürlich nicht im PLC Bereich zu finden, der natürlich den Dullis aus der "OT" erstmal beibringen muss was Phase ist


Man merkt du hast noch nie in dem Bereich gearbeitet.


Niemand ist schlecht in der Versionsverwaltung oder hat keine Ahnung wie Git funktioniert etc, nur weil er im PLC-Bereich tätig ist oder dass hier gar die Meinung vorherrscht man brauche das nicht.
Das Problem ist schlicht und ergreifend der Punkt, dass die IDEs, jetzt im Beispiel Siemens, TIA Portal das eben nicht anbietet(/angeboten hat) und man hier eben nur das verwenden kann, ob man will oder nicht, was einem vorgesetzt wird. Letzteres hat wiederum was mit der proprietären HW in der Branche zu tun was eben zu teils suboptimalen IDEs führt. Die Welt ist hier nun mal nicht so offen wie auf dem PC und man ist von einen Hersteller abhängig.
Eine saubere Versionskontrolle mit GIT oder anderen Tools wünscht sich jeder seit Anbeginn. Dein merkwürdiger Ansatz mit "mindset of an electrician" ist Blödsinn. Der einzige Punkt wo du Recht hast, ist das solche Dinge auch hier reingehören. Die Herleitung nicht.

 

[fkrc]

Du musst aber nicht nur den fett markierten Satz weglöschen... Ich verstehe deinen seltsamen personenbezogenen Ansatz nicht: OT vs IT, PLC Programmierer = Elektriker der "circuit diagrams umsetzt??? vs software engineer = zwingend IT Bereich, aber natürlich nicht im PLC Bereich zu finden, der natürlich den Dullis aus der "OT" erstmal beibringen muss was Phase ist


Niemand ist schlecht in der Versionsverwaltung oder hat keine Ahnung wie Git funktioniert etc, nur weil er im PLC-Bereich tätig ist oder dass hier gar die Meinung vorherrscht man brauche das nicht.
Das Problem ist schlicht und ergreifend der Punkt, dass die IDEs, jetzt im Beispiel Siemens, TIA Portal das eben nicht anbietet(/angeboten hat) und man hier eben nur das verwenden kann, ob man will oder nicht, was einem vorgesetzt wird. Letzteres hat wiederum was mit der proprietären HW in der Branche zu tun was eben zu teils suboptimalen IDEs führt. Die Welt ist hier nun mal nicht so offen wie auf dem PC und man ist von einen Hersteller abhängig.
Eine saubere Versionskontrolle mit GIT oder anderen Tools wünscht sich jeder seit Anbeginn. Dein merkwürdiger Ansatz mit "mindset of an electrician" ist Blödsinn. Der einzige Punkt wo du Recht hast, ist das solche Dinge auch hier reingehören. Die Herleitung nicht.

Dann sind wir uns also eh einig, was die Ziele betrifft, aber nicht was meine (zugegeben zweifelhafte) "Herleitung" betrifft
Ich würde meinen, dass es beide Fälle gibt:

- Manche PLC-Programmierer glauben, solche Sachen nicht zu brauchen, weil es eh "immer schon so" funktioniert hat.
- Andere PLC-Programmierer wissen sehr wohl, dass sie all das brauchen würden, aber sind gezwungen, die existierenden Tools zu fressen.

Wie die prozentuelle Verteilung zwischen diesen zwei Arten von Programmierern ist, darüber kann ich nur spekulieren...
Du zählst jedenfalls zur zweiten Art, so wie ich deine Antwort verstehe.

Die Quintessenz ist vermutlich, dass monopolisitsche und geschlossene Hersteller-Strukturen häufig zu verkrusteter und schlechter Software führen.
Ähnliche Probleme gibt oder gab es auch im Bereich "Embedded Software IDEs" (hat sich aber vielleicht schon verbessert).

 

[fkrc]

Also für mich sind die TIA-Fehlermeldungen beim Kompilieren mittlerweile recht klar, wahrscheinlich wie Dir die C-Fehlermeldungen, die wiederum mich vor Rätsel stellen.
Und ein V13-Projekt ist auch auf V16 hochrüstbar aber meist hat die Instandhaltung eben nur V13 und kann mit V16 eben nichts anfangen. Aber ich denke Wordstar von 1990 wird ein Word365-Dokument auch nicht öffnen können, da ja schon die alten Word_Versionen das heutige Format nicht mehr verstehen. Vermutlich läuft es auch nicht nicht mehr unter den aktuellen Windows-Versionen. Aber irgendwann kommt jemand mal auf die Idee, auch die Tankstutzen der Autos dauernd zu ändern ... bei den Elektroautos klappt das schon ganz gut.

Und ich vermute, es wird mit einem modernen C-Compiler ganz schön schwierig, ein Programm für einen MS-DOS-PC von 1990 zu kompilieren.

Wir hatten vor kurzen jemanden bei uns, der mit Phyton ein ganz kleines Problem lösen sollte (Anzeige eines Videostreams). Was der sich tagelang mit Bibliotheksversionen usw. rumgeschlagen hat, bis es dann schlussendlich lief .... Nein, dann lieber TIA.

Ich glaube, dass du die C-Fehlermeldungen sehr schnell lernen würdest, solange es nicht allzu sehr in die Tiefe geht.
Zugegeben gibt es auch mit C kryptische Linker-Errors oder Makros, bei denen man potentiell stundenlang debuggen muss.
Aber zumindest habe ich die Möglichkeit, ein C-Makefile in seine Einzelteile zu zerlegen, bis ich ans Ziel komme und einen Fehler lösen kann.

C-Makefiles sind vom Grundprinzip nämlich sehr einfach zu verstehen (ein sogenannter "Directed Acyclic Graph aus Timestamp-Dependencies", für C-Programmierer die das genauer verstehen wollen).
Bei TIA-Portal und Konsorten würde ich hingegen bezweifeln, dass du die Compile-Chain wirklich bis in die Tiefe verstehst, weil für die TIA-Compile-Chain ja gar keine öffentliche Doku existiert.

 

[rostiger Nagel]

Zuviel Werbung?
-> Hier kostenlos registrieren

Dann sind wir uns also eh einig, was die Ziele betrifft, aber nicht was meine (zugegeben zweifelhafte) "Herleitung" betrifft
Ich würde meinen, dass es beide Fälle gibt:

- Manche PLC-Programmierer glauben, solche Sachen nicht zu brauchen, weil es eh "immer schon so" funktioniert hat.
- Andere PLC-Programmierer wissen sehr wohl, dass sie all das brauchen würden, aber sind gezwungen, die existierenden Tools zu fressen.

Wie die prozentuelle Verteilung zwischen diesen zwei Arten von Programmierern ist, darüber kann ich nur spekulieren...
Du zählst jedenfalls zur zweiten Art, so wie ich deine Antwort verstehe.

Es gibt C++ Programmierer die meinen man muss Automatisierung für Maschinen unbedingt
von Informatiker machen lassen.
Und da gibt es die, die verstanden haben besser die Finger davon zu lassen.

 

[BenGun]

ich versteh nicht mehr worum es hier eigendlich geht.

- der Themenstarter hat halt SEINE Meinung (wie ich es verstehe C ist das non plus ultra). Er scheint aus der PC Ecke zu kommen, und versucht den Rest zu überzeugen, das ER das einzig Wahre Konzept hat.
- der Rest kennt sich halt mehr mit der PLC Programmierung aus , sagen wir mal TIA oder S7 Basis, und haben entsprechend mehr Hintergrundwissen.

Sicher gibt es immer wieder Schnittstellenprobleme zw. PC/IT und/oder PLC´s, aber ehrlich gesagt, macht Das doch den "Kick" aus. Warum soll ich ein monolitisches System nutzen wo "jeder" Hinz und Kunz dran rumpfuschen kann. Gerade bei PLC´s führen "1000" Wege zum Ziel. Jeder so wie er will und kann...

Bisher war ich immer nur Leser, habe Vieles hier im Forum gelernt. aber solch eine Sinnfreie Diskusion, hatten wir das schon mal?

Gruß

 

[Faceman]

Es ist halt wie so oft im Leben.

Es gibt Redner und Macher. Zu welcher Gruppe der TE gehört, darüber kann sich jeder seine eigene Meinung bilden.

 

[Blockmove]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich glaube, dass du die C-Fehlermeldungen sehr schnell lernen würdest, solange es nicht allzu sehr in die Tiefe geht.
Zugegeben gibt es auch mit C kryptische Linker-Errors oder Makros, bei denen man potentiell stundenlang debuggen muss.
Aber zumindest habe ich die Möglichkeit, ein C-Makefile in seine Einzelteile zu zerlegen, bis ich ans Ziel komme und einen Fehler lösen kann.

C-Makefiles sind vom Grundprinzip nämlich sehr einfach zu verstehen (ein sogenannter "Directed Acyclic Graph aus Timestamp-Dependencies", für C-Programmierer die das genauer verstehen wollen).
Bei TIA-Portal und Konsorten würde ich hingegen bezweifeln, dass du die Compile-Chain wirklich bis in die Tiefe verstehst, weil für die TIA-Compile-Chain ja gar keine öffentliche Doku existiert.

Jetzt bin ich hier auch raus.
Die Fehlersuche bei C, in einer Toolchain und Makefiles haben nun wirklich nix mehr mit PLC zun tun.


Ein Gutes hat der ganze lange Thread.
Ich brauche nun kein schlechtes Gewissen mehr haben weil ich als Elektrokonstrukteur in unserem Konzern ein gutes Stück höher eingruppiert bin als unsere Softwareentwickler und UX-Designer

Viele Grüße
Blockmove

 

[fkrc]

ich versteh nicht mehr worum es hier eigendlich geht.

- der Themenstarter hat halt SEINE Meinung (wie ich es verstehe C ist das non plus ultra). Er scheint aus der PC Ecke zu kommen, und versucht den Rest zu überzeugen, das ER das einzig Wahre Konzept hat.
- der Rest kennt sich halt mehr mit der PLC Programmierung aus , sagen wir mal TIA oder S7 Basis, und haben entsprechend mehr Hintergrundwissen.

Sicher gibt es immer wieder Schnittstellenprobleme zw. PC/IT und/oder PLC´s, aber ehrlich gesagt, macht Das doch den "Kick" aus. Warum soll ich ein monolitisches System nutzen wo "jeder" Hinz und Kunz dran rumpfuschen kann. Gerade bei PLC´s führen "1000" Wege zum Ziel. Jeder so wie er will und kann...

Bisher war ich immer nur Leser, habe Vieles hier im Forum gelernt. aber solch eine Sinnfreie Diskusion, hatten wir das schon mal?

Gruß

Ok jetzt sind wir wohl schon zu weit vom Thema abgedriftet
C/C++ bezeichne ich nicht als das Non-plus-ultra, jedenfalls nicht für PLC-Zwecke.

Monolithische Systeme haben wir eh schon genug, und die "1000 Wege zum Ziel" sind nur zweifelhaft gut.
Ich würde eher 10 leichte Wege bevorzugen, die "einfach funktionieren", anstatt 1000 komplizierte Wege, von denen fast jeder Weg ein unnötiges Gefrickel mit Low-level-Variablen ist.

Dass nicht "jeder Hinz und Kunz" herumpfuschen soll, das sieht mir eher nach einer künstlichen Verkomplizierung für Experten aus, anstatt nach einer tatsächliche notwendigen Komplexität.

 

[fkrc]

Es gibt C++ Programmierer die meinen man muss Automatisierung für Maschinen unbedingt
von Informatiker machen lassen.
Und da gibt es die, die verstanden haben besser die Finger davon zu lassen.

Was jemand studiert hat ist nicht so wichtig.
Aber mit C++ hat das PLC-Thema sowieso nichts zu tun, weil ich C++ für übertrieben komplex halte (obwohl sich das mit C++-20 vielleicht ändert).

 

[Fluffi]

Zuviel Werbung?
-> Hier kostenlos registrieren

Monolithische Systeme haben wir eh schon genug, und die "1000 Wege zum Ziel" sind nur zweifelhaft gut.
Ich würde eher 10 leichte Wege bevorzugen, die "einfach funktionieren", anstatt 1000 komplizierte Wege, von denen fast jeder Weg ein unnötiges Gefrickel mit Low-level-Variablen ist.

Worauf willst du eigentlich hinaus? Willst du herstellerübergreifende Standards in allen Möglichen Bereichen der PLC Programmierung durchsetzen? Dann darfst du gerne anfangen. Dein erster Schritt wäre bei Siemens oder den anderen Vereinen anzurufen und denen das vorzuschlagen. Die freuen sich bestimmt und lassen sich gerne ihr Geschäftsmodell kaputt machen.

 

[fkrc]

Worauf willst du eigentlich hinaus? Willst du herstellerübergreifende Standards in allen Möglichen Bereichen PLC Programmierung durchsetzen? Dann darfst du gerne anfangen. Dein erster Schritt wäre bei Siemens oder den anderen Vereinen anzurufen und denen das vorzuschlagen. Die freuen sich bestimmt und lassen sich gerne ihr Geschäftsmodell kaputt machen.

Ja solche Standards wären vermutlich notwendig, und sind mit OPC UA teilweise eh in Umsetzung (obwohl es unklar ist, wie erfolgreich OPC UA sein wird). Die Artikel ganz zu Beginn des Threads behandeln das Standardisierungs-Thema.

Im übrigen würde ich nicht bei jedem Standardisierungs-Versuch gleich das Business-Modell in Frage stellen.
Vor allem bei Siemens habe ich das Gefühl, dass Kommunikations-Protokolle so stark verschleiert werden, dass sogar die eigenen Produktlinien darunter leiden (und nicht nur irgendwelche Open-Source-Entwickler, die in ihrer Freizeit eine Kommunikations-Library schreiben).

Wenn schlecht gewartete Libraries wie http://snap7.sourceforge.net/ in großen Konzernen zum Einsatz kommen, dann zeichnet das ein trauriges Bild über den Zustand der konzern-internen Kommunikation.
IT-Konzerne wie Microsoft oder Google fahren seit Jahren mit riesigen internen Monorepos und Open-Source-Tools, und ein Blick auf die Aktienkurse deutet nicht darauf hin, dass dadurch das Business-Modell zerstört wird.

 

[Peter Gedöns]

also ich bin ja überzeugt das fkrc die reinkarnation von Mike100 ist.

 

[Mrtain]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich habe nacht 8 Seiten immer noch nicht verstanden, um was es hier eigentlich geht...

 

[Unimog-HeizeR]

Ich habe nacht 8 Seiten immer noch nicht verstanden, um was es hier eigentlich geht...

Bin ich froh, dass es dir genauso geht wie mir...

Ich dichte mir das hier so zusammen:
Ein Supersportwagen-Konstrukteur kommt in ein LKW-Forum und liest hier einige Beiträge.
Daraufhin findet er es eine super Idee, anstatt einem langsamen 40 Tonnen LKW mit tausenden Joghurtbechern
viele kleine Supersportwagen mit je 4 Kartons Joghurt im Kofferraum durch die Lande Fahren zu lassen,
weil das doch viel schneller und effizienter ist.

Habe ich das so richtig verstanden?

Gruß
Timo

 

[ThomasGCH]

Der Thread ist zwar stark vom eigentlichen Thema abgekommen, aber dem ersten Post stimme ich voll und ganz zu.
TIA ist der Grund, warum ich von der Automatisierungsbrache in die IT-Branche wechsle.

 

[fkrc]

Zuviel Werbung?
-> Hier kostenlos registrieren

Bin ich froh, dass es dir genauso geht wie mir...

Ich dichte mir das hier so zusammen:
Ein Supersportwagen-Konstrukteur kommt in ein LKW-Forum und liest hier einige Beiträge.
Daraufhin findet er es eine super Idee, anstatt einem langsamen 40 Tonnen LKW mit tausenden Joghurtbechern
viele kleine Supersportwagen mit je 4 Kartons Joghurt im Kofferraum durch die Lande Fahren zu lassen,
weil das doch viel schneller und effizienter ist.

Habe ich das so richtig verstanden?

Gruß
Timo

Der Thread ist zwar stark vom eigentlichen Thema abgekommen, aber dem ersten Post stimme ich voll und ganz zu.

TIA ist der Grund, warum ich von der Automatisierungsbrache in die IT-Branche wechsle.

Ich würde es so zusammenfassen:
Ein Konstrukteur sieht eine Gruppe von anderen Konstrukteuren, welche von ein paar wenigen Groß-Konstrukteuren geknebelt werden und systematisch daran gehindert werden, effizientere Workflows einzusetzen. Die Lizenzgebühren sind ein Hohn im Vergleich zum Stand der gelieferten Software-Technik.
Ein paar der Konstrukteure werfen entnervt das Handtuch, während viele andere den Status Quo als unveränderlich akzeptieren.

 

[Heinileini]

Ich würde eher 10 leichte Wege bevorzugen, die "einfach funktionieren", anstatt 1000 komplizierte Wege, von denen fast jeder Weg ein unnötiges Gefrickel mit Low-level-Variablen ist.

Wer würde nicht 10 leichte Wege (oder noch lieber einen einzigen) bevorzugen anstelle von 1000 komplizierten?
Aber was stellst Du Dir unter einem "unnötigen Gefrickel" und unter "LowLevelVariablen" vor???

Wohin willst Du die unverzichtbare Ebene des Gefrickels mit LowLevelVariablen outsourcen, damit sich die PLC fortan auf die einzig wichtige Aufgabe konzentrieren kann, den IT-lern das Leben zu erleichtern?

 

[fkrc]

Wer würde nicht 10 leichte Wege (oder noch lieber einen einzigen) bevorzugen anstelle von 1000 komplizierten?
Aber was stellst Du Dir unter einem "unnötigen Gefrickel" und unter "LowLevelVariablen" vor???

Wohin willst Du die unverzichtbare Ebene des Gefrickels mit LowLevelVariablen outsourcen, damit sich die PLC fortan auf die einzig wichtige Aufgabe konzentrieren kann, den IT-lern das Leben zu erleichtern?

PLCs sind keine Mikrocontroller, das Low-level Communication Zeugs hat meiner Meinung nach nichts verloren in der tagtäglichen Projektierungsarbeit.
Da geht's nicht nur um ein "leichteres Leben für die IT", sondern auch um einfachere Projektierungen und Visualisierungen.
Wenn im Jahr 2020 von "absoluten Variablenoffsets" oder "optimierten Bausteinen" gesprochen wird, dann befinden wir uns nicht mehr auf der richtigen Abstraktions-Ebene (in der Informatik würde man das als "Abstraktions-Mismatch" bezeichnen).

Sehen wir es doch ein:
Variablen-Exporte sind keine Rocket Science, genauso wenig wie Versionsverwaltung, Migrationen oder Paketmanager.
Wenn für solche Aufgaben Expertenwissen benötigt wird, dann liegt das nicht an der natürlichen Komplexität des Problems, sondern eher an den verwendeten Tools.