Pointer als IN im FC verarbeiten

H

Hewlett_de

Guest
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo!
Ich habe ein kleines Problem:
Ich habe einen FC angelegt und als IN ist eine Variable "Eingang" mit dem Datemtyp Pointer angelegt.
Nun zum Problem: wie kann ich den dann weiterverarbeiten?
Am Eingang des FCs ist jetzt z.B. P#E0.0 angelegt. Wenn ich aber jetzt im
FC den Aufruf 'L P##Eingang' mache, dann habe ich ja nur die Pointeradresse von der Variable "Eingang" und nicht von P#E0.0 oder habe ich da falsch gedacht? Irgendwie muss ich ja jetzt die Adresse z.B. ins Adressregister speichern können
 
hoffe ich versteh dich nicht falsch.

übergib am eingang keinen pointer, sonder die adresse die du laden willst. den pointer erzeugst du dann in der fc.

IN: MW 100 //z.b. 20

in der fc:

L IN
sld 3
lar1

L EB [AR1,P#0.0] //läd eb20
U E [AR1,P#0.1] //e20.1
 
Zuviel Werbung?
-> Hier kostenlos registrieren
OK, diese Lösung ist auch gut, das habe ich auch mal versucht, allerdings als bool. IN ist E0.0. Nun soll das EB0 in AB1 "kopiert" werden:
L P##IN
LAR1

L B [AR1,P#0.0]
T AB 1

Funktioniert aber dann nur bei E0.0, dann ist A1.0 "1". Aber bei allen anderen bits funktioniert es nichtmehr. Oder mache ich hier was falsch?
 
Ganz einfach...

Hewlett_de schrieb:
Hallo!
Nun zum Problem: wie kann ich den dann weiterverarbeiten?
Am Eingang des FCs ist jetzt z.B. P#E0.0 angelegt. Wenn ich aber jetzt im
FC den Aufruf 'L P##Eingang' mache, dann habe ich ja nur die Pointeradresse von der Variable "Eingang" und nicht von P#E0.0

Genau das ist ja auch der Sinn eines Pointers.
So wie du dein vorgehen beschreibst, würdest du ja keinen Pointer brauchen.
Den Pointer setzt mann ein, um dynamisch die Adresse oder auch nur Adressbereiche (BitNr., Byte, Bereich) zu "verbiegen".

Du musst zunächst den Pointer aus seinem bytearray "zerpflücken", dann kannst du an die einzelnen Adresssegmente ran, siehe hier:


=========== AWL ANFANG ===============

L P##EINGANSPOINTER // Andresse des Eingangs- Bits, aus Pointer lesen
LAR1 // Adresspointer adressieren
L W [AR1,P#0.0] // erstes Wort eines Pointers enthält DB-Nr.
T #DB_NR
L 0 // Wenn DB-Nr = 0, dann kein D sondern E/A/M
==I
SPB noDB

AUF DB [#DB_NR] // Wenn DB-Nr <>0, dann DB öffnen


noDB: L D [AR1,P#2.0] // Bereichskennung. Byte u. Bitadresse
T #Pnt_Bit
LAR1 // ergibt Zieladresse als Eingangs-Adresse !!!!!!
U [AR1,P#0.0]
= #EINGANG // Errechnete Bitposition ist das Eingangs-Bit.

U #EINGANG
=


=========== AWL ENDE ===============

in der Deklarationszeile der
EINGANGSPOINTER als Pointer (In)
Pnt_Bit als Doppelwort (Temporär)
DB_Nr als Int (Temporär)



Das steht übrigens auch sehr schön in der S7 - Hilfe beschrieben !


Viel Spaß noch mit den Pointern!
 
Zuletzt bearbeitet:
Unregistrierter gast schrieb:
Bitte erkläre der geneigten Leserschaft, warum du einen DB0 öffnen willst ?

Beachte hierbei bitte auch die Zykluszeitoptimierung.

Hallo Unreg,

das ist keine Kritik, einfach nur ein Hinweis.

Zykluszeitoptimierung? Du kannst den Vergleicher weglassen.

Aber es würde mich interessieren, was andere Spezis dazu sagen.

Gruß, pt
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Der Vergleicher muss vergleichen.

plc_tippser schrieb:
Du kannst den Vergleicher weglassen.


Dann lass mich kurz die S7 - Hilfe rezitieren:

"Die verwendung eines DB 0 ist nicht zulässig" (oder so)

Versuch mal den DB0 z.B. in AWL zu öffnen....
(AUF DB0)

Warum sollte ich dann das Risiko eingehen, das "hinterücks" indirekt zu machen ?

IMHO: Vergleicher ist Notwendig.
 
Es wird kein DB0 verwendet, es wird lediglich die 0 ins DB1-Register geladen. Solange nicht auf einen nicht vorhandenen DB zugegriffen wird, gibt es auch kein Problem.

AUF DB0 geht nicht aber AUF DB[#DB_No] ist kein Problem, auch wenn eine 0 im DB_No steht.

pt
 
Zuviel Werbung?
-> Hier kostenlos registrieren
scheint den db0 zu öffnen.
ohne transfer ins dbw0 läufts aber mit nicht.


Ereignis 2 von 100: Ereignis-ID 16# 4562
STOP durch Programmierfehler (OB nicht geladen oder nicht möglich, bzw. kein FRB vorhanden )
Unterbrechungstelle im Anwenderprogramm: Zyklisches Programm (OB 1)
Prioritätsklasse: 1
FC-Nummer: 9
Bausteinadresse: 104
Bisheriger Betriebszustand: RUN
Angeforderter Betriebszustand: STOP (intern)
interner Fehler, kommendes Ereignis
11:35:26:581 30.06.06

Ereignis 3 von 100: Ereignis-ID 16# 2523
Bereichslängenfehler beim Schreiben
Global -DB , Wortzugriff, Zugriffsadresse: 0
FC-Nummer: 9
Bausteinadresse: 104
Angeforderter OB: Programmierfehler-OB (OB 121)
Prioritätsklasse: 1
interner Fehler, kommendes Ereignis
11:35:26:581 30.06.06
 

Anhänge

  • Zwischenablage01.gif
    Zwischenablage01.gif
    26,9 KB · Aufrufe: 29
Zuletzt bearbeitet:
Es wird die 0 ins DB-Register geladen.

Ohne einen Schreib- oder Lesezugriff passiert aber nichts.

@ Volker
kommentier das mal aus.

in dem Pointer steht ja bei DB=0 kein DBx sondern M/E/A .Deshalb gibt es dann auch keinen Konflikt.

pt
 
plc_tippser schrieb:
in dem Pointer steht ja bei DB=0 kein DBx sondern M/E/A .Deshalb gibt es dann auch keinen Konflikt.
pt

da hast du sicherlich recht.
ich habe das bewusst mal dahingeschrieben um zu sehen was passiert.
wenn man L 0, T DBW0 weglässt, läuft das ohne stop.
 
volker schrieb:
da hast du sicherlich recht.
ich habe das bewusst mal dahingeschrieben um zu sehen was passiert.
wenn man L 0, T DBW0 weglässt, läuft das ohne stop.

Wenn du dir das in Maschinenebene vorstellst, dann ist dir ja auch egal was für eine Adresse im Register steht. Erst wenn du dieses benötigst, wirst du es initialisieren.

Nun nimmt Siemens einem ja die ganze Arbeit schon ab und wenn im DB 0 steht, dann steht ja zwangsläufig EAM im Rest des Pointers.
Ein Mischmasch aus indirekt und direkt ist ja da nicht vorgesehen und auch sinnlos.

pt
 
Onkel, mir fällt da sofort der BEARBEITE-Befehl ein.
Oder liege ich da komplett falsch ?
 
Zuletzt bearbeitet:
Onkel Dagobert schrieb:
Steht im DB-Register eine "0", so führt die CPU eine NOP-Operation aus.

schau mal die grafik in meinem beitrag (#12)

wenn dem so wäre, sollte dann nicht der db80 weiterhin geöffnet sein?
 
Zurück
Oben