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

Zuviel Werbung?
-> Hier kostenlos registrieren
Heinileini, du warst sicherlich auch Fan von Allo' Allo'
Da war schon wieder einer schneller! ;)
Nein, ich war kein Fan von 'Allo 'Allo - kannte ich gar nicht :oops: - bin jetzt aber auf dem Wege, einer zu werden. :s12:

PS:
Wie kriegen wir jetzt die Kurve zurück zum topic?
 
Kann ich mir nicht vorstellen, das müsste dann ja in den Lizenzinformationen vermerkt sein. Ich schaue da gelegentlich rein was Siemens so an Open-Source Software verwendet , aber dass da direkt ein Linux-Kernel zum Einsatz kommt ist mit noch nicht aufgefallen. Die alten WinCC flexible Spar-Bediengeräte liefen auf Linux-Basis, gegenüber den Windows CE Geräten war das aber der letzte Schrott (OP77A vs OP77B).

Ein kleiner Funken Wahrheit steht darin schon.

Die 1518 MFP hat einen Linux-Kernel, allerdings wird diese CPU selbst als F-Baugruppe nicht bei allen zugelassen da sie sehr angreifbar ist aufgrund der Linux-Architektur. Da sind einige "Löcher" entstanden die auf dem Linux-Kernel beruhen. Ob die alle dicht sind ist mir unbekannt, ich habe mir den Werdegang schon länger nicht mehr angeschaut, wir haben sie damals nicht mehr weiter beachtet weil sie einfach nicht akzeptiert wurde.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Das geht mal zu weit, du solltest nicht alle SPS-Programmierer, die mit Siemens arbeiten beleidigen, sonst stehst du bald allein in diesem Thread.
Es gibt tatsächlich ein paar Leute, die sich auf der Messe haben vollblubbern lassen, aber das sind wenigsten hier, insbesondere niemand von denen, die dir hier geantwortet haben. Also bleib sachlich!

Zum Thema:

Immerhin laufen die SPS stabil, das hat ja nichts mit der IDE zu tun. Und genau das ist es, was für und besonders wichtig ist.
Meine V15.1 stürzt inzwischen akzeptabel selten ab, das war früher schlimmer und tatsächlich ein Armutszeugnis.
Der Versionshorror wird uns, aber auch Siemens noch schwer zu schaffen machen.

Donnerstag hab ich eine V15.0 auf V15.1 gehoben, ging, hatte aber ein kleineres Problem. Eigentlich sollte es V16 werden, aber da fehlte mit dann die Safety Advanced Lizenz. Ja spinnen die bei Siemens?

Sorry für den Ausdruck "TIA-Jünger".
Damit bist nicht du gemeint, sondern Leute, welche glauben, dass TIA das Nonplusultra der Automatisierung ist.

Der Versionshorror ist ein von Siemens hausgemachtes Problem.
Normalerweise müsste man darüber schimpfen, dass TIA nicht mit standardisierten Quellcode-Files im Textformat kompatibel ist. TIA ist hingegen nicht einmal zu sich selbst kompatibel, was ein eigenes Niveau von "unterirdisch" definiert.

Dein Beispiel mit der Safety Advanced Lizenz ist typisch für Siemens. Als wäre das Versions-Chaos nicht schon schlimm genug, wird es durch das Lizenz-Chaos noch zusätzlich verschärft.
Siemens hat eine Erbsenzähler-Mentalität, wo Lizenzen für absurde Features kassiert werden, obwohl ohnehin der Großteil des Umsatzes über den Hardware-Verkauf erzielt wird.

Siemens ist auch der Hauptgrund, warum ich die Industrie-Normen nicht mehr ernst nehme:
Ich habe früher sehr großen Wert auf die Langzeit-Stabilität und Robustheit von Software gelegt. Seit ich aber gelernt habe, dass TIA immer noch in der Industrie verbreitet ist, seitdem glaube ich, dass die handelnden Personen keinen Dunst von Langzeit-Stabilität und Robustheit haben. In der Industrie kommt es nicht mehr auf die tatsächliche Qualität von Software an, sondern eher auf Marktmacht und Pseudo-Weisheiten an. Anders kann ich mir den Einsatz von TIA nicht erklären.
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
Siemens ist auch der Hauptgrund, warum ich die Industrie-Normen nicht mehr ernst nehme:
Ich habe früher sehr großen Wert auf die Langzeit-Stabilität und Robustheit von Software gelegt. Seit ich aber gelernt habe, dass TIA immer noch in der Industrie verbreitet ist, seitdem glaube ich, dass die handelnden Personen keinen Dunst von Langzeit-Stabilität und Robustheit haben. In der Industrie kommt es nicht mehr auf die tatsächliche Qualität von Software an, sondern eher auf Marktmacht und Pseudo-Weisheiten an. Anders kann ich mir den Einsatz von TIA nicht erklären.

Na dann...
 
Der Thread war ab dem ersten Post schon nicht mehr ernst zu nehmen. C/C++ als PLC Anwender Programmiersprache, weil die TIA IDE (teilweise) Murks ist? Das ist einfach nur falsch und realitätsfremd. Für µController, kleine Projekte usw. kann man so sicher ein Projekt aufziehen, aber niemals ist das die Wahl für Industrieanlagen mit Safety, hunderten Komponenten usw. Never ever. Das sind andere Welten.
Solche Ansichten kann nur von jemanden kommen der aus der C/C++ Welt kommt und noch nie an größeren PLC Projekten gearbeitet hat. So ging es mir auch mal, und ja, ich war auch verwundert über die Dinge die hier anders laufen, da man besseres gewohnt ist. Ich hätte auch gerne ein modernes IDE wie Visual Studio, Einfluss auf die Kompilierung, technische Details usw. Das macht die Grundthese die diesem Thread innewohnt aber nicht logischer. PLC Programmierung benötigt zwingend ein abstrahiertes Progammiersystem und da hat Siemens, ob nun TIA seine Macken hat oder nicht, durchaus was Großes und Nachhaltiges geschaffen. Rumfrickeln in C ist nichts für Maschinen.
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
Der Thread war ab dem ersten Post schon nicht mehr ernst zu nehmen. PLC Programmierung benötigt zwingend ein abstrahiertes Progammiersystem und da hat Siemens, ob nun TIA seine Macken hat oder nicht, durchaus was Großes und Nachhaltiges geschaffen. Rumfrickeln in C ist nichts für Maschinen.

Aber ST bzw. SCL ist für Maschinen geeignet? Ich sehe da kein großen Unterschied ob ich nun in C oder ST programmiere. Für C gibt da aber etliche Tools zur statischen Codeanalyse und diverse weitere Werkzeuge die sehr hilfreich sind, auf die man somit direkt zurückgreifen kann.

Meiner Meinung nach ist AWL nichts für Maschinen, da kannst du wirklich den größten Nonsens zusammen programmieren, ohne dass auch nur annähernd etwas auf Plausibilität vom Programmiersystem zur Entwicklungszeit überprüft wird. Und vom Sprachumfang bietet dir jeder Assembler eines 08/15 Prozessors einen besseren und angenehmeren Befehlssatz als AWL.

Ich finde zudem den Begriff C/C++ sehr unpassend, denn die Sprachen haben zum aktuellen Zeitpunkt außer dass C eine Untermenge von C++ ist nichts mehr gemeinsam. Ich kenne mich zwar mit C aus, und mit den Erstentwürfen von C++ (quasi C mit Klassen). Aber wenn ich mir aktuellen C++ Code ansehe der die aktuellsten Funktionen des Standards umfangreich verwendet, dann verstehe ich davon kaum noch etwas. Meiner Meinung nach ist das durch die Features mittlerweile völlig überfrachtet, und da muss für meinem Geschmack Codesys auch aufpassen, dass sie den IEC Standard nicht mit immer mehr Features überladen.
 
Ich finde die ganze Diskussion sehr interessant. Auch wenn der C/C++ Ansatz nicht wirklich zielführend ist, finde ich viele Aussagen von Mike100 richtig gut.
Ich finde die ganze TIA Entwicklung auch einfach nur seltsam. Wie kann man so eine Oberfläche entwickeln? Noch schlimmer finde ich das Version-Problem. Bei Step7 Classic hatte ich einfach die neueste Version und alles war gut. Das war aus meiner Sicht immer der große Vorteil von Step7, gegenüber den Mitbewerbern. Keine Ahnung, warum man das aufgegeben hat. Ich habe jetzt schon bei diversen Kunden die verschiedensten Versionen im Einsatz. Wie soll das in 10 Jahren aussehen?
 
Ich finde die ganze TIA Entwicklung auch einfach nur seltsam. Wie kann man so eine Oberfläche entwickeln?

Ich denke, Siemens ist hier ein so krass typisches Opfer des "Not invented here syndrom" Ich meine, es gibt schon eine sehr ausgereifte Oberfläche zum Programmieren, wieso lizenziert man sich nicht einfach sowas wie Visualstudio und baut damit sein Programmiersystem für die PLC? Da ist das ganze Fernstergespiele schon so ausgereift das man sich direkt auf die Industrieautomatisations Spezialitäten hätte konzentrieren können.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ich denke, Siemens ist hier ein so krass typisches Opfer des "Not invented here syndrom" Ich meine, es gibt schon eine sehr ausgereifte Oberfläche zum Programmieren, wieso lizenziert man sich nicht einfach sowas wie Visualstudio und baut damit sein Programmiersystem für die PLC? Da ist das ganze Fernstergespiele schon so ausgereift das man sich direkt auf die Industrieautomatisations Spezialitäten hätte konzentrieren können.

Das hat ja Beckhoff gemacht mit TwinCat III und zb. Inosoft mit VisiWin.
Kann den jemand, hier seine Erfahrung damit posten, ist das wirklich soviel
besser?
 
Ich denke, Siemens ist hier ein so krass typisches Opfer des "Not invented here syndrom" Ich meine, es gibt schon eine sehr ausgereifte Oberfläche zum Programmieren, wieso lizenziert man sich nicht einfach sowas wie Visualstudio und baut damit sein Programmiersystem für die PLC? Da ist das ganze Fernstergespiele schon so ausgereift das man sich direkt auf die Industrieautomatisations Spezialitäten hätte konzentrieren können.

Na gut, man muß nicht unbedingt ganz soweit gehen, aber die haben ja anscheinend nicht mal die üblichen Fensterklassen etc. genutzt, soindern gleich alles selbst gemacht. Brrr...
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Davon habe ich ja noch nie etwas gehört. Man lernt halt nie aus. Aber auch, wenn man sich nicht an solche quasi Standard wie Visualstudio hält, hätte es nicht so schlimm werden müssen.

Man muss halt an dieser Stelle, den Architektur unterschied der beiden Programme berücksichtigen. Die Entscheidung von Siemens eine aufwendiges IDE, wie TIA mit C# & somit einer Interpreter Sprache zu entwickeln ist halt Fragwürdig. Vor allem da mir bekannt ist das vor der TIA Entwicklung Microsoft Siemens aus genau dem Grund davon abgeraten hat.
Aber das ist ja auch der Grund warum Siemens nicht wie ursprünglich geplant TIA in Richtung PLS IDE entwickelt hat sondern mit PCS 7 NEO was ganz neues entwickelt hat.
Naja mal abwarten ob "WEBBASIERT" so viel besser ist.

Vielleicht gibt es ja irgendwann ein Tool, das alles kann was in diesem Thread gewünscht ist, mit den Vorteilen der meisten SPS/PLS IDE. :TOOL::TOOL:
 
Zuletzt bearbeitet:
Das hat ja Beckhoff gemacht mit TwinCat III und zb. Inosoft mit VisiWin.
Kann den jemand, hier seine Erfahrung damit posten, ist das wirklich soviel
besser?

Ja, aus meiner Sicht ist Twincat3 mit Visual Studio dem TIA Portal in den meisten Punkten deutlich überlegen. Die Editoren im TIA sind zwar sehr komfortabel aber es hakt beim Strukturieren der Software, der Hardware, und bei der Performance. Da fehlen mir so viele auch einfache Dinge, dass ich mich frage, warum Siemens die nicht einfach einbaut, obwohl es so offensichtlich ist, dass die fehlen.
Und im Detail kann Twincat3 oft doch mehr.

Nur bei der safety ist Siemens aus meiner Sicht besser.
 
Die Editoren im TIA sind zwar sehr komfortabel aber es hakt beim Strukturieren der Software, der Hardware, und bei der Performance.

Das sehe ich ähnlich. Ich finde die einzelnen Editoren auch sehr gelungen. Bis auf SCL sind alle sichtbar besser als bei CODESYS. Aber die eigentliche Oberfläche, dass Frame ist ganz furchtbar. Als wenn ganz verschiedene Teams da aneinander vorbei gearbeitet haben.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Der Thread war ab dem ersten Post schon nicht mehr ernst zu nehmen. C/C++ als PLC Anwender Programmiersprache, weil die TIA IDE (teilweise) Murks ist? Das ist einfach nur falsch und realitätsfremd. Für µController, kleine Projekte usw. kann man so sicher ein Projekt aufziehen, aber niemals ist das die Wahl für Industrieanlagen mit Safety, hunderten Komponenten usw. Never ever. Das sind andere Welten.
Solche Ansichten kann nur von jemanden kommen der aus der C/C++ Welt kommt und noch nie an größeren PLC Projekten gearbeitet hat. So ging es mir auch mal, und ja, ich war auch verwundert über die Dinge die hier anders laufen, da man besseres gewohnt ist. Ich hätte auch gerne ein modernes IDE wie Visual Studio, Einfluss auf die Kompilierung, technische Details usw. Das macht die Grundthese die diesem Thread innewohnt aber nicht logischer. PLC Programmierung benötigt zwingend ein abstrahiertes Progammiersystem und da hat Siemens, ob nun TIA seine Macken hat oder nicht, durchaus was Großes und Nachhaltiges geschaffen. Rumfrickeln in C ist nichts für Maschinen.

Mittlerweile bin ich mit C/C++ schon zurückgerudert, ich verfolge C/C++ nicht mehr. Dennoch bin ich fest davon überzeugt, dass TIA-Portal am Holzweg ist.

Wenn man hunderte Industrie-Komponenten hat, warum soll dann bitte TIA-Portal geeignet sein? TIA-Portal stößt bereits bei Kleinprojekten an seine Skalierungsgrenzen. Die Tatsache, dass TIA-Portal weder eine brauchbare Versions-Kontrolle noch eine Traceability der Build-Chain hat, das macht TIA-Portal für komplexe Software-Projekte ungeeignet.

Obwohl C für SPSen ungeeignet ist, ist zum Beispiel die Firmware aller SPSen in C programmiert. SPS-Firmware hat eine Komplexität, mit welcher TIA-Portal nicht einmal ohne die zahlreichen Bugs klarkommen würde.

Ich finde es immer wieder bizarr, wie manche Programmierer von "großen und komplexen Projekten" sprechen und dann mit TIA-Portal weder Source-Control noch automatisierte Tests einsetzen.

Früher hat man SPSen teilweise mit AWL programmiert, was noch mehr Low-level ist als C (obwohl es prinzipiell sinnlos ist, sich auf diese Low-level-Ebene für ein SPS-Anwendungsprogramm zu begeben).

Mein Fazit ist:
Weder C noch ST/SCL sind moderne und gute Sprachen für die SPS-Programmierung.
Es wird einfach nur verwendet, was gerade aktuell von der Masse verwendet wird.
 
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.
 
Zuletzt bearbeitet:
Zurück
Oben