merkwürdiges phänomen ?

[volker]

Zuviel Werbung?
-> Hier kostenlos registrieren

hallo
ich hab hier ein problem mit 2 fc.

      AUF   DB   175                    // **1
      CALL  FC   170
       Takt    :=M2.2
       Start   :=#berieseln_start
       Zeitwert:=#Soll_Berieseln
       Reset   :=#berieseln_reset
       Restzeit:=DB175.DBD4             // **2
       Out     :=DB176.DBX0.1
 
      CALL  FC   175
       Takt       :=M2.2
       Run        :=DB176.DBX0.1
       TW         :=#Soll_Pause
       Out        :=DB176.DBX0.2
       TE_Speicher:=DB175.DBD8          // **3

werden die bausteine so aufgerufen flattert db175.dbd4 zwischen soll_pause und soll_pause - 1.

**2
schreibe ich bei fc170 bei restzeit nur dbd4 oder irgendein MD hin klappts.

**3
es klappt auch wenn ich bei te_Speicher ein MD und bei restzeit db175.dbd4 schreibe.

ich sitze hier schon seit 3 stunden und kriege einfach nicht raus woran das liegen kann.

hier mal das komplette prog zum testen als awl-quelle.

 

[Ralle]

Und wie sieht FC175 intern aus, den finde ich nicht .

 

[volker]

Zuviel Werbung?
-> Hier kostenlos registrieren

sorry. hab wohl einen falschen baustein dabeigepackt.

hier die fc175

FUNCTION FC 175 : VOID
TITLE = SE
AUTHOR : Lischnew
FAMILY : 'TIMER'
NAME : 'Time-SE'
VERSION : 1.0
 
VAR_INPUT
  Takt : BOOL ; //positive Flanke. Sinnvoll sind 1 Sekunde oder 1 Minute. 
  Run : BOOL ; //Zeit läuft wenn dieses Bit 1-Signal hat. bei 0 wird die Zeit auf TW gesetzt 
  TW : DINT ; //Zeitwert. 
END_VAR
VAR_OUTPUT
  Out : BOOL ; //1 Signal wenn die Zeit abgelaufen ist. (DW hat 0 erreicht) 
END_VAR
VAR_IN_OUT
  TE_Speicher : DINT ; //Datenwort in dem die Zeit gespeichert wird. (DW wird dekrementiert) 
END_VAR
BEGIN
NETWORK
TITLE = 
      U     #Run; 
      SPB   RUN; 
      L     #TW; 
      T     #TE_Speicher; 
      U     #Out; 
      R     #Out;
      SAVE; 
      BEA   ; 
RUN:  UN    #Takt; 
      SPB   ENDE; 
      L     #TE_Speicher; 
      L     1; 
      -D    ; 
      T     #TE_Speicher; 
      L     0; 
      >D    ; 
      SPB   OK; 
      L     0; 
      T     #TE_Speicher; 
OK:   NOP   0; 
ENDE: L     0; 
      L     #TE_Speicher; 
      ==D   ; 
      =     #Out;
      SAVE; 
END_FUNCTION

 

[Ralle]

Auf jeden Fall würde ich Restzeit und TE_Speicher mal als INOUT parametrieren. Damit hatte ich schon des öfteren Erfolg.​

 

[sps-concept]

Problem

Hallo Volker,

wenn OUT-Parameter nicht zyklisch auf DB-Variablen geschrieben werden gibts Probleme. Mit Merker etc funktionierts. Und wenn man ne Variable in nem Baustein liest und schreibt sollte es IN_OUT sein.

MfG
André Räppel

 

[volker]

Zuviel Werbung?
-> Hier kostenlos registrieren

im fc175 wars ein in out. im fc170 nicht.

ja dann gehts. hätte ich auch selbst drauf kommen können.

find ich aber trotzdem irgendwie merkwürdig.
na ja, hauptsache es geht.

 

[JesperMP]

Der Grund ist dies:

Am Ende eines FC Anrufs, wird die OUT Addressen immer geschrieben.
Wenn es keine relevanten Daten in die OUT-Adressen gibt, dann wird etwas gefälschter Werte anstatt geschrieben.
Eine IN_OUT Adresse hat nicht dieses Problem.

 

[volker]

Der Grund ist dies:
Am Ende eines FC Anrufs, wird die OUT Addressen immer geschrieben.

alles klar. das ist der entscheidende satz.
blöde regel.

aber wenn mans weiss.

hatte längerer zeit schon mal ein prob welches ich dann auch durch in/out beseitigt hatte. aber manchmal sieht man den wald vor lauter bäumen nicht.

 

[Unregistrierter gast]

Zuviel Werbung?
-> Hier kostenlos registrieren

alles klar. das ist der entscheidende satz.
blöde regel.

aber wenn mans weiss.

hatte längerer zeit schon mal ein prob welches ich dann auch durch in/out beseitigt hatte. aber manchmal sieht man den wald vor lauter bäumen nicht.

Die Out - Variablen eines FC (nicht eines FB) werden immer vom Lokaldatenstack versorgt, anders als bei S5, wo über die Formaloperanden immer direkt die Aktualoperanden angesprochen wurden.

Wird im FC nun der Formaloperand nicht beschrieben (böser Fehler) dann stehen im OUT "willkürliche" Daten, eben die, welche die letzte Instanz (mehr oder weniger zufällig) dort hinterlassen hat.

Das besonders Gemeine: Je nach Konstellation kann sich der Fehler erst nach langer Zeit bemerkbar machen oder sporadisch auftreten (z.B. wegen Alarm - OB aufruf vor FC - Aufruf)

 

[Ralle]

Aus dem Grund nehme ich eigentlich fast nur noch IN_OUT, da muß man nicht so lange über solche Wirkungen nachdenken.

 

[Unregistrierter gast]

Aus dem Grund nehme ich eigentlich fast nur noch IN_OUT, da muß man nicht so lange über solche Wirkungen nachdenken.

Das stimmt, allerdings werden die FC dadurch etwas unübersichtlicher (finde ich) und "länger" (von der Ansicht her, nicht vom Code )