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

Zuviel Werbung?
-> Hier kostenlos registrieren
Die Realität sieht doch so aus: Dem Kunden ist IDE mit der programmiert wird, schnurzpiepe egal. Der will nur, dass seine Anlage funktioniert und das möglichst ohne Ausfall. Und wenn der Kunde unbedingt Siemens haben will, dann programmiert man halt die Anlage mit Siemens und deren IDE.
Vielleicht läuft der Hersteller XYZ Siemens irgendwann den Rang ab, dann programmieren wir halt Anlagen mit Steuerungen von XYZ und deren IDE.

Wir sind in erster Linie alle Angestellte / Dienstleister. Und den Luxus, den eigenen Kopf gegenüber unseren Kunden durchzusetzen kann man sich selten leisten.

Im Falle von TIA halte ich das für ein sehr stupides Mindset. Warum sollte ich als Kunde die Verwendung einer schlechte IDE erzwingen, wenn es keine Vorteile bringt sondern nur Nachteile für die Entwicklung und Wartung (zb. ständige Zerstörung der Binary-Kompatibilität bei TIA)?

Welcher seriöser Kunde will ein System einsetzen, welches nur mit VMs und veralteten TIA-Versionen noch am Leben gehalten werden kann? Die sogenannte "Bit-Verrottung" setzt bei TIA nicht nach Jahren ein, sondern bereitets nach wenigen Monaten. Es ist naiv, als langfristig denkender Kunde darauf zu setzen.

Ja, ich verstehe es natürlich, dass manche Kunden von Siemens-Hardware abhängig sind.
Für viele Aufgaben macht es aber keinen Sinn, stupide auf TIA zu setzen, außer man hat Programmierer welche nur TIA können und nichts anderes.

Oder anders gesagt: Warum sollten Leute über IDEs entscheiden, welche erstens keinen Dunst davon haben und zweitens die IDEs nie verwenden?
Ein vernünftiger Kunde setzt auf das, was für die Entwickler am effizientesten funktioniert und die Anforderungen erfüllt. Und von Effizienz ist TIA weit entfernt, wie in diesem Thread lang und breit dargelegt wird.
 
Zuletzt bearbeitet:
Das Argument ist oft, dass das Personal des Kunden in einem System geschult ist. Und das ist oft Siemens, weil die so clever waren dafür zu sorgen, dass an den berufschulen das SIEMENS System Standard ist. Die kennen dann gar ni hts anderes.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Das Argument ist oft, dass das Personal des Kunden in einem System geschult ist. Und das ist oft Siemens, weil die so clever waren dafür zu sorgen, dass an den berufschulen das SIEMENS System Standard ist. Die kennen dann gar ni hts anderes.

Richtig, das halte ich auch für das wichtigste Pro-TIA-Argument.
Ganz nach dem Motto: "Was der Bauer nicht kennt, frisst er nicht".
Ebenfalls halte ich es für sinnvoll, dass Berufsschüler die IDEs der Industrie diktieren (also Leute, welche noch nie im Leben mit einer vernünftigen IDE gearbeitet haben, geschweige denn programmieren können).


Ok jetzt im Ernst:
Das ist ebenfalls ein Zeichen für Lobbyismus und Marktversagen. Marktversagen ist es, wenn eine miserable Software durch Keiler-Strategien jahrelang die Qualität nach unten zieht und die Kosten nach oben drückt.
 
Zuletzt bearbeitet:
Das Argument ist oft, dass das Personal des Kunden in einem System geschult ist. Und das ist oft Siemens, weil die so clever waren dafür zu sorgen, dass an den berufschulen das SIEMENS System Standard ist. Die kennen dann gar ni hts anderes.

Ich kenne einen Hochschuldozenten, der ein Automatisierungspraktikum leitet. Dort haben z.B. die Studenten die freie Wahl zwischen Beckhoff und SIEMENS (TIA Portal). Ich haben ihn mal gefragt, womit die Studenten lieber arbeiten. Da kam dann die Antwort: SIEMENS
Ist wohl intuitever. Ich kenne bei SIEMENS auch die SIMOTION- Steuerung. Dieses vielleicht von den Programmierung / Task- System vielleicht näher an TWINCAT und kann z.B. auch objektorientiert programmiert werden, hatte auch immer wieder Features die erst später bei der SIMATIC nachgezogen geholt wurden. Die Kunden haben wohl eine SIMATIC am liebsten.
 
Zuletzt bearbeitet:
Im Falle von TIA halte ich das für ein sehr stupides Mindset.

Das einzig stupide in deiner scheinbar endlosen Troll-Aktion hier ist dein rumgeheule, wie schlecht und veraltet doch die SPS-Welt. Da du ja anscheinend der Programmiergott schlechthin bist, frage ich mich mittlerweile, warum du offensichtlich an TIA / St bzw. SCL scheiterst, wenn doch zig tausend Leute trotz der Probleme damit funktionierende Anlagen auf die Beine stellen?

Oder anders gesagt: Warum sollten Leute über IDEs entscheiden, welche erstens keinen Dunst davon haben und zweitens die IDEs nie verwenden?
Ein vernünftiger Kunde setzt auf das, was für die Entwickler am effizientesten funktioniert und die Anforderungen erfüllt. Und von Effizienz ist TIA weit entfernt, wie in diesem Thread lang und breit dargelegt wird.

Vielleicht weil diese Leute darüber entscheiden, ob man den Auftrag bekommt oder nicht.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Nur weil man mit ST/SCL nicht umzugehen weiß, bedeutet es noch lange nicht, dass es keine guten Sprachen für die SPS Programmierung sind...

ich wüsste auch nicht was für einen Gewinn man hätte wenn man statt SCL C# und Co verwenden könnte. Die Funktionen würden ja grundsätzlich die gleichen bleiben.
diese Hochsprachen müssten für eine robuste SPS Umgebung derart beschnitten werden dass eh am ende wieder SCL dabei rauskommt. Oder erwartet hier wirklich einer das man z.B. jemals wird Arbeitsspeicher dynamisch allozieren können?
Die Robustheit einer SPS Software kommt nicht nur durch den Programmierer, sondern auch durch die sehr restriktiven Einschränkungen der Codebasis und ich denke das ist auch ganz okay so.
Wer mehr will, nimmt sich einen Industrie Raspberry und hängt da ein paar ET200sp Anschaltungen dran, und schon ist er Herr über alles inklusive Kernschmelze wenn notwendig.

Die Schwäche bei TIA ist definitiv nicht die Einschränkung der Sprachen.
 
Ich denke der Frust beim Endkunden wird mit den Jahren wachsen. Der Vorteil von Siemens ist neben guter Dokumentation eine wirklich gute Lieferfähigkeit. Ich bekomme auch nach Jahren noch Teile für meine Steuerung von nahezu einem Tag zum anderen. Das ist für den Endkunden sehr wichtig.

Aber das nutzt einem natürlich nichts mehr, wenn die Teile nur mechanisch passen. Bekomme ich auf das neue Teil meine alte Firmenware? Muss ich die alte Anlage hochrüsten? Das möchte sich doch niemand antun.
 
ich wüsste auch nicht was für einen Gewinn man hätte wenn man statt SCL C# und Co verwenden könnte. Die Funktionen würden ja grundsätzlich die gleichen bleiben.
diese Hochsprachen müssten für eine robuste SPS Umgebung derart beschnitten werden dass eh am ende wieder SCL dabei rauskommt. Oder erwartet hier wirklich einer das man z.B. jemals wird Arbeitsspeicher dynamisch allozieren können?
Die Robustheit einer SPS Software kommt nicht nur durch den Programmierer, sondern auch durch die sehr restriktiven Einschränkungen der Codebasis und ich denke das ist auch ganz okay so.
Wer mehr will, nimmt sich einen Industrie Raspberry und hängt da ein paar ET200sp Anschaltungen dran, und schon ist er Herr über alles inklusive Kernschmelze wenn notwendig.

Die Schwäche bei TIA ist definitiv nicht die Einschränkung der Sprachen.

Ich gebe zu: Go und C# kann ich mir ohne dynamischer Speicherallokation nur sehr schwer vorstellen. Falls man den Garbage Collector eliminiert, dann könnte es eventuell trotzdem funktionieren.

C++20 könnte theoretisch auch funktionieren. Allerdings sind viele Features von C++ übermäßig komplex, und auch der C++-Compiler ist eigentlich zu komplex.

Es sollte eine Sprache ohne "Raw Pointer" wie in C sein, aber auch ohne Garbage Collector wie in Java.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Dazu passend noch ein paar Insider-Infos:

TIA-Portal ist großteils in C# programmiert, und enthält ein paar native DLLs aus C/C++.
TIA-Portal ist eines der größten C#-Projekte der Welt, wenn nicht sogar das größte (im Bezug auf Codemenge).
Eine große Codemenge führt aber nicht notwendigerweise zu einem guten Produkt, ganz im Gegenteil.

Im Falle von TIA wird viel Code für die Kompatibilität mit veralteten Produktlinien und obskuren Protokollen verwendet.
Eine lange Zeit gültige SW-Design-Richtlinie bei Siemens war: "Es darf ruhig komplex sein, weil es soll ohnehin nur für unsere eigenen Produkte funktionieren".
Diese ausufernde Komplexität fällt Siemens jetzt auf den Kopf.

Zusätzlich wird sehr viel Code für "einfache" IDE-Features benötigt, welche mehr schlecht als recht gelungen sind.
Eine gute IDE zu implementieren ist sehr, sehr komplex. Ich behaupte, dass ein großer Teil der IDE-Projekte daran scheitert, mit den weltbesten Top-IDEs mitzuhalten.
Daher wäre es besser, wenn Siemens eine der Top-IDEs lizenzieren würde (zb. JetBrains, Microsoft) und sich stattdessen auf die industriellen Kernkompetenzen konzentriert.

Als Software-Architekt sehe ich nur eine tragfähige Lösung:
Siemens muss TIA-Portal auslaufen lassen und durch eine moderne Plattform ersetzen.

- Diese moderne Plattform sollte nicht "from scratch" entwickelt werden, sondern auf einer der Top-IDEs aufsetzen.
- Bei den Themen Package Manager/Dependency Management/Source Control/statische Codeanalyse sollte Siemens auf den weltbesten Open-Source-Tools aufbauen, weil die derzeitigen Siemens-Tools grottenschlecht sind (das was TIA macht würde ich nicht einmal als Dependency Management bezeichnen).
- Der monolithische Ansatz von TIA muss in die Tonne getreten werden. Stattdessen soll die Build-Chain modular sein, um die Robustheit zu verbessern und Skripte schreiben zu können.
- Das Projekt-Format soll aus menschenlesbaren Text-Files bestehen, und Breaking-Changes sollen nur nach sorgfältiger Abwägung mit einfachen Migrations-Pfaden gemacht werden.
- Die S7-300 soll von der neuen Plattform nicht mehr unterstützt werden. Um Fortschritt zu erzielen, muss man irgendwann einen Cut machen.

Das kann ich fast alles unterschreiben und das erzähle ich spätestens seit V13 (Seitdem ich das produktiv einsetzte).
S7 300 in TIA war nach meinen Infos nicht geplant, sondern ein MUSS des Marketings und hatte tatsächlich großen Anteil and er Katastrophe. Völlig unverständlich.

Leider fürchte ich, wir werden nichts Neues bekommen und vor allem nichts Besseres.
Denke es geht in Richtung Cloud, Cloud-Dienste. Siemens hat Schiß, dass sie Ihre spezailhardware (PLC etc.) nicht mehr verkauft bekommen, weil all das auf irgendwelchen Computern, Controllern oder in der Cloud läuft. Daher kommt es wohl auch, dass immer mehr Kleinkram mit einer License verkauft wird. Irgendwann verkauft man nur noch Software und License. Die Entwicklung ist sicherlich auch bedenklich, ich halte sie für fatal.

Ich hätte gerne ien IDE, die die Sprachelemente KOP/FUP/SCL/Graph enthält. Ich will mich möglichst ohne C/C++ oder andere Sprachkenntnisse um die Programmierung von Maschinen kümmern. Die müssen funktionieren und zwar tadellos! Code-Testfunktionen wären schon nett, aber wohl nur für SCL sinnvoll, wenn überhaupt. Ist sicherlich schwierig umzusetzen, denn da hängt ja i.d.R. noch ein Bus und externen Hardware dran.

PS: AWL war nie schlecht. Es war Anfangs die Sprache, mit der man komplexere Sachverhalte umsetzen konnte. Zu Zeiten, als es nichts wirkich Besseres gab. Beim heutigen Stand von SCL programmiere ich auch mit SCL und nicht mehr mit AWL.
 
PS: AWL war nie schlecht. Es war Anfangs die Sprache, mit der man komplexere Sachverhalte umsetzen konnte. Zu Zeiten, als es nichts wirkich Besseres gab. Beim heutigen Stand von SCL programmiere ich auch mit SCL und nicht mehr mit AWL.

Wobei AWL auch heute noch seine Vorteile hat
=> Beobachten teilweise deutlich einfacher
=> Sehr gute Verbreitung, Instandhalter können damit umgehen ( zumindest in meiner Branche ), SCL eher weniger
 
Ich kenne einen Hochschuldozenten, der ein Automatisierungspraktikum leitet. Dort haben z.B. die Studenten die freie Wahl zwischen Beckhoff und SIEMENS (TIA Portal). Ich haben ihn mal gefragt, womit die Studenten lieber arbeiten. Da kam dann die Antwort: SIEMENS
Ist wohl intuitever. Ich kenne bei SIEMENS auch die SIMOTION- Steuerung. Dieses vielleicht von den Programmierung / Task- System vielleicht näher an TWINCAT und kann z.B. auch objektorientiert programmiert werden, hatte auch immer wieder Features die erst später bei der SIMATIC nachgezogen geholt wurden. Die Kunden haben wohl eine SIMATIC am liebsten.

Ich hatte so gehofft, das Siemens Simotion weiterentwickelt, als man die TIA-Entwicklung ankündigte. Das wäre wirklich etwas gewesen. Aber da gibt es leider wohl auch Konzern-interne Rangeleien. Wie peinlich.
 
Zuviel Werbung?
-> Hier kostenlos registrieren

Das einzig stupide in deiner scheinbar endlosen Troll-Aktion hier ist dein rumgeheule, wie schlecht und veraltet doch die SPS-Welt. Da du ja anscheinend der Programmiergott schlechthin bist, frage ich mich mittlerweile, warum du offensichtlich an TIA / St bzw. SCL scheiterst, wenn doch zig tausend Leute trotz der Probleme damit funktionierende Anlagen auf die Beine stellen?



Vielleicht weil diese Leute darüber entscheiden, ob man den Auftrag bekommt oder nicht.

Jetzt komm mal wieder auf den Boden. Man kann eine Diskussion vielleicht auch mal sinnvoll weiterführen ohne dem gegenüber immer Vorhaltungen zu machen. Für seinen Einstieg hat Mike100 doch schon sein Fett wegbekommen und in der weiteren Diskussion ist es doch recht konstruktiv zugegangen. Das fnad ich bisher ganz gut so. Man muß nicht anfangen zu polemisieren, wenn man nicht mehr argumentieren will/kann!
 
Das kann ich fast alles unterschreiben und das erzähle ich spätestens seit V13 (Seitdem ich das produktiv einsetzte).
S7 300 in TIA war nach meinen Infos nicht geplant, sondern ein MUSS des Marketings und hatte tatsächlich großen Anteil and er Katastrophe. Völlig unverständlich.

Leider fürchte ich, wir werden nichts Neues bekommen und vor allem nichts Besseres.
Denke es geht in Richtung Cloud, Cloud-Dienste. Siemens hat Schiß, dass sie Ihre spezailhardware (PLC etc.) nicht mehr verkauft bekommen, weil all das auf irgendwelchen Computern, Controllern oder in der Cloud läuft. Daher kommt es wohl auch, dass immer mehr Kleinkram mit einer License verkauft wird. Irgendwann verkauft man nur noch Software und License. Die Entwicklung ist sicherlich auch bedenklich, ich halte sie für fatal.

Ich hätte gerne ien IDE, die die Sprachelemente KOP/FUP/SCL/Graph enthält. Ich will mich möglichst ohne C/C++ oder andere Sprachkenntnisse um die Programmierung von Maschinen kümmern. Die müssen funktionieren und zwar tadellos! Code-Testfunktionen wären schon nett, aber wohl nur für SCL sinnvoll, wenn überhaupt. Ist sicherlich schwierig umzusetzen, denn da hängt ja i.d.R. noch ein Bus und externen Hardware dran.

PS: AWL war nie schlecht. Es war Anfangs die Sprache, mit der man komplexere Sachverhalte umsetzen konnte. Zu Zeiten, als es nichts wirkich Besseres gab. Beim heutigen Stand von SCL programmiere ich auch mit SCL und nicht mehr mit AWL.

Code-Test-Funktionen sind gut, wenn sie schnell und leichtgewichtig funktionieren.
Wenn ich einen SCL-Unittest in 5 Minuten schreiben kann und in einer Sekunde ausführen kann, dann ist es ein gutes Tool.
Wenn ich aber mehrere Gigabytes an Simulatoren downloaden muss, und dazu noch exakt die richtigen Versionen und License Extensions aufeinander abstimmen muss, dann wird das Testen ad absurdum geführt.

Wenn ich daher im Siemens-Marketing von "Digital Twins" lese, dann kommt mir nur das lachen. Nicht einmal primitive Unit-Tests werden von Siemens ordentlich supported, wie wollen die einen Digital Twin einer Industriestraße bauen?! Ich vermute, dass abgesehen von einzelnen Auftragsentwicklungen auch nichts für das Thema "Industrie 4.0" zusammengebracht wird, aufgrund von all diesen Limitationen.

Bei vielen Siemens-Tools frage ich mich immer, woher das schlechte Verhältnis zwischen Performance und Funktionalität kommt. Manche Tools tun nicht viel, aber sind trotzdem riesengroß und langwierig zu installieren. PLCSim Advanced ist so ein Negativbeispiel.
 
Bezüglich Lizenzen:
Ich kann bei Siemens keine konsistente Business-Strategie erkennen. Ich habe eher das Gefühl, dass jede Software für sich alleine versucht, profitabel zu wirtschaften, dabei aber die Kernprodukte sträflich vernachlässigt werden. So als würde ich ein dutzend mittelständische Software-Schmieden in einen Konzern werfen, welche dann in einzelnen Silos vor sich hinarbeiten.
Also das genaue Gegenteil von Google/Microsoft/Facebook, welche mit riesigen Monorepos, Developer Tools Teams und interner Open Source Kultur arbeiten.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Man muß nicht anfangen zu polemisieren, wenn man nicht mehr argumentieren will/kann!
ahja...

So als würde ich ein dutzend mittelständische Software-Schmieden in einen Konzern werfen, welche dann in einzelnen Silos vor sich hinarbeiten

Naja das ausgliedern und aufspalten hat bei Siemens ja schon eine gewisse Tradition...


Ich frage mich nur, was der Mehrwert dieser ganzen Diskussion ist? Ja TIA ist nicht das gelbe vom Ei, viele andere IDE's auch nicht. Wenn es hier nur darum geht, wegen TIA zu jammern, hätte man das ganze auch im Thread "TIA-Frust" abhandeln können...
 
Jetzt komm mal wieder auf den Boden. Man kann eine Diskussion vielleicht auch mal sinnvoll weiterführen ohne dem gegenüber immer Vorhaltungen zu machen. Für seinen Einstieg hat Mike100 doch schon sein Fett wegbekommen und in der weiteren Diskussion ist es doch recht konstruktiv zugegangen. Das fnad ich bisher ganz gut so. Man muß nicht anfangen zu polemisieren, wenn man nicht mehr argumentieren will/kann!

Ich sehe keine Diskussion, ich lese immer nur TIA ist schlecht und die Nutzer sind Dämlich weil Sie es nutzen.

Ich lese keinen Ansatz wie es besser ist oder was besser ist, das ist keine Niveauvolle Diskussion. Es sind
einfach nur dahin gestellte Behauptungen.
 
Ich sehe keine Diskussion, ich lese immer nur TIA ist schlecht und die Nutzer sind Dämlich weil Sie es nutzen.

Ich lese keinen Ansatz wie es besser ist oder was besser ist, das ist keine Niveauvolle Diskussion. Es sind
einfach nur dahin gestellte Behauptungen.

So unterschiedlich kann die Sicht sein. Für mich ist es die spannendste Diskussion seit ganz langer Zeit. Vielleicht spitzt Mike100 etwas zu, aber die Kernpunkte sehe ich genauso. Ob es auch Verantwortliche bei Siemens gibt, welche es ähnlich sehen? Mir ist nicht klar, wo die Reise mit TIA hingehen soll. Da wir als Anwender mit dem Einsatz dieser Software unseren Unterhalten verdienen, sollten wir das auch hinterfragen. Außerdem möchte ich auch Werkzeuge haben, mit denen das Arbeiten Spass macht.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ich sehe keine Diskussion, ich lese immer nur TIA ist schlecht und die Nutzer sind Dämlich weil Sie es nutzen.

Ich lese keinen Ansatz wie es besser ist oder was besser ist, das ist keine Niveauvolle Diskussion. Es sind
einfach nur dahin gestellte Behauptungen.

Na ja, es schwingt immer die Hoffnung mit, das jemand bei Siemens mitbekommt, wie wir Nutzer denken und dann entprechend reagiert wird. Die Hoffnung stirbt zuletzt. Siemes ist auf dem Ohr i.d.R. absolut taub!
Wir können da nichts ändern, wir können aber darüber reden und auch Alternativen diskutieren, ob die nun gut oder schlecht sind, wird sich vielleicht irgendwann zeigen.
Mike100 hat in einem auf jeden Fall Recht: TIA ist eine Krücke, die mit Müh nund Not am Leben erhalten wird und uns allen früher oder später um die Ohren fliegt. Siehhe Versions-Chaos.
Ich muß auch sagen: "Ich hab mich mit TIA inzwischen arrangiert, kenne einige Tücken und komme halbwegs damit zurecht, auch Dank des Forums und des ständigen Mitlesens. Das sollte eigentlich nicht nötig sein, komplette Neueinsteiger haben es nicht leicht. Daher habe ich ein gewisses "Expertenwissen" angesammelt, das ich bei Wechsel auf Beckhoff, Wago etc. wegwerfen kann. Mach ich nicht, warum?
Die Hardware ist nicht so schlecht, der Kunde will das, also...
 
Brauchst du dieses Expertenwissen bei Beckhoff, Codesys und auch bei VisualStudio auch,
da fängt man immer wieder bei Null an. Ich bin ja auch hin und her Gerissen mit TIA und
möchte auch darüber Diskutieren aber dann auch sachlich und fundiert.

Wie sieht den eine Alternative aus?
Gibt es überhaupt eine Alternative zu den bisherigen SPS-Programmier Umgebungen?

Wir sprechen immer noch von SPS-Programmierung, das ist ein anderes Werkzeug,
als wenn man eine Anwendung für ein Büro PC erstellt.

Nicht ohne Grund wird da eine alte Basis für Hardware und Software verwendet.
 
@RN
Darum gings ja ursprünglich. Und wir haben ja festgestellt, es gibt derzeit keine anderen Tools für Siemens, so wie früher für die S5 und die S7. Da kommt wohl keiner mehr hinterher.
 
Zurück
Oben