Genau das möchte ich ja nicht. Dadurch vermeide ich Flüchtigkeitsfehler, weil ich es nur an einer Stelle ändern muss. Nichts desto trotz muss ich es immer noch händisch ändern. Wenn ich das auch nur einmal vergesse, warum auch immer, und die CPU dadurch in den Stop geht im laufenden Betrieb....dann gibts Mord und Totschlag. Mir ist auch klar, dass es dafür auch Organisationsbausteine gibt, die eben die CPU nicht in Stop gehen lassen. Ich ziehe es aber vor mir einen Programmierstil anzueignen, bei dem möglichst elegant, kompakt und nachvollziehbar solche Fehler von vornherein automatisch umgangen werden. Und da es diese Funktion für Arrays schon gibt, würde ich sie gerne auch für alle Arrays nutzen können. Wie gesagt, es ist ein Wunsch und kein aktuelles Problem was ich habe^^ Ich könnte mir ja theoretisch auch als Parameter im DB die Array Größe liefern lassen. Aber das sind alles nur Workarounds um eine eigentlich simple Lösung.
wenn ich mir so anschaue, was heute überall so abgeht, wundert mich das nicht. Und aufregen bringt überhaupt nix, man kann sich natürlich abundzu den Frust von der Seele schreien, aber ändern tut das nix...
Na klar machen wir alle Fehler, Michael. Dass ich selbst das auch sehr gut beherrsche, habe ich in diesem Forum ja schon häufig bewiesen!
Tja, wenn mal jemand hier schreibt "Ich habe das Programm 1:1 von Siemens übernommen", da bedeutet also nicht unbedingt, das es passt bzw. funktioniert. Sind ja auch nur Menschen.
Wahrscheinlich ist das einer der Punkte, die beim Erstellen der Dokumentation abgehakt werden müssen.Du hast Recht, ducati. Sich aufzuregen bringt nix und für die Erledigung der Aufgabe ist es eher hinderlich als hilfreich.
Dito
Nee, nur die Anzahl der Straßen nach Rom wächst halt
Wo sollen denn die Informationen zu den Array-Grenzen eines "herkömmlichen" Arrays "simpel" in der SPS hinterlegt werden? Die müssten ja in einem zusätzlichen Speicherbereich als "Meta"-Daten gespeichert werden oder bei jedem Zugriff als unsichtbarer zusätzlicher Parameter mitgegeben werden.
Im Zeitalter der Navis kein Problem.
Ja, aber das wäre doch ein Kompromiss?!
Im SCL für 300/400er gibts das doch? Oder hab ich da jahrelang was falsches drunter vermutet?Ja, aber das wäre doch ein Kompromiss?!
Neben den anderen Haken (remanent, aus HMI lesbar, von HMI beschriebbar, Einrichtwert,...) könnte man für Arrays ja noch anfügen "Grenzen lesbar" und "Grenzenprüfung aktiv"
Ja, das ist sicherlich ein Problem, wenn man sich darüber zur Einführung der Arrays noch keine Gedanken gemacht hat.Joa. Warum nicht, Harald? Zumindest bei SchreibZugriffen auf Arrays wäre das doch schon sehr hilfreich, um unbeabsichtigte DatenSabotage zu verhindern. Ressourcen- und Perfomance-fressend ist das natürlich. Aber wir reden ja hier über SPS-Programme und die sollten ja vorrangig "sicher" funktionieren.
FOR ix := UpperBound(aktuellesArray, 1) TO LowerBound(aktuellesArray, 1) BY -1 DO
aktuellesArray[ix + 1] := aktuellesArray[ix] ;
END_FOR ;
Aber man muss sie nur oft genug gemacht haben, dann achtet man schon automatisch darauf.
In der Formulierung "Wenn ein Feldindex den zulässigen Bereich überschreitet, wird das OK-Flag auf FALSE gesetzt." fehlt mir wieder die wichtigste Information: wird bei einem SchreibZugriff ins Nirvana denn auf das Schreiben auch zuverlässig vezichtet?
naja, wie gesagt, für S7-300 könnte man ja im resultierenden AWL-Code nachschauen, was genau gemacht wird.
// SCL Code
FUNCTION FC100 : INT
VAR_TEMP
test : ARRAY[1..10] OF REAL;
i : INT;
END_VAR
i := 2;
test[i]:= 123.456 ;
FC100 := 100;
END_FUNCTION// AWL Code ohne Arraygrenzenprüfung
SET
SAVE
SET
= L 42.1
L 2
T #i
L #i
ITD
T LD 44
L LD 44
L L#1
-D
T LD 44
L LD 44
L L#32
*D
T LD 44
L 1.234560e+002
LAR1 LD 44
T LD [AR1,P#0.0]
L 100
T #RET_VAL
U L 42.1
SAVE
BE// AWL Code mit Arraygrenzenprüfung
SET
SAVE
SET
= L 42.1
L 2
T #i
L #i
ITD
T LD 44
L LD 44
L L#1
>=D
= L 42.2
U L 42.2
U L 42.1
= L 42.1
L LD 44
L L#10
<=D
= L 42.2
U L 42.2
U L 42.1
= L 42.1
L LD 44
L L#1
-D
T LD 44
L LD 44
L L#32
*D
T LD 44
L 1.234560e+002
LAR1 LD 44
T LD [AR1,P#0.0]
L 100
T #RET_VAL
U L 42.1
SAVE
BE// AWL Code mit Arraygrenzenprüfung und optimiertem Code
SET
SAVE
= L 42.1
L 2
T #i
ITD
L L#1
>=D
U L 42.1
= L 42.1
TAK
L L#10
<=D
U L 42.1
= L 42.1
TAK
L L#1
-D
L L#32
*D
L 1.234560e+002
TAK
LAR1
TAK
T LD [AR1,P#0.0]
L 100
T #RET_VAL
SAVE
BE// AWL Code mit optimiertem Code, Arraygrenzenüberwachung und OK Flag setzen
SET
SAVE
= L 42.1
L 2
T #i
ITD
L L#1
>=D
U L 42.1
= L 42.1
TAK
L L#10
<=D
U L 42.1
= L 42.1
TAK
L L#1
-D
SPO I007
SPA I008
I007: CLR
= L 42.1
I008: L L#32
*D
SPO I009
SPA I00a
I009: CLR
= L 42.1
I00a: L 1.234560e+002
TAK
LAR1
TAK
T LD [AR1,P#0.0]
L 100
T #RET_VAL
CLR
U L 42.1
SAVE
BE
Das kann ja wie in C/C++ funktionieren. Der Aufruf von "LOWER_/UPPER_BOUND" wird, bei bekannten Arrays, beim Übersetzen durch die Konstante der Array-Größe ersetzt. Der Compiler weis ja wie lang das Array ist.
