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

M

Mike100

Level-1
Beiträge
66
Reaktionspunkte
9
Zuviel Werbung?
-> Hier kostenlos registrieren
Modulare IDE ohne Instabilität und obskuren Binary-Files

Hallo,

Ich bin zwar relativ neu in der SPS-Programmierung, aber ich verabscheue die meisten aktuellen SPS-IDEs (Integrated Development Environment).
Das größte Negativ-Beispiel ist aus meiner Sicht TIA-Portal, welches in diesem Thread ausführlich behandelt wird.

TIA Portal ist meilenweit schlechter als IDEs wie CLion, Eclipse, VSCode, Visual Studio.
Beispiele für die Unterlegenheit TIA Portal: Versionschaos mit ständiger Zerstörung von alten Projekten, sehr schlechte Langzeit-Stabilität (dadurch Workarounds wie VMs mit verschiedenen TIA-Versionen nötig), Obskure Binär-Files anstatt Text-Files, kein guter Git-Versionierungs-Support, instabile monolithische Monster, keine modulare Trennung zwischen Command-Line-Buildchain und IDE-GUI - dadurch sind Custom Tools nur sehr schwer möglich, kein vernünftiges Refactoring/Auto-Complete, kein ordentliches Dependency-Management mit Library-Updates, keine Lightweight-Simulation für schnelle Unit-Tests, gigantische DVD-Downloads, überteuerter Preis, etc. etc.

Um aus der Welt der instabilen Monster-IDEs mit obskuren Binary-Files auszubrechen, sehe ich C/C++ als mögliche Notlösung (sicher keine optimale Lösung!).

Ich möchte eine modulare IDE, bei welcher die kritische Build-Chain von der nicht-kritischen IDE-GUI sauber getrennt ist.
Durch eine modulare und moderne IDE erwarte ich folgende Vorteile:

- Die Build-Chain würde im Falle von IDE-Fehlern immer noch funktionieren.
- Ich hätte keinen Lock-In in eine bestimmte IDE, sondern könnte verschiedene IDEs auf der gleichen Codebasis ausprobieren.
- Die Build-Chain wäre wesentlich leichtgewichtiger und stabiler.
- Ich könnte einzelne Libraries komfortabel und selektiv updaten, anstatt riesige TIA-Updates hineingewürgt zu bekommen.
- Ich könnte eigene Hilfs-Skripte schreiben, weil die Build-Chain im Hintergrund als Command-Line-Tool läuft (zb. Continuous Integration, Tests).
- Im Falle von IDE-Fehlern würde ein einfaches Git-Kommando ausreichen, um alle "temporären" IDE-Files zu löschen und das Projekt neu zu öffnen.
- Der Source-Code wäre einfach lesbar, und nicht auf eine bestimmte Version von TIA beschränkt.

Ich will ebenfalls *nicht* eine pure Mikrocontroller-Platform einsetzen, sondern tatsächlich eine echte SPS programmieren.

Habt ihr Ideen, welches System diese Anforderungen erfüllt?
 
Zuletzt bearbeitet:
vielen dank für die beinahe unterhaltsame jedoch absolut nutzlose einführung.
ich werde nicht weiter antworten.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Wenn so eine C/C++ Programmierung für SPS sinnvoll wäre, dann wäre die schon längst erfunden ;)
Aber vielleicht hat die Welt auf Dich gewartet? ;) Überrasche uns mit guten wartbaren und diagnostizierbaren Libraries! :D Vielleicht kann es wirklich jemand brauchen.

Harald
 
@Mike100

Welche Anwendungen willst du mit einer SPS umsetzen?
Privat für dich oder gewerblich?
Wenn gewerblich, dann denk bitte daran, dass du Programme für Kunden schreibst.
Für SPS-Programme auf C oder C++ Basis ist die Akzeptance im Markt kaum gegeben.

Wenn du unbedingt unter C oder C++ Programmieren willst, dann ist das eigentlich nur eine Frage der passenden Hardware.
Modbus oder CanOpen sind frei verfügbar und due bekommst jegliche Hardware dafür. Bibliotheken und Protokollstacks gibt es für alle Hochsprachen.
Ein normales SPS-Programm ist ja eigentlich nix anderes als eine Endlosschleife :p
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Daher noch einmal zur Klarstellung:
Ich habe danach gefragt, ob es derartige Libraries gibt.
Würden die Hersteller moderne Tools entwickeln, dann wäre die gesamte Automatisierungs-Branche bereits viel weiter fortgeschritten.

Bezüglich Programmiersprachen:
Ich sage nichts gegen FUP.
FUP ist einfach lesbar und für viele Zwecke die richtige Lösung.
Dennoch gibt es Anwendungen, für welche "höhere" Programmiersprachen gefragt sind.
 
Zuletzt bearbeitet:
Blockmove schrieb:
@Mike100
Wenn du unbedingt unter C oder C++ Programmieren willst, dann ist das eigentlich nur eine Frage der passenden Hardware.
Modbus oder CanOpen sind frei verfügbar und due bekommst jegliche Hardware dafür. Bibliotheken und Protokollstacks gibt es für alle Hochsprachen.
Ein normales SPS-Programm ist ja eigentlich nix anderes als eine Endlosschleife :p
Zum Vergrößern anklicken....

Ja, prinzipiell gibt es C-Code für alles.
Die Sache ist aber, dass ich mir keine eigenen Protokoll-Stacks zusammenkopieren will, sondern eine bereits vorgefertigte Umgebung verwenden will.
Ich habe nicht ausreichend Zeit dafür, um schlecht gewartete Bibliotheken aus verschiedensten Quellen zusammenzubasteln.
 
Thomas_v2.1 schrieb:
B+R SPSen kannst du in C programmieren.
Zum Vergrößern anklicken....

Die Frage ist, wie die Tool-Integration dafür aussieht.
Ist es möglich, B+R SPSen *ohne* B&R-Automation-Studio oder sonstigen grafischen Editoren, sondern stattdessen nur mit einfachen, aber gut gewarteten Command-Line-Tools zu programmieren?
(ohne dass ich selbst so ein Tool from Scratch schreiben muss)
 
Mike100 schrieb:
Die Frage ist, wie die Tool-Integration dafür aussieht.
Ist es möglich, B+R SPSen *ohne* B&R-Automation-Studio oder sonstigen grafischen Editoren, sondern stattdessen nur mit einfachen, aber gut gewarteten Command-Line-Tools zu programmieren?
(ohne dass ich selbst so ein Tool from Scratch schreiben muss)
Zum Vergrößern anklicken....

In deinem ersten Beitrag willst du Eclipse und nun Commandline?
Ich denke du solltest mehr Richtung Embedded orientieren.
Dort findest alle deine Wünsche umgesetzt.
Also C, Git, Eclipse, Commandline, Unittests.

Programmierung von Medizintechnik oder auch Baumaschinen.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Mike100 schrieb:
Eine derartige Antwort habe ich mir fast erwartet.
Stumpfsinnig und eingebildet, beschränkt auf den eigenen Blickwinkel.
Was der Bauer nicht kennt, das frisst er nicht.

Ein Blick über den eigenen Tellerrand schadet nicht:
Nur weil die meisten SPS-Programmierer keine Software-Entwickler sind bedeutet das nicht, dass es keinen Bedarf dafür gibt.

Daher noch einmal zur Klarstellung:
Ich habe danach gefragt, ob es derartige Libraries gibt.
Niemand braucht sich von mir überraschen lassen.
Würden die Hersteller moderne Tools entwickeln, dann wäre die gesamte Automatisierungs-Branche bereits viel weiter fortgeschritten.

Bezüglich Programmiersprachen:
Ich sage nichts gegen Kontaktplan/FUP.
Kontaktplan ist einfach lesbar und für viele Zwecke die richtige Lösung.
Dennoch gibt es Anwendungen, für welche "höhere" Programmiersprachen gefragt sind (und AWL zähle ich sicher nicht als "höhere" Programmiersprache).
Zum Vergrößern anklicken....
Wenn Sie derartige Antworten erwartet haben und sich daran stören frage ich mich, warum Sie Ihren Beitrag überhaupt verfasst haben. Übrigens sind wir mitnichten eingebildet und auf den eigenen Blinkwinkel beschränkt und durchaus bereit über den Tellerrand zu schauen.
Was sind denn SPS-Programmierer für Sie? SPS-Programmierung ist auch Softwareentwicklung oder wie glauben Sie entstehen z.B. die Frameworks, die in manchen Firmen erstellt werden um die Arbeit zu erleichtern? Die fallen nicht einfach so vom Himmel, sondern erfordern auch eine gründliche Planung, Realisierung und Tests. Des Weiteren kommen (unter anderem ich) einige von uns aus dem PC Umfeld, haben vorher also objektorientiert Programmiert.
Wenn Sie uns vorwerfen dürfen eingebildet und beschränkt zu sein, müssen Sie sich jetzt jedoch auch leider gefallen lassen schlecht bis gar nicht informiert zu sein, denn Ihre Aussagen sind teilweise schlicht falsch. Es gibt sehr wohl Plugins für Quellcodeverwaltungssysteme, unter anderem für GIT, auch Refaktoring gibt es, wobei hier die Frage wäre was Sie unter vernünftig verstehen, das Selbe gilt übrigens für Auto-Complete. Zumindest bei Codesys V3 basierten Steuerungen liegt der Quellcode nicht im Binärformat vor.
Wie Harald schon schrieb würde es eine allumfassende Nutzung von C/C++ im SPS Bereich schon geben wenn dies sinnvoll wäre, zumal das den Vorteil hätte, dass nur ein System verwendet würde. Außerdem akzeptieren, wie Blockmove schon erwähnte, die Kunden auch nicht unbedingt was Anderes bei SPS Projekten, wo es oft üblich ist, dass auch der Quellcode mit der Anlage geliefert wird und da dann keiner durchsteigen würde wenn auf einmal alles in C/C++ erstellt werden würde. Das wäre so wie wenn im PC-Bereich heute Programme in Fortran, Cobol oder ähnliches geschrieben würden, das würde auch funktionieren, aber in dem Bereich würde das auch kaum noch jemand verstehen oder noch besser, wie im SPS-Bereich üblich mit zyklischer Abarbeitung und in CFC. OOP ist eine tolle Sache und im PC-Bereich absolut sinnvoll und gerechtfertigt, aber im SPS-Bereich eben nicht, da können gewisse Konzepte der OOP sogar sehr gefährlich werden. Wenn ein PC-Programm abstürzt ist das ärgerlich und man verliert mehr oder weniger viele Daten, aber im SPS Umfeld können bei einem Absturz nicht nur Daten verlorengehen, sondern im schlimmsten Fall Leben, weil Abschaltmechanismen nicht mehr funktionieren. Unit-Tests sind meist übrigens nicht sinnvoll, weil die einzelnen Komponenten oft nicht isoliert sinnvoll funktionieren oder getestet werden können, und nur weil der Compiler das nicht zulässt heißt das ja nicht, dass man derartiges in seinem Programm nicht vorsehen kann, außerdem lassen die Entwicklungsumgebungen viele Möglichkeiten für Test zu, es können z.B. Variablen beeinflusst werden
Sie werfen uns vor nicht über den eigenen Tellerrand zu schauen und einen beschränkten Blickwinkel zu haben und unterstreichen dies durch ein Sprichwort. Bitte seien Sie nicht böse, aber diese Vorwürfe können wir ungenutzt zurückgeben. Sie sind ja offensichtlich noch nicht sehr erfahren (wobei sich die Frage stellt wann man das wirklich ist) im SPS Umfeld, führen sich aber so auf, als würden Sie alle Konzepte kennen, verstehen und beurteilen können.
Es lässt sich nicht leugnen, dass gewisse Konzepte sicher modernisierungsbedürftig sind und es durchaus Funktionalitäten gibt bei denen es sinnvoll sein könnte diese zu integrieren. Das Problem bei der Sache ist nur, dass andere Dinge im SPS Bereich wichtiger sind und erst realisiert werden und dadurch andere Dinge hinten runter fallen. Ich bin mir sicher im PC Umfeld ist dies nicht anders, auch da wird es Funktionalitäten geben die sich einige die aus dem SPS Umfeld kommen wünschen würden die es aber auch noch nicht gibt.
Als Friedensangebot würde ich Ihnen empfehlen sich erstmal in die Geschichte der SPS und die allgemeine Thematik, gerne mit unserer Unterstützung, einzuarbeiten, ich bin mir sicher, dass Sie dann etwas anders denken werden. Was Ihre Einstellung zu den Preisen angeht, ist das ein gutes Beispiel woran man einen Laien erkennt. Auch ich habe mich am Anfang gefragt, warum die Komponenten alle so relativ teuer sind, bis ich dann selber ein paar Jahre in der Entwicklungsabteilung eines SPS Herstellers gearbeitet habe und mit eigenen Augen gesehen habe wie groß der Aufwand ist. Nur so zum Vergleich, der zugegebenermaßen etwas hinkt. Ein Netzteil für ein Medizinprodukt ist auch deutlich teurer als eins mit den selben Daten für Strom, Spannung usw. für ein Laptop, weil das Gerät für das Medizingerät wesentlich robuster und besser geprüft sein muss.
Um letztlich doch noch auf Ihre Frage zu antworten. Eine SPS ohne eine SPS-Entwicklungsumgebung zu programmieren gibt es nicht, da dies aufgrund des Funktionsprinzips und Konzepts einer SPS nicht wirklich sinnvoll wäre, bzw. praktisch unmöglich wäre und auch wieder eine extreme Nischenanwendung darstellen würde.
 
Zuletzt bearbeitet:
Mike100 schrieb:
Hallo,

Ich bin zwar relativ neu in der SPS-Programmierung, aber ich habe einen starken Background in C/C++.
Daher möchte ich C oder C++ für die SPS-Programmierung einsetzen.

Außerdem: Ich verabscheue die meisten SPS-IDEs (Integrated Development Environment), weil die meisten SPS-IDEs meilenweit schlechter sind als CLion oder Eclipse.
Beispiele für die Unterlegenheit der SPS-IDEs: Kein vernünftiges Auto-Complete, kein vernünftiges Refactoring, kein guter Unit-Test-Support, kein Git-Versionierungs-Support, keine Lightweight-Simulation für schnelle Unit-Tests, überteuerter Preis, obskure Binär-Files anstatt Text-Files etc. etc.

Mein Problem:
Ich habe zwar SPS-Umgebungen gefunden, mit welchen C/C++ prinzipiell möglich ist, allerdings nur als "Plugin" für verstaubte SPS-IDEs.
Mit solchen Plugins kann ich nichts anfangen, weil dadurch die oben aufgezählten Probleme der verstaubten SPS-IDEs nicht umgangen werden.
Diese Probleme kann ich nur umgehen, wenn ich ein gesamtes SPS-Projekt mit C/C++ *ohne* einer SPS-IDE umsetze.
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.


Das funktioniert aber nur dann, wenn gute Libraries, Template-Projekte und Dokumentation für C/C++ vorhanden sind.
Ich will nämlich weder in die Firmware-Programmierung mit Embedded Linux einsteigen, noch will ich meine eigenen C/C++-Libraries für triviale I/O-Aufgaben schreiben.
In anderen Worten: Ich will keine SPS-Umgebung, wo C/C++ "irgendwie ausführbar ist", sondern eine SPS-Umgebung, wo C/C++ auch tatsächlich ordentlich supported wird.

Ich will ebenfalls *nicht* eine pure Mikrocontroller-Platform einsetzen, sondern tatsächlich eine echte SPS programmieren.

Habt ihr Ideen, welches System diese Anforderungen erfüllt?
Zum Vergrößern anklicken....

Mit einigen Punkten haben Sie durchaus Recht.

Aber die Ansprache!!!

Ich setze das mal um, wie es bei mir ankam:

"Hallöchen Ihr Schnarchnasen,

ihr programmiert ja alle so schön gruselig mit staubigen Primitiv-IDE. Na ja, programmieren kann man sowas eigentlich nicht nennen, ihr kleinen Stümper, aber ich will mal nicht so sein!
Nun gibt es mal Leute wie mich, die Großen sozusagen, die machen alles auf der Command-Line und pushen dann einfach den Code hoch. Natürlich mache ich nur in C/C++ (hier fehlte übrigens der Link zu Wikipedia, was C/C++ ist!) "

Das ist es, was mir so übersetzt im Gedächtnis geblieben ist. Gaaaanz schlechter Anfang, findest du nicht?
Mit den Reaktionen hast du noch Glück gehabt, würde ich mal sagen. *ROFL*

PS: Vor 30 Jahren hatte ich mal ein Gespräch mit einem Prof. für Automatisierungstechnik an einer Uni. Der meiinte dann auch zu mir: "Wir machen alles in C". Na ja, da wundert mich auch nichts mehr.
 
> Wenn Sie derartige Antworten erwartet haben und sich daran stören frage ich mich, warum Sie Ihren Beitrag überhaupt verfasst haben. Übrigens sind wir mitnichten eingebildet und auf den eigenen Blinkwinkel beschränkt und durchaus bereit über den Tellerrand zu schauen.
Zum Vergrößern anklicken....

Sorry, ich möchte keinenfalls einen Vorwurf an alle SPS-Experten machen, sondern nur an solche Experten, welche "neue" Ideen prinzipiell als lächerlich verhöhnen.

> Was sind denn SPS-Programmierer für Sie? SPS-Programmierung ist auch Softwareentwicklung oder wie glauben Sie entstehen z.B. die Frameworks, die in manchen Firmen erstellt werden um die Arbeit zu erleichtern? Die fallen nicht einfach so vom Himmel, sondern erfordern auch eine gründliche Planung, Realisierung und Tests.
Zum Vergrößern anklicken....

Viele dieser Frameworks sind für mich ein Zeugnis für das Versagen der SPS-Hersteller.
Wenn ein mittelständisches Unternehmen Low-Level-I/O-Libraries oder Git-Plugins programmiert, dann ist das zwar schön und gut, aber es zeugt davon, dass Unternehmen wie Siemens bei der Lieferung von trivialen Tools versagt haben.

> OOP ist eine tolle Sache und im PC-Bereich absolut sinnvoll und gerechtfertigt, aber im SPS-Bereich eben nicht, da können gewisse Konzepte der OOP sogar sehr gefährlich werden.
Zum Vergrößern anklicken....

Tatsächlich ist es so, dass mir OOP gar nicht so wichtig ist. Wer will, der kann zwar Vererbung und "virtuelle" Funktionen einsetzen, aber ich halte OOP für kein zentrales Konzept der Programmierung (sondern nur eines von vielen verschiedenen Konzepten).

> Unit-Tests sind meist übrigens nicht sinnvoll, weil die einzelnen Komponenten oft nicht isoliert sinnvoll funktionieren oder getestet werden können, und nur weil der Compiler das nicht zulässt heißt das ja nicht, dass man derartiges in seinem Programm nicht vorsehen kann, außerdem lassen die Entwicklungsumgebungen viele Möglichkeiten für Test zu, es können z.B. Variablen beeinflusst werden
Zum Vergrößern anklicken....

Ja, Unit-Tests sind zwar oft nicht sinnvoll, aber eine schnelle und einfachere Simulation wäre dennoch sinnvoll. Und damit schließe ich aufgeblähte Monster-Programme wie PLCSim-Advanced explizit aus.

> Es lässt sich nicht leugnen, dass gewisse Konzepte sicher modernisierungsbedürftig sind und es durchaus Funktionalitäten gibt bei denen es sinnvoll sein könnte diese zu integrieren. Das Problem bei der Sache ist nur, dass andere Dinge im SPS Bereich wichtiger sind und erst realisiert werden und dadurch andere Dinge hinten runter fallen.
Zum Vergrößern anklicken....

Nach über 30 Jahren Existenz zieht das Argument, dass "andere Dinge wichtiger sind", nicht mehr. Dieses Argument kann man bei einem Startup oder bei einer erst vor kurzem neu etablierten Branche bringen.
Ich habe das Gefühl, dass die Modernisierung durch die etablierten SPS-Hersteller absichtlich eingebremst wird. Beispiel: Warum wird OPC UA als bezahltes Plugin mit Zusatzaufwand angeboten? Diesen Herstellern geht es nicht um einfache Plug-and-play-Connectivity mit möglichst wenig Setup, sondern eher nur um das Ausquetschen von Lizenzgebühren.
> Auch ich habe mich am Anfang gefragt, warum die Komponenten alle so relativ teuer sind, bis ich dann selber ein paar Jahre in der Entwicklungsabteilung eines SPS Herstellers gearbeitet habe und mit eigenen Augen gesehen habe wie groß der Aufwand ist.
Zum Vergrößern anklicken....

Teilweise glaube ich, dass die SPS-Hersteller selbst schuld sind am hohen Aufwand. Beispiel TIA-Portal: Warum programmiert Siemens ein aufwendiges "Multi-user-engineering", anstatt eine einfache Git-Integration zu ermöglichen? Das Ergebnis für die Nutzer ist inferior, obwohl der Aufwand größer ist.
Linus Torvalds hat in wenigen Wochen eine bessere Versions-Verwaltung programmiert, als viele Corporate-Abteilungen mit tausenden Arbeitsstunden. Daher stellt sich die Frage: Warum muss man in dieser Branche ständig das Rad neu erfinden, anstatt von den erfolgreichsten Open-Source-Gewinnern zu kopieren?
> Um letztlich doch noch auf Ihre Frage zu antworten. Eine SPS ohne eine SPS-Entwicklungsumgebung zu programmieren gibt es nicht, da dies aufgrund des Funktionsprinzips und Konzepts einer SPS nicht wirklich sinnvoll wäre, bzw. praktisch unmöglich wäre und auch wieder eine extreme Nischenanwendung darstellen würde.
Zum Vergrößern anklicken....

Ich glaube schon, dass es einen Markt für SPS-Programmierung mit purem C gibt.
Meine Frage ist aber, ob eine freie Auswahl der IDE auf Mikrocontroller beschränkt ist.
 
Zuletzt bearbeitet von einem Moderator:
Zuviel Werbung?
-> Hier kostenlos registrieren
Siemens versuchte ein SPS Variante (M7) auf den Markt zu bringen, der als Alternativ zu S7 sein sollte, und in C/C++ programmierbar war.
Da die Hardware denselbe als S7-300 war und deswegen als Industrietaugllich als möglich war, und von den grossen Marktführer Siemens war, hatte diesen Versuch C/C++ als Steuerungsprogrammiersprache die beste chancen.
Markteindrängung: Annähernd Null.

Mike100 schrieb:
Beispiel: Warum wird OPC UA als bezahltes Plugin mit Zusatzaufwand angeboten? Diesen Herstellern geht es nicht um einfache Plug-and-play-Connectivity mit möglichst wenig Setup, sondern eher nur um das Ausquetschen von Lizenzgebühren.
Zum Vergrößern anklicken....
Die Lizenzen für z.B. OPC UA sind lächerlich.
Du befindest dich in einen anderen Welt wie ich. In meinen welt kümmern meine Kunden sich um Kosten in einen anderen Grössenordnung.
Z.B. eine Stunde Produktionsstopp wegen einen Programmfehler kann 10000'er Euros kosten, oder sogar in die 100000'er Euros gelangen.
Nur um eine Zeitfenster für das einspleisen von Programmänderungen kann man Stundenlang mit die Kunde verhandeln.
 
Mike100 schrieb:
> Wenn Sie derartige Antworten erwartet haben und sich daran stören frage ich mich, warum Sie Ihren Beitrag überhaupt verfasst haben. Übrigens sind wir mitnichten eingebildet und auf den eigenen Blinkwinkel beschränkt und durchaus bereit über den Tellerrand zu schauen.

Sorry, ich möchte keinenfalls einen Vorwurf an alle SPS-Experten machen, sondern nur an solche Experten, welche "neue" Ideen prinzipiell als lächerlich verhöhnen.
Zum Vergrößern anklicken....

Tat hier glaube ich keiner, aufgrund der Berufserfahrung wurde nur angemerkt, dass diese Konzepte im SPS-Umfeld aus verschiedenen Gründen nicht sinnvoll/nützlich sind.
​
Mike100 schrieb:
> Was sind denn SPS-Programmierer für Sie? SPS-Programmierung ist auch Softwareentwicklung oder wie glauben Sie entstehen z.B. die Frameworks, die in manchen Firmen erstellt werden um die Arbeit zu erleichtern? Die fallen nicht einfach so vom Himmel, sondern erfordern auch eine gründliche Planung, Realisierung und Tests.

Viele dieser Frameworks sind für mich ein Zeugnis für das Versagen der SPS-Hersteller.
Wenn ein mittelständisches Unternehmen Low-Level-I/O-Libraries oder Git-Plugins programmiert, dann ist das zwar schön und gut, aber es zeugt davon, dass Unternehmen wie Siemens bei der Lieferung von trivialen Tools versagt haben.
Zum Vergrößern anklicken....

Das Problem dabei ist, dass z.B. von Visual-Studio erheblich mehr Lizenzen (unter anderem an SPS-Hersteller) verkauft werden als SPS-IDEs und somit die Entwicklung eines Frameworks auch finanziell erst möglich ist. Es gibt übrigens auch SPS-Hersteller die Frameworks anbieten, z.B. Schneider Electric bei den PacDrive Steuerungen.
Irgendwie haben Sie ein Talent dazu Leute miss zu verstehen, es sei denn Sie meinten mit Mittelständler die SPS-Hersteller. Ich meinte, dass es von den SPS-Herstellern schon Plugins für GIT und andere Systeme gibt und nicht das die Anwender diese schreiben.
​
Mike100 schrieb:
> Es lässt sich nicht leugnen, dass gewisse Konzepte sicher modernisierungsbedürftig sind und es durchaus Funktionalitäten gibt bei denen es sinnvoll sein könnte diese zu integrieren. Das Problem bei der Sache ist nur, dass andere Dinge im SPS Bereich wichtiger sind und erst realisiert werden und dadurch andere Dinge hinten runter fallen.

Nach über 30 Jahren Existenz zieht das Argument, dass "andere Dinge wichtiger sind", nicht mehr. Dieses Argument kann man bei einem Startup oder bei einer erst vor kurzem neu etablierten Branche bringen.
Ich habe das Gefühl, dass die Modernisierung durch die etablierten SPS-Hersteller absichtlich eingebremst wird. Beispiel: Warum wird OPC UA als bezahltes Plugin mit Zusatzaufwand angeboten? Diesen Herstellern geht es nicht um einfache Plug-and-play-Connectivity mit möglichst wenig Setup, sondern eher nur um das Ausquetschen von Lizenzgebühren.

> Auch ich habe mich am Anfang gefragt, warum die Komponenten alle so relativ teuer sind, bis ich dann selber ein paar Jahre in der Entwicklungsabteilung eines SPS Herstellers gearbeitet habe und mit eigenen Augen gesehen habe wie groß der Aufwand ist.

Teilweise glaube ich, dass die SPS-Hersteller selbst schuld sind am hohen Aufwand. Beispiel TIA-Portal: Warum programmiert Siemens ein aufwendiges "Multi-user-engineering", anstatt eine einfache Git-Integration zu ermöglichen? Das Ergebnis für die Nutzer ist inferior, obwohl der Aufwand größer ist.
Linus Torvalds hat in wenigen Wochen eine bessere Versions-Verwaltung programmiert, als viele Corporate-Abteilungen mit tausenden Arbeitsstunden. Daher stellt sich die Frage: Warum muss man in dieser Branche ständig das Rad neu erfinden, anstatt von den erfolgreichsten Open-Source-Gewinnern zu kopieren?
Zum Vergrößern anklicken....

Auch auf PC-Ebene gibt es Dinge die manche gerne hätten, die aber (noch) nicht realisiert wurden, weil der Markt zu klein war/ist und das auch schon seit vielen Jahren.
Bezüglich Ihrer Äußerung zu den Kosten kann ich nur wiederholen, dass Ihnen einfach die Erfahrung in dem Bereich fehlt um dies objektiv beurteilen zu können. Es fängt schon damit an, dass z.B. Visual-Studio erheblich öfters verkauft wird als eine SPS-IDE und dadurch eine andere Preisgestaltung möglich ist. Und wenn ich mir mal die Kosten für eine VS-Pro Version ansehe und im Vergleich dazu den Preis der TC3 IDE (kostenlos) plus ein paar Zusatzfunktionen (z.B. OPC) vergleiche, sehe ich das Argument teuer nicht wirklich, natürlich kostet die Runtime auf der SPS und die erwähnten Zusatzfunktionen etwas, aber für Windows, SQL-Server und ähnliches muss man ja auch Geld zahlen. Außerdem muss sich VS-Studio selber nicht um die Ansteuerung und Integration von Hardware kümmern, da hier (standardisierte) Schnittstellen der Treiber, die die Hardwarehersteller zur Verfügung stellen, genutzt werden und diese Kosten gar nicht anfallen, bei einem SPS-Hersteller aber schon und die sind, wie gesagt nicht unerheblich. 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. Übrigens entwickeln viele SPS-Hersteller gar nicht komplett selber, sondern passen ein vorhandenes System (Codesys) an, aber das erfolgt dann nur an zwei Stellen und verteilt sich nicht auf zig Entwicklergruppen die vertreut in der Welt sitzen.
​
Mike100 schrieb:
> Um letztlich doch noch auf Ihre Frage zu antworten. Eine SPS ohne eine SPS-Entwicklungsumgebung zu programmieren gibt es nicht, da dies aufgrund des Funktionsprinzips und Konzepts einer SPS nicht wirklich sinnvoll wäre, bzw. praktisch unmöglich wäre und auch wieder eine extreme Nischenanwendung darstellen würde.

Ich glaube schon, dass es einen Markt für SPS-Programmierung mit purem C gibt.
Meine Frage ist aber, ob eine freie Auswahl der IDE auf Mikrocontroller beschränkt ist.
Zum Vergrößern anklicken....
Wie bereits erwähnt, den gibt es wohl, aber der Bedarf dürfte so gering sein, dass sich der Aufwand nicht lohnt.
 
Zuletzt bearbeitet:
Ich Arbeite jetzt seit über 3ß jahren im gleichen Unternehmen, bin über S5 -> S7 und jetzt bei TIA,
ein bisschen eine Fremdsteuerung die ein Maschinbauer selbst gebaut hat (Reines Assembler) und
ein wenig Beckhoff.

Irgendwann haben wir einen neuen Dr. als GF bekommen, der Träumte von einer eignen Steuerung,
da hat er im letzten Jahr externe Dienstleister reingeholt, die uns beibringen sollten wie man in
Hochsprache C#, WPF und C++ Steuerungen programmiert, dieser Dienstleister sollte das Konzept
schon bei anderen Firmen umgesetzt haben.

Als Plattform sollte dann wie benannt B&R (jetzt ja wohl ABB) sein, weil diese C auf Steuerungsebene
können.

Wir wurden über ein Jahr, einmal die Woche geschult von der externen Firma, im ersten Schritt für
die Grundlagen sollte alles Inhouse sein und später alles über Skype.

Die Schulung war meiner Ansicht nach wirklich Grottenschlecht, man bekam kein Stück Papier, wo
man sich hätte mal etwas nachlesen können. Wir sind immer wieder von vorne angefangen.

Im Prinzip sollte dann, sagen wir mal, einfach Maschinen nur noch Konfigurieren anstatt zu Programmieren,
ich sehe da sogar einen Ansatz, wenn man zb. viel Gleichartige Fördertechnik hat, wie am Flughafen.
Leider haben wir solche Anwendungen gar nicht in der Firma.

Die Firma sollte parallel zur Schulung zwei Maschinen fertig machen, wenn Sie dann gestartet haben, hat
es nach mehren Anläufen nicht funktioniert, von HMI wollen wir garnicht reden. Die haben mit zwei bis zu
vier Mann, mehr rum Programmiert, wie wir mit der Konventionellen weise und mussten nicht mal den
steinigen Weg der Entwicklung gehen, sondern hat fertige TIA Projekte als Vorlage. Das heißt. eine Maschine
ist ja nicht fertig wenn das Blech da steht, Antriebstechnik, Pneumatik alles muss ja erst einmal aufeinander
abgestimmt werden, gleich womit man es Programmiert.

Was ich mich auch frage, wie will man in Hochsprache eine Online Diagnose gestalten, also mal eben Kontrollieren,
ob eine Verknüpfung überprüfen ob Sie erfüllt ist (beim Kunden an der Maschine)?

Ich fand es Interessant, aber einen Mehrwert sehe ich da nicht, im Nachhinein waren wir alle der Meinung das
es richtiger Quatsch ist.

Der Dr. ist auch nicht mehr da... wurde gefeuert.
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo,

von Beckhoff wird das seit der Einführung von TwinCAT3 unterstützt. Hat durchaus seine Berechtigung, dass es die Lösung für alles ist bezweifle ich. Dort wird Visual Studio verwendet, ich denke die Umgebung kann man nicht veraltet nennen. Die Anbindung an alle möglichen Source Code Verwaltungen (GIT, SVN, TFS...) ist möglich. Sogar debuggen kann man online und auch Online-Changes sind möglich.

Ist sicher oft eine coole Lösung. Das es generell für eine Maschine Sinn macht bezweifle ich.

Andere System kenne ich zu wenig.
 
Hallo Hack,
Hack schrieb:
Hallo,

von Beckhoff wird das seit der Einführung von TwinCAT3 unterstützt. Hat durchaus seine Berechtigung, dass es die Lösung für alles ist bezweifle ich. Dort wird Visual Studio verwendet, ich denke die Umgebung kann man nicht veraltet nennen.
Zum Vergrößern anklicken....
das ist aber nicht ganz das was der TE wollte, er wollte die SPS ja komplett in C++ programmieren und das ist damit nicht möglich.


Von irgendwas mit Internetzugang gesendet.
 
Wieso soll das nicht möglich sein? Man kann auf I/O's Zugreifen, ADS, FileSystem...
Es gibt halt weniger Bibliotheken, darum muss man vieles selber machen, dass es in der SPS schon gibt.
 
Zurück
Oben