Auswahlkriterium Betriebsstunden

Zuviel Werbung?
-> Hier kostenlos registrieren
rs-plc-aa schrieb:
Aber ganz ehrlich ... Das mit den Schleifen hätte ich allein nicht hinbekommen.
Schleifen sind auch etwas ungewöhnlich und etwas gefährlich in SPS-Programmen: Wenn du die Anzahl der Elemente erhöhst, nimmt die Anzahl der Durchläufe der äußeren Schleife mit n zu, bei jedem Durchlauf der äußeren Schleife werden erst n, dann immer ein Durchlauf weniger der inneren Schleife ausgeführt. Insgesamt gibt es also n*(n-1)/2 oder (n*n-n)/2 Durchläufe. Für sehr große Zahlen spielt nur noch n*n eine Rolle: Bei 1 Million Einträgen in das Telefonbuch einer Metropole ist n*n 1Billion. Ein besserer Sortieralgorithmus wie Quicksort schafft das mit n*log2(n), also ca 100000*20 = 20 Millionen Durchläufen!
Irgendwo, vielleicht bei 50, vielleicht bei 500 Elementen geht die CPU in Stop wegen Zykluszeitüberschreitung.
Abhilfe für längere Listen, wenn nicht oft neu sortiert werden muß: Pro Zyklus nur einen Durchlauf der Schleife ausführen.
 
Hallo,

so ganz auf anhieb komme ich irgendwie doch nicht weiter...

Ich dachte mir, daß ich für die Auswertungs- und Anforderungsfunktionen einen separaten FB erstelle.

Dieser stellt bis jetzt fest, wieviele BM´s momentan gefordert sind.

Die geschieht zyklisch, undzwar wird die Variable zuerst mit 0 überschrieben, und dann wieder neu ermittelt wieviele es diesmal sind (kann man bei den wenigen wohl so machen...).

Wenn diese Variable nun 0 ist liegt keine Anforderung vor.

Wenn sie aber einen Zyklus vorher >0 war ist mal anzunehmen daß irgendwas läuft was jetzt nicht mehr laufen soll.

Also das Spiel umgekehrt...

Jetzt kommt aber hinzu daß das BM mit den meisten Stunden nicht unbedingt laufen muss (wenn z.B. nur eines kurze Zeit lief kann es ja sein, daß es immer noch das mit den wenigsten Stunden ist - oder daß welche nicht betriebsbereit waren etc. ....)


Wäre es da nicht besser zur Abwahl eine andere Vorgehensweise einzuschlagen ?

Z.B. man nimmt Bytes die in der Einschaltfolge mit der ermittelten BM-Nummer versorgt werden, und dann in umgekehrter Reihenfolge wieder ausgeschaltet werden.

Laut meiner Denkweise komme ich aber dann (und auch schon für die Anforderung) auf eine ganze menge Vergleichsoperationen auf == Gleichheit.

Weil ich ja so immer noch nicht konkret weiß welches BM sich hinter DB10.DBB0 verbirgt.

Beispiel:

DB10.DBB0 = 5 muß ja erst mal so lange verglichen werden bis das mit dem BM#5 übereinstimmt - oder nicht ?


Vielleicht mache ich mir jetzt ein wenig unnötig in die Hose - aber es war doch mal die Rede von einem Zeiger der gleich auf das jeweilige BM verweisen würde.


Das erschlägt dann zwar auch nicht das prüfen auf betriebsbereitschaft bzw. bei der Abwahl ob das betreffende überhaupt läuft - aber würde die Sache nicht noch mehr aufblasen.


Daß hier natürlich mit allen Eventualitäten berücksichtigt nicht mit 20 Zeilen auszukommen ist, ist ja schon klar, aber mich würde das mit dem Pointer auch generell interessieren - und weil´s halt gerade hier passen würde...
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Zottel schrieb:
Ich würde die Betiebsbereitschaft nachher testen.
Das ist jetzt kein getesteter Code, nur das Prinzip:

Du brauchst z.B. 2 Betriebsmittel.
Diese Information kopierts du in irgendeine Variable. Ich sag´ mal MB88.
Du zählst MB89 hoch, da du auf jeden fall als nächste BM das mit nächstwenigeren Stunden einzuschalten versuchst.
Das nächste ist auch nicht getestet, aber eine konkrete Umsetzung:
Annahme : E1.0, E2.3, E3.4, E3.5, E4.1, E4.2, E6.3, E6.5, E6.6 fordern BMs an.
mit Absicht ungeordnet und mehr als du BMS hast...

Code:
L 0
UN E1.0
SPB =NB1
INC 1
NB1:UN E2.3
SPB =NB2
INC 1
NB2:UN E3.4
SPB =NB3
INC 1
NB3:UN E3.5
SPB =NB4
INC 1
NB4:UN E4.1
SPB =NB5
INC 1
NB5:UN E4.2
SPB =NB6
INC 1
NB6:UN E6.3
SPB =NB7
INC 1
NB7:UN E6.5
SPB =NB8
INC 1
NB8:UN E6.6
SPB =NB9
INC 1
T MB88
Du gehtst die Liste in DB10 durch, beginnend mit 0. Wo du bist, merkst du dir z.B. in MB89.
Du liest aus DB10.DBB[0], daß das BM mit den wenigsten Stunden die Nummer 4 hat.
L 0
T MB89
L 0
L MB88
SPZ NE // Wenn keine BMs mehr gebraucht werden, nix tun
call fc17 // fc17 schaltet das nächste Betriebsmiitel ein
nummer: MB89
Anzahl: MB88
L MB89
INC 1
T MB89 //nächste IndexNummer
L 0
L MB88
SPZ NE
call fc17 // fc17 schaltet das nächste Betriebsmiitel ein
nummer: MB89
Anzahl: MB88
...
L MB89
INC 1
T MB89 //nächste IndexNummer
L 0
L MB89
SPZ NE
call fc17 // fc17 schaltet das nächste Betriebsmiitel ein
nummer: MB89
Anzahl: MB88
NE: NOP0
[/code]
Öfter als 7 mal brauchst du das nicht machen, mehr BMs hast du ja nich...
Der FC17 macht die Vergleiche und das Folgende:
Du zählst MB89 hoch, da du auf jeden fall als nächste BM das mit nächstwenigeren Stunden einzuschalten versuchst.
Nun prüfst du die Betriebsbereitschaft von Nummer 4.
JA: Ist es bereit so schaltest du es ein und verringert MB88 um 1. Es ist nun 2-1=1. Du mußt noch 1 BM einschalten.
NEIN: Ist es NICHT bereit so schaltest du es nicht ein und läßt MB88 wie es ist. Es ist immer noch 2. Du mußt also noch 2 BM einschalten.
Code:
fc17 
in Nummer byte
inout Anzahl byte
A DB10
L #Nummer
L 8 // 8-bit-Einträge
*I
T LD0	// Temp index	
L DBB[LD0]
SPL  //Sprungverteiler, genaue Syntax aus Hilfe, es wird zu einer Marke 
// abhängig von der BM-Nummer gesprungen:
BM0,BM1;BM2,BM3,BM4,BM5,BM6

BM0:UN E14.0 // betriebsbereit BM0
BEB	// Ende, kann BM nicht einschalten
SET	//VKE 1
S A12.0	//einschalten
SPA END1	// Ende mit reduzierter Anzahl

BM1:UN E14.6 // betriebsbereit BM1
BEB	// Ende, kann BM nicht einschalten
S A22.1	//BM1 einschalten
SPA END1	// Ende mit reduzierter Anzahl

...

BM6:UN E15.6 // betriebsbereit BM6
BEB	// Ende, kann BM nicht einschalten
S  A34.6	//BM6 einschalten
SPA END1	// Ende mit reduzierter Anzahl
BEA			// fertig und Anzahl nicht verringern

END1:
L #Anzahl 
DEC 1
T #Anzahl
BE
Das Einschalten habe ich auf beliebige Ausgänge gelegt. Es gibt nur ein Einschalten durch den Setz-Befehl. Wie macht man nun die nicht gebrauchten BMs aus? Einfach vor dem Einschalten alle ausschalten!
Code:
SET
R A 12.0
R A 22.1
...
R A34.6
Das muß vor dem Einschalten erfolgen. Da die geänderten Zustände der Ausgänge erst am Ende des Zyklus übertragen werden, besteht keine Gefahr, daß die Schütze "rappeln".
 
bubblesort in st

Hallo Siemensgeplagte,

wenn ich mir das so durchlese, weiss ich wieder, warum ich von AWL immer Knoten im Hirn kriege :shock: . Hier bubblesort in ST:

  • PROGRAM bubblesort
    VAR CONSTANT
    [list:f88fb9d6a0]SORTMAX:INT:=6;
END_VAR
VAR
  • i: INT;
    zw: INT;
    ok: BOOL;
    sort: ARRAY[0..SORTMAX] OF WORD;
END_VAR
WHILE NOT ok DO
  • ok:=TRUE;
    FOR i:= 0 TO SORTMAX-1 DO
    [list:f88fb9d6a0] IF (sort > sort [i + 1]) THEN
    [list:f88fb9d6a0]zw:= sort ; sort := sort [i + 1];
    sort [i + 1]:= zw;
    ok:=FALSE;
END_IF[/list:u:f88fb9d6a0]END_FOR[/list:u:f88fb9d6a0]END_WHILE
[/list:u:f88fb9d6a0]
Und das Schönste daran ist: Wenn ich jetzt mal 50 statt 7 Werte sortieren will, muß ich genau einen Wert (SORTMAX) ändern. Ich liebe ST :p

Gruß
Andi
 
Ok, in ST sieht das wie in einer vernünftigen Programmiersprache aus. Eigentlich sieht es nach PASCAL aus... Habe aber kein ST-Werkzeug für S7 zur Verfügung und ich schätze, rs-plc-aa auch nicht... Eigentlich schade, daß Siemens beim Preis von Step7 ST nicht gleich mitliefert.
Was mich noch interessieren würde, ist wie der mit ST generierte Baustein in AWL aussieht. Poste doch bitte.
Bei meinem Vorschlag sortierst du 50 Einträge, indem du beim FC16 den Längen-Parameter auf 49 setzt. Natürlich müssen die DBs dann auch so lang sein.
 
Hallo,

zunächst mal will ich mich entschuldigen daß ich den Thread so kurz vor dem Ende veröden ließ...

Mir war es leider nicht möglich nur einen Handschlag daran weiter zu machen.


Einen riesen Dank will ich an Zottel aussprechen, der geduldig die Sache bis dahin mitgemacht hat.

============================================
@ Oberchefe:

Ich hoffe du bist nicht sauer wegen meiner "Gegenfrage" auf deine Frage...

Ich war irgendwie perplex, und konnte mir nicht richtig vorstellen was mein Wohnort jetzt damit zu tun haben soll...

============================================



Ich schrieb ja zu Anfangs daß ich diesen Baustein erst "demnächst" brauche...

Dieses "demnächst" wird wohl dieses Jahr eh nix mehr weswegen jetzt die ganze Zeit andere Dinge einfach Vorrang hatten...


Ich will aber den Thread auf jeden Fall wiederbeleben wenn es soweit ist.



Bis dahin...
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo,

nun habe ich die Arbeit an dieser Aufgabe wieder aufgenommen...



Ich bin - glaube ich - auch schon ziemlich weit gekommen mit den bisher geposteten Ideeen (--> besonderer Dank an Zottel ! ) ...


Mein momentaner Stand sieht ungefähr so aus:


Die Sortierung selbst funktioniert ja bereits.

Im Index DB stehen nun in absteigender Reihenfolge die BM´s

Die Auswertung ist quasi fertig - die Funktion die Einschaltet eigentlich auch ?? .


Hier wird ja eine Sprungleiste verwendet (was ja eigentlich eine super sache ist wenn man es mal kapiert hat...) - und genau hiermit habe ich noch ein Problem.


in dem Beispielcode von Zottel (FC 17) steht am Anfang folgendes:


Code:
      AUF   DB 10
      L     #Nummer
      L     8                           // 8-bit-Einträge 
      *I    
      T     LD    12                    // Temp index    
      L     DBB [LD 12]

      SPL ...


Was ich dabei noch nicht verstanden habe ist warum #Nummer mit 8 multipliziert wird.


Ziel des Ganzen ist ja aus meiner Sicht daß anhand von der übergebenen Variable #Nummer die Sprungleiste angewiesen wird z.B. DBB 0 aus dem IndexDB zu selektieren.


Was ich dabei wieder gar nicht verstehe ist wie der Bezug von dem Byte im IndexDB zum realen BM hergestellt wird.


Wenn z.B. im IndexDB das BM 4 an erster Stelle steht ( DBB 0 ) und die Sprungleiste holt sich das DBB 0 aus dem Index DB --> woher soll sie nun wissen daß es das BM 4 ist für das der Ausgang geschaltet werden soll ???



Das ist eigentlich auch gerade meine einzige "Sorge" an dem ganzen...


Besten Dank schon mal für mein "Aha Erlebnis" auf das ich noch warte :) ...
 
Das muss x8 multipliziert weil Pointers haben den Format Byte.Bit. D.h. wenn du Dein Offset eingibst wenn Du nichts weiteres machst, hast ein Offset in Bits. Es wurde vielleicht klarer aussehen wenn man stat

L Offset
L 8
*D
T LD0

einfach

L Offset
SLD 3 //shift Double Word Left 3 Bits
T LD0

aber im Prinzip ist es dasselbe, aber wenn Du den Fall Offset = 1 nimmst und Dich vorstellt wie der AKKU1 vorher und nachher aussieht, vielleicht verstehst Du es besser.
 
Hallo,

wieso Pointer ?

... vielleicht ist es das was ich daran nicht verstehe.

Ich dachte die Variable #Nummer gibt an welches DBB im IndexDB ausgewählt werden soll.

Und genau hierbei verstehe ich dann nicht wie die IndexDB Adresse (DBB) mit dem momentanen Wert des DBB´s (BM) verknüpft werden soll.


Das muß mir bitte jemand noch ein wenig genauer erklären.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ich dachte die Variable #Nummer gibt an welches DBB im IndexDB ausgewählt werden soll.

Ja und deswegen ist dieser Variable ein "Pointer" - Englisch für Zeiger, weil der Variable "zeigt" wo Deine Daten zu finden sind. Dies nennt man indirekte Adressierung.

Du findest einiges darüber hier.
 
Hallo,

danke.

Ich habe mal eine Weile geschmökert bei Siemens.

Aber meine eigentliche Frage:

rs-plc-aa schrieb:
Und genau hierbei verstehe ich dann nicht wie die IndexDB Adresse (DBB) mit dem momentanen Wert des DBB´s (BM) verknüpft werden soll.

kann ich nun immer noch nicht beantworten.


Ich denke wenn ich das verstanden habe, verstehe ich den Rest auch viel besser (vielleicht hänge ich mich auch deswegen zu sehr daran auf...) .


Also noch mal ganz präzise gefragt:

Beispiel --> Es soll nur ein BM eingeschaltet werden.


Dann wären die Variablen #Nummer = 0 und #Anzahl = 1 ... vor dem Aufruf der FC17.


In der FC 17 wird dann bei der Sprungleiste festgestellt daß das BM das im IndexDB an der Adresse DBB0 liegt eingeschaltet werden soll (wir gehen mal davon aus es ist betriebsbereit...)

Wenn jetzt aber #Nummer = 0 ist wird ja an der Sprungleiste der SPA nach BM0 ausgeführt - richtig ?

Und genau dann komme ich doch beim BM0 und nirgends wo anders heraus - oder ?

Und da bin ich der meinung daß das falsch ist --> denn nach der Sortierung kann ja beispielsweise auch das BM4 als DBB0 da stehen - oder habe ich schon weiter vorne was nicht verstanden ?

Somit sollte ja auch das BM4 (weil es in dem Fall dann die wenigsten Stunden auf dem Buckel hat) als einzigstes eingeschaltet werden.


Und eben diese Erkennung welche "echte" BM - Nummer sich hinter der IndexDB Adresse verbirgt fehlt doch oder ?



So zumindest habe ich das bis jetzt verstanden.
 
Wenn Du im Daten DB folgende Zeiten hast:

45 Stunden
20 Stunden
46 Stunden
34Stunden

heißt das, daß dein 1.Betriebsmittel 45 Stunden, dein 2. BM 20, dein 3.BM 46 und das 4.BM 34 Stunden auf dem Buckel hat. Eine Zeile im Daten DB gehört unabänderlich zu einem BM.

Nicht so im Index-DB. Der wird initialisiert mit:
0
1
2
3

Nach Sortieren steht aber drin:
1
3
0
2

Es wird die 1 aus dem 1.Wort des Index-DB geladen. Der Sprungverteiler springt zur 2.Marke. Dort wird das 2. BM eingeschaltet (weil du dessen Ausgang hinter dieser Marke ansteuerst). Das 2. BM ist das mit den wenigsten Stunden.

Soll nun noch ein BM eingeschaltet werden, so wird die 3 aus dem 2.Wort des Index-DB geladen. Der Sprungverteiler springt zur 3.Marke. Dort wird das 3. BM eingeschaltet (weil du dessen Ausgang hinter dieser Marke ansteuerst). Das 3. BM ist das mit den zweitwenigsten Stunden.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Zottel schrieb:
Es wird die 1 aus dem 1.Wort des Index-DB geladen. Der Sprungverteiler springt zur 2.Marke. Dort wird das 2. BM eingeschaltet (weil du dessen Ausgang hinter dieser Marke ansteuerst). Das 2. BM ist das mit den wenigsten Stunden.

Soll nun noch ein BM eingeschaltet werden, so wird die 3 aus dem 2.Wort des Index-DB geladen. Der Sprungverteiler springt zur 3.Marke. Dort wird das 3. BM eingeschaltet (weil du dessen Ausgang hinter dieser Marke ansteuerst). Das 3. BM ist das mit den zweitwenigsten Stunden.

Hallo,

darüber muß ich mir morgen intensiv Gedanken machen - denn das worauf die Sprungleiste zurückgreift ist für mich (noch) ein böhmisches Dorf... - obwohl ich volles Vertrauen habe in das was du sagst.

Aber gerade im Moment ist das für micht nicht greifbar da ich erst verstehen muß wie "die 1 aus dem ersten Wort des IndexDB´s geladen wird" - da hier für mich zunächst nur 7 einzelne Bytes drin sind :?
 
rs-plc-aa schrieb:
Aber gerade im Moment ist das für micht nicht greifbar da ich erst verstehen muß wie "die 1 aus dem ersten Wort des IndexDB´s geladen wird" - da hier für mich zunächst nur 7 einzelne Bytes drin sind :?
Sorry, ersetze "Wort" durch "Byte", habe mir das Programm nicht nochmal angesehen.
 
Hallo,

gut ok - das nehme ich dir keinesfalls übel...


Dann komme ich schon eher hin.

Ich hab das Programm jetzt zwar auch nicht vor mir aber ich versuch´s mal so:

Die Sprungleiste ist ja so aufgebaut:

Code:
L "Zahl" // Bitte beschriften...
SPL over // Die Zahl ist größer als die Anzahl der Elemente
SPA BM0 // Zahl = 0
SPA BM1 // = 1
SPA BM2 // = 2
SPA BM3 // = 3
SPA BM4 // ...
SPA BM5
SPA BM6

over: nop 0
S Störung // Zum Beispiel
SPA ENDE

BM0: // hier gleich prüfen ob das BM Bereit ist UND ob es schon läuft...
// Wenn Bereit=1 UND Läuft=0 dann
Einschalten_BM0
SPA EN1

BM1: ....

....

Ist das soweit korrekt ?
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Im Prinzip ist das korrekt.
Nach Einschalten eines BMs musste dann noch die Zahl der benötigen BMs verringert werden und die Position der Nummer des nächsten BMs im IndexDB hochgezählt, so daß als nächstes BM das mit den nächstwenigstens Stunden genommen wird.

Es sind doch schon alle Teillösungen hier aufgetaucht (außer vielleicht die Betriebsstunden im DatenDB genau dann hochzuzählen, wenn das BM eingeschaltet ist. Dabei muß natürlich die gleiche Zuordnung zwischen BM-Nummern und Ausgängen verwendet werden. Soll heißen, wenn im Sprungverteiler BM-Nummer 0 zum Einschalten des A12.0 führt, so muß, wann immer A12.0 ein ist, die Zeit im Eintrag 0 des DatenDB hochgezählt werden.).


Warum packst du es nicht auf eine CPU oder einen Simulator und probierst den ganzen Ablauf, bis du es verstehst?
 
Zottel schrieb:
Warum packst du es nicht auf eine CPU oder einen Simulator und probierst den ganzen Ablauf, bis du es verstehst?

Hallo,

da bin ich gerade dabei...

Jetzt war´s aber so daß im Auswertungsbaustein der die FC 17 aufruft nichts passiert ist --> kein Aufruf der FC.

Der Fehler lag an der SPZ anweisung die eigentlich nur ausgeführt werden sollte wenn keine weitere Anforderung ansteht.

Sie wurde aber komischerweise immer ausgeführt, und verhinderte das Starten der FC.


Ich hab dann mal

Code:
//... Das erste Modul holen...

      L     0
      L     "Module_soll"
      SPZ   nene                        // ... oder auch nicht ...

      CALL  "Index_Ausw"
       Nummer :="Index_Pos"
       indexDB:=10
       Anzahl :="Module_soll"


gegen

Code:
//... Das erste Modul holen...

      L     0
      L     "Module_soll"
      ==I   
      SPB   nene                        // ... oder auch nicht ...

      CALL  "Index_Ausw"
       Nummer :="Index_Pos"
       indexDB:=10
       Anzahl :="Module_soll"

getauscht - und siehe da es geht...

Was ich jetzt zwar sehe aber nicht verstehe ist das:


Code:
      AUF   DB [#idbn]
      L     #Nummer
      L     8                           // 8-bit-Einträge 
      *I    
      T     LD    12                    // Temp index    
      L     DBB [LD 12]

      SPL   tbig                        // wenn Nummer größer als Anzahl Sprungziele ist
      SPA   BM00
      SPA   BM01
      SPA   BM02
      SPA   BM03
      SPA   BM04
      SPA   BM05
      SPA   BM06

tbig: NOP   0
// hier kann eine Störmeldung o.Ä. erzeugt werden...
      SPA   ende

BM00: NOP   0
      UN    "M1_Bereit"                 // betriebsbereit BM0 
....

Wenn jetzt z.B. #Nummer = 6 ist, dann wird ja mit 8 multipliziert und in LD 12 kopiert (habe es von LD0 auf LD12 geändert...).

Hier steht dann 48 drin...

Nach der Anweisung

L DBB [LD 12]

steht 4 im Akku 1... warum ???

mir ist klar daß in meinem Beispiel das BM 4 (Sprungziel ist allerdings BM3 weil von 0 an gezählt) in der Indexliste an sechster stelle steht --> also eigentlich richtig gedeutet.

Laut Programmstatus wird aber an der Marke BM 5 (=Modul 6) weitergemacht...

In wirklichkeit wird aber das reale Modul 4 (Marke BM3) eingeschaltet.


Das verwirrt mich wieder komplett :(

Vielleicht liegt´s aber auch am Simulator --> und wenn es so ist dann kann der einen manchmal gewaltig nerven :!:
 
rs-plc-aa schrieb:
Hallo,

da bin ich gerade dabei...

Ich hab dann mal



gegen

Code:
      L     0
      L     "Module_soll"
      ==I   
      SPB   nene                        // ... oder auch nicht ...
...
So ist es richtiger. War das andere von mir?

Was ich jetzt zwar sehe aber nicht verstehe ist das:
Code:
      AUF   DB [#idbn]
      L     #Nummer
      L     8                           // 8-bit-Einträge 
      *I    
      T     LD    12                    // Temp index    
      L     DBB [LD 12]

      SPL   tbig                        // wenn Nummer größer als Anzahl Sprungziele ist
      SPA   BM00
      SPA   BM01
      SPA   BM02
      SPA   BM03
      SPA   BM04
      SPA   BM05
      SPA   BM06

tbig: NOP   0
// hier kann eine Störmeldung o.Ä. erzeugt werden...
      SPA   ende

BM00: NOP   0
      UN    "M1_Bereit"                 // betriebsbereit BM0 
....

Wenn jetzt z.B. #Nummer = 6 ist, dann wird ja mit 8 multipliziert und in LD 12 kopiert (habe es von LD0 auf LD12 geändert...).

Hier steht dann 48 drin...

Nach der Anweisung

L DBB [LD 12]

steht 4 im Akku 1... warum ???
Wohl deshalb weil im 7 Byte des IndexDB die Nummer 4 stand. Das kann ich aber nur aus dem Ergebnis schließen.
Nummer =6 bedeutet: 7.Eintrag im IndexDB = DBB6
Nummer =0 bedeutet: 1.Eintrag im IndexDB = DBB0
Die Byte-Nummer (hier 6) ist mit 8 zu multiplizieren. Das ist einfach eine Vorraussetzung damit der Befehl
Code:
     L     DBB [LD 12]
funktioniert.
Es haben ja schon Leute versucht, "pointer" zu erklären. Eigentlich finde ich das keine gute Erklärung, weil:
1. Step7 auch noch "typisierte" Pointer kennt, z.B. P#DB20.DBX0.0, P#E60.0, die eine Information über den Speicherbereich beinhalten.
2. Die hier verwendeten Adressen im Gegensatz zu pointern anderer Programmiersprachen stehen: Im Gegenstatz zu Pascal ist Rechnen mit "pointern" erlaubt. Im Gegenstatz zu C wird bei den Berechnungen aber eben nicht die Größe des Zielobjekts automatisch berücksichtigt.

Man könnte meinen, der Befehl
Code:
     L     DBB [LD 12]
behandele den Speicher als ein "array of bits". Nur: dann sollte es möglich sein, mittels eines Ausdrucks wie L DBB [5] ein byte zu lesen des erste 3 bits aus DBB0 und die anderen 5 aus DBB1 stammen. Geht aber nicht.

Fazit: der Befehl
Code:
     L     DBB [LD 12]
braucht immer die 8-fache Bytenummer, was zufällig auch die Bit-Nummer ist. Das ist weder vernünftig, noch dem Wesen nach durch den Begriff "Pointer" zu erklären, sondern schlicht eine "Schrulle" der Siemens-Entwickler, mit der man jetzt leben muß.

mir ist klar daß in meinem Beispiel das BM 4 (Sprungziel ist allerdings BM3 weil von 0 an gezählt) in der Indexliste an sechster stelle steht --> also eigentlich richtig gedeutet.
Ja, genau.
Laut Programmstatus wird aber an der Marke BM 5 (=Modul 6) weitergemacht...
Kann ich nicht nachvollziehen, eventuell siehst du einen Durchlauf in einem anderen Zyklus?
Kan der Simulator Einzelschritt?
In wirklichkeit wird aber das reale Modul 4 (Marke BM3) eingeschaltet.
Das soll es ja auch.
 
Zurück
Oben