TIA SCL mit Variablen auf einen DB mit verschachtelten Strukturen zugreifen

[Delwood]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo,

ich habe einen DB mit verschachtelten Strukturen. Ich möchte nun z.B. Im Namen "1" (Real) einen Wert übergeben. Die Namen für #Monat, #Tag und #Std werden in SCL ermittelt.
Beipielsweise: "DB_Monatswerte_1_6".#Monat.#Tag.#Std := #akt_kwh.

Der o.g. Code funktioniert leider nicht. #Monat , #Tag und #Std liegen als INT vor.

Wie muss ich den Zugriff angeben? Ich arbeite mit TIA V18. Als CPU wird eine S7-1200 verwendet.

 

[Larry Laffer]

so funktioniert es nicht - wenn du mit INT-Werten arbeiten willst dann wäre ein mehr dimensionales Array das Richtige für dich :

Array [1..12 , 1..31 , 0..23] of REAL

 

[Delwood]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo Larry,
vielen Dank für die schnelle Antwort. Wie wäre es wenn ich #Monat als String hätte? Und dann mit Jan,Febr,Mrz,April... beschriftet haben möchte?

 

[hucki]

Was hast Du gegen Larrys Vorschlag?

Auch mir erscheint dies als der richtige Weg, denn daraus entsteht die Angabe:

DB_Monatswerte_1_6[#Monat, #Tag, #Std]

 

[Larry Laffer]

Hallo Larry,
vielen Dank für die schnelle Antwort. Wie wäre es wenn ich #Monat als String hätte? Und dann mit Jan,Febr,Mrz,April... beschriftet haben möchte?

Du mußt generell zwischen Variablen-Inhalt und Variablen-Namen zu unterscheiden lernen. Das Eine kannst du nicht so ohne weiteres für das Andere verwenden ...
Du könntest dir aber für deine Monatsnamen Konstanten hinterlegen, die dann den entsprechenden Wert haben - das hilft dir hier aber, so denke ich, nicht wirklich ...

 

[Ludewig]

Zuviel Werbung?
-> Hier kostenlos registrieren

Kleine Anmerkung: Zumindest Anfänger sollten Arrays immer bei 0 beginnen lassen. Auch wenn der Bereich leer bleibt, erspart das hässliche Bereichslängenfehler.

 

[hucki]

Kleine Anmerkung: Zumindest Anfänger sollten Arrays immer bei 0 beginnen lassen. Auch wenn der Bereich leer bleibt, erspart das hässliche Bereichslängenfehler.

Wobei ich diese irgendwie immer eher mit der oberen als der unteren Arraygrenze habe.

 

[Larry Laffer]

Ich würde auch gerne mal wissen woher das kommt ... (ich weiß doch was ich angelegt / dimensioniert habe)

 

[hucki]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich würde auch gerne mal wissen woher das kommt ... (ich weiß doch was ich angelegt / dimensioniert habe)

Vielleicht, weil es TIA/Siemens immer noch nicht geraffelt bekommt und alle Arrays im HMI immer noch bei 0 beginnen lässt, egal wie sie in der PLC in Wirklichkeit deklariert sind?
Dann benötigt man dort andere Feldnummern und die kann man schon mal durcheinander bringen.



PS:
Wieso habe ich was im Zitat, was mir in Larrys Original nie angezeigt wurde (auch wenn's vlt. mal so da stand)?

PPS:
Ach, das kam erst nachträglich (zwischen Threadanzeige und Zitat) noch hinzu, oder?

 

[Larry Laffer]

Vielleicht, weil es TIA/Siemens immer noch nicht geraffelt bekommt und alle Arrays im HMI immer noch bei 0 beginnen lässt, egal wie sie in der PLC in Wirklichkeit deklariert sind?

Das wird sich sehr wahrscheinlich auch nicht ändern, da es u.A. direkt von Microsoft kommt. Ob nun VB-Script oder eine derv .Net-basierten Sprachen - alle arbeiten beim Dimensionieren mit "highest Index" und sind 0-basiert. Ein "Dim XYZ (100)" erzegut also ein Array mit 101 Elementen - eben 0 bis 100 ...
Das mag dann sicherlich der Grund sein warum beispielsweise @DCDCDC seine Arrays in der SPS auch gerne so dimensionieren möchte - ich denke aber mal, dass einmal die meißten SPS-Arrays auch in der SPS bleiben ... und dann sollte man sich auch immer darüber im Klaren sein was man da macht ...

 

[Salli1991]

ich denke aber mal, dass einmal die meißten SPS-Arrays auch in der SPS bleiben ... und dann sollte man sich auch immer darüber im Klaren sein was man da macht ...

Funktioniert in TIA V19 eigentlich mittlerweile UPPER_BOUND und LOWER_BOUND für alle Arrays?

 

[hucki]

Zuviel Werbung?
-> Hier kostenlos registrieren

Das wird sich sehr wahrscheinlich auch nicht ändern, da es u.A. direkt von Microsoft kommt. Ob nun VB-Script oder eine derv .Net-basierten Sprachen - alle arbeiten beim Dimensionieren mit "highest Index" und sind 0-basiert. Ein "Dim XYZ (100)" erzegut also ein Array mit 101 Elementen - eben 0 bis 100 ...

Bei den in den Scripten erzeugten Arrays sehe ich das ja noch ein, denn die haben ja max. indirekt mit der PLC zu tun.

Aber warum ist es bei den PLC-Variablen im HMI auch so anstatt die Deklarations-Vorgabe aus der PLC zu übernehmen?

Wenn das HMI das intern dann beim Kompilieren in ein 0-basiertes Array umwandelt, interessiert mich als Programmierer ja nicht.
Wird bei jedem Array in der PLC vermutlich auch bloß so gemacht. Ist ja auch nix weiter als ein feststehender Offset, den man während des Kompilieren bei jedem Schleifenaufruf u.ä. wieder einfließen läßt.

 

[PN/DP]

Funktioniert in TIA V19 eigentlich mittlerweile UPPER_BOUND und LOWER_BOUND für alle Arrays?

Für welche Arrays funktioniert das denn nicht?
Es geht nur bei Arrays in "optimiertem" Speicher - meinst du das?

 

[Salli1991]

Für welche Arrays funktioniert das denn nicht?
Es geht nur bei Arrays in "optimiertem" Speicher - meinst du das?

Leider nur für Arrays vom Typ [*]
Ich weiß, man sollte selber immer die Grenzen kontrollieren, aber so muss man immer das gesamte Programm kontrollieren.
Wenn ich z.B. eine UDT ändere und die in vielen verschiedenen FBs verwende wirds lustig. Würde UPPER_BOUND und LOWER_BOUND für statische Arrays funktionieren würde man sich so eine menge Fleißarbeit sparen.

Und zusätzlich dazu machen so schusselige Typen wie ich dadurch weniger Flüchtigkeitsfehler

 

[hucki]

Zuviel Werbung?
-> Hier kostenlos registrieren

Anhang anzeigen 74861


Leider nur für Arrays vom Typ [*]
Ich weiß, man sollte selber immer die Grenzen kontrollieren, aber so muss man immer das gesamte Programm kontrollieren.
Wenn ich z.B. eine UDT ändere und die in vielen verschiedenen FBs verwende wirds lustig. Würde UPPER_BOUND und LOWER_BOUND für statische Arrays funktionieren würde man sich so eine menge Fleißarbeit sparen.

Und zusätzlich dazu machen so schusselige Typen wie ich dadurch weniger Flüchtigkeitsfehler

Deswegen verwende ich für die ARRAY-Deklaration und dann für Schleifen u.ä. immer (meist globale) Konstanten.
So muss ich nur an einer Stelle ändern.

Nur für Bibliotheken (die ich bis dato für mein eines Programm, dass ich nur habe, nicht nutze) ist es doof, dass man die globalen Konstanten nicht an interne Konstanten übergeben kann. Und dass die globalen Konstanten auch im HMI unbekannt sind.

 

[Larry Laffer]

Bei den in den Scripten erzeugten Arrays sehe ich das ja noch ein, denn die haben ja max. indirekt mit der PLC zu tun.

Aber warum ist es bei den PLC-Variablen im HMI auch so anstatt die Deklarations-Vorgabe aus der PLC zu übernehmen?

Wenn das HMI das intern dann beim Kompilieren in ein 0-basiertes Array umwandelt, interessiert mich als Programmierer ja nicht.

Wie schon geschrieben - an der Stelle hat Siemens dann mal nichts Neues erfunden sondern die Standard-Microsoft-Objekte so übernommen wie sie sind. Das wäre aber nichts ungewöhnliches ...

 

[hucki]

Spielt doch überhaupt keine Rolle.

TIA muss das PLC-Array so oder so irgendwann einmal von nicht-nullbasiert in der PLC zu nullbasiert im HMI umrechnen/wandeln.
Warum kann dieses Wandeln nicht erst beim Kompilieren/Übersetzen geschehen, wenn es den TIA-Programmierer nicht mehr interessiert?

 

[Larry Laffer]

Zuviel Werbung?
-> Hier kostenlos registrieren

Nein ... da vertust du dich - TIA (oder Flexibel früher oder auch ProTool noch früher) greifen einfach nur den Einstiegspunkt des Objektes auf und ordnen den dann dem internen Array zu - dabei ist es egal ob das Visu-Array von 1 bis 100 oder von 1000 bis 1050 ofer was auch immer geht ...

 

[hucki]

Nein ... da vertust du dich - TIA (oder Flexibel früher oder auch ProTool noch früher) greifen einfach nur den Einstiegspunkt des Objektes auf und ordnen den dann dem internen Array zu - dabei ist es egal ob das Visu-Array von 1 bis 100 oder von 1000 bis 1050 ofer was auch immer geht ...

Aber auch das kann doch alles erst beim Kompilieren geschehen. Ändert doch für die Ausführung auf dem HMI nix.

 

[DCDCDC]

Anhang anzeigen 74861


Leider nur für Arrays vom Typ [*]
Ich weiß, man sollte selber immer die Grenzen kontrollieren, aber so muss man immer das gesamte Programm kontrollieren.
Wenn ich z.B. eine UDT ändere und die in vielen verschiedenen FBs verwende wirds lustig. Würde UPPER_BOUND und LOWER_BOUND für statische Arrays funktionieren würde man sich so eine menge Fleißarbeit sparen.

Und zusätzlich dazu machen so schusselige Typen wie ich dadurch weniger Flüchtigkeitsfehler

Für feste Arrays kann man dafür Konstanten verwenden.