SPS mit C/C++ *ohne* Editor/IDE programmieren

[Blockmove]

Zuviel Werbung?
-> Hier kostenlos registrieren

Das ist sehr entlarvend.
Warum haben Sie es notwendig, V13, 14,15,15.1 parallel zu betreiben?
Die Antwort ist klar: Weil Siemens bei der Rückwärtskompatibilität katastrophal versagt hat. Ich vermute, dass Siemens mit Absicht versagt hat, um mehr TIA-Lizenzgebühren einzunehmen.
Existierende Projekte regelmäßig zu zerschießen ist anscheinend ein beliebter Sport bei den TIA-Entwicklern.

In der IT-Welt würde man Siemens mit dieser Update-Strategie mit hohem Bogen rauswerfen.
Nicht nur das alte C ist stabil, sondern sogar moderne Sprachen wie Kotlin oder Rust sind bereits seit mehreren Jahren stabil.
Und falls es bei Kotlin/Rust doch einmal zu einem Breaking-Change kommt, dann sind das meistens triviale Code-Fixes, wohingegen TIA-Portal bei Projektimporten stupide Fehlermeldung anzeigt, oder eine Aufrüstung auf Gut Glück ausführt.

Gerade vor diesem Hintergrund kann ich nur darüber lachen, wenn TIA-Jünger von Stabilität und Langzeit-Verfügbarkeit reden.

Jetzt wird es aber langsam unsachlich.
Wieviel Versionen vom .NET-Framework gibt es in der Zwischenzeit?
Wie sieht es da mit Rückwärtskompatibilität aus?
Ich hab da auch schon Stunden in der Versionshölle verbracht.
Das selbe Thema gibt es bei anderen Frameworks genauso.

 

[Mike100]

Jetzt wird es aber langsam unsachlich.
Wieviel Versionen vom .NET-Framework gibt es in der Zwischenzeit?
Wie sieht es da mit Rückwärtskompatibilität aus?
Ich hab da auch schon Stunden in der Versionshölle verbracht.
Das selbe Thema gibt es bei anderen Frameworks genauso.

Ich weiß nicht, wie es mit .NET auf DLL-Ebene aussieht, aber zumindest auf Code-Ebene ist C# sehr stabil.
Es ist problemlos möglich, alten C#-Code auf die neueste Version hochzuziehen. Falls es Fehler gibt, dann zeigt mir der C#-Compiler exakt die Position des Fehlers, und der Fix ist meistens trivial. Falls es doch nicht trivial ist, dann hat die C#-Codebasis eine Komplexität, bei welcher es TIA schon hundert Mal zerlegt hätte.

Vergleich mit TIA: Der Code besteht aus obskuren Binärfiles, eine formale Spec ist non-existent, und die Upgrades sind wie ein russisches Roulette-Spiel.

 

[ms_gp]

Zuviel Werbung?
-> Hier kostenlos registrieren

Unsachlich auf jeden Fall. Er ist halt sehr frustriert und desillusioniert. War ich auch damals .

Aber ich stimme ihm in manchen Punkte inhaltlich trotzdem zu, z.B. dass da bei SIEMENS durchaus Absicht dahinterstecken könnte. Betonung auf könnte! Und ja, die Installationsdateien von TIA sind riesig und die Installation dauert ewig. Und man fragt sie wofür, weil soviel steckt da ja gar nicht drin.

SIEMENS hat sich ganz bewusst für ein monolithisches Projekt-System (also wie ein TIA-Projekt Datentechnisch unter der Haube aussieht) entschieden. Und das obwohl es bei Step7 Classic ja nicht so war, da war ja jeder Baustein eine Datei. Und das fällt ihnen jetzt auf die Füße.
Und das meinte ich weiter oben auch damit, dass SIEMENS nicht so offen ist. Ich kann nicht einfach eine einen Baustein exportieren und in ein anderes Steuerungssystem importieren. Obwohl das ja gehen müsste, weil alles toll IEC-61131.
Codesys/Twincat ist genau den anderen Weg gegangen und aus den *.pro Dateien wurde ein Projekt, bei dem jedes Element eine Datei ist.
Und hier kann auch einfach Bausteine im PLCOpen Format exportieren und woanders importieren(außer SIEMENS natürlich).

Das das dann alles XML-Dateien sind, darüber kann ja meckern, aber solange es Text ist, ist es doch Ok für die Versionsverwaltungssysteme.


Aber nicht falsch verstehen. TIA kann man trotzdem produktiv nutzen und es hat auch seine Stärken. Besonders im Safety-Bereich. Aber ein gutes Beispiel für eine ordentliche IDE und ein gutes Programmiersystem ist es eben nicht, weder für SPS Programmierung noch für etwas anderes.

 

[Mike100]

Mit einigen Punkten haben Sie durchaus Recht.

Aber die Ansprache!!!

Ich setze das mal um, wie es bei mir ankam:

"Hallöchen Ihr Schnarchnasen,

ihr programmiert ja alle so schön gruselig mit staubigen Primitiv-IDE. Na ja, programmieren kann man sowas eigentlich nicht nennen, ihr kleinen Stümper, aber ich will mal nicht so sein!
Nun gibt es mal Leute wie mich, die Großen sozusagen, die machen alles auf der Command-Line und pushen dann einfach den Code hoch. Natürlich mache ich nur in C/C++ (hier fehlte übrigens der Link zu Wikipedia, was C/C++ ist!) "

Das ist es, was mir so übersetzt im Gedächtnis geblieben ist. Gaaaanz schlechter Anfang, findest du nicht?
Mit den Reaktionen hast du noch Glück gehabt, würde ich mal sagen. *ROFL*

PS: Vor 30 Jahren hatte ich mal ein Gespräch mit einem Prof. für Automatisierungstechnik an einer Uni. Der meiinte dann auch zu mir: "Wir machen alles in C". Na ja, da wundert mich auch nichts mehr.

Mit dieser Interpretation liegst du nicht so falsch
Aber trotzdem zur Klarstellung:

Ich respektiere SPS-Programmierung als Beruf, weil es jahrelange Expertise und Know-How benötigt.
Die Stärken von SPS-Programmierern liegen in der Industrie und in der Elektrotechnik.
Trotzdem gehe ich soweit zu behaupten, dass die meisten TIA-Jünger von guten IDEs keinen Tau haben, und schon gar nicht von guter Versionskontrolle und Portabilität einen Tau haben.
Wenn ein TIA-Jünger von Stabilität und Robustheit redet, dann kann ich nur darüber lachen.
Codesys- oder Twincat-Benutzer kann ich eher noch ernst nehmen bezüglich IDE.

C/C++ sehe ich übrigens nur als Notlösung. Die optimale Lösung wäre eine moderne IDE und eine moderne Sprache, und natürlich weiterhin Kontaktplan für die Zwecke wo es ausreicht.

 

[wollvieh]

Wo liegen Deine Stärken, was hast Du für eine geniale IDE im Einsatz?
P.S.: Was ist TIA? ;-)

 

[Mike100]

Zuviel Werbung?
-> Hier kostenlos registrieren

Unsachlich auf jeden Fall. Er ist halt sehr frustriert und desillusioniert. War ich auch damals .

Aber ich stimme ihm in manchen Punkte inhaltlich trotzdem zu, z.B. dass da bei SIEMENS durchaus Absicht dahinterstecken könnte. Betonung auf könnte! Und ja, die Installationsdateien von TIA sind riesig und die Installation dauert ewig. Und man fragt sie wofür, weil soviel steckt da ja gar nicht drin.

SIEMENS hat sich ganz bewusst für ein monolithisches Projekt-System (also wie ein TIA-Projekt Datentechnisch unter der Haube aussieht) entschieden. Und das obwohl es bei Step7 Classic ja nicht so war, da war ja jeder Baustein eine Datei. Und das fällt ihnen jetzt auf die Füße.
Und das meinte ich weiter oben auch damit, dass SIEMENS nicht so offen ist. Ich kann nicht einfach eine einen Baustein exportieren und in ein anderes Steuerungssystem importieren. Obwohl das ja gehen müsste, weil alles toll IEC-61131.
Codesys/Twincat ist genau den anderen Weg gegangen und aus den *.pro Dateien wurde ein Projekt, bei dem jedes Element eine Datei ist.
Und hier kann auch einfach Bausteine im PLCOpen Format exportieren und woanders importieren(außer SIEMENS natürlich).

Das das dann alles XML-Dateien sind, darüber kann ja meckern, aber solange es Text ist, ist es doch Ok für die Versionsverwaltungssysteme.


Aber nicht falsch verstehen. TIA kann man trotzdem produktiv nutzen und es hat auch seine Stärken. Besonders im Safety-Bereich. Aber ein gutes Beispiel für eine ordentliche IDE und ein gutes Programmiersystem ist es eben nicht, weder für SPS Programmierung noch für etwas anderes.

Genau das wollte ich ebenfalls sagen, allerdings mit einer schärferen Sprache.
Ich bin bei Leibe kein C-Freak, sondern habe C nur als Notlösung für den Ausstieg aus TIA-ähnlichen IDEs gesehen.

Obwohl TIA für mich das Negativbeispiel Nummer 1 ist, komme ich nicht darum herum, auch gegen Codesys/Twincat herzuziehen.
Die Tatsache, dass einzelne Bausteine exportiert werden können, ist zwar gut und schön, aber keine echte Kompatibilität.
Ein seriöses Baustein-Format müsste über mehrere IDEs unverändert funktionieren, aber daran sind die SPS-Hersteller nicht interessiert.
Und viele TIA-Jünger sind auch damit zufrieden, sich in die Abhängigkeit eines monolithischen Multi-DVD-Downloads mit zweifelhafter Stabilität zu fesseln.

Bereits die Download-Seite von TIA-V15 zeigt, dass Siemens die letzten Jahrzehnte verschlafen hat.
Multi-Gigabyte-Downloads als DVD-Files... Wer bitte verwendet noch DVDs für Softwareinstallationen?!

Und die TIA-Extension-Packs fühlen sich ebenfalls wie aufgeblähte Bruchstücke an, und nicht wie stabile Software.
Sowohl Git-Export als auch TIA-Openness sind eine Farce.
Eine seriöse IDE braucht keinen manuellen Git-Export, sondern funktioniert mit Git ohne manuellen Import/Export-Schritten.
Und TIA-Openness ist ein Inter-Process-Communication-Gefrickele anstatt ein einfaches Handieren von Projektdaten.

 

[Mike100]

Teile meiner Negativ-Infos gegen TIA-Portal beziehe ich auch aus Insider-Informationen.

Ein Ex-Studienkollege von mir hat eine Zeit lang bei Siemens Digital Industries als Entwickler gearbeitet. Er hat ein Hilfs-Tool geschrieben, um gewisse Projekt-Informationen für TIA-Kunden zu analysieren.
Er hat Monate damit verbracht, mit obskuren TIA-Projekt-Binaries zu kämpfen.
Herausgekommen ist ein Tool, welches zwar irgendwie funktioniert hat, aber keine gute User Experience geboten hat.
Das Tool ist niemals zu Kunden ausgeliefert worden, weil die Probleme mit Inkompatibilitäten am Ende den Nutzen überwiegt haben (das Tool war außerhalb von TIA, aber hat TIA-Projekt-Binaries geparsed).
Die Kunden verwenden für diesen Zweck jetzt noch weiterhin Excel-Sheets außerhalb von TIA.

Außerdem habe ich erfahren, dass TIA als monolithisches Monster kaum mehr wartbar ist und Agilität für die Siemens-internen TIA-Devs nur mehr ein Fremdwort ist.
Ich kann mir nicht vorstellen, dass ein Siemens-Entwickler mit gutem Gewissen das Büro verlässt und behauptet: "Wir entwickeln mit TIA eine gute Software".


Mit anderen Worten:
Die Software-Architektur von TIA ist so verzwickt, dass nicht nur Third-Party-Tools bewusst abgewürgt werden, sondern auch Siemens-interne Initiativen zur Innovation abgewürgt werden.
TIA ist in meinen Augen eine Totgeburt und muss mittelfristig abgelöst werden.

 

[zako]

Teile meiner Negativ-Infos gegen TIA-Portal beziehe ich auch aus Insider-Informationen.

Ein Ex-Studienkollege von mir hat eine Zeit lang bei Siemens Digital Industries als Entwickler gearbeitet. Er hat ein Hilfs-Tool geschrieben, um gewisse Projekt-Informationen für TIA-Kunden zu analysieren.
Er hat Monate damit verbracht, mit obskuren TIA-Projekt-Binaries zu kämpfen.
Herausgekommen ist ein Tool, welches zwar irgendwie funktioniert hat, aber keine gute User Experience geboten hat.
Das Tool ist niemals zu Kunden ausgeliefert worden, weil die Probleme mit Inkompatibilitäten am Ende den Nutzen überwiegt haben (das Tool war außerhalb von TIA, aber hat TIA-Projekt-Binaries geparsed).
Die Kunden verwenden für diesen Zweck jetzt noch weiterhin Excel-Sheets außerhalb von TIA.

Außerdem habe ich erfahren, dass TIA als monolithisches Monster kaum mehr wartbar ist und Agilität für die Siemens-internen TIA-Devs nur mehr ein Fremdwort ist.
Ich kann mir nicht vorstellen, dass ein Siemens-Entwickler mit gutem Gewissen das Büro verlässt und behauptet: "Wir entwickeln mit TIA eine gute Software".


Mit anderen Worten:
Die Software-Architektur von TIA ist so verzwickt, dass nicht nur Third-Party-Tools bewusst abgewürgt werden, sondern auch Siemens-interne Initiativen zur Innovation abgewürgt werden.
TIA ist in meinen Augen eine Totgeburt und muss mittelfristig abgelöst werden.

… okay jetzt verstehe ich langsam warum Du hier gar so ablederst. Du hast also einen alten Kumpel, der die Aufgabe hatte ein Tool für TIA zu entwickeln, das aber hinterher unbrauchbar war, weil er anscheinend die Softwarestruktur auch nicht umrissen hat. In dieser Funktion ist er mittlerweile auch nicht mehr (okay entweder wollte man ihn nicht mehr, oder er hat selbst aufgegeben).
Jetzt hat der sich bei Dir also ausgeheult und die spielst jetzt den großen Rächer.

Vielleicht bist Du jetzt noch nicht so alt und erfahren. Aber ich möchte Dir und Deinen Kumpel folgendes mitgeben. Bei neuen Arbeitgebern ledere nicht über Deinen vorherigen Arbeitgeber ab. Das kommt immer schlecht an und wenn man sich dann auch noch selbst mit einigen Aussagen disqualifiziert ist das umso beschämender.

 

[Mike100]

Zuviel Werbung?
-> Hier kostenlos registrieren

… okay jetzt verstehe ich langsam warum Du hier gar so ablederst. Du hast also einen alten Kumpel, der die Aufgabe hatte ein Tool für TIA zu entwickeln, das aber hinterher unbrauchbar war, weil er anscheinend die Softwarestruktur auch nicht umrissen hat. In dieser Funktion ist er mittlerweile auch nicht mehr (okay entweder wollte man ihn nicht mehr, oder er hat selbst aufgegeben).
Jetzt hat der sich bei Dir also ausgeheult und die spielst jetzt den großen Rächer.

Vielleicht bist Du jetzt noch nicht so alt und erfahren. Aber ich möchte Dir und Deinen Kumpel folgendes mitgeben. Bei neuen Arbeitgebern ledere nicht über Deinen vorherigen Arbeitgeber ab. Das kommt immer schlecht an und wenn man sich dann auch noch selbst mit einigen Aussagen disqualifiziert ist das umso beschämender.

Richtig. Er ist nicht gekündigt worden, sondern hat selbst das Handtuch geworfen.

Ein weiteres Siemens-internes Tool, wo ich vom Scheitern weiß, ist eine TIA-Integration mit gewissen Industrierobotern.
Auch hier waren die Gründe ähnlich: Obskure Binary-Files, deren Format sogar innerhalb von Siemens kaum jemand kennt.
Die "Specs" für dieses File-Format ist das "TIA-Persistenz-Layer" aus zigtausenden Zeilen C#-Code. Soll heißen, es gibt keine vernünftige Spec, was auch mit ein Grund für das ständige Zerschießen von TIA-Projekten ist.
Theoretisch könnte man zwar alles reverse-engineeren, aber die reverse-engineerten Tools können bei jedem TIA-Update wieder zerstört werden.

Glaubt ihr, dass Siemens-Entwickler mit diesem Trümmerhaufen besser klarkommen als externe Entwickler?
Die Antwort ist nein, weil sonst würde man nicht die schlecht gewartete Open Source Library "Snap7" innerhalb von Siemens verwenden.

Es dauert Monate, um als Siemens-Entwickler irgendeinen Code ins TIA-Portal zu mergen. Was auch gut ist, weil sonst würde das fragile Kartenhaus in sich zusammenbrechen. Gleichzeitig zeigt sich aber immer stärker, dass das TIA Portal für moderne Anforderungen gescheitert ist.

Das Unix-Prinzip ist: "Do one thing and do it well."
Das TIA-Prinzip ist: "Try everything and do it slow."

BTW: Vielleicht sollten wir diesen Thread ins TIA-Forum verschieben, wäre interessant zu sehen wie die blinden TIA-Jünger reagieren

 

[oliver.tonn]

BTW: Vielleicht sollten wir diesen Thread ins TIA-Forum verschieben, wäre interessant zu sehen wie die blinden TIA-Jünger reagieren

Es wäre schön, wenn Du mal die Keule oder den Holzhammer einpacken würdest und etwas gemäßigter und differenzierter agieren würdest. Falls es Dein Ziel ist von den Admins irgendwann geblockt zu werden bist Du, meiner Meinung nach, auf dem besten Weg. Niemand (zumindest fast) hat hier Probleme mit einer anderen Meinung oder Kritik, aber der Ton macht die Musik.
Ich hoffe diese Aussage ist nicht pauschal gemeint. Die wenigsten halten TIA oder Codesys Derivate für ein Allheilmittel und erkennen auch an, dass die Systeme ihre Schwächen aber auch stärken haben. Völlig nutzlos, wie Du es einem immer weiß machen willst, sind die Systeme definitiv nicht, denn sonnst würden wir damit kein Projekt erfolgreich fertig kriegen und das tun wir definiv.


Von irgendwas mit Internetzugang gesendet.

 

[Blockmove]

Ich hab mal mit 2 Bekannten aus der Embedded-Entwicklung gesprochen und sie gebeten den Thread mal zu lesen.
Einer der beiden macht Software für Baumaschinen, der andere macht viel im Bereich Medizintechnik.
Deren gemeinsames Fazit:
Mike100 hat im Punkt Quellcodeverwaltung und -Versionierung recht, da natürlich die meisten Quellcode-Files reine Textdateien sind.
Sobald aber irgendwelche Bedienoberflächen dazukommen, sieht die Welt wieder anders aus. Hier gibt es diverse Formate (inkl. Bin-Files).
Was die Entwicklngsumgebungen und die Tools angeht, stehen sie hier vor dem genau gleichem Problem wie wir auch.
Um eine Software für ein Produkt (egal ob Kran oder Dosierpumpe für Medikamente) über Jahre zu pflegen und Supporten, müssen beim Make-Prozess immer die gleichen Bin-Files erzeugt werden.
Daher gibt es im Entwicklungsprozess einen Freeze für Entwicklungssystem, eingesetzte Tools, Frameworks und Bibliotheken. Hier wird genauso mit VMs gearbeitet, wie es viele von uns auch tun.


Für mich als SPS'ler stellt es sich so dar, dass die Kollegen eigentlich noch mehr Probleme mit dem Softwareumfeld haben als wir.

Gruß
Blockmove

 

[olliew]

Zuviel Werbung?
-> Hier kostenlos registrieren

Daher gibt es im Entwicklungsprozess einen Freeze für Entwicklungssystem, eingesetzte Tools, Frameworks und Bibliotheken. Hier wird genauso mit VMs gearbeitet, wie es viele von uns auch tun.

Betriebssystem nicht vergessen. Gibt z.B. das eine oder andere Produkt das in den 90'er entwickelt wurde (MS-DOS, klingelt da etwas?) und heute immer noch 'aktiv' ist.

Für mich als SPS'ler stellt es sich so dar, dass die Kollegen eigentlich noch mehr Probleme mit dem Softwareumfeld haben als wir.

Sagen wir mal so, langfristige Verfügbarkeit ist schon etwas feines

 

[Mike100]

Ich hab mal mit 2 Bekannten aus der Embedded-Entwicklung gesprochen und sie gebeten den Thread mal zu lesen.
Einer der beiden macht Software für Baumaschinen, der andere macht viel im Bereich Medizintechnik.
Deren gemeinsames Fazit:
Mike100 hat im Punkt Quellcodeverwaltung und -Versionierung recht, da natürlich die meisten Quellcode-Files reine Textdateien sind.
Sobald aber irgendwelche Bedienoberflächen dazukommen, sieht die Welt wieder anders aus. Hier gibt es diverse Formate (inkl. Bin-Files).
Was die Entwicklngsumgebungen und die Tools angeht, stehen sie hier vor dem genau gleichem Problem wie wir auch.
Um eine Software für ein Produkt (egal ob Kran oder Dosierpumpe für Medikamente) über Jahre zu pflegen und Supporten, müssen beim Make-Prozess immer die gleichen Bin-Files erzeugt werden.
Daher gibt es im Entwicklungsprozess einen Freeze für Entwicklungssystem, eingesetzte Tools, Frameworks und Bibliotheken. Hier wird genauso mit VMs gearbeitet, wie es viele von uns auch tun.


Für mich als SPS'ler stellt es sich so dar, dass die Kollegen eigentlich noch mehr Probleme mit dem Softwareumfeld haben als wir.

Gruß
Blockmove

Ich glaube, dass die Embedded Entwicklung sehr vielfältig ist und daher ein allgemeiner Vergleich nicht möglich ist.
Quellcode-Verwaltung ist mit C natürlich besser als mit TIA-Portal-ähnlichen IDEs.

Make ist zwar ein sehr altes Build-Tool, aber trotzdem noch halbwegs brauchbar. Im Gegensatz zu TIA weiß man bei Make wenigstens was im Hintergrund passiert (nämlich ein Directed Acyclic Graph aus Files mit Last-Modified-Timestamps).

Warum die exakt gleichen Bin-Files produziert werden müssen, ist mir ein Rätsel. So etwas kenne ich nur aus dem Open Source Security Bereich, wo ein kryptografischer Hash den Link zwischen einem Open Source Git-Commit und einem Binary-File garantiert.

Wenn man Tests hat, dann sehe ich eine Änderung der Build-Umgebung als unproblematisch. Ich kann beispielsweise auf eine neue Version des GCC-Compilers upgraden, und wenn alle Tests immer noch passen, dann kann ich mit hoher Sicherheit sagen dass der neue GCC-Compiler funktioniert (für mein Projekt).

Einen "Tool-Freeze" mit VMs halte ich nicht für zielführend. Was soll dadurch gewonnen werden, dass mit historischen Versionen von Make/GCC/Linux gearbeitet wird?
Qualität sollte auf andere Art gesichert werden, und nicht durch einen erzwungenen Total-Stillstand in irgendeiner zehn Jahre alten Linux-Distribution. Wenn "never touch anything" das Hauptmotto ist, dann ist es bezüglich Testabdeckung und Codestrukturierung vermutlich ziemlich dürr.

Abschließend noch zum Thema Bedienoberflächen/Visualisierung:

Ich halte es für sinnvoll, die Visualisierung vom Embedded-Core oder SPS-Programm möglichst gut zu trennen (hinsichtlich Software-Architektur).
Im Gegensatz dazu halte ich den TIA-WinCC-Weg für den falschen Weg hinsichtlich skalierbarer Programmierung in Teams.
Denn auch bei Visualisierungen halte ich obskure Binaries für den falschen Weg.

Dazu passend ein Beispiel aus der Smartphone-Welt:
Apple hat vor kurzem iOS-Storyboards durch iOS-SwiftUI ersetzt. Seitdem können komplexe iOS-Apps mit menschenlesbaren Textfiles programmiert werden, und siehe da: Die Developer Experience ist viel besser als vorher, und fast kein iOS-Dev will jemals zurück zu Storyboards.
SwiftUI und React sind auf einem so hohen Niveau, dass TIA WinCC nicht einmal in einem Paralleluniversum auch nur annähernd mithalten könnte.

Und nachdem Siemens bereits TIA-WinCC, TIA-Openness, TIA-Git-Extensions und TIA-Multiuser hinsichtlich Developer Experience und Robustheit vermasselt hat, weiß ich gar nicht mehr, ob TIA überhaupt zu exzellenten Developer-Tools fähig ist.
Exzellente Developer-Tools funktionieren todsicher und skalieren in großen Teams, während TIA-Tools meistens nur im Happy-Case unter bestimmten Preconditions funktionieren.

 

[Thomas_v2.1]

Warum die exakt gleichen Bin-Files produziert werden müssen, ist mir ein Rätsel. So etwas kenne ich nur aus dem Open Source Security Bereich, wo ein kryptografischer Hash den Link zwischen einem Open Source Git-Commit und einem Binary-File garantiert.

Wenn man Tests hat, dann sehe ich eine Änderung der Build-Umgebung als unproblematisch. Ich kann beispielsweise auf eine neue Version des GCC-Compilers upgraden, und wenn alle Tests immer noch passen, dann kann ich mit hoher Sicherheit sagen dass der neue GCC-Compiler funktioniert (für mein Projekt).

Wenn dir ein Kunde ein Fehler berichtet und du das nachstellen können willst, dann ist es hilfreich die genau gleiche Umgebung zu besitzen mit der das Binary damals erstellt wurde um ggf. bis auf Assembler-Ebene nachvollziehen zu können wo der Fehler liegt. Ein kleines GCC Update nimmt beispielsweise eine Optimierung etwas anders vor, was beim Ergebnis und bei deinen Testfunktionen zwar erst mal das gleiche ergibt, aber unter Umständen zu Seiteneffekten führen kann.

 

[Blockmove]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich glaube, dass die Embedded Entwicklung sehr vielfältig ist und daher ein allgemeiner Vergleich nicht möglich ist.
Quellcode-Verwaltung ist mit C natürlich besser als mit TIA-Portal-ähnlichen IDEs.

Make ist zwar ein sehr altes Build-Tool, aber trotzdem noch halbwegs brauchbar.

Warum die exakt gleichen Bin-Files produziert werden müssen, ist mir ein Rätsel. So etwas kenne ich nur aus dem Open Source Security Bereich, wo ein kryptografischer Hash den Link zwischen einem Open Source Git-Commit und einem Binary-File garantiert.

Wenn man Tests hat, dann sehe ich eine Änderung der Build-Umgebung als unproblematisch. Ich kann beispielsweise auf eine neue Version des GCC-Compilers upgraden, und wenn alle Tests immer noch passen, dann kann ich mit hoher Sicherheit sagen dass der neue GCC-Compiler funktioniert (für mein Projekt).

Einen "Tool-Freeze" mit VMs halte ich nicht für zielführend. Was soll dadurch gewonnen werden, dass mit historischen Versionen von Make/GCC/Linux gearbeitet wird?
Qualität sollte auf andere Art gesichert werden, und nicht durch einen erzwungenen Total-Stillstand in irgendeiner zehn Jahre alten Linux-Distribution.
Wenn "never touch anything" das Hauptmotto ist, dann ist es bezüglich Testabdeckung und Codestrukturierung vermutlich ziemlich dürr.

Wie lange bist du eigentlich schon im Berufsleben und wieviele professionelle / gewerbliche Projekte (egal ob nun PC oder PLC) hast du umgesetzt und über einen langen Zeitraum betreut?
Wenn Software oder Geräte beim Kunden im Einsatz sind, dann musst du Produktpflege und Betreuung machen können.
Genauso wenig wie ich eine Anlage von TIA13 auf TIA16 wegen einer kleinen Änderung hochrüste, aktualisiert mein Bekannter seine Toolchain für ein Steuergerät in einem 8 Jahre alten Autokran.
Bei Medizintechnik ist's noch ne Runde komplexer.

Fazit:
Selbst in Bereichen die mit "richtigen" IDE's arbeiten, mit "richtigen" Programmiersprachen, mit "richtiger" Versionsverwaltung und mit Unit-Tests treten in der Realität genau die selben Themen auf, wie wir sie in der SPS-Welt haben.

 

[Thomas_v2.1]

Nimmt man C die Möglichkeit, malloc auszuführen, dann ist der Vorteil gegenüber ST (SCL) oder Basic (wie es beispielsweise B&R auch noch anbietet) marginal.

malloc ist eine Funktion aus der Standardbibliothek, du kannst dir auch deine eigene malloc Funktion in der SPS nachbilden. Dazu legst du dir z.B. zu Beginn bei einer S7 einen sehr großen Datenbaustein an, und verteilst daraus den Speicher, das ist also keine Sprachbeschränkung sondern nur das Fehlen einer Funktion aus einer Bibliothek. Es gibt aber etliche Konzepte die zum eigentlich sehr beschränkten Sprachumgfang von C gehören, die du in ST nicht hast. Z.B. Funktionszeiger, was es auch erlaubt in C quasi-objektorientiert mit Methoden usw. zu programmieren, in dem in einer einfachen Struct nicht nur Variablen sondern auch Funktionszeiger für die Methoden gespeichert werden (wird von GTK in der Art so gemacht).

Ob man das alles auch in einer SPS haben muss sei dahingestellt. Das beißt sich auch etwas mit dem Online-Ändern von Programmteilen, bzw. wird zumindest schwierig vom unterlagerten Betriebssystem da jeden Zustand zuverlässig abzufangen, wenn über Zeiger Speicheradressen gespeichert werden die sich beim Online-Ändern ändern können.

 

[Mike100]

malloc ist eine Funktion aus der Standardbibliothek, du kannst dir auch deine eigene malloc Funktion in der SPS nachbilden. Dazu legst du dir z.B. zu Beginn bei einer S7 einen sehr großen Datenbaustein an, und verteilst daraus den Speicher, das ist also keine Sprachbeschränkung sondern nur das Fehlen einer Funktion aus einer Bibliothek. Es gibt aber etliche Konzepte die zum eigentlich sehr beschränkten Sprachumgfang von C gehören, die du in ST nicht hast. Z.B. Funktionszeiger, was es auch erlaubt in C quasi-objektorientiert mit Methoden usw. zu programmieren, in dem in einer einfachen Struct nicht nur Variablen sondern auch Funktionszeiger für die Methoden gespeichert werden (wird von GTK in der Art so gemacht).

Ob man das alles auch in einer SPS haben muss sei dahingestellt. Das beißt sich auch etwas mit dem Online-Ändern von Programmteilen, bzw. wird zumindest schwierig vom unterlagerten Betriebssystem da jeden Zustand zuverlässig abzufangen, wenn über Zeiger Speicheradressen gespeichert werden die sich beim Online-Ändern ändern können.

Ich weiß zwar nicht, ob man malloc-ähnliche Funktionen in einer SPS haben will, aber dieses Beispiel ist Teil einer größeren Problematik:
SPS-IDEs haben ein sehr mangelhaftes Dependency-Management-System.
Wenn ich den "Library-Import" in TIA-Portal mit modernen Package-Managern wie NPM, Gradle oder SPM vergleiche, dann bekomme ich bereits beim Zusehen Brechreiz.
Wie stellt sich Siemens eine Aktualisierung von Libraries vor?
Nicht durch einen einfachen Pull von Library-Updates, sondern durch fragile Click-Import-GUIs oder tiefgreifende TIA-Aufrüstungen.

 

[Blockmove]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich weiß zwar nicht, ob man malloc-ähnliche Funktionen in einer SPS haben will, aber dieses Beispiel ist Teil einer größeren Problematik:
SPS-IDEs haben ein sehr mangelhaftes Dependency-Management-System.
Wenn ich den "Library-Import" in TIA-Portal mit modernen Package-Managern wie NPM, Gradle oder SPM vergleiche, dann bekomme ich bereits beim Zusehen Brechreiz.
Wie stellt sich Siemens eine Aktualisierung von Libraries vor?
Nicht durch einen automatisierten Pull von Library-Updates, sondern durch fragile manuelle Import-Steps oder tiefgreifende TIA-Aufrüstungen.

An dem Tag an dem mir eine SPS-Entwicklungsumgebung automatisch Bibliotheken in einem Projekten hochrüstet, fliegt sie von der Platte.
Du hast echt keine Ahnung von Anforderungen und Erfordernissen in Anlagen-, Maschinenbau und Instandhaltung.

 

[Thomas_v2.1]

Wie stellt sich Siemens eine Aktualisierung von Libraries vor?
Nicht durch einen automatisierten Pull von Library-Updates, sondern durch fragile manuelle Import-Steps oder tiefgreifende TIA-Aufrüstungen.

Genau das macht Siemens ja mittlerweile. Eine triviale Funktion wie Scatter (oder auch Gather) welche Bits aus einem Word extrahiert/einbindet wird nicht als Bibliotheksfunktion implementiert, sondern in das Betriebssystem verpflanzt. D.h. wenn du die Funktion verwendet willst, dann musst du ggf. eine neue Steuerung kaufen. Wenn du eine alte Steuerung / TIA Version hast dann kannst du diese Funktion selber nachbilden, dürftest dann aber später in einen Namenskonflikt laufen weil Scatter / Gather durch diese Integration vermutlich zu reservierten Wörtern werden.

 

[Mike100]

An dem Tag an dem mir eine SPS-Entwicklungsumgebung automatisch Bibliotheken in einem Projekten hochrüstet, fliegt sie von der Platte.
Du hast echt keine Ahnung von Anforderungen und Erfordernissen in Anlagen-, Maschinenbau und Instandhaltung.

Du hast mich hier falsch verstanden.
Ich fordere keine automatische Aufrüstung von Bibliotheken, sondern eine manuell getriggerte automatische Aufrüstung.
Dadurch kann ich Minor-Library-Updates mit einem einzigen Kommando einspielen, und habe immer noch die volle Kontrolle darüber.

Tatsächlich hat man mit vernünftigen Package-Managern sogar viel mehr Kontrolle als mit TIA-Portal, weil man einzelne Libraries selektiv updaten kann, anstatt Monster-Updates von TIA hineingewürgt zu bekommen.