# TIA Frust: (Kolumen, Kommentar)



## Maagic7 (25 Juli 2017)

Unter jenen, die bereits lange Jahre mit Step7 und anderen Systemen arbeiten
herrscht anscheinend weitgehend Einigkeit, dass TIA-Portoal wohl nicht der große Wurf ist. 
Ich kann mich da voll und ganz anschließen. Obwohl man auch einiges verbessert hat (z.B. SCL Integration),
ist man die Unzulänglichkeiten von Step 7 nicht wirklich angegangen und hat die gleichen Fehler und noch schlimmere
gleich wieder gemacht. Statt uns Entwicklern ein System bereit zu stellen, mit dem man perfekt arbeiten kann,
hat man mehr schlecht als recht von anderen kopiert.
Wer Codesys 3 kennt, weis beim ersten öffnen des TIA-Portals in der Porjektansicht wo die Bedienphilosophie herkommt.
Gefühlt hat man bei Codesys aber mehr Platz am Bildschirm und es reagiert schneller und präziser. 

Statt mit Gewalt ein neues System zu entwicklen was zum alten noch weitghend inkompatibel
ist, hätten wir bei Step 7/WinCC flexible folgendes gebraucht.

1. Ein verbessertes SCL 
 - welches standardmäßig in jeder Step 7 integriert ist (ohne Zusatzlizens)
 - welches nicht ständig bei Querverweisanfragen neu übersetzt und zu Zeitstempeldifferenzen mit der CPU führt
 - welches Status über Multiinstanzen hinweg beherrscht (das beherrscht Codesys, dort hätte man sich das abschauen können)

2. direkt Querverweise aus allen Editoren, vor allem aus dem Symboleditor heraus
   (stattdessen hat man in TIA, sowohl die Querverweise als auch den Symboleditor verschlechtert)

3. Vernüftige Tastaturkürzel, so dass man in einer Hand die Maus fahren kann und mit der andern
   die wichtigsten Kürzel einhändig eingeben. (Am besten umschaltbar für Links- und Rechtshänder)
   Ich bin jetzt wahrlich kein Fan von rein Tastaturbedienten Steinzeit DOS-Programmen, hab aber
   vor kurzem erst wieder mit dem alten Step5 DOS-Programmen gearbeitet. Und es ist extrem erstaunlich
   wie schnell man da mit ein paar Tastendrücken arbeiten kann. Wieso geht sowas unter Windows Programmen nicht auch???   

4. Exportfunktion für die personalisierten Einstellungen.
   Ich hab keine Ahnung mehr auf wie vielen Systemen ich die letzten 15Jhare die persönlichen Einstellungen, Filter usw.
   schon mühselig wieder per Hand eingeben musste.

5. Schnellzugriff für die Fensteranordnung.
    Im Simatic-Manger hat man es noch geschafft, Symbole für die Schnellanordnung der Fenster auf die
    Symbolleiste zu legen. In allen Editoren fehlt dies. Warum??? Dort muss man sich immer über die
    die Drop-Down Menüs hangeln (Fenster/Anorden ...)

6. Filtereinstellungen    
   Die Filtereinstellungen hat man leider nur über Drop-Down-Feld, was immer etwas umständlich ist.
   Die wichtigsten Filter nebeneinander auf der Symbolleiste währe ein stark erleichternder Schritt
   zu weniger Klicks! (z.B. FB, FC, DB ... im Simatic Manager) (Eingänge, Ausgänge, Merker, Zeiten ... im Programmeditor)
   (sieh IBH Ste5/Step7 sowie PI-PG2000)

7. Drop-Down-Felder
   Bildschirme haben immer höhrere Auflösung und trotzdem sind die Standargrößen für Drop-Down-Felder = 8 Zeilen oder weniger.
   Für einen Programmierer sollte es kein größeres Problem darstellen, die Bildschirmgröße zu ermitteln und die
   Dropdownfelder bis zum Bildschrimrand aufzuklappen. (Windows bietet dafür ein API-Funktionen, das geht sogar schon in VB6)

8. Saubere Systembiliotheken, welche die Arbeit erleichtern. 
   (WAGO kann das mit der Building Library, Ifm mit der Hydraulik Lib, beides für Codesys.
    Hier hätte man sich wirklich was abkucken können.)

9. Statusrecorder (aufzeichnen/wiedergeben) des Online-Status
   (die IBH-Software Ste5/Step7 für Windos kann das)

10. Bessere Bausteinvergleicher
   IBH Step5/Step7 macht das vor: gibt es z.B. eingefügten Code, wird die Anzeige gespreizt und der
   Punkt gesucht wo es wieder zusammenpasst. Die Unterschiede werden farblich hervorgehoben.   

! Man müsste und soll die Funktionen gar nicht von anderer Software klauen. Man kann sich das auch Einkaufen bzw. die Erfinder beteiligen!
! Das ist sicherlich nicht teuerer als selbst Blödsinn zu entwickeln!   


WinCC felxibel

1. Ein sauberes Zeitdauereingabefeld für hh:mm:ss, konfigurierbar was und in welcher Form man eingeben will.
   (hh:mm; mm:ss; ...). Das vorhandene Uhrzeitfeld löst dieses leider nicht, da immer auf die Zeitformatierung im
   12h/24h System umgerechnet wird und dann bei einer Zeitdauer von 8h:30m 08:00 AM rauskommt. Zeiteingaben für 
   Prozesse über 24h sind überhaupt nicht möglich.

2. Verbesserte Script-Programmierung und Scripte bei allen Panels 
   (siehe Movicon da ist das mit einem VBA Dialekt auf allen Panels wesentlich besser gelöst als bei WinCC mit VB-Script)

3. Bildbausteine auf allen Panels

4. Leere Variablen oder Festwerte bei Aufruf von Bildbausteinen


CPU's

Stabile fehlerfreie CPU's, was man eigentlich mit den letzten Verisonen der 300'er nach ca. 15 Jahren endlich weitgehend geschafft hatte.
Genau zu diesem Datum wurden sie dann quasi abgekündigt. Gratulation an die Verantwortlichen, so macht man das in einer globalisierten Welt!!!

1. Warum Softwareinterpreter für den Step 7 Code auf den CPU's laufen (zumindest unterhalb der 318er) erschließt sich mir bis heute nicht.
   - diese hatten/haben immer wieder mal Firmwarefehler besonders mit der Mitnahme des VKE wenn man temporäre Variablen verwendet.
     (da denkst du, du bist zu blöd zum programmieren, bis du das auf ner 400er oder ner VIPA laufen lässt und es geht! ASIC statt Interpreter!)
     (mittlerweile kenn ich das Problem und mach eben die zusätzlichen CLR-Befehle rein oder ein Firmwareupdate)

2. Die meisten, die noch vor 2002 die Step7 programmiert haben können wohl noch ein Lied von den Fehlern singen!
   - Da funktionierte z.B. der Temporär-Stack überhaupt nicht und geschachtelte Aufrufe produzierten die wildesten Fehler.
     Leider hat man das damals nicht wirklich durchblickt und dann einfach in S5-Manier mit Merkern programmiert, dann gings!
     Darüber stolpere ich immer mal wieder noch bei alten Anlagen. Bei Siemens kennt man das Problem ganz genau, zumindest diejeigen,
     welche schon lange an der Hotline sitzen.
     S7-Timer Fehler bei einigen CPU's mit dem 32sten Bit. Da hat man anscheinend vergessen das 32igste Bit bei den Timern, die ja definitionsgemäß 
     nur 31 Bit haben, korrekt auszublenden. Solche Fehler hauen so richtig rein. Vor allem merkst du das nicht gleich, sondern erst nach einiger Zeit
     wenn du schon lange wieder von der Anlage weg bist.

     Richtig wäre bei solchen CPU's eine automatische Warnung in Step7 wenn man sich mit einer CPU mit diesen Fehlern verbindet. Technisch wäre das kein
     Problem. Leider wird das aber weitgehend totgeschwiegen! (Ausser man nervit die Leute an der Hotline lange genug, dann bekommt man doch einiges bestätigt)

     Ich frage mich welche Problem bei TIA da noch zu Tage kommen werden.
     Ist ja jetzt alles komplette Compilertechnik und läuft auf irgendwelchen Standardprozessoren!
     Ist ja auch erst gut 7 Jahre alt, dh. noch 7-8 Jahre warten, dann is evlt. nicht schlecht. Dann haben wir 2025 und TIA wird wahrscheinlich gerade
     abgekündigt.     

Was man mit TIA stattdessen geschaffen hat:

1. Ein langsames schwerfälligs, Speicher und Resourcenfressendes Monstrum.
   - Installationsdateien für TIA incl. WinCC flexible Comfort : kanpp 30GB
   - Updates mit Downloadgrößen um 10GB jeweils für Step7 und für WinCC extra.
     (Gott sei dank hab ich letztes Jahr Glasfaser mit 100Mbit bekommen und konnte mich vom alten DSL-Light mit 348kBit verabschieden)
   - Systemanforderung lt. Siemens 16GB Ram 
     (Ich habe ein Fuitsu Lifebook der neuesten Generation mit Intel Quadcore I7, 16GB RAM und 1TB Samsung 850 SSD
      unter TIA ist das einfach nur langsam - TIA nutz auch weitgehend auch nur 1 Core) 

2. zu wenig Platz am Bildschirm.
   - Platz mit leeren Feldern und Schnörkselgrafik verblödet. 
   - Editorenfenster lassen sich nicht auf komplette Bildschirmgröße skalieren
     (Einmal zu MAC und Linux geschielt wäre nicht die schlechteste Idee!
      Menüzeile des aktiven Fensters immer in die Hauptmenüleiste eingeblendet! Bingo!)
    - abelöste Fenster über Windows Fensterleiste anwählbar würde extrem helfen
    - das alte Multi-Dokument System von Step7 ist für Mehrmonitorbetrieb nicht beste Lösung, aber immer noch
      besser als TIA.
    - Seht euch mal die Lazarus (free Pascal) Entwicklungsumgebung an. Wenn man das mit den komplett freien
      Fenstern und dem Docking richtig konfiguriert finde ich das eine ziemlich gute Lösung.
      (Achtung geht leider nicht ganz so einfach unter Lazarus, man muss richtige Packete auswählen und neu komnpilieren)

3. TIA Klickwahnsinn
   Statt die Zahl der notwendigen Klicks, was speziell bei WinCCflexibel zu viel ist, zu reduzieren
   hat man bei TIA WinCCflexible noch einen draufgelegt. Noch mehr Klicks. Teilweise muss man immer doppelt klicken um
   was zu ändern. 1x anklicken für Feldaktivierung, ein zweites mal, um den Inhalt zu bearbeiten.
   Ich war erst wieder auf einem 14tägigen Inbetrienahmemaraton mit 10Std täglich vor TIA-Portal.
   Da bekommst du nach wenigen Tagen krämpfe in der Maus-Operator-Hand!

4. Scorollen in WinCC
   Ich frage mich, welcher Dödel auf die Idee kam das künstlich zu verlangsamen???

5. Wieso müssen die Fenster links und rechts am Bildschrimrand langsam ein- und ausblenden, wenn man
   diese auf automatisch in den Hintergrund einstellt. Und wieso kann man das nicht einfachst zugänglich abschalten???
   Leute, das kostet Zeit. Das muss doch in ms Sekunden möglich sein, die Fenster ein- /auszublenden.

6. Reaktionszeit in TIA
   Ich bin mit Maus positioneren und klicken um ein vielfaches schneller als TIA-Portal reagiert.
   TIA braucht teilweise zwischen 2..4sec um zu reagieren, ich nur einen bruchteil einer Sekunde.
   Das kann's nicht sein!
   Liebe Siemens Programierer: Wieso muss man auch bei jedem mal anklicken die Datenbank komplett neu abfragen?
   Lasst doch die Abfragen offen und lasst euch von der DB per Ereignis über Änderungen informieren,
   dann neu abfragen. Der MS-SQL Server den ihr verwendet kann das!!! Übrigens, der kann auch gespeicherte
   Proceduren das könnte richtig angewendet unter Umständen zu imensen Gewschwindigkeitsexplosionen führen!

7. Umschaltung der Ansichten KOP-FUP-AWL
   Prima, da hat man sich bei CodeSys was abgesehen, was dort schon nicht's taugt.
   Das ging in Step7 classic doch perfekt. Jeder wie er es wollte konnte sich seine Anzeige on the fly umschalten.
   Die beste Lösung für das gespaltene Lager der FUP'ler und KOP'ler.
   Jetzt muss man den Baustein in der entsprechenden Sprache anlegen und dann kann man, wenn man Glück hat,
   den Baustein Umwandeln!!!
   (Liebe verantwortliche Siemensler: Habt ihr noch alle Tassen im Schrank?)

8. Konvertieren von WinCC flexible nach WinCC TIA.
   Bingo! Wo ist der ARRAY Of CHAR (String fester Länge in WinCCflexible 2008 geblieben!
   Wegrationalisiert, mit dem Effekt, dass man Projekte aus WinCCflexible 2008 mit festen Stringlängen z.B.
   für Userkennungen bei Datensätzen nicht mehr ohne Codeänderungen in Step7 konvertieren kann.   

9. WinCCflexilbe wurde mit der 2008er Verision offiziell eingestellt und 2010 kam das TIA-Portal.
   TIA ist jetzt also mindestens 7 Jahre alt und auf die Wünsche der Anwender hat man nur marginal reagiert!
   Siemens malt das immer alles schön. Ich denke es gibt genügend die auf Messen die TIA Probleme bei Siemens immer wieder ansprechen.
   Es interessiert nur keinen. Schreiben Sie mal eine Mail, wenden Sie sich an die Hotline. (Also ich hab's aufgegeben!)
   Von denen die das als super präsentieren müssen ist keiner dabei, der sich dem mal annimmt! Das sind aber leider unsere
   ersten Ansprechpartner. 

10. Bis zur Version V13SP1 hatte WinCCflexible bei großen Projekten regelmäßig Schwierigkeiten bei den Projektübersetzungen.
    Es war praktisch bei den meisten Änderungen eine mehrere Minuten dauerende Komplettübersetzung nötigt um sicher zu gehen,
    dass es auch korrekt läuft. So viele Kaffepausen konnte ich gar nicht machen, dass die Wartezeit einigermassen ausgefüllt war.
    Seit V13SP2 ist das wesentlich besser! (Danke, nach nur 7 Jaren TIA, welch überragende Leistung)

11. Ich hatte ja gleich TIA V14 installiert als es im Updateservice angeliefert wurde. Ich hoffte noch dass die
    WinCC Übersetzungsprobleme der V13 verschwinden.
    Irgendwas hat sich da dann mit der VWware Wrokstation 10 gebissen, und ich konnte keine VM's mehr starten.
    VM's sind aber mittlerweile mit der Siemens Software eine lebensnotwendige Maßnahme. Also mit HD-Images alles wieder zurück.
    (So schlau ist man ja mittlerweile - Erfahrung!)
    So nun mit der V14SP1 wieder probiert - geht! Super ist auch, dass V13 und V14 parallel auf einer Installation laufen.
    Musste ich doch gleich ein paar Tage später an meinem letzten V13 Projekt etwas am Panel ändern. Da wollte ich das in
    der Simulation testen! Bingo! Das geht dann nur noch mit der V14, da die Runtime der V13 ersetzt wurde. Dazu müsste man
    aber das Projekt komplett auf V14 konvertieren. 
    Die VM-Technik lebe auch in Zukunft hoch! Nur mache ich mir Sorgen mit meinen Rechnern. Siemens gibt ja mittlerweile
    einen RAM-Empfehlung von 16GB für TIA. Da kommen die neuen AMD Ryzen mit 8 Kernen und 16 Threads gerade recht. 64GB rein und die 
    Sache sollte mit ein paar TIA-VM's sogar parallel laufen!

12. Übrigens noch Gratulation und Kompliment an Siemens. Seit es TIA-Portal gibt braucht man wirklich genau die richtige
    Version um das Projekt zu öffnen! Diese alten ungemütlichen Zeiten, in denen man ohne Updatevertrag die Step7 Software mit
    den kostenlosen Hardwarepackes selbst noch mit Uraltversionen von Step7 öffnen und bearbeiten konnte ist endgültig vorbei.


Ausblick:

Man muss sich mittlerweile wirklich nach Alternativen zur Siemens S7 umsehen.
Wahrscheinlich unbedachter Weise macht es einem da Siemens mit Ausstieg aus TIA-Portal doch einfacher als gewollt.

Die nächste Alternative ist CodeSys 3. Die gewisse Änlichkeit von TIA zu Codesys macht diesen Schritt auf jedenfall leichter.
Nachdem jetzt wohl auch VIPA Steuerungen mit CodeSys bringen wird, ist das auf jeden Fall zu überlegen.  
Mit den WAGO und Beckkoff System hat man bereits jetzt auch technisch ausgereifte und weit verbreitete Hardware zur Verfügung.
Individuallösungen wie Rexroth Indraworks basieren ja ebenfalls auf CodeSys 3.
Die jetzige VIPA-Lösung mit dem Speed7 Studio ist leider noch nicht ausgereift und das alte WinPLC ist jetzt nicht unbedingt jedermanns Fall!

Meine Vermutung für die Zukunt sind:

1. S7 Classic wird TAI-Portal weit überleben.
2. TIA-Portal wird um 2025 gegen neues System ersetzt 
3. Für Nachfolger von TIA tippe ich auf Siemens eigene CodeSys ähnlich wie bei Beckhoff und Rexroth


----------



## DeltaMikeAir (25 Juli 2017)

> Meine Vermutung für die Zukunt sind:
> 
> 1. S7 Classic wird TAI-Portal weit überleben.



Danke für deinen kompakten Beitrag 

Ja, dass mit dem überlegen von S7 Classic wird mangels beschaffbarer Baugruppen bald ein Problem werden.
Dann wird es nur noch für Bestandsanlagen benötigt und dann läuft es wie bei der S5. Es wird immer weniger,
wir gehen in Rente und die Leute, die sich auskennen werden langsam rar.


Danke für deinen Beitrag!


----------



## Münchnerjunge (25 Juli 2017)

Sorry, aber ich teile weder die Meinung des TE, noch die gängige Aussage "TIA=Schrott und Step7 das einzig Wahre".

Vielleicht ziehe ich den Zorn der meisten diesen Forums auf mich mit einer solchen Aussage.

Aber mal ganz ehrlich. Wenn ihr nie mit Step7 gearbeitet hättet und bekommt dann beide Programme vorgesetzt, würde euer Urteil dann genauso ausfallen??

Ich gehöre wohl zu den wenigen, die von Anfang an fast ausschließlich mit TIA programmieren, und jedes mal, wenn ich Anpassungen an alten Anlagen mit Step 7 machen muss, bekomme ich einfach nur einen Anfall. Ich würde mich selbst niemals als einen guten oder erfahrenen Programmierer bezeichnen, da sind 4 Jahre viel zu wenig Erfahrung, aber TIA wollte ich echt nicht missen. 

Es ist für mich bis auf den heutigen Tag nicht verständlich, wie man ernsthaft meinen kann, Step 7 wäre TIA weit überlegen. Sicher, vieles ist neu, an vieles muss man sich anpassen, viele Dinge gehen nicht mehr so einfach und schnell wie sie gehen, wenn man etwas schon Jahrzehnte macht. Und es tut mir aufrichtig Leid, dass hier der ein oder andere alte Hase zum Ende seiner beruflichen Laufbahn nochmal so viele Umstellungen erlernen muss. Meine alten Kollegen, von denen ich bis heute sehr viel profitiere, tun mir auch immer wieder wirklich Leid. 

Aber niemand will im 21. Jahrhundert mit einer Software arbeiten, die sowohl was Design, als auch Umfang betrifft, noch aus dem 20. Jahrhundert kommen. Die Technik macht Fortschritte, die Anforderungen passen sich an, meine Generation besteht nicht nur aus lauter Pragmatikern, sondern vielmehr aus solchen, die schon in frühen Jahren die Liebe zur Software entdeckt haben und daher vieles aus Intuition ganz anders angehen und das meiste auch anders betrachten.

Bitte zerreist mich jetzt nicht. Bitte schmeißt mir jetzt auch nicht die ganzen Bugs an den Kopf, die auch ad hoc einfallen. Aber - habt ihr es schon mal erlebt, dass in der heutigen Zeit eine Software ohne jegliche Bugs ausgeliefert wird?

Und das gemecker über die ständigen Updates, Neuerungen und Erweiterungen: gut - die Installation ist oft sehr lästig, aber wenn alles dazu beiträgt, dass meine Software noch besser und schneller wird nehme ich eben mal einige Stunden in kauf um den Kram zu installieren. Wer von euch will bitte in dem heutigen Wandel und Fortschritt der Technik, in dieser Schnelllebigkeit, mit einer Software arbeiten, die alle 20 Jahre mal aktualisiert wird?


----------



## DeltaMikeAir (25 Juli 2017)

> Vielleicht ziehe ich den Zorn der meisten diesen Forums auf mich mit einer solchen Aussage.



Nein, ich kann mich auch an die Anfänge von Step7 erinnern wo dann jeder mir bekannte S5 Programmierer
nur noch geschimpft hat. Mir ging es auch so. Ich habe viel mit ProTool gearbeitet, als dann WinCC flex rauskam,
wurde ich fast wahnsinnig ( Abstürze, Fehlfunktionen.... ). Heute ist es für mich das optimale ( wie auch Step7 V5.5 )


----------



## ducati (25 Juli 2017)

Münchnerjunge schrieb:


> Aber mal ganz ehrlich. Wenn ihr nie mit Step7 gearbeitet hättet und bekommt dann beide Programme vorgesetzt, würde euer Urteil dann genauso ausfallen??
> 
> Ich gehöre wohl zu den wenigen, die von Anfang an fast ausschließlich mit TIA programmieren, und jedes mal, wenn ich Anpassungen an alten Anlagen mit Step 7 machen muss, bekomme ich einfach nur einen Anfall.



Jo, die Bedienung vom TIA ist sehr verschieden zum Step7. Deshalb hast Du beim Umstieg vom TIA zum Classic die gleichen Kopfschmerzen wie umgekehrt!

Aber, diese Änderung der Bedienphilosophie hat aber so gut wie keine Vorteile gebracht, dafür aber viele Nachteile!

Darum, warum hat Siemens diesen Schwachsinn verbrochen???

Gruß.


----------



## ducati (25 Juli 2017)

Maagic7 schrieb:


> Meine Vermutung für die Zukunt sind:
> 
> 1. S7 Classic wird TAI-Portal weit überleben.
> 2. TIA-Portal wird um 2025 gegen neues System ersetzt
> 3. Für Nachfolger von TIA tippe ich auf Siemens eigene CodeSys ähnlich wie bei Beckhoff und Rexroth



ich hatte schonmal prophezeit, dass die 300er auch die 1500er überleben wird, bevor die 300er ausstirbt gibts bestimmt schon die 1600er...

Gruß.


----------



## ducati (25 Juli 2017)

Münchnerjunge schrieb:


> Und das gemecker über die ständigen Updates, Neuerungen und Erweiterungen: gut - die Installation ist oft sehr lästig, aber wenn alles dazu beiträgt, dass meine Software noch besser und schneller wird nehme ich eben mal einige Stunden in kauf um den Kram zu installieren. Wer von euch will bitte in dem heutigen Wandel und Fortschritt der Technik, in dieser Schnelllebigkeit, mit einer Software arbeiten, die alle 20 Jahre mal aktualisiert wird?



Auch wenns alle 2 Jahre neue Smarphones gibt, in der INdustrie ist das noch lange nicht so.

Schön für Dich, wenn Du im Büro immer mit der neusten TIA-Version ne Software zusammenklickst, welche Du dann nie mehr zu Gesicht bekommst 

Der Instandhalter, der sich die nächsten 20 Jahre mit 20 Steuerungen alle mit ner anderen Engineeringversion projektiert, rumschlagen darf, wirds Dir bestimmt danken 

Halleluja


----------



## DeltaMikeAir (25 Juli 2017)

> Der Instandhalter, der sich die nächsten 20 Jahre mit 20 Steuerungen  alle mit ner anderen Engineeringversion projektiert, rumschlagen darf,  wirds Dir bestimmt danken



Ja, aus diesem Grund bin ich bei V13 SP2 stehen geblieben. Die läuft bei mir stabil und es gibt noch keinen Grund, hochzurüsten ( außer die neue Panelserie kommt demnächst, welche dann V14 SPx
verlangen ).


----------



## PN/DP (25 Juli 2017)

Münchnerjunge schrieb:


> Und das gemecker über die ständigen Updates, Neuerungen und Erweiterungen: gut - die Installation ist oft sehr lästig, aber wenn alles dazu beiträgt, dass meine Software noch besser und schneller wird nehme ich eben mal einige Stunden in kauf um den Kram zu installieren.


Diese häufigen "einige Stunden" machst Du kostenlos in Deiner Freizeit oder wie denkt Deine Kostenkalkulationsabteilung da drüber? Besonders wenn Du mit den "einigen Stunden" vor Ort beim Kunden anfängst?

Diese unzähligen Versions-Inkompatibilitäten der Engineeringsoftware und der Firmware der Hardware machen es eigentlich unmöglich, dem Kunde vor einer simplen oder größeren Änderung/Erweiterung eine fundiert kalkulierte Kostenschätzung zu geben. Entweder läßt sich der Kunde zur Abrechnung der Unwägbarkeiten auf Stundenbasis überreden oder Deine Firma zahlt drauf - Siemens bezahlt niemandem die Software+Firmware-Update-Installationsorgien und auch nicht die vielen Stunden der Fehlersuche und des Trial+Error, welche Versionskombinationen denn möglich und verträglich sind.

Harald


----------



## Januar (26 Juli 2017)

Ich will euch nicht stören oder vergraulen, aber der Thread, in dem man sich einfach über TIA beschweren kann, ist hier. Hier haben auch schon andere vor euch sich den Frust von der Seele gelabert. Und ehrlich gesagt, gehört dieses Thema auch in den Off-Topic-Bereich.


----------



## Ralle (26 Juli 2017)

Januar schrieb:


> Ich will euch nicht stören oder vergraulen, aber der Thread, in dem man sich einfach über TIA beschweren kann, ist hier. Hier haben auch schon andere vor euch sich den Frust von der Seele gelabert. Und ehrlich gesagt, gehört dieses Thema auch in den Off-Topic-Bereich.



Nein, da liegst du falsch und ChristophD mit seinem Danke genauso.
Und warum Off-Topic-Bereich? Nichts ist aktueller und betrifft SPS-Programmierung mehr, als dieser Misthaufen von Siemens.

Wir alle zahlen seit vielen Jahren an Siemens unsere Updateverträge.
Was wir bekommen ist beschämend.
Inzwischen, nach Jaaaaaahren kann man so leidlich damit arbeiten. Es gibt sogar einige Dinge (oho!!!), die gehen besser von der Hand als im alten S7 Klassik. Die allerdings, kann man an einer Hand abzählen.


@MümchnerJunge

Mag sein, das ist deine Meinung und es gibt ja noch andere Programmierer, die TIA toll finden. Das ist nun mal immer so, was man am besten kennt, findet man auch am tollsten. Das du mit Klassik nicht klar kommst, liegt entweder an mangelnder Übung oder an einem Prorgrammierstil in den Step7-Programmen, der Klassik eher abträglich ist? Keine Ahnung, was ihr da so drinhabt.

Ich war 30 Jahre lang der absolute "Nur-Siemens-Programmierer" und Siemens-Unterstützer. Mit Step7-Klassik hat man uns das erste mal in die Sch... geritten, das war jahrelang unbrauchbar. Noch schlimmer kam es mit WinCCFlexible, das war am Anfang völlig unbrauchbar und mit TIA hat man es nun geschafft, das Ganze noch mal zu toppen. 

Zu Siemens:
Ich hatte ein Meeting mit den Kollegen, die haben zugehört und mitgeschrieben, aber offensichtich liegen viele Probleme schon in den Grundlagen von TIA und werden niemals mehr ausgebügelt. Viele kleine Dinge scheitern an der schieren Zahl und an der Schwerfälligekeit der Siemens-Organisation???? Ich hab einige wenige, der von mir angsprochenen Probleme als gefixt gefunden, die Mehrzahl ist immer noch im System.

Für mich steht fest, Siemens hat keinerlei Achtung und Verständnis für unsere Probleme und Nöte. Dafür wünsche ich denen inzwischen die P... an den Hals, sollen sie Pleite gehen an ihrer Ignoranz und Dummheit.


----------



## Larry Laffer (26 Juli 2017)

Sicherlich ist es so, dass jemand, der S7-Classic nicht kennt, ggf. leichter mit TIA klarkommt. Somit wird sich dieses Problem dann sicherlich auch über die Jahre relativieren - das ist sicherlich der Ansatz von Siemens.
Wenn ich diesen Ansatz mal ganz simpel auf z.B. ein Auto übertrage dann kann man auch da sicherlich sagen, dass es mal an der Zeit wäre, das Gaspedal nach Links zu setzen und die Bremse nach Rechts und die Kupplung in die Mitte. Auch das Lenkrad schränkt mit seiner Platzierung die Sicht auf die Instrumente ein - das könnte also auch z.B. unter das Dach. Und dann noch der Schalthebel - der könnte doch genauso gut im Handschuhfach untergebracht sein - gerade bei einem Automatik-Getriebe ... Aber macht das so Sinn ? In der heutigen Zeit sollte und kann der Fokus doch wohl auf Bedienbarkeit, sich Zurechtfinden und Performance gelenkt werden. Von Bugs will ich in diesem Zusammenhang mal nicht sprechen ...
Ich komme mittlerweile mit TIA auch einigermaßen klar - Nichts aber im Vergleich zu S7-Classic ...
Für mich ist es so, dass zwar ein paar nette Features hinzugekommen sind - dafür im Gegenzug aber die Bedienbarkeit und die Auffindbarkeit von Funktionen, von denen man weiß das sie da sind, EXTREM zurückgefallen ist.

Aber ... wie man sieht ... es ist Alles relativ ...

Gruß
Larry


----------



## ChristophD (26 Juli 2017)

Ralle schrieb:


> Nein, da liegst du falsch und ChristophD mit seinem Danke genauso.
> Und warum Off-Topic-Bereich? Nichts ist aktueller und betrifft SPS-Programmierung mehr, als dieser Misthaufen von Siemens.



Und was unterscheidet Deiner Meinung nach diesen Thread von dem anderen Frust Thread?
Für mich lesen sich beide gleich.


----------



## rostiger Nagel (26 Juli 2017)

Ich habe es mal in den Stammtisch geschoben, weil es meiner Meinung nach ein Stammtisch Thema ist.


----------



## Ralle (26 Juli 2017)

Wenn sich dein Danke darauf bezieht, dass es einen ähnlichen Thread schon gibt, ok. 
Aber ansonmsten kann man ja durchaus nochmal einen starten um eben nicht nur Einzelmängel zu dokumentieren, sondern der Zusatz "Kolumnen, Kommentar" heißt für mich, eben auch nochmal größere Zusammenfassungen zu bringen. Im "Urthread" muß man ja inzwischen schon viel lesen, der ist lang geworden. Auf Wunsch können wir diesen Thread auch in den anderen verschieben.


----------



## ChristophD (26 Juli 2017)

Jup das Danke bezog sich nur auf den Hinweis das es einen Frust Thread schon gibt.

Ansonsten ist TIA für mich eher Feind statt Freund


----------



## maxder2te (26 Juli 2017)

Dann möchte ich auch mal meinen ausführlichen Senf dazugeben:

Vorzeichen:
Ich hab mittlerweile knapp 17 Jahre Erfahrung mit S7 Classic (ab 5.1), hab noch viel mit ProTool (ab 5.2) und WinCCflexible gearbeitet. Ich kenne B&R Automation Studio seit Version 2.4 (ca. 2005), und RS Logix 500 und 5000 von Rockwell. Zudem hab ich einiges mit VB6, C und Matlab gemacht, sowie Erfahrungen mit ProFace GPPro und CoDeSys 2 (in Form des SEW PLC-Editors) gemacht.

Ich war einige Jahre direkt an der Maschine und hab dementsprechend auch einiges an Erfahrung gesammelt, wie Inbetriebnahmen so ablaufen können (und wie sie nicht ablaufen sollen). Ich musste dabei nicht sehr oft, aber doch immer wieder mal an Steuerungen von Fremdherstellern oder Zulieferern ran. Das Fazit daraus: Die Qualität der Wartbarkeit steht und fällt nicht nur mit der Entwicklungsumgebung sondern noch mehr mit der Arbeitsweise der Programmierer, Maschinenhersteller und Endkunden. Für mich wesentliche Punkte dabei sind u.A.

Versionsverwendung: S7 Classic und ProTool haben es meist problemlos verziehen, wenn man ohne Nachzudenken auf aktuellere Versionen hochgegangen ist. Sowohl B&R AS und andere Hersteller waren da generell viel sensibler auf Versionsupdates, wodurch ein Projekt, welches einmal mit einer Version begonnen wurde, auch immer in der gleichen Version verblieb. Dafür gabs bei B&R schon immer Mechanismen, um mehrere Versionen vernünftig parallel betreiben zu können.
Warauf ich damit hinauswill: auch der klassische Siemens-Programmierer muss sich damit arrangieren, dass man verschiedene Versionen parallel hat, nicht alles immer problemlos hochziehen kann. Und bevor man für Änderungen Kalkulationen abgibt, müssen einfach auch solche Rahmenbedingungen geklärt sein - auch auf die Gefahr dass ein Umbau u.U. wesentlich teurer wird als geplant, oder der Kunde sucht sich einen anderen Dummen.
Klare Technologie-Trennung: Eine klares Unding von Siemens ist ja, dass man bei neuer Software auch alte Hardware mit integriert. Dass man S7-300 mit TIA programmieren kann ist imho ein ähnlicher Unfug wie damals die Möglichkeit, ein OP170B mit WinCCflexible zu projektieren. Ich ziehe hier wieder das Beispiel B&R: gewisse Panels konnten nur mit der Visu-SW SG3 projektiert werden, neuere nur mit SG4 - die Parallelinstallation von beiden war von vornherein vorgesehen.
Aber was macht Siemens: Wir packen einfach alles in eine neue Software, in einem Jahr ja eh nur noch die neue Software gebraucht wird und man Siemens-intern denkt, dass man S7-Classic und WinCCflexible einfach nicht mehr pflegen muss. Das ist halt etwas blauäugig - ich denke, es wäre wohl sinnvoller gewesen, die Entwicklungskapazitäten nicht zum "Hochrüsten" alter Hardware zu verbraten, sondern sie in die Pflege der alten Software zu stecken.
Programmierphilosophie: Ein Großteil von Wartungseinsätzen, an denen man mit PG an die Maschine ran muss, hängen einfach nur mit verfehlter Programmierphilisophie zusammen. Ein Beispiel, das ich auch gerne intern und gegenüber Kunden bringe ist das Thema Servomotoren: Ich hatte Kunden, da musste jedesmal, wenn Motor oder ein Geber getauscht wurde, unbedingt jemand mit Programmiergerät ran, da ja das Rücksetzen des Istwertes notwendig war - oder das Hinstellen des Gebers in einen gültigen Bereich usw. Bei uns herrscht die Philosophie: "Das Tauschen von unintelligenten Teilen darf keinen PC erfordern, sondern muss mit Hausmitteln der Applikation gehen." Das beginnt beim Einphasen von Linearmotoren, beim Rücksetzen von Absolutwertgebern bis hin zum Tauschen von Panels oder dezentralen IO-Modulen.
Speziell für letzteres wirft und v.a. Siemens immer mehr Knüppel zwischen die Beine, dazu weiter unten mehr.
Programmierstil: Es gibt tatsächlich noch immer Leute, die würden sich die Hand für AWL abhacken lassen. Mir ist unverständlich, warum dieser Schwachsinn in TIA V12 wieder als vollwertige Sprache mit rein gekommen ist. Ja: man kann manchmal Dinge in Assembler effizienter Umsetzen, aber dazu hätten die AWL-Netzwerke und eine SCL-Umgebung #AWL #END_AWL auch gereicht. Ich kenne niemanden, der bei Beckhoff oder B&R AWL programmiert (Zitat B&R-Vertrieb: "Wir müssen es haben, weil es eine IEC-Sprache ist und wenn wir gegen Siemens anbieten, werden wir danach gefragt. Aber uns ist kein Kunde bekannt, der es einsetzt.") Ich hab bis jetzt in TIA erst einen einzigen AWL-Baustein geöffnet und schnell GGG gemacht.
Diese Unterstützung hat leider dazu geführt, dass wir von einer namhaften deutschen Firma, die u.A. Autos baut, mit "Standardbausteinen" (FCs mit absoluter Adressierung) beglückt wurden, welche ein anderer Lieferant einfach 1:1 aus S7-Classic importiert und notdürftig auf S7-1500 zum Laufen gebracht hatte. Danke auch mal. Dass es zu dem, was der Baustein macht (irgendwas mit Leitsystem und Industrie 4.0), nicht den Hauch einer Spezifikation gibt, sei mal dahingestellt.


Das TIA-Portal ist leider ein Produkt der Siemens "Eins-für-alles" Philosophie, dass sich durch mehrere Produkte zieht. Ein weiteres Beispiel dafür ist Profinet.

Mit Profinet hat Siemens einen Begriff geschaffen, bei dem man einfach "bus" durch "net" ersetzt hat, und gleichzeitig die Eierlegende Wollmilchsau "eins für alles" geschaffen.

IRT-Kommunikation? Kein Problem: Profinet
RT-Kommunikation? Kein Problem: Profinet
Visu-Kommunikation? Profinet
Leitsysteme? Profinet
....
Wir sind ja alle ganz verrückt nach Industrie 4.0 und wollen von jedem noch so unwichtigen Teil Informationen haben - egal ob die jemand braucht oder nicht. Deswegen hängen wir alles an ein Netz. Die Konsequenz daraus: die klassischen (geizigen) Maschinenbauer verwenden es auch für alles. Router? Zu teuer! Eigenes Netzwerk für den nicht IRT-Teil? Zusätzlicher CP notwendig, zu teuer! Speicherkarte in jede ET200S Busanschaltung? Zu teuer! X200-Switches, sodass zumindest der Gerätetausch ohne PG geht? Bist du wahnsinnig, wozu das Teil, der XB005 ist doch auch für Profinet geeignet! .....
Diese Probleme gabs bei Profibus nicht - und auch bei EtherCAT oder Powerlink gibts das nicht - man kann sie schlicht nicht mischen und jede Steuerung hat einfach zusätzliche Ethernet-Schnittstellen.

Zurück zu TIA:
Tatsache ist, dass sich die Optik des Tia-Portals einfach ein die Systeme von Rockwell, Visual Studio, B&R AS usw. angenähert hat, was nicht grundsätzlich falsch ist. Dass es für manche Dinge krötenlangsam ist man eine Weile braucht, manche Dinge wiederzufinden, sei dahingestellt. Das Problem haben andere Systeme teils auch - und wenn ich von Rockwell zu Siemens wechsle und umgekehrt, brauch ich immer eine gewisse Umgewöhnung.
Einige Features, die ich persönlich als riesengroßen Wurf sehe sind

Die durchgehende symbolische Programmierung bis runter zur Hardware. Ich brauche mir absolut keine Gedanken mehr über Adressierung, Bausteinnummern und Offsets machen. Das hat mir bei Rockwell und B&R schon sehr gut gefallen, die waren hier teilweise 15 Jahre voraus. Das ist speziell bei der Bibliotheks- und Frameworkentwicklung wichtig.
Konstanten: dass man Array-Größen über globale oder lokale Konstanten festlegen kann, und sich so mit ein-zwei Handgriffen ganze Pakete an die Applikation anpassen kann, ist der Hammer. Mein Antriebstreiber lässt sich auch diese Weise problemlos von 2 auf 120 Umrichtern skalieren - was auch exzessiv genutzt wird.
Das Sperren/Freigeben jeder einzelnen Variablen für den OPC/HMI-Zugriff: Wir hatten nicht nur einmal das Problem von Datenverfälschung bei der Anbindung von Leitsystemen, weil sich der C#-Programmierer beim Anlegen seine OPC-Tags bei einer Variable vertippt hatte und aus DB1179 dann der DB1197 wurde. Wenn dann im DB1197 die internen Daten des Antriebstreibers liegen und es dadurch sporadisch zu spontanen Bewegungen kommt, ist das schon recht happig. Wireshark ist hier eigentlich keine Chance, sowas überhaupt nachzuweisen. Jetzt sind solche Variablen für das Leitsystem schlicht nicht mehr erreichbar.
Saubere SCL-Integration
Ein Bibliothekssystem, welches zumindest den Namen verdient. Ja, es hakt und knirscht noch an einigen Stellen. Und so wie immer arrangiert man sich mit diesen Problemchen. Aber wenn man sich an eine vorgegebene Arbeitsweise hält, ist das Updaten einer kompletten Bibliothek in einem Projekt doch recht rasch erledigt, ohne jeden Bausteinaufruf (wenn man z.B. im FB eine statische Variable hinzugefügt hat) einzeln anfassen zu müssen. Was noch fehlt sind die Bibliotheks-Konstanten, wie sie beispielsweise B&R bietet.
64 Bit Arithmetik
Ordner und Gruppierung von Objekten
Trace
ProgramAlarm: Das Konzept ist interessant und viel Leistungsfähiger als das alte Alarm_S, vor allem wenn man Frameworks oder Bibliotheken einsetzt. Für die klassischen, projektspezifischen Alarme hat es sich bis dato nicht bewährt.
Instanz-Arrays und das Ausblenden von nicht benötigten Baustein Ein-/Ausgängen
Es fällt auf, dass ich hauptsächlich Features aufzähle, die sich im Prinzip wohl auch in mit S7 Classsic implementieren hätte lassen, vielleicht aber nicht in dieser kompakten Form.
Ein paar ganz grobe Böcke möchte ich nicht unerwähnt lassen:

Mehrere Leute an einem Projekt ist faktisch unmöglich: Ja, es gibt das Team Engineering und die Multiuser-Geschichte. Ersteres ist mehr schlecht als recht von Rockwell abgekupfert (vgl. pending edits - die haben damit schon 20 Jahre Erfahrung), letzteres aus der Hochsprachenwelt und ist vor allem für die Inbetriebnahme ungeeignet. Es war zwar meines Wissens nach nie offiziell zugelassen, dass mehrer Leute in Classc ein und dasselbe Projekt gleichzeitig öffnen - bis 4-5 Leuten hat es aber problemlos funktioniert, solange man auf die Netzwerkverbindung acht gegeben hat.
Natürlich ist unsere Steuerungsphilosophie "eine große Steuerung für alles" eine Ursache dafür, dass das überhaupt nötig ist. Dem wirken wir mit TIA jetzt so entgegen, dass wieder mehr, dafür kleinere Steuerungen in einer Maschine verbaut werden. Aber schnell mal dazusetzen und eine Kleinigkeit umprogrammieren, während der Kollege sich seinen IB-Aufgaben widmet, geht nicht mehr.
Das DB-Konzept und Merker-Konzept: ich werde es nie verstehen, wozu man sowas heute noch braucht.
Instanz-Daten global sichtbar: Sorry, aber in internen Instanz-Daten hat niemand was herumfummeln zu können. Das Rockwell-Konzept der Not-Required-IN/OUT überzeugt mich da mehr.
Die Unterscheidung "optimiert"/"nicht optimiert". Dieser Unfug ist eigentlich nur der Tatsache geschuldet, dass Siemens (aus Kompatibilitätsgründen) wieder auf einen Codeinterpreter setzt und sich nicht auf die Intel/Motorola/sonstwas-Plattform festnageln lassen will. Was heißt "optimiert" eigentlichen? Dass die Folge BOOL-INT-BOOL intern zu INT-BOOL-BOOL gedreht wird um nur 4 Byte Speicher zu belegen? Wäre es nicht Sch.-Egal wenn das 8 Bytes braucht in Zeiten wo RAM nichts kostet? Das ist doch nur ein Feature, mit dem man Diplomingenieure beeindruckt, die vor 30 Jahren eine S5 programmiert haben, heute in Vorständen sitzen und seit 20 Jahren nichts aufwändigeres als Netscape/Internet Explorer oder Word/Excel benutzt haben.
Im B&R-Kurs haben wir damals ganz einfach gelernt, was der Compiler aus einer Deklarationsreihenfolge macht (mit Füllbytes usw.). Das reicht. Eigentlich. "Optimiert" heißt in Wirklichkeit eigentlich nichts anderes als "Wir legen die Reihenfolge willkürlich fest und garantieren euch nicht, dass wir sie bis zur nächsten Software/Hardware-Version nicht wieder ändern". Egal, wir programmieren trotzdem alles optimiert und verlassen uns drauf, dass in einem Array die Variable mit dem Index [1] unmittelbar nach der Variable mit dem Index [0] im Speicher liegt......
Warum muss TIME_TCK einen 31 Bit Zeitwert liefern?

Und was mir nach wie vor absolut unverständlich ist: wieso kann man nicht einfach frei über Pointer/Zeiger/Referenzen oder was auch immer verfügen? Ich hatte schon so oft den Fall, dass ich einen Datenblock per Zeiger an Framework übergeben wollte, welches die Daten aber nicht direkt im aufgerufenen Baustein verarbeitet, sondern an einer anderen Stelle. In C oder auf einer B&R-Steuerung speichere ich einfach einen UDINT-Zeiger ab und kann ihn an beliebiger Stelle wieder auflösen.....

Ach ja: es gibt bis heute keinen Starter für TIA, der ansatzweise den Funktionsumfang des Standalone-Starters besitzt. Stattdessen gibt es kastrierte Versionen für V14, zu denen die Entwicklung gezwungen wurde. Und nun zwingt man auch noch die Sinumerik-Abteilung zu TIA ohne das darunterliegende System mal ernsthaft zu hinterfragen.


Zusammenfassend:
Der Frust mit dem TIA-Portal an sich hält sich bei mir in Grenzen. Ist halt eine andere Software die anders arbeitet. Der Mensch ist ein Gewohnheitstier.
Frustrierend ist halt, dass sich Siemens wieder mal nicht traut, einen Cut zu machen und was gänzlich neues zu bringen. Lediglich neue Fassade für ein System das darunter massiv knarzt. Die S7-1500 wäre an sich der richtige Weg, aber auch hier hat man gegenüber Rockwell nur 10 der 15 Jahre Rückstand aufgeholt.
Die Suche nach Alternativen hat auch hier begonnen......


----------



## ducati (26 Juli 2017)

maxder2te schrieb:


> Ein weiteres Beispiel dafür ist Profinet.
> 
> Mit Profinet hat Siemens einen Begriff geschaffen, bei dem man einfach "bus" durch "net" ersetzt hat, und gleichzeitig die Eierlegende Wollmilchsau "eins für alles" geschaffen.
> 
> ...



Jo, auch wenn dass nix mit TIA zu tun hat, kann ich das nur voll unterschreiben...

Ich versuche halt immer den Feldbus als PROFINET-IO zu bezeichnen und den Rest als Industrial Ethernet. Aber die meisten verstehen das nicht. Diese unsägliche Vermischung von Feldbus und sonstiger Kommunikation find ich auch nicht gut...

Gruß.


----------



## Thomas_v2.1 (26 Juli 2017)

maxder2te schrieb:


> Einige Features, die ich persönlich als riesengroßen Wurf sehe sind
> 
> Die durchgehende symbolische Programmierung bis runter zur Hardware. Ich brauche mir absolut keine Gedanken mehr über Adressierung, Bausteinnummern und Offsets machen. Das hat mir bei Rockwell und B&R schon sehr gut gefallen, die waren hier teilweise 15 Jahre voraus. Das ist speziell bei der Bibliotheks- und Frameworkentwicklung wichtig.





Man hat aber wieder nur einen halben Schnitt gemacht. Die Bausteinnummern sind immer noch vorhanden, und sind sehr elementar im TIA-Portal vergraben. Wenn ich nicht einen totalen Nummern-Wildwuchs bei automatischer Nummernvergabe haben will, dann muss ich mich jetzt um zwei Dinge kümmern. Vorher konnte ich nach Nummern sortieren, jetzt werden Bausteine nach Namen sortiert.
Wenn das Projekt anständig aussehen soll, dann muss ich eine entsprechende Nummer selber vergeben, und beim Namen auch noch darauf achten dass meine Bausteine eine vernünftige Reihenfolge bekommen.
Ich habe schon Fremd-Projekte gesehen wo die Bausteine wieder die FC oder FB-Nummer am Anfang enthalten, das kann es aber auch nicht sein.

Zumindest bei "optimierten" DBs hätte man die Nummer ganz einfach weglassen sollen, oder einen Nummernbereich einstellbar machen in dem sich die Automatik austoben darf, so wie es auch bei Step7 CFC der Fall war.

Und wenn du aus einer Bibliothek einen Baustein in dein Projekt ziehst und du hast die Nummer schon vergeben, dann erhältst du auch einen Nummernkonflikt. Der kann dann zwar mittlerweile automatisch korrigiert werden, aber ich könnte gut ganz ohne Bausteinnummern leben - Siemens aber anscheinend nicht.



maxder2te schrieb:


> [*]Das Sperren/Freigeben jeder einzelnen Variablen für den OPC/HMI-Zugriff: Wir hatten nicht nur einmal das Problem von Datenverfälschung bei der Anbindung von Leitsystemen, weil sich der C#-Programmierer beim Anlegen seine OPC-Tags bei einer Variable vertippt hatte und aus DB1179 dann der DB1197 wurde. Wenn dann im DB1197 die internen Daten des Antriebstreibers liegen und es dadurch sporadisch zu spontanen Bewegungen kommt, ist das schon recht happig. Wireshark ist hier eigentlich keine Chance, sowas überhaupt nachzuweisen. Jetzt sind solche Variablen für das Leitsystem schlicht nicht mehr erreichbar.



Hast du die Funktion schon einmal ausgetestet?
Ich vermute die Funktion ist nur für den internen OPC-Server der SPS aktiv. Bei einer 1200 kann ich den Haken für Schreibzugriff entfernen, und kann trotzdem lustig vom HMI (Siemens Panel im gleichen Projekt) auf die Variable schreiben.
Meiner Erkenntnis nach sind diese ganzen Optionen mit erreichbar / sichtbar / schreibbar nur ein Hinweis (Bitte) an ein System das nicht zu machen, aber kein echter Zugriffsschutz.
Wenn du per WinCC eine 1500er Steuerung browst, dann überträgt sie dir prinzipiell den kompletten Symbolhaushalt, nur WinCC filtert diesen dann nach der Option "sichtbar" bzw. "erreichbar". Das heißt aber nicht, dass du darauf nicht trotzdem Zugriff bekommst.


----------



## maxder2te (26 Juli 2017)

Thomas_v2.1 schrieb:


> Man hat aber wieder nur einen halben Schnitt gemacht. Die Bausteinnummern sind immer noch vorhanden, und sind sehr elementar im TIA-Portal vergraben. Wenn ich nicht einen totalen Nummern-Wildwuchs bei automatischer Nummernvergabe haben will, dann muss ich mich jetzt um zwei Dinge kümmern. Vorher konnte ich nach Nummern sortieren, jetzt werden Bausteine nach Namen sortiert. Wenn das Projekt anständig aussehen soll, dann muss ich eine entsprechende Nummer selber vergeben, und beim Namen auch noch darauf achten dass meine Bausteine eine vernünftige Reihenfolge bekommen.


Den "Wildwuchs der Nummern" sehe ich keinesfalls als Problem oder als Wildwuchs. Für mich sind die Nummern nur eine Information, die TIA unnötigerweise anzeigt. Ich blende sie geistig vollkommen aus. Die Sortierung von Bausteinen nach Namen ist nur die halbe Wahrheit, man muss natürlich die Mittel, die TIA zur Verfügung stellt, auch nutzen. Das sind

Ordner: jeder Bereich / jede Bibliothek / jedes Framework kommt in einen eigenen Unterordner.
Hierarchische Namen:
die Ordner bekommen hierarchische Namen, wobei diese mit eine Nummer beginnen. z.B. 01 SysLib, 02 HMI, 04 Antriebstechnik, 100 Station 1, 200 Station 2, ...
die Bausteinenamen bekommen hierarchisch Präfix-Ketten wie z.B. Sys___ für die Systembibliothek, SysMath___ für jenen Teil der Systembibliothek für Mathematische Funktionen, SysMsg___ fürs Meldesystem, Ax___ für alles was mit dem Antriebspaket zu tun hat, AxCmd___ für ein Antriebskommando, ....
bei einer Station sieht das dann beispielsweise so aus: Präfix 'Saw', es existiert ein FB mit dem Namen 'SawFb', der in MAIN oder CYCLIC_INTERRUPT mit der Instanz 'SawIdb' aufgerufen wird. Die weiteren Bausteine haben dann die Namen SawGeneral für den allgemeinen Part, SawOutput für den Ausgangsbaustein usw. usw.
Wenn man die Ausführungsreihenfolge dazu noch kennzeichnen will, bietet sich ein Zwischenindex an, um beim vorgenannten Beispiel zu bleiben: Saw00Fb, Saw00Idb, Saw01General, Saw10Jog, Saw20Auto, Saw21AutoHome, Saw22AutoCut, Saw23AutoChangeBlade, Saw80Output, Saw90Alm, ...

Die Nummern oder Indizes, die hier vorkommen sind aber prinzipiell willkürlich gewählt. Sie müssen lediglich Aussagekräftig sein. Wichtig ist die Hierarchie und ein paar Grundregeln, an die sich alle halten. Bausteinnummern sind aber völlig irrelevant.




Thomas_v2.1 schrieb:


> Ich habe schon Fremd-Projekte gesehen wo die Bausteine wieder die FC oder FB-Nummer am Anfang enthalten, das kann es aber auch nicht sein.


Ok, das geht gar nicht. Es deutet aber drauf hin, dass die zuständigen Programmierer entweder nicht die Zeit, die Motivation oder das Wissen haben, was man anders machen könnte. Für eine saubere symbolische Denkweise habe ich auch den Ausflug zu B&R und zu Matlab gebraucht.




Thomas_v2.1 schrieb:


> Zumindest bei "optimierten" DBs hätte man die Nummer ganz einfach weglassen sollen, oder einen Nummernbereich einstellbar machen in dem sich die Automatik austoben darf, so wie es auch bei Step7 CFC der Fall war. Und wenn du aus einer Bibliothek einen Baustein in dein Projekt ziehst und du hast die Nummer schon vergeben, dann erhältst du auch einen Nummernkonflikt. Der kann dann zwar mittlerweile automatisch korrigiert werden, aber ich könnte gut ganz ohne Bausteinnummern leben - Siemens aber anscheinend nicht.


Offensichtlich nicht.
Leider gibts auch Nummernkonflikte, die nicht automatisch aufgelöst werden können. Ich hab da mit V14 mal eine Situation produziert, mit der ich einen Absturz reproduzieren konnte. War aber eine saublöde Situation.





Thomas_v2.1 schrieb:


> Hast du die Funktion schon einmal ausgetestet?
> Ich vermute die Funktion ist nur für den internen OPC-Server der SPS aktiv. Bei einer 1200 kann ich den Haken für Schreibzugriff entfernen, und kann trotzdem lustig vom HMI (Siemens Panel im gleichen Projekt) auf die Variable schreiben.
> Meiner Erkenntnis nach sind diese ganzen Optionen mit erreichbar / sichtbar / schreibbar nur ein Hinweis (Bitte) an ein System das nicht zu machen, aber kein echter Zugriffsschutz.
> Wenn du per WinCC eine 1500er Steuerung browst, dann überträgt sie dir prinzipiell den kompletten Symbolhaushalt, nur WinCC filtert diesen dann nach der Option "sichtbar" bzw. "erreichbar". Das heißt aber nicht, dass du darauf nicht trotzdem Zugriff bekommst.


Nein, habe ich nicht. Und der Einwand ist berechtigt.
Aufgrund des DB-Konzepts kann das auch nur auf die Browsing-Ebene Auswirkungen haben. Aber wenn man konsequentest symbolisch mit optimierten Bausteinen arbeitet, dann gibt es keinerlei Grund dafür anzunehmen, dass Fehler, wie der von mir beschriebene passieren. Weil dass man durch einen einfachen Zahlen- oder Zeichendreher ein Tag mit einer vollkommen anderen Funktion beschreibt, ist zumindest unrealistischer.


----------



## Thomas_v2.1 (26 Juli 2017)

Das mit den Ordnern ist praktisch. Der Nachteil ist jedoch, dass die Ordnerstruktur nicht auf der Steuerung landet. D.h. falls jemand in die Verlegenheit kommt das Projekt aus der Steuerung herunterladen zu müssen, dann ist die schöne Hierarchie weg. Darum würde ich mir bei der Bezeichnung nicht alleine auf die Ordner in dem sich die Bausteine befinden verlassen.

Ich habe z.Zt. ein Projekt bei dem ich ein paar Nicht-Optimierte DBs für die Kommunikation mit einem Alt-System bereithalten muss. Und hier brauche ich wieder die Bausteinnummern. Und da hätte ich halt ganz gerne den DB-Bereich bis 100 freigehalten. Das geht aber nicht, also muss ich immer selber vergeben.


----------



## maxder2te (26 Juli 2017)

Thomas_v2.1 schrieb:


> Das mit den Ordnern ist praktisch. Der Nachteil ist jedoch, dass die Ordnerstruktur nicht auf der Steuerung landet. D.h. falls jemand in die Verlegenheit kommt das Projekt aus der Steuerung herunterladen zu müssen, dann ist die schöne Hierarchie weg. Darum würde ich mir bei der Bezeichnung nicht alleine auf die Ordner in dem sich die Bausteine befinden verlassen.


Das ist klar.
Was ich wohl nicht klar genug ausgedrückt habe: Die Ordner sind nur eine Zusatzmaßnahme. Die Zusammengehörigen Bausteinblöcke lassen sich alleine durch die Bausteinpräfixen reproduzieren, auch ohne Ordner. Die "Nummerierung" ist dann halt weg.
Dass die Ordner nicht auf der PLC vorhanden sind, ist auch irgendwie schwach.....


----------



## Ralle (26 Juli 2017)

maxder2te schrieb:


> Das ist klar.
> Was ich wohl nicht klar genug ausgedrückt habe: Die Ordner sind nur eine Zusatzmaßnahme. Die Zusammengehörigen Bausteinblöcke lassen sich alleine durch die Bausteinpräfixen reproduzieren, auch ohne Ordner. Die "Nummerierung" ist dann halt weg.
> Dass die Ordner nicht auf der PLC vorhanden sind, ist auch irgendwie schwach.....



Weil niemand von den Siemensprogrammieren jemals ein Projekt > 15 Bausteine getestet hat, wurde das halt nachgefrickelt. Wie so Vieles am TIA. Also landet es im Projekt, denn richtig gemacht, müßte es auf die Steuerung und "Richtig machen" wollen die aus irgend einem unerfindlichen Grund einfach nicht.

PS: Ich wollte vorhin an einer Steuerung die Eingänge einer F-Baugruppe ändern. Keine Chance, war einfach teilweise ausgegraut, ohne Grund. Da half nur löschen, neu anlegen, übertragen, Safety-Adresse vergeben, wieder übertragen ... Was soll an sowas auch nur ansatzweise vertrauenserweckend sein?


----------



## Maagic7 (27 Juli 2017)

an maxder2te kann ich mich nur nochmal anschließen!

AWL und die Programmierung der 300er/400er hat meiner Meinung nach im TIA-Portal nichts zu suchen!

Mal zu den evtl. positiven Seiten!

Geht jetzt im TIA folgendes? (hatte noch nicht die Zeit das alles zu suchen und zu probieren)

1. Vernüftige Templates? So dass man einen Baustein anlegen kann und automatisch auf mehrere kopieren, die Platzhalter werden dabei durch E/A usw automatisch ersetzt.
    (ich habe immer zig Baugruppen die im Prinzip alle das gleiche machen. In Step7 lässt sich das aber nicht vernüftig in Multiinstanzen packen - da wirst beim Testen whansinnig) 

2. Wenn das mit 1. nicht geht! Gehen dann Multiinstanzen mit Parameter UDT, so dass man dann im Status noch sieht was passiert?

Ähnlich TwinCat/CodeSys, da kann man in SCL richtige UDT-Parameterfarmen anlegen und das dann  an die Multiinstanzbausteine übergeben. Und man bekommt den Status!

3. Intellisense in SCL
in CodeSys kann man das Intellisense dazu missbrauchen sich wirklich nichts mehr merken zu müssen. Mann kann z.B. ein Startobjekt für seine Anlage definieren,
dann Unterobjekte usw.

z.B.  o  Ist das Startobjekt  man tippt  "o."  und hat über das Intellisense faktisch alle Anlagenfunktionen parat

Type Transport
   MotorStart : Bool;
   VentilStopper : Bool;
   SensorAnfang : Bool;
   SensorEnde : Bool;
End Type


Type MainObject
  Transport1 : Transport;
   Transport2 : Transport;
End_Type

o : MainObject

dann kann man das Intellisens nutzen und tippt nur noch 

o.   // dann hat man seine ganze Anlage mit allen Funktionen im Intellisense - Merken muss man sich da nicht's mehr

d.h. :
 IF o.Transport1.SensorAnfang THEN
     o.Transport1.MotorStart := True;
END_IF;


----------



## maxder2te (27 Juli 2017)

Maagic7 schrieb:


> 1. VernÃ¼ftige Templates? So dass man einen Baustein anlegen kann und automatisch auf mehrere kopieren, die Platzhalter werden dabei durch E/A usw automatisch ersetzt.
> (ich habe immer zig Baugruppen die im Prinzip alle das gleiche machen. In Step7 lÃ¤sst sich das aber nicht vernÃ¼ftig in Multiinstanzen packen - da wirst beim Testen whansinnig)
> 
> 2. Wenn das mit 1. nicht geht! Gehen dann Multiinstanzen mit Parameter UDT, so dass man dann im Status noch sieht was passiert?
> Ã„hnlich TwinCat/CodeSys, da kann man in SCL richtige UDT-Parameterfarmen anlegen und das dann an die Multiinstanzbausteine Ã¼bergeben. Und man bekommt den Status!


Also, sowas wie Templates mit Platzhaltern gibts wohl nicht. Zumindest hab ich noch nichts dergleichen gesehen.

Das Thema Multiinstanzen ist bei S7-1500 doch recht mächtig. Man kann Instanz-Arrays anlegen und eigentlich alles recht gut beobachten.

Das mit den Parameterfarmen verstehe ich nicht ganz 100%ig. Was problemlos geht, ist, dass du jedem FB UDTs als InOut mitgibst. Sofern der Datentyp (nicht die Variable) bei jedem FB-Aufruf der gleiche ist, ist das generell kein Problem. Es ist dabei auch egal, ob die angehängte Variable ein "DB vom Typ" oder ein Element in einem Global-DB oder eine stat-Variable ist. Wenn der Datentyp unterschiedlich ist, gibts die Variant-Geschichte mit generischem Datentyp. Du musst dann intern auswerten, welcher Datentyp angehängt wurde und entsprechend darauf reagieren.



Maagic7 schrieb:


> 3. Intellisense in SCL
> in CodeSys kann man das Intellisense dazu missbrauchen sich wirklich nichts mehr merken zu mÃ¼ssen. Mann kann z.B. ein Startobjekt fÃ¼r seine Anlage definieren,
> dann Unterobjekte usw.
> 
> ...



SCL ist voll integriert und hat auch Autovervollständigung usw. Ich arbeite auch nur noch so.
Was nicht mehr so einfach geht, ist das Deklarieren von Variablen in Textform. UDTs legt man wie Bausteine an, Datenbausteine detto.
Das mit o. muss dann halt so aussehen, dass es einen DB mit dem Namen "o" gibt und du gruppierst darin deine Datenstrukturen, Typen, usw. Da die DBs jetzt wesentlich größer sein können, ist das kein Problem.


----------



## ducati (28 Juli 2017)

Maagic7 schrieb:


> an maxder2te kann ich mich nur nochmal anschlieÃŸen!
> 
> AWL und die Programmierung der 300er/400er hat meiner Meinung nach im TIA-Portal nichts zu suchen!



nunja, es gibt viele Szenarien, wo auch verschiedene Dinge Sinn oder nicht machen...

unseres sieht so aus:

- hunderte Anlagen mit 300/400 und seit 10 Jahren unveränderter Standartbibliothek in AWL
- Kunde bzw. Chef sagt, ab nächster Woche beginnt die IBN ner neuen Anlage mit 1500
- wann soll man da jetzt nen neuen Standard entwickeln???
- warum soll der neue 1500er Standard sich elementar von den restlichen 100erten Anlagen unterscheiden???

Es gibt immer sehr viele Zielkonflikte um sich für den einen oder anderen Standard/Programmierstil zu entscheiden... Die Unterschiede sind aber maginal, das wichtigste ist, das der Standard konsequent durchgezogen wird, und sich nicht ständig ändert...

Gruß.


----------



## rostiger Nagel (28 Juli 2017)

ducati schrieb:


> nunja, es gibt viele Szenarien, wo auch verschiedene Dinge Sinn oder nicht machen...
> 
> unseres sieht so aus:
> 
> ...



Es ist halt so, das eine 1500er keine 300er ist und das man dann mit seinen entwickelten Standard nicht weiter kommt.
Das ist so als wenn man den Lieferanten gewechselt hat. Dein Chef trifft mit den Harten Wechsel eine Unternehmerische
Fehlendscheidung, das kann man nicht den TIA Portal oder Siemens anlasten.


----------



## Larry Laffer (28 Juli 2017)

Naja ... also sooooooo unterschiedlich sind die beiden Systeme nun auch wieder nicht, das man nicht den größten Teil von entwickelten Standards und Spielregeln nicht auch im TIA wieder weiterverwenden (und ggf. weiterentwickeln) könnte ... 8)

Gruß
Larry


----------



## ducati (28 Juli 2017)

Larry Laffer schrieb:


> Naja ... also sooooooo unterschiedlich sind die beiden Systeme nun auch wieder nicht, das man nicht den größten Teil von entwickelten Standards und Spielregeln nicht auch im TIA wieder weiterverwenden (und ggf. weiterentwickeln) könnte ... 8)
> 
> Gruß
> Larry



jo eben, dann bleibt aber AWL und absolute Adressierung erhalten... womit ich auch kein Problem habe, was die letzten 30 Jahre funktioniert hat, wird jetzt auch nicht mit ner 1500er plötzlich böse 

Deshalb, kommt halt immer auf den konkreten Einzelfall drauf an.

Gruß.


----------



## bike (29 Juli 2017)

Es stimmt, die Hardware wird moderner und besser? das ist der Lauf der Zeit und das ist auch gut so.
Schwarz / grüne Bildschirme will niemand mehr.
Die Frage die sich stellt ist doch, warum MUSS alles, das gut gut funktioniert hat und auch von Nutzern akzeptiert wurdem in den Mülleimer?
Urspünglich hatten wir gehofft, dass solche ein Chaos wie bei Step 7 Version 1.0 NIE wieder geschehen würde. 
Aber ein Konzern ist eben nicht den Kunden verpflichtet, sondern nur den Aktionären.(Grüsse nach Moskau).
Langsam finde ich Bosch, Fanuc  oder Codesys gut., da kommt was Neues, aber man MUSS nicht alles, was in den letzten Jahren erarbeitet wurde, wegschmeißen.
 Als Neuling, mit nur 40 Jahren Leben als PLC Programmier, verstehe ich das nicht (mehr).
Leider? habe ich noch? kein Alzheimer, würde vieles einfacher machen, manchmal.

bike


----------



## zako (6 August 2017)

Maagic7 schrieb:


> ...
> Meine Vermutung für die Zukunt sind:
> 
> 1. S7 Classic wird TIA-Portal weit überleben.
> ...



... das brauchen die ja gar nicht zu entwickeln. Man hat je ne SIMOTION da finden sich die CodeSys - Anwender eher wieder als bei einer klassischen SIMATIC mit Datenbausteinen,  Merkern, OB´s, ... . 
In der SIMOTION ist z.B. auch OOP umfänglich umgesetzt (auch Matlab SIMULINK, C/C++, ... wird unterstützt). 
Vor daher sehen wohl die SIEMENS- Vertriebler solche Aussagen wie "... wir müssen uns mal nach eine anderen System umsehen" relativ entspannt. Der SIMOTION fehlt eigentlich nur SAFETY. Dann braucht man aber noch ne F-CPU (Einbindung über  I-Device F-PROXY).


----------



## JesperMP (8 August 2017)

Ich finde dass es ist i.O. mit mehrere TIA Frust Themen. Desto mehr desto besser ! 
Wenn es kein Erleichteung von Siemens ins Sicht gibt, hilft es sein Frustrierung zu äussern und Leidensgenossen zu finden.


Dies ist was mich am meisten bei TIA und S7-1500 am meistens begeistert bzw. ärgert:


Verbesserungen in STEP7 TIA + WinCC TIA gegenüber STEP7 Classic + WinCC Flexible: 



Array inizieren direkt in KOP/FUP.
Slice Zugriff.
AT-Sicht direkt in KOP/FUP.
Trace.
Speichern von Programmbaustene Code die nicht fertig editiertsind, sogar mit Code-Fehler ! (Einer von die grössten Mängel bie Classic).
64-bit Variablen und dazuhörige Befehle (was wichtig ist weil einige Siemens Spezialmodule verwendet schon 64-bit).
Manche funktionen die in Classic nicht wirklich sauber funktioniert, funktioniert gut in TIA.


Verschlechterungen in STEP7 TIA + WinCC TIA gegenüber STEP7 Classic + WinCC Flexible:


In den Alltag stört es mich enorm mit den schlechten Bedienung von TIA. Selbst mit ein grossen Monitor hat man nicht genug Platz, weil so viel verschwendet ist. Dazu muss mann immer wieder Fenster aufklappen, verschieben, zuklappen, dasselbe füe eingabelfelder usw. usw. Kein ordentliche Tastaturbediening ohne Maus.
Optimiert/nicht optimiert. Was soll das ??? Ich will den gesammten funktionalität haben, ohne das ich etwas zuwählen oder abwählen muss.
Zwang um den Firmwarestand mit den Softwarestand von TIA zu synkronisieren. Dies ist für mich schon mit wenige S7-1500 Kundenprojekte ein Problem. Ich kann nicht meine Kunden auf ein Firmwareversion updaten, nur weil ich für eine halbe Stunde online ein Problem anschauen will. Wenn hier in den Zukunf kein Rückwärtskompatibilität in TIA kommt, dann sehe ich ein Alptraum dass um seine Kunden unterstützen zu können muss man sämtliche TIA version (v11, V12, V13, V14, V15 .....) installiert haben.
Zwang um den Firmwarestand in den Hardware mit den Firmwarestand in Software zu synkronisieren. Mit S7-300 kann man den Flashkarte von ein -EG10 CPU ein ein -EH14 stecken, und es läuft. Wenn ich es richtig verstanden habe, dann kann unsere Kunden nicht mehr einfach den Flashkarte von ein defekten S7-1500 CPU in ein neuen CPU stecken. Das wird in den Zukunft ein grossen Problem sein.
PLC-SIM 1500 kann keine geschützte Bausteine Simulieren. Was katastrofal ist, da mehr und mehr Siemens Biblioteksbausteine für Spezielle Module in Einsatz kommt. Dies macht PLCSIM mehr oder weniger unanwendbar. Ich muss ein realen CPU auf den Tisch haben, was auch nicht ohne Probleme ist (Firmwarestand immer aktualisieren). Warum bezahle ich für PLCSIM ?
Das ET200SP ein Enttäuschung geworden ist muss ich auch nennen. Ich hätte lieber ein etwas verbesserte ET200S, nicht diese winzige und mechanisch empfindliche Design.

Ahhh, jetzt fühle ich mich schon besser.


----------



## Thomas_v2.1 (8 August 2017)

JesperMP schrieb:


> Zwang um den Firmwarestand mit den Softwarestand von TIA zu synkronisieren....
> Zwang um den Firmwarestand in den Hardware mit den Firmwarestand in Software zu synkronisieren...
> PLC-SIM 1500 kann keine geschützte Bausteine Simulieren. Was katastrofal ist, da mehr und mehr Siemens Biblioteksbausteine für Spezielle Module in Einsatz kommt...



Richtig spaßig wird es, wenn du diese Punkte kombinierst.
Also wenn du ein Projekt mit geschützten Bausteinen von denen du kein Passwort hast, auf eine neue TIA-Version hochrüsten musst. Das ist nämlich in vielen Fällen nicht möglich.
Ich würde darum empfehlen wenn das Projekt abgeschlossen ist und die Gewährleistung abgelaufen: Finger weg von einer alten TIA-Anlage.


----------



## DeltaMikeAir (8 August 2017)

Hallo zusammen,
ich stimme euch mit der Firmwaregeschichte voll und ganz zu. Ich suche ab und an in "fremden" Anlagen, also Anlagen, die nicht bei
uns gebaut wurden nach Fehlern. Das ergibt sich manchmal so, ich bin bei einem Kunden, die sprechen mich an, dass irgendeine Anlage
nicht mehr läuft und ob ich nicht mal schauen kann. Bei Step7 5.5 kein Problem, insofern ein einigermaßen aktuelles Programm da ist.
Ich schaue mir dass an und dann finde ich auch meistens die Fehlerursache. Wenn es eine allerdings ein TIA Projekt ist, lasse ich die
Finger davor. Bei einer fremden Anlage würde ich nie ein FW Update machen, um vielleicht nur ein kleines Problem zu finden.

Dass ist mir zu heiß.


----------

