31
SPS-Programmierung / Re: Objektorientiert Programmieren
« am: 19. Februar 2008, 00:51:36 »
Schöne Sache, nur zu spät, wenn die Hardware schon zu Hause steht ... 
Beiträge anzeigen
Diese Sektion erlaubt es ihnen alle Beiträge dieses Mitglieds zu sehen. Beachten sie, dass sie nur solche Beiträge sehen können, zu denen sie auch Zugriffsrechte haben.
32
oscat.lib fuer TwinCAT/CoDeSys / Re: BLIND_INPUT, Automatik und manueller Betrieb?
« am: 19. Dezember 2007, 03:47:43 »... 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.
33
Bestehende Module / Existing Modules / PI-Regler
« am: 03. November 2007, 12:58:08 »
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
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
34
Bestehende Module / Existing Modules / Re: PID-Regler
« am: 31. Oktober 2007, 07:28:41 »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.
35
Bestehende Module / Existing Modules / Re: PID-Regler
« am: 30. Oktober 2007, 09:56:12 »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
36
Bestehende Module / Existing Modules / PID-Regler
« am: 26. Oktober 2007, 17:52:24 »
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
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
37
Bestehende Module / Existing Modules / Re: Baustein Ltime
« am: 23. Oktober 2007, 20:11:03 »
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 ...
Wie auch immer, die Abfrage kann nicht schaden. Keep up the good work ...
38
Bestehende Module / Existing Modules / Re: Baustein Ltime
« am: 22. Oktober 2007, 21:10:43 »
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?
----------------------------------------------------------------
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?
39
Bestehende Module / Existing Modules / Re: Baustein Ltime
« am: 22. Oktober 2007, 19:12:29 »
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.
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.
40
oscat.lib fuer TwinCAT/CoDeSys / Pi-Konstante mehrfach deklariert
« am: 17. Oktober 2007, 03:07:04 »
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
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