TIA Hochsprachen-Erweiterungen für TIA SCL

Draco Malfoy

Level-1
Beiträge
1.168
Reaktionspunkte
82
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo Forum

1) Wann sollen die OOP-Erweiterungen für die TIA-CPUs (Methoden, Vererbung etc.) für TIA kommen - gibt es hierzu irgendwelche Infos ?
2) Sieht jemand in seiner Arbeit aktuell einen Nutzen davon ?
 
Hallo Forum

1) Wann sollen die OOP-Erweiterungen für die TIA-CPUs (Methoden, Vererbung etc.) für TIA kommen - gibt es hierzu irgendwelche Infos ?
2) Sieht jemand in seiner Arbeit aktuell einen Nutzen davon ?

Naja riesen Vorteile bringt OOP sicher nicht. Aber ich erwarte mir einfach eine Arbeitserleicherung.
Im Prinzip kannst du heute schon mit FBs und UDTs fast das gleiche erreichen wie mit Methoden und Eigenschaften.

Bei Vererbung bin ich sehr vorsichtig. Die Gefahr ist groß, dass damit die Diagnose / Fehlersuche schwierig wird.

Spannend für mich ist, wie Siemens Querverweise, Intelisense und Status umsetzt.
Also wielange ich brauche bis ich von "Station3.Anschlag2.GetGrst" auf das BMK des fehlenden Ini's komme.
 
Hat zwar nicht unbedingt etwas mit OOP zu tun, aber was ich bei Codesys 3 ganz gut finde sind die Namespaces.
Aber solange bei Siemens die Nummern über allem stehen bringt das alles nichts.

Nun, ich programmiere im Moment zu einem überwiegenden Teil noch auf SIMOTION. Dort hat's auch Namespaces. Habe ich aber noch nie sinnvoll nutzen können. Nummern gab es bei Simotion noch nie.

Wo steht denn das das kommt?
Das sind informelle Informationen, man hört es aber immer wieder. Genau so wie die Information, daß die Simotion im Jahr 2025 abgekündigt werden soll.
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
Nun, ich programmiere im Moment zu einem überwiegenden Teil noch auf SIMOTION. Dort hat's auch Namespaces. Habe ich aber noch nie sinnvoll nutzen können. Nummern gab es bei Simotion noch nie.

Leider hab ich nie verstanden, warum Siemens nicht die Simotion als Grundlage für TIA genutzt hat, sondern alles neu machen mußte. Was wohl zu Codesys-Like oder zu ostlastig entwickelt???

Zum Thema: Ich hoffe Siemens braucht noch sehr lange, mindestens 10 Jahre, dann hör ich auf und ihr könnt Steuerungen von mir aus in C# entwickeln, vererben und überladen was das Zeug hält oder bist das nächste Kraftwerk in die Luft fliegt. :ROFLMAO:
 
Zuletzt bearbeitet:
Nun, ich programmiere im Moment zu einem überwiegenden Teil noch auf SIMOTION. Dort hat's auch Namespaces. Habe ich aber noch nie sinnvoll nutzen können. Nummern gab es bei Simotion noch nie.

Dann hast du keine Namenskollisionen mehr, bzw. ist es dann sehr unwahrscheinlich da du dann auch zwei gleiche Namensräume haben müsstest. Wenn du viel mit Bibliotheken arbeitest ist das schon nützlich. Auch als Bibliotheksersteller musst du dich nicht darum kümmern nur Namen zu verwenden die irgendwo im Siemens Universum noch nicht verwendet werden, oder wie es dann viele machen als Ersatz für den Namespace dem Namen dann noch ein Kürzel voranstellen.
 
Dann hast du keine Namenskollisionen mehr, bzw. ist es dann sehr unwahrscheinlich da du dann auch zwei gleiche Namensräume haben müsstest. Wenn du viel mit Bibliotheken arbeitest ist das schon nützlich. Auch als Bibliotheksersteller musst du dich nicht darum kümmern nur Namen zu verwenden die irgendwo im Siemens Universum noch nicht verwendet werden, oder wie es dann viele machen als Ersatz für den Namespace dem Namen dann noch ein Kürzel voranstellen.

Könnte Sinn ergeben, wenn ich z.B. Fehlerkonstanten quer über alle Librarys gleich halten möchte. Ich weiß aber nicht, was passiert wenn ich zwei Bibliotheken mit verschiedenen NameSpaces in einer übergeordneten Quelle verwende, und dort dann zum Beispiel einer Variablen den Konstantenwert aus einer dieser Librarys zuweisen möchte.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Naja riesen Vorteile bringt OOP sicher nicht. Aber ich erwarte mir einfach eine Arbeitserleicherung.
Im Prinzip kannst du heute schon mit FBs und UDTs fast das gleiche erreichen wie mit Methoden und Eigenschaften.

Bei Vererbung bin ich sehr vorsichtig. Die Gefahr ist groß, dass damit die Diagnose / Fehlersuche schwierig wird.

Spannend für mich ist, wie Siemens Querverweise, Intelisense und Status umsetzt.
Also wielange ich brauche bis ich von "Station3.Anschlag2.GetGrst" auf das BMK des fehlenden Ini's komme.
Also zumindest das Thema Vererbung kann man sich vereinfacht jetzt schon im Tia Portal ansehen.
Und zwar wird es bei den Technologieobjekten für motion control bereits eingesetzt. In der Deklaration sieht man in base die Elemente der Basisklasse, bei Speedaxis die erste Vererbungsstufe und bei PositioningAxis die zweite.

Einsatzgebiete sind schnell einige skizziert: Bibliotheken für das Handling von azyklischen Zugriffen z. B. IO-Link, Profinet oder CANopen, wo man eine Basis gemäß Smartsensor-Profil, Profidrive-Profil oder CIA301 hat und dann geräte- oder herstellerspezifisch ableitet.
Bibliotheken zum verarbeiten von UTF8-Strings oder Datenstrukturen mit Meta-Informationen (z. B. json, sortierte Listen,...)
 
Einsatzgebiete sind schnell einige skizziert: Bibliotheken für das Handling von azyklischen Zugriffen z. B. IO-Link, Profinet oder CANopen, wo man eine Basis gemäß Smartsensor-Profil, Profidrive-Profil oder CIA301 hat und dann geräte- oder herstellerspezifisch ableitet.
Bibliotheken zum verarbeiten von UTF8-Strings oder Datenstrukturen mit Meta-Informationen (z. B. json, sortierte Listen,...)

Man sollte bedenken, daß für eine solche Anwendung hohe Sachkunde erforderlich ist. Außerhalb von Bibliotheken würde ich diese Werkzeuge nicht erlauben, es sei denn, der Entwickler und Inebtriebnehmer sind ein und dieselbe Person.

Wenn ich mir schon vorstelle, wie verschiedentliche Wald-und Wiesenprogrammierer, die nicht einmal innerhalb von KOP/FUB vernünftig arbeiten wollen, den sinnvollen Einsatz von einem SR-FlipFlop nicht verstehen und stattdessen irgendwelche Lösch- und Reset-Orgien im Programm veranstalten - auf die objektorientierte Programmierung mit Methoden und Vererbung treffen. Dann wird mir übel.
 
Man sollte bedenken, daß für eine solche Anwendung hohe Sachkunde erforderlich ist. Außerhalb von Bibliotheken würde ich diese Werkzeuge nicht erlauben, es sei denn, der Entwickler und Inebtriebnehmer sind ein und dieselbe Person.

Wenn ich mir schon vorstelle, wie verschiedentliche Wald-und Wiesenprogrammierer, die nicht einmal innerhalb von KOP/FUB vernünftig arbeiten wollen, den sinnvollen Einsatz von einem SR-FlipFlop nicht verstehen und stattdessen irgendwelche Lösch- und Reset-Orgien im Programm veranstalten - auf die objektorientierte Programmierung mit Methoden und Vererbung treffen. Dann wird mir übel.

*ACK*

Sehe ich im Prinzip genauso!
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Man sollte bedenken, daß für eine solche Anwendung hohe Sachkunde erforderlich ist. Außerhalb von Bibliotheken würde ich diese Werkzeuge nicht erlauben, es sei denn, der Entwickler und Inebtriebnehmer sind ein und dieselbe Person.

Wenn ich mir schon vorstelle, wie verschiedentliche Wald-und Wiesenprogrammierer, die nicht einmal innerhalb von KOP/FUB vernünftig arbeiten wollen, den sinnvollen Einsatz von einem SR-FlipFlop nicht verstehen und stattdessen irgendwelche Lösch- und Reset-Orgien im Programm veranstalten - auf die objektorientierte Programmierung mit Methoden und Vererbung treffen. Dann wird mir übel.

Die Gefahr sehe ich auch.
Ich habe mich in letzter Zeit etwas mit Codesys 3.x und OOP beschäftigt. Also da liegt Segen und Fluch bzw. Licht und Schatten eng beieinander.
Fehlersuche kann da schon sehr heftig werden.
Mit der klassischen Fehlersuche "Schau mal warum A3.4 nicht angesteuert wird" kommt man nicht ohne weiteres mehr ans Ziel.
Je nachdem wie verstreut irgendwelche Methodenaufrufe im Programm sind.
 
Aber ich muß Draco Recht geben, für Bibliotheken ist das sicher etwas, für "normale" 0815-Schrittdketten mit ein wenig drumrum braucht es das eher nicht.
Wenn ich im TIA einen 3-Achser mit der T-CPU steuern will, dann nutze ich die entsprechenden Bibliotheksbausteine und kann darin ohnehin nicht wirklich Fehler suchen.
 
Naja ... und genauso sollte man das m.E. auch sehen ...
Der beste Ansatz für eine gute Programmierung ist eigentlich der : durchblicke ich nach 4 Wochen, in denen ich nichts mehr mit meinem Programm zu tun hatte, dieses immer noch ...

Für die SPS ist das so, dass ich ja auch jetzt schon "Objekte" erstellen kann - also "Standard"-Bausteine, die immer wieder in gleicher Form zum Einsatz kommen.
Was ich schon mal hin und wieder ganz witzig gefunden hätte wäre das "Überladen" - hier aber bezogen auf Übergabe-Parameter an den Baustein.
Namespaces, wie bereits erwähnt, sind sicher ganz nützlich - hier oder da.
Aber ganz grundsätzlich ist der Hauptbestandteil, zumindestens meiner bisherigen Werke, immer ein Ablauf gewesen. Da braucht man das doch eher weniger bis gar nicht - naja ... und der Einwand von Draco hat schon was - das habe ich erst unlängst wieder bei dem Lieferanden einer Maschine an uns gesehen (da hatte sich auch der Programmierer in (s)einem Wahn es sich so richtig selbst besorgt - bin mal gespannt wie das ausgeht).

Gruß
Larry
 
Zuletzt bearbeitet:
Zurück
Oben