SFC 14 "DPRD_DAT" mehrmals aufrufen

Immer_1

Level-1
Beiträge
27
Reaktionspunkte
1
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo,
Zugriff über Profibus auf FU-Daten:
In einem multiinstanz-FB(FBx) rufe ich SFC14 und SFC 15 auf , in diesem FB arbeite ich auch mit AR1, und AR2. Die ARs werden am Anfang gerettet und im letzten Netwerk wieder geladen.

In einem übergeordneten FB instanziere ich FBx mehrmals.
Die Instanzen rufe ich dann auf, so das SFC 14 und SFC 15 mehrmals hintereinander aufgerufen werden.

Nun zu meinem Problem: Beim übergeben der ausglesenen Werte stehen überall, d.h. in jeder Instanz die gleichen Werte(STAT-Variablen), obwohl ich mit SFC 15 andere jeweils Parameter anfordere.
Rufe ich allerdings nur eine Instanz auf, wird immer der jeweils richtige geliefert.
Gibt es vielleicht ein Zeitproblem?
Darf man SFC14 und SFC15 die auf den gleichen PEW/PAB-Bereich zeigen mehrmals hintereinander aufrufen?
Gibts da eventuell Probleme mit dem AR1 und AR2?. Muss ich die ARs auch vor den SFC-Aufrufen retten?

Wäre für Tipps sehr dankbar.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo!

Wenn du mit dem AR2 arbeitest benützt du dann in diesem Baustein auch noch Variablen?
Dann müßtest du bevor du eine Variable aus dem Deklarationsbereich verwendest das AR2 zurücksichern.

godi
 
Hallo,

In FBx(multiinstanziert)
benutze ich z.B. folgende Anweisungen

Var1: OUT (INT)
Var2: out (INT)

In_BOOL: IN(Bool)
Steuer_B: STAT(Byte)
Status_HB: STAT(Byte)
Status_LB: STAT(Byte)
TempAr1 : Temp(DWORD)
TempAr2 : Temp(DWORD)

Code:

erstes NW n:
TAR1 #TempAr1 // Adressregister 1 retten
TAR2 #TempAr2 // Adressregister 2 retten

NW n+1:
LAR1 P##Steuer_B
TAR2 //Adressoffset in Akku1
+AR1 //Bereichskennung wird nicht verändert

U In_BOOL
= DIX [AR1,P#0.4]

NW n+2:
CALL SFC 15 /schreiben
übergebe in SFC 15 Steuer_B

NW n+3:
CALL SFC 14 /lesen
Werte in Status_LB, Status_HB eingelesen

NW n+4:
LAR1 P##Var1
TAR2 //Adressoffset in Akku1
+AR1 //Bereichskennung wird nicht verändert

L Status_LB
T DIB [AR1,P#0.0]
L Status_HB
T DIB [AR1,P#1.0]

letztes NW:
LAR2 #TempAr2 // Adressregister 2 wiederherstellen
LAR1 #TempAr1 // Adressregister 1 wiederherstellen


In Übergeordnete FB
Def:
Instanz1: FBx
Instanz2: FBx

Code:
CALL Instanz1(Steuer_B = 2)
CALL Instanz2(Steuer_B = 4)

Instanz1.Var1 = 23
Instanz2.Var1 = 23

In beiden Instanzen steht der gleiche Wert. Warum?
Wenn man nur eine Instanz aufruft sind die Werte unterschiedlich.

Ich hoffe das jetzt alles klar ist.
Die Anweisungen sind mehr symbolisch zu verstehen.

Danke im voraus.

Immer_1, immer high
 
NW n+4:
LAR1 P##Var1
TAR2 //Adressoffset in Akku1
+AR1 //Bereichskennung wird nicht verändert

L Status_LB
T DIB [AR1,P#0.0]
L Status_HB
T DIB [AR1,P#1.0]

Warum rechnest du da das AR2 in das AR1 hinzu?

Ich schätze mal das du mit Status_LB und Status_HB das Var1 beschreiben willst.
Da würde genügen:
Code:
LAR1    P##VAR1
L [COLOR=Blue]Status_LB
[/COLOR]T [AR1,P#0.0] 
L [COLOR=Blue]Status_HB
[/COLOR]T [AR1,P#1.0]

godi
 
Das Problem wird an der Verwendung des AR2 liegen.

Das AR2- und das DI-Register dienen als Basisadressregister für die Adressierung aller Parameter und der STAT-Variablen innerhalb eines FB.

Wenn AR2 oder DI innerhalb eines FBs vom Anwender überschrieben werden, darf danach ohne eine Restaurierung der beiden Register kein Zugriff auf FB-eigene Parameter der STAT-Variablen erfolgen.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Also ich hab dein Vorgehen noch nicht ganz verstanden.

Bezieht ich das Folgende:

Darf man SFC14 und SFC15 die auf den gleichen PEW/PAB-Bereich zeigen mehrmals hintereinander aufrufen?
Gibts da eventuell Probleme mit dem AR1 und AR2?. Muss ich die ARs auch vor den SFC-Aufrufen retten?

auf einen FB-Aufruf, oder greifst du in jedem FB auf die selbe Adresse zu?

In jedem Fall wird es einige SPS-Zyklen dauern, bis nach deinem Schreibauftrag mit SFC15 eine Antwort von deinem Slave mit SFC14 ausgelesen werden kann. (der muß ja erst mal den Auftrag bearbeiten) Dazwischen kannst du sicher keinen Auftrag mehr an die selbe Adresse überstellen, denke ich mal. Also sollte normalerweise nach dem Auftrag, Parameter XY auszulesen, irgendeine Möglichkeit bestehen zu erkennen, daß auch der richtige Parameter mit SFC14 gelesen wurde. Übergibt der Slave dazu keine eindeutige Kennung bleibt nur die Wertänderung des einglesenen Wertes oder noch schlechter, eine feste Wartezeit, bis zum Einlesen des Wertes.

Was auf jeden Fall gehen sollte, ist mit 2 FB aus 2 Slaves Werte auslesen, da diese ja unterschiedliche Adressen belegen.
 
Wenn AR2 oder DI innerhalb eines FBs vom Anwender überschrieben werden, darf danach ohne eine Restaurierung der beiden Register kein Zugriff auf FB-eigene Parameter der STAT-Variablen erfolgen.[/quote]

Wie rettet/restauriert man DI-Register ?

mit den FB-Instanzen greife ich auf die PEB/PAB-Adressen nur mit unterschiedlichen Parametern für die Abfragen aus dem FU.

Der FU(Slave) meldet zwar Wert gelesen z.B. Status ="5", aber der Status ="5" bleibt gesetzt, solange sich der Zustand nicht ändert.
Ich Plane jetzt alle 200ms jeweils nur eine Instanz zu aktivieren, so dass die PEB,PAB-Bereiche eindeutige Werte liefern.
Das werde ich mal Morgen an der Anlage testen.

Danke für die Tipps!
 
Also die Datenbausteinregister lassen sich recht einfach sichern / restaurieren:
Code:
VAR_TEMP
  Global_DBNr : INT ;    
  Instanz_DBNr : INT ;    
END_VAR
BEGIN
NETWORK
TITLE =
      L     DBNO;     // lädt die Nummer des aktuell geöffneten Global-DBs
      T     #Global_DBNr; 

      L     DINO;     // lädt die Nummer des aktuell geöffneten Instanz-DBs
      T     #Instanz_DBNr; 

// hier ist irgendwelcher code

      AUF   DB [#Global_DBNr]; // öffnet den Global-DB

      AUF   DI [#Instanz_DBNr]; // öffnet den Instanz-DB
END_FUNCTION_BLOCK
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo,
"Übergibt der Slave dazu keine eindeutige Kennung bleibt nur die Wertänderung des einglesenen Wertes oder noch schlechter, eine feste Wartezeit, bis zum Einlesen des Wertes. "

Leider musste ich mit einer festen Zeit(200ms) lesen, dann klappts. Nicht immer, aber immer öfter.
 
Zurück
Oben