Arduino IDE vs. Siemens TIA Portal

[Stefan H. (Firma: dm2sh) (stefan_helmert)]

Hallo,

auf Arbeit habe ich sowohl mit Arduino IDE als auch mit TIA Portal zu 
tun.

Disclaimer: Ich möchte an dieser Stelle gar nicht erst den Versuch 
unternehmen, mich für die Verwendung von Arduino zu rechtfertigen. Ich 
bekenne mich einfach schuldig im Sinne der Anklage. Ich habe für diese 
Sünde Buße getan, indem ich mich mit Siemenskram herum geärgert habe.

Jetzt mal ehrlich: Wenn man den Siemenskram so anschaut, bekommt man 
nicht gerade den Eindruck, dass es sich hierbei um etwas handelt, was 
jemand ernsthaft professionell einsetzt. Da macht selbst der 
Arduino-Kram einen deutlich besseren Eindruck.

TIA Portal enthält zwar sehr viel Funktionalität, z. B. die Integration 
von IO-Link-Kompenten, Rechtemanagement, HMI-Efitor, aber alles wirkt 
wie zusammengeklebt. Es ist nicht wirklich ergonomisch integriert. Es 
ist alles sehr langsam, selbst SCL-Quellcode ist irgendwie binär 
gespeichert. Man kann den nicht einmal richtig exportieren oder 
importieren. Die Variablen-Deklaration ist eine Tabelle, für die es auch 
keine Quellcode-Repräsentation gibt. Man kann den Kram nicht wirklich 
anständig mit git verwalten. Automatische Tests scheinen auch mit 
vorgesehen zu sein. Die Software ist bei mir mehrmals abgestürzt. Die 
Begriffe sind verwirrend. "Laden" kann in die SPS oder von der SPS 
bedeuten. Man kann zwischen komplett laden und nur Unterschiede laden 
wählen. Das sollte nicht notwendig sein. Man kann HMI und SPS auch 
inkonsistenz laden. Die Verknüpfung zwischen HMI und SPS erscheint 
irgendwie primitiv. Man muss auf beiden Seiten Variablen definieren und 
verbinden. Das HMI hat auch Macken. Manchmal "klemmen" Buttons. Und für 
den Schrott verlangen die bei Siemens sogar noch Geld.

Irgendwie kann ich mir nicht vorstellen, dass damit wirklich jemand 
ernsthaft eine Anlage programmiert, die Autos produziert o. ä. Würde 
jemand einen Produktionsanlage mit einer Arduino-basierten Steuerung 
betreiben und diese mit der Arduino IDE programmieren, denke ich nicht, 
dass da signifikant mehr Probleme auftreten.

Warum hat der "professionelle" Kram trotz der miserablen user experience 
und der schlechten Qualität immer noch so viel Relevanz?

[Sven L. (sven_rvbg)]

So Industriekram hat oft ganz andere Anforderungen, als ein Controller, 
auf dem irgendwie ein selbst gebasteltes Programm läuft.

Das geht irgendwo bei der Robustheit der Hardware los und hört damit 
auf, das man die Kommunikationsprotokolle über viele Jahre lang kann.

So kenne ich einen Fall, das hat man ein S7 300 Netzwerk um eine S7 1500 
erweitert, um über diese Daten auskoppeln.

Natürlich hängt die Industrie gefühlt hinterher, weil die Usecases 
einfach andere waren oder auch noch sind, als auf irgendwelcher anderen 
Hardware.

Eine FritzBox kann im ersten Moment auch mehr, als ein um ein vielfaches 
teuerer Cisco Router, aber trotzdem gibt es Einsatzzwecke, da ist so ein 
Cisco trotzdem die bessere Wahl.

Ein Stück weit, ist es wie Äpfel mit Birnen vergleichen, daheim steckt 
man einen Drucker ein und druckt los, im Enterpricesegment ist die 
Installation eines Drucker ein anderer Aufwand, nicht weil er mehr kann, 
aber weil er in eine Struktur eingefügt werden muss.

[Gerhard O. (gerhard_)]

Hallo Stefan,

Nix da! Du brauchst Dich doch nicht für den Einsatz von Arduino IDE 
schämen noch zu entschuldigen. Kommt in den besten Häusern vor. Wir 
setzen ihn manchmal in der Arbeit in In-House MSR Laborprojekten auch 
gerne mit guten Ergebnissen ein. Dafür ist das IDE ideal, weil es 
überall ohne Mucken "out of the box" läuft. Ganz gleich ob PC, Linux 
oder MAC. Nee, ist schon in Ordnung.

Aber der Sven hat da sonst sehr viel recht.

Duck und weg,
Gerhard

[Manfred P. (pruckelfred)]

Sven L. schrieb:
> Natürlich hängt die Industrie gefühlt hinterher, weil die Usecases
> einfach andere waren oder auch noch sind,

Das ist nicht zwingend "hinterher", sondern zur Anforderung passend, die 
wir Kleinspannungselektroniker uns schlecht vorstellen können.

> Eine FritzBox kann im ersten Moment auch mehr, als ein um ein vielfaches
> teuerer Cisco Router, aber trotzdem gibt es Einsatzzwecke, da ist so ein
> Cisco trotzdem die bessere Wahl.

Deutlich andere Anforderung. Fritz muß für den Privatkunden simpel 
beherrschbar sein. Die kann Dinge, die man im Firmennetz nicht braucht 
und lässt dafür vieles vermissen, was dort unverzichtbar ist.

Gerhard O. schrieb:
> Arduino
> [..]
> Wir
> setzen ihn manchmal in der Arbeit in In-House MSR Laborprojekten auch
> gerne mit guten Ergebnissen ein. Dafür ist das IDI ideal, weil es
> überall ohne Mucken "out of the box" läuft.

Der Industrieelektriker, der gelernt hat, Steuerungen mit diversen 
Schützen zu bauen, kann sich mit überschaubarem Aufwand in SPS mit 
Kontaktplänen einarbeiten. Zudem bekommt er Hardware, die direkt zu 
seinen groben Schnittstellen passt.

Gibt man ihm einen Arduino, wird er an C++ verzweifeln, das erfordert 
eine total andere Denkweise. Dazu kommen die Schnittstellen zur 
Außenwelt, die der nicht hat.

Es gibt inzwischen Arduinos im Hutschienengehäuse, ich habe keine 
Ahnung, ob es dafür auch vorgefertigte Software in Art einer SPS gibt.

Würde man Dir eine SPS auf den Tisch stellen, könntest Du auf Anhieb 
Kontaktpläne bauen? Vermutlich nicht.

Also, wie Sven schrieb:
>> Ein Stück weit, ist es wie Äpfel mit Birnen vergleichen,

[Sven L. (sven_rvbg)]

Manfred P. schrieb:
> Das ist nicht zwingend "hinterher", sondern zur Anforderung passend, die
> wir Kleinspannungselektroniker uns schlecht vorstellen können.
Darum schrieb ich ein gefühlt vor das hinterher.

Manfred P. schrieb:
> Deutlich andere Anforderung. Fritz muß für den Privatkunden simpel
> beherrschbar sein. Die kann Dinge, die man im Firmennetz nicht braucht
> und lässt dafür vieles vermissen, was dort unverzichtbar ist.
Das sollte ebenso ein Bsp. sein, wie sich verschiedene Anforderungen für 
verschiedene Anwendungsfälle präsentieren und somit passt das Deutlich 
andere Anforderungen ja auch ganz gut zum ursprünglichen Bsp. des TO.

[Christoph M. (mchris)]

Stefan H. (Firma: dm2sh) (stefan_helmert)
08.03.2025 21:01

>Disclaimer: Ich möchte an dieser Stelle gar nicht erst den Versuch
>unternehmen, mich für die Verwendung von Arduino zu rechtfertigen. Ich
>bekenne mich einfach schuldig im Sinne der Anklage. Ich habe für diese
>Sünde Buße getan, indem ich mich mit Siemenskram herum geärgert habe

Meinst du das hier?
https://www.arduino.cc/pro/software-plc-ide

[S. M. (lichtmensch)]

Siemens ist ein risen Schiff. Regeln und Vorschriften ohne ende. Da sind 
"moderne" ansätze kaum mehr möglich. Dazu kommen kunden wie VW die 
jegliche änderrung verweigern. Alles wie immer und bitte alles bleibt 
wie immer.

[Weingut P. (weinbauer)]

Hab mit TIA meine Rollladensteuerung vom Haus und paar Steuerungen der 
Füllanlage realisiert, S7, ist eben ne ganz andere Herangehensweise, 
eher vergleichbar mit PLD-Programmierung als mit Programmablauf, man 
nimmt Funktionsblöcke und verdrahtet die virtuell. Was TIA draus macht 
ist einem ziemlich schnuppe.
Brauchst n Timer, schwups Timer rein werfen und logisch verdrahten.
Dafür ist die S7 verglichen mit nem Arduino in manchen Bereichen 
schnarchlangsam.
Wenn Du das vergleichen willst, dann musst Du n RTOS und ne Statemachine 
auf m Arduino laufen lassen. Das kommt ner S7 am Nähsten.

[Axel S. (a-za-z0-9)]

Stefan H. schrieb:
> Warum hat der "professionelle" Kram trotz der miserablen user experience
> und der schlechten Qualität immer noch so viel Relevanz?

Weil "Siemens" drauf steht. Noch nie ist jemand dafür gefeuert worden, 
daß er Produkte vom "Marktführer" gekauft hat.

[Matthias S. (da_user)]

S. M. schrieb:
> Siemens ist ein risen Schiff. Regeln und Vorschriften ohne ende. Da sind
> "moderne" ansätze kaum mehr möglich. Dazu kommen kunden wie VW die
> jegliche änderrung verweigern. Alles wie immer und bitte alles bleibt
> wie immer.

Wir haben da mittlerweile eine VEVK die aus der Automobilbranche kommt. 
Wir sind aber eher Handwerk - zwar mit Industrieanlagen, aber Handwerk.

Will für alle Steuerungen S7 vorschreiben, weil dann müssen wir ja nur 
eine Toolchain pflegen und wir können dann bequem selbst mal in der SPS 
was ändern.
Ich habe in meinen 15 Jahren hier ganze zweimal auf die SPSen unserer 
Anlagen zugegriffen - um den Fehlerspeicher auszulesen.
Und ein drittes mal auf eine Fremdanlage um als quasi externer 
Servicetechniker das vorbereitete Programm aufspielen. Ich hab halt 
15min hin gebraucht, für den Anlagenhersteller wären es 6h einfache 
Fahrt + Hotel gewesen.

Ach ja, Kommentar eines Anlagenherstellers (schon vor Jahren auf 
Beckhoff/Codedesys umgestiegen): "Der glaubt doch nicht, dass Ihr unsere 
SPS-Programme bekommt um darin rumzupfuschen?".