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

Zuviel Werbung?
-> Hier kostenlos registrieren
So langsahm wird es zu ein Klagensang über TIA. Das TIA nicht perfekt ist, ist uns alle klar.

Wenn wir zurück zum ersten Beitrag geht, dann stöhrt es mir mit diesen Forderung:
Stattdessen möchte ich eine vernünftige IDE und Command-Line-Tools für das pushen des Codes verwenden.
Im einfachsten Fall reicht es mir aus, wenn ich ein kompiliertes C/C++-Programm mittels SSH auf die SPS pushen kann.
Also ick kenne keine Kunden der es erlaubt das Programmupdates "gepusht" werden.

Es kann eventuell auch gegen Sicherheitvorschriften stossen. Z.B. gibt es ein C-Standard für Giessereien (EN710), den meinen Firma folgen muss.
Darin ist ein Kapitel
5.1.10 Remote access to the control systems
The following requirements shall be complied with:
a) enabling remote access only by secured connection and by authorized remote users;
b) it shall be arranged by guidelines, e.g., user profile, rights, time limits;
c) activities capable of being carried out by remote access shall be defined;
d) where safety-related software and parameters have been modified, a functional test shall be carried out;
e) activities shall be carried out solely on site in co-ordination with and with direct participation of the responsible personnel; both sides shall document these activities;
f) personnel on-site are responsible for functional tests and re-commissioning as well as compensational safety measures.
Fazit, "pushing" ist nicht erlaubt.

Mike100, welchen Art Maschinen oder Anlagen handelt es um ?
 
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.

Das ist ein weiteres Beispiel für die Idiotie von TIA.
Ich weiß es nicht, ob der Grund dafür die Erhöhung der Lizenzeinnahmen ist, aber mit einer guten Software-Architektur hat das absolut nichts mehr zu tun.
User-Libraries in ein Betriebssystem zu hardcoden ist ein Stümperfehler, den wahrscheinlich jeder Informatik-Bachelor-Student erkennen würde.
Egal ob Absicht oder Wahnsinn: Von einer hohen Produktivität ist TIA meilenweit entfernt.

Aufgrund der Insider-Infos weiß ich, dass durch diesen monolithischen Architektur-Wahnsinn nicht nur die TIA-Anwender beschädigt werden, sondern auch die Produktivität des Siemens-internen TIA-Dev-Teams in den Keller gesunken ist.

Jahrzehntelange Geschichte in der Software-Entwicklung zeigt, dass nur modulare Ansätze für eine große Codebasis skalieren können. TIA macht das Gegenteil und scheitert dabei katastrophal.
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
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.
Ich hatte zwar auch im Medizinsektor zu tun, aber nicht im Softwarebereich, daher kann ich nur vermuten. In dem Bereich wird ja aus gutem Grund alles doppelt und dreifach geprüft, dokumentiert und abgenommen und ich denke mal, wenn ein abgenommenes Programm erneut kompiliert wird muss die Datei absolut gleich sein, dafür müssen dann aber alle beteiligten Softwarekomponenten auf dem gleichen Stand sein.

Von irgendwas mit Internetzugang gesendet.
 
Ich hatte zwar auch im Medizinsektor zu tun, aber nicht im Softwarebereich, daher kann ich nur vermuten. In dem Bereich wird ja aus gutem Grund alles doppelt und dreifach geprüft, dokumentiert und abgenommen und ich denke mal, wenn ein abgenommenes Programm erneut kompiliert wird muss die Datei absolut gleich sein, dafür müssen dann aber alle beteiligten Softwarekomponenten auf dem gleichen Stand sein.

So wurde es mir auch erklärt.
Das Generieren der ausführbaren Software muss nachvollziehbar sein.
 
Ich hatte zwar auch im Medizinsektor zu tun, aber nicht im Softwarebereich, daher kann ich nur vermuten. In dem Bereich wird ja aus gutem Grund alles doppelt und dreifach geprüft, dokumentiert und abgenommen und ich denke mal, wenn ein abgenommenes Programm erneut kompiliert wird muss die Datei absolut gleich sein, dafür müssen dann aber alle beteiligten Softwarekomponenten auf dem gleichen Stand sein.

Von irgendwas mit Internetzugang gesendet.

Ich stimme auch grundsätzlich zu. Reproduzierbare Builds sind eine gute Sache. Nicht nur in der Medizintechnik, sondern generell.

Trotzdem behaupte ich:
Mit einem vernünftigen Package-Manager und package-lock-files sind reproduzierbare Builds wesentlich einfacher umzusetzen, als mit einem monolithischen Monster wie TIA-Portal.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ich respektiere SPS-Programmierung als Beruf... .

Den Eindruck habe ich nicht, so wie du dich hier gebärdest...

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.

Du schwadronierst hier über moderne Sprachen und IDE und kommst dann mit KOP um die Ecke. Passt für mich nicht ganz zusammen...
 
Den Eindruck habe ich nicht, so wie du dich hier gebärdest...

Du schwadronierst hier über moderne Sprachen und IDE und kommst dann mit KOP um die Ecke. Passt für mich nicht ganz zusammen...

Das passt sehr wohl zusammen. KOP respektiere ich als Sprache, weil es eine gute Lesbarkeit für Elektriker bietet und auch für die Online-Maintenance gut geeignet ist (obwohl KOP natürlich eine sehr limitierte Sprache ist).

Was ich hingegen nicht akzeptiere sind aufgeblähte IDEs wie TIA-Portal, bei welchen das Verhältnis zwischen Features und Stabilität unterirdisch schlecht ist, und bei welchen sämtliche Openness-Features eine reine Farce sind.

Und der Grund, warum ich gegen ST/SCL schimpfe ist nicht die Sprache selbst, sondern weil die IDEs und Libraries unterirdisch schlecht sind im Vergleich zu modernen IDEs und Package Managern.
 
Zuletzt bearbeitet:
So langsahm wird es zu ein Klagensang über TIA. Das TIA nicht perfekt ist, ist uns alle klar.

Wenn wir zurück zum ersten Beitrag geht, dann stöhrt es mir mit diesen Forderung:
Also ick kenne keine Kunden der es erlaubt das Programmupdates "gepusht" werden.

Es kann eventuell auch gegen Sicherheitvorschriften stossen. Z.B. gibt es ein C-Standard für Giessereien (EN710), den meinen Firma folgen muss.
Darin ist ein Kapitel
Fazit, "pushing" ist nicht erlaubt.

"Pushing" bedeutet nicht notwendigerweise Remote-Pushing über das Internet. Es ist problemlos möglich, SSH in einem lokalen Netzwerk einzusetzen.
SSH war auch nur ein beliebiges Beispiel für Code-Pushing.
Das tatsächliche Ziel ist die Unabhängigkeit von instabilen Monster-IDEs mit proprietären File-Formaten.

Eine vernünftige IDE ist so strukturiert, dass man alles über die Command-Line machen kann. Der Grund ist nicht, dass ich ein Command-Line-Freak bin und um jeden Preis eine GUI vermeiden will, sondern ein architektonisch sinnvoller Split zwischen kritischer Build-Chain und nicht-kritischer IDE-GUI.

Würde TIA eine Trennung zwischen GUI und Build-Chain einhalten, dann wäre TIA vermutlich wesentlich stabiler.
Außerdem ermöglichen Command-Line-Tools die Entwicklung und Weitergabe von eigenen customized Dev-Tools, oder auch Continuous Integration.

Egal ob man customized Dev-Tools braucht oder nicht: Solche "home-grown" Tools sind notwendig, um ein vernünftiges Ecosystem um eine Plattform herum zu schaffen.
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
Das passt sehr wohl zusammen. KOP respektiere ich als Sprache, weil es eine gute Lesbarkeit für Elektriker bietet und auch für die Online-Maintenance gut geeignet ist.

Ich glaube mittlerweile, dass du keinerlei Schimmer von elektrischer Instandhaltung hast. Wärst du mir in meiner Zeit als Instandhalter mit Kop um die Ecke gekommen, ich hätte dir dein Programm buchstäblich um die Ohren gehauen :D
 
Ich glaube mittlerweile, dass du keinerlei Schimmer von elektrischer Instandhaltung hast. Wärst du mir in meiner Zeit als Instandhalter mit Kop um die Ecke gekommen, ich hätte dir dein Programm buchstäblich um die Ohren gehauen :D

Welche Sprache setzt du für einfache SPS-Zwecke ein?
Programmierst du alles mit ST/SCL?
 
Das ist ein weiteres Beispiel für die Idiotie von TIA.
Ich weiß es nicht, ob der Grund dafür die Erhöhung der Lizenzeinnahmen ist, aber mit einer guten Software-Architektur hat das absolut nichts mehr zu tun.
User-Libraries in ein Betriebssystem zu hardcoden ist ein Stümperfehler, den wahrscheinlich jeder Informatik-Bachelor-Student erkennen würde.
Egal ob Absicht oder Wahnsinn: Von einer hohen Produktivität ist TIA meilenweit entfernt.

Aufgrund der Insider-Infos weiß ich, dass durch diesen monolithischen Architektur-Wahnsinn nicht nur die TIA-Anwender beschädigt werden, sondern auch die Produktivität des Siemens-internen TIA-Dev-Teams in den Keller gesunken ist.

Jahrzehntelange Geschichte in der Software-Entwicklung zeigt, dass nur modulare Ansätze für eine große Codebasis skalieren können. TIA macht das Gegenteil und scheitert dabei katastrophal.

Also was TIA betrifft werden dir hier so einige Leute Recht geben. Wir reden seit Jahren, aber Siemens interessiert sich nun einmal nicht für die Probleme seiner Kunden. Ich hab vor Jahren an Kaeser geschrieben (TIA V13), die haben nicht mal begriffen, was genau ich denen mitteilen wollte, weil die nicht mehr in der Lage sind, sich und ihre Produkte zu hinterfragen. Zu TIA wurde mit gegenüber behauptet, man habe die "alten" Step7-Entwickler bewußt ausgeschlossen, weil man etwas Neues machen und nicht auf alten Schienen fahren wollte. Das war Megaclever von den Kollegen bei Siemens. Die erste TIA-Version 10.5 haben wir in der Luft zerissen, bis auf ein paar bezahlte Speichellecker, die Alles ganz toll finden. Genau nach denen scheint sich Siemens zu richten. Inzwischen hat man sich gewöhnt und einige Dinge sind ja auch ok.

Aber mal zu C/C++: Hauptproblem sehe ich in der völlig anderen Herangehens- und Denkweise. Ehrlich, ich bin einfach nciht in der Lage, einen wirklich ordentlichen C++-Code zu schreiben, weil ich immer in der Liniearen SPS-Schiene denke. Gleiches hab ich schon einige Male bei Software-Entwicklern gesehen, die eine kleine SPS-Maschine ums Verrecken nicht zum Laufen gebracht haben, weil sie eben auch eine völlig andere Herangehensweise gewohnt waren.

Kommandozeile ok, ich versteh dein Argument, das ist auch gut, aber ich will die auf jeden Fall nicht, wlll also die IDE als Kapsel drumherum. Würde ja locker gehen.

Deshalb die Bitte: Geh zu Siemens und bring denen was bei, aber bitte, komm uns nicht mit C/C++ als First-Class-SPS-Sprache. Das sollte schon KOP/FUP und ST bleiben. Wer muß und will kann ja C/C++ bekommen, ich kann seinen Code dann definitiv nicht so warten, dass ich mich traue eine komplexe Anlage nach einer kleinen Änderung einzuschalten. NEVER
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
Unser Steuerungshersteller bietet nur ST bzw. STX an. Ich persönlich komme mit ST/SCL/STX besser zurecht als mit anderen Sprachen. Aber das ist nur meine Auffassung. Für einfache Aufgaben würde ich aber FUP wählen.
 
Jemand, der seinen PC so zugemüllt hat das selbst ein triviales TIA-Portal abschmiert und träge wird (Startzeit TIA-Portal V15.1 inklusive Projektöffnung und Bereitschaft zum "coden": <20 Sekunden = Standard).
Eine haltlose Behauptung. Und selbst wenn TIA-Portal 15 Sekunden für ein einfaches Projekt braucht, ist das grottenschlecht für eine moderne IDE auf einem modernen PC.
Für einfache Projekte erwarte ich eher eine Startzeit von 5 Sekunden.

Eine Person, die eine "Hochsprache" gerne zum Standard hätte und glaubt, das er einen Kunden findet dessen Frage er mit einem zuverlässigen "Nein" beantworten kann: "Binden wir uns mit Ihrer Programmierung an Sie?" (Kein Kunde will ein Projekt das nur von einer Person bearbeitet werden kann und schon lange keines das seine eigenen Elektriker nicht mehr überblicken können.

Ich frage den Kunden:
Wollen Sie ein IDE-unabhängiges und menschen-lesbares File-Format mit offenen Standards, welches bereits seit Jahren stabil ist und noch Jahrzehnte weiterhin supported wird?
Oder wollen Sie ein TIA-Portal, welches Ihr Binary-File-Format mit dem nächsten TIA-Service-Pack zerschießt und nur mehr mit Hilfe von veralteten TIA-VMs gewartet werden kann?

Elektriker lernen sehr viel Hardware und Fachwissen, müssen im Programm allerdings auch suchen können woran es hängt, und nicht erst noch Stunden damit verbringen wie das Programm aufgebaut wurde und abläuft. Denn sicher ist: Einer SPS kann ich zuschauen, einem C-Code in der laufenden Anlage nicht, da er compiliert ist.)

Was mich stört, so richtig:

Was kann C/C++ in einer Anlage BESSER als eine industrielle SPS? Bleib ruhig bei Siemens, orientier Dich an der aktuellsten, größten verfügbaren 1500er die Du finden kannst, auf Siemens bist ja eingeschossen. Ich finde nicht ein einziges Argument. Nichteinmal der Punkt Geschwindigkeit. Zyklen sind schon lange nicht mehr auf ms begrenzt und jede Anweisung ist dokumentiert, selbst mit Angabe wie lange diese Anweisung bearbeitet werden muss.

Ich gebe zu, dass C nicht das Gelbe vom Ei ist.
Der Grund, warum ich nach C gefragt habe ist, weil C ein möglicher Ausweg aus der Welt der instabilen Monster-IDEs mit obskuren Binary-Files ist.
Trotzdem behaupte ich, dass ST/SCL auch nicht wesentlich besser als C ist (wenn man nicht zwanghaft Siemens verwenden muss).

Was soll man von diesen Aussagen nun halten?
Siemens ist Dreck, hat ne blöde IDE die ich nicht mag (weil mein Rechner nicht richtig aufgesetzt ist). Google und MS sind besser, weil Google ja keine Lizenzen zu horrenden Preisen vertickt (HW-Hersteller will Android-Lizenz=$100.000 aufwärts), MS Zwangsupdates als "unverzichtbar" bei lediglichen "Funktionserweiterungen" wird vorraussetzt und alte SW <NULL> supportet, sich Support sogar bezahlen lässt, was selbst Siemens beim After-Sales nicht macht, und es nicht hinbekommen hat einen eigenen Kernel für sein System zu nutzen, sogar kopieren und Strafen hinnehmen musste. Wenn Siemens, Schneider, Wago, Beckhoff, Sick doch alle so dumm sind, dann vertrau doch auf die Firmen denen Deine Idole wie Google und Microsoft vertrauen.

Ich verherrliche Microsoft und Google keineswegs, aber in gewissen Punkten sind diese Unternehmen Siemens weit überlegen.
TIA-Portal hat keine Chance gegen die IDEs von Microsoft (Visual Studio, VSCode) oder Google (Android Studio, Flutter).
Die Kern-Kompetenz von Siemens liegt in der Elektrotechnik, aber sicher nicht in der IDE-Entwicklung.

Außerdem:
Microsoft und Google haben sehr leistungsstarke Developer-Tools-Teams, während Siemens-interne Teams teilweise die schlecht gewartete Open-Source-Library "Snap7" einsetzen :sm7::sm7:
Das weiß ich aus Insider-Infos: Weder die offiziellen Developer-Tools noch die internen Developer-Libraries von Siemens haben irgendeine Chance gegen die IT-Giganten.
Siemens hat auch keine vernünftige interne Open-Source-Kultur, was bewirkt, dass interne Siemens-Teams so wie externe Auftrags-Entwickler arbeiten (anstatt von den Konzern-Ressourcen zu profitieren). Ein Blick auf die GitHub-Profile der Groß-Unternehmen zeigt bereits den Weg, wer in Zukunft aufgekauft oder zerschlagen wird.


Nimm Controllino und alles wird gut. Programmierbar mittels kleiner IDE, kostenfrei, kostenpflichtig, wie man mag, teilweise mit Bildchen, und vor Allem: versuch eine der Mio€-Aufträge zu bekommen die da in der Industrie schlummern mit dem Produkt in der es darauf ankommt das die anwesenden Elektriker und Maschinenbediener sicher damit arbeiten können und bei Fehlern schnell die Reparatur durchführen können.

Controllino ist interessant, allerdings ist mir die Arduino-Basis etwas zu leistungsschwach.
Ich will eine SPS, auf welcher auch High-Level-Anwendungen wie Web-Server/einfache Visualisierung/OPC UA lauffähig sind.
Dafür benötige ich eine SPS auf Embedded-Linux-Basis.
Gibt es leistungsstärkere Alternativen zu Controllino auf Linux-Basis?
 
Zuletzt bearbeitet:
Unser Steuerungshersteller bietet nur ST bzw. STX an. Ich persönlich komme mit ST/SCL/STX besser zurecht als mit anderen Sprachen. Aber das ist nur meine Auffassung. Für einfache Aufgaben würde ich aber FUP wählen.

Wo ich von KOP gesprochen habe, habe ich eh auch FUP gemeint.
KOP und FUP sind für mich funktionell gleichwertig.

ST/SCL/STX sind zwar der mächtigste Weg in der aktuellen SPS-Landschaft, in diesem Thread stelle ich aber TIA-Portal als Ganzes in Frage.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Also was TIA betrifft werden dir hier so einige Leute Recht geben. Wir reden seit Jahren, aber Siemens interessiert sich nun einmal nicht für die Probleme seiner Kunden.

Du hast es richtig erfasst. Siemens Developer Tools interessieren sich nicht für die Bedürfnisse von modernen Software-Entwicklern, und ich habe bereits in diesem Thread dutzende Beispiele dafür aufgezählt.
Falls die Marktwirtschaft funktioniert, dann muss Siemens mit dieser Vorgangsweise mittelfristig vom Markt eliminiert werden.
Möglicherweise können sie sich aber dank Marktmacht und Knebel-Verträgen am Leben erhalten.

Ich hab vor Jahren an Kaeser geschrieben (TIA V13), die haben nicht mal begriffen, was genau ich denen mitteilen wollte, weil die nicht mehr in der Lage sind, sich und ihre Produkte zu hinterfragen.

Joe Kaeser ist hierfür der falsche Ansprechpartner. Der richtige Ansprechpartner wären die Manager von Siemens Digital Industries.
Allerdings befürchte ich, dass auch bei Digital Industries die Controller und Erbsenzähler das Sagen übernommen haben, und niemand mehr weiß was eine moderne IDE eigentlich bedeutet.


Zu TIA wurde mit gegenüber behauptet, man habe die "alten" Step7-Entwickler bewußt ausgeschlossen, weil man etwas Neues machen und nicht auf alten Schienen fahren wollte. Das war Megaclever von den Kollegen bei Siemens. Die erste TIA-Version 10.5 haben wir in der Luft zerissen, bis auf ein paar bezahlte Speichellecker, die Alles ganz toll finden. Genau nach denen scheint sich Siemens zu richten. Inzwischen hat man sich gewöhnt und einige Dinge sind ja auch ok.

Hier zeigt sich die Idiotie einer dysfuntionalen Organisation, welche nicht mehr zur Entwicklung von hoch qualitativer Software nach Developer-Bedürfnissen in der Lage ist.
Step7 war zwar auch nicht das Gelbe vom Ei, aber es war für die damaligen Markt-Verhältnisse halbwegs in Ordnung.
TIA-Portal hat hingegen vollkommen den Anschluss an die moderne Developer-Welt verpasst.

Aber mal zu C/C++: Hauptproblem sehe ich in der völlig anderen Herangehens- und Denkweise. Ehrlich, ich bin einfach nciht in der Lage, einen wirklich ordentlichen C++-Code zu schreiben, weil ich immer in der Liniearen SPS-Schiene denke. Gleiches hab ich schon einige Male bei Software-Entwicklern gesehen, die eine kleine SPS-Maschine ums Verrecken nicht zum Laufen gebracht haben, weil sie eben auch eine völlig andere Herangehensweise gewohnt waren.

Ich gebe zu, dass C/C++ nur eine Notlösung wären.
Ich habe nur deshalb nach C gefragt, um aus der Welt der instabilen Lock-In-IDEs mit proprietären File-Formaten auszubrechen.

Kommandozeile ok, ich versteh dein Argument, das ist auch gut, aber ich will die auf jeden Fall nicht, wlll also die IDE als Kapsel drumherum. Würde ja locker gehen.

Ich selbst will auch keine Command-Line verwenden, aber ich will eine Build-Chain, welche mit der Command-Line funktioniert.
Das hat zwei Hauptgründe:
1. Die Command-Line ermöglicht eine modulare Trennung zwischen der kritischen Build-Chain und der nicht-kritischen IDE-GUI.
2. Die Command-Line ermöglicht die Entwicklung von Customized-Tools, eventuell auch für Continuous Integration oder alternative GUIs.

Deshalb die Bitte: Geh zu Siemens und bring denen was bei, aber bitte, komm uns nicht mit C/C++ als First-Class-SPS-Sprache. Das sollte schon KOP/FUP und ST bleiben. Wer muß und will kann ja C/C++ bekommen, ich kann seinen Code dann definitiv nicht so warten, dass ich mich traue eine komplexe Anlage nach einer kleinen Änderung einzuschalten. NEVER

Ich habe zwar nicht viel Berufserfahrung, aber lange genug, um zu wissen, dass dieses Himmelfahrtskommando vermutlich aussichtslos wäre.
C/C++ würde ich jedenfalls niemals als First-Class-SPS-Sprache propagieren, da ich C/C++ selbst nur als temporäre Notlösung sehe.
 
Dafür benötige ich eine SPS auf Embedded-Linux-Basis.
Gibt es leistungsstärkere Alternativen zu Controllino auf Linux-Basis?
Absolut.
Nimm Codesys for Linux (https://store.codesys.com/codesys-control-for-linux-sl.html?___store=en). Dazu ein Controller in Industriegeäuse und mit CE-Marke (https://revolution.kunbus.com/)
Beckhoff ist auch auf den Weg von Windows CE nach BSD (also nicht Linux, aber vermutlich stabiler als Linux) aber es wird dauern bis sie da sind (https://www.beckhoff.com/english.asp?industrial_pc/news_twincat_bsd.htm).
 
Zurück
Oben