Problem mit OUT Variabeln

Zuviel Werbung?
-> Hier kostenlos registrieren
Jochen Kühner schrieb:
Geht nicht, da eine Statische Variable eine DB variable ist, und auf DB gehen keine direkten Out Zugriffe.
Zum Vergrößern anklicken....
Woher stammt denn diese "Erkenntnis"? Komisch, daß mein Step7 das nicht weiß. :ROFLMAO:
Bei mir funktionieren Zuweisungen von FC.OUT auf STAT oder DB.DBX schon immer prima.


explorer42 schrieb:
also noch mal:

FC1:

U E1.0
= #sensor (ist eine out variable)


im FB1:

Call FC1
sensor:=#stat_sensorzustand (ist eine statische variable)
...

Call FC2
invariable:=#stat_sensorzustand
...

so funktioniert aber Anlage richtig:

Call FC2
invariable:="-42B6"
...
Zum Vergrößern anklicken....
Ist es zuviel verlangt, daß Du mal genau erklärst, was bedeutet: "funktioniert richtig" und "funktioniert nicht richtig"?

Genau Dein Beispiel funktioniert bei mir auf Anhieb "richtig". Hier mal als AWL-Quelle:
Code: 
FUNCTION "FC1" : VOID
TITLE =
VERSION : 0.1

VAR_OUTPUT
  sensor : BOOL ;	
END_VAR
BEGIN
NETWORK
      U     E      1.0; 
      =     #sensor; 
END_FUNCTION

FUNCTION "FC2" : VOID
TITLE =
VERSION : 0.1

VAR_INPUT
  invariable : BOOL ;	
END_VAR
BEGIN
NETWORK
      U     #invariable; 
      =     M    102.0; 
END_FUNCTION

FUNCTION_BLOCK "FB1"
TITLE =
VERSION : 0.1

VAR
  stat_sensorzustand : BOOL ;	
END_VAR
BEGIN
NETWORK
// Zum Testen M101.0 nach E1.0 übertragen
      U     M    101.0;     // Test-Steuervariable
      =     E      1.0; 

// FC1 überträgt E1.0 nach #stat_sensorzustand
      CALL "FC1" (
           sensor := #stat_sensorzustand);

// FC2 überträgt #stat_sensorzustand nach M102.0
      CALL "FC2" (
           invariable := #stat_sensorzustand);

// M102.0 muß nun den selben Zustand wie M101.0 haben
      U     M    102.0; 
      U     M    101.0; 
      =     M    103.0; 
END_FUNCTION_BLOCK

DATA_BLOCK "DB1"
TITLE =
VERSION : 0.0

"FB1"
BEGIN
   stat_sensorzustand := FALSE; 
END_DATA_BLOCK

ORGANIZATION_BLOCK "OB1"
TITLE = "Main Program Sweep (Cycle)"
VERSION : 0.1

// VAR_TEMP
// ...
// END_VAR
BEGIN
NETWORK
      CALL "FB1" , "DB1" ;

END_ORGANIZATION_BLOCK

Ist Dein FB1-Instanz-DB aktuell? (ggf. löschen und neu erstellen lassen)
Werden bei Dir irgendwo die AR1- und AR2-Register verändert?
Hast Du irgendwo im Programm indirekte Schreibzugriffe, die eventuell nicht sauber sind?

Gruß
Harald
 
funtioniert richtig bedeutet das die Anlage bzw. Zylinder genau das macht was ich möchte.
d.h. ich habe zwei zylinder in der Maschine. Zylinder1 darf ausfahren wenn Zylinder 2 in Grundstellung ist. Fährt irgendwann aus. Aber macht es nicht wenn ich über stat oder db variable gehe.

Instanz DB , Schreibzugriffe, AR1 und AR2 habe ich überprüft. In Ordnung.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
explorer42 schrieb:
Danke für die Antworten!

d.h. wenn ich es richtig verstanden habe:

eine db-variable am in eingang eines FCs wird irgendetwas aus dem L-Stack geladen.
bei einem Eingangswort nicht weil der Pointer direkt auf das EW zeigt.

Aber was passiert wenn ich die db variable nicht vorher lese sondern vorher immer zyklisch über einen FC out beschreibe
und dann später lese?
Zum Vergrößern anklicken....

Die DB Variable wird in die Lokaldaten umgespeichert und dann von dort gelesen. Aber Sie wird nur vor dem FC Aufruf umgespeichert wenn es ein In oder ein IN_OUT Parameter ist. Genauso werden die Lokaldaten nur zurück in den Db geschrieben wenn es sich um OUT oder IN_OUT Variablen handelt!
 
PN/DP schrieb:
Woher stammt denn diese "Erkenntnis"? Komisch, daß mein Step7 das nicht weiß. :ROFLMAO:
Bei mir funktionieren Zuweisungen von FC.OUT auf STAT oder DB.DBX schon immer prima.
Gruß
Harald
Zum Vergrößern anklicken....

Was nicht funktioniert sind lesende Zugriffe auf Out Variablen eines FCs, bei dem ein DB oder DI Datenwort an der OutVariable benutzt wird, wenn die Out Variable vor dem ersten lesen nicht beschrieben wird!

Und auch nur wenn man es so:

Code: 
      CALL  "POSITIONSKONTROLLE"
       aa:=DB1.DBW0

und nicht so
Code: 
AUF DB1
      CALL  "POSITIONSKONTROLLE"
       aa:=DBW0

programmiert!
 
Zuletzt bearbeitet:
Jochen Kühner schrieb:
Die DB Variable wird in die Lokaldaten umgespeichert und dann von dort gelesen. Aber Sie wird nur vor dem FC Aufruf umgespeichert wenn es ein In oder ein IN_OUT Parameter ist. Genauso werden die Lokaldaten nur zurück in den Db geschrieben wenn es sich um OUT oder IN_OUT Variablen handelt!
Zum Vergrößern anklicken....

also war dein MC7-ausflug für die lösung des problems nicht notwendig. ich hatte ihn im hintergrund schon gestern gemacht und festgestellt, dass es daran nicht liegt... aber schön zu wissen, dass du dir nen kopp machst...



explorer42 schrieb:
Instanz DB , Schreibzugriffe, AR1 und AR2 habe ich überprüft. In Ordnung.
Zum Vergrößern anklicken....

wie überprüft?
 
Zuviel Werbung?
-> Hier kostenlos registrieren
vierlagig schrieb:
also war dein MC7-ausflug für die lösung des problems nicht notwendig. ich hatte ihn im hintergrund schon gestern gemacht und festgestellt, dass es daran nicht liegt... aber schön zu wissen, dass du dir nen kopp machst...
Zum Vergrößern anklicken....

Ja aber im MC7 kann mal halt schön sehen was Step 7 daraus macht. Es sind ja in MC7 eigentlich alle Befehle so wie in AWL eingegeben, außer die Calls, da es eben dafür keinen direkten MC7 Befehl gibt...
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Jochen Kühner schrieb:
Ne, bin leider im OG, da Ich mein EG zur Zeit renoviere... Und da ist's grad verdammt warm... :ROFLMAO: Also wird die Entwicklung wohl etwas stocken...
Zum Vergrößern anklicken....
Hast Du da jetzt Langeweile und mußt User mit halbverstandenen technischen Details verunsichern?

Im übrigen ist es in jeder Programmiersprache so, daß temporäre Variablen und Übergabeparameter auf dem Stack vor
einer expliziten Zuweisung einen undefinierten Inhalt haben. Das ist keine Spezialität von Step7.

Jochen Kühner schrieb:
Was nicht funktioniert sind lesende Zugriffe auf Out Variablen eines FCs, bei dem ein DB oder DI Datenwort an der OutVariable benutzt wird, wenn die Out Variable vor dem ersten lesen nicht beschrieben wird!
Zum Vergrößern anklicken....
Das ist nicht auf DB oder DI beschränkt und hat auch nichts damit zu tun, ob man die voll-qualifizierte Schreibweise
für den DB-Aktualparameter benutzt oder die Kurzform ohne Angabe des DB. Egal welcher Aktualparameter (D,L,M) an der
OutVariable (von einfachem Datentyp) dran ist, das Lesen (in- oder außerhalb des FC) ohne vorherige Zuweisung (im FC)
ist zwar möglich, ergibt aber immer zufälligen bzw. undefinierten Mist.

Ausnahme: Übergabe von Datentypen, die mehr als 4 Byte groß sind und Pointer.
Da ist es völlig egal, ob die als IN, OUT oder IN_OUT übergeben werden, die Übergabeparameter können nach Herzenslust
gelesen und beschrieben werden.

Gruß
Harald
 
PN/DP schrieb:
Hast Du da jetzt Langeweile und mußt User mit halbverstandenen technischen Details verunsichern?

Im übrigen ist es in jeder Programmiersprache so, daß temporäre Variablen und Übergabeparameter auf dem Stack vor
einer expliziten Zuweisung einen undefinierten Inhalt haben. Das ist keine Spezialität von Step7.


Das ist nicht auf DB oder DI beschränkt und hat auch nichts damit zu tun, ob man die voll-qualifizierte Schreibweise
für den DB-Aktualparameter benutzt oder die Kurzform ohne Angabe des DB. Egal welcher Aktualparameter (D,L,M) an der
OutVariable (von einfachem Datentyp) dran ist, das Lesen (in- oder außerhalb des FC) ohne vorherige Zuweisung (im FC)
ist zwar möglich, ergibt aber immer zufälligen bzw. undefinierten Mist.

Ausnahme: Übergabe von Datentypen, die mehr als 4 Byte groß sind und Pointer.
Da ist es völlig egal, ob die als IN, OUT oder IN_OUT übergeben werden, die Übergabeparameter können nach Herzenslust
gelesen und beschrieben werden.

Gruß
Harald
Zum Vergrößern anklicken....


Nee würd Ich so nicht behaupten. Du kannst ja mal eine Out Variable in einem FC definieren und deren wert lesen. Das Funktioniert. Es ist natürlich nicht schön, aber es geht!

Es ist ja so das der Compiler den gleichen Code aus dem FC Aufruf macht, ob ein Parameter IN, OUT oder IN_OUT ist, es wird nur was anderes erzeugt wenn der Parameter vorher in Lokaldaten umgespeichert werden muss (Beispiel DBxx.DBWyy).
 
Hab folgendes nochmal versucht:


AUF DB 99
CALL "POSITIONSKONTROLLE"
aa:=DBW0

aa ist ein Out parameter.

in meinem FC kann Ich den Wert von DBW 0 lesen....
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Jochen Kühner schrieb:
Nee würd Ich so nicht behaupten. Du kannst ja mal eine Out Variable in einem FC definieren und deren wert lesen. Das Funktioniert. Es ist natürlich nicht schön, aber es geht!

Es ist ja so das der Compiler den gleichen Code aus dem FC Aufruf macht, ob ein Parameter IN, OUT oder IN_OUT ist, es wird nur was anderes erzeugt wenn der Parameter vorher in Lokaldaten umgespeichert werden muss (Beispiel DBxx.DBWyy).
Zum Vergrößern anklicken....

und wann muß umgespeichert werden? genau, wenn die adresse mit einem pointer nicht erreichbar ist! (oder bei KOP/FUP: sowieso alle IN, IN/OUT) ... toll, und was kann man beim aktuell vorliegenden problem mit diesem wissen anfangen? richtig! nischts!

hat schon jemand die bausteinkonsistenzprüfung vorgeschlagen?
was ist mit der prüfung der indirekten adressierung? ist diese vorhanden? wenn ja, wie? multiinstanzen? ... das sind die wirklich bewegenden fragen und nicht ob der compiler die datenbausteinadresse aufspalten muß, weil er dafür einen any und keinen einfachen pointer verwenden muß ... man ey :sw13:
 
explorer42 schrieb:
Hallo zusammen,

Der FC wird von einem FB aufgerufen. Die Out Variable speichere ich in eine Stat variable von dem aufrufenden FB ab. Diese Stat variable lege ich dann auf einen anderen FC als Freigabe IN Variable z.B. für ein Zylinder.
Das Problem ist das der Zylinder vorher schon fährt obwohl er noch nicht die Freigabe bekommen. Lege ich den Eingang auf den FC direkt an oder ich deklariere die out variable als INout Variable klappt alles wunderbar.
Zum Vergrößern anklicken....

Wenn ich diese Ursprungsfrage lese wurde gefragt warum es mit dem Eingang direkt oder als In_OUT Funktioniert, oder lieg Ich falsch?


Nee, Ich hatte nichts anderes erwartet...
 
Jochen Kühner schrieb:
Wenn ich diese Ursprungsfrage lese wurde gefragt warum es mit dem Eingang direkt oder als In_OUT Funktioniert, oder lieg Ich falsch?



Nee, Ich hatte nichts anderes erwartet...
Zum Vergrößern anklicken....

ja richtig, aber trotzdem komisch irgendwie :(.
baustein konsistenz habe ich überprüpft.
benutze keine multiinstanzen.
keine überlappenden bereiche...
ich habe keine indirekte adressierung benutzt.
 
Zuletzt bearbeitet:
ich kann leider den code nicht einfach posten.
das problem habe ich zwar "umschifft" aber wäre schön gewesen
warum das so ist.
 

Similar threads

T
TIA TIA V16 Upd 6 - Bug beim Erweitern der Hardware / Zur Info
Antworten
1
Aufrufe
2K
TheQuest
T
G
Grundsatzfragen zur Restrukturierung einer bestehenden Programmstruktur
Antworten
11
Aufrufe
2K
Mrtain
Mrtain
L
TIA Komisches Ablöseverhalten bei tiefen-verschachtelten FBs übergeben als inout
Antworten
4
Aufrufe
2K
LehnerTh
L
T
TIA Holding Register bei S7-1200 als Modbus Server/Slave
Antworten
0
Aufrufe
835
TIAnoob93
T
S
TIA Wie kann ich in TIA etwas vergleichbares wie den ANY-Pointer nutzen?
2
Antworten
25
Aufrufe
10K
shaggy0815
S
Zurück
Oben