Step 7 Eingangswort über Pointer einlesen (Anfängerfrage)

Üblicherweise unterscheidet man in der IT schon zwischen Init und Restore / Wiederherstellen von Registern.

Was soll bei einem bedingten Aufruf passieren? Solange ich AR2 in Ruhe lasse nix

Gruß
Dieter

Danke schön !
Hab mir gedacht dass Init mit irgendwelche Startwerte füllen bedeutet ... mea culpa !
;)

Falls man gerade in einen Multiinstanz FB ist (zB. 3A)dann ist in AR2 eine Zahl , die der Abstand in Bytes zur Anfang der 1-er Instanz (1A) ist ...oder ? und falls man aus dieser Multiinstanz FB irgend einen andern Multiinstanz FB aufruft (zB. 2B) ...Hab nicht gewusst dass AR2 automatisch korrigiert wird falls man danach Multiinstanz 4A aufruft ...
( Die 2 verschiedenen Multiinstanzen haben 2 verschidene Datenbausteine !)


DANKE!

Das mit Temporär Daten symbolisch eingeben hat sich erledigt ( man soll Pointer = 4 Bytes ...also über REAL , TIME , DINT , DWORD Format übergeben ! INT , WORD , S5Time ...etc. würde nicht gehen weil zu wenig Bytes!).
 
Zwischen verschiedene OB-s wird aufm Stack zwischengespeichert und hinterher "korrigiert" da ist also kein Gefahr ... im gleichen OB aber :confused::confused::confused:
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo Leute,

entschuldigt die späte Antwort! ERSTMAL VIELEN DANK FÜR DIE ZAHLREICHEN UND GUREN BEITRÄGE!

Leider handelt es sich bei dem Integer-Wert als Bezug für die Adresse um eine Vorgabe, die ich nicht ändern kann! Ich werde aber auf jeden Fall die Adressen in Zukunft zwischenspeichern!

Vielen Dank an euch!
Marcus
 
Hallo Leute,

entschuldigt die späte Antwort! ERSTMAL VIELEN DANK FÜR DIE ZAHLREICHEN UND GUREN BEITRÄGE!

Leider handelt es sich bei dem Integer-Wert als Bezug für die Adresse um eine Vorgabe, die ich nicht ändern kann! Ich werde aber auf jeden Fall die Adressen in Zukunft zwischenspeichern!

Vielen Dank an euch!
Marcus

Könntest es so machen , so hättest du kein Stress mit den Adressregister ....

Code:
[COLOR=#333333]L #Eingang //INT(IN)
[/COLOR]SLD 3
T [COLOR=#333333]#EingangTEMP //DINT(TEMP)[/COLOR]
L #Ausgang //INT(IN)
SLD 3
T #AusgangTEMP //DINT(TEMP)
L EW [[COLOR=#333333]#EingangTEMP[/COLOR]]

[COLOR=#333333](Bitmanipulation)
[/COLOR]
//L EW [[COLOR=#333333]#EingangTEMP[/COLOR]] 
[COLOR=#333333]T AW [[/COLOR]#AusgangTEMP[COLOR=#333333]]
[/COLOR]
 
Hi Marcus,

hättest du gedacht das DAS HIER aus deiner Anfrage wird????????? :)
Aber bitte keine Angst vor weiteren Postings, das ist ein Glück nicht immer so
das ein Thread so auseinandergepflückt wird ;-)

Gruß, Toki
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Also , was soll man in diesem spezial Fall machen ... AR2 RESTORE/Init :confused: ?

Also ich würde das Register mit Null initialiseren.
Null ist nichts, daher kann nichts geschehen.

@TE; Wenn man ein EW über Pointer ansprechen muss , dann bitte es gut dokumentieren.
Solltest du in deinem FB das 2. Register benötigen, dann dieses im ersten NW1
LAR2
T #AR2_SAVE

und im letzten NW
L #AR2_SAVE
TAR2

schreiben, dann passiert dir beim Rücksprung aus der Funktion kein unschönes Erlebnis.


bike
 
Hi Bike,

sollte es nicht heißen:
TAR2
T#AR2_Save

L#AR2_Save
LAR2

Oder habe ich jetzt einen Gedankenfehler?? ;-)

Gruß, Toki
 
@TE; Wenn man ein EW über Pointer ansprechen muss , dann bitte es gut dokumentieren.
Solltest du in deinem FB das 2. Register benötigen, dann dieses im ersten NW1
LAR2
T #AR2_SAVE

und im letzten NW
L #AR2_SAVE
TAR2

schreiben, dann passiert dir beim Rücksprung aus der Funktion kein unschönes Erlebnis.

Da hast du aber einen groben Gedankenfehler, wozu das Sichern des AR2 in einem FB überhaupt notwendig ist.
Am Ende des FB interessiert es nämlich überhaupt keinen mehr ob das AR2 passt oder nicht, weil der Inhalt dann nicht mehr benötigt wird.

Wenn du das AR2 manipulierst, laufen alle Zugriffe auf statische Variablen bei symbolischer Adressierung auf falsche Speicherbereiche. Darum muss es heißen:
Bevor in einem FB das AR2 manipuliert wird, sichern, und unmittelbar nachdem es nicht mehr verwendet wird, wiederherstellen. Bzw. spätestens dann, wenn man auf eine Variable zugreifen will die im Instanz-DB des FB liegt, d.h. In, Out, InOut oder Stat.

Aber das sieht man selbst bei Siemens Programmbeispielen, dass da ohne Sinn und Verstand Register gesichert und rückgesichert werden. Was nur zeigt dass der Programmierer überhaupt nicht verstanden hat was er da macht.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Da hast du aber einen groben Gedankenfehler, wozu das Sichern des AR2 in einem FB überhaupt notwendig ist.
Am Ende des FB interessiert es nämlich überhaupt keinen mehr ob das AR2 passt oder nicht, weil der Inhalt dann nicht mehr benötigt wird.

Wenn du das AR2 manipulierst, laufen alle Zugriffe auf statische Variablen bei symbolischer Adressierung auf falsche Speicherbereiche. Darum muss es heißen:
Bevor in einem FB das AR2 manipuliert wird, sichern, und unmittelbar nachdem es nicht mehr verwendet wird, wiederherstellen. Bzw. spätestens dann, wenn man auf eine Variable zugreifen will die im Instanz-DB des FB liegt, d.h. In, Out, InOut oder Stat.

Aber das sieht man selbst bei Siemens Programmbeispielen, dass da ohne Sinn und Verstand Register gesichert und rückgesichert werden. Was nur zeigt dass der Programmierer überhaupt nicht verstanden hat was er da macht.

Habe ich den wirklich?
Mir ist schon klar, dass im AR2 für DI bzw Temp zuständig ist.
Und ist es wirklich unerheblich, wenn ich einen FB als Multiinstanz verwende, was mit dem AR2 geschieht?
Thomas, ich habe es gerade versucht, und habe beim Rücksprung bewusst Müll in das AR2 geschrieben und es hat beim Aufruf des nächsten FB geknallt.
Wenn ich jetzt über Weihnachten lang und weile habe, muss ich mir das einmal genauer anschauen.

Toki du hast natürlich recht, sorry.

bike
 
Thomas, ich habe es gerade versucht, und habe beim Rücksprung bewusst Müll in das AR2 geschrieben und es hat beim Aufruf des nächsten FB geknallt.

Was heißt "geknallt"?

Solange du das Call-Makro zum Aufrufen eines FB verwendest (mit UC kann man ja nur manuell einen FB als Multiinstanz aufrufen) kann da nichts passieren, weil dieses Makro eben auch das Sichern und Wiederherstellen des AR2 beinhaltet.
Ein Call "FB12" umschließt dann automatisch folgendes:
Code:
      TAR2  LD     0
      +AR2  P#12.0
      UC    "FB12"
      LAR2  LD     0
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Was meinst du mit Überlauf?

Er müsste schon mutwillig auf die Vorgänger-Lokaldaten schreiben um das System zum Einsturz zu bringen.
Im untergeordneten FB z.B.:
Code:
L DW#16#87000000
LAR1  
L P#9999.7
T D [AR1,P#0.0]

dann zeigt im übergeordneten FB das AR2 auf 9999.7 (in meinem konkreten Beispiel wo das AR2 im LD 0 zwischengespeichert wird), obwohl keiner was am AR2 gedreht hat ;-)
 
Was meinst du mit Überlauf?

Der Lokaldaten-Bereich hat je nach CPU nur eine bestimmte Größe.
Was passiert, wenn im aufgerufen FB die kompletten Lokaldaten belegt werden?
Bin zwar selber noch nie in die Situation gekommen ... aber es gibt ja bekanntlich nichts was nicht irgendeiner Programmierer fertig bringt :)


Gruß
Dieter
 
Der Lokaldaten-Bereich hat je nach CPU nur eine bestimmte Größe.
Was passiert, wenn im aufgerufen FB die kompletten Lokaldaten belegt werden?
Bin zwar selber noch nie in die Situation gekommen ... aber es gibt ja bekanntlich nichts was nicht irgendeiner Programmierer fertig bringt :)

Pro Baustein wird der Lokaldatenbereich schon beim Laden überprüft. D.h. wenn ich einen Baustein laden will, der auf LD 3000 zugreifen will wird das von der CPU abgewiesen wenn diese nur 2048 Bytes Lokaldaten pro Baustein hat. Da der Speicher für das AR2 immer hinter die letzte deklarierte Variable gelegt wird, sollte das auch abgefangen werden.
In die Verlegenheit dass mir der gesamte Lokaldatenbereich für eine Prioritätsklasse ausgegangen ist, bin ich noch nicht gekommen. Bei einer 300er wird vorher die maximale Bausteinverschachtelungstiefe (war mal bei 16) zuschlagen.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Pro Baustein wird der Lokaldatenbereich schon beim Laden überprüft.

Hin und wieder sollte man das Gehirn komprimieren :) Du hast vollkommen recht mit deinen Ausführungen.
Der Stack ist ja größer als der max. adressierbare Lokaldatenbereich in der Steuerung.

Gruß
Dieter
 
Respekt Thomas!
wo ich deine Ausführungen lese, erinnert mich das an einige Erläuterungen des Siemens-Trainers zum Speicherkonzept.
Doch das so detailliert zu begreifen, umzusetzen und zu erläutern das hat Klasse...
Du solltest vielleicht bei Siemens anfangen, da könntest wahrscheinlich einigen Leuten noch was beibringen!

@Dieter
wenn du weißt wie man sein Gehirn komprimiert dann schick mir ne PN. Ich versuche fehlenden Speicherplatz hin und wieder
mit einer "kleinen Ram-Löschung" in Griff zu bekommen :sm24:.
Klappt aber nur sehr bedingt ;-) (ich tue es trotzdem immer wieder)

Gruß, Toki
 
Zurück
Oben