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

[MarcusSPunkt]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo Leute,

ich (noch ein Anfänger) möchte gerne aus einem Funktionsbaustein heraus ein Eingangswort einlesen und dieses Wort an einem Ausgangswort wieder ausgeben. Die Anfangsadresse wird mir dazu als INT-Wert am FB als Eingang angegeben. Ich habe mir bereits was überlegt, weiß aber nicht, ob das so funktionieren wird, da ich keine Simulationssoftware habe kann ich es leider nicht prüfen. Also schaut bitte mal drüber und berichtigt mich (GANZ WICHTIG) bei Fehlern!

Beispiel: Eingangsvariable am FB (INT) Anfangsadresse zum Einlesen des Einangswortes 50: #Eingang=50
Eingangsvariable am FB (INT) Anfangsadresse zum Ausgeben am Ausgangsworte 40: #Ausgang=40

Es soll nun also das Merkerwort 50 in den FB eingelesen werden, Bitmanipulation vorgenommen werden und anschließend wieder in das Ausgangswort Mein Vorschlag (AWL):

L            #Eingang               // einlesen
SLD        3
LAR1                                   // ergibt einen Pointer von P#50.0 im Adressregister1
L            EW[AR1, P#0.0]     // lädt das EW50
T            MW0

(...Bitmanipulation am MW0...)

L              #Ausgang             // einlesen
SLD          3
LAR1                                    // ergibt einen Pointer von P#40.0 im Adressregister1
L             MW0
T             AW [AR1, P#0.0]   // transferiert in das AW40

Ich wüsste gerne, ob das so funktioniert! (Ich bin mir vor Allem bei dem Einlesen des Integer-Zahlenwertes nicht ganz sicher, ob ich daraus wie angegeben den Pointer machen kann, der dann auch wirklich auf das richtige Eingangswort bzw. Ausgangswort zeigt.)

Vielen Dank im Voraus,
Marcus

 

[MSB]

Also grundsätzlich könnte das schon so funktionieren,
nur machen deine Kommentare mit "lädt das MW50" wenn du ein EW liest nicht wirklich sinn, selbiges beim AW.

Abgesehen davon, ist das eine stinkordinäre IN-OUT Variable, das muss und sollte man nicht so umständlich (indirekte Adressierung) machen.

Mfg
Manuel

 

[MarcusSPunkt]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo Manuel,

vielen Dank für deine schnelle Antwort!

Entschuldige, ich habe meinen Code oben noch mal verbessert (Natürlich sollte das auch im Kommentar lädt EW50 heißen). Ich hatte die Aufgabenstellung vorhin beim Erstellen ein wenig geändert und vergessen die Kommentare anzupassen.

Du würdest es also nicht so umständlich machen, meintest du! Wie würde es denn deiner Meinung nach einfacher gehen?

LG,

Marcus

 

[MSB]

Es sind in letzter Konsequenz immer noch nur IN oder OUT oder IN-Out Variablen, nichts wofür sich eine indirekte Adressierung lohnen würde ...
Ein MW hat in einem derartigen FB schon mal aus Prinzip nichts zu suchen ... aber abgesehen davon, würde das wohl durchaus so funktionieren.

 

[MarcusSPunkt]

Stimmt, es muss sich bei dem "MW0" um z.B. eine temporäre Variable handeln!
Aber da ich an den Eingängen des FB nur die Adressen als Integer-Werte vorliegen habe, weiß ich nicht genau wie ich das sonst anders programmieren sollte.

 

[MSB]

Zuviel Werbung?
-> Hier kostenlos registrieren

Aber da ich an den Eingängen des FB nur die Adressen als Integer-Werte vorliegen habe, weiß ich nicht genau wie ich das sonst anders programmieren sollte.

Stellt sich jetzt natürlich die Frage warum ist das so, und muss das so sein?

Kurzum, um was es mir geht:
Du kannst indirekt adressieren wie du willst, nur bin ich aus verschiedenen Gründen absolut kein Freund davon, das elementare Sachen wie EA nicht in Querverweisen zu finden sind.

 

[bike]

Stellt sich jetzt natürlich die Frage warum ist das so, und muss das so sein?

Kurzum, um was es mir geht:
Du kannst indirekt adressieren wie du willst, nur bin ich aus verschiedenen Gründen absolut kein Freund davon, das elementare Sachen wie EA nicht in Querverweisen zu finden sind.

Du hast absolut recht.
Wenn man nicht findet, wo etwas gelesen oder geschrieben wird, ist fehlersuchen schwer.
Aber es ist doch inzwischen so chick alles indirekt und/oder mit Zeiger zu machen.
Das ist der neue Zeitgeist.


bike

 

[Sioan]

L #Eingang
//SLD 3
T LD 0
L #Ausgang
//SLD 3
T LD 4
L EW [LD 0]

[COLOR=#333333](Bitmanipulation)
[/COLOR]
//L EW [LD 0]
T AW [LD 4]

LD 0 und LD 4 sollen auch "Namen" haben obwohl man sie hier nur absolut benutzen DARF ! ... sonst wenn man auch andere Temporäre Lokal Daten hat ... etc.

Ein paar Siemens REGELN von einem Freund (...von mir ) :

1-Verwende immer symbolische Adressierung außer (wenn nicht anderes möglich) bei Indirekte Adressierung .
2-Vor Gebrauch zusammengesetzten Datentypen in FC oder FB(In-Out) AR1 retten (oder hinterher re-initialisieren).
3-Vor CALL FB und vor CALL FC/SFC ohne Parameter AR2 retten (oder hinterher re-initialisieren).

 

[M-Ott]

Zuviel Werbung?
-> Hier kostenlos registrieren

LD 0 und LD 4 sollen auch "Namen" haben obwohl man sie hier nur absolut benutzen DARF ! ... sonst wenn man auch andere Temporäre Lokal Daten hat ... etc.

Wie kommst Du darauf? Ich darf und kann die an dieser Stelle auch symbolisch verwenden.

1-Verwende immer symbolische Adressierung außer (wenn nicht anderes möglich) bei Indirekte Adressierung .

*ACK*

2-Vor Gebrauch zusammengesetzten Datentypen in FC oder FB(In-Out) AR1 retten (oder hinterher re-initialisieren).

Es ist in der Regel nicht nötig, das AR1 zu retten.

3-Vor CALL FB und vor CALL FC/SFC ohne Parameter AR2 retten (oder hinterher re-initialisieren).

Es ist nur dann nötig, das AR2 zu retten, wenn man schreibend darauf zugreift. In diesem Fall ist es aber sinnvoller, das AR2 VOR und nicht erst IN dem betreffenden Baustein zu retten.

 

[Toki0604]

Hi Michael, Hi Sioan,

In diesem Fall ist es aber sinnvoller, das AR2 VOR und nicht erst IN dem betreffenden Baustein zu retten.

Vor CALL FB

Das hatte Sioan glaube ich so gemeint, vorm CALL zu retten.
Ich habe das bislang so gehandhabt das ich das Retten der Register in NW1 gemacht habe und das Rücksichern im letzten NW.
Wo liegt der Unterschied ob ich das vor dem CALL des FB mache oder im ersten NW?
Ich möchte die Register nach erfolgtem Aufruf so verlassen wie ich sie "vorgefunden" habe,
daher finde ich irgendwie das das zum Baustein selbst gehört (daher handle ich das innerhalb des Bausteins)
Anders kann ich mein Vorgehen derzeit nicht begründen. Wenn es einen funktionellen oder anderen Hintergrund geben sollte
das Save and Resave vorm CALL zu machen, dann würde ich mein Vorgehen überdenken.
Gruß, Toki

 

[M-Ott]

Eigentlich wollte ich schreiben "... IN und nicht schon VOR ..."
Natürlich ist es im Baustein sinnvoller, da kann es nicht vergessen gehen.

 

[bike]

Zuviel Werbung?
-> Hier kostenlos registrieren

Macht es überhaupt Sinn AR2 immer zu "retten"?
Wenn man in einem FB das AR2 verwendet wird, dann sollte dieses Register in dem Baustein, in dem damit gearbeitet wird, gesichert und später wieder hergestellt werden.
Sollte vor dem Call schon gespeichert werden, kann es geschehen, dass wenn zwischen Sichern und Aufruf eingefügt wird, der Inhalt nicht mehr so ist wie er sein soll.

Man sollte doch modular programmieren.
Macht es dann echt Sinn im Programm Daten zu sichern, die in einer Funktion erst geändert werden?


bike

btw: Da Alex noch nie ein echtes Programm schreiben durfte, sollte man auf dessen "Erklärung" nicht wirklich viel geben

 

[Blockmove]

Macht es überhaupt Sinn AR2 immer zu "retten"?
Wenn man in einem FB das AR2 verwendet wird, dann sollte dieses Register in dem Baustein, in dem damit gearbeitet wird, gesichert und später wieder hergestellt werden.
Sollte vor dem Call schon gespeichert werden, kann es geschehen, dass wenn zwischen Sichern und Aufruf eingefügt wird, der Inhalt nicht mehr so ist wie er sein soll.

Man sollte doch modular programmieren.
Macht es dann echt Sinn im Programm Daten zu sichern, die in einer Funktion erst geändert werden?

Das seh ich auch so.
AR1 ist für mich ein reines Register für Adressierungszwecke.
Die Daten werden in statischen Daten verarbeitet.

AR2 meide ich. Für mich ist das nur bei Multiinstanzen interessant. Für andere Zwecke habe ich noch nie AR2 benutzt.

Sobald Alarm-OBs mit entsprechenden FB-Aufrufen ins Spiel kommen, ist eben Vorsicht geboten.
Deshalb hat sich bei mir jeder FB selber um seine Daten zu kümmern.
So "schöne" Dinge wie Parameter-Übergabe durch AR1 oder AR2 sind zwar vielleicht nett fürs Ego, bringen aber einen anderen zum Wahnsinn.

Gruß
Dieter

 

[Sioan]

[COLOR=#333333]L #Eingang[/COLOR]//SLD 3
T LD 0
L #Ausgang
//SLD 3
T LD 4
L EW [[B]LD 0[/B]]

[COLOR=#333333](Bitmanipulation)
[/COLOR]
//L EW [[B]LD 0[/B]] 
[COLOR=#333333]T AW [[B]LD 4[/B]]
[/COLOR]

Anstatt wie oben meint ihr , so wie unten aufrufen könnte in STEP 7 funktionieren ? Oder meint ihr einen Symbolischen Namen in der Symboltabelle (... geht das überhaupt für DIX ,DIB , DIW , DID ....Temporäre Daten?)

[COLOR=#333333]L #Eingang
[/COLOR]//SLD 3
T [COLOR=#333333]#EingangTEMP[/COLOR]
L #Ausgang
//SLD 3
T #AusgangTEMP
L EW [[B][COLOR=#333333]#EingangTEMP[/COLOR][/B]]

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

Selbstverständlich AR1 , AR2 nur dann retten/initialisieren wenn sie wirklich gebraucht werden : "man soll immer wissen was drinnen ist "

 

[bike]

Zuviel Werbung?
-> Hier kostenlos registrieren

Anstatt wie oben meint ihr , so wie unten aufrufen könnte in STEP 7 funktionieren ? Oder meint ihr einen Symbolischen Namen in der Symboltabelle (... geht das überhaupt für DIX ,DIB , DIW , DID ....Temporäre Daten?)

[Ironie]
Nein kann man nicht.
Denn die Angaben für In und OUT sowie Temp und STAT im Header des FB sind nur Zierde.

Die werden beim generieren des InstanzDB auch nicht übernommen.
Daher ist immer besser Lokaldaten absolut zu adressieren.
Man kann dann auch keinen Fehler machen beim Zugriff[/Ironie]

Man kann bzw sollte immer die Variablen symbolisch im Header anlegen, bevor man diese verwendet.
Hat zwei Vorteile:
Man kann lesen was wie verwendet wird und es kommt zu keinem Problem beim Ändern des Bausteines.
Es genügt FB speichern und IDB neu generieren und alles funktioniert.



bike

 

[Blockmove]

2-Vor Gebrauch zusammengesetzten Datentypen in FC oder FB(In-Out) AR1 retten (oder hinterher re-initialisieren).
3-Vor CALL FB und vor CALL FC/SFC ohne Parameter AR2 retten (oder hinterher re-initialisieren).

AR2 reinitialisieren ... Eine sehr schlaue Regel :twisted:
Was steht noch mal im AR2 bei Verwendung einer Multinstanz?

 

[Sioan]

Wie kommst Du darauf? Ich darf und kann die an dieser Stelle auch symbolisch verwenden.

... man ist/wird verwirrt !:???:

 

[Sioan]

Zuviel Werbung?
-> Hier kostenlos registrieren

AR2 reinitialisieren ... Eine sehr schlaue Regel :twisted:
Was steht noch mal im AR2 bei Verwendung einer Multinstanz?

Der Abstand zu Null Instanz
Initialisieren muss nicht unbedingt abnullen bedeuten

... was passiert aber wenn man aus zB. 3-te Instanz bedingt einen FB aufruft ?

 

[bike]

Der Abstand zu Null Instanz
Initialisieren muss nicht unbedingt abnullen bedeuten

... was passiert aber wenn man aus zB. 3-te Instanz bedingt einen FB aufruft ?

Was ist Abstand zu Null Instanz?

Es gibt Dokumentationen zu dem Programm Step7 und auch was die Adressregister bedeuten.
Warum in Gottesnamen liest du nicht endlich BEVOR du hier Mist ablässt.


bike

 

[Blockmove]

Der Abstand zu Null Instanz
Initialisieren muss nicht unbedingt abnullen bedeuten

... was passiert aber wenn man aus zB. 3-te Instanz bedingt einen FB aufruft ?

Ü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