AUF DB - und was geht jetzt alles damit ?

rs-plc-aa · 31 März 2007

Hallo,

mir ist klar daß die Suche zu dem Thema einiges ausspuckt aber ich habe trotzdem noch eine Frage die ich damit nicht beantwortet bekam...

Dafür will ich mich kurz fassen:

Warum funktioniert das nicht ?

Code:

      SET   
 
      AUF   DB [#DB_Nr_Merkerbits_Int]
      L     0                           // alle vorherigen Bits löschen
      T     DBD    4                    // HMI_Statuszeile_1
      T     DBD    8                    // HMI_Statuszeile_2
 
      S     #HMI_Gesperrt               // aktuelles Bit setzen

Das Problem scheint das Transferieren zu sein...

das sollte funktionieren:

Code:

      SET   
 
      AUF   DB [#DB_Nr_Merkerbits_Int]
      L     DBD    4                    // HMI_Statuszeile_1
      L     0                           
      T     DBD    4                    // HMI_Statuszeile_1
 
      L     DBD    8                    // HMI_Statuszeile_2
      TAK                           // alternativ zum neuen Laden der 0...
      T     DBD    8                    // HMI_Statuszeile_2
 
      S     #HMI_Gesperrt               // aktuelles Bit setzen

Gibt´s etwas dazwischen das auch funktioniert aber nicht so umständlich ist ?
Oder warum geht bei mir das obere nicht - fehlt vielleicht nur was oder wo ist der Fehler ?

volker · 31 März 2007

was soll den da nicht funktionieren?
in den dbd wird eine 0 stehen.
die #HMI_Gesperrt wird durch das obige set 1 sein. wenns ne tempvar ist, logischerweise NUR für diesen baustein.

rs-plc-aa · 31 März 2007

Nun, dann muss ich eine Fehlbeobachtung gemacht haben...

Die #HMI_Gesperrt ist Teil eines der DBDs (für die Textliste), und bevor ich das neue Bit setze wollte ich so die (alle) vorherigen rücksetzen.

Nur daß ich eben den DB beobachtet habe und feststellte daß dadurch keines der Bits zurückgesetzt wurde - und alle TRUE waren die im Ablauf je gesetzt wurden *grr*

Da im Beispiel für AUF in der Hilfe immer zuerst etwas aus dem (aufgeschlagenen) DB geladen wurde bevor etwas transferiert wurde dachte ich eben daß nur Lösung 2 funktionieren würde (obwohl mein erster Gedanke ja Lösung 1 war).

Deshalb hier die Frage da ich die Sache zum ersten mal so gebraucht habe.

Code:

L 0
T DB1.DBD0
T DB1.DBD4
...

Das ging ja auch immer... - nur daß ich jetzt halt nirgens mehr die direkte DB Nummer stehen haben darf / kann.

Du würdest also sagen daß der Fehler wo anders liegen dürfte da alle "T" sich auf den aufgeschlagenen DB beziehen bis ein anderer aufgeschlagen wird ?!?

volker · 31 März 2007

rs-plc-aa schrieb:
da alle "T" sich auf den aufgeschlagenen DB beziehen bis ein anderer aufgeschlagen wird ?!?

korrekt.
schau dir den baustein im status an. dort siehst du in der spalte DB1 welcher db geöffnet ist.

rs-plc-aa · 31 März 2007

Mist, dann ist was anderes faul - aber egal schon wieder was dazugelernt...

Ich hab auch schon einen Verdacht...

Die Spalte müsste ich natürlich erst mal "aktivieren" -> danke für den TIP !!!

volker · 31 März 2007

dazu noch was am rande

Code:

auf db10
l db11.dbw2
t dbw4

hier wird in in den db11 transferiert.
für s7 intern ist l db11.dbw2 2 befehle. nämlich auf db11, l dbw4.
damit ist der zuletzt geöffnete db also der db11

rs-plc-aa · 31 März 2007

auch noch am rande:

Wie "kopiere" ich dann Inhalte von DB zu DB wenn ich beide vorher AUF machen muss ?

? -> die Quelle öffnen, Inhalt z.B. DBD0 laden; das Ziel öffnen (ist dann meine Quelle noch im Akku ?) und transferieren ?

Oder SFCs verwenden ?

MSB · 31 März 2007

Wenn es größere Bereiche sind, ist der SFC20 dein Freund!

Mfg
Manuel

rs-plc-aa · 31 März 2007

Dann müsste ich aber auch zuerst wieder Pointer bauen um die SFC zu versorgen, oder ?

Das ist noch nicht getestet, müsste aber gehen:

Code:

      AUF   DB [#DB_Nr_ZS_IO_Int]
      L     DBW    0                    // beinhaltet "Schalter" und "Status" (Quelle)
      AUF   DB [#DB_Nr_Merkbits_Int]
      L     DBW    0
      TAK   
      T     DBW    0                    // bekommt "Schalter" und "Status" (Ziel)

Klar, wenn mehr als ein DW benötigt wird muss der Vorgang wiederholt werden -> hier kommt dann SFC20 ins Spiel.

Wie müsste dann SRCBLK und DSTBLK aussehen wenn die DB Nummer in ner Variable steht ?

volker · 31 März 2007

entweder so
l db10.dbw2
t db12.dbw4

oder

auf db10
l dbw2
auf db12
t dbw4

merke: der aufruf eines db ändert nicht den akku

SinusQuadrat · 31 März 2007

rs-plc-aa schrieb:
.....
Wie müsste dann SRCBLK und DSTBLK aussehen wenn die DB Nummer in ner Variable steht ?
.......

Wenn man was variables hast (DB-Nr, Anzahl, Anfangsadresse .....) muß man
Quelle und Ziel als Anypointer definieren.
Byte 4 und 5 des Anypointers wäre dann die DB-Nr.
Dazu gab es im Forum schon zig Beiträge , such mal nach Anypointer.

jabba · 31 März 2007

rs-plc-aa schrieb:

Warum funktioniert das nicht ?

Code:

      SET   
 
      AUF   DB [#DB_Nr_Merkerbits_Int]
      L     0                           // alle vorherigen Bits löschen
      T     DBD    4                    // HMI_Statuszeile_1
      T     DBD    8                    // HMI_Statuszeile_2
 
      S     #HMI_Gesperrt               // aktuelles Bit setzen

Probier mal so,

Code:

      SET   
 
      AUF   DB [#DB_Nr_Merkerbits_Int]
      L     L#0                           // alle vorherigen Bits löschen
      T     DBD    4                    // HMI_Statuszeile_1
      T     DBD    8                    // HMI_Statuszeile_2
 
      S     #HMI_Gesperrt               // aktuelles Bit setzen

Du lädst nur 16 Bit mit einer 0 und nicht 32Bit

rs-plc-aa · 31 März 2007

Hallo,

danke noch mal für die Antworten.

Das mit den 16 statt 32 bit war ein "Kopierfehler" - natürlich L#0 oder DW#16#0 ...

Wow - und das an einem Samstag :s12:

volker · 1 April 2007

jabba schrieb:
Du lädst nur 16 Bit mit einer 0 und nicht 32Bit

das ist zwar nicht 100% korrekt, funktioniert aber.
die linken 16bit des akku werden mit 0 gefüllt

rs-plc-aa · 2 April 2007

Ich dreh noch durch...

Es klappt einfach nicht !

Wenn ich die "Löschoperation" ausserhalb des FB mache - z.B. OB1 vor dem FB call ist alles toll -> nur im FB geht´s net *grr*

Verdacht1: Die zu löschenden Bits die in den DWs drin sind sitzen ebenfalls einzeln in der IN_OUT Schnittstelle des FB. Wäre es möglich daß das irgendwie konkurriert ?

Wäre es (jetzt mal rein theoretisch) nicht genau so wie bei Merkern daß deren Zustände pro (FB-)Durchlauf mehrmals geändert werden können und jede Änderung SOFORT wirksam wird ?

Wenn ja dann geht hier irgendwas gewaltig schief !

Liegt da vielleicht ein Abbild der Bits aus der IN_OUT Schnittstelle das am ende des Bausteins wieder drübergebügelt wird und quasi den alten zustand wiederherstellt ? -->> So kommt´s mir nämlich so langsam vor !!!

Hat jemand noch nen Tip auf lager ?

P.S.: @ Volker: Ich habe die DB Register im Status jetzt "sichtbar" - alles korrekt... sogar bei AUF DB[...] steht im Indirekt die richtige nummer.

volker · 2 April 2007

normal sollte das auch in dem fb funzen.

poste doch mal den kompletten fb als awl-quelle (aber beim exportieren auf absolute adressierung schalten)

rs-plc-aa · 2 April 2007

... funzt ja auch -> aber lies bitte noch mal das Fettgedruckte aus meiner vorigen Antwort - je mehr ich in die Richtung überlege um so sicherer bin ich mir daß es genau das ist !

Die Opraration selbst geht einwandfrei - auch im FB -> nur nach beendigung des FB´s ist alles wieder wie vorher weil (da bin ich mir jetzt zu 99,9% sicher) die Bits selbst nicht durch R-Befehle einzeln zurückgesetzt werden sondern immer noch so in der Instanz liegen wie vorher - und dann wird am Ende des FB die Schnittstelle wieder aktualisiert, sprich die (immer noch) gesetzten Bits in den DB zurückgeschrieben.

Blöd ist jetzt natürlich nur daß ich die ganze Vorgehensweise jetzt knicken kann :???:

edit: mittlerweile könnte man eigentlich wieder in den dem Ur-Problem gewidmeten Thread zurückwechseln da das mit der "AUF DB" geschichte hiermit eigentlich abgehandelt ist und das Problem damit (noch) nicht behoben ist. Hier der Thread zum Kernproblem : http://www.sps-forum.de/showthread.php?t=12885 , hier würden auch alle weiteren Gedanken zur Bausteinschnittstelle besser dazupassen und für die spätere Suche nützlicher sein.
(hoffe das ist ok so...)

Kai · 2 April 2007

Bei mir funktioniert folgendes Programm:

Code:

DATA_BLOCK DB 1
TITLE =
VERSION : 0.1
 
  STRUCT    
   DBW0 : WORD ;   
   DBW2 : WORD ;    
   DBW4 : WORD ;    
   DBW6 : WORD ;    
   DBW8 : WORD ;    
   DBW10 : WORD ;   
  END_STRUCT ;  
BEGIN
   DBW0 := W#16#0; 
   DBW2 := W#16#0; 
   DBW4 := W#16#0; 
   DBW6 := W#16#0; 
   DBW8 := W#16#0; 
   DBW10 := W#16#0; 
END_DATA_BLOCK

Code:

FUNCTION FC 1 : VOID
TITLE =
VERSION : 0.1
 
VAR_INPUT
  [COLOR=red]DBNR : INT[/COLOR] ;  
END_VAR
VAR_TEMP
  [COLOR=red]DBNRW : WORD[/COLOR] ;    
END_VAR
BEGIN
NETWORK
TITLE =
      UN    E      0.0; 
      SPB   M01; 
      [COLOR=red]L     #DBNR; [/COLOR]
[COLOR=red]      T     #DBNRW; [/COLOR]
[COLOR=red]      AUF   DB [#DBNRW];[/COLOR] 
      L     DW#16#12235678; 
      T     DBD    0; 
      L     DW#16#87654321; 
      T     DBD    4; 
M01:  NOP   0; 
NETWORK
TITLE =
      UN    E      0.1; 
      SPB   M02; 
      [COLOR=red]L     #DBNR; [/COLOR]
[COLOR=red]      T     #DBNRW; [/COLOR]
[COLOR=red]      AUF   DB [#DBNRW];[/COLOR] 
      L     DW#16#0; 
      T     DBD    0; 
      T     DBD    4; 
M02:  NOP   0; 
END_FUNCTION

Code:

ORGANIZATION_BLOCK "HAUPTPROGRAMM"
TITLE = Hauptprogramm
AUTHOR : KAI
FAMILY : SPSFORUM
NAME : SEGMENT
VERSION : 1.0
 
VAR_TEMP
  OB1_EV_CLASS : BYTE ; //Bits 0-3 = 1 (Coming event), Bits 4-7 = 1 (Event class 1)
  OB1_SCAN_1 : BYTE ;   //1 (Cold restart scan 1 of OB 1), 3 (Scan 2-n of OB 1)
  OB1_PRIORITY : BYTE ; //Priority of OB Execution
  OB1_OB_NUMBR : BYTE ; //1 (Organization block 1, OB1)
  OB1_RESERVED_1 : BYTE ;   //Reserved for system
  OB1_RESERVED_2 : BYTE ;   //Reserved for system
  OB1_PREV_CYCLE : INT ; //Cycle time of previous OB1 scan (milliseconds)
  OB1_MIN_CYCLE : INT ; //Minimum cycle time of OB1 (milliseconds)
  OB1_MAX_CYCLE : INT ; //Maximum cycle time of OB1 (milliseconds)
  OB1_DATE_TIME : DATE_AND_TIME ;   //Date and time OB1 started
END_VAR
BEGIN
NETWORK
TITLE =
      CALL FC     1 (
           DBNR                     := 1);
 
END_ORGANIZATION_BLOCK

Gruß Kai

Flinn · 2 April 2007

rs-plc-aa schrieb:
auch noch am rande:

Wie "kopiere" ich dann Inhalte von DB zu DB wenn ich beide vorher AUF machen muss ?

? -> die Quelle öffnen, Inhalt z.B. DBD0 laden; das Ziel öffnen (ist dann meine Quelle noch im Akku ?) und transferieren ?

Oder SFCs verwenden ?

Tach,
oder - falls du einen FC hast - den zweiten DB als DI öffnen,so:

Code:

AUF   DB10
AUF   DI11
 
L   DBW30
T   DIW30
 
L   DBW32
T   DIW32

Gruß
Flinn

rs-plc-aa · 2 April 2007

von Kai:
Bei mir funktioniert folgendes Programm:

bei mir auch...

Nimm statt einer FC einen FB und deklariere im IN_OUT Bereich 16 BOOL Variablen. Dann deklarierst du in deinem DB ebenfalls 16 BOOL Variablen.

Diese ordnest du an der Schnittstelle deines FB beim Aufruf zu.

Jetzt setzt du ein paar davon wahhlos in deinem FB und versuchst anschließend das DBW0 mit NULL zu überschreiben (im FB).

Das Ergebnis müsste dann so aussehen daß wenn du hinterher im OB1 das DBW0 deines DB lädst es nicht =NULL sondern diese Bits die gesetzt wurden immer noch gesetzt sind...

Mehr zu meinem eigentlichen Problem und vielleicht schon mögliche Lösungen: http://www.sps-forum.de/showthread.php?t=12885

AUF DB - und was geht jetzt alles damit ?

Level-1

Supermoderator

Level-1

Supermoderator

Level-1

Supermoderator

Level-1

Level-3

Level-1

Supermoderator

Level-2

Level-1

Level-1

Supermoderator

Level-1

Supermoderator

Level-1

Level-1

Level-1

Level-1

Similar threads

Wir schützen deine Privatsphäre