Maximale Elementeanzahl bei Feldern

Hallo Stefan,

leider nein. Eine Variable kann nur 32 kB gross sein.
Eine POS hat 32 Bytes (6 real,2 int) und ein paar Verwaltungsbits - darum die krumme 906.
max. DECL POS OTTO[3,2,151]

Hi,

Wie LindePaul schon geschrieben hat, geht nicht mehr. Du kannst deine Felder aber organisieren, wie du willst.
DECL POS OTTO[n1,n2,n3]
mit der einzigen Einschränkung, dass gelten muss: n1*n2*n3 <= 906

Die Feldbreite 3 in 1. Dim. ist also gar kein Problem.

Gruß ... gooselk

Hallo Stefan,

Zitat von StefanW

Felder vom Datentyp POS können ja nur 906 Elemente enthalten, also:

Code

DECL POS Test1Pos[906]         ; Maximum = 906 Elemente (gesamt)
DECL POS Test2Pos[2,453]       ; Maximum = 906 Elemente (gesamt)
DECL POS Test3Pos[2,2,226]     ; Maximum = 906 Elemente (gesamt)

Kann diese maximale Anzahl erhöht werden?
Problem ist, dass wir in der 1. Dimension statt 2 -> 3 haben sollten.

Da hilft dann wohl nur zerlegen, vielleicht so:

.dat-Datei:

DECL POS Pos1[2,350]
DECL POS Pos2[2,350]
DECL POS Pos3[2,350]

.src-Datei:

DEFFCT POS GetPos(I1:IN, I2:IN, I3:IN)
  DECL INT I1,I2,I3
  SWITCH I1
  CASE 1
     RETURN POS1[I2,I3]
  CASE 2
     RETURN POS2[I2,I3]
  CASE 3
     RETURN POS3[I2,I3]
  DEFAULT
     HALT
  ENDSWITCH
ENDFCT ; GetPos


DEF SetPos(POSi:OUT, I1:IN, I2:IN, I3:IN)
  DECL POS POSi
  INT I1,I2,I3
  SWITCH I1
  CASE 1
     POS1[I2,I3] = POSi
  CASE 2
     POS2[I2,I3] = POSi
  CASE 3
     POS3[I2,I3] = POSi
  DEFAULT
     HALT
  ENDSWITCH
ENDFCT ; SetPos

Aber, das hast Du Dir wahrscheinlich schon selbst so ueberlegt.

Gruss, Dirk.

Zitat von scheff

.src-Datei:

Code

[...]
DEF SetPos(POSi:OUT, I1:IN, I2:IN, I3:IN)
  DECL POS POSi
  INT I1,I2,I3
[...]
ENDFCT ; SetPos

Aber, das hast Du Dir wahrscheinlich schon selbst so ueberlegt.

Hallo,
nur damit es bei der Realisierung nicht zu Schwierigkeiten kommt, würde ich ein paar Korrekturen anregen wollen
1. Wenn eine Funktion mit ENDFCT abgeschlossen wird, sollte sie auch als solche definiert sein. Da hat sich Dirk aber sicher nur vertippt.
2. Wenn die Variable POSi in der Funktion deklariert wird, ist sie nur dort gültig. Wenn die Funktion beendet ist, verliert sie ihre Gültigkeit und kann nicht weiter verarbeitet werden. Zudem bin ich mir nicht sicher, ob das Programm so überhaupt kompiliert werden kann, da beim Aufruf der Funktion die mit Call by Reference referenzierte Variable noch nicht bekannt ist. Ich würde sie deshalb ebenfalls in der .dat deklarieren.

Korrigiert mich bitte, wenn ich falsch liege.

Gruß ... gooselk

Hallo,

Zitat von gooselk

1. Wenn eine Funktion mit ENDFCT abgeschlossen wird, sollte sie auch als solche definiert sein. Da hat sich Dirk aber sicher nur vertippt.

In der Tat - Tippfehler. Es muss natuerlich END heissen.

Zitat von gooselk

2. Wenn die Variable POSi in der Funktion deklariert wird, ist sie nur dort gültig. Wenn die Funktion beendet ist, verliert sie ihre Gültigkeit und kann nicht weiter verarbeitet werden. Zudem bin ich mir nicht sicher, ob das Programm so überhaupt kompiliert werden kann, da beim Aufruf der Funktion die mit Call by Reference referenzierte Variable noch nicht bekannt ist. Ich würde sie deshalb ebenfalls in der .dat deklarieren.

Da haben wir uns evtl. missverstanden.
POSi ist der formale Parameter in SetPos, der Call-By-Reference uebergeben werden soll.

Also z.B. so:

DECL POS aPos;
...
aPos = {POS:X 1.1,Y 1.2,Z 1.3, A 0.0,B 45.0,C 90.0}
SetPos(aPos, 1, 1, 17)

oder alternativ so:

SetPos({POS:X 1.1,Y 1.2,Z 1.3, A 0.0,B 45.0,C 90.0}, 1, 1, 17)

Der koennte eigentlich auch als :IN vereinbart werden, aber als "alter" C/C++-Programmierer weiss ich natuerlich, dass man Speicher und Zeit sparen kann, wenn man groessere Datenstrukturen (die in der Funktion/Prozedur nicht geaendert werden) als :OUT (also call-by-reference, sprich: per Speicher-Adresse) uebergibt.

Das DECL mag an der Stelle falsch sein. Das liegt daran, dass ich bis heute leider nicht verstanden habe, wann man es genau verwenden muss.
Das Handbuch ist leider auch ueberhaupt nicht hilfreich dabei. In meinen Beispielquellen habe ich es teils so und teils so gefunden.
Daher habe ich fuer mich beschlossen, dass DECL ein Relikt ist, dass man verwenden kann aber nicht muss.
Fuer Er-/Aufklaerung bin ich natuerlich (wie immer) sehr dankbar.

Da ihr (wie ich inzwischen feststellen konnte) groesstenteils ausgemachte Pragmatiker seid, und die Datenlisten aus irgendwelchen CAD-Tools bezieht, koennte man diese SetPos-Prozedur u.U. auch einfach ersatzlos streichen.
GetPos() sollte man uebrigens direkt ueberall dort verwenden koennen, wo urspruenglich die Variable stehen sollte.

z.B. so:

PTP GetPos(1, 2, 27)

oder so:

FOR I1 = 1 TO 3
  FOR I2 = 1 TO 2
    FOR I3 = 1 TO 350
      PTP GetPos(I1,I2,I3)
    ENDFOR ; I3
  ENDFOR ; I2
ENDFOR ; I1

Gruss, Dirk.

Hallo Dirk,

Zitat

Da haben wir uns evtl. missverstanden.
POSi ist der formale Parameter in SetPos, der Call-By-Reference uebergeben werden soll.

Ermmm... ne, haben wir nicht. Ich hatte einfach nur Quark geschrieben. Ich nehme alles zurück und behaupte das Gegenteil

Zitat

Daher habe ich fuer mich beschlossen, dass DECL ein Relikt ist, dass man verwenden kann aber nicht muss.
Fuer Er-/Aufklaerung bin ich natuerlich (wie immer) sehr dankbar.

DECL darf immer dann weggelassen werden, wenn es sich um einen Standarddatentyp handelt, also INT, REAL, BOOL usf. Es muss aber verwendet werden, wenn du z.B. einen eigenen Strukturdatentyp o.ä. deklarieren willst.

Gruß ... Lars

Hallo Allerseits,

diese Post ist a bereits etwas alt, ich kann aber eure Berechnungen nicht ganz verstehen.

für den Index von 906 finde ich keine vernünftige Lösung.

E6POS: X, Y, Z, A, B, C (= 7*4 = 28 Byte) + S (= 2*4 = 8 Byte) + T (= 2*4 = 8 Byte) + E1, E2, E3, E4, E5, E6 (= 7*4 = 28 Byte) => 455 (Index)
E3POS: X, Y, Z, A, B, C (= 7*4 = 28 Byte) + S (= 2*4 = 8 Byte) + T (= 2*4 = 8 Byte) + E1, E2, E3 (= 4*4 Byte = 16 Byte) => 546 (Index)
POS : X, Y, Z, A, B, C (= 7*4 = 28 Byte) + S (= 2*4 = 8 Byte) + T (= 2*4 = 8 Byte) => 744 (Index)
FRAME: X, Y, Z, A, B, C (= 7*4 = 28 Byte) => 1170 (Index)

Vielleicht könnt hier etwas weiterrechnen (32767 / 906 = 36 => 36 /4 => 9 (?) was

mfg

MOM

Hallo Allerseits,

ich habe die ganze Geschichte noch einmal nachgerechnet und geprüft und muss daher korrigieren:

E6POS: 544 Elemente (ca. 32767 / 60)
E3POS: 680 Elemente (ca. 32767 / 48)
POS : 906 Elemente (ca. 32767 / 36)
FRAME: 1164 Elemente (ca. 32767 / 28)

Ich bitte daher um Nachsicht

mfg

MOM

Zitat von scheff

Das DECL mag an der Stelle falsch sein. Das liegt daran, dass ich bis heute leider nicht verstanden habe, wann man es genau verwenden muss.
Das Handbuch ist leider auch ueberhaupt nicht hilfreich dabei. In meinen Beispielquellen habe ich es teils so und teils so gefunden.
Daher habe ich fuer mich beschlossen, dass DECL ein Relikt ist, dass man verwenden kann aber nicht muss.
Fuer Er-/Aufklaerung bin ich natuerlich (wie immer) sehr dankbar.

Nur bei Strukturen brauchst Du DECL

LindePaul

Bezüglich deines Posts:

Zitat von LindePaul

Hallo Stefan,

leider nein. Eine Variable kann nur 32 kB gross sein.
Eine POS hat 32 Bytes (6 real,2 int) und ein paar Verwaltungsbits - darum die krumme 906.
max. DECL POS OTTO[3,2,151]

Ich habe das mal kurz nachgerechnet. Die 906 POS-Elemente brauchen 28'992kBytes. Nun ist die Frage:
1. Ist die maximale Variablen Grösse 32'000kB oder 32'768kB?
2. Wenn ich mal die kleinere Zahl annehme bleiben 3008Bytes übrig, sprich rund 3,3 Byte (resp. 4.1 Byte) pro POS-Element. Das sieht auf den ersten Blick nach viel aus. Wie wird so ein Array aufgebaut? (um Variablengrössen im voraus zu berrechnen) Ich stelle mir das in etwa so vor:
Arraygrösse (32Bit)
Pointerstack (32Bit * Anzahl Elemente)
Elementenstack (Elementgrösse*Anzahl Elemente; z.B. POS 256Bit * Anzahl Elemente)

3. Was in dem Zusammenhang auch noch interessant zu wissen wäre, ist wie gross eine ENUM Variable im Speicher ist. (Ist es abhänging von der Bezeichnungsgrösse und Anzahl der Enumerationen oder wird es Systemintern als eine Integer/Byte gehandelt?)

was meinst du(ihr) dazu?

Hallo MOM!

Mich wuerde mal interessieren wie du auf 28 Bytes bei einem Frame kommst?
In der Rechnung, die du noch einmal korrigiert hast, sagst du was von 7x4 Bytes = 28 Bytes. Aber warum 7x4 Bytes und nicht 6x4 Bytes? Angesicht, dass doch ein FRAME aus 6 REALs besteht.

Hmm... ich wuerde jetzt einfach mal vermuten, dass der Rahmen jeder Struktur nochmal 4 Bytes in anspruch nimmt.
Aber warum dann in einer E6POS 4x 4 Bytes overhead?

Und stimmt es, dass ein REAL sowie ein INT je 4 Bytes groß sind?

Demnach waere nach meiner Logik eine E6POS = 60 Bytes groß:
X, Y, Z, A, B, C (6x REAL) = 6x4 Bytes
E1, E2, E3, E4, E5, E6 (6x REAL) = 6x4 Bytes
S, T (2x INT) = 2x4 Bytes
E6POS-Gerüst = 4 Bytes

Wenn ich falsch liege, bitte belehrt mich eines Besseren!
Vielen Dank schon mal!

Gruß Harry

Also der Overhead ist immer so ~4Byte, damit ist ein:

Frame = 6x4 + 1x4 = 28Byte
Pos = 6x4 + 2x4 + 1x4 = 36Byte
E3Pos = 6x4 + 2x4 + 3x4 + 1x4 = 48Byte
E6Pos = 6x4 + 2x4 + 6x4 + 1x4 = 60byte

Und ja, REAL und INT sind je 4 Bytes gross..

Oh, super! Dann weiß ich das!

Wie ist es denn mit selbst definierten Structuren?

Beispiel:

STRUC BEISPIEL INT int1, REAL real1, E6POS pos1, pos2

INT = 4 byte
REAL = 4 byte
2xE6POS = 2x60 = 120 byte
OVERHEAD = 4 byte ???
---------------------------------
Total = 132 bytes ???

Wenn ich aber diese Struktur in einem Array benutze, kann ich maximal 247 elemente benutzen.
132 bytes x 247 = 32604 bytes

Kann das sein?
Habe weiter oben gelesen, dass eine Variable maximal 32768 bytes groß sein darf und davon nur 27936 bytes fuer Daten verwendet werden duerfen.
Was ist nun falsch?
Meine Rechnung fuer mein STRUC oder das nur 27937 bytes von den 32 kb benutzt werden duerfen?

Grueße vom Harry

Ich muss mich jetzt doch korrigieren, das sind nicht immer 4Byte Overhead, der Overhead wächst mit dem was in dem Array/Struct drin ist und benötigt so 1-2Bits pro Element, ist allerdings immer mimimum 4Byte. Der Overhead wird auch immer pro Schachtelung benötigt, also da ist Overhead für das E6Pos, Overhead für dein Struct und Overhead für dein Array von Structs.

Dein Beispiel Struct wäre also:
int = 4byte
real = 4byte
2xE6Pos = 120byte
overhead = 4 byte
--------------------------------
Total 132Byte

Wenn man das nun in ein maximal großes Array steckt, so hat man:
132byte x 247 + (1-2Bit*247 gerundet auf 4Byte = ~30-60byte overhead) = ~32664Byte

Das ist kleiner als 32768Byte und es passt aber kein struct mehr rein. Also sollte die Rechnung ungefähr stimmen

Eine Variable darf max 32k groß sein, allerdings inclusive allem Overhead.

Um also keinen Speicher zu verschwenden können wir ja eine Funktion
E6POS GetE6Pos(nElement :IN)
SetE6Pos(e6PosIN :IN, nElement :IN)

DECL REAL mX[4,4,512]
mX[1,1,1] = 0.0
mX[1,1,2] = 0.0
...
mX[4,4,512] = 0.0

und das für alle E6POS Elemente....

DECL REAL mY[4,4,512]
DECL REAL mZ[4,4,512]
DECL REAL mA[4,4,512]
DECL REAL mB[4,4,512]
DECL REAL mC[4,4,512]
DECL INT mS[4,4,512]
DECL INT mT[4,4,512]
DECL REAL mE1[4,4,512]
DECL REAL mE2[4,4,512]
DECL REAL mE3[4,4,512]
DECL REAL mE4[4,4,512]
DECL REAL mE5[4,4,512]
DECL REAL mE6[4,4,512]

Dann no die Funktion im Modul Positions...

DEFFCT E6POS GetE6POS(nElementDim1 :IN,nElementDim2 :IN, nElementDim3 :IN)
DECL INT nElementDim1, nElemtDim2, nElementDim3
DECL E6POS mE6POS

mE6POS.X = mX[nElement...]
mE6POS.Y = mY[nElement...]
mE6POS.Z = mZ[nElement...]
mE6POS.A = mA[nElement...]
mE6POS.B = mB[nElement...]
mE6POS.C = mC[nElement...]
mE6POS.S = mS[nElement...]
mE6POS.T = mT[nElement...]
mE6POS.E1 = mE1[nElement...]
mE6POS.E2 = mE2[nElement...]
mE6POS.E3 = mE3[nElement...]
mE6POS.E4 = mE4[nElement...]
mE6POS.E5 = mE5[nElement...]
mE6POS.E6 = mE6[nElement...]

Return mE6POS

ENDFCT

Und dann noch das SetE6POS.... aber das ist dann ja klar!

Geht das So? Oder sprengt das den Speicher eines DAT-Files?
Wenn einer das ausprobiert hat soll er doch bitte den Code Posten.

Sonst muß i mal nen DatFileGenerator schreiben, der mir Array's in beliebiegen grössen generiert.

Gruß
Robotnik

Hallo Robotnik,

wir reden hier vom Speicher und nicht von der Groesse der Dat -file.

Realzahlen benötigen 1 Bit je Zahl. Mit einem Overhead von 4 Byte für Realzahlen können wir also 32 Realzahlen abbilden. Bei 33 Realzahlen benötigen wir bereits 8 Bytes als Overhead.

Pro Integer benötigen wir 2 Bit pro Zahl und könnnen mit 4 Byte nur 16 Integer abbilden. Weiter siehe oben...

Vielleicht koennten wir hier einmal eine Liste mit allen bereits gefunden Limits fuer bestimmte Strukturen sammeln.

mfg

MOM

Liste siehe hier:
http://www.roboterforum.de/rob…c_v417_array-t2142.0.html

Servus Roland