-Menü

Beiträge anzeigen

Dieser Abschnitt erlaubt es Ihnen, alle Beiträge anzusehen, die von diesem Mitglied geschrieben wurden. Beachten Sie, dass Sie nur Beiträge sehen können, die in Teilen des Forums geschrieben wurden, auf die Sie aktuell Zugriff haben.

Beiträge anzeigen-Menü

Beiträge - fu_zhou

#1
Hallo zusammen,

ich nutze den CTRL_PID um mit der Lüftung die Raumfeuchte zu regeln. Funktioniert wie erwartet. Aber: Ich habe am CTRL_PID SUP mit 1 parametriert, Sollwert = 60%, d.h. zwischen 59 und 61% ändert der Regler am Stellsignal Y nichts. LL ist bei mir 10 (minimale Luftleistung 10%), LH ist 100 (maximale Luftleistung 100%). Jetzt passiert es immer wieder, dass die Lüftung bei 99-100% Leistung läuft, sich die Feuchte von z.B. 63% Richtung 61% bewegt und der Regler plötzlich 10 (=LL) am Y-Ausgang ausgibt, um ein paar Sekunfen später wieder auf den vorherigen Wert zu springen (99-100%). Wenn ich SUP mit 0 parametriere passiert das nicht.

Kennst jemand das Problem und hat es schon behoben, wahrscheinlich im SCL-Quellcode?

Danke und Gruß!
#2
Ich habe das Problem mit der Enthalpie auch und verzichte daher im Moment... Eine Lösung wäre schön!
#3
Bin auch eben drüber gestolpert. So funktioniert es - das Übersetzen, die Funktion werde ich gleich testen.

FUNKTIONIERT!!!!!  ;D ;D ;D ;D

Danke!
#4
Wie kriegt man das mit dem STATUS=131 noch unter?
IF tx - last >= max_runtime THEN status := 131; END_IF
Das IF soll ja im Prinzip erweitert werden, so dass es neben der "max_runtime" auch die berechneten Positionen mit der "PositionReachedDelay"-Nachlaufzeit dazu verwendet, den Ausgang für AUF oder Zu zurückzusetzen, ohne dass ein Tastendruck die Zeit bis zum Erreichen der "max_runtime" unterbrechen muss.
#5
Ja, POS ist als Byte definiert, hier die Deklaration:
VAR_INPUT
  POS, ANG : BYTE;
  S1, S2 : BOOL;
  IN : BOOL;
  PI, AI : BYTE;
END_VAR
VAR_INPUT   
  SINGLE_SWITCH : BOOL;
  CLICK_EN : BOOL := TRUE;
  CLICK_TIME : TIME := T#500ms;
  MAX_RUNTIME : TIME := T#60s;
  PositionReachedDelay : TIME := t#3s; (*1.8*)
  MANUAL_TIMEOUT: TIME := T#1h;
  DEBOUNCE_TIME : TIME := T#20ms;
  DBL_CLK1 : BOOL := FALSE;
  DBL_POS1 : BYTE;
  DBL_ANG1 : BYTE;
  DBL_CLK2 : BOOL := FALSE;
  DBL_POS2 : BYTE := 255;
  DBL_ANG2 : BYTE := 255;
  D1_TOGGLE : BOOL := TRUE;
  D2_TOGGLE : BOOL := TRUE;
  MASTER_MODE : BOOL;
END_VAR
VAR_OUTPUT
  QU : BOOL := TRUE;
  QD : BOOL := TRUE;
  STATUS : BYTE;
  PO : BYTE := 255;
  AO : BYTE := 255;
  D1, D2 : BOOL;
END_VAR
VAR
  s1e, s2e : TOF;
  s1d, s2d : CLICK_MODE;
  dir : BOOL;
  tx: TIME;
  last: TIME;
  TimePositionReached: TIME; (*1.8*)
END_VAR
VAR_TEMP
  TOP_SI: STRUCT
    EV_CLASS: BYTE;
    EV_NUM:   BYTE;
    PRIORITY: BYTE;
    NUM:      BYTE;
    TYP2_3:   BYTE;
    TYP1:     BYTE;
    ZI1:      WORD;
    ZI2_3:    DWORD;
  END_STRUCT;
  START_UP_SI: STRUCT
    EV_CLASS: BYTE;
    EV_NUM:   BYTE;
    PRIORITY: BYTE;
    NUM:      BYTE;
    TYP2_3:   BYTE;
    TYP1:     BYTE;
    ZI1:      WORD;
    ZI2_3:    DWORD;
  END_STRUCT;
  ERR : INT;
END_VAR


Die Fehlermeldung bleibt trotz  POS <  BYTE#255 die gleiche:
1. unzulässige Operandentypen, 2. Der Ausdruck muss vom Datentyp Bool sein. Der Code sieht so aus:
134:  (* manual operation single click up *)
      QU := TRUE;
      QD := FALSE;
      PO := POS; AO := ANG;
      //IF tx - last >= max_runtime THEN status := 131; END_IF; (*1.8*)
      IF POS < BYTE#255 THEN TimePositionReached := tx; END_IF; (*1.8*)
      IF tx - last >= max_runtime OR tx - TimePositionReached >= PositionReachedDelay THEN status := 131; END_IF; (*1.8*)

  135:  (* manual operation single click dn *)
      QU := FALSE;
      QD := TRUE;
      PO := POS; AO := ANG;
      //IF tx - last >= max_runtime THEN status := 131; END_IF; (*1.8*)
      IF POS > BYTE#0 THEN TimePositionReached := tx; END_IF; (*1.8*)
      IF tx - last >= max_runtime OR tx - TimePositionReached >= PositionReachedDelay THEN status := 131; END_IF; (*1.8*)
#6
Obwohl ich TimePositionReached: TIME; noch unter VAR definiert habe, kommt beim Übersetzen der Zeile
IF POS < 255 THEN TimePositionReached := tx; END_IF; (*1.8*)

"Unzulässige Operandentypen" und
"der Ausdruck mus vom Datentyp BOOL sein"




[gelöscht durch Administrator]
#7
mattsches ist der Knüller, muss ich heute Abend mal probieren...
#8
So, ich bin jetzt auch mal dabei...
#9
Gibts hier keinen SCL Spezi, der sich der Sache mal annimmt? Ich teste dann gerne...
#10
Ich probier's auch mal, danke...

Der Rolladen fährt auf, wenn ich den Fenstergriff drehe und bleibt dann stehen, wenn ich ihn wieder schließe. Zurück in die Position, in der der Rolladen stand, als ich den Fenstergriff betätigt habe, fährt der Rolladen nicht. Ist das so geplant? Ich dachte, der Rolladen fährt die alte Position wieder an...
#11
Ich arbeite mit den Weckalarmen OB32-OB35. Den OB 32 lasse ich im 20 ms Zyklus laufen mit den Raffstores drin. Temperaturregelungen etc. lasse ich dann im OB35 mit 500 ms laufen. Das resultiert in einer Gesamtzykluszeit bei einer 315 PN von weit unter 20 ms. In der Anleitung steht, dass sich SENS auf die Zeit zur Bearbeitung des Bausteins (BLIND_SHADE) und nicht auf die Zykluszeit der CPU bezieht. Meine Raffstores brauchen auch ca. 1.1 Sekunde zum Lamellenverstellen. Demnach müsste die Zykluszeit bei SENS=5 < 0,43 ms sein. Für den Baustein stimmt das bestimmt bei einer Zykluszeit von 20ms, aber für die CPU halte ich das für nicht machbar. Im Moment fehlt mir sogar eine Idee, wie das überhaupt unabhängig von der Zykluszeit gehen soll. Wenn die Lamellen z.B. 1,0 s für die Verstellung brauchen und die Zykluszeit 50 ms ist heißt das ja, dass ein DO mindestens für 50 ms ausgegeben wird, was automatisch bedeutet, dass ich die Jalousie nur in 5% Schritten fahren kann und nicht in 1% Schritten. Demnach müsste sich die Zykluszeit in der Anleitung doch auf den CPU Zyklus und nicht auf die Bearbeitungszeit des Bausteins beziehen. Zur Veranschaulichung ein extremes Beispiel: Deine Zykluszeit geht auf 500 ms hoch, keine Chance das zu optimieren. Damit sitzt ein DO für minestens 500 ms, was zur Folge hat, dass bei einer Lamellenverstellung von 1 s diese immer zu mindestens 50% fährt. Ist jetzt die Auflösung kleiner als 50, erkennt BLIND_SHADE eine Abweichung von Soll zu Ist und setzt wieder den anderen Ausgang und dann nimmt das Unglück seinen Lauf - auf, zu, auf zu, weil der Sollwert z.B. 25% ist, die angefahrene Position aber durch die Zykluszeit nur 100%, 50% oder 0% sein kann.