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

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.
 
rostiger Nagel schrieb:
ja dann beschreibe doch mal wie es aussehen soll!
Zum Vergrößern anklicken....

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.
 
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.
Zum Vergrößern anklicken....

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.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
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.
Zum Vergrößern anklicken....

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.
 
Blockmove schrieb:
Ich warte ja schon einige Zeit darauf, dass Mike100 seine innovative Alternative vorstellt.:ROFLMAO:
Zum Vergrößern anklicken....

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).
 
Zuletzt bearbeitet:
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.
War jedesmal "nett", wenn der Buildprozess aus irgendeinem Grund abgebrochen hat.
Sowas brauch ich im Job wirklich nicht.
Zum Vergrößern anklicken....

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).
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
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.

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.
Zum Vergrößern anklicken....

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

https://m.youtube.com/watch?v=lcOxhH8N3Bo
Zum Vergrößern anklicken....

Die Probleme von TIA-Portal sind zum Glück eh nicht mehr meine persönlichen Probleme :ROFLMAO:
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).
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
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.
 
Zuletzt bearbeitet:
... 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! :ROFLMAO:
 
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! :ROFLMAO:
Zum Vergrößern anklicken....

Also so habe ich das wirklich nicht gemeint :ROFLMAO:
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.
 
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.
 
Zuletzt bearbeitet:
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 !
 
Zurück
Oben