WinCC Unified Verwendung Array beginnend mit 1 möglich?

[schwimmer]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo Unified-Experten,
habe gerade verzweifelt einen Fehler gesucht, bis ich gemerkt habe, dass WinCC mir anscheinend die Array's umschreibt.
Deklariert habe ich im DB ein Array [1..10] of String und wenn ich das nach WinCC ziehe, dann wird daraus ein Array [0..9].
Mache ich da etwas verkehrt oder kann WinCC Array nur ab 0?
TIA V19 Upd3 / MTP1900

 

[faust]

Bin mir zwar gerade nicht sicher, da ich aus Handlingsgründen meistens Array-Elemente einzeln anbinde, aber ...

Bei Variablen "Array of Word" für das Bitmeldeverfahren z.B. macht Siemens das schon immer so.


Gruß, Fred

 

[ducati]

Zuviel Werbung?
-> Hier kostenlos registrieren

ja, das ist schon immer so, deshalb in der SPS immer Arrays bei 0 beginnen lassen und gegebenenfalls das Nullte Element nicht verwenden...

Warum die das jetzt bei Unified nicht mal endlich geändert haben, kann ich dir auch nicht sagen...

 

[maxder2te]

Das ist verständlich da außer Pascal eigentlich kaum eine Sprache das definieren von Array-Grenzen zulässt sondern bei 0 beginnt.
Da Unified auf JavaScript basiert und die Vorgänger auf VB, ist das im HMI quasi schon immer so.

 

[Heinileini]

Das ist verständlich da außer Pascal eigentlich kaum eine Sprache das definieren von Array-Grenzen zulässt sondern bei 0 beginnt.
Da Unified auf JavaScript basiert und die Vorgänger auf VB, ist das im HMI quasi schon immer so.

SCL treibt es auf die Spitze:

Der Index kann ein beliebiger ganzzahliger Wert (-32768 bis 32767) sein.

Sehr ungewöhnlich finde ich bei SCL, dass negative Indizes zulässig sind bzw. sein sollen.
Hat schon mal jemand davon Gebrauch gemacht oder gar eine "sinnvolle" Anwendung dafür gefunden?
Ich sehe darin (ganz "unaufgeregt") lediglich eine Verdoppelung der maximalen Anzahl FeldElemente von 32K auf 64K unter Beibehaltung des DatenTyps INT für den Index.

Ist es wirklich so ungewöhnlich, dass in einer ProgrammierSprache die untere ArrayGrenze definiert werden kann?
Im Laufe der Jahre habe ich in diversen Sprachen bzw. "Dialekten" von Sprachen programmiert.
Habe mich immer irgendwie mit den Gegebenheiten abgefunden und gelegentlich geflucht, wenn nicht die 0 als kleinster Index zulässig war.
Aber aus dem Gedächtnis könnte ich nicht sagen, wie es genau bei welcher Sprache geregelt war/ist.

 

[maxder2te]

Zuviel Werbung?
-> Hier kostenlos registrieren

Naja. SCL basiert ebenso wie STL auf Pascal.

Ich hatte mal eine Lookup-Table-Mechanismus wo es in S7 effizienter war mit dem Index -2 zu beginnen. Nachdem ich den Code aber dann auf Rockwell portieren musste welches 0-basiert arbeitet war das wieder hinfällig.

Unterm Strich hat sich 0-basiert bewährt und ist am weitesten verbreitet, weshalb ich heute nur noch so arbeite.

Der Vorteil von INT als Index gegenüber DINT ist heutzutage auch eher theoretischer Natur.

 

[Watchcat]

"In vielen Prozessorarchitekturen werden Arrays als zusammenhängende Speicherbereiche behandelt, und der Zugriff auf ein Element erfolgt durch eine Berechnung wie: Adresse=Basisadresse+Index×Größe des Elements. Wenn Arrays bei 0 beginnen, entfällt die Notwendigkeit, zusätzliche Berechnungen für eine Verschiebung (Offset) vorzunehmen. Das spart Rechenzeit."

Ich würde auch aus Standartisierungsgründen ein Array immer bei 0 anfangen lassen. Der nächste Programmierer der an der Software arbeitet wird nicht begeistert sein, wenn er einen Startindex ungleich 0 übersieht .

Wenn nötig halt einfach Index 0 definieren aber nicht nutzen.

 

[Ludewig]

Es erspart in jedem Fall Bereichslängenfehler bei fehlender Indexinitialisierung.

 

[Heinileini]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich würde auch aus Standartisierungsgründen ein Array immer bei 0 anfangen lassen. Der nächste Programmierer der an der Software arbeitet wird nicht begeistert sein, wenn er einen Startindex ungleich 0 übersieht .

Gelegentlich gibt es Fälle, dass der Index eine "Bedeutung" hat jenseits einer simplen, bei 1 beginnenden Zählung. Ich nenne jetzt mal willkürlich als Beispiele Kunden- oder Artikel-Nrn, die nicht bei 1, sondern z.B. bei 10.000 beginnen.
Da hätte ich keine Hemmungen, den unteren Index mit 10.000 und den oberen z.B. mit 99.999 festzulegen (sofern die Obergrenze nicht z.B. bei nur 32.767 liegt). Eher hätte ich Hemmungen, den nicht vernachlässigbar kleinen Bereich 0...9.999 ungenutzt zu verschwenden.

Wenn nötig halt einfach Index 0 definieren aber nicht nutzen.

Nicht nutzen oder ... habe schon die Zeile 0 einer Tabelle als "SummenZeile" missbraucht.

Es erspart in jedem Fall Bereichslängenfehler bei fehlender Indexinitialisierung.

Ich finde es immer "verdächtig", wenn FehlerBehandlungen (elegant) unter den Teppich gekehrt werden.

 

[hucki]

"In vielen Prozessorarchitekturen werden Arrays als zusammenhängende Speicherbereiche behandelt, und der Zugriff auf ein Element erfolgt durch eine Berechnung wie: Adresse=Basisadresse+Index×Größe des Elements. Wenn Arrays bei 0 beginnen, entfällt die Notwendigkeit, zusätzliche Berechnungen für eine Verschiebung (Offset) vorzunehmen. Das spart Rechenzeit."

Das spart genau einmal Rechenzeit und zwar beim Übersetzen.
Wenn der Programmierer z.B. ein Array von -2 bis 3 deklariert, damit es seinen Realitäten entspricht, kann doch der Übersetzer intern gerne ein Array von 0 bis 5 daraus machen.
WinCC schafft doch das bei den Array der CPU auch. Es sollte aber IMHO nicht sichtbar sondern im Hintergrund passieren.

Wenn nötig halt einfach Index 0 definieren aber nicht nutzen.

Sehe ich so völlig anders.

Ich versuche mit den Arrays meine Realität abzubilden.
Und wenn das z.B. meine Pumpen 11 bis 15 sind, dann möchte ich auch mein Arrray von 11 bis 15 deklarieren und nicht von 0 bis 4. Das ist IMHO heutzutage Aufgabe des Übersetzers.
Und schon gar nicht möchte ich ein Array von 0 bis 15, denn auch heute ist zumindest bei kleinen CPUen Speicherplatz immer noch Geld.

 

[ducati]

Ich versuche mit den Arrays meine Realität abzubilden.
Und wenn das z.B. meine Pumpen 11 bis 15 sind, dann möchte ich auch mein Arrray von 11 bis 15 deklarieren und nicht von 0 bis 4. Das ist IMHO heutzutage Aufgabe des Übersetzers.
Und schon gar nicht möchte ich ein Array von 0 bis 15, denn auch heute ist zumindest bei kleinen CPUen Speicherplatz immer noch Geld.

Das sehen hier sicherlich alle genauso wie Du. Aktuell ist aber die einzige Möglichkeit, die Indizees zw. SPS und HMI identisch zu halten, in SPS und HMI mit 0...15 zu deklarieren und in beiden Welten 0 bis 10 ungenutzt zu lassen...
Vielleicht kommt ja auch bei der Inbetriebnahme oder in 3 Jahren noch ne Pumpe 3 und ne Pumpe 7 dazu...

 

[Watchcat]

Zuviel Werbung?
-> Hier kostenlos registrieren

Das spart genau einmal Rechenzeit und zwar beim Übersetzen.

Hmm da wäre ich mir nicht so sicher. Bin jetzt aber auch kein Compiler Experte. Selbst wenn die Speicheradresse zur Laufzeit berechnet wird, ist das kompett vernachlässigbar und auch garnicht meine Intention gewesen, dies hier als Vorteil für einen Startindex bei 0 aufzuführen. Ich wollte vielmehr damit verdeutlichen, warum der Startindex bei 0 wohl der allgemeine "Standart" ist.

Und weil dieser Standart eben so verbreitet ist, versuche ich diesen wenn möglich immer umzusetzen.

Aktuell ist die einzige Möglichkeit, die Indizees zw. SPS und HMI identisch zu halten aber, in SPS und HMI mit 0...15 zu deklarieren und in beiden Welten 0 bis 10 ungenutzt zu lassen...

Ich träume manchmal von assoziativen Arrays in der SPS. Also praktisch nicht fortlaufende Schlüssel (Indizes).

 

[schwimmer]

Aktuell ist aber die einzige Möglichkeit, die Indizees zw. SPS und HMI identisch zu halten, in SPS und HMI mit 0...15 zu deklarieren und in beiden Welten 0 bis 10 ungenutzt zu lassen...

Eine andere Möglichkeit wäre ja noch das Array nicht als Ganzes sondern jede Variable einzeln in die Visu zu ziehen, dann bleibt die Definition wie sie in der SPS angelegt wurde.

 

[Watchcat]

Und wenn das z.B. meine Pumpen 11 bis 15 sind, dann möchte ich auch mein Arrray von 11 bis 15 deklarieren und nicht von 0 bis 4. Das ist IMHO heutzutage Aufgabe des Übersetzers.

Gerade im WinCC ist das dann natürlich extra verwirrend, wenn du da z.B. auf die Variable Pumpen[1].Sollwert zugreifst und das eigentlich die Pumpe 12 ist.

In der SPS und WinCC habe ich schon eine Funktion genutzt wie GetArrayIndexRecipe(Number: 1234) wo ich dann z.B. auf aRecipe.Number = Number vergleiche und den Index zurückgebe. Da ich Index 0 nicht verwende, heißt das wenn ich eine 0 zurückbekomme, gibts das Rezept nicht.

Ist im WinCC jetzt nicht all zu performat mit großen Arrays. Also für Pumpen die überall als Anwenderobjekte im Bild dauerhaft aktuallsiert werden müssen, ist das wahrscheinlich nicht zu empfehlen.

 

[Watchcat]

Zuviel Werbung?
-> Hier kostenlos registrieren

Eine andere Möglichkeit wäre ja noch das Array nicht als Ganzes sondern jede Variable einzeln in die Visu zu ziehen, dann bleibt die Definition wie sie in der SPS angelegt wurde.

Ja so bleibt der Index tatsächlich gleich.

 

[Oberchefe]

Hat schon mal jemand davon Gebrauch gemacht oder gar eine "sinnvolle" Anwendung dafür gefunden?

z.B. eine AT-Sicht eines SINT-Arrays auf einen S7-String kannst du im negativem starten und bekommst dann mit [x] den x-ten Buchstaben des Strings

 

[faust]

Ja so bleibt der Index tatsächlich gleich.
Anhang anzeigen 83091

Mache ich mit Ausnahme der Meldungswort-Arrays nur so (siehe #2), weil nur dann eine uneingeschränkte Verwendung von Array-Elementen in Scripten möglich ist.

 

[ducati]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ja so bleibt der Index tatsächlich gleich.
Anhang anzeigen 83091

Die erste Variable "TEST_Array{1}" ist aber kein Arrayelement und kann nicht über den Index 1 angesprochen werden, oder doch?
Gerade bei bool ist es halt so nen Ding, die Variablen zählen dann einzeln als Powertag und u.U. holt der Kommunikationstreiber die auch einzeln...
In meiner alten Fa. hatten wir auch das Problem, dass 1000 bools einzeln im HMI angelegt waren, weil im Programmierstandard in der SPS das entsprechende Array bei 1 losging...

Wenn eine Variable kein Array ist, würd ich auch keine eckigen oder geschweiften Klammern in den Variablennamen einbauen
Also nenn die Einzelvariablen doch lieber so: "TEST_BOOL_0001"

 

[Botimperator]

Hat schon mal jemand davon Gebrauch gemacht oder gar eine "sinnvolle" Anwendung dafür gefunden?

Ich benutze das um prozesstechnische Konstantwerte für Berechnungen zu speichern.
Physikalische Prozesse treiben sich halt leider auch mal im negativen Wertebereich von Einheiten rum.

Gegenüberstellung Temperatur & Thermoelement-Spannung wäre Beispielsweise sowas. Die Berechnung des Seebeck-Effekts ist recht aufwändig, ist im Bezug auf einen einzelnen Temperaturwert und Thermoelement Typ aber eine Konstante.
Das benutze ich Beispielsweise um beim Start zu prüfen ob die TC-Eingangskarte korrekt parametriert wurde.
Hatte schon Deppen, die eine Anwendung mit Typ S Thermoelement mit den Startwerten (Typ K) in Betrieb genommen haben & sich dann wunderten wieso sich die Anlage selbst eingeschmolzen hat.

Bei Failsafe Anwendungen geht das leider nicht, da muss ich dann (Beispiel Thermoelemente) immer im Kopf umrechnen "Array-Index 300 = 0°C".
Da finde ich die Möglichkeit für negative Indizes schon angenehmer.

Eine andere Möglichkeit wäre ja noch das Array nicht als Ganzes sondern jede Variable einzeln in die Visu zu ziehen, dann bleibt die Definition wie sie in der SPS angelegt wurde.

Das Array nochmal in einen UDT zu packen & diesen dann ins hmi zu ziehen funktioniert auch.
Zumindest bei Comfort-Panels.
Da meine Kollegen noch nicht geheult haben, dass das bei Unified nicht geht, solle das da auch klappen.

 

[schwimmer]

Die erste Variable "TEST_Array{1}" ist aber kein Arrayelement und kann nicht über den Index 1 angesprochen werden, oder doch?

Auch wenn ich den Screenshot nicht eingestellt habe, bei mir sieht es genauso aus, wenn eine Variable aus einem Array einzeln ins HMI gezogen wird. Dann bleibt der Index1 erhalten und wird in die geschweiften Klammern gesetzt.