Step 7 FC Aufruf bei KOP und FUB

[Asab]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo

ich bin neulich über folgendes gestolpert. Ich rufe eine FC2 auf, der eine Flankenauswertung macht und diese Flanke und eine Zählwert an einen anderen FC3 weiter gibt.
Rufe ich beide FCs in Reihe auf, wird FC3 nicht mit dem Ergebnis von Fc2 aufgerufen, sondern mit dem Bit, das in Fc2 rein geht. (im AWL Code zu sehen, dass FC3 mit L4.0 versorgt wird).



Mache ich aus diesem Netzwerk quasi eine Parallelschaltung (siehe NW2), dann wird FC3 mit dem Ergebnis von FC2 versorgt so wie ich es wollte.

Aber nun meine Frage: Warum wird im Aufruf von NW1 die Boolsche Variable anders behandelt als die Integer Variable. Der BOOL Input am FC3 wird mit dem Bit "vor" Aufruf FC2 versorgt aber die Integer Variable bekommt durchaus den aktuellen Wert aus FC2, kann mir jemand sagen warum dieses so ist.

Warum die Nichtgleichbehandlung von BOOL und INT ?

Gruss A.

 

[de vliegende hollander]

Hallo,

Hab mal geprüft.
Das macht er auch wenn man nicht FC nehmt aber dann mit FB's

Auch wenn man die EN Eingang nicht beschaltet.

Und auch wenn man im FC (Wo man die FC 2 und 3 aufruft) nicht Temp variablen nehmt aber Merker.

Und auch wenn man die Reihenfolge von Boll und INT mal ändert.

Und auch wenn man nur ein Boll als Variabele hat...

Würde einfach mal behaupten das das Beschalten der ENO Ausgang nur funktioniert mit Bausteine aus der Bibliothek. So wie MOVE oder ADD und so weiter.

Bram

 

[vierlagig]

Zuviel Werbung?
-> Hier kostenlos registrieren

Das Beschalten des ENO funktioniert in obigen Fällen! (Voraussetzung: BIE wird vernünftig bedient)
Der Rest ist ein furchtbare Krücke aus der FUP/KOP Darstellungswelt ...

Ich vermute, es hat mit der Übersetzung und der Bedienung der Statusbits zu tun.
Fakt ist aber auch, dass es in reinem AWL super funktioniert

 

[JoopB]

Wenn Sie am ende der FC s und FB s deiser 2 regelen code eingibt wekt das beispie in 1ste nw auch

Set  // leste 2 regelen code in ein FC oder FB.
Save  // mit dieser code wurde die ENO  true.

Gruss,

Joop

 

[vierlagig]

Wenn Sie am ende der FC s und FB s deiser 2 regelen code eingibt wekt das beispie in 1ste nw auch

Set  // leste 2 regelen code in ein FC oder FB.
Save  // mit dieser code wurde die ENO  true.

Gruss,

Joop

Abgesehen davon, dass ich das probiert habe: was im FC steht hat keinen Einfluss auf die Darstellung des Aufrufs.

 

[de vliegende hollander]

Zuviel Werbung?
-> Hier kostenlos registrieren

Das Beschalten des ENO funktioniert in obigen Fällen! (Voraussetzung: BIE wird vernünftig bedient)

Dass soll man dann in, FC2 und 3machen ? am ende?

Ik ben niet de enigste nedelander die hier in dit Forum is zie ik.. Hallo Joop

Bram

 

[PN/DP]

Hmm, das KOP-Programm funktioniert bei der Hintereinanderschaltung tatsächlich nicht richtig.
Genauso, wie aus der AWL-Ansicht zu erwarten ist:

      [COLOR="#FF0000"]U     #BoolTemp
      =     L      4.0[/COLOR]
      BLD   103
      U(    
      U     M     10.0
      =     L      4.1
      BLD   103
      U     M      0.1
      SPBNB _001
      CALL  FC     2
       inFlag:=L4.1
       pFlag :=[COLOR="#FF0000"]#BoolTemp[/COLOR]
       pWert :=#IntTemp
_001: U     BIE
      )     
      SPBNB _002
      CALL  FC     3
       inFlag:=[COLOR="#FF0000"]L4.0[/COLOR]
       inWert:=#IntTemp
_002: NOP   0

So wäre es richtig:

      U(    
      U     M     10.0
      =     L      4.1
      BLD   103
      U     M      0.1
      SPBNB _001
      CALL  FC     2
       inFlag:=L4.1
       pFlag :=#BoolTemp
       pWert :=#IntTemp
_001: U     BIE
      )     
      SPBNB _002
      [COLOR="#0000FF"]U     #BoolTemp
      =     L      4.0
      BLD   103[/COLOR]
      CALL  FC     3
       inFlag:=L4.0
       inWert:=#IntTemp
_002: NOP   0

Der ganze Aufwand mit der L4.0-Kopie von #BoolTemp ist vorgesehen, damit man am IN von FC3 noch weitere Bits verknüpfen kann, nur leider sitzt der Code an der falschen Stelle. Auch dann wenn man tatsächlich weitere Bits verknüpft.

Ich habe es gerade mit PLCSIM und einer CPU 315-2EH14 V3.2.10 getestet.
So kann man es testen, indem man den M6.0 steuert:

// im FC2
      U     M      6.0      // Testvorgabemerker
      =     #pFlag          // auf FC-OUT geben

// im FC3
      U     #inFlag         // FC-IN
      X     M      6.0      // mit Testvorgabemerker vergleichen
      S     M      6.1      // bei ungleich setze Fehlermerker

Ich kann mir nicht vorstellen, daß dieser anscheinend uralte Bug des KOP/FUP-AWL-Compilers bei Siemens nicht bekannt ist. Ich vermute, wegen "Kompatibilitätsgründen" darf der Bug nicht beseitigt werden. Der "Entdecker" Asab kann ja mal den Siemens Support befragen und uns dann berichten ...

Harald

 

[LinusAM4V]

Hallo zusammen.
In der Liesmich.rtf steht zu diesem Thema:
Bausteinparameter

• Wenn Sie boolsche Ausgangsparametern einer Call Box als Eingangsparameter einer zweiten Call Box verwenden, müssen die Call Boxen in unterschiedlichen Netzwerken platziert sein, da sonst unter Umständen die Ausgangsparameter der ersten Call Box keine Wirkung als Eingangsparameter der folgenden Call Box haben.

mfg
Linus

 

[Asab]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo,

also handelt es sich, wie von PN/DP vermutet wurde, um einen "...uralte Bug des KOP/FUP-AWL-Compilers" daher die Ungleichbehandlung. Und dieser Fehler ist wohl bei Siemens bekannt, daher die nette Umschreibung:

"... , da sonst unter Umständen die Ausgangsparameter der ersten Call Box keine Wirkung als Eingangsparameter der folgenden Call Box haben"

und die Umstände sind, wenn neben einander dann nicht, wenn untereinader dann unter Umständen wohl.

Hallo Linus,

bis zur Seite 39 des Liesmich.Rtf habe ich mich wahrscheinlich noch nie vorgearbeitet, meinen ehrlichen Respekt dafür, dieses zu finden.

Gruss Asab