TIA TIA Portal V19 Wunschliste [Diskussion]

Status
Für weitere Antworten geschlossen.
Zuviel Werbung?
-> Hier kostenlos registrieren
Wenn wir bei der Sprachauswahl sind, möchte
ich das irgendwie das es so gestaltet ist, das ich
nicht immer zum Übersetzer eine Excel-File mit
25.000 Zeilen schicke für 10 HMI Seiten.
Der das gestaltet hat, hat doch einen Knall
und gehört die Höchststrafe aufgebrummt.
Strafe denke ich mir noch aus, tut aber weh.
 
Beim Export aus der globalen Textliste lässt sich bereits auswählen, z.B. nur "Meldetexte" und "HMI Bild".
 
Zeitstempel beim Prüfzeichen nicht mit einbeziehen.
Speziell beim Arbeiten mit dem Projektserver und Multiusern gibt es immer wieder Probleme, daß durch das Kompilieren nach dem einchecken der Zeitstempel zwischen Server und lokaler Kopie sich unterscheidet. Habe ich Änderungen im F-Programm gemacht, muß ich den ganzen Rotz nochmal übertragen und schicke die CPU nochmal in den Stop.
Das war schon mal weg, weiß nicht mehr, bei welcher Version, aber in der nächsten war es wieder da.

Keine Abstürze mehr, die die Datenbank korrumpieren. Ich schicke öfter mal ein Projekt zum Support, um die Datenbank reparieren zu lassen, damit ich nicht wieder bei Null anfangen muß. Nach einem halben Jahr Vorbereitung und Inbetriebnahme ist das extrem belastend. Es wäre ja auch schon hilfreich, wenn Siemens die Ursache mal erkennen würde, aber scheinbar sind wir ja noch nicht mal in der Betatestphase von TIA angekommen.
 
derwestermann schrieb:
Ich wünsche mir so sehr ein FOR...EACH....

Dieser Wunsch ist auch schon von anderen zur V18 vorgebracht worden.
Zum Vergrößern anklicken....
Und über was willst du damit iterieren? Ein For-Each ist meiner Meinung nach nur sinnvoll, wenn die Programmiersprache auch mehrere Sammlungen von Objekten anbietet, wie Listen, Stack, Queues, usw. Bei TIA gibt es aber einzig und alleine das Array.
 
Heinileini schrieb:
Irgendwie schon, finde ich. Eine Ansammlung von Daten und meist auch von mehr als 1 DatenTyp.
Aber ob man mit einem Mischmasch von DatenTypen in einer FOR-Schleife etwas anfangen kann? :unsure:
Zum Vergrößern anklicken....
Ok, dann Sammlung von gleichartigen Objekten. Über jedes Element einer Struct zu iterieren, mit diversen unterschiedlichen Datentypen, ob das sinnvoll ist? Vielleicht ist mit dem gewünschten For-Each hier aber auch etwas ganz anderes gemeint, so in Richtung "As" in Vb um sich Schreibarbeit zu ersparen.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ich möchte einfach über jedes Objekt in einem STRUCT eine Schleife haben.
Vor allem, wenn ich den später erweitere, möchte ich nicht alle Stellen raussuchen und dort immer das Gleiche wieder nachprogrammieren müssen.

ARRAYs sind halt z.B. oft nicht so sprechend, wie eine Sammlung gleichartiger Datentypen im STRUCT.
Höchstens noch, wenn man "Unmengen" an globalen Konstanten für 0, 1, 2 ... schafft, um Felder des ARRAYs konkret zu adressieren.
Und alles vom STRUCT in ein ARRAY umzudatieren (AT, Serialize..) verbraucht ja auch einiges an Zykluszeit


Ob die Objekte dann wirklich den richtigen Datentypen für das Geplante haben, kann man ja ggf. prüfen.
 
Reicht es nicht ein Input von Array[*] of myUDT deklarieren.
Mit UpperBound und LowerBound die Grenzen ermitteln und dann for Schleife zwischen LowerBound und UpperBound durchlaufen.

Würde mir wünschen, man könnte LowerBound und UpperBound auch auf statische Arrays anwenden, dann kommt man nicht in den Fehler, dass jeman die Konstante in der Deklaration ändert und das Programm dann in einen Bereichslängen Fehler läuft.
 
Ja.

Wie Thomas schon geschrieben hat, fehlen die iterierbaren Objekte. Außer Arrays gibt es da nichts. Und wie iteriert man dann über ein Struct unterschiedlicher Datentypen? In jeder Loop den Datentyp prüfen verbraucht sehr viel Zeit. Listen gibt es nicht.

Man muss auch bedenken, dass es letztendlich auch der Norm entsprechen und vor allem deterministisch sein muss. PLC's sind immer noch Echtzeit Systeme,bei dem die Abarbeitungszeit der einzelnen Verzweigungen kalkulierbar sein muss.
 
Michitronik schrieb:
Wie Thomas schon geschrieben hat, fehlen die iterierbaren Objekte. Außer Arrays gibt es da nichts. Und wie iteriert man dann über ein Struct unterschiedlicher Datentypen? In jeder Loop den Datentyp prüfen verbraucht sehr viel Zeit. Listen gibt es nicht.

Man muss auch bedenken, dass es letztendlich auch der Norm entsprechen und vor allem deterministisch sein muss. PLC's sind immer noch Echtzeit Systeme,bei dem die Abarbeitungszeit der einzelnen Verzweigungen kalkulierbar sein muss.
Zum Vergrößern anklicken....
Wenn ich per AT ein ARRAY über ein solches STRUCT legen kann, sollte IMHO auch ein FOR...EACH möglich sein. 🤷‍♂️

Und das es keine unterschiedlichen Datentypen sind, muss ja auch nicht zur Laufzeit geprüft werden, sondern kann schon beim Übersetzen abgehakt oder eben als Fehler des FOR...EACH-Aufrufs angekreidet werden.


"Problem" am AT, ich kann eben nicht per Array[*] deklarieren.
Ich muss die Größe bei jeder Verwendungstelle immer manuell angeben/anpassen. Ist aufwendig und viel schlimmer -> fehleranfällig.
FOR...EACH dagegen würde automatisch mit der aktuellen STRUCT-Größe mitlaufen.
Und AT funktioniert bei zusammengesetzten Datentypen auch nicht am INOUT, daher muss ich momentan auch noch zum STATIC hin & wieder zurück kopieren.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
hucki schrieb:
Wenn ich per AT ein ARRAY über ein solches STRUCT legen kann, sollte IMHO auch ein FOR...EACH möglich sein. 🤷‍♂️

Und das es keine unterschiedlichen Datentypen sind, muss ja auch nicht zur Laufzeit geprüft werden, sondern kann schon beim Übersetzen abgehakt oder eben als Fehler des FOR...EACH-Aufrufs angekreidet werden.


"Problem" am AT, ich kann eben nicht per Array[*] deklarieren.
Ich muss die Größe bei jeder Verwendungstelle immer manuell angeben/anpassen. Ist aufwendig und viel schlimmer -> fehleranfällig.
FOR...EACH dagegen würde automatisch mit der aktuellen STRUCT-Größe mitlaufen.
Und AT funktioniert bei zusammengesetzten Datentypen auch nicht am INOUT, daher muss ich momentan auch noch zum STATIC hin & wieder zurück kopieren.
Zum Vergrößern anklicken....
Das Thema mit den Array-Grenzen kann man eigentlich recht gut abfangen, indem man konsequent mit PLC-Konstanten oder lokalen Konstanten arbeitet, die die auch im Code verwendet. Das Thema Array-Überläufe kenne ich seit TIA V13 eigentlich gar nicht mehr.

Zum Thema FOR EACH - das ganze Konstrukt setzt einfach auf der Idee der Objektorientierung auf, die S7 einfach fehlt. Es macht einfach einen riesen Unterschied, ob man
  • eine Funktion aufruft, welche über Datentypen bzw. deren Instanzen (also Variablen) iteriert oder
  • über Objekte iteriert, die ihren eigenen Code mitbringen
Das Konstrukt mit AT auf unterschiedliche STRUCT ist ein Ansatz, den man mit C-89 gemacht hat, und der damals schon nicht gerne gesehen war. STRUCT ist ein Relikt und gehört imho eigentlich verboten - kein Wunder dass es sowas bei Rockwell oder B&R nicht gibt.

Michitronik schrieb:
Ja.

Wie Thomas schon geschrieben hat, fehlen die iterierbaren Objekte. Außer Arrays gibt es da nichts. Und wie iteriert man dann über ein Struct unterschiedlicher Datentypen? In jeder Loop den Datentyp prüfen verbraucht sehr viel Zeit. Listen gibt es nicht.

Man muss auch bedenken, dass es letztendlich auch der Norm entsprechen und vor allem deterministisch sein muss. PLC's sind immer noch Echtzeit Systeme,bei dem die Abarbeitungszeit der einzelnen Verzweigungen kalkulierbar sein muss.
Zum Vergrößern anklicken....
Ja, aber es scheitert nicht an "iterierbar", sondern an "Objekte".
 
STRUCT ist ein Relikt und gehört imho eigentlich verboten - kein Wunder dass es sowas bei Rockwell oder B&R nicht gibt.
Zum Vergrößern anklicken....
Kannst du das etwas detaillierter ausführen? Dein Standpunkt ist interessant.
Ich fand den Unterschied zwischen Struct und UDT auch erstmal verwirrend.
Allerdings nutze ich ein Struct gern innerhalb eines Bausteins, um meine Variablen zu gruppieren. Finde das einfach übersichtlicher.
 
Mrtain schrieb:
Kannst du das etwas detaillierter ausführen? Dein Standpunkt ist interessant.
Ich fand den Unterschied zwischen Struct und UDT auch erstmal verwirrend.
Allerdings nutze ich ein Struct gern innerhalb eines Bausteins, um meine Variablen zu gruppieren. Finde das einfach übersichtlicher.
Zum Vergrößern anklicken....
Zum strukturieren von statischen Variablen innerhalb von Bausteinen ist STRUCT ok. Ich werde STRUCT auch ganz gerne zur Deklaration von Konstanten mittels schreibgeschützter DBs.
Aber es gibt nichts, wo ein STRUCT nicht durch UDT ersetzt werden könnte. Dass für die obigen beiden Beispiel STRUCT eleganter und portabler als UDT ist kann ich nicht abstreiten.

Was aber eine katastrophe ist, dass viele Programmierer nach wie vor STRUCT an Schnittstellen einsetzen, oder STRUCT erstellen und dann innerhalb von Bausteinen mehrfach einsetzen und dazu diese STRUCT kopieren.

Also, alles was wiederverwendbar sein muss, muss imho ein Datentyp sein.
 
Status
Für weitere Antworten geschlossen.

Similar threads

DeltaMikeAir
  • Angepinnt
TIA TIA Portal V21 Wunschliste [Diskussion]
8 9 10
Antworten
190
Aufrufe
57K
ducati
D
DeltaMikeAir
  • Gesperrt
TIA TIA Portal V20 Wunschliste [Diskussion]
22 23 24
Antworten
462
Aufrufe
128K
IBFS
IBFS
PN/DP
Sonstiges Probleme nach Windows 11 24H2 Update
2
Antworten
36
Aufrufe
6K
oliver.tonn
O
P
TIA SIMATIC IPC MD-57A alte TIA Versionen
Antworten
2
Aufrufe
869
DeltaMikeAir
DeltaMikeAir
D
TIA [SIOS] Produktabkündigung der Version V16
Antworten
0
Aufrufe
1K
DCDCDC
D
Zurück
Oben