TIA Frust: (Kolumen, Kommentar)

[Maagic7]

Zuviel Werbung?
-> Hier kostenlos registrieren

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]

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]

Zuviel Werbung?
-> Hier kostenlos registrieren

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]

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]

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]

Zuviel Werbung?
-> Hier kostenlos registrieren

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]

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]

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]

Zuviel Werbung?
-> Hier kostenlos registrieren

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]

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]

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]

Zuviel Werbung?
-> Hier kostenlos registrieren

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]

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]

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

 

[Ralle]

Zuviel Werbung?
-> Hier kostenlos registrieren

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]

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]

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.

1. 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.
2. 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.
3. 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.
4. 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]

Zuviel Werbung?
-> Hier kostenlos registrieren

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.

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]

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.
  
  

  [*]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]

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.

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.

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.

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.