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

[ducati]

Zuviel Werbung?
-> Hier kostenlos registrieren

keine Ahnung, was so Eure täglichen Sorgen bei der SPS-Programmierung sind?

Bei mir gehts abgesehen von 10% TIA-Frust, bei 90% um die Automatisuerungsaugabe. Also, wann, warum und wie lange mach ich ein Ventil auf, und wann wieder zu etc...

Da mach ich doch nicht noch freiwillig Extrabaustellen wie Versionsverwaltung oder Multiuserquatsch auf...

Und grundsätzlich ists mir egal, ob die Variablen jetzt absolut, optimiert, Merker oder sonstwas sind...

Wir hatten hier auch mal selbsternannte Informatiker, die haben sich zu 90% ihrer Zeit mit der Versionsverwaltung beschäftigt. Und 10% mit Teamorganisationssoftware.
Achja, nach 5 Jahren war übrigens von ihrer eigentlichen Aufgabe NICHTS erledigt!

 

[Ingmar64]

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

Ich weiß nicht so recht, worauf Du eigentlich raus willst. In den aktuellen Programmierumgebungen wie TIA oder auch Automation Studio sind wir doch weit weg von absoluten Adressen und haben Vollsymbolik. Aber natürlich gibt es für jede angeschlossene Hardware einen speziellen mehr oder weniger komplexen Datentyp, der auch noch von den Hardwareeinstellungen abhängig ist. Da brauche ich keine "absolute Variablenoffsets" mehr, nachdem ich das einmal in der Symboltabelle angelegt habe. Das, was alle Programmierumgebungen wollen, ist den Weg nach unten offen zu halten, denn eine Siemens 300er kann z.B. selbst keine Symbolik, eine 1500er schon. Andererseits wird es ein großes Problem, bewährte Programme und Hardware auszutauschen, bloß weil es eine bessere Programmierumgebung gibt, wie es in der PC-Welt üblich. Abgesehen von Zertifizierungskasten, würde es mich beunruhigen, wenn unsere Atomkraftwerke alle halbe Jahre eine neue Software bekommen mit bis zum Ernstfall unbekannten Schwachstellen!

Irgendwo gab es vor ein paar Jahren mal einen Straßenbahnunfall, weil die Notbremsung wegen dem abgestürzten Bordcomputer nicht funktionierte ...

 

[Ingmar64]

Zuviel Werbung?
-> Hier kostenlos registrieren

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.

Das ist Sache des Programmierers, nicht des Systems.
Gerüchten zufolge gibt es auch in C Variablen, Zeiger, Funktionsaufrufe, ...
Und wie oft stürzt ein C-Programm ab, weil vergessen wurde:
- vor der Verwendung die Variablen zu instanziieren
- Variablen nach Verwendung wieder freizugeben, so daß der Heap nicht überläuft
Das möge jeder für sich ergänzen.

 

[fkrc]

keine Ahnung, was so Eure täglichen Sorgen bei der SPS-Programmierung sind?

Bei mir gehts abgesehen von 10% TIA-Frust, bei 90% um die Automatisuerungsaugabe. Also, wann, warum und wie lange mach ich ein Ventil auf, und wann wieder zu etc...

Da mach ich doch nicht noch freiwillig Extrabaustellen wie Versionsverwaltung oder Multiuserquatsch auf...

Und grundsätzlich ists mir egal, ob die Variablen jetzt absolut, optimiert, Merker oder sonstwas sind...

Wir hatten hier auch mal selbsternannte Informatiker, die haben sich zu 90% ihrer Zeit mit der Versionsverwaltung beschäftigt. Und 10% mit Teamorganisationssoftware.
Achja, nach 5 Jahren war übrigens von ihrer eigentlichen Aufgabe NICHTS erledigt!

Nicht du sollst die genannten Extra-Baustellen lösen, sondern die Hersteller von Engineering-Software.
Schön und gut, dass dir die Engineering-Software persönlich egal ist, aber es gibt andere Leute, welche sich um diese Optimierung kümmern (sollten).
Wenn dich das Thema nicht interessiert, dann musst du den Thread ja nicht lesen.
Ich selbst bin sehr genervt, wenn ich mit schlechter Engineering-Software arbeiten muss, aber das ist nur meine persönliche Einstellung.

Übrigens: Die genannten Informatiker sind in einem kleinen Team vielleicht deplatziert, aber könnten in großen Teams potentiell sehr viel zu Qualität beitragen.

 

[Peter Gedöns]

N
Übrigens: Die genannten Informatiker sind in einem kleinen Team vielleicht deplatziert, aber könnten in großen Teams potentiell sehr viel zu Qualität beitragen.

Wie jetzt ein Informatiker allein kann nix , 2 Informatiker auch nicht.
wie groß muß das das Team sein ? Damit einer dabei ist der was kann und für die restlichen Dampfplauderer im Team arbeitet.

 

[fkrc]

Zuviel Werbung?
-> Hier kostenlos registrieren

Wie jetzt ein Informatiker allein kann nix , 2 Informatiker auch nicht.
wie groß muß das das Team sein ? Damit einer dabei ist der was kann und für die restlichen Dampfplauderer im Team arbeitet.

Wir driften jetzt schon sehr stark von sachlichen Argumenten ab.
Gemeint war, dass ein spezielles "Developer-Tools-Team" ein Vorteil für größere Unternehmen sein kann, aber für kleine Unternehmen nicht leistbar ist.

Der springende Punkt ist, dass Probleme wie Versionskontrolle hocheffizient gelöst werden könnten, wenn es die Hersteller nur wollten. Dafür würde es keine "Dampfplauderer" brauchen, sondern einfach nur bessere Developer-Tools. Diesen Willen zur Besserung sehe ich bei TIA-Openness aber keineswegs, ein Import/Export ist nämlich keine gute Versionskontrolle für Programmierer. Programmierer sind nämlich typischerweise effizienter, wenn sie direkt auf den versionierten Files arbeiten, anstatt XML-Exporte zu machen.

 

[Fluffi]

Da hier so auf den PLC Bereich rumgehakt wird, könnte man genauso gut aber auch den Spieß umdrehen. Ich habe Jahrelang im Embedded Bereich mit C gearbeitet. Auch wenn ich die Sprache sehr schätze, möchte ich mittlerweile eigentlich fast nicht mehr zurück.
Warum? Weil hier wiederum die ganzen Vorzüge aus der PLC Welt fehlen, die das Programmieren effizienter und produktiver machen. Mit einer PLC macht man es einfach und ist fertig, hier endet selbst die kleinste Aufgabe in einem unendlichen Rumgefrickel, um es mal etwas überspitzt zu formulieren.
Das Debugging ist eine Katastrope, man kann sich irgendeinen Müll zusammenkompilieren, Zeigersprünge ins Nirvana, keine online Änderungen am System, keine Datenhandling wie mit DBs, kein HW-Handling in der IDE, natürlich nicht sowas wie unterschiedlichen Sprachen im Programm, die IDE ist quasi nur da um den Code rüberzuschubsen, usw. Die Liste ist wirklich unendlich lang. Und auch keine einheitlichen Standards bei den versch. Systemen in jeglicher Hinsicht weit und breit.
Daher könnte man genauso gut sagen, dass dieser Bereich sich mal an die PLC Standards und Errungenschaften anpassen könnte. Nur mal so als Einwurf.

 

[Peter Gedöns]

der springende Punkt ist , du verzapft hier wieder genau das selbe wie unter deinem alten Account.

ich sach dir Mal wie ich das sehe .
Als Entwickler bei Siemens ist die wohl nahegelegt worden zu gehen , da kam das gefassel von Mike100 hier im Forum
dann hattest du scheinbar einen neuen Job , bist ihn aber wieder los , weil kein PLC Projekt fertig wurde da du lieber über die IDE jammerst . das hat uns dann diesen Thread eingebracht

 

[fkrc]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich weiß nicht so recht, worauf Du eigentlich raus willst. In den aktuellen Programmierumgebungen wie TIA oder auch Automation Studio sind wir doch weit weg von absoluten Adressen und haben Vollsymbolik. Aber natürlich gibt es für jede angeschlossene Hardware einen speziellen mehr oder weniger komplexen Datentyp, der auch noch von den Hardwareeinstellungen abhängig ist. Da brauche ich keine "absolute Variablenoffsets" mehr, nachdem ich das einmal in der Symboltabelle angelegt habe. Das, was alle Programmierumgebungen wollen, ist den Weg nach unten offen zu halten, denn eine Siemens 300er kann z.B. selbst keine Symbolik, eine 1500er schon. Andererseits wird es ein großes Problem, bewährte Programme und Hardware auszutauschen, bloß weil es eine bessere Programmierumgebung gibt, wie es in der PC-Welt üblich
.

Im Falle von Siemens sehe ich es als großen Fehler, dass TIA den S7-300er-Ballast mitgeschleppt hat.
Bitte nicht falsch verstehen: Die S7-300 ist ein grundsolides System, aber hat meiner Meinung nach in moderner Engineering-Software nichts mehr verloren.
Ich sehe Backwards-Compatibility selbstverständlich als sehr wichtig, aber ich sehe nicht ein, warum man es nicht einfach bei Step7-Classic belassen hat können, anstatt zwanghaft das TIA-Portal aufzublähen.

Abgesehen von Zertifizierungskasten, würde es mich beunruhigen, wenn unsere Atomkraftwerke alle halbe Jahre eine neue Software bekommen mit bis zum Ernstfall unbekannten Schwachstellen!
Irgendwo gab es vor ein paar Jahren mal einen Straßenbahnunfall, weil die Notbremsung wegen dem abgestürzten Bordcomputer nicht funktionierte ...

Für bereits laufende Kraftwerke gibt es nicht viele Anreize, eine existierende PLC-Software auszutauschen.
Wenn ich aber ein neues Kraftwerk komplett neu projektieren würde, dann würde ich selbstverständlich auf moderne Software setzen.

 

[fkrc]

der springende Punkt ist , du verzapft hier wieder genau das selbe wie unter deinem alten Account.

ich sach dir Mal wie ich das sehe .
Als Entwickler bei Siemens ist die wohl nahegelegt worden zu gehen , da kam das gefassel von Mike100 hier im Forum
dann hattest du scheinbar einen neuen Job , bist ihn aber wieder los , weil kein PLC Projekt fertig wurde da du lieber über die IDE jammerst . das hat uns dann diesen Thread eingebracht

Das sind jetzt wilde Fantasien, mit denen hier spekuliert wird
Weder habe ich einen Zweit-Account, noch weiß ich, wer "Mike100" sein soll.

 

[fkrc]

Da hier so auf den PLC Bereich rumgehakt wird, könnte man genauso gut aber auch den Spieß umdrehen. Ich habe Jahrelang im Embedded Bereich mit C gearbeitet. Auch wenn ich die Sprache sehr schätze, möchte ich mittlerweile eigentlich fast nicht mehr zurück.
Warum? Weil hier wiederum die ganzen Vorzüge aus der PLC Welt fehlen, die das Programmieren effizienter und produktiver machen. Mit einer PLC macht man es einfach und ist fertig, hier endet selbst die kleinste Aufgabe in einem unendlichen Rumgefrickel, um es mal etwas überspitzt zu formulieren.
Das Debugging ist eine Katastrope, man kann sich irgendeinen Müll zusammenkompilieren, Zeigersprünge ins Nirvana, keine online Änderungen am System, keine Datenhandling wie mit DBs, kein HW-Handling in der IDE, natürlich nicht sowas wie unterschiedlichen Sprachen im Programm, die IDE ist quasi nur da um den Code rüberzuschubsen, usw. Die Liste ist wirklich unendlich lang. Und auch keine einheitlichen Standards bei den versch. Systemen in jeglicher Hinsicht weit und breit.
Daher könnte man genauso gut sagen, dass dieser Bereich sich mal an die PLC Standards und Errungenschaften anpassen könnte. Nur mal so als Einwurf.

Ich kann dir voll und ganz zustimmen, und zwar aus folgendem Grund:
Der "Embedded Bereich" ist historisch von schlechten und veralteten Toolchains aus dem Jahre Schnee geplagt worden.
Oft hat es abgesehen von historischen C-Compilern und minimalsten "IDEs" fast gar keine Tools gegeben, geschweige denn irgendwelche brauchbaren Debugger.
Abgesehen davon ist C zwar eine extrem erfolgreiche Sprache für die System-Programmierung, aber für die Entwicklung von Endanwendungen bei weitem nicht mehr zeitgemäß (auch nicht für PLC-Anwendungen).

Bereiche wie Web-Frontend, Web-Backend, DevOps, IoT sind oder waren den historischen Embedded-Toolchains teilweise massiv überlegen.
Allerdings glaube ich, dass sich auch der Embedded-Bereich mittlerweile modernisiert, sodass Themen wie Debugging nicht mehr so eine große Katastrophe sind.

 

[fkrc]

Zuviel Werbung?
-> Hier kostenlos registrieren

Das ist Sache des Programmierers, nicht des Systems.
Gerüchten zufolge gibt es auch in C Variablen, Zeiger, Funktionsaufrufe, ...
Und wie oft stürzt ein C-Programm ab, weil vergessen wurde:
- vor der Verwendung die Variablen zu instanziieren
- Variablen nach Verwendung wieder freizugeben, so daß der Heap nicht überläuft
Das möge jeder für sich ergänzen.

Zugegebenerweise würde ich C nicht gerade als "Referenz" für moderne Systeme sehen.
C ist eine historisch extrem erfolgreiche Sprache für die System-Programmierung, aber für die Entwicklung von Endanwendungen bei weitem nicht mehr zeitgemäß (auch nicht für "PLC-Endanwendungen").

 

[Fluffi]

Der "Embedded Bereich" ist historisch von schlechten und veralteten Toolchains aus dem Jahre Schnee geplagt worden.

Da hat sich nicht viel getan. Klar, als IDE für den Code an sich nimmt man heute VS und ähnliches, das ist modern, aber alles drüber hinaus und der gesamte Workfow drumherum inkl. dem Debugger-Chaos ist gefühlt in den 90ern stehengeblieben. Hier gibt es zwar, zumindest an einigen Stellen, deine "Standards" aber dafür den Rest nicht. Evtl weil es eben eben offen ist und nicht von einzelnen Big-Playern angetrieben wird. Da programmiere ich lieber PLCs und nehme in Kauf dass so geschlossene Systeme wie TIA eine saubere Versionsverwaltung und ein paar andere brauchbare Dinge unverständnisserweise (noch) nicht können. Genau darum arbeite ich auch nicht mehr mit C auf µControllern. Sich jahrelang in unnützem Pseudo-Expertenwissen verlieren und sich die Weltmeisterschaft im "wer kann die kryptischsten Zeigerkonstruktionen entwerfen" holen? Verschenkte Zeit, das bringt einen nicht weiter und danken tuts einem auch keiner. Im PLC-Automationbereich kann man was sinnvolles auf die Beine stellen und zudem auch deutlich anspruchsvollere Aufgaben programmieren und in vielen Nebenbereichen Experte werden. Ich kann mir vorstellen dort (in vielen Jahren) auch noch mit weit über 50 zu coden und arbeiten, weil hier trotz der vielen Kritikpunkte an TIA und Co (und dieses Forum ist voll davon), doch einiges richtig läuft. Alles hat eben seine zwei Seiten.

 

[fkrc]

Da hat sich nicht viel getan. Klar, als IDE für den Code an sich nimmt man heute VS und ähnliches, das ist modern, aber alles drüber hinaus und der gesamte Workfow drumherum inkl. dem Debugger-Chaos ist gefühlt in den 90ern stehengeblieben. Hier gibt es zwar, zumindest an einigen Stellen, deine "Standards" aber dafür den Rest nicht. Evtl weil es eben eben offen ist und nicht von einzelnen Big-Playern angetrieben wird. Da programmiere ich lieber PLCs und nehme in Kauf dass so geschlossene Systeme wie TIA eine saubere Versionsverwaltung und ein paar andere brauchbare Dinge unverständnisserweise (noch) nicht können. Genau darum arbeite ich auch nicht mehr mit C auf µControllern. Sich jahrelang in unnützem Pseudo-Expertenwissen verlieren und sich die Weltmeisterschaft im "wer kann die kryptischsten Zeigerkonstruktionen entwerfen" holen? Verschenkte Zeit, das bringt einen nicht weiter und danken tuts einem auch keiner. Im PLC-Automationbereich kann man was sinnvolles auf die Beine stellen und zudem auch deutlich anspruchsvollere Aufgaben programmieren und in vielen Nebenbereichen Experte werden. Ich kann mir vorstellen dort (in vielen Jahren) auch noch mit weit über 50 zu coden und arbeiten, weil hier trotz der vielen Kritikpunkte an TIA und Co (und dieses Forum ist voll davon), doch einiges richtig läuft. Alles hat eben seine zwei Seiten.

Das kann ich sehr gut verstehen, mit derartigen uControllern würde ich auch nicht arbeiten wollen.
Mit den heutigen 32-Bit-uController ist es ja vollkommen absurd, auf welcher viel zu tiefen Abstraktionsebene sich manche Embedded-Projekte bewegen.
Wenn das Expertenwissen darin besteht, eine miserable Toolchain zu meistern, dann kann ich auf dieses Expertenwissen gut verzichten.
Vermutlich trifft ein gewisser Teil dieses Threads auch auf den "Embedded-Bereich" zu, aber die Probleme sind andere.
Während Tools wie TIA Schwachpunkte in Bereichen wie Versionskontrolle haben, gibt es im "Embedded-Bereich" teilweise nicht einmal ordentliche Debugging-Tools.

Eventuell ist die Toolchain-Situation im Embedded-Linux-Bereich für IoT-Devices besser.

 

[Faceman]

Zuviel Werbung?
-> Hier kostenlos registrieren

....Für bereits laufende Kraftwerke gibt es nicht viele Anreize, eine existierende PLC-Software auszutauschen.
Wenn ich aber ein neues Kraftwerk komplett neu projektieren würde, dann würde ich selbstverständlich auf moderne Software setzen.

Das klingt ja hoch kompetent von dir. Dir ist schon klar, dass Kraftwerke > 50 Jahre in Betrieb sind und am Netz hängen. Dass gerade da nach bestimmter
Zeit ein Anreiz besteht, die PLC zu modernisieren leuchtet vermutlich auch einem Kleinkind ein. Stichwort Produktauslauf, Abkündigung, Streichung Ersatzteileservice und Reparatur.
Außerdem ändern sich in diesen 50 Jahren auch bestimmte Anforderungen oder es wird einiges nachgerüstet wie Filteranlagen, Prozesssysteme...

Also vielleicht mal nachdenken bevor man schreibt. Danke

 

[MFreiberger]

Moin,

Das klingt ja hoch kompetent von dir. Dir ist schon klar, dass Kraftwerke > 50 Jahre in Betrieb sind und am Netz hängen. Dass gerade da nach bestimmter
Zeit ein Anreiz besteht, die PLC zu modernisieren leuchtet vermutlich auch einem Kleinkind ein. Stichwort Produktauslauf, Abkündigung, Streichung Ersatzteileservice und Reparatur.
Außerdem ändern sich in diesen 50 Jahren auch bestimmte Anforderungen oder es wird einiges nachgerüstet wie Filteranlagen, Prozesssysteme...

Also vielleicht mal nachdenken bevor man schreibt. Danke

Genau.

Außerdem muss eine Steuerung >10 Jahre im Feld eingesetzt worden sein, bevor sie für (Atom-)kraftwerke zugelassen wird. Also ist die eingesetzte Software schon mindestens Entwicklungszeit+10 Jahre "alt" oder halt "bewährt". Wie modern kann die Software da sein?

 

[fkrc]

Moin,
Genau.

Außerdem muss eine Steuerung >10 Jahre im Feld eingesetzt worden sein, bevor sie für (Atom-)kraftwerke zugelassen wird. Also ist die eingesetzte Software schon mindestens Entwicklungszeit+10 Jahre "alt" oder halt "bewährt". Wie modern kann die Software da sein?

Ich habe mich in diesem Thread eher auf Versionskontrolle und Package-Manager bezogen, für diese zwei Zwecke gibt es bereits mehr als zehn Jahre alte und robuste Lösungen.
Selbstverständlich ist es auch möglich, dass eine Engineering-Software "moderner" ist als die eingesetzte Steuerung, gerade deshalb weil die Engineering-Software weniger kritisch für den laufenden Betrieb ist.

Schlussendlich braucht es auch einen vernünftigen Tradeoff zwischen "Modernheit" und "Bewährtheit".
Im Embedded-Bereich wird es mit "Bewährtheit" zum Teil übertrieben, wenn ein uController mit C-Compilern aus den Anfangszeiten von Dennis Ritchie programmiert wird.

 

[Thomas_v2.1]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich habe mich in diesem Thread eher auf Versionskontrolle und Package-Manager bezogen, für diese zwei Zwecke gibt es bereits mehr als zehn Jahre alte und robuste Lösungen.

Zu Versionskontrolle gibt es nichts neues zu sagen, das ist auch hier im Forum ein alter Hut. Bei Software mit Stückzahl Anzahl 1 und Entwickler Anzahl 1 ist eine externe Versionskontrolle auch nicht so wichtig. Hier reicht für mich ein Backup und die Vergleichsfunktion in der Entwicklungssoftware.

Zu deinem "Package-Manager" würde ich gerne mal ein konkretes Beispiel hören, an welcher Stelle in einem Automatisierungsprojekt du wie und welche Pakete mit welcher Funktion einbinden würdest, und welchen Vorteil du dir dadurch erhoffst.

 

[Mrtain]

Klingt für mich schwer nach Bibliothek, oder liege ich da falsch?

 

[Thomas_v2.1]

Klingt für mich schwer nach Bibliothek, oder liege ich da falsch?

Bibliotheken gibt es ja schon. Paketmanager laden üblicherweise auch alle ggf. notwendigen Abhängigkeiten nach. Ob das bei der SPS-Programmierung so benötigt wird ist meine Frage. Üblicherweise gibt es dort nur sehr wenig Abhängigkeiten von Bibliotheken, im Gegensatz zur "Frontend" Entwicklung wo er tätig ist.

Seit 10 Seiten gibt es hier Buzzword-Bingo, aber überhaupt nichts konkretes was er da vor hat zu ändern, wenn man schon so so groß kritisiert. Ist ja nicht so dass bei er SPS-Programmierung alles 100%ig ist, aber einen Paketmanager um da irgendwelche Bibliotheken aus dem Internet nachzuladen wie bei npm, habe ich bisher noch nicht vermisst. Eine gut gepflegte Bibliothek wie Oscat wäre mir schon ausreichend. Die packe ich halt ins Projekt (Step7) oder linke sie dazu (Codesys) und dann kann ich diese verwenden.