TIA Frust: (Kolumen, Kommentar)

Thomas_v2.1

Well-known member
Beiträge
7.760
Punkte Reaktionen
2.293
Zuviel Werbung?
->Hier kostenlos registrieren
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

Well-known member
Beiträge
541
Punkte Reaktionen
164
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

Supermoderator
Teammitglied
Beiträge
14.246
Punkte Reaktionen
3.296
Zuviel Werbung?
->Hier kostenlos registrieren
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?
 
Zuletzt bearbeitet:
OP
M

Maagic7

Well-known member
Beiträge
245
Punkte Reaktionen
79
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

Well-known member
Beiträge
541
Punkte Reaktionen
164
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.

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;

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

Well-known member
Beiträge
5.369
Punkte Reaktionen
981
Zuviel Werbung?
->Hier kostenlos registrieren
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

Forums-Knochenbrecher
Teammitglied
Beiträge
13.843
Punkte Reaktionen
3.940
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ß.

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

Supermoderator
Teammitglied
Beiträge
12.961
Punkte Reaktionen
2.677
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

Well-known member
Beiträge
5.369
Punkte Reaktionen
981
Zuviel Werbung?
->Hier kostenlos registrieren
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

Well-known member
Beiträge
6.464
Punkte Reaktionen
794
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

Well-known member
Beiträge
1.472
Punkte Reaktionen
377
...
Meine Vermutung für die Zukunt sind:

1. S7 Classic wird TIA-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

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

Well-known member
Beiträge
6.273
Punkte Reaktionen
1.170
Zuviel Werbung?
->Hier kostenlos registrieren
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

Well-known member
Beiträge
7.760
Punkte Reaktionen
2.293
  • 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

User des Jahres 2018
Beiträge
8.611
Punkte Reaktionen
1.972
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ß.
 
Oben