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



## Mike100 (8 Juni 2020)

*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?


----------



## Senator42 (8 Juni 2020)

vielen dank für die beinahe unterhaltsame jedoch absolut nutzlose einführung.
ich werde nicht weiter antworten.


----------



## PN/DP (8 Juni 2020)

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!  Vielleicht kann es wirklich jemand brauchen.

Harald


----------



## Blockmove (8 Juni 2020)

@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


----------



## Thomas_v2.1 (8 Juni 2020)

PN/DP schrieb:


> Wenn so eine C/C++ Programmierung für SPS sinnvoll wäre, dann wäre die schon längst erfunden



B+R SPSen kannst du in C programmieren.


----------



## Mike100 (8 Juni 2020)

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.


----------



## Mike100 (8 Juni 2020)

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



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.


----------



## Mike100 (8 Juni 2020)

Thomas_v2.1 schrieb:


> B+R SPSen kannst du in C programmieren.



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 (8 Juni 2020)

Senator42 schrieb:


> vielen dank für die beinahe unterhaltsame jedoch absolut nutzlose einführung.
> ich werde nicht weiter antworten.



Vielen Dank für die nützliche Antwort.
Es ist immer wieder nützlich, wie offen und hilfsbereit die diversen Fach-Experten sind.


----------



## Blockmove (9 Juni 2020)

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)



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.


----------



## DeltaMikeAir (9 Juni 2020)

Ob das der Bruder von Draco ist??


----------



## oliver.tonn (9 Juni 2020)

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


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.


----------



## Ralle (9 Juni 2020)

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



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.


----------



## Mike100 (9 Juni 2020)

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



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



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



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



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.



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? 


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


----------



## JesperMP (9 Juni 2020)

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.


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.


----------



## oliver.tonn (9 Juni 2020)

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.



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.



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


Wie bereits erwähnt, den gibt es wohl, aber der Bedarf dürfte so gering sein, dass sich der Aufwand nicht lohnt.


----------



## rostiger Nagel (9 Juni 2020)

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.


----------



## Hack (9 Juni 2020)

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.


----------



## oliver.tonn (9 Juni 2020)

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.


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.


----------



## Hack (9 Juni 2020)

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.


----------



## Mike100 (9 Juni 2020)

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


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.


----------



## oliver.tonn (9 Juni 2020)

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.


----------



## Blockmove (9 Juni 2020)

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


----------



## Mrtain (9 Juni 2020)

Mike100 schrieb:


> Dennoch gibt es Anwendungen, für welche "höhere" Programmiersprachen gefragt sind (und AWL zähle ich sicher nicht als "höhere" Programmiersprache).




Nur der Interesse halber, welche wären dass Ihrer Meinung nach?


----------



## Larzerus (9 Juni 2020)

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.


----------



## Mike100 (9 Juni 2020)

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, ….).
> ...



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.


----------



## Blockmove (9 Juni 2020)

Larzerus schrieb:


> Das Debuging einer solchen Lösung ist ein Alptraum.



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.


----------



## Blockmove (9 Juni 2020)

Mike100 schrieb:


> Genau deshalb frage ich explizit nach ausgereiften Umgebungen, und keine Umgebungen wo man C/C++ "irgendwie ausführen" kann.



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.


----------



## Mike100 (9 Juni 2020)

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.


----------



## Heinileini (9 Juni 2020)

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.


 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?


----------



## Mike100 (9 Juni 2020)

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.



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.


----------



## Mike100 (10 Juni 2020)

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.


----------



## escride1 (10 Juni 2020)

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.


----------



## oliver.tonn (10 Juni 2020)

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.


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.


----------



## Mike100 (10 Juni 2020)

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.



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.


----------



## oliver.tonn (10 Juni 2020)

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.


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.


----------



## ChristophD (10 Juni 2020)

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.



wie er schon selber sagtein Post #6 "Was der Bauer nicht kennt, das frisst er nicht."


----------



## Tol3l3e (10 Juni 2020)

ChristophD schrieb:


> wie er schon selber sagtein Post #6 "Was der Bauer nicht kennt, das frisst er nicht."




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.


----------



## rostiger Nagel (10 Juni 2020)

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.



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


----------



## MFreiberger (10 Juni 2020)

Moin rostiger Nagel,



rostiger Nagel schrieb:


> [..]
> und mit der Kettensäge mir meine Scheibe Brot abschneiden.



sag Bescheid, wenn es soweit ist. Das gucke ich mir gerne an 

VG

Mario


----------



## maxder2te (10 Juni 2020)

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


----------



## Blockmove (10 Juni 2020)

maxder2te schrieb:


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


----------



## Hack (10 Juni 2020)

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


----------



## ms_gp (10 Juni 2020)

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.


----------



## escride1 (10 Juni 2020)

ms_gp schrieb:


> Ich weiß schon, dass der Mike100 hier nur provozieren wollte und das dieser Thread jetzt langsam ins philosophische abgleitet...



Und was willst Du nun gerade wenn Du doch eh den gleichen Unfug schreibst?


----------



## DeltaMikeAir (10 Juni 2020)

escride1 schrieb:


> Und was willst Du nun gerade wenn Du doch eh den gleichen Unfug schreibst?



Ist doch schön wenn sich einer nahtlos anschließt


----------



## rostiger Nagel (10 Juni 2020)

ms_gp schrieb:


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


----------



## escride1 (10 Juni 2020)

rostiger Nagel schrieb:


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



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.


----------



## Mike100 (10 Juni 2020)

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.



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.


----------



## Mike100 (10 Juni 2020)

ms_gp schrieb:


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


----------



## oliver.tonn (10 Juni 2020)

Mike100 schrieb:


> Die Debugging-Fähigkeit auf File-Ebene ist hingegen katastrophal bei TIA-Portal.


Ich kenne TIA jetzt nicht wirklich, frage mich aber grundsätzlich, was man auf Dateiebene debuggen soll/muss.

Von irgendwas mit Internetzugang gesendet.


----------



## Mike100 (10 Juni 2020)

oliver.tonn schrieb:


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


----------



## Mike100 (10 Juni 2020)

ms_gp schrieb:


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


----------



## rostiger Nagel (10 Juni 2020)

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?


----------



## Peter Gedöns (10 Juni 2020)

der arbeitet doch nicht mit TIA 
wie kommst auf die Idee ?


----------



## Mike100 (10 Juni 2020)

rostiger Nagel schrieb:


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


----------



## PN/DP (10 Juni 2020)

Mike100 schrieb:


> Ich bin zwar relativ neu in der SPS-Programmierung





Mike100 schrieb:


> bei TIA-Portal, wo Abstürze und inkompatible Binary-Files an der Tagesordnung stehen.





Mike100 schrieb:


> 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


----------



## Mike100 (10 Juni 2020)

Peter Gedöns schrieb:


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


----------



## rostiger Nagel (10 Juni 2020)

Mike100 schrieb:


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



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.


----------



## rostiger Nagel (10 Juni 2020)

Zur Performance, Visual Studio finde ich noch langsamer als TIA.


----------



## Blockmove (10 Juni 2020)

Mike100 schrieb:


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



Jetzt wird es aber langsam unsachlich.
Wieviel Versionen vom .NET-Framework gibt es in der Zwischenzeit?
Wie sieht es da mit Rückwärtskompatibilität aus?
Ich hab da auch schon Stunden in der Versionshölle verbracht.
Das selbe Thema gibt es bei anderen Frameworks genauso.


----------



## Mike100 (10 Juni 2020)

Blockmove schrieb:


> Jetzt wird es aber langsam unsachlich.
> Wieviel Versionen vom .NET-Framework gibt es in der Zwischenzeit?
> Wie sieht es da mit Rückwärtskompatibilität aus?
> Ich hab da auch schon Stunden in der Versionshölle verbracht.
> Das selbe Thema gibt es bei anderen Frameworks genauso.



Ich weiß nicht, wie es mit .NET auf DLL-Ebene aussieht, aber zumindest auf Code-Ebene ist C# sehr stabil.
Es ist problemlos möglich, alten C#-Code auf die neueste Version hochzuziehen. Falls es Fehler gibt, dann zeigt mir der C#-Compiler exakt die Position des Fehlers, und der Fix ist meistens trivial. Falls es doch nicht trivial ist, dann hat die C#-Codebasis eine Komplexität, bei welcher es TIA schon hundert Mal zerlegt hätte.

Vergleich mit TIA: Der Code besteht aus obskuren Binärfiles, eine formale Spec ist non-existent, und die Upgrades sind wie ein russisches Roulette-Spiel.


----------



## ms_gp (10 Juni 2020)

Unsachlich auf jeden Fall. Er ist halt sehr frustriert und desillusioniert. War ich auch damals . 

Aber ich stimme ihm in manchen Punkte inhaltlich trotzdem zu, z.B. dass da bei SIEMENS durchaus Absicht dahinterstecken könnte. Betonung auf könnte! Und ja, die Installationsdateien von TIA sind riesig und die Installation dauert ewig. Und man fragt sie wofür, weil soviel steckt da ja gar nicht drin.

SIEMENS hat sich ganz bewusst für ein monolithisches Projekt-System (also wie ein TIA-Projekt Datentechnisch unter der Haube aussieht) entschieden. Und das obwohl es bei Step7 Classic ja nicht so war, da war ja jeder Baustein eine Datei. Und das fällt ihnen jetzt auf die Füße.
Und das meinte ich weiter oben auch damit, dass SIEMENS nicht so offen ist. Ich kann nicht einfach eine einen Baustein exportieren und in ein anderes Steuerungssystem importieren. Obwohl das ja gehen müsste, weil alles toll IEC-61131.
Codesys/Twincat ist genau den anderen Weg gegangen und aus den *.pro Dateien wurde ein Projekt, bei dem jedes Element eine Datei ist.
Und hier kann auch einfach Bausteine im PLCOpen Format exportieren und woanders importieren(außer SIEMENS natürlich).

Das das dann alles XML-Dateien sind, darüber kann ja meckern, aber solange es Text ist, ist es doch Ok für die Versionsverwaltungssysteme.


Aber nicht falsch verstehen. TIA kann man trotzdem produktiv nutzen und es hat auch seine Stärken. Besonders im Safety-Bereich. Aber ein gutes Beispiel für eine ordentliche IDE und ein gutes Programmiersystem ist es eben nicht, weder für SPS Programmierung noch für etwas anderes.


----------



## Mike100 (10 Juni 2020)

Ralle schrieb:


> Mit einigen Punkten haben Sie durchaus Recht.
> 
> Aber die Ansprache!!!
> 
> ...



Mit dieser Interpretation liegst du nicht so falsch 
Aber trotzdem zur Klarstellung:

Ich respektiere SPS-Programmierung als Beruf, weil es jahrelange Expertise und Know-How benötigt.
Die Stärken von SPS-Programmierern liegen in der Industrie und in der Elektrotechnik.
Trotzdem gehe ich soweit zu behaupten, dass die meisten TIA-Jünger von guten IDEs keinen Tau haben, und schon gar nicht von guter Versionskontrolle und Portabilität einen Tau haben.
Wenn ein TIA-Jünger von Stabilität und Robustheit redet, dann kann ich nur darüber lachen.
Codesys- oder Twincat-Benutzer kann ich eher noch ernst nehmen bezüglich IDE.

C/C++ sehe ich übrigens nur als Notlösung. 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.


----------



## wollvieh (10 Juni 2020)

Wo liegen Deine Stärken, was hast Du für eine geniale IDE im Einsatz?
P.S.: Was ist TIA? ;-)


----------



## Mike100 (10 Juni 2020)

ms_gp schrieb:


> Unsachlich auf jeden Fall. Er ist halt sehr frustriert und desillusioniert. War ich auch damals .
> 
> Aber ich stimme ihm in manchen Punkte inhaltlich trotzdem zu, z.B. dass da bei SIEMENS durchaus Absicht dahinterstecken könnte. Betonung auf könnte! Und ja, die Installationsdateien von TIA sind riesig und die Installation dauert ewig. Und man fragt sie wofür, weil soviel steckt da ja gar nicht drin.
> 
> ...



Genau das wollte ich ebenfalls sagen, allerdings mit einer schärferen Sprache.
Ich bin bei Leibe kein C-Freak, sondern habe C nur als Notlösung für den Ausstieg aus TIA-ähnlichen IDEs gesehen.

Obwohl TIA für mich das Negativbeispiel Nummer 1 ist, komme ich nicht darum herum, auch gegen Codesys/Twincat herzuziehen.
Die Tatsache, dass einzelne Bausteine exportiert werden können, ist zwar gut und schön, aber keine echte Kompatibilität.
Ein seriöses Baustein-Format müsste über mehrere IDEs unverändert funktionieren, aber daran sind die SPS-Hersteller nicht interessiert.
Und viele TIA-Jünger sind auch damit zufrieden, sich in die Abhängigkeit eines monolithischen Multi-DVD-Downloads mit zweifelhafter Stabilität zu fesseln.

Bereits die Download-Seite von TIA-V15 zeigt, dass Siemens die letzten Jahrzehnte verschlafen hat.
Multi-Gigabyte-Downloads als DVD-Files... Wer bitte verwendet noch DVDs für Softwareinstallationen?! 

Und die TIA-Extension-Packs fühlen sich ebenfalls wie aufgeblähte Bruchstücke an, und nicht wie stabile Software.
Sowohl Git-Export als auch TIA-Openness sind eine Farce.
Eine seriöse IDE braucht keinen manuellen Git-Export, sondern funktioniert mit Git ohne manuellen Import/Export-Schritten.
Und TIA-Openness ist ein Inter-Process-Communication-Gefrickele anstatt ein einfaches Handieren von Projektdaten.


----------



## Mike100 (10 Juni 2020)

Teile meiner Negativ-Infos gegen TIA-Portal beziehe ich auch aus Insider-Informationen.

Ein Ex-Studienkollege von mir hat eine Zeit lang bei Siemens Digital Industries als Entwickler gearbeitet. Er hat ein Hilfs-Tool geschrieben, um gewisse Projekt-Informationen für TIA-Kunden zu analysieren.
Er hat Monate damit verbracht, mit obskuren TIA-Projekt-Binaries zu kämpfen.
Herausgekommen ist ein Tool, welches zwar irgendwie funktioniert hat, aber keine gute User Experience geboten hat.
Das Tool ist niemals zu Kunden ausgeliefert worden, weil die Probleme mit Inkompatibilitäten am Ende den Nutzen überwiegt haben (das Tool war außerhalb von TIA, aber hat TIA-Projekt-Binaries geparsed).
Die Kunden verwenden für diesen Zweck jetzt noch weiterhin Excel-Sheets außerhalb von TIA.

Außerdem habe ich erfahren, dass TIA als monolithisches Monster kaum mehr wartbar ist und Agilität für die Siemens-internen TIA-Devs nur mehr ein Fremdwort ist.
Ich kann mir nicht vorstellen, dass ein Siemens-Entwickler mit gutem Gewissen das Büro verlässt und behauptet: "Wir entwickeln mit TIA eine gute Software".


Mit anderen Worten:
Die Software-Architektur von TIA ist so verzwickt, dass nicht nur Third-Party-Tools bewusst abgewürgt werden, sondern auch Siemens-interne Initiativen zur Innovation abgewürgt werden.
TIA ist in meinen Augen eine Totgeburt und muss mittelfristig abgelöst werden.


----------



## zako (10 Juni 2020)

Mike100 schrieb:


> Teile meiner Negativ-Infos gegen TIA-Portal beziehe ich auch aus Insider-Informationen.
> 
> Ein Ex-Studienkollege von mir hat eine Zeit lang bei Siemens Digital Industries als Entwickler gearbeitet. Er hat ein Hilfs-Tool geschrieben, um gewisse Projekt-Informationen für TIA-Kunden zu analysieren.
> Er hat Monate damit verbracht, mit obskuren TIA-Projekt-Binaries zu kämpfen.
> ...



… okay jetzt verstehe ich langsam warum Du hier gar so ablederst. Du hast also einen alten Kumpel, der die Aufgabe hatte ein Tool für TIA zu entwickeln, das aber hinterher unbrauchbar war, weil er anscheinend die Softwarestruktur auch nicht umrissen hat. In dieser Funktion ist er mittlerweile auch nicht mehr (okay entweder wollte man ihn nicht mehr, oder er hat selbst aufgegeben). 
Jetzt hat der sich bei Dir also ausgeheult und die spielst jetzt den großen Rächer. 

Vielleicht bist Du jetzt noch nicht so alt und erfahren. Aber ich möchte Dir und Deinen Kumpel folgendes mitgeben. Bei neuen Arbeitgebern ledere nicht über Deinen vorherigen Arbeitgeber ab. Das kommt immer schlecht an und wenn man sich dann auch noch selbst mit einigen Aussagen disqualifiziert ist das umso beschämender.


----------



## Mike100 (10 Juni 2020)

zako schrieb:


> … okay jetzt verstehe ich langsam warum Du hier gar so ablederst. Du hast also einen alten Kumpel, der die Aufgabe hatte ein Tool für TIA zu entwickeln, das aber hinterher unbrauchbar war, weil er anscheinend die Softwarestruktur auch nicht umrissen hat. In dieser Funktion ist er mittlerweile auch nicht mehr (okay entweder wollte man ihn nicht mehr, oder er hat selbst aufgegeben).
> Jetzt hat der sich bei Dir also ausgeheult und die spielst jetzt den großen Rächer.
> 
> Vielleicht bist Du jetzt noch nicht so alt und erfahren. Aber ich möchte Dir und Deinen Kumpel folgendes mitgeben. Bei neuen Arbeitgebern ledere nicht über Deinen vorherigen Arbeitgeber ab. Das kommt immer schlecht an und wenn man sich dann auch noch selbst mit einigen Aussagen disqualifiziert ist das umso beschämender.



Richtig. Er ist nicht gekündigt worden, sondern hat selbst das Handtuch geworfen. 

Ein weiteres Siemens-internes Tool, wo ich vom Scheitern weiß, ist eine TIA-Integration mit gewissen Industrierobotern.
Auch hier waren die Gründe ähnlich: Obskure Binary-Files, deren Format sogar innerhalb von Siemens kaum jemand kennt.
Die "Specs" für dieses File-Format ist das "TIA-Persistenz-Layer" aus zigtausenden Zeilen C#-Code. Soll heißen, es gibt keine vernünftige Spec, was auch mit ein Grund für das ständige Zerschießen von TIA-Projekten ist.
Theoretisch könnte man zwar alles reverse-engineeren, aber die reverse-engineerten Tools können bei jedem TIA-Update wieder zerstört werden.

Glaubt ihr, dass Siemens-Entwickler mit diesem Trümmerhaufen besser klarkommen als externe Entwickler?
Die Antwort ist nein, weil sonst würde man nicht die schlecht gewartete Open Source Library "Snap7" innerhalb von Siemens verwenden.

Es dauert Monate, um als Siemens-Entwickler irgendeinen Code ins TIA-Portal zu mergen. Was auch gut ist, weil sonst würde das fragile Kartenhaus in sich zusammenbrechen. Gleichzeitig zeigt sich aber immer stärker, dass das TIA Portal für moderne Anforderungen gescheitert ist.

Das Unix-Prinzip ist: "Do one thing and do it well."
Das TIA-Prinzip ist: "Try everything and do it slow."

BTW: Vielleicht sollten wir diesen Thread ins TIA-Forum verschieben, wäre interessant zu sehen wie die blinden TIA-Jünger reagieren


----------



## oliver.tonn (11 Juni 2020)

Mike100 schrieb:


> BTW: Vielleicht sollten wir diesen Thread ins TIA-Forum verschieben, wäre interessant zu sehen wie die blinden TIA-Jünger reagieren


Es wäre schön, wenn Du mal die Keule oder den Holzhammer einpacken würdest und etwas gemäßigter und differenzierter agieren würdest. Falls es Dein Ziel ist von den Admins irgendwann geblockt zu werden bist Du, meiner Meinung nach, auf dem besten Weg. Niemand (zumindest fast) hat hier Probleme mit einer anderen Meinung oder Kritik, aber der Ton macht die Musik.
Ich hoffe diese Aussage ist nicht pauschal gemeint. Die wenigsten halten TIA oder Codesys Derivate für ein Allheilmittel und erkennen auch an, dass die Systeme ihre Schwächen aber auch stärken haben. Völlig nutzlos, wie Du es einem immer weiß machen willst, sind die Systeme definitiv nicht, denn sonnst würden wir damit kein Projekt erfolgreich fertig kriegen und das tun wir definiv.


Von irgendwas mit Internetzugang gesendet.


----------



## Blockmove (11 Juni 2020)

Ich hab mal mit 2 Bekannten aus der Embedded-Entwicklung gesprochen und sie gebeten den Thread mal zu lesen.
Einer der beiden macht Software für Baumaschinen, der andere macht viel im Bereich Medizintechnik.
Deren gemeinsames Fazit:
Mike100 hat im Punkt Quellcodeverwaltung und -Versionierung recht, da natürlich die meisten Quellcode-Files reine Textdateien sind.
Sobald aber irgendwelche Bedienoberflächen dazukommen, sieht die Welt wieder anders aus. Hier gibt es diverse Formate (inkl. Bin-Files).
Was die Entwicklngsumgebungen und die Tools angeht, stehen sie hier vor dem genau gleichem Problem wie wir auch.
Um eine Software für ein Produkt (egal ob Kran oder Dosierpumpe für Medikamente) über Jahre zu pflegen und Supporten, müssen beim Make-Prozess immer die gleichen Bin-Files erzeugt werden.
Daher gibt es im Entwicklungsprozess einen Freeze für Entwicklungssystem, eingesetzte Tools, Frameworks und Bibliotheken. Hier wird genauso mit VMs gearbeitet, wie es viele von uns auch tun.


Für mich als SPS'ler stellt es sich so dar, dass die Kollegen eigentlich noch mehr Probleme mit dem Softwareumfeld haben als wir.

Gruß
Blockmove


----------



## olliew (11 Juni 2020)

Blockmove schrieb:


> Daher gibt es im Entwicklungsprozess einen Freeze für Entwicklungssystem, eingesetzte Tools, Frameworks und Bibliotheken. Hier wird genauso mit VMs gearbeitet, wie es viele von uns auch tun.



Betriebssystem nicht vergessen.  Gibt z.B. das eine oder andere Produkt das in den 90'er entwickelt wurde (MS-DOS, klingelt da etwas?) und heute immer noch 'aktiv' ist.



Blockmove schrieb:


> Für mich als SPS'ler stellt es sich so dar, dass die Kollegen eigentlich noch mehr Probleme mit dem Softwareumfeld haben als wir.



Sagen wir mal so, langfristige Verfügbarkeit ist schon etwas feines


----------



## Mike100 (11 Juni 2020)

Blockmove schrieb:


> Ich hab mal mit 2 Bekannten aus der Embedded-Entwicklung gesprochen und sie gebeten den Thread mal zu lesen.
> Einer der beiden macht Software für Baumaschinen, der andere macht viel im Bereich Medizintechnik.
> Deren gemeinsames Fazit:
> Mike100 hat im Punkt Quellcodeverwaltung und -Versionierung recht, da natürlich die meisten Quellcode-Files reine Textdateien sind.
> ...



Ich glaube, dass die Embedded Entwicklung sehr vielfältig ist und daher ein allgemeiner Vergleich nicht möglich ist. 
Quellcode-Verwaltung ist mit C natürlich besser als mit TIA-Portal-ähnlichen IDEs.

Make ist zwar ein sehr altes Build-Tool, aber trotzdem noch halbwegs brauchbar. Im Gegensatz zu TIA weiß man bei Make wenigstens was im Hintergrund passiert (nämlich ein Directed Acyclic Graph aus Files mit Last-Modified-Timestamps).

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.

Wenn man Tests hat, dann sehe ich eine Änderung der Build-Umgebung als unproblematisch. Ich kann beispielsweise auf eine neue Version des GCC-Compilers upgraden, und wenn alle Tests immer noch passen, dann kann ich mit hoher Sicherheit sagen dass der neue GCC-Compiler funktioniert (für mein Projekt).

Einen "Tool-Freeze" mit VMs halte ich nicht für zielführend. Was soll dadurch gewonnen werden, dass mit historischen Versionen von Make/GCC/Linux gearbeitet wird?
Qualität sollte auf andere Art gesichert werden, und nicht durch einen erzwungenen Total-Stillstand in irgendeiner zehn Jahre alten Linux-Distribution. Wenn "never touch anything" das Hauptmotto ist, dann ist es bezüglich Testabdeckung und Codestrukturierung vermutlich ziemlich dürr.

Abschließend noch zum Thema Bedienoberflächen/Visualisierung:

Ich halte es für sinnvoll, die Visualisierung vom Embedded-Core oder SPS-Programm möglichst gut zu trennen (hinsichtlich Software-Architektur).
Im Gegensatz dazu halte ich den TIA-WinCC-Weg für den falschen Weg hinsichtlich skalierbarer Programmierung in Teams.
Denn auch bei Visualisierungen halte ich obskure Binaries für den falschen Weg.

Dazu passend ein Beispiel aus der Smartphone-Welt:
Apple hat vor kurzem iOS-Storyboards durch iOS-SwiftUI ersetzt. Seitdem können komplexe iOS-Apps mit menschenlesbaren Textfiles programmiert werden, und siehe da: Die Developer Experience ist viel besser als vorher, und fast kein iOS-Dev will jemals zurück zu Storyboards.
SwiftUI und React sind auf einem so hohen Niveau, dass TIA WinCC nicht einmal in einem Paralleluniversum auch nur annähernd mithalten könnte.

Und nachdem Siemens bereits TIA-WinCC, TIA-Openness, TIA-Git-Extensions und TIA-Multiuser hinsichtlich Developer Experience und Robustheit vermasselt hat, weiß ich gar nicht mehr, ob TIA überhaupt zu exzellenten Developer-Tools fähig ist.
Exzellente Developer-Tools funktionieren todsicher und skalieren in großen Teams, während TIA-Tools meistens nur im Happy-Case unter bestimmten Preconditions funktionieren.


----------



## Thomas_v2.1 (11 Juni 2020)

Mike100 schrieb:


> 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.
> 
> Wenn man Tests hat, dann sehe ich eine Änderung der Build-Umgebung als unproblematisch. Ich kann beispielsweise auf eine neue Version des GCC-Compilers upgraden, und wenn alle Tests immer noch passen, dann kann ich mit hoher Sicherheit sagen dass der neue GCC-Compiler funktioniert (für mein Projekt).



Wenn dir ein Kunde ein Fehler berichtet und du das nachstellen können willst, dann ist es hilfreich die genau gleiche Umgebung zu besitzen mit der das Binary damals erstellt wurde um ggf. bis auf Assembler-Ebene nachvollziehen zu können wo der Fehler liegt. Ein kleines GCC Update nimmt beispielsweise eine Optimierung etwas anders vor, was beim Ergebnis und bei deinen Testfunktionen zwar erst mal das gleiche ergibt, aber unter Umständen zu Seiteneffekten führen kann.


----------



## Blockmove (11 Juni 2020)

Mike100 schrieb:


> Ich glaube, dass die Embedded Entwicklung sehr vielfältig ist und daher ein allgemeiner Vergleich nicht möglich ist.
> Quellcode-Verwaltung ist mit C natürlich besser als mit TIA-Portal-ähnlichen IDEs.
> 
> Make ist zwar ein sehr altes Build-Tool, aber trotzdem noch halbwegs brauchbar.
> ...



Wie lange bist du eigentlich schon im Berufsleben und wieviele professionelle / gewerbliche Projekte (egal ob nun PC oder PLC) hast du umgesetzt und über einen langen Zeitraum betreut?
Wenn Software oder Geräte beim Kunden im Einsatz sind, dann musst du Produktpflege und Betreuung machen können.
Genauso wenig wie ich eine Anlage von TIA13 auf TIA16 wegen einer kleinen Änderung hochrüste, aktualisiert mein Bekannter seine Toolchain für ein Steuergerät in einem 8 Jahre alten Autokran.
Bei Medizintechnik ist's noch ne Runde komplexer.

Fazit:
Selbst in Bereichen die mit "richtigen" IDE's arbeiten, mit "richtigen" Programmiersprachen, mit "richtiger" Versionsverwaltung und mit Unit-Tests treten in der Realität genau die selben Themen auf, wie wir sie in der SPS-Welt haben.


----------



## Thomas_v2.1 (11 Juni 2020)

maxder2te schrieb:


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



malloc ist eine Funktion aus der Standardbibliothek, du kannst dir auch deine eigene malloc Funktion in der SPS nachbilden. Dazu legst du dir z.B. zu Beginn bei einer S7 einen sehr großen Datenbaustein an, und verteilst daraus den Speicher, das ist also keine Sprachbeschränkung sondern nur das Fehlen einer Funktion aus einer Bibliothek. Es gibt aber etliche Konzepte die zum eigentlich sehr beschränkten Sprachumgfang von C gehören, die du in ST nicht hast. Z.B. Funktionszeiger, was es auch erlaubt in C quasi-objektorientiert mit Methoden usw. zu programmieren, in dem in einer einfachen Struct nicht nur Variablen sondern auch Funktionszeiger für die Methoden gespeichert werden (wird von GTK in der Art so gemacht).

Ob man das alles auch in einer SPS haben muss sei dahingestellt. Das beißt sich auch etwas mit dem Online-Ändern von Programmteilen, bzw. wird zumindest schwierig vom unterlagerten Betriebssystem da jeden Zustand zuverlässig abzufangen, wenn über Zeiger Speicheradressen gespeichert werden die sich beim Online-Ändern ändern können.


----------



## Mike100 (11 Juni 2020)

Thomas_v2.1 schrieb:


> malloc ist eine Funktion aus der Standardbibliothek, du kannst dir auch deine eigene malloc Funktion in der SPS nachbilden. Dazu legst du dir z.B. zu Beginn bei einer S7 einen sehr großen Datenbaustein an, und verteilst daraus den Speicher, das ist also keine Sprachbeschränkung sondern nur das Fehlen einer Funktion aus einer Bibliothek. Es gibt aber etliche Konzepte die zum eigentlich sehr beschränkten Sprachumgfang von C gehören, die du in ST nicht hast. Z.B. Funktionszeiger, was es auch erlaubt in C quasi-objektorientiert mit Methoden usw. zu programmieren, in dem in einer einfachen Struct nicht nur Variablen sondern auch Funktionszeiger für die Methoden gespeichert werden (wird von GTK in der Art so gemacht).
> 
> Ob man das alles auch in einer SPS haben muss sei dahingestellt. Das beißt sich auch etwas mit dem Online-Ändern von Programmteilen, bzw. wird zumindest schwierig vom unterlagerten Betriebssystem da jeden Zustand zuverlässig abzufangen, wenn über Zeiger Speicheradressen gespeichert werden die sich beim Online-Ändern ändern können.



Ich weiß zwar nicht, ob man malloc-ähnliche Funktionen in einer SPS haben will, aber dieses Beispiel ist Teil einer größeren Problematik:
SPS-IDEs haben ein sehr mangelhaftes Dependency-Management-System.
Wenn ich den "Library-Import" in TIA-Portal mit modernen Package-Managern wie NPM, Gradle oder SPM vergleiche, dann bekomme ich bereits beim Zusehen Brechreiz. 😫
Wie stellt sich Siemens eine Aktualisierung von Libraries vor?
Nicht durch einen einfachen Pull von Library-Updates, sondern durch fragile Click-Import-GUIs oder tiefgreifende TIA-Aufrüstungen. 🤦🤦


----------



## Blockmove (11 Juni 2020)

Mike100 schrieb:


> Ich weiß zwar nicht, ob man malloc-ähnliche Funktionen in einer SPS haben will, aber dieses Beispiel ist Teil einer größeren Problematik:
> SPS-IDEs haben ein sehr mangelhaftes Dependency-Management-System.
> Wenn ich den "Library-Import" in TIA-Portal mit modernen Package-Managern wie NPM, Gradle oder SPM vergleiche, dann bekomme ich bereits beim Zusehen Brechreiz.
> Wie stellt sich Siemens eine Aktualisierung von Libraries vor?
> Nicht durch einen automatisierten Pull von Library-Updates, sondern durch fragile manuelle Import-Steps oder tiefgreifende TIA-Aufrüstungen.



An dem Tag an dem mir eine SPS-Entwicklungsumgebung automatisch Bibliotheken in einem Projekten hochrüstet, fliegt sie von der Platte.
Du hast echt keine Ahnung von Anforderungen und Erfordernissen in Anlagen-, Maschinenbau und Instandhaltung.


----------



## Thomas_v2.1 (11 Juni 2020)

Mike100 schrieb:


> Wie stellt sich Siemens eine Aktualisierung von Libraries vor?
> Nicht durch einen automatisierten Pull von Library-Updates, sondern durch fragile manuelle Import-Steps oder tiefgreifende TIA-Aufrüstungen. 🤦🤦


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.


----------



## Mike100 (11 Juni 2020)

Blockmove schrieb:


> An dem Tag an dem mir eine SPS-Entwicklungsumgebung automatisch Bibliotheken in einem Projekten hochrüstet, fliegt sie von der Platte.
> Du hast echt keine Ahnung von Anforderungen und Erfordernissen in Anlagen-, Maschinenbau und Instandhaltung.



Du hast mich hier falsch verstanden. 
Ich fordere keine automatische Aufrüstung von Bibliotheken, sondern eine manuell getriggerte automatische Aufrüstung. 
Dadurch kann ich Minor-Library-Updates mit einem einzigen Kommando einspielen, und habe immer noch die volle Kontrolle darüber.

Tatsächlich hat man mit vernünftigen Package-Managern sogar viel mehr Kontrolle als mit TIA-Portal, weil man einzelne Libraries selektiv updaten kann, anstatt Monster-Updates von TIA hineingewürgt zu bekommen.


----------



## JesperMP (11 Juni 2020)

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:


Mike100 schrieb:


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


Fazit, "pushing" ist nicht erlaubt.

Mike100, welchen Art Maschinen oder Anlagen handelt es um ?


----------



## Mike100 (11 Juni 2020)

Thomas_v2.1 schrieb:


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


----------



## oliver.tonn (11 Juni 2020)

Mike100 schrieb:


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


----------



## Blockmove (11 Juni 2020)

oliver.tonn schrieb:


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


----------



## Mike100 (11 Juni 2020)

oliver.tonn schrieb:


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


----------



## Mrtain (11 Juni 2020)

Mike100 schrieb:


> Ich respektiere SPS-Programmierung als Beruf... .



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



Mike100 schrieb:


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


----------



## Mike100 (11 Juni 2020)

Mrtain schrieb:


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


----------



## Mike100 (11 Juni 2020)

JesperMP schrieb:


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



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


----------



## Mrtain (11 Juni 2020)

Mike100 schrieb:


> 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


----------



## Mike100 (11 Juni 2020)

Mrtain schrieb:


> 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



Welche Sprache setzt du für einfache SPS-Zwecke ein?
Programmierst du alles mit ST/SCL?


----------



## Ralle (11 Juni 2020)

Mike100 schrieb:


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



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


----------



## Mrtain (11 Juni 2020)

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.


----------



## Mike100 (11 Juni 2020)

escride1 schrieb:


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



escride1 schrieb:


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



escride1 schrieb:


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



escride1 schrieb:


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




escride1 schrieb:


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


----------



## Mike100 (11 Juni 2020)

Mrtain schrieb:


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


----------



## Mike100 (11 Juni 2020)

Ralle schrieb:


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



Ralle schrieb:


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




Ralle schrieb:


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



Ralle schrieb:


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



Ralle schrieb:


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



Ralle schrieb:


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


----------



## JesperMP (11 Juni 2020)

Mike100 schrieb:


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


----------



## Mrtain (11 Juni 2020)

KOP und FUP sind definitiv nicht das selbe.


----------



## Mike100 (11 Juni 2020)

Mrtain schrieb:


> KOP und FUP sind definitiv nicht das selbe.



Was ist der tatsächliche Unterschied? Zumindest in der Siemens-Welt scheinen mir KOP und FUP sehr austauschbar zu sein.


----------



## wollvieh (11 Juni 2020)

Zur Erläuterung:
https://infosys.beckhoff.com/index.php?content=../content/1031/tc3_plc_intro/2526631051.html&id=
Gruß,  euer Wollvieh .

P.S.: Wir sind doch hier nicht im Kindergarten! ;-)

Für die Autodidakten ...
https://de.m.wikipedia.org/wiki/EN_61131


----------



## Mrtain (12 Juni 2020)

Mike100 schrieb:


> Was ist der tatsächliche Unterschied? Zumindest in der Siemens-Welt scheinen mir KOP und FUP sehr austauschbar zu sein.



So gesehen hast du recht, aber aus meiner persönlichen Erfahrung fand ich die Fehlersuche bei FUP schon nervig, bei Kop noch nerviger.


----------



## Mrtain (12 Juni 2020)

wollvieh schrieb:


> Zur Erläuterung:
> https://infosys.beckhoff.com/index.php?content=../content/1031/tc3_plc_intro/2526631051.html&id=
> Gruß,  euer Wollvieh .
> 
> ...



Hättest du gefühlt bei zig anderen Beiträgen hier schreiben können...


----------



## Mike100 (12 Juni 2020)

wollvieh schrieb:


> Zur Erläuterung:
> https://infosys.beckhoff.com/index.php?content=../content/1031/tc3_plc_intro/2526631051.html&id=
> Gruß,  euer Wollvieh .
> 
> ...



Normen interessieren mich nicht, ich bin auf schnellen Business-Value und ein schnelles Projekt-Setup aus. Die elendslangen Specs können die Devs für sich behalten.

Wenn ich ein 20-Zeilen-README lese, dann ist meine Aufmerksamkeitsspanne bereits zu Ende. 
In meiner Welt starten Developer-Tools fünf Minuten nach dem Download, und nicht nach stundenlangen DVD-Installationen.

Über TIA-Portals Steinzeit-Installer kann ich nur lachen, der stammt offensichtlich nicht von Software-Entwicklern sondern von Juristen aus dem 20. Jahrhundert.


----------



## DeltaMikeAir (12 Juni 2020)

Mike100 schrieb:


> Wenn ich ein 20-Zeilen-README lese, dann ist meine Aufmerksamkeitsspanne bereits zu Ende. .


Das glaube ich dir sogar, das lesen nicht deine Stärke ist. Bei uns nennt man jemand wie dich Dampfredner, viel heiße Luft aber nichts dahinter. Viel Erfolg


----------



## wollvieh (12 Juni 2020)

Nun,  du musst bei Deiner Geschwindigkeit ja schon zig tausend Anwendungen programmiert haben, scharfer Hund!


----------



## testor (12 Juni 2020)

Mike100 schrieb:


> Normen interessieren mich nicht, ich bin auf schnellen Business-Value und ein schnelles Projekt-Setup aus. Die elendslangen Specs können die Devs für sich behalten.
> 
> Wenn ich ein 20-Zeilen-README lese, dann ist meine Aufmerksamkeitsspanne bereits zu Ende.
> In meiner Welt starten Developer-Tools fünf Minuten nach dem Download, und nicht nach stundenlangen DVD-Installationen.
> ...



Wenn dich Normen nicht interessieren solltest du vllt von der Automatisierungstechnik Abstand nehmen. Oder generell von allem was über eine Android App hinaus geht


----------



## Mike100 (12 Juni 2020)

testor schrieb:


> Wenn dich Normen nicht interessieren solltest du vllt von der Automatisierungstechnik Abstand nehmen. Oder generell von allem was über eine Android App hinaus geht



Als würden die TIA-Jünger jemals eine Norm lesen 😂
Die TIA-Jünger starten ihr Portal, trinken einen Kaffee, starten eine andere Portal-Version auf einer VM weil Projekt oder Firmware inkompatibel sind, trinken einen zweiten Kaffee.
Und danach bringen sie ihr Projekt irgendwie zum Laufen, weil sie Experten darin sind, die künstlichen Siemens-Limitierungen zu umgehen.
Ach ja, die TIA-Jünger sind selbstverständlich unersetzlich in ihren Unternehmen, weil niemand anderer weiß, wie die Workarounds für die zahlreichen Siemens-Bugs und Siemens-Inkompatibilitäten funktionieren.


----------



## testor (12 Juni 2020)

Mike100 schrieb:


> Als würden die TIA-Jünger jemals eine Norm lesen 😂
> Die TIA-Jünger starten ihr Portal, trinken einen Kaffee, starten eine andere Portal-Version auf einer VM weil Projekt oder Firmware inkompatibel sind, trinken einen zweiten Kaffee.
> Und danach bringen sie ihr Projekt irgendwie zum Laufen, weil sie Experten darin sind, die künstlichen Siemens-Limitierungen zu umgehen.
> Ach ja, die TIA-Jünger sind selbstverständlich unersetzlich in ihren Unternehmen, weil niemand anderer weiß, wie die Workarounds für die zahlreichen Siemens-Bugs und Siemens-Inkompatibilitäten funktionieren.



Hmm das klingt nach einer schlechten persönlichen Erfahrung. Ich kann natürlich nur mutmaßen was die widerfahren ist, aber es geht bestimmt vorbei.


----------



## Heinileini (12 Juni 2020)

Mike100 schrieb:


> ... ich bin auf schnellen Business-Value und ein schnelles Projekt-Setup aus.


Dann bist Du doch bei µSoft & Co viel besser aufgehoben. Die Kunden von Anlagen und Maschinen sind nicht so erpicht auf SchnellLebigkeit.
Meistens fangen die Maschinen nach jahrelanger Nutzung, ggfs einem BesitzerWechsel und einem RetroFit ein zweites (oder drittes oder viertes) Leben an.


----------



## Mike100 (12 Juni 2020)

Heinileini schrieb:


> Dann bist Du doch bei µSoft & Co viel besser aufgehoben. Die Kunden von Anlagen und Maschinen sind nicht so erpicht auf SchnellLebigkeit.
> Meistens fangen die Maschinen nach jahrelanger Nutzung, ggfs einem BesitzerWechsel und einem RetroFit ein zweites (oder drittes oder viertes) Leben an.



Genau deshalb verstehe ich es nicht, warum TIA-Portal so weit verbreitet ist.
Wenn ein Kunde auf Langlebigkeit wert legt, warum setzt man dann ein TIA-Portal ein, welches seine eigenen Binary-Files bei jedem Service Pack zerschießt und inkompatibel macht?
Warum setzt man ein TIA-Portal ein, welches bereits nach kurzer Zeit von VMs und Parallelversionen abhängig ist, um überhaupt noch auf die Anlage online zu gehen?

Ich verherrliche Microsoft keinesfalls, aber Microsofts C#-Code ist hundert Mal stabiler als es TIA-Portal jemals gewesen ist.
Wenn man TIAs Abstürze in Betracht zieht, dann ist die Bilanz noch bitterer für Siemens.


----------



## JesperMP (12 Juni 2020)

Mike100 schrieb:


> Wenn ein Kunde auf Langlebigkeit wert legt, warum setzt man dann ein TIA-Portal ein, welches seine eigenen Binary-Files bei jedem Service Pack zerschießt und inkompatibel macht?
> Warum setzt man ein TIA-Portal ein, welches bereits nach kurzer Zeit von VMs und Parallelversionen abhängig ist, um überhaupt noch auf die Anlage online zu gehen?


Du hast absolut recht, dass diese Versionsabhängigkeit eine Schwachheit bei S7-1500/TIA ist. MMn das schlimmste Problem für TIA.
Meisten von uns arbeiten entweder mit VMs, und/oder bleiben bei eine "gute" Version über eine längere Zeit. Ich z.B blieb bei V13SP2 für eine lange Zeit, und bin jetzt bei V15.1 was vermutlich ein paar Jahren so bleibt.

Warum wir trotzt dies TIA einsetzt.
Das hat etwas zu tun mit:
Marktakseptanz - Weltweit.
24/7 Support - Weltweit.
Liefersicherheit von Ersatzteile, auch nach 10+ Jahren.
Zuverlässigkeit von den Hardware.
Zuverlässigkeit von den Runtime Software (nicht mit TIA Engineering Software zu verwechseln).
Funktionsumfang, SPS + HMI + IO + Motion + Netzwerk (Industrielle) + Safety + ...

Ich fühle aber dass du immer wieder diesen Thema mit neue Argumente gegen TIA neustartet. Es war von Anfang ab etwas mit IDE, und Git, und Pushen. Jetzt aber andere Argumente. Hmmm. 
Vielleicht brauchst du nur eine Ausrede um zu bitschen und moanen.


----------



## Heinileini (12 Juni 2020)

JesperMP schrieb:


> Vielleicht brauchst du nur eine Ausrede um zu bitschen und moanen.


Zwar leider off topic, aber das bringt mich auf eine Idee, Jesper: ich werde, falls ich mich in diesem Thread oder einem seiner Ableger noch mal melde, den TE mit den Worten 'Good moaning Mike100' begrüssen.


----------



## JesperMP (12 Juni 2020)

Heinileini, du warst sicherlich auch Fan von Allo' Allo'


----------



## Mike100 (12 Juni 2020)

JesperMP schrieb:


> Du hast absolut recht, dass diese Versionsabhängigkeit eine Schwachheit bei S7-1500/TIA ist. MMn das schlimmste Problem für TIA.
> Meisten von uns arbeiten entweder mit VMs, und/oder bleiben bei eine "gute" Version über eine längere Zeit. Ich z.B blieb bei V13SP2 für eine lange Zeit, und bin jetzt bei V15.1 was vermutlich ein paar Jahren so bleibt.
> 
> Warum wir trotzt dies TIA einsetzt.
> ...



Zu Beginn des Threads habe ich naiv geglaubt, dass C/C++ eventuell eine Notlösung für diese Misere sein könnten.
Diese C/C++-Idee habe ich im Laufe des Threads verworfen. Stattdessen hat sich herauskristallisiert, dass grottenschlechte IDEs wie TIA der Grund für diesen Thread sind.

24/7 Support ist zwar gut und schön, aber trotzdem eine Farce bei einer instabilen Software die ständig zu sich selbst inkompatibel ist.

Bei der TIA Runtime Software habe ich ebenfalls meine Zweifel. Wenn Siemens das TIA-Portal seit Jahren nicht stabil hinbekommt, woher kommt dann der Glaube, dass die TIA Runtime Software stabil ist?
Es reicht bereits ein S7-Firmware-Update aus, um potentiell nicht mehr online gehen zu können.

Auch dieser Thread hört sich danach an, dass die Runtime-Software alles andere als stabil ist:
Wichtige Updates für SIMATIC S7-1500 Software Controller für alle Versionen ab V2.0
Das sind zwar "nur" Software-Controller, zeigt aber trotzdem, dass Siemens den Windows-Software-Stack nicht im Griff hat.

Übrigens läuft die S7-1500 intern mit einem Linux-Kernel, und TIA-Portal ist in C# programmiert.
Sowohl Linux als auch C# sind TIA um Lichtjahre voraus was Rückwärts-Kompatibilität und Abstürze betrifft.
Wenn TIA-Jünger behaupten, dass Linux oder C# keine ausreichende Industrie-Zuverlässigkeit haben, dann kann das daher nur als Farce bezeichnet werden.

Ersatzteile, Marktakzeptanz etc. bleiben dann als die einzigen Argumente übrig, welche (noch) für TIA sprechen.
Die Quintessenz ist: Man setzt Siemens nicht wegen TIA ein, sondern trotz TIA.


----------



## Heinileini (12 Juni 2020)

JesperMP schrieb:


> Heinileini, du warst sicherlich auch Fan von Allo' Allo'


Leider habe ich keine Ahnung, wovon Du sprichst, Jesper, aber Du wolltest doch sowieso mal zum NRW-ForumsTreff erscheinen ... dann können wir ausgiebig darüber f[l]achsimpeln! 

PS:
Sorry, das war schon wieder off topic, aber manche Threads kann man damit ein weinig auflockern.


----------



## escride1 (12 Juni 2020)

Mike100 schrieb:


> Normen interessieren mich nicht, ich bin auf schnellen Business-Value und ein schnelles Projekt-Setup aus. Die elendslangen Specs können die Devs für sich behalten.
> 
> Wenn ich ein 20-Zeilen-README lese, dann ist meine Aufmerksamkeitsspanne bereits zu Ende.
> In meiner Welt starten Developer-Tools fünf Minuten nach dem Download, und nicht nach stundenlangen DVD-Installationen.
> ...



Whoa, wozu lesen wir uns tagelang komplette Anforderungen der Kunden durch wenn wir Programme erstellen wenn er doch einfach so drauf losballern darf?

Aja - liegt daran das wir Kunden haben die zufrieden wiederkommen *ROFL*


----------



## Ralle (12 Juni 2020)

Mike100 schrieb:


> Wenn TIA-Jünger



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?


----------



## wollvieh (12 Juni 2020)

Wenn ich das alles so lese, kann ich es kaum glauben. Als überzeugter Codesys Fan, es ist möglich, Codesys V2 Programme nach Codesys V3 hochzukonvertieren, so sollte es sein. Step7 hab ich auch noch erlebt, aber TIA brauche ich nicht mehr. Habs versucht, 1.6GB Software runtergeladen, am Ende bei der Installation gescheitert, warum auch immer.  So sollte SW heute nicht sein.


----------



## JesperMP (12 Juni 2020)

Heinileini schrieb:


> Leider habe ich keine Ahnung, wovon Du sprichst, Jesper, aber Du wolltest doch sowieso mal zum NRW-ForumsTreff erscheinen ... dann können wir ausgiebig darüber f[l]achsimpeln!
> 
> PS:
> Sorry, das war schon wieder off topic, aber manche Threads kann man damit ein weinig auflockern.


https://www.youtube.com/watch?v=zGNVU5ZjlgA


----------



## Blockmove (12 Juni 2020)

Mike100 schrieb:


> Normen interessieren mich nicht, ich bin auf schnellen Business-Value und ein schnelles Projekt-Setup aus. Die elendslangen Specs können die Devs für sich behalten.
> 
> Wenn ich ein 20-Zeilen-README lese, dann ist meine Aufmerksamkeitsspanne bereits zu Ende.
> In meiner Welt starten Developer-Tools fünf Minuten nach dem Download, und nicht nach stundenlangen DVD-Installationen.



Also langsam nimmt es sonderbare Formen mit dir an.
Die Installation von Visualstudio ist auch nicht in 5min erledigt.
Und auch die Einrichtung nimmt einige Zeit in Anspruch.

Ausser TIA-Bashing kommt nix sinnvolles von dir.
Jede Menge inhaltsleere Buzzwords.


----------



## Thomas_v2.1 (12 Juni 2020)

Mike100 schrieb:


> Übrigens läuft die S7-1500 intern mit einem Linux-Kernel



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


----------



## Heinileini (12 Juni 2020)

JesperMP schrieb:


> 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  - bin jetzt aber auf dem Wege, einer zu werden. :s12:

PS:
Wie kriegen wir jetzt die Kurve zurück zum topic?


----------



## escride1 (12 Juni 2020)

Thomas_v2.1 schrieb:


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


----------



## Mike100 (13 Juni 2020)

Ralle schrieb:


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



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.


----------



## Ralle (13 Juni 2020)

Thomas_v2.1 schrieb:


> ... gegenüber den Windows CE Geräten war das aber der letzte Schrott (OP77A vs OP77B).



Ja, wegen dem A hießen die bei uns Arschloch-Geräte *ROFL*


----------



## zako (13 Juni 2020)

Heinileini schrieb:


> Leider habe ich keine Ahnung, wovon Du sprichst, Jesper, aber Du wolltest doch sowieso mal zum NRW-ForumsTreff erscheinen ... dann können wir ausgiebig darüber f[l]achsimpeln!



Ja erlaubt Euch das der Laschet schon?
Ansonsten trefft Euch halt auf Malle...


----------



## Mrtain (13 Juni 2020)

Mike100 schrieb:


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


----------



## kp400 (13 Juni 2020)

Mike100 schrieb:


> Siemens ist auch der Hauptgrund, warum ich die Industrie-Normen nicht mehr ernst nehme



Dieser Post ist auch der Hauptgrund, warum ich diesen "Thread" nicht (mehr) ernst nehme.


----------



## Fluffi (14 Juni 2020)

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.


----------



## Thomas_v2.1 (14 Juni 2020)

Fluffi schrieb:


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


----------



## Kieler (14 Juni 2020)

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?


----------



## vollmi (15 Juni 2020)

Kieler schrieb:


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


----------



## rostiger Nagel (15 Juni 2020)

vollmi schrieb:


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


----------



## Kieler (15 Juni 2020)

vollmi schrieb:


> Ich denke, Siemens ist hier ein so krass typisches Opfer des "Not invented here syndrom"



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.


----------



## Ralle (15 Juni 2020)

vollmi schrieb:


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


----------



## Larzerus (15 Juni 2020)

Kieler schrieb:


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


----------



## ms_gp (15 Juni 2020)

rostiger Nagel schrieb:


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


----------



## Kieler (15 Juni 2020)

ms_gp schrieb:


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


----------



## Mike100 (15 Juni 2020)

Fluffi schrieb:


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


----------



## wollvieh (15 Juni 2020)

Steigt doch einfach auf TwinCAT3 um, da gibt es vieles, was ihr vermisst.

Oder gleich CODESYS?
https://help.codesys.com/

;-)


----------



## Mike100 (15 Juni 2020)

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.


----------



## wollvieh (15 Juni 2020)

Das Marketing ist jedenfalls top.


----------



## rostiger Nagel (15 Juni 2020)

@ Mike100,
es mag zwar sein das TIA Kritisiert werden kann, aber wie du es hier raus haust,
finde ich das sehr Fragwürdig. Ich habe den Eindruck das du noch kein kommerzielles
Projekt erstellt hast.

Ich bezweifle auch das der Schwager, deines Onkels dritten Grades, die interner der
Softwareentwicklung bei Siemens als Praktikant sehen durfte und du diese dann als
dritte Person hier ausposaunst, was du nicht selber gesehen hast.

Alles was du hier an Problemen aufzählst, ist uns längst bekannt und ausführlich im
Forum Diskutiert worden bzw. kann man nachlesen. 

Hoffentlich fällt dir das nicht mal irgendwann auf die Füße ...


----------



## Mike100 (15 Juni 2020)

wollvieh schrieb:


> Das Marketing ist jedenfalls top.
> Anhang anzeigen 50147



Ich kenne kaum ein Software-Unternehmen, wo die Kluft zwischen Marketing und Realität so groß ist.
TIA hat viele stümperhafte Funktionalitäten, welche teilweise von primitivsten Open Source Tools besser umgesetzt werden (zb. Package Management, Build Traceability).

Würde man nicht wissen, dass solche Großprojekte in einen dysfunktionalen Zustand verfallen können, dann könnte man glauben, dass die TIA-Entwicklung mit absoluter Inkompetenz durchseucht ist.


----------



## Blockmove (15 Juni 2020)

ms_gp schrieb:


> Nur bei der safety ist Siemens aus meiner Sicht besser.



Sehe ich auch so.

Was uns mittlerweile auch sehr gut gefällt ist ProDiag.
Kenne ich von anderen Herstellern in dieser Form auch nicht.
Wir haben es mittlerweile als Standard für unsere Anlagen definiert.


----------



## Mrtain (15 Juni 2020)

Mike100 schrieb:


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



Nur weil man mit ST/SCL nicht umzugehen weiß, bedeutet es noch lange nicht, dass es keine guten Sprachen für die SPS Programmierung sind...


----------



## wollvieh (15 Juni 2020)

So schlecht kann es doch nun auch nicht sein?


----------



## Blockmove (15 Juni 2020)

Mike100 schrieb:


> Ich kenne kaum ein Software-Unternehmen, wo die Kluft zwischen Marketing und Realität so groß ist.



Also ich kenne da Einige 
Sowohl aus der Automatiserungsbranche als auch aus der IT.
Viele davon sind trotzdem führend auf ihrem Sektor.


----------



## Mike100 (15 Juni 2020)

wollvieh schrieb:


> So schlecht kann es doch nun auch nicht sein?
> 
> Anhang anzeigen 50148



Die Marktwirtschaft funktioniert manchmal, aber nicht immer.
Eine funktionierende Marktwirtschaft würde bedeuten, dass gleichzeitig minderwertige und teure Produkte vom Markt verdrängt werden (TIA-Portal erfüllt beide Kriterien: teuer und schlechte Software-Qualität).
In der Realität ist das aber nicht immer gegeben. 
Es gibt viele Gründe für eine dysfunktionale Wirtschaft, zum Beispiel Monopole, Knebelverträge, ausufernde Regulatorien, Korruption etc. etc. Aus diesen Gründen sind strenge Antitrust-Gesetze essentiell für jede funktionierende Marktwirtschaft.
Ich will Siemens keinen kriminellen Vorwurf machen, aber gleichzeitig sehe ich, dass die Konkurrenz von Siemens teilweise ebenfalls sehr schlechte IDEs liefert.


----------



## wollvieh (15 Juni 2020)

Mike100:
Wann kommt Dein Compiler oder welche Entwicklungsumgebung verwendest Du?


----------



## Mike100 (15 Juni 2020)

wollvieh schrieb:


> Mike100:
> Wann kommt Dein Compiler oder welche Entwicklungsumgebung verwendest Du?



Ich verwende Visual Studio und bin damit semi-zufrieden.
JetBrains halte ich zwar für besser als Visual Studio, aber das sind Detail-Unterschiede.

So etwas unterirdisches wie TIA-Portal habe ich als Programmierer jedoch noch nie zuvor erlebt, weshalb ich aus der Siemens-Programmierung geflüchtet bin.


----------



## Mrtain (15 Juni 2020)

Kurze Frage: Wirst du für das Bashing hier bezahlt? Nicht das ich dir irgendwas unterstellen will... 

Du kannst sagen was du willst, aber deren SPS‘en laufen nunmal sehr gut. In meinem alten Betrieb laufen heute noch zum Teil S5.


----------



## Mike100 (15 Juni 2020)

Mrtain schrieb:


> Du kannst sagen was du willst, aber deren SPS‘en laufen nunmal sehr gut. In meinem alten Betrieb laufen heute noch zum Teil S5.



Das ist zwar gut und schön, aber trotzdem kein Kriterium für eine moderne IDE.
Sogar die S7-300 ist immer noch eine Geldmaschine für Siemens Digital Industries.
Eine Zukunft der Automatisierung lässt sich mit solchen Produkten dennoch nicht aufbauen.


----------



## wollvieh (15 Juni 2020)

Die Konzerne wird es immer geben, die haben schon Generationen von Programmierern überlebt. Ich hab S5, S7 erlebt, TIA kann ich altersbedingt vermeiden, und ja, die Oberfläche mit den vielen Unterfenstern mutet anachronistisch an, aber es gibt wohl cracks, die damit zurechtkommen. ;-)


----------



## Blockmove (15 Juni 2020)

Mike100 schrieb:


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



Wenn ich über den Tellerrand blicke, dann stelle ich fest, dass bei allem was mit Steuerung zu tun hat eigentlich Programmiersprachen der 3. Generation führend sind.
Egal ob nun Medizintechnik, Luft- und Raumfahrt, Automotive, ...
Objektorientierung findet nur langsam Einzug und auch nur im begrenzten Umfang. 

Im "hippen" IoT-Umfeld kommen moderne Sprachen und moderne Tools zum Einsatz.
Und was passiert, bzw, wo tauchen Probleme auf:
Datentypen, Typkonvertierungen, Zeitformate ... Die Frameworks sind so klasse und die IDEs nehmen einem soviel Arbeit ab
und dann muss ich Kunstgriffe machen weil das System Probleme hat mit Int16, Int32, Int64.
Oder auch schön, wenn der Kollege aus China auf einmal Probleme hat, da das Dezimaltrennzeichen nun "." und nicht "," ist.
Von Zeit- und Datumformaten oder gar UTF8 will ich gar nicht reden.

Mein Fazit ist:
Ich bin zu alt für den Scheiß


----------



## Mike100 (15 Juni 2020)

Blockmove schrieb:


> Wenn ich über den Tellerrand blicke, dann stelle ich fest, dass bei allem was mit Steuerung zu tun hat eigentlich Programmiersprachen der 3. Generation führend sind.
> Egal ob nun Medizintechnik, Luft- und Raumfahrt, Automotive, ...
> Objektorientierung findet nur langsam Einzug und auch nur im begrenzten Umfang.
> 
> ...



Ich glaube, dass du hier Ursache und Wirkung verwechselt.
All die Probleme mit Datentypen werden dadurch verschlimmert, dass IDEs wie TIA rückständig und monolithisch sind.
Wären die SPS-IDEs ein wenig "hipper", dann würde auch die IoT-Integration leichter fallen.

Ich nehme an, dass C/ST/SCL als "Programmiersprachen der dritten Generation" bezeichnet werden.
Diese Sprachen sind selbstverständlich veraltet, obwohl sie in manchen Nischen noch ihre Berechtigung haben. 
Wenn jedoch ganze Branchen seit vierzig Jahren nichts anderes einsetzen, dann ist das kein konservativer Fortschritt, sondern absoluter Stillstand.

Objektorientierung ist übrigens auch nicht modern, sondern nur einer von mehreren Design-Ansätzen. Abgesehen davon glaube ich, dass Klassen-Hierarchien und Vererbung in der SPS-Programmierung nicht essenziell sind.


----------



## Mrtain (15 Juni 2020)

Mike100 schrieb:


> Das ist zwar gut und schön, aber trotzdem kein Kriterium für eine moderne IDE.
> Sogar die S7-300 ist immer noch eine Geldmaschine für Siemens Digital Industries.
> Eine Zukunft der Automatisierung lässt sich mit solchen Produkten dennoch nicht aufbauen.



Die Realität sieht doch so aus: Dem Kunden ist IDE mit der programmiert wird, schnurzpiepe egal. Der will nur, dass seine Anlage funktioniert und das möglichst ohne Ausfall. Und wenn der Kunde unbedingt Siemens haben will, dann programmiert man halt die Anlage mit Siemens und deren IDE. 
Vielleicht läuft der Hersteller XYZ Siemens irgendwann den Rang ab, dann programmieren wir halt Anlagen mit Steuerungen von XYZ und deren IDE. 

Wir sind in erster Linie alle Angestellte / Dienstleister. Und den Luxus, den eigenen Kopf gegenüber unseren Kunden durchzusetzen kann man sich selten leisten.


----------



## Blockmove (15 Juni 2020)

Mike100 schrieb:


> Abgesehen davon glaube ich, dass Klassen-Hierarchien und Vererbung in der SPS-Programmierung nicht essenziell sind.



Jetzt enttäuscht du mich.
Wie ist eine Maschine oder Anlage aufgebaut?
Aus einzelnen Objekten (Zylinder, Motoren, ...)
Die Objekte bilden dann Einheiten, Stationen, Maschinen und Fertigungslinien.
Also wenn man was in der Theorie objektorientiert betrachten kann, dann doch wohl eine Maschine.

Und Vererbung ist doch wohl auch sinnvoll. Beispiel:
Normaler Motor: Methode "Einschalten" / Eigenschaft "Läuft"
Drehzahlgeregelter Motor: Erbt Normaler Motor und bekommt Methode "Solldrehzahl" und Eigenschaft "Istdrehzahl"
Positionierantrieb: Erbt "drehzahlgeregelter Motor" und bekommt Methode "Position anfahren" und Eigenschaft "Istposition"
Also das ist doch das Paradebeispiel für Vererbung.

Und jetzt kommst du und erklärst ST und SCL für veraltet und gleichzeitig Objektorientierung als nicht essenziell.
Hmmm wie soll denn dann aus deiner Sicht SPS-Programmierung in Zukunft aussehen?


----------



## Mrtain (15 Juni 2020)

DIN-Normen sind doch anscheinend auch nicht essenziell...*ROFL*


----------



## wollvieh (15 Juni 2020)

Am Ende wird alles gut.
Gesetz des Dschungels, die starken fressen die schwachen.


----------



## oliver.tonn (15 Juni 2020)

wollvieh schrieb:


> Gesetz des Dschungels, die starken fressen die schwachen.


Wobei uns die Geschichte immer wieder lehrt, dass das nicht immer die Besseren sind, siehe Siegeszug des VHS-Systems.

Von irgendwas mit Internetzugang gesendet.


----------



## Mike100 (15 Juni 2020)

Mrtain schrieb:


> Die Realität sieht doch so aus: Dem Kunden ist IDE mit der programmiert wird, schnurzpiepe egal. Der will nur, dass seine Anlage funktioniert und das möglichst ohne Ausfall. Und wenn der Kunde unbedingt Siemens haben will, dann programmiert man halt die Anlage mit Siemens und deren IDE.
> Vielleicht läuft der Hersteller XYZ Siemens irgendwann den Rang ab, dann programmieren wir halt Anlagen mit Steuerungen von XYZ und deren IDE.
> 
> Wir sind in erster Linie alle Angestellte / Dienstleister. Und den Luxus, den eigenen Kopf gegenüber unseren Kunden durchzusetzen kann man sich selten leisten.



Im Falle von TIA halte ich das für ein sehr stupides Mindset. Warum sollte ich als Kunde die Verwendung einer schlechte IDE erzwingen, wenn es keine Vorteile bringt sondern nur Nachteile für die Entwicklung und Wartung (zb. ständige Zerstörung der Binary-Kompatibilität bei TIA)? 

Welcher seriöser Kunde will ein System einsetzen, welches nur mit VMs und veralteten TIA-Versionen noch am Leben gehalten werden kann? Die sogenannte "Bit-Verrottung" setzt bei TIA nicht nach Jahren ein, sondern bereitets nach wenigen Monaten. Es ist naiv, als langfristig denkender Kunde darauf zu setzen.

Ja, ich verstehe es natürlich, dass manche Kunden von Siemens-Hardware abhängig sind. 
Für viele Aufgaben macht es aber keinen Sinn, stupide auf TIA zu setzen, außer man hat Programmierer welche nur TIA können und nichts anderes.

Oder anders gesagt: Warum sollten Leute über IDEs entscheiden, welche erstens keinen Dunst davon haben und zweitens die IDEs nie verwenden?
Ein vernünftiger Kunde setzt auf das, was für die Entwickler am effizientesten funktioniert und die Anforderungen erfüllt. Und von Effizienz ist TIA weit entfernt, wie in diesem Thread lang und breit dargelegt wird.


----------



## ms_gp (15 Juni 2020)

Das Argument ist oft, dass das Personal des Kunden in einem System geschult ist. Und das ist oft Siemens, weil die so clever waren dafür zu sorgen, dass an den berufschulen das SIEMENS System Standard ist. Die kennen dann gar ni hts anderes.


----------



## Mike100 (15 Juni 2020)

ms_gp schrieb:


> Das Argument ist oft, dass das Personal des Kunden in einem System geschult ist. Und das ist oft Siemens, weil die so clever waren dafür zu sorgen, dass an den berufschulen das SIEMENS System Standard ist. Die kennen dann gar ni hts anderes.



Richtig, das halte ich auch für das wichtigste Pro-TIA-Argument.
Ganz nach dem Motto: "Was der Bauer nicht kennt, frisst er nicht".
Ebenfalls halte ich es für sinnvoll, dass Berufsschüler die IDEs der Industrie diktieren (also Leute, welche noch nie im Leben mit einer vernünftigen IDE gearbeitet haben, geschweige denn programmieren können).


Ok jetzt im Ernst:
Das ist ebenfalls ein Zeichen für Lobbyismus und Marktversagen. Marktversagen ist es, wenn eine miserable Software durch Keiler-Strategien jahrelang die Qualität nach unten zieht und die Kosten nach oben drückt.


----------



## zako (16 Juni 2020)

ms_gp schrieb:


> Das Argument ist oft, dass das Personal des Kunden in einem System geschult ist. Und das ist oft Siemens, weil die so clever waren dafür zu sorgen, dass an den berufschulen das SIEMENS System Standard ist. Die kennen dann gar ni hts anderes.



Ich kenne einen Hochschuldozenten, der ein Automatisierungspraktikum leitet. Dort haben z.B. die Studenten die freie Wahl zwischen Beckhoff und SIEMENS (TIA Portal). Ich haben ihn mal gefragt, womit die Studenten lieber arbeiten. Da kam dann die Antwort: SIEMENS
Ist wohl intuitever. Ich kenne bei SIEMENS auch die SIMOTION- Steuerung. Dieses vielleicht von den Programmierung / Task- System vielleicht näher an TWINCAT und kann z.B. auch objektorientiert programmiert werden, hatte auch immer wieder Features die erst später bei der SIMATIC nachgezogen geholt wurden. Die Kunden haben wohl eine SIMATIC am liebsten.


----------



## Mrtain (16 Juni 2020)

Mike100 schrieb:


> Im Falle von TIA halte ich das für ein sehr stupides Mindset.



Das einzig stupide in deiner scheinbar endlosen Troll-Aktion hier ist dein rumgeheule, wie schlecht und veraltet doch die SPS-Welt. Da du ja anscheinend der Programmiergott schlechthin bist, frage ich mich mittlerweile, warum du offensichtlich an TIA / St bzw. SCL scheiterst, wenn doch zig tausend Leute trotz der Probleme damit funktionierende Anlagen auf die Beine stellen?  
​


Mike100 schrieb:


> Oder anders gesagt: Warum sollten Leute über IDEs entscheiden, welche erstens keinen Dunst davon haben und zweitens die IDEs nie verwenden?
> Ein vernünftiger Kunde setzt auf das, was für die Entwickler am effizientesten funktioniert und die Anforderungen erfüllt. Und von Effizienz ist TIA weit entfernt, wie in diesem Thread lang und breit dargelegt wird.



Vielleicht weil diese Leute darüber entscheiden, ob man den Auftrag bekommt oder nicht.


----------



## vollmi (16 Juni 2020)

Mrtain schrieb:


> Nur weil man mit ST/SCL nicht umzugehen weiß, bedeutet es noch lange nicht, dass es keine guten Sprachen für die SPS Programmierung sind...



ich wüsste auch nicht was für einen Gewinn man hätte wenn man statt SCL C# und Co verwenden könnte. Die Funktionen würden  ja grundsätzlich die gleichen bleiben.
diese Hochsprachen müssten für eine robuste SPS Umgebung derart beschnitten werden dass eh am ende wieder SCL dabei rauskommt. Oder erwartet hier wirklich einer das man z.B. jemals wird Arbeitsspeicher dynamisch allozieren können?
Die Robustheit einer SPS Software kommt nicht nur durch den Programmierer, sondern auch durch die sehr restriktiven Einschränkungen der Codebasis und ich denke das ist auch ganz okay so.
Wer mehr will, nimmt sich einen Industrie Raspberry und hängt da ein paar ET200sp Anschaltungen dran, und schon ist er Herr über alles inklusive Kernschmelze wenn notwendig.

Die Schwäche bei TIA ist definitiv nicht die Einschränkung der Sprachen.


----------



## Kieler (16 Juni 2020)

Ich denke der Frust beim Endkunden wird mit den Jahren wachsen. Der Vorteil von Siemens ist neben guter Dokumentation eine wirklich gute Lieferfähigkeit. Ich bekomme auch nach Jahren noch Teile für meine Steuerung von nahezu einem Tag zum anderen. Das ist für den Endkunden sehr wichtig. 

Aber das nutzt einem natürlich nichts mehr, wenn die Teile nur mechanisch passen. Bekomme ich auf das neue Teil meine alte Firmenware? Muss ich die alte Anlage hochrüsten? Das möchte sich doch niemand antun.


----------



## Mike100 (16 Juni 2020)

vollmi schrieb:


> ich wüsste auch nicht was für einen Gewinn man hätte wenn man statt SCL C# und Co verwenden könnte. Die Funktionen würden  ja grundsätzlich die gleichen bleiben.
> diese Hochsprachen müssten für eine robuste SPS Umgebung derart beschnitten werden dass eh am ende wieder SCL dabei rauskommt. Oder erwartet hier wirklich einer das man z.B. jemals wird Arbeitsspeicher dynamisch allozieren können?
> Die Robustheit einer SPS Software kommt nicht nur durch den Programmierer, sondern auch durch die sehr restriktiven Einschränkungen der Codebasis und ich denke das ist auch ganz okay so.
> Wer mehr will, nimmt sich einen Industrie Raspberry und hängt da ein paar ET200sp Anschaltungen dran, und schon ist er Herr über alles inklusive Kernschmelze wenn notwendig.
> ...



Ich gebe zu: Go und C# kann ich mir ohne dynamischer Speicherallokation nur sehr schwer vorstellen. Falls man den Garbage Collector eliminiert, dann könnte es eventuell trotzdem funktionieren. 

C++20 könnte theoretisch auch funktionieren. Allerdings sind viele Features von C++ übermäßig komplex, und auch der C++-Compiler ist eigentlich zu komplex. 

Es sollte eine Sprache ohne "Raw Pointer" wie in C sein, aber auch ohne Garbage Collector wie in Java.


----------



## Ralle (16 Juni 2020)

Mike100 schrieb:


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



Das kann ich fast alles unterschreiben und das erzähle ich spätestens seit V13 (Seitdem ich das produktiv einsetzte).
S7 300 in TIA war nach meinen Infos nicht geplant, sondern ein MUSS des Marketings und hatte tatsächlich großen Anteil and er Katastrophe. Völlig unverständlich.

Leider fürchte ich, wir werden nichts Neues bekommen und vor allem nichts Besseres.
Denke es geht in Richtung Cloud, Cloud-Dienste. Siemens hat Schiß, dass sie Ihre spezailhardware (PLC etc.) nicht mehr verkauft bekommen, weil all das auf irgendwelchen Computern, Controllern oder in der Cloud läuft. Daher kommt es wohl auch, dass immer mehr Kleinkram mit einer License verkauft wird. Irgendwann verkauft man nur noch Software und License. Die Entwicklung ist sicherlich auch bedenklich, ich halte sie für fatal.

Ich hätte gerne ien IDE, die die Sprachelemente KOP/FUP/SCL/Graph enthält. Ich will mich möglichst ohne C/C++ oder andere Sprachkenntnisse um die Programmierung von Maschinen kümmern. Die müssen funktionieren und zwar tadellos! Code-Testfunktionen wären schon nett, aber wohl nur für SCL sinnvoll, wenn überhaupt. Ist sicherlich schwierig umzusetzen, denn da hängt ja i.d.R. noch ein Bus und externen Hardware dran. 

PS: AWL war nie schlecht. Es war Anfangs die Sprache, mit der man komplexere Sachverhalte umsetzen konnte. Zu Zeiten, als es nichts wirkich Besseres gab. Beim heutigen Stand von SCL programmiere ich auch mit SCL und nicht mehr mit AWL.


----------



## DeltaMikeAir (16 Juni 2020)

Ralle schrieb:


> PS: AWL war nie schlecht. Es war Anfangs die Sprache, mit der man komplexere Sachverhalte umsetzen konnte. Zu Zeiten, als es nichts wirkich Besseres gab. Beim heutigen Stand von SCL programmiere ich auch mit SCL und nicht mehr mit AWL.



Wobei AWL auch heute noch seine Vorteile hat
=> Beobachten teilweise deutlich einfacher
=> Sehr gute Verbreitung, Instandhalter können damit umgehen ( zumindest in meiner Branche ), SCL eher weniger


----------



## Ralle (16 Juni 2020)

zako schrieb:


> Ich kenne einen Hochschuldozenten, der ein Automatisierungspraktikum leitet. Dort haben z.B. die Studenten die freie Wahl zwischen Beckhoff und SIEMENS (TIA Portal). Ich haben ihn mal gefragt, womit die Studenten lieber arbeiten. Da kam dann die Antwort: SIEMENS
> Ist wohl intuitever. Ich kenne bei SIEMENS auch die SIMOTION- Steuerung. Dieses vielleicht von den Programmierung / Task- System vielleicht näher an TWINCAT und kann z.B. auch objektorientiert programmiert werden, hatte auch immer wieder Features die erst später bei der SIMATIC nachgezogen geholt wurden. Die Kunden haben wohl eine SIMATIC am liebsten.



Ich hatte so gehofft, das Siemens Simotion weiterentwickelt, als man die TIA-Entwicklung ankündigte. Das wäre wirklich etwas gewesen. Aber da gibt es leider wohl auch Konzern-interne Rangeleien. Wie peinlich.


----------



## Ralle (16 Juni 2020)

Mrtain schrieb:


> Das einzig stupide in deiner scheinbar endlosen Troll-Aktion hier ist dein rumgeheule, wie schlecht und veraltet doch die SPS-Welt. Da du ja anscheinend der Programmiergott schlechthin bist, frage ich mich mittlerweile, warum du offensichtlich an TIA / St bzw. SCL scheiterst, wenn doch zig tausend Leute trotz der Probleme damit funktionierende Anlagen auf die Beine stellen?
> ​
> 
> Vielleicht weil diese Leute darüber entscheiden, ob man den Auftrag bekommt oder nicht.



Jetzt komm mal wieder auf den Boden. Man kann eine Diskussion vielleicht auch mal sinnvoll weiterführen ohne dem gegenüber immer Vorhaltungen zu machen. Für seinen Einstieg hat Mike100 doch schon sein Fett wegbekommen und in der weiteren Diskussion ist es doch recht konstruktiv zugegangen. Das fnad ich bisher ganz gut so. Man muß nicht anfangen zu polemisieren, wenn man nicht mehr argumentieren will/kann!


----------



## Mike100 (16 Juni 2020)

Ralle schrieb:


> Das kann ich fast alles unterschreiben und das erzähle ich spätestens seit V13 (Seitdem ich das produktiv einsetzte).
> S7 300 in TIA war nach meinen Infos nicht geplant, sondern ein MUSS des Marketings und hatte tatsächlich großen Anteil and er Katastrophe. Völlig unverständlich.
> 
> Leider fürchte ich, wir werden nichts Neues bekommen und vor allem nichts Besseres.
> ...



Code-Test-Funktionen sind gut, wenn sie schnell und leichtgewichtig funktionieren.
Wenn ich einen SCL-Unittest in 5 Minuten schreiben kann und in einer Sekunde ausführen kann, dann ist es ein gutes Tool.
Wenn ich aber mehrere Gigabytes an Simulatoren downloaden muss, und dazu noch exakt die richtigen Versionen und License Extensions aufeinander abstimmen muss, dann wird das Testen ad absurdum geführt.

Wenn ich daher im Siemens-Marketing von "Digital Twins" lese, dann kommt mir nur das lachen. Nicht einmal primitive Unit-Tests werden von Siemens ordentlich supported, wie wollen die einen Digital Twin einer Industriestraße bauen?! Ich vermute, dass abgesehen von einzelnen Auftragsentwicklungen auch nichts für das Thema "Industrie 4.0" zusammengebracht wird, aufgrund von all diesen Limitationen.

Bei vielen Siemens-Tools frage ich mich immer, woher das schlechte Verhältnis zwischen Performance und Funktionalität kommt. Manche Tools tun nicht viel, aber sind trotzdem riesengroß und langwierig zu installieren. PLCSim Advanced ist so ein Negativbeispiel.


----------



## Mike100 (16 Juni 2020)

Bezüglich Lizenzen:
Ich kann bei Siemens keine konsistente Business-Strategie erkennen. Ich habe eher das Gefühl, dass jede Software für sich alleine versucht, profitabel zu wirtschaften, dabei aber die Kernprodukte sträflich vernachlässigt werden. So als würde ich ein dutzend mittelständische Software-Schmieden in einen Konzern werfen, welche dann in einzelnen Silos vor sich hinarbeiten.
Also das genaue Gegenteil von Google/Microsoft/Facebook, welche mit riesigen Monorepos, Developer Tools Teams und interner Open Source Kultur arbeiten.


----------



## Mrtain (16 Juni 2020)

Ralle schrieb:


> Man muß nicht anfangen zu polemisieren, wenn man nicht mehr argumentieren will/kann!


ahja...




Mike100 schrieb:


> So als würde ich ein dutzend mittelständische Software-Schmieden in einen Konzern werfen, welche dann in einzelnen Silos vor sich hinarbeiten



Naja das ausgliedern und aufspalten hat bei Siemens ja schon eine gewisse Tradition...​​

Ich frage mich nur, was der Mehrwert dieser ganzen Diskussion ist? Ja TIA ist nicht das gelbe vom Ei, viele andere IDE's auch nicht. Wenn es hier nur darum geht, wegen TIA zu jammern, hätte man das ganze auch im Thread "TIA-Frust" abhandeln können...


----------



## rostiger Nagel (16 Juni 2020)

Ralle schrieb:


> Jetzt komm mal wieder auf den Boden. Man kann eine Diskussion vielleicht auch mal sinnvoll weiterführen ohne dem gegenüber immer Vorhaltungen zu machen. Für seinen Einstieg hat Mike100 doch schon sein Fett wegbekommen und in der weiteren Diskussion ist es doch recht konstruktiv zugegangen. Das fnad ich bisher ganz gut so. Man muß nicht anfangen zu polemisieren, wenn man nicht mehr argumentieren will/kann!



Ich sehe keine Diskussion, ich lese immer nur TIA ist schlecht und die Nutzer sind Dämlich weil Sie es nutzen.

Ich lese keinen Ansatz wie es besser ist oder was besser ist, das ist keine Niveauvolle Diskussion. Es sind
einfach nur dahin gestellte Behauptungen.


----------



## Kieler (16 Juni 2020)

rostiger Nagel schrieb:


> Ich sehe keine Diskussion, ich lese immer nur TIA ist schlecht und die Nutzer sind Dämlich weil Sie es nutzen.
> 
> Ich lese keinen Ansatz wie es besser ist oder was besser ist, das ist keine Niveauvolle Diskussion. Es sind
> einfach nur dahin gestellte Behauptungen.



So unterschiedlich kann die Sicht sein. Für mich ist es die spannendste Diskussion seit ganz langer Zeit. Vielleicht spitzt Mike100 etwas zu, aber die Kernpunkte sehe ich genauso. Ob es auch Verantwortliche bei Siemens gibt, welche es ähnlich sehen? Mir ist nicht klar, wo die Reise mit TIA hingehen soll. Da wir als Anwender mit dem Einsatz dieser Software unseren Unterhalten verdienen, sollten wir das auch hinterfragen. Außerdem möchte ich auch Werkzeuge haben, mit denen das Arbeiten Spass macht.


----------



## Ralle (16 Juni 2020)

rostiger Nagel schrieb:


> Ich sehe keine Diskussion, ich lese immer nur TIA ist schlecht und die Nutzer sind Dämlich weil Sie es nutzen.
> 
> Ich lese keinen Ansatz wie es besser ist oder was besser ist, das ist keine Niveauvolle Diskussion. Es sind
> einfach nur dahin gestellte Behauptungen.



Na ja, es schwingt immer die Hoffnung mit, das jemand bei Siemens mitbekommt, wie wir Nutzer denken und dann entprechend reagiert wird. Die Hoffnung stirbt zuletzt. Siemes ist auf dem Ohr i.d.R. absolut taub!
Wir können da nichts ändern, wir können aber darüber reden und auch Alternativen diskutieren, ob die nun gut oder schlecht sind, wird sich vielleicht irgendwann zeigen.
Mike100 hat in einem auf jeden Fall Recht: TIA ist eine Krücke, die mit Müh nund Not am Leben erhalten wird und uns allen früher oder später um die Ohren fliegt. Siehhe Versions-Chaos.
Ich muß auch sagen: "Ich hab mich mit TIA inzwischen arrangiert, kenne einige Tücken und komme halbwegs damit zurecht, auch Dank des Forums und des ständigen Mitlesens. Das sollte eigentlich nicht nötig sein, komplette Neueinsteiger haben es nicht leicht. Daher habe ich ein gewisses "Expertenwissen" angesammelt, das ich bei Wechsel auf Beckhoff, Wago etc. wegwerfen kann. Mach ich nicht, warum?
Die Hardware ist nicht so schlecht, der Kunde will das, also...


----------



## rostiger Nagel (16 Juni 2020)

Brauchst du dieses Expertenwissen bei Beckhoff, Codesys und auch bei VisualStudio auch, 
da fängt man immer wieder bei Null an. Ich bin ja auch hin und her Gerissen mit TIA und 
möchte auch darüber Diskutieren aber dann auch *sachlich* und *fundiert*.

Wie sieht den eine Alternative aus?
Gibt es überhaupt eine Alternative zu den bisherigen SPS-Programmier Umgebungen?

Wir sprechen immer noch von SPS-Programmierung, das ist ein anderes Werkzeug, 
als wenn man eine Anwendung für ein Büro PC erstellt.

Nicht ohne Grund wird da eine alte Basis für Hardware und Software verwendet.


----------



## Ralle (16 Juni 2020)

@RN
Darum gings ja ursprünglich. Und wir haben ja festgestellt, es gibt derzeit keine anderen Tools für Siemens, so wie früher für die S5 und die S7. Da kommt wohl keiner mehr hinterher.


----------



## Blockmove (16 Juni 2020)

rostiger Nagel schrieb:


> Wie sieht den eine Alternative aus?
> Gibt es überhaupt eine Alternative zu den bisherigen SPS-Programmier Umgebungen?



Ich warte ja schon einige Zeit darauf, dass Mike100 seine innovative Alternative vorstellt.


----------



## rostiger Nagel (16 Juni 2020)

Vielleicht braucht es auch keine Alternative, TIA muss sich vielleicht nach außen (also zu uns hin)
verbessern, wie da intern gearbeitet wird ist mir doch völlig Egal.
Es ist immer noch das richtige Werkzeug für SPS-Programierer und wir sind hier im SPS-Forum.
ich kann auch mit einen Kuchenheber eine Wand verputzen, einfacher ist es aber mit Kelle und Reibbrett,
auch wenn der Kuchenheber aus Silber eleganter aussieht.


----------



## Kieler (16 Juni 2020)

rostiger Nagel schrieb:


> Es ist immer noch das richtige Werkzeug für SPS-Programierer und wir sind hier im SPS-Forum.


*EINSPRUCH *!!

Es wird nicht das richtige Werkzeug, weil wir es eben verwenden. Wenn es das richtige Werkzeug wäre, würde es diese ganze Diskussion nicht geben.


----------



## rostiger Nagel (16 Juni 2020)

Kieler schrieb:


> *EINSPRUCH *!!
> 
> Es wird nicht das richtige Werkzeug, weil wir es eben verwenden. Wenn es das richtige Werkzeug wäre, würde es diese ganze Diskussion nicht geben.



ja dann beschreibe doch mal wie es aussehen soll!


----------



## DeltaMikeAir (16 Juni 2020)

rostiger Nagel schrieb:


> ja dann beschreibe doch mal wie es aussehen soll!



-Eine Software für alles ( keine x Versionen )
-Mehr Kompabilität mit den Firmwaren
-(noch) weniger SPS-STOP Zwang

das wären so meine Punkte die mir spontan einfallen

Stabil läuft es bei mir ( TIA13, 14, 15, 15.1 parallel installiert )


----------



## JesperMP (16 Juni 2020)

Sind 19 Themenseiten nicht schon genug ?


----------



## Mike100 (16 Juni 2020)

rostiger Nagel schrieb:


> ja dann beschreibe doch mal wie es aussehen soll!



Ich habe in diesem Thread bereits einen detaillierten Plan beschrieben, wie TIA-Portal durch eine moderne Plattform ersetzt werden sollte. 
Die Beendigung des Versions-Chaos und die Modularisierung der Build-Chain sind nur zwei der Punkte, um für mehr Developer-Effizienz und Langzeit-Stabilität zu sorgen.


----------



## Mike100 (16 Juni 2020)

rostiger Nagel schrieb:


> Es ist immer noch das richtige Werkzeug für SPS-Programierer und wir sind hier im SPS-Forum.
> ich kann auch mit einen Kuchenheber eine Wand verputzen, einfacher ist es aber mit Kelle und Reibbrett,
> auch wenn der Kuchenheber aus Silber eleganter aussieht.



Das ist ein klassischer Trugschluss welcher aus Betriebsblindheit oder anderen Gründen entstehen kann. In diesem Thread sind bereits dutzende nachweisbare Gründe, welche belegen, dass TIA weder eine gute Entwickler-Effizienz noch eine gute Langzeit-Stabilität aufweist (ganz im Gegenteil).

Nur weil ein Werkzeug von vielen Leuten verwendet wird, bedeutet das nicht, dass es ein gutes Werkzeug ist.


----------



## Blockmove (16 Juni 2020)

Mike100 schrieb:


> Ich habe in diesem Thread bereits einen detaillierten Plan beschrieben, wie TIA-Portal durch eine moderne Plattform ersetzt werden sollte.
> Die Beendigung des Versions-Chaos und die Modularisierung der Build-Chain sind nur zwei der Punkte, um für mehr Developer-Effizienz und Langzeit-Stabilität zu sorgen.



Mit dem Versionschaos hast du recht ... Wird hier im Forum schon seit Jahren bemängelt.
Aber weshalb sollte ich mit einer modularen Build-Chain effizenter sein?
Ich bin eigentlich froh, wenn ich mich um den Build-Prozess nicht kümmern muss.
Vor langen Jahren war ich mal etwas bei der Entwicklung des ISDN-Subsystems für Linux aktiv.
War jedesmal "nett", wenn der Buildprozess aus irgendeinem Grund abgebrochen hat.
Sowas brauch ich im Job wirklich nicht.


----------



## Mike100 (16 Juni 2020)

Blockmove schrieb:


> Ich warte ja schon einige Zeit darauf, dass Mike100 seine innovative Alternative vorstellt.



Bezüglich IDE hätte ich sehr genaue Vorstellungen für eine Alternative. 
Bezüglich Programmiersprachen bin ich aber unsicher. 
Wahrscheinlich wäre es am mittelfristig am besten, bei SC/SCL/FUP/KOP zu bleiben, und auf moderne Coding-Tools für SC/SCL zu setzen.

AWL hingegen hat in einer modernen Plattform nichts mehr zu suchen, weil ich das register-basierte Programmiermodell für outdated halte (mindestens 30 Jahre outdated).
Nur weil manche Mikrocontroller immer noch in Assembler programmiert werden, bedeutet das nicht, dass AWL in einer SPS immer noch sinnvoll ist (abseits von Legacy-Support).


----------



## Mike100 (16 Juni 2020)

Blockmove schrieb:


> Mit dem Versionschaos hast du recht ... Wird hier im Forum schon seit Jahren bemängelt.
> Aber weshalb sollte ich mit einer modularen Build-Chain effizenter sein?
> Ich bin eigentlich froh, wenn ich mich um den Build-Prozess nicht kümmern muss.
> Vor langen Jahren war ich mal etwas bei der Entwicklung des ISDN-Subsystems für Linux aktiv.
> ...



Eine modulare Build-Chain hat nichts mit der Menge an Konfiguration oder Mausklicks zu tun.
Stattdessen geht es darum, die kritischen Build-Tools von der nicht-kritischen IDE-GUI zu trennen.
Dadurch erreicht eine modulare Build-Chain eine höhere Robustheit.

Zusätzlich ermöglicht eine modulare Build-Chain customized Build/Deploy-Skripte über die Kommandozeile. Diese Skripte werden zwar von den meisten Entwicklern nicht gebraucht, können aber beispielsweise für Continuous Integration Builds in einem Git-Repo eingesetzt werden. Oder auch für customized Deploy-Skripts, wenn jemand sehr viele baugleiche Anlagen gleichzeitig bespielen muss.
Wenn man aber nur die IDE verwendet, dann bekommt man von der modularen Buildchain nicht viel mit.

Der dritte Vorteil ist, dass eine modulare Buildchain die Effizienz der IDE-Entwickler erhöht. Die derzeitigen TIA-Entwickler sind nämlich in einem lähmenden monolithischen Trümmerhaufen gefangen, wodurch der Fortschritt gebremst wird. Eine modulare Buildchain hilft daher, um schnell auf Kundenfeedback reagieren zu können (falls Siemens überhaupt auf Kundenfeedback reagiert).


----------



## Mike100 (16 Juni 2020)

rostiger Nagel schrieb:


> Brauchst du dieses Expertenwissen bei Beckhoff, Codesys und auch bei VisualStudio auch,
> da fängt man immer wieder bei Null an. Ich bin ja auch hin und her Gerissen mit TIA und
> möchte auch darüber Diskutieren aber dann auch *sachlich* und *fundiert*.
> 
> ...



Für jede Software-Plattform braucht es Expertenwissen.
Die entscheidende Frage ist aber:
Bringt dieses Expertenwissen tatsächlichen Business-Value, oder geht es eher darum, ein minderwertiges Produkt dank Expertenwissen lauffähig zu machen?

Im Falle von TIA-Portal besteht ein Teil des Expertenwissens aus:

- Verschiedene TIA-Versionen in VMs ausführen.
- Verschiedene License-Extension-Packs zu verwalten.
- Zahlreiche Abstürze und Known Bugs zu umschiffen.
- Junge und alte Projekte hochrüsten, ohne das Projekt zu zerstören.
- Die exakt richtigen Versionen der Firmwares und Zusatztools aufeinander abstimmen.
- Code und Libraries ohne Versionsverwaltung und Dependency Management zu versionieren.

Auf all dieses Expertenwissen würde ich gerne verzichten. Nichts davon bringt einen Mehrwert in Projekten.


----------



## wollvieh (16 Juni 2020)

Hey Mike100, jetzt sei doch net so verbittert. 
Wie die Ami's sagen:
a winner find's a way,  a looser find's a reason. 
;-)

https://m.youtube.com/watch?v=lcOxhH8N3Bo


----------



## Mike100 (16 Juni 2020)

wollvieh schrieb:


> Hey Mike100, jetzt sei doch net so verbittert.
> Wie die Ami's sagen:
> a winner find's a way,  a looser find's a reason.
> ;-)
> ...



Die Probleme von TIA-Portal sind zum Glück eh nicht mehr meine persönlichen Probleme 
Falls ich ein paar Neu-Einsteiger davon abhalten kann, sich auf diesen TIA-Trümmerhaufen einzulassen, dann hat dieser Thread bereits gewonnen.

Meine ständige Überspitzung der Argumente ist nur ein Stilmittel.
Im Gegensatz zum Siemens-Marketing-Bullshit beruhen meine Argumente auf echter Entwickler-Substanz und treffen die verfaulte TIA-Kern-Platform ohne Schönredung.

Ich warte auf das Jahr, wo die TIA-Jünger plötzlich all ihren Code wegwerfen müssen, während die IoT-Entwickler ihren angeblich instabilen Code für Jahrzehnte weiterbetreiben.
Wer bereits heute auf TIA-VMs angewiesen ist, um überhaupt auf seine Anlagen online zu gehen, der baut auf einem riesigen Kartenhaus auf Sand.
Die Frage ist nicht mehr ob dieses Jahr kommt, sondern wann.
Ich sehe langfristig nur zwei Möglichkeiten:

- Kundenfeedback und Developer Relations von Siemens DI verbessern sich (in diesem Fall wird TIA freiwillig eingestellt).
- Siemens DI hört weiterhin nicht auf seine Kunden, und wird irgendwann von echten IT-Unternehmen mit Kundenfeedback vom Markt verdrängt (in diesem Fall wird TIA ebenfalls eingestellt).


----------



## Mike100 (16 Juni 2020)

Um noch ein weiteres Argument zu kontern:

Wenn ein Berufsschüler ohne Programmier-Kenntnisse TIA gut findet, dann sagt das nichts über die Effizienz und Langzeit-Stabilität der Tools aus. 
Im Gegensatz zu SPS-Lehrgangs-Teilnehmern ohne IT-Background kann ich euch prophezeien, was für die meisten Experten ohnehin offensichtlich ist:

Eine Software-Platform, welche nur dank Workarounds wie VMs für mehrere Jahre am Leben erhalten werden kann, welche ihre eigenen Binary-Files regelmäßig zerstört,
welche so komplex ist dass die Bugs den Siemens-internen Entwicklern um die Ohren fliegen, welche keine brauchbare Modularität und Wiederverwertung von Code bietet, welche die Software-Verrottung im Jahres-Zyklus an die Spitze treibt, eine solche Software-Platform ist langfristig zum Scheitern verurteilt.
Das Problem liegt nicht bei SC/SCL oder sonstigen Sprachen, sondern an der Kern-Architektur von TIA und den S7-Produktlinien.

Wer nicht weiß, von was ich rede, der kann auch Wikipedia bemühen:
https://de.wikipedia.org/wiki/Softwareerosion

Oder man erkennt das Problem eben nicht, und ist mit seinem TIA-Projekt auf Blindflug unterwegs, solange TIA-Version X noch zufällig mit Windows-Version Y und Firmware-Version Z funktioniert.
Dieses kurzfristige Mindset kann ich bei Auftrags-Programmieren gut verstehen, aber nicht bei seriösen Industrie-Kunden.


----------



## zako (16 Juni 2020)

... da kann man ja richtig Angst bekommen. Allein die ganzen Verpackungsmaschinen, Brauereien, Molkereien, Logistikzentren - was da alles mit TIA programmiert ist! Das bricht alles zusammen und wir müssen alle verhungern!
Zumindest  gehe ich morgen erstmal Klopapier kaufen!


----------



## Mike100 (16 Juni 2020)

zako schrieb:


> ... da kann man ja richtig Angst bekommen. Allein die ganzen Verpackungsmaschinen, Brauereien, Molkereien, Logistikzentren - was da alles mit TIA programmiert ist! Das bricht alles zusammen und wir müssen alle verhungern!
> Zumindest  gehe ich morgen erstmal Klopapier kaufen!



Also so habe ich das wirklich nicht gemeint 
Was ich aussagen wollte:
TIA wird untergehen, und zukünftige Entwicklung wird nicht mehr in TIA stattfinden.
In der Industrie oder IT ist es durchaus üblich, dass tote Tools noch Jahrzehnte weiter verwendet werden.
Der Betrieb als Legacy-Software ändert nichts daran, dass ein Tool de-facto gestorben ist wenn es für Neu-Entwicklungen nicht mehr verwendet wird.


----------



## zako (16 Juni 2020)

Mike100 schrieb:


> ...Was ich aussagen wollte:
> TIA wird untergehen, und zukünftige Entwicklung wird nicht mehr in TIA stattfinden.
> ...


... nutze mal die Nacht um mal von was anderes träumen.


----------



## ms_gp (16 Juni 2020)

Der Thread müsste doch eigentlich heißen: "Warum ich TIA-Portal hasse!"
Ich hasse es nicht. Ich bin nur traurig, dass es nicht besser geworden ist. Ich bin noch jung (Mitte 30ig) und habe jetzt fast 10 Jahre S7 programmiert. Ich hatte mich so darauf gefreut, dass es endlich vorwärts geht, aber so vieles ist nicht fertig, so vieles geht nicht richtig.

Und vieles davon ist gar nicht mal nur die Schuld von SIEMENS allein. Sie mussten ganz viel neu machen und dabei die bisherigen Kunden mit ihren Anwendungen mitnehmen. Wie viele sind bei S5 gestartet und haben das KnowHow nach S7 rübergerettet. Und jetzt, 20 Jahre später, wollen sie es wieder rüberretten. Aber da das alte S7 so dermaßen veraltet ist, gleicht dieses Unterfangen der Quadratur des Kreises.
Da muss dann doch wieder alter AWL-Code emuliert werden, da muss es weiter DBs geben und OBs und Variablentabellen, es muss weiter EAs mit Nummern geben, überhaupt muss es überall Nummern geben. Warum muss man bei SIEMENS ständig irgendwelche Nummern verwalten? Und dann gibt es so komische Sachen wie "optimierte Bausteine". Und dann kommen noch ein paar Fehlentscheidungen beim Management dazu und wir stehen da wo wir jetzt stehen.

 Es ist kein sauberer Schnitt gewesen und den hätte es gebraucht. So bleibt vieles beim Alten. 

Trotzdem kann man damit gute Software für gute Maschinen erstellen. Denn die Anforderungen an die Maschinen ändern sich doch in vielen Fällen gar nicht so sehr. Und wahrscheinlich gilt wie immer, dass ich 80% der Maschinen mit 20% der Funktionen programmieren kann. Oft sind es doch ganz profane Dinge, die man abbilden muss. 

Die Wichtigkeit der Effizienz der Software-Entwicklung ist ja massiv abhängig von der Größe der Maschine. Das ist ein großer Unterschied zur vielen Bereichen in der IT-Welt. Dort ist die Software das Produkt. Bei "uns" ist die Maschine das Produkt. Wenn die Anlage 100Mio kostet, dann ist es fast egal, ob die Software-Entwicklung dabei 100k oder 200k kostet. Wenn ich nur ein Softwareprodukt erwerbe, dann ist das was ganz anderes.

Deshalb wird es TIA auch weiter geben. Der Kostendruck ist bei vielen Maschinen wahrscheinlich nicht hoch genug.


----------



## wollvieh (16 Juni 2020)

Schön beschrieben. Ich bin alt, 61, habe S5 , S7 erlebt,  TIA nur gesehen, seit 1999 arbeite ich mit Codesys in verschiedenen Varianten, nativ,  V2.3,  V3, Indralogic, Twincat2  Twincat3,  und ich persönlich bin von Codesys überzeugt. Gerade heute hab ich ne alte Twincat2 auf Twincat3 hochkonvertiert, problemlos. So muss (sollte) es sein. They software Automation... 
smart Software solutions = 3S !


----------



## Mike100 (17 Juni 2020)

ms_gp schrieb:


> Der Thread müsste doch eigentlich heißen: "Warum ich TIA-Portal hasse!"
> Ich hasse es nicht. Ich bin nur traurig, dass es nicht besser geworden ist. Ich bin noch jung (Mitte 30ig) und habe jetzt fast 10 Jahre S7 programmiert. Ich hatte mich so darauf gefreut, dass es endlich vorwärts geht, aber so vieles ist nicht fertig, so vieles geht nicht richtig.
> 
> Und vieles davon ist gar nicht mal nur die Schuld von SIEMENS allein. Sie mussten ganz viel neu machen und dabei die bisherigen Kunden mit ihren Anwendungen mitnehmen. Wie viele sind bei S5 gestartet und haben das KnowHow nach S7 rübergerettet. Und jetzt, 20 Jahre später, wollen sie es wieder rüberretten. Aber da das alte S7 so dermaßen veraltet ist, gleicht dieses Unterfangen der Quadratur des Kreises.
> Da muss dann doch wieder alter AWL-Code emuliert werden, da muss es weiter DBs geben und OBs und Variablentabellen, es muss weiter EAs mit Nummern geben, überhaupt muss es überall Nummern geben. Warum muss man bei SIEMENS ständig irgendwelche Nummern verwalten? Und dann gibt es so komische Sachen wie "optimierte Bausteine". Und dann kommen noch ein paar Fehlentscheidungen beim Management dazu und wir stehen da wo wir jetzt stehen.



Diese Idiotie mit "optimierten Bausteinen" und ständiger Nummer-Verwaltung ist eine weitere Krücke von TIA, genauso wie der AWL-Support.
Generell verstehe ich es nicht, warum S7-300 etc. überhaupt mitgezogen wurden.
Es ist für die S7-300-Altkunden doch problemlos möglich, Step7 weiterhin zu verwenden.
Die Altsysteme sollen für die Altkunden bestehen bleiben, aber nicht zwanghaft in neue Plattformen hineingestopft werden.



ms_gp schrieb:


> Die Wichtigkeit der Effizienz der Software-Entwicklung ist ja massiv abhängig von der Größe der Maschine. Das ist ein großer Unterschied zur vielen Bereichen in der IT-Welt. Dort ist die Software das Produkt. Bei "uns" ist die Maschine das Produkt. Wenn die Anlage 100Mio kostet, dann ist es fast egal, ob die Software-Entwicklung dabei 100k oder 200k kostet. Wenn ich nur ein Softwareprodukt erwerbe, dann ist das was ganz anderes.
> 
> Deshalb wird es TIA auch weiter geben. Der Kostendruck ist bei vielen Maschinen wahrscheinlich nicht hoch genug.



Das scheint mir eine mögliche Erklärung zu sein. Trotzdem glaube ich, dass die Software-Entscheidungen bei den Leuten liegen sollten, die davon Ahnung haben.


----------



## Ralle (17 Juni 2020)

Mike100 schrieb:


> Generell verstehe ich es nicht, warum S7-300 etc. überhaupt mitgezogen wurden.
> Es ist für die S7-300-Altkunden doch problemlos möglich, Step7 weiterhin zu verwenden.
> Die Altsysteme sollen für die Altkunden bestehen bleiben, aber nicht zwanghaft in neue Plattformen hineingestopft werden.



Hatte ich doch schon geschrieben, das waren tatsächlcih die Marketing-Leute.
Ursprünglich sollte die 300-er nicht mit rein ins TIA. Wäre besser so geblieben.

Und nein, TIA geht nicht unter. leider. Da stecken soviel Manjahre drin und einen Alternative zu entwickeln würde Jahre dauern. Ich hab die Hoffnung aufgegeben. Aber besser wird es auch ncit mehr, da sind einfach zu viele Fallen drin, aus denen man wohl nicht mehr rauskommt. Das tote Pferd reiten wir weiter *ROFL*


----------



## MFreiberger (17 Juni 2020)

Moin,  ich bin ein sehr interssierter Leser dieses Threads.  Ich kenne eigentlich nur SIEMENS (S5 in der Ausbildung gesehen, dann S7 und seit einigen Jahren TIA).  Schon seit einiger Zeit überlege ich, mich in die CoDeSys-Welt einzuarbeiten. Ich denke da in erster Linie an Beckhoff. Dieser Thread hat mir einen neuen Anstoss in diese Richtung gegeben.  





Mike100 schrieb:


> Falls ich ein paar Neu-Einsteiger davon abhalten kann, sich auf diesen TIA-Trümmerhaufen einzulassen, dann hat dieser Thread bereits gewonnen.


  Keine Ahnung, aber zumindest hast Du einem Um-Steiger-Willigen einen neuen Schubs gegeben.   





wollvieh schrieb:


> Schön beschrieben. Ich bin alt, 61, habe S5 , S7 erlebt,  TIA nur gesehen, seit 1999 arbeite ich mit Codesys in verschiedenen Varianten, nativ,  V2.3,  V3, Indralogic, Twincat2  Twincat3,  und ich persönlich bin von Codesys überzeugt. Gerade heute hab ich ne alte Twincat2 auf Twincat3 hochkonvertiert, problemlos. So muss (sollte) es sein. They software Automation...  smart Software solutions = 3S !


  Die Argumente gegen SIEMENS und für eine coDeSys-Alternative verdichten sich.  VG  MFreibeger


----------



## wollvieh (17 Juni 2020)

@MFreiberger:
Links zu einem sehr guten englischen Twincat3 Tutorial...
http://www.contactandcoil.com/twincat-3-tutorial/

Gruß, Wollvieh.


----------



## Blockmove (17 Juni 2020)

MFreiberger schrieb:


> Moin,  ich bin ein sehr interssierter Leser dieses Threads.  Ich kenne eigentlich nur SIEMENS (S5 in der Ausbildung gesehen, dann S7 und seit einigen Jahren TIA).  Schon seit einiger Zeit überlege ich, mich in die CoDeSys-Welt einzuarbeiten. Ich denke da in erster Linie an Beckhoff. Dieser Thread hat mir einen neuen Anstoss in diese Richtung gegeben.    Keine Ahnung, aber zumindest hast Du einem Um-Steiger-Willigen einen neuen Schubs gegeben.     Die Argumente gegen SIEMENS und für eine coDeSys-Alternative verdichten sich.  VG  MFreibeger



So dann bring ich jetzt mal ein paar Argumente gegen die Siemens Alternativen:

Beckhoff Twincat ist bei Updates auch sehr mit Vorsicht zu geniesen. Du findest auch hier einige Beiträge hier im Forum.
Die Teile-Verfügbarkeit ist bei Beckhoff selten besser aber oft schlechter als bei Siemens. Die Komponentenanzahl ist geringer als bei Siemens (Segen und Fluch)
Ethercat bedarf mehr Planung als Profinet und die Fehlersuche ist auch nicht einfacher.
Die Safety-Integration ist bei Siemens - meiner Meinung nach - besser. Auch gerade in Hinblick auf Profisafe
 ---
Wago e!Cockpit ist auch nicht schneller als TIA.
Für die Controller gibt es auch diverse Firmwarestände, die nicht unbedingt kompatibel sind. Online-Update ist erst seit kurzem verfügbar. Für ältere Stände musst du die Firmware beim Support anfordern.
---
Codesys erzeugt reinen Binärcode für die Steuerung. Das Projekt (Quellcode) musst du explizit auf die Steuerung laden. Einen bearbeitbaren AG-Abzug wie bei Siemens gibt es in dem Sinne bei Codesys nicht. Viele Firmen nutzen dies als Know-Protect 

Ich persönlich betrachte eigentlich Codesys-Systeme und TIA als ziemlich ausgewogen.
Jedes System hat seine eigenen Stärken und Schwächen mit denem Hersteller UND Kunde umgehen können müssen.


----------



## ms_gp (17 Juni 2020)

zako schrieb:


> Ich kenne einen Hochschuldozenten, der ein Automatisierungspraktikum leitet. Dort haben z.B. die Studenten die freie Wahl zwischen Beckhoff und SIEMENS (TIA Portal). Ich haben ihn mal gefragt, womit die Studenten lieber arbeiten. Da kam dann die Antwort: SIEMENS
> Ist wohl intuitever.



Was für eine Hochschule ist das? Fachhochschule oder Uni? Wenn ersteres, dann könnte es daran liegen, dass dort viele Leute studieren, die vorher schon eine Ausbildung als Mechatroniker gemacht haben. Und dann haben die an der Berufschule natürlich SIEMENS kennengelernt. Das ist dann Heimspiel.

Ich behaupte, dass ein "normaler" Studierender das SIEMENS System befremdlicher finden wird, vor allem, wenn er vorher schon programmieren gelernt hat, was ja irgendwie Voraussetzung für SPS-Programmierung ist. Sonst muss man ja beim Urschleim mit Variablen, Datentypen, Kontrollstrukturen anfangen. Bei SIEMENS muss er zusätzliche Begriffe verinnerlichen wie "DB" oder "OB". Und es gibt "optimierte Bausteine" und nicht optimierte Bausteine.In TwinCat heißen die Sachen ja einfach "globale Variablen Liste" und Task. 
Außerdem hat man bei TwinCat ja VisualStudio. Und das kennen ja viele schon vom normalen Programmieren.

Vielleicht arbeiten die Studierenden aber wirklich lieber mit TIA, weil sie dann mehr Zeit für andere Sachen haben, weil alles so lange dauert :wink:


----------



## zako (17 Juni 2020)

... anscheinend liegt es daran, dass sich die Studenten mit TIA leichter zu recht finden - wichtig: ich möchte das jetzt Euch nicht als Insiderwissen verkaufen, wie es vielleicht jemand anderes in diesem Thread machen würde.😁 Ich bin da ja nicht dabei und auf subjektive Wahrnehmumgen anderer sollte man sich auch nicht verlassen.
 Aber wenn es daran liegt, dass da ein paar dabei sind die schon Vorkenntnisse haben und man sich gegenseitig aushilft, ist das ja auch okay (war im Studium auch immer froh wenn man Praktikum mit jemanden gemacht hat der sich schon etwas ausgekannt hat  ).
Meine Vermutung wäre eher gewesen, dass man als Neuling eher versucht das zu lernen, was am Markt am verbreitesten ist, wenn man sich im Bereich der Automatisierungstechnik bewerben will...?


----------



## wollvieh (17 Juni 2020)

Googelt mal nach "TIA" und nach "Codesys", lustig, was dabei rauskommt.
;-)


----------



## roboticBeet (18 Juni 2020)

Blockmove schrieb:


> So dann bring ich jetzt mal ein paar Argumente gegen die Siemens Alternativen



In vielen Punkten kann ich nur zustimmen. 

Ergänzen würde ich:

Die Qualität der Editoren; Die Programmierung (unabhängig ob FUP/KOP, SCL oder Graph) ist mit den Siemens Editoren (egal ob TIA oder STEP7 Classic) deutlich besser machbar.
Auch die Online-Darstellung finde ich in Codesys und Co. im Vergleich zu Siemens deutlich gewöhnungsbedürftiger.
Die Dokumentation von Soft- und Hardware ist bei weitem nicht so umfangreich, wie man es bei Siemens gewohnt ist.
Die Hardwarekonfiguration ist bei Siemens auch übersichtlicher.



Blockmove schrieb:


> Codesys erzeugt reinen Binärcode für die Steuerung. Das Projekt (Quellcode) musst du explizit auf die Steuerung laden. Einen bearbeitbaren AG-Abzug wie bei Siemens gibt es in dem Sinne bei Codesys nicht.



Zumindest unter TwinCAT 3 hast du die Möglichkeit SPS-Code in das PG hochzuladen und darin zu arbeiten oder einen sehr detaillierten Vergleich mit einem anderen Projekt durchzuführen.

Auch die ADS-Schnittstelle bei Beckhoff ist sehr sinnvoll, um die Kommunikation mit Windows-Applikationen zu ermöglichen. Durch die Windows-Umgebung beim TwinCAT ist auch die Dateiübertragung (besser) möglich.

Wir entscheiden applikationsabhängig, ob wir Siemens (Standard) einsetzen oder auf zusätzliche Funktionen wie Dateiübertragung, ADS etc. angewiesen sind und greifen in diesem Fall zu Beckhoff.


----------



## wollvieh (18 Juni 2020)

Der Unterschied mag sein, die deutsche Bank mit angegliedertem E-technik Bereich ist eine Aktionärs getriebene AG, die anderen müssen/wollen von ihrer Arbeit leben. ;-)


----------



## ms_gp (18 Juni 2020)

roboticBeet schrieb:


> Die Qualität der Editoren; Die Programmierung (unabhängig ob FUP/KOP, SCL oder Graph) ist mit den Siemens Editoren (egal ob TIA oder STEP7 Classic) deutlich besser machbar.



Stimmt teilweise. Die Editoren von Codesys biete aber eigentlich mehr Möglichkeiten. 


z.B. in KOP Bausteine mit EN Eingang und ohne einzufügen.
FUP und KOP kann man mischen
Zapfen an den Bausteinen gruppieren
Außerdem kann man an den Zapfen direkt Code eingeben, was bei SIEMENS nicht geht.
Codesys hat außerdem den Vorteil, dass Bausteine mit Actions ausgestattet werden können, womit der Baustein weiter untergliedert werden kann, wobei auch die Programmiersprache geändert werden kann. Bei Siemens kann man nur Netzwerkwiese zwischen KOP und SCL wechseln. Die Actions können auch bedingt aufgerufen werden. Insgesamt werden die FBs dadurch sehr viel mächtiger.
mit Pragmas kann man den Kompiliervogang steuern



roboticBeet schrieb:


> Auch die Online-Darstellung finde ich in Codesys und Co. im Vergleich zu Siemens deutlich gewöhnungsbedürftiger.






aus meinser Sicht ist eigentlich ist auch die Onlinedarstellung bei Codesys besser. Wenn man Online ist, ist jeder Baustein den man öffnen online. Bei TIA muss ich immer erst auf diese Brille klicken.
In ST werden die Werte direkt an den Variablen angezeigt und nicht rechts an der Seite, wo man auch noch ausklappen muss, wenn es mehrere Variablen pro Zeile sind.
Enumeratoren und Konstanten werden mit ihrem Namen angezeigt, nicht als Zahlen, wie bei SIEMENS. Abgesehen davon, dass es bei SIEMENS erst gar keine Enums gibt.
Man kann mit pragmas Variablen aus der Online-Darstellung ausschließen. Die tauchen dann in der Onlineansicht im Bausteinkopf nicht auf.
Ich kann kann im Bausteinkopf die Instanzdaten der unterlagerten Bausteine sehen. Bei SIEMENS muss ich dazu den globalen Instanzdatenbaustein öffnen und mich ganz nach unten klicken.






roboticBeet schrieb:


> Die Hardwarekonfiguration ist bei Siemens auch übersichtlicher.



Übersichtlich? Die meinst diese große Fläche in der ich alle Geräte habe und keine ausblenden kann? Wo ich auch keine Geräte deaktivieren kann. Wo ich alles umständlich mit der Maus ewig rumschieben muss bis ich mal Übersicht erzeugt habe?
Bei TwinCat habe ich alles in einem Baum, hierarchisch gegliedert. Man kann nicht vorhandene Baugruppen deaktivieren und muss sich nicht aus dem Projekt löschen. Man kann online unheimlich detaillierte Informationen von den Baugruppen abrufen.
Wo genau ist SIEMENS bitte übersichtlicher? Sorry für die provokante Frage.


----------



## Ralle (18 Juni 2020)

ms_gp schrieb:


> Stimmt teilweise. Die Editoren von Codesys biete aber eigentlich mehr Möglichkeiten.
> 
> 
> z.B. in KOP Bausteine mit EN Eingang und ohne einzufügen.
> ...



Da kann man mal sehen, der Standpunkt macht die Musik.


----------



## roboticBeet (19 Juni 2020)

@ms_gp:

Hängt wahrscheinlich davon ab, mit welchem System man mehr arbeitet und welche Anforderung die jeweilige Applikation hat. Ein wirklich objektives und allgemeingültiges Fazit lässt sich hier wahrscheinlich nicht ziehen.


----------



## Heinileini (19 Juni 2020)

roboticBeet schrieb:


> Hängt wahrscheinlich davon ab, mit welchem System man mehr arbeitet und welche Anforderung die jeweilige Applikation hat. Ein wirklich objektives und allgemeingültiges Fazit lässt sich hier wahrscheinlich nicht ziehen.


Der Satz ...


roboticBeet schrieb:


> Auch die Online-Darstellung finde ich in Codesys und Co. im Vergleich zu Siemens deutlich *gewöhnungsbedürftiger*.



... sagt doch schon eine Menge aus. Über den Schreiber des Satzes und die objektive Reihenfolge seiner Erfahrungen. Nicht so sehr über die Online-Darstellungen selbst.​


----------



## Werner29 (19 Juni 2020)

Wenn jemand mit einem neuen Produkt arbeitet, dann fällt ihm immer sofort auf, wenn ihm was fehlt. Neue Möglichkeiten muss man erst entdecken. Mich würde jetzt so eine Auflistung an Punkten interessieren, die bei Siemens besser sind als bei CODESYS. @robotic_beet: was vermisst du denn bei den Editoren in CODESYS und was genau am Online Modus ist gewöhnungsbedürftig?


----------



## roboticBeet (22 Juni 2020)

Danke für deine Antwort. Nun, wie bereits mehrfach erwähnt, ist dies natürlich eine sehr subjektive Wahrnehmung, welche noch dazu von der jahrelangen Arbeit mit Siemens Produkten beeinflusst ist. 



Einzelne "Setzen" / "Rücksetzen" Befehle in FUP und KOP
Das Hinzufügen von einzelnen S / R Befehlen empfinde ich als sehr mühselig, da dies nur über die Symbolleiste bzw. das Kontextmenü möglich ist. Zum Hinzufügen eines Rücksetzen-Befehls muss zunächst ein Setzen-Befehl hinzugefügt werden, welcher anschließend durch erneutes Anwenden des Kontextmenüs in einen Rücksetzen-Befehl gewandelt wird. Das Löschen des Befehls geht auch nur über das Kontextmenü (Durchschalten von S, R und normaler Zuweisung). Wählt man den S bzw. R Kasten aus und drückt Entfernen, wird auch die Variable mit entfernt.
Bausteinanschlüsse in KOP / FUP haben mehrere Positionen für Negation
Dies ist wahrscheinlich gewollt aufgrund der zusätzlichen Möglichkeit der Flankenerkennung im Bausteinanschluss. Zusammen mit dem nächsten Punkt kann dies aber das schnelle Erfassen des Signalzustands beim Beobachten beeinträchtigen.
Negationen werden farblich nicht hervorgehoben
Der Negationskreis wird, wenn er ein Signal von FALSE nach TRUE negiert nicht farblich markiert, bspw. mit blauer Umrandung. Sitzt die Negation direkt am Baustein, kann man daher nicht auf einen Blick den Signalzustand erfassen, sondern muss zusätzlich den Signalzustand der vorgeschalteten Logik / Variable in Betracht ziehen.
Der gemäß Deklaration erste Bausteinausgang, sofern angezeigt, hat einen langen Anschlusszweig. Die Länge des Strichs ist mindestens so lang, wie die symbolische Verschaltung der restlichen Ausgangssignale. Für ein ENO-Signal sicher hilfreich, für eine andere Variable zerreist es aber die Darstellung und wird damit unnötig kompliziert auf einen Blick zu erfassen.
Das Zusammenklappen einzelner FUP / KOP Netzwerke finde ich bei STEP7 (Classic oder im TIA Portal) sehr hilfreich
Beim Beobachten von ST-Bausteinen wird der Wert einer Variable direkt an die Variable geschrieben. Hierdurch gerät die Formatierung durcheinander und ist schwieriger zu erfassen. Ich persönlich empfinde die Darstellung im TIA Portal mit Trennung von Logik und aktuellem Signalzustand in einer eigenen Spalte besser und schneller zu lesen.
Wie bereits erwähnt, finde ich die Darstellung der Hardwarekonfiguration (v. a. bei STEP7 Classic) besser gelungen, da die Topologie durch den grafischen Aufbau einfacher zu erkennen ist.
Komplexere Logik lässt sich in KOP schwieriger implementieren, da bspw. die Verbindungslinien von Parallelverknüpfungen nicht per Drag&Drop zusammengeführt werden können.
(Nachtrag): Das ST-Programmierfenster ist in Execute-Bausteinen innerhalb von FUP / KOP recht klein

Wir verwenden die Implementierung der Editoren in TwinCAT 3.

Natürlich führe ich keine Liste mit Aspekten, welche in meinen Augen verbesserungswürdig sind, aber die o. g. sind mir zumindest in Erinnerung geblieben. Für Siemens ließe sich natürlich eine ähnliche Liste aufstelle - was hier im Forum ja auch immer wieder thematisiert wird, bspw. in diesem Thread oder in der TIA Wunschliste.
Am Ende geht es darum, wie man mit den, zweifelsohne bei jeder Entwicklungsumgebung vorhandenen, Schwächen umgeht bzw. Workarounds und Kniffe kennt. Dies ist nur mit Erfahrung in der jeweiligen Umgebung möglich.


----------



## Werner29 (22 Juni 2020)

Vielen dank für die Auflistung! Natürlich wollen wir auch die langjährigen Siemens-Anwender von unserem Produkt überzeugen, wen denn sonst?

Wir werden uns das sicher anschauen, was  davon bei uns in die Philosophie passt. Bei einigen Punkten hat man ja  schon gesehen, dass man das so oder so sehen kann:
- das Inline  Monitoring im Online Modus ist für viele Anwender sicher ein Pluspunkt,  das werden wir sicher nicht ändern. Da wäre allenfalls eine alternative  Ansicht denkbar. Ob Anwender das Nachfragen weiss ich nicht.
-  Ähnlich ist es mit einem topologischen Editor für die  Steuerungskonfiguration. Eine topologische Ansicht wäre als alternative  Ansicht denkbar. Dass Anwender das Nachfragen weiss ich ...


----------



## roboticBeet (22 Juni 2020)

Danke für deine Rückmeldung und eure Offenheit bzgl. Feedbacks. Mir ist natürlich klar, dass ihr euer Produkt nicht total umstrukturieren könnt und v. a. auch die alteingesessenen Codesys-Nutzer berücksichtigen müsst. Dennoch freue ich mich, dass ihr Anregungen aus der Community annehmt und diskutiert, ob und ggf. in welcher Form sie in euer Produkt passen.


----------

