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

Zuviel Werbung?
-> Hier kostenlos registrieren
Ich finde es spannend, dass hier immer wieder das Thema Hochsprache von irgendeinem SPS-Fremdling aufgebracht wird, und dann von C/C++ die Rede ist.

Die Sprache(n) sind eh ganz nett und eh ganz fein, aber wirklich wünschen würde ich mir manchmal, dass ich noch modernere Sprachen wie java, python oder matlab zur Verfügung habe - oder zumindest deren offenes Speicherkonzept. 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.
Ich würde mir wünschen, mal eben eine JSON- oder xml-Datei auf einer SPS parsen zu können und dabei einen flexiblen Suchbaum wie in java anlegen zu können. Eine solche Applikation ist mit C (ohne ++) und der modernsten IDE der Welt auch nicht besser machbar als mit TwinCat, Automation Studio oder TIA Portal.
 
Ich finde es spannend, dass hier immer wieder das Thema Hochsprache von irgendeinem SPS-Fremdling aufgebracht wird, und dann von C/C++ die Rede ist

Der TE stellt sich vor, dass man eine passende C oder C++ Lib oder ein Framework herunterlädt und auf der SPS verwenden kann.
Also mal schnell ein "git clone libjson" und schon kannst du deine JSON-Datei parsen.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo,

wenn man weiß wie Java funktioniert und wie eine SPS funktioniert wird ziemlich schnell klar, dass sich das nicht vereinen lässt. Das kann ich darum sagen, weil ich lange Steuerungssysteme mit Java programmiert habe und jetzt SPS programmiere.

JSON und XML parsen kann man z.B. mit TwinCAT. Dazu gibt es Bibliotheken.

Soll nicht heißen, dass es nicht schön wäre.

Grüße
 
Ich weiß schon, dass der Mike100 hier nur provozieren wollte und das dieser Thread jetzt langsam ins philosophische abgleitet...aber ich finde das eigentlich trotzdem immer ganz spannend.:)

Ich schlage mich mal auf seine Seite und sage:
Ja, TIA Portal ist keine gute IDE. Sie ist langsam, fehleranfällig und schon jetzt veraltet. Sie ist gemacht für die SIEMENS Welt. Und man soll da möglichst drin bleiben. Sie soll gar nicht mit anderen Systemen verbunden werden. Man soll alles bei SIEMENS kaufen. Man soll in dem System gefangen sein, man soll gar nicht schnell auf einen anderen Steuerungshersteller umsteigen können. Man soll jedes Jahr eine neue Version kaufen müssen, damit die aktuell lieferbare Hardware überhaupt programmiert werden kann. Aber immerhin hat SIEMENS OPENNESS und das wird in C# programmiert und damit auf dem aktuellen Stand der Technik.
Beckhoff ist trotzdem deutlich weiter. Ja, auch TwinCat3 stürzt mal ab, auch da ist nicht alles Gold was glänzt. Aber es ist die deutliche bessere IDE, sie kann OOP, sie kann C++, sie kann Git, sie kann Matlab, sie kann Safety-C (wobei ich damit keine Erfahrung habe).

Nun aber genug des TIA-Bashings.


Zum Thema Hochsprache:
Es wird immer behauptet, dass SPS nicht mit Hochsprachen programmiert werden können. Das ist Unsinn. SPSen werden in Hochsprachen programmiert. ST ist definitiv ein Hochsprache und bis auf die dynamische Speicher-Allozierung gleichmächtig wie C. Wurde hier auch schon richtigerweise gesagt. IL/AWL war es nicht, aber das benutzt ja auch niemand mehr. KOP und FUP sind so an der Grenze.
 
Ja, TIA Portal ist keine gute IDE. Sie ist langsam, fehleranfällig und schon jetzt veraltet. Sie ist gemacht für die SIEMENS Welt. Und man soll da möglichst drin bleiben. Sie soll gar nicht mit anderen Systemen verbunden werden. Man soll alles bei SIEMENS kaufen. Man soll in dem System gefangen sein, man soll gar nicht schnell auf einen anderen Steuerungshersteller umsteigen können.

Ich würde mal sagen das ist eine gute Produktphilosophie.
TWINCAT ist ja auch nur für Beckhoff.
Automation Studio nur für B&R.
Audi Felgen nur für Audi.
IOs nur für Apple
usw.
 
Ich würde mal sagen das ist eine gute Produktphilosophie.
TWINCAT ist ja auch nur für Beckhoff.
Automation Studio nur für B&R.
Audi Felgen nur für Audi.
IOs nur für Apple
usw.

Am Ende backen die alle mit den gleichen Brötchen:

Profinet
Profibus
MPI
CAN
Modbus
0-10V
2-10V
5V HTL/TTL
230V I/O
24V I/O
0-20mA
4-20mA
...

Die gängigen Größen können sie alle und untereinander kommunizieren können die meisten. Beckhoff, Wago, Schneider, Siemens bieten sogar großartige Hilfen an, ich sehe da keinen Punkt wo die sich weigern eine eigene Steuerung mit einer fremden kommunizieren zu lassen.

Ich würde mir eher Sorgen machen wenn ein Hersteller HW anbietet die nur mit dem hauseigenen Protokoll arbeitet. Dann ist man gebunden, und das wird von vielen Firmen mittlerweile unterbunden, finde ich auch richtig.
Im Bereich IO-Link warte ich auch noch darauf das der erste Ausreißer seine HW extrem günstig anbietet, diese aber nur mit seinem Master arbeiten kann.

Als unsere "Hausmarke" verwenden wir Siemens. Die hat sich bewährt, ist bei Kunden gerne gesehen, ist preislich für uns manchmal günstiger und manchmal teurer (+-20%) als andere Hersteller, lässt sich sehr umfangreich bearbeiten und erweitern. Und wenn wir noch so weit in der Pampa sind, gibt es immer irgendwo einen Vertriebsweg wo wir Bauteile bekommen. Darauf kommt es an.
Will der KD unbedingt eine Steuerung eines anderen Herstellers so schauen wir uns sie gerne an wenn wir sie nicht kennen, lehnen viele China-Produkte aber kategorisch ab, zu groß das Risiko das wir ne Anlage betreuen für die es kaum Support oder Hardware gibt bzw. wo Hardware nach Wochen geliefert wird. Dann lieber Vorweg klären was man selbst unter Service und guter Arbeit versteht als am Ende das Nachsehen zu haben.

Aber der Grundgedanke dieses Themas C/C++ als Programmiersprache weil alle anderen zu schwach sind, ist auffällig trollig, zumal die Lösungen ja genannt wurden, nur nicht für den TE akzeptabel sind und 9 von 10 der Argumente gegen die bisherigen Hersteller des TE wie Sand vom Winde weggefegt wurden.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Da komme ich jetzt nicht ganz mit. Wieso ist das editieren der XML in einer modernen IDE nicht möglich, oder gehst Du von falschen Voraussetzungen aus?
Natürlich wird nicht direkt in XML in der IDE editiert, wobei das im Fall von Codesys 3 und Derivaten jetzt auch nicht so schlimm wäre, sondern die IDE interpretiert diese und zeigt sie aufbereitet an. Im Falle von ST wird in der XML-Datei der Deklarationsteil und der Programmteil, sowie Aktionen, Eigenschaften und Methoden getrennt.

Genau das ist das Problem:
Codesys verwendet ein obskures XML-Format, welches nur von Codesys verstanden wird. Eine Editierung von rohen XMLs macht nämlich kaum Sinn.

Kein C-Programmierer würde jemals auf die schwachsinnige Idee kommen, den C-Code in ein XML-File einzubetten.

Ich verstehe es, dass SPSler auf eine gute Debugging-Fähigkeit zur Laufzeit wertlegen.
Die Debugging-Fähigkeit auf File-Ebene ist hingegen katastrophal bei TIA-Portal.
 
Ich schlage mich mal auf seine Seite und sage:
Ja, TIA Portal ist keine gute IDE. Sie ist langsam, fehleranfällig und schon jetzt veraltet. Sie ist gemacht für die SIEMENS Welt. Und man soll da möglichst drin bleiben. Sie soll gar nicht mit anderen Systemen verbunden werden. Man soll alles bei SIEMENS kaufen. Man soll in dem System gefangen sein, man soll gar nicht schnell auf einen anderen Steuerungshersteller umsteigen können. Man soll jedes Jahr eine neue Version kaufen müssen, damit die aktuell lieferbare Hardware überhaupt programmiert werden kann. Aber immerhin hat SIEMENS OPENNESS und das wird in C# programmiert und damit auf dem aktuellen Stand der Technik.
Beckhoff ist trotzdem deutlich weiter. Ja, auch TwinCat3 stürzt mal ab, auch da ist nicht alles Gold was glänzt. Aber es ist die deutliche bessere IDE, sie kann OOP, sie kann C++, sie kann Git, sie kann Matlab, sie kann Safety-C (wobei ich damit keine Erfahrung habe).

Endlich jemand der mich versteht.
Du hast es korrekt erfasst:

TIA-Portal ist kein gutes Produkt, sondern nur ein schlechter Lock-In in die Siemens-Welt. TIA-Portals Abstürze und Ladezeiten sprechen für sich.
Mit den TIA-Lizenzgebühren hätte ich kein Problem, wenn die Gegenleistung stimmen würde. Solange aber VMs und Re-Installationen zu den häufigen Debugging-Methoden zählen, so lange ist TIA keinen Cent wert.
Mit einer vernünftigen IDE reicht ein einziges Git-Kommando, um alle"temporären" IDE-Files zu löschen. Die TIA-Jünger hingegen sind es gewohnt, bei IDE-Crashes ein komplettes Projekt neu aufzusetzen.

TIA-Openness ist ebenfalls lächerlich. Eine tatsächliche Openness wäre nur mit offenen Fileformaten möglich (kein XML-Import/Export!!!). Diese obskuren C#-APIs von TIA-Openness können niemals ein offenes Projektformat ersetzen.

Und bezüglich TIA V16 Git Support:
Solange die Hardware-Konfig nicht in Git abgebildet ist, solange kann ich über den Git-Support nicht einmal lachen.
Siemens hat anscheinend "git push" und "git pull" mit "selektiven Git-Import/Export-Tools" verwechselt.
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
Ich kenne TIA jetzt nicht wirklich, frage mich aber grundsätzlich, was man auf Dateiebene debuggen soll/muss.

In einer idealen Welt würden alle Tools und IDEs fehlerfrei funktionieren, und man müsste niemals irgendwas auf Dateiebene debuggen. Diese Welt existiert aber nicht in der Realität, und schon gar nicht bei TIA-Portal, wo Abstürze und inkompatible Binary-Files an der Tagesordnung stehen.
 
Zum Thema Hochsprache:
Es wird immer behauptet, dass SPS nicht mit Hochsprachen programmiert werden können. Das ist Unsinn. SPSen werden in Hochsprachen programmiert. ST ist definitiv ein Hochsprache und bis auf die dynamische Speicher-Allozierung gleichmächtig wie C. Wurde hier auch schon richtigerweise gesagt. IL/AWL war es nicht, aber das benutzt ja auch niemand mehr. KOP und FUP sind so an der Grenze.

Da stimme ich zu. C für sich alleine genommen bringt nicht viel im Vergleich zu ST. Der tatsächliche Vorteil von C ist der Befreiungsschlag aus der Welt der inferioren Lock-In-IDEs.

SPS-Hersteller haben ihre Kernkompetenzen in der Elektrotechnik, aber sicher nicht in der IDE-Programmierung (zumindest nicht die derzeitigen SPS-Hersteller).

Siemens scheitert mit TIA-Portal katastrophal und kann sich nur dank Marktmacht am Leben erhalten. Beckhoff hat es zumindest halbwegs verstanden, dass sie alleine gegen Microsofts IDEs keine Chance hätten.
Und das vielgepriesene Codesys verwendet immer noch keinen echten Quelltext, sondern Quelltext in XML eingebettet.
 
Zuletzt bearbeitet:
Ich weiß ja nicht mit welcher TIA Version du arbeitest, mit V15[.1] habe ich noch keinen
Absturz erlebt. V13, 14, 15, 15.1 laufen bei mir parallel ohne VM.
TIA selber läuft inzwischen ganz rund, arbeitest du noch mit V11?
 
Ich weiß ja nicht mit welcher TIA Version du arbeitest, mit V15[.1] habe ich noch keinen
Absturz erlebt. V13,14, 15, 15.1 laufen bei mir parallel ohne VM.
TIA selber läuft inzwischen ganz rund, arbeitest du noch mit V11?

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 Fehlermeldungen 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.
 
Zuletzt bearbeitet:
Ich bin zwar relativ neu in der SPS-Programmierung
bei TIA-Portal, wo Abstürze und inkompatible Binary-Files an der Tagesordnung stehen.
Siemens scheitert mit TIA-Portal katastrophal und kann sich nur dank Marktmacht am Leben erhalten.
Wieviele SPS mit wievielen Datenpunkten hast Du schon programmiert? Mit welcher TIA-Version hast Du schon wie lange gearbeitet? Wie kommst Du darauf daß Du in der Lage bist solche generellen Urteile abzugeben?

Harald
 
Zuviel Werbung?
-> Hier kostenlos registrieren
der arbeitet doch nicht mit TIA
wie kommst auf die Idee ?

Ich habe mit TIA gearbeitet (V15.X), aber habe nach relativ kurzer Zeit das Handtuch geworfen.
Meine größten Painpoints waren:
- Ständiges Zerschießen von existierenden Projekten nach diversen Updates
- Obskure Binärfiles ohne guten Git-Support
- Abstürze
- Schlechte Performance

Lasst euch noch eines gesagt sein:
Wenn eine TIA-Software mehrere "DVDs" zum Download fordert, dann weiß man schon, in welchem gedanklichen Jahrhundert der Hersteller angesiedelt ist.

Und wenn man dann noch elendslange Export-Formulare und Lizenzen ausfüllt, dann erhält man den Eindruck, dass Siemens mehr Buchhalter und Juristen als Software-Entwickler hat (in den Führungsebenen).

Zum iranischen Atomprogramm können sie die S7-1200 gerne hinschicken: TIAs "Performance" wird das Atomprogramm eher bremsen als beschleunigen.
 
Zuletzt bearbeitet:
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 Fehlermeldungen 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.

Entlarvend, was soll der Quatsch den?
Ich kann doch Projekte hoch ziehen wenn ich will, mach ich permanent.
Ohne Absturz, wenn es bei dir nicht gelingt solltest du vielleicht
mal einen Kurs bei Siemens belegen.

Ich habe das hochziehen ohne Kurs hinbekommen.
 
Zurück
Oben