Beiträge

Schöne Sache, nur zu spät, wenn die Hardware schon zu Hause steht ...  :(

... zuvor war die Automatik im Nachtmodus. Jetzt schaue ich nach mehr als 2 Stunden nach. Es ist die Jalousie noch immer oben, der Status ist auf 132 - also noch immer auf manuell Hoch. - Er hat also noch immer nicht in den Automatikmodus zurückgeschalten? Warum nicht?

Ist doch imho korrekt, Handbetätigung im Nachtbetrieb schaltet die Automatik für diese Nacht ab.

Hallo Hugo,

am neuen FT_PI sind mir 2 Sachen aufgefallen. Der "overflow" kann eigentlich nie kommen, da der "integ.out" auf größer bzw. kleiner Limit verglichen wird und der Integrator auf Limit begrenzt. Zum Zweiten wird der "LIM" nicht zurückgesetzt, da die entsprechende ELSE-Bedingung fehlt (sieht beim PID auch so aus, war bei der 2.2 noch drin).

Den PI find ich gut, werde ich mal für meine FBH testen. D-Anteil brauch ich da eh nicht.


Gruß

Tom

das mit dem pid regler muss ich mir in aller ruhe ansehen.

Nur keine Hektik. Ich frag mich sowieso, wo du die Zeit für so ein Projekt hernimmst.

[ELSIF integ.Out <= (limit_L - offset) / KP THEN Y := limit_L; overflow := TRUE;]

das problem tritt auch dann auf wenn ein system zykluszeiten < 1ms hat.

Wegen T_PLC_US, da ja im Prinzip 1ms die kleinste Auflösung ist,oder?

Da ist noch etwas: Hab mal bissel mit dem Regler rumgespielt. Ich brauche ein Ausgangssignal mit unterem Limit von 0. Feine Sache, dachte ich, nimmste limit_L, dann brauchste keine externe Beschaltung. Funktioniert leider nicht, da dann bei einem Istwert außerhalb von int_band der Ausgang generell auf 0 geht. Das Problem ist, dass der Integrator korrekt auf 0 gesetzt ist, die Zusammenrechnung der PID-Teile in der ELSE-Verzweigung dadurch aber nicht mehr bearbeitet wird (integ.Out = limit_L).

IF integ.Out >= (limit_H - Offset) / KP THEN
      Y := limit_H;
      overflow := TRUE;
   ELSIF integ.Out <= (limit_L - offset) / KP THEN
      Y := limit_L;
      overflow := TRUE;
   ELSE
      Y := KP * (integ.Out + deriv.out + diff) + offset;
      overflow := FALSE;
   END_IF;


Vielleicht sollte bei IF und ENDIF auch noch int_band abgefragt werden.


Und dann wäre noch persönlicher Wunsch. Betrifft den Baustein "blind_control": Der "blind_actuator" wird ja nicht mehr gebraucht, da vom "blind_control" direkt aufgerufen. Das Problem ist, dass ich die Lockout-Zeit nicht mehr verändern kann. Meine Antriebe sind mit 500ms angegeben. Wäre nicht schlecht, wenn man den Wert im "blind_control" ändern könnte.




Gruß

Tom

Hallo,

ich schon wieder. Der PID-Regler lässt bei mir die PLC auf stop gehen, Fehlermeldung "Division durch 0!". Das Problem scheint im "FT-deriv" zu liegen. Beim ersten Aufruf wird last=tx gesetzt, in der Formel

    out := (in - old) / DWORD_TO_REAL(tx - last) * 1000000.0 * K;

ensteht dann durch tx-last eine  Division durch 0. Eventuell mit

    IF run AND NOT init THEN

die Berechnung beim ersten Aufruf nicht durchführen?


Gruß,

Tom

Mit CFC hab ich noch gar nicht gearbeitet. Sollte ich mir vielleicht mal anschauen. Reihenfolge ist richtig. Hab mal mit einem kleinen FB die Werte vom NT_GetTime in ein Array gelesen. Im ersten Zyklus sind alle Werte auf 0, daher das Problem, erst im 2 Zyklus werden korrekte Werte geliefert. Vielleicht liegts daran, dass ich meine Testumgebung in einer VM von VMWARE laufen hab, dann entschuldige den Trouble. Mein CX ist halt noch nicht betriebsbereit.  ::)  Wie auch immer, die Abfrage kann nicht schaden.

Keep up the good work ...  :)

Hab das grad mal getestet: Die Variable "next_check" hat jetzt das richtige Datum, die Sommerzeit wird aber erst nach dem nächsten Check zur vollen Stunde gesetzt, wegen der Reihenfolge im Programm. Wenn man die init-Verzweigung weglässt, funktioniert das Ganze, weiss nur nicht wie das performancemäßig aussieht, die Verzweigung war ja sicher nicht umsonst drin. Kann man aber bei den Aufrufen im Stundentakt sicher verschmerzen. So sähe das aus:

----------------------------------------------------------------

IF utc > next_check  OR next_check > (utc+T#2h) THEN
   local_dt := utc + time_zone_offset;
   next_check := DWORD_TO_DT(DT_TO_DWORD(utc) / 3600 * 3600 +3600);
   DST_on := DST(local_dt, time_zone_offset);
   IF DST_on AND dst_enable THEN time_adder := time_zone_offset + T#1h; ELSE time_adder := time_zone_offset; END_IF;
END_IF;
local_dt :=utc + time_adder;
wday := weekday(DT_TO_DATE(local_dt));

----------------------------------------------------------------

Man könnte auch statt "local_dt" eine andere Hilfsvariable beim Check für verwenden, der Übersichtlichkeit halber.

----------------------------------------------------------------

IF utc > next_check  OR next_check > (utc+T#2h) THEN
   temp_dt := utc + time_zone_offset;
   next_check := DWORD_TO_DT(DT_TO_DWORD(utc) / 3600 * 3600 +3600);
   DST_on := DST(temp_dt, time_zone_offset);
   IF DST_on AND dst_enable THEN time_adder := time_zone_offset + T#1h; ELSE time_adder := time_zone_offset; END_IF;
END_IF;
local_dt :=utc + time_adder;
wday := weekday(DT_TO_DATE(local_dt));

----------------------------------------------------------------



Bei mir funktioniert's, oder hab ich was übersehen? Was sagst du dazu, Hugo?

Hab den Thread noch mal ausgegraben.

Es scheint immer noch ein Problem zu geben, zumindest bei meinem CX mit Lib2.1. Das Auslesen der Uhrzeit dauert halt etwas und scheint nicht sauber zu sein. Der "Ltime" rechnet zumindest mit einem falschen Wert, in der Variable next_check steht "2042-11-02-02:00", damit findet auch keine Korrektur mehr statt. Ich hab mir damit beholfen, dass ich "Ltime" überspringe, solange der "NT_GetTime" busy ist. Vielleicht ist auch eine andere Lösung möglich, z.B. im "Ltime" in der ersten Zeile auch zu prüfen, ob "next_check" größer eine Stunde gegenüber "utc" ist und bei TRUE die Berechnungen durchlaufen zu lassen.

Hallo,

zuerst ein mal vielen Dank für die Entwicklung dieser Lib. Tolle Arbeit!  :)

Leider habe ich ein kleines Problem: Mir ist aufgefallen, dass PI sowohl in der Beckhoff TcSystem.lib als auch in der oscat.lib definiert ist. Allerdings werden unterschiedliche Datentypen verwendet: LREAL bei Beckhoff und REAL bei euch. Gibts Probleme, wenn ich die Deklaration aus der oscat.lib entferne?


Gruß

Tom