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

Zuviel Werbung?
-> Hier kostenlos registrieren
oliver.tonn schrieb:
Open-Source ist eine schöne Sache, aber im SPS-Umfeld schwer zu realisieren, denn dort muss jede Änderung ja erstmal gründlich geprüft werden und wenn die Entwickler nicht im Haus sind, wird das schwierig und vermutlich teuerer als etwas selber zu entwickeln.​
Zum Vergrößern anklicken....
Lol. Ich möchte beim Beispiel TIA-Portal bleiben, weil gerade TIA-Portal bekannt ist für seine häufigen Bugs und Abstürze.
Die Open-Source Git-Versionkontrolle hat eine extrem gute Zuverlässigkeit und ist wahrscheinlich zuverlässiger als jeder TIA-Multiuser-Engineering-Müll, den Siemens jemals programmiert hat.
Glauben Sie ernsthaft, dass der TIA-Multiuser-Server auch nur annähernd an die Zuverlässigkeit und Robustheit von Git-Repositories herankommt?

Ich stimme zu, dass SPSen eine sehr gute Runtime-Zuverlässigkeit haben, was auch ein Hauptgrund ist, warum man überhaupt SPSen verwendet.
Die Zuverlässigkeit von vielen Engineering-Tools wie TIA-Portal ist hingegen grottenschlecht bis unterirdisch (im Gegensatz zur Runtime-Zuverlässigkeit).

Im Runtime-Bereich verstehe ich eine Ablehnung gegen Open-Source, aber im Engineering-Tools-Bereich ist das geradezu lächerlich.
Es ist bizarr, wie man mit einem so schlechten Track-Record wie TIA-Portal eine absolut zuverlässige Open-Source-Software wie Git schlechtreden kann.
 
Zuletzt bearbeitet:
TIA ist aber nicht alles, andere Hersteller bieten wie gesagt eine GIT-Unterstützung und z.B. Twincat 3, wie ich gerade gesehen habe wohl auch eine recht umfangreiche Unterstützung um Programme in C++ zu erstellen und sogar mit Echtzeit (Sorry Hack, dieser Funktionsumfang war mir nicht bewusst) auszuführen.

Von irgendwas mit Internetzugang gesendet.
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
Langsam wird's unübersichtlich:
  • C / C++ als Programmiersprache
  • Entwicklungsumgebungen / IDE
  • Versionskontrollsystem
  • Multiuser
  • Runtime

Bei der Vielzahl von Themen kann eigentlich letztlich nix rauskommen.

Meine persönliche Meinung:
SPS ist ein extrem breites Feld mit vielen zum Teil sogar gegensätzlichen Anforderungen.
Daher sind immer mehr oder weniger Kompromisse nötig.

Wenn man eben gerne mit Visualstudio und OOP arbeitet, dann ist man vielleicht bei Beckhoff besser aufgehoben als bei Siemens.
Macht man viel HLK oder Gebäudetechnik, dann ist vielleicht Wago wieder die bessere Wahl.
Ist man in der Kunststoffindustrie, dann ist es vielleicht B&R.

Die Auswahl der geeigneten Steuerungen / Komponenten sehe ich persönlich als entscheidender an, als C oder ST.

Gruß
Blockmove
 
Also diese Troll Diskussion ist zwar ganz nett zu lesen aber die irgendwie sinnfrei.

Das was der TE möchte ist auf verschiedenste weise möglich, nur halt nicht mit den Steuerungen und IDE mit denen die meisten hier zu tun haben.
Einfach eine Arduino oder Raspberry Basis nehmen. Für diese kann man mit allerhand IDE aus der Hochsprachenwelt Code erzeugen (VS, Eclipse, ….).

Aber jeder Kunde mit etwas Sachverstand wird eine Implementierung im Maschinen oder Anlagenbau ablehnen. Das Debuging einer solchen Lösung ist ein Alptraum.

Ich habe regelmäßig mit beiden Welten zu tun und die strikte Trennung war bisher immer ein MUSS.
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
Larzerus schrieb:
Also diese Troll Diskussion ist zwar ganz nett zu lesen aber die irgendwie sinnfrei.

Das was der TE möchte ist auf verschiedenste weise möglich, nur halt nicht mit den Steuerungen und IDE mit denen die meisten hier zu tun haben.
Einfach eine Arduino oder Raspberry Basis nehmen. Für diese kann man mit allerhand IDE aus der Hochsprachenwelt Code erzeugen (VS, Eclipse, ….).

Aber jeder Kunde mit etwas Sachverstand wird eine Implementierung im Maschinen oder Anlagenbau ablehnen. Das Debuging einer solchen Lösung ist ein Alptraum.

Ich habe regelmäßig mit beiden Welten zu tun und die strikte Trennung war bisher immer ein MUSS.
Zum Vergrößern anklicken....

Raspberry ist zwar ganz nett, aber kein wirklicher Ersatz. Ich suche schließlich nach einer SPS für einen Schaltschrank und nicht nach einem Dev-Board nach Raspberry-Stil.
Ein Arduino wäre mir leistungstechnisch etwas zu schwach, und ist ebenfalls keine SPS.

Bezüglich Debugging:
Dieses Debugging-Problem existiert vor allem deshalb, weil die heutigen Debugging-Tools zu schlecht sind.
Es wäre technisch ohne weiteres möglich, ausgezeichnete Debugging- und Diagnosetools für eine C/C++-Umgebung zu kreieren. Genau deshalb frage ich explizit nach ausgereiften Umgebungen, und keine Umgebungen wo man C/C++ "irgendwie ausführen" kann.
 
Larzerus schrieb:
Das Debuging einer solchen Lösung ist ein Alptraum.
Zum Vergrößern anklicken....

Ein früherer Kollege von mir ist vor Jahren auf Embedded-Programmierung umgestiegen.
Status und Online-Change weint er heute noch nach.
Interessanterweise haben sie jetzt zum erstenmal einige Projekte im Bereich Warenautomaten mit Raspi und Codesys umgesetzt.
Entwicklungszeiten sind kürzer und Service deutlich einfacher.
 
Mike100 schrieb:
Genau deshalb frage ich explizit nach ausgereiften Umgebungen, und keine Umgebungen wo man C/C++ "irgendwie ausführen" kann.
Zum Vergrößern anklicken....

Mir ist nicht klar was du mit C/C++ willst.
Ob nun C oder ST / SCL ist nun wirklich kein großer Unterschied.
Beides sind einfache, alte Sprachen.
C++ bietet OO, aber das kann Codesys / Twincat auch. Zumindest in dem Umfang der für eine SPS sinnvoll ist.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ich wäre auch mit anderen Sprachen außer C/C++ zufrieden.
Mein wirkliches Ziel ist nicht C, sondern eine moderne IDE mit text-basierten Files.

In Wahrheit halte ich C/C++ sogar für relativ schlechte SPS-Sprachen.
C hat nämlich das Problem, dass die Speicherverwaltung mit Pointern relativ komplex und fehleranfällig ist (für SPS-Zwecke).
C++ hat alle Probleme von C und zusätzlich viele unnötig komplexe Konstrukte (für diese Zwecke).

Der Grund warum ich trotzdem nach C frage ist, weil C sozusagen der kleinste gemeinsame Nenner unter den Programmiersprachen ist.
Ich halte es für wahrscheinlicher, dass ich mein Ziel mit C erreiche, als mit modernen Sprachen.
 
Mike100 schrieb:
Dieses Debugging-Problem existiert vor allem deshalb, weil die heutigen Debugging-Tools zu schlecht sind.
Es wäre technisch ohne weiteres möglich, ausgezeichnete Debugging- und Diagnosetools für eine C/C++-Umgebung zu kreieren.
Zum Vergrößern anklicken....
:confused: Am Anfang dieses Thread hörte es sich so an, als gebe es bereits so wahnsinnig tolle Tools für eine C/C++-Umgebung und sie alle nur deshalb vergeblich darauf warten, endlich die SPS-Welt auf einen zeitgemässen Stand der Technik beamen zu können, weil sich die SPS-Welt so vehement dagegen sperrt?
 
Blockmove schrieb:
Mir ist nicht klar was du mit C/C++ willst.
Ob nun C oder ST / SCL ist nun wirklich kein großer Unterschied.
Beides sind einfache, alte Sprachen.
C++ bietet OO, aber das kann Codesys / Twincat auch. Zumindest in dem Umfang der für eine SPS sinnvoll ist.
Zum Vergrößern anklicken....

All das sind alte Sprachen, aber C ermöglicht die Verwendung von modernen Tools und IDEs.
Mit ST/SCL sind moderne Tools zwar theoretisch ebenfalls möglich, aber nur mit großen Verrenkungen.

Um beim Beispiel Siemens zu bleiben:

- Git-Versionierung ist mit obskuren TIA-Binärdateien nicht sinnvoll möglich.
- TIA zerschießt ständig alte Projekte nach Updates, und aufgrund der Binärdateien gibt es auch kein gutes File-Debugging.
- Für ein gutes C-Tool lese ich ein Zehn-Zeilen-README-File. Für Siemens-Tools lese ich aufgeblähte PDFs mit vollkommen irrelevanten Boilerplate-Infos.
- Einen C-Compiler kann ich jahrelang verwenden, während ich meinen TIA-Code ständig wegwerfen oder re-importieren muss (oder auf noch stärker verbuggten TIA-Alt-Versionen bleiben muss).
- Mit Visual Studio oder Eclipse bin ich bereits mitten im Coding, während TIA noch laden muss oder abstürzt.
- Git-Versionierung funktioniert fehlerfrei und jahrelang stabil für Millionen Developer, während TIA-Multiuser von Beta-Bugs und ausufernder Komplexität geplagt ist (für die Hand voll Lizenzkäufer).
- Ich würde die TIA-Lizenzen nur dann zahlen wollen, wenn das Verhältnis zwischen Funktionalität und Performance stimmen würde.

In anderen Worten: TIA ist unrettbar und muss mittelfristig vollständig ersetzt werden.
Ich halte es für einen großen Fehler von Siemens, dass die alten S7-300 ins TIA gezogen worden sind.
Stattdessen hätte man mit TIA eine moderne Plattform erschaffen sollen, und Step7 für die Altkunden weiterhin supporten können.

Manche SPSler kommen sich gut vor, weil sie mit TIA-Obskuritäten wie "Aufrüstungen", "Abstürzen", "VMs" oder "optimierten Bausteinen" vertraut sind.
Lasst euch gesagt sein: Keine dieser TIA-spezifischen Obskuritäten bringt irgendeinen Business-Value, außer den Zwang, Siemens verwenden zu müssen.
Im 21. Jahrhundert sollte es uns nicht mehr interessieren, auf welchem Offset eine bestimmte Variable steht.
Und wenn TIA-User etwas von Stabilität, Performance und Robustheit reden, dann kann ich nur darüber lachen.
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
Unternehmen wie Google und Microsoft halte ich für wesentlich intelligenter als Siemens.

Microsoft hat mit Visual Studio und VSCode zwei ausgezeichnete IDEs im Angebot, weil sie zur richtigen Zeit die richtigen Spitzen-Programmierer auf die IDE-Projekte angesetzt haben.

Google hat eingesehen, dass sie mit den guten IDEs nicht mithalten können oder wollen, und hat daher Android Studio vom vermutlich weltbesten IDE-Macher "Jetbrains" lizensiert.

Siemens hingegen will nicht einmal mit den guten IDEs mithalten.
TIA Portal ist langsam und instabil, ohne Aussicht auf Besserung.
Siemens ist weder selbst dazu fähig, eine gute IDE zu bauen, noch ist Siemens gewillt mit fähigen IDE-Partnern zu kooperieren (zb. Jetbrains).
Und die Tatsache, dass TIA-Multiuser keine Chance gegen die eiserne Stabilität von Git hat, das sollte jedem TIA-Multiuser ebenfalls bekannt sein.

Was ist der Unterschied zwischen guten IDEs und TIA-Portal?
Gute IDEs werden verwendet, weil sie zur Weltspitze ihrer Klasse zählen. TIA-Portal wird hingegen hauptsächlich aufgrund von Marktzwängen verwendet.
 
Zuletzt bearbeitet:
Ein "Hochsprachenprogrammierer" (Willkommen im Club, Kleiner!), der nicht weiß was er will und sich darüber amüsiert das SPS-Programmierer eigentlich keine Programmierer sind sondern nur Bildchenschubser weil er KOP gesehen hat und glaubt das AWL "aktuell" ist (veraltet, sorry, nur noch aus Kompatibilitätsgründen implementiert, Auslauf ist geplant, aktuell ist FUP&SCL und zukünftig werden komplexe Aufgaben in C/C++ zur Unterstützung innerhalb der SPS umgesetzt).

Ein Mensch, der der Meinung ist das er schlauer ist wie Millionen weil er glaubt das er etwas besser weiß, sich aber darüber im Unklaren ist, das er gegen jahrzehntelanger Entwicklung in einem Bereich hetzt und das Rad mal eben neu erfinden mag, sich aber nicht damit auseinandersetzen will was alles dahinter steckt.

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 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. 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 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.

Ach, da oben tummeln sich so dutzende Aussagen die einfach nicht haltbar sind, fast alle ohne glaubwürdige nachweisbare Begründung.


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.

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.
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.

Alle anderen, alle Siemens-Entwickler, ach, auch hier alle, alle irren sich. Alle liegen falsch, sind ja keine richtigen Programmierer.

Was für ein Projekt Du da auch haben magst, ich tippe darauf es wird ne Haussteuerung, die, sorry, irgendein "Hochsprachenprogrammierer" selbst machen will und ihm alles zu teuer ist was er finden konnte.
 
Mike100 schrieb:
Ich wäre auch mit anderen Sprachen außer C/C++ zufrieden.
Mein wirkliches Ziel ist nicht C, sondern eine moderne IDE mit text-basierten Files.
Zum Vergrößern anklicken....
Wie bereits erwähnt liegt bei Codesys V3 basierten Steuerungen (Beckhoff TC3, WAGO, KEB, usw.) der Quelltext in Textbasierten Dateien (XML) vor und könnte auch ohne IDE bearbeitet werden. Visual Studio wurde ja von Dir schon als moderne IDE benannt, Beckhoff nutzt für TC3 Visual Studio als IDE.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
oliver.tonn schrieb:
Wie bereits erwähnt liegt bei Codesys V3 basierten Steuerungen (Beckhoff TC3, WAGO, KEB, usw.) der Quelltext in Textbasierten Dateien (XML) vor und könnte auch ohne IDE bearbeitet werden. Visual Studio wurde ja von Dir schon als moderne IDE benannt, Beckhoff nutzt für TC3 Visual Studio als IDE.
Zum Vergrößern anklicken....

Genau das ist eine typische SPS-Idiotie (nicht persönlich gemeint, schuld sind die Hersteller):

Quelltext als XML ist schwachsinnig.
Man kann XMLs zwar lesen, aber eine komfortable Editierung mit einer modernen IDE ist mit XMLs nicht möglich.
Wir reden schließlich von echtem Quellcode und nicht von einer XHTML-Website.

Bezüglich Visual Studio:
Beckhoff ist für mich der Einäugige unter den Blinden. Allerdings nicht, weil Beckhoff tatsächlich versteht, was IDE-technisch notwendig wäre, sondern nur um effizienter zu sein.
 
Mike100 schrieb:
Genau das ist eine typische SPS-Idiotie (nicht persönlich gemeint, schuld sind die Hersteller):

Quelltext als XML ist schwachsinnig.
Man kann XMLs zwar lesen, aber eine komfortable Editierung mit einer modernen IDE ist mit XMLs nicht möglich.
Wir reden schließlich von echtem Quellcode und nicht von einer XHTML-Website.
Zum Vergrößern anklicken....
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.
 
oliver.tonn schrieb:
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.
Zum Vergrößern anklicken....

wie er schon selber sagtein Post #6 "Was der Bauer nicht kennt, das frisst er nicht." ;)
 
Zuviel Werbung?
-> Hier kostenlos registrieren
ChristophD schrieb:
wie er schon selber sagtein Post #6 "Was der Bauer nicht kennt, das frisst er nicht." ;)
Zum Vergrößern anklicken....


Das Siemens mit der TIA V16 uns die Möglichkeit gegeben hat, git oder svn zu nutzen, und somit SCL Code zu verfolgen zu können, oder das man theoretisch sich selber mit TIA Openness sich einen SPS Coder in Visual Studio selber entwickeln könnte, muss man ja nicht erwähnen. Da man als 'doofer' SPS Programmierer nicht über den Tellerrand gucken sollte.
Die Programmierung in einer Hochsprache ist in den meisten Anwandungsfälle auch nicht zielführend, da wir in 95% der Anwendungsfälle mit digitalen Signalen arbeiten und diese über UND und ODER Verknüpfungen verarbeiten.
Ein SPS-Code soll ja auch leicht zu verstehen undeine lange Wartbarkeit haben, ob dies mit einer reinen Hochsprache gegeben wäre, mag ich stark zu bezweifeln, da ansonsten es wie in der normalen Software Entwicklung es mehrere Hochsprachen geben würde und alle durcheinander programmieren würde. Dass die SPS-Sprachen standardisiert sind empfinde ich als einen großen Vorteil, da man so Anlagen weltweit verstehen und programmieren kann.
 
Zuletzt bearbeitet:
Tol3l3e schrieb:
Die Programmierung in einer Hochsprache ist in den meisten Anwandungsfälle auch nicht zielführend, da wir in 95% der Anwendungsfälle mit digitalen Signalen arbeiten und diese über UND und ODER Verknüpfungen verarbeiten.
Ein SPS-Code soll ja auch leicht zu verstehen undeine lange Wartbarkeit haben, ob dies mit einer reinen Hochsprache gegeben wäre, mag ich stark zu bezweifeln, da ansonsten es wie in der normalen Software Entwicklung es mehrere Hochsprachen geben würde und alle durcheinander programmieren würde. Dass die SPS-Sprachen standardisiert sind empfinde ich als einen großen Vorteil, da man so Anlagen weltweit verstehen und programmieren kann.
Zum Vergrößern anklicken....

Ich sehe das genauso, aus Erfahrung.

Für jeden zweck das richtige Werkzeug, wer als Werkzeug nur einen Hammer hat, sieht in jedem Problem einen Nagel.

Ich kann auch mit einen Brotmesser einen Baum fällen
und mit der Kettensäge mir meine Scheibe Brot abschneiden.

https://youtu.be/Vj6VBnQNvmY
 
Zuletzt bearbeitet:
Zurück
Oben